Designing Integrated Solutions - Windows Azure Libraries for .NET FAQ

http://msdn.microsoft.com/en-us/library/gg602420.aspx#SB_FAQ

Windows Azure Libraries for .NET FAQ

If you have questions about the Windows Azure Service Bus pricing structure, see the FAQ in the following section. You can also visit theWindows Azure Platform pricing FAQ for general Windows Azure pricing information.

Service Bus FAQ

• What is the Windows Azure Service Bus? 
  
  
• What are typical usage scenarios for the Service Bus? 
  
  
• What are the main capabilities and benefits of the Service Bus? 
  
  
• How do you currently charge for the Service Bus? 
  
  
• How will you charge for the Service Bus once the promotional period ends? 
  
  
• What usage of the Service Bus is subject to data transfer? What is not? 
  
  
• What exactly is a Service Bus “relay”? 
  
  
• How is the Relay Hours meter calculated? 
  
  
• What if I have more than one listener connected to a given relay? 
  
  
• What happened to the “Service Bus Connections” billing meter? 
  
  
• How is the Messages meter calculated for queues, topics/subscriptions, and message buffers? 
  
  
• How is the Messages meter calculated for relays? 
  
  
• Are management operations and control messages counted as billable Messages? 
  
  
• Does the Service Bus charge for storage? 
  
  
• How much billable usage will I see if I operate 100 queues for 24 hours, each processing one 128 KB message per minute? 
  
  
• How much billable usage will I see if I operate 1 topic with 4 subscriptions for 24 hours, processing one 45 KB message per second? 
  
  
• How much billable usage will I see if I operate 10 non-netTCP relays for 24 hours, each processing one 8KB message per second? 
  
  
• How much billable usage will I see if I operate 10 netTCP relays for 24 hours, each processing one 8KB message per second? 
  
  
• Does the Service Bus have any usage quotas? 
  
  

What is the Windows Azure Service Bus?

The Windows Azure Service Bus provides secure messaging and relay capabilities that enable building distributed and loosely-coupled applications in the cloud. The Windows Azure Service Bus also enables developing hybrid applications that span private clouds, public clouds and clients running on PCs, mobile devices, or in the browser. It supports multiple messaging protocols and patterns and handles delivery assurance, reliable messaging and scale for your applications. The Service Bus is a managed service that is operated by Microsoft and has a 99.9% monthly SLA.

What are typical usage scenarios for the Service Bus?

Some common applications of the Service Bus include:

• Hybrid applications: Enables you to securely connect and integrate enterprise systems running in your private cloud with applications running on Windows Azure. This makes it easier to extend solutions to the cloud without having to port or migrate all of your data or code from an existing enterprise datacenter to Windows Azure.
  
  
• Mobile applications: Enables you to easily build applications that can distribute event notifications and data to occasionally connected clients, such as smartphones or tablets. You can expose notifications or events from an application running either in Windows Azure or in your private cloud environment, and ensure that they are ultimately delivered to mobile devices.
  
  
• Loosely coupled architectures: Enables you to build loosely coupled systems that are more resilient to network failure and can more easily scale out based on demand. The Service Bus can act as the connecting broker between the different components of a system, eliminating direct dependencies between different components. Easily leverage the Service Bus to architect applications that support application load balancing.
  
  

What are the main capabilities and benefits of the Service Bus?

Service Bus Messaging

• Service Bus queues offer a reliable, highly scalable way to store messages as they travel between systems without losing messages in the event of connectivity failure.
  
  
• Service Bus topics and subscriptions implement a publish/subscribe pattern that delivers a highly scalable, flexible, and cost-effective way topublish messages from an application and deliver them to multiple subscribers.
  
  

Service Bus Connectivity

• The Service Bus relay enables applications hosted in Windows Azure to securely call back to private cloud-based applications hosted in your own datacenter behind a firewall, and vice versa. The relay service avoids the need to instantiate and set up a new connection on each call and makes connectivity faster and more reliable. It also supports the ability to integrate applications across existing NATs and firewalls. The relay service supports a variety of different transport protocols and Web services standards, including REST, SOAP, and WS-*.
  
  
• Companies can use the Service Bus relay to expose just the information they want from their private cloud environment, which creates an architecture more secure than opening up a VPN. Enterprises can use a SOA-based architecture and expose just the services they want to deliver from their on-premise data centers.
  
  

How do you currently charge for the Service Bus?

We are currently not charging for any of the Service Bus capabilities. This promotional period will end for all billing months beginning March 31, 2012.

How will you charge for the Service Bus once the promotional period ends?

At the end of the promotional period, these meters will be billed as follows:

1. Messages – Messages sent to or delivered by the Service Bus will be billed at $0.01 per 10,000 messages. Messages are charged based on the number of messages sent to, or delivered by, the Service Bus during the billing month. This includes delivery of “null” messages in response to receive requests against empty queues/subscriptions. Messages over 64KB in size will be charged an additional message for each additional 64KB of data (rounded up). This meter applies to relays as well as queues, topics, subscriptions, and message buffers.
   
   
2. Relay Hours – This meter applies only when using the Service Bus relay capability. There is no relay hour charge if you are only using Service Bus queues, topics/subscriptions, or message buffers. Relay hours will be billed at $0.10 per 100 relay hours, and charged from the time the relay is opened (the first listener connect on a given relay address) to the close of the relay (the last listener disconnect from that relay address), and rounded up to the next whole hour.
   
   

In addition to the prices noted above for the Service Bus, you will be charged for associated data transfers for egress outside of the data center in which your application is provisioned. You can find more details in the What usage of the Service Bus is subject to data transfer? What is not? section below.

What usage of the Service Bus is subject to data transfer? What is not?

Any data transfer within a given Windows Azure sub-region is provided at no charge. Any data transfer outside a sub-region is subject to egress charges at the rate of $0.15 per GB from the North America and Europe regions, and $0.20 per GB from the Asia-Pacific region. Any inbound data transfer is provided at no charge.

What exactly is a Service Bus “relay”?

A relay is a Service Bus entity that relays messages between clients and Web services. The relay provides the service with a persistent, discoverableService Bus address, reliable connectivity with firewall/NAT traversal capabilities, and additional features such as automatic load balancing. A relay is implicitly instantiated and opened at a given Service Bus address (namespace URL) whenever a relay-enabled WCF service, or “relay listener,” first connects to that address. Applications create relay listeners by using the Service Bus .NET managed API, which provides special relay-enabled versions of the standard WCF bindings.

How is the Relay Hours meter calculated?

Relay hours are billed for the cumulative amount of time during which each Service Bus relay is “open” during a given billing period. A relay is implicitly instantiated and opened at a given Service Bus address (service namespace URL) when a relay-enabled WCF service, or “Relay listener,” first connects to that address. The relay is closed only when the last listener disconnects from its address. Therefore, for billing purposes a relay is considered “open” from the time the first relay listener connects, to the time the last relay listener disconnects from the Service Bus address of that relay. In other words, a relay is considered “open” whenever one or more relay listeners are connected to its Service Bus address.

What if I have more than one listener connected to a given relay?

In some cases, a single relay in the Service Bus may have multiple connected listeners. This can occur with load-balanced services that use thenetTCPRelay or *HttpRelay WCF bindings, or with broadcast event listeners that use the netEventRelay WCF binding. A relay in the Service Bus is considered “open” when at least one relay listener is connected to it. Adding additional listeners to an open relay does not change the status of that relay for billing purposes. The number of relay senders (clients that invoke or send messages to relays) connected to a relay also has no effect on the calculation of relay hours.

What happened to the “Service Bus Connections” billing meter?

The Service Bus no longer charges for connections. However, there are quotas limiting the number of simultaneous connections that can be open against any single Service Bus entity. See the Does the Service Bus have any usage quotas? section below.

How is the Messages meter calculated for queues, topics/subscriptions, and message buffers?

Each message sent to or delivered by the Service Bus counts as a billable message. This applies to all Service Bus entity types, including queues, topics/subscriptions, message buffers, and relays.

A message is defined as a unit of data which is 64KB or less in size. In the case of brokered entities (queues, topics/subscriptions, message buffers), any message that is less than or equal to 64KB in size is considered as one billable message. If the message is greater than 64KB in size, the number of billable messages is calculated according to the message size in multiples of 64KB. For example, an 8 KB message sent to the Service Bus will be billed as one message, but a 96 KB message sent to the Service Bus will be billed as two messages. In most cases, the same method of determining billable messages is applicable to relays as well. See the How is the Messages meter calculated for relays?section for details about the exception cases for relays.

Multiple deliveries of the same message (for example, message fan out to multiple listeners or message retrieval after abandon, deferral, or dead lettering) will be counted as independent messages. For example, in the case of a topic with three subscriptions, a single 64 KB message sent and subsequently received will generate four billable messages (one “in” plus three “out”, assuming all messages are delivered to all subscriptions).

In general, management operations and “control messages,” such as completes and deferrals, are not counted as billable messages. There are two exceptions:

1. Null messages delivered by the Service Bus in response to requests against an empty queue, subscription, or message buffer, are also billable. Thus, applications that poll against Service Bus entities will effectively be charged one message per poll.
   
   
2. Setting and getting state on a MessageSession will also result in billable messages, using the same message size-based calculation described above.
   
   

How is the Messages meter calculated for relays?

In general, billable messages are calculated for relays using the same method as described above for brokered entities (queues, topics/subscriptions and message buffers). However, there are several notable differences:

1. Sending a message to a Service Bus relay is treated as a “full through” send to the relay listener that receives the message, rather than a send to the Service Bus relay followed by a delivery to the relay listener. Therefore, a request-reply style service invocation (of up to 64 KB) against a relay listener will result in two billable messages: one billable message for the request and one billable message for the response (assuming the response is also <= 64 KB). This differs from using a queue to mediate between a client and a service. In the latter case, the same request-reply pattern would require a request send to the queue, followed by a dequeue/delivery from the queue to the service, followed by a response send to another queue, and a dequeue/delivery from that queue to the client. Using the same (<= 64 KB) size assumptions throughout, the mediated queue pattern would thus result in four billable messages, twice the number billed to implement the same pattern using relay. Of course, there are benefits to using queues to achieve this pattern, such as durability and load leveling. These benefits may justify the additional expense.
   
   
2. Relays that are opened using the NetTCPRelay WCF binding treat messages not as individual messages but as a stream of data flowing through the system. In other words, only the sender and listener have visibility into the framing of the individual messages sent/received using this binding. Thus, for relays using the netTCPRelay bindng, all data is treated as a stream for the purpose of calculating billable messages. In this case, the Service Bus will calculate the total amount of data sent or received via each individual relay on an hourly basis and divide that total by 64 KB in order to determine the number of billable messages for the relay in question during that hour.
   
   

Are management operations and control messages counted as billable Messages?

Management operations, such as enumerating subscriptions on a topic or determining queue depth, and “control messages,” such as completes anddeferrals, are not generally counted as billable messages. There are two exceptions:

1. “Null” messages delivered by the Service Bus in response to requests against an empty queue, subscription or message buffer are billable. Therefore, applications that poll against Service Bus entities will effectively be charged one message per poll.
   
   
2. Setting and getting state on a MessageSession will also result in billable messages, using the same message size based calculation described above.
   
   

Does the Service Bus charge for storage?

No, the Service Bus does not charge for storage. However, there is a quota limiting the maximum amount of data that can be persisted per queue/topic. See the Does the Service Bus have any usage quotas? section below.

How much billable usage will I see if I operate 100 queues for 24 hours, each processing one 128 KB message per minute?

• Assume all messages in each queue are delivered exactly once.
  
  
• 1 message of 128 KB = 2 billable messages (128 KB/64 KB).
  
  
• 2 billable messages sent per minute + 2 billable messages delivered per minute = 4 billable messages per queue per minute.
  
  
• 4 messages per queue per minute * 1,440 minutes per day = 5,760 messages per queue per day.
  
  
• Total billable messages per day sent to/delivered by the Service Bus = 5,760 messages per queue per day * 100 queues = 576,000 messages per day.
  
  
• 576,000 Service Bus messages cost 576,000/10,000 * $0.01 = 58 * $0.01 = $0.58 per day.
  
  

How much billable usage will I see if I operate 1 topic with 4 subscriptions for 24 hours, processing one 48 KB message per second?

• Assume all subscriptions receive all messages, and all messages in each subscription are delivered exactly once.
  
  
• 1 message of 48 KB = 1 billable message.
  
  
• 1 billable message per second * 86,400 seconds per day = 86,400 billable messages per day sent to the topic.
  
  
• 86,400 messages per day * 4 subscriptions = 345,600 messages per day delivered to subscription clients.
  
  
• Total billable messages per day sent to/delivered by the Service Bus = 86,400 + 345,600 = 432,000 messages per day.
  
  
• 432,000 Service Bus messages cost 432,000/10,000 * $0.01 = 44 * $0.01 = $0.44 per day.
  
  

How much billable usage will I see if I operate 10 non-netTCP relays for 24 hours, each processing one 8KB message per second?

• Assume a request/reply pattern and all requests receive replies <= 64 KB in size.
  
  
• 1 message of 8 KB = 1 billable message.
  
  
• 1 billable message per second * 86,400 seconds per day = 86,400 billable messages per day for request messages sent via each relay.
  
  
• Since all requests receive replies, also have 86,400 billable messages per day for reply messages sent via each relay.
  
  
• Total billable messages per day per relay = 86,400 * 2 = 172,800.
  
  
• Total billable messages per day sent to/received by the Service Bus = 172,800 * 10 Relays = 1,728,000.
  
  
• 1,728,000 Service Bus messages cost 1,728,000/10,000 * $0.01 = 173 * $0.01 = $1.73.
  
  
• 10 relays open 24 hours = 240 relay hours.
  
  
• 240 relay hours cost 240/100 * $0.10 = 3 * $0.10 = $0.30.
  
  
• Total cost = $1.73 + $0.30 = $2.03 per day.
  
  

How much billable usage will I see if I operate 10 netTCP relays for 24 hours, each processing one 8KB message per second?

• Assume a request/reply pattern and all requests receive replies <= 64 KB in size.
  
  
• 8 KB per second * 3,600 seconds per hour = 28,800 KB per hour for request messages sent via each relay.
  
  
• Since all requests receive replies, also have 28,800 KB per hour for reply messages sent via each relay.
  
  
• Total message data per hour per relay = 57,600 KB.
  
  
• 57,600 KB = 57,600/64 or 900 billable messages per hour per relay = 900 * 24 or 21,600 billable messages per day per relay.
  
  
• Total billable messages per day sent to/received by the Service Bus = 21,600 messages * 10 relays = 216,000.
  
  
• 216,000 Service Bus messages cost 216,000/10,000 * $0.01 = 22 * $0.01 = $0.22.
  
  
• 10 relays open 24 hours = 240 relay hours.
  
  
• 240 relay hours cost 240/100 * $0.10 = 3 * $0.10 = $0.30.
  
  
• Total cost = $0.22 + $0.30 = $0.52 per day.
  
  

Does the Service Bus have any usage quotas?

By default, for any cloud service Microsoft sets an aggregate monthly usage quota that is calculated across all of a customer’s subscriptions. Because we understand that you may need more than these limits, please contact customer service at any time so that we can understand your needs and adjust these limits appropriately. For the Service Bus, the aggregate usage quotas are as follows:

• 5 billion messages
  
  
• 2 million relay hours
  
  

While we do reserve the right to disable a customer's account that has exceeded its usage quotas in a given month, we will provide e-mail notification and make multiple attempts to contact a customer before taking any action. Customers exceeding these quotas will still be responsible for charges that exceed the quotas.

As with other services on Windows Azure, the Service Bus enforces a set of specific quotas to ensure that there is fair usage of resources. The following are the usage quotas that the service enforces:

• Queue/topic size – You specify the maximum queue or topic size upon creation of the queue or topic. This quota can have a value of 1, 2, 3, 4, or 5 GB. If the maximum size is reached, additional incoming messages will be rejected and an exception will be received by the calling code.
  
  
• Number of concurrent connections 
  
  
  • Queue/Topic/Subscription - The number of concurrent TCP connections on a queue/topic/subscription is limited to 100. If this quota is reached, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. For every messaging factory, the Service Bus maintains one TCP connection if any of the clients created by that messaging factory have an active operation pending, or have completed an operation less than 60 seconds ago. REST operations do not count towards concurrent TCP connections.
    
    
  • Message Buffer - The Service Bus only supports REST operations for message buffers. Therefore, a connection quota does not apply.
    
    
• Number of concurrent listeners on a relay – The number of concurrent NetTcpRelay and NetHttpRelay listeners on a relay is limited to 25(1 for a NetOneway relay).
  
  
• Number of concurrent relay listeners per service namespace – The Service Bus enforces a limit of 2000 concurrent relay listeners per service namespace. If this quota is reached, subsequent requests to open additional relay listeners will be rejected and an exception will be received by the calling code.
  
  
• Number of topics/queues per service namespace – The maximum number of topics/queues (durable storage-backed entities) on a service namespace is limited to 10,000. If this quota is reached, subsequent requests for creation of a new topic/queue on the service namespace will be rejected. In this case, the management portal will display an error message or the calling client code will receive an exception, depending on whether the create attempt was done via the portal or in client code.
  
  
• Message size quotas 
  
  
  • Queue/Topic/Subscription 
    
    
    • Message size – Each message is limited to a total size of 256KB, including message headers.
      
      
    • Message header size – Each message header is limited to 64KB.
      
      
  • Message Buffer - Each message is limited to a total size of 64KB, including message headers.
    
    
  • NetOneway and NetEvent relays - Each message is limited to a total size of 64KB, including message headers.
    
    
  • Http and NetTcp relays – The Service Bus does not enforce an upper bound on the size of these messages.
    
    
  Messages that exceed these size quotas will be rejected and an exception will be received by the calling code.
  
  
• Number of subscriptions per topic – The maximum number of subscriptions per topic is limited to 2,000. If this quota is reached, subsequent requests for creating additional subscriptions to the topic will be rejected. In this case, the management portal will display an error message or the calling client code will receive an exception, depending on whether the create attempt was done via the portal or in client code.
  
  
• Number of SQL filters per topic – the maximum number of SQL filters per topic is limited to 2,000. If this quota is reached, any subsequent requests for creation of additional filters on the topic will be rejected and an exception will be received by the calling code.
  
  
• Number of correlation filters per topic – the maximum number of correlation filters per topic is limited to 100,000. If this quota is reached, any subsequent requests for creation of additional filters on the topic will be rejected and an exception will be received by the calling code.
  

FAQ for Windows Azure Caching

Windows Azure Platform

• What is Windows Azure Caching? 
  
  
• How do I purchase the Caching service? 
  
  
• What are the advantages of using Caching vs. hosting my own caching solution on Windows Azure? 
  
  
• What if I need a different size cache or bigger size cache than the options that you are providing? 
  
  
• Can I change the cache size after I signed up and provision it? 
  
  
• What kind of data can I store in the cache? 
  
  
• How does the Windows Azure Caching service relate to Windows Server AppFabric Caching? 
  
  
• Does the caching service have any usage quotas? 
  
  

What is Windows Azure Caching?

The Caching service is a distributed, in-memory cache that you can use to accelerate the performance and scale of your cloud applications built on Windows Azure and SQL Azure. Caching is often used to keep frequently-queried data in-memory close to the application itself, which both reduces overhead on the database tier and also eliminates unnecessary network latency.

ASP.NET developers can use the Caching service without code changes, as pre-built session state and output caching providers enable you to activate with simple configuration changes. Caching capabilities are also directly available using a simple API for even more flexible and customized application use. At runtime, the Cache service transparently distributes ASP.NET session/output cache data or .NET Framework objects stored in the cache across the elastic, scale-out infrastructure.

Because it is delivered as a true service, Caching has a very simple provisioning model – there is no complex infrastructure to install, set up or manage. This is performed for you by the service itself. There are only two things to configure: the data that you want to store and how large a cache you need.As the needs of your application grow or decrease, you can dynamically change the size of the elastic cache based on your needs.

How do I purchase the Caching service?

You can sign up to use the Caching service through the Windows Azure portal.

If you are signed up to one of the Windows Azure Platform offers you might be eligible to get the 128MB cache option for free for a certain period of time depending on the specific offer. You can find more details on the Windows Azure Platform Offers page.

The regular prices of the different cache size are the following:

• 128 MB cache for $45.00/month
  
  
• 256 MB cache for $55.00/month
  
  
• 512 MB cache for $75.00/month
  
  
• 1 GB cache for $110.00month
  
  
• 2 GB cache for $180.00/month
  
  
• 4 GB cache for $325.00/month
  
  

We are running a promotion in which we will start charging for any cache size only on August 1st, 2011, until then you will not be charged for the service.

What are the advantages of using Caching vs. hosting my own caching solution on Windows Azure?

Consistent with other Windows Azure Platform services, Caching provides a true Platform as a Service (PaaS) model in which the cost and complexity of installing, configuring, and managing the infrastructure is hidden from you. All you do is provision and configure the service. This means that the total cost of ownership can be significantly lower over the lifetime of your application. The table shown here summarizes several advantages to a service vs. a hosted do-it-yourself solution:

 

 CachingHosted Do-it-Yourself

Dedicated memory

With Caching, you are guaranteed the complete cache size at all times.

With a hosted caching solution, you can only use a part of the instance memory because part of the memory is consumed by the operating system and other running processes.

Ease of use

Caching handles of all the service details. All you have to do is use it.

With a hosted caching solution, you are responsible for installation and configuration in addition to ongoing management and maintenance.

Distributed

Because Cachingis distributed, it can scale with the demand of your applications. You just visit the portal and increase the memory size.

With a hosted caching solution, your application scale is limited by the capacity of the compute instance hosting your cache. You must manually add and prepare additional instances.

Service Level Agreement (SLA)

We promise uptime and availability of the service in our SLA.

With a hosted caching solution, you are not guaranteed any uptime.

What if I need a different size cache or bigger size cache than the options that you are providing?

You can sign up and provision more than one cache. By doing this, you can have a combination of caches that add up to sizes that differ from we provide out-of-the-box. They will also be bigger than the maximum size cache we provide. It is up to you to select the most cost effective option for your needs.

Can I change the cache size after I signed up and provision it?

Yes. You can upgrade or downgrade the cache size that you signed up for after you start to use the cache. If you upgrade to a bigger size cache, existing data in the cache will remain intact. If you downgrade, and have more data in the cache than the size of the cache to which you are downgrading, the regular cache eviction policy will occur and the least-recently-accessed data in the cache will be removed as needed.

From a cost perspective, the service is billed monthly based on the cache size you are signed up for, but the charge is calculated on a daily basis. When upgrading or downgrading between cache sizes, you will be charged for that month according to the portion of days you were signed up for each cache size.

For instance, if you were signed up for the 128MB ($45/month) cache for 10 days of the month, and then upgraded to the 256MB ($55/month) cache size for the rest of the 20 days during that month, you will pay the total of 45/(10/30) + 55/(20/30) = $51.67 for that month.

What kind of data can I store in the cache?

You can store any kind of data in the cache. The only requirement is that the data is serializable. This includes but is not limited to:

• Common Language Runtime (CLR) objects
  
  
• Rows
  
  
• XML
  
  
• Binary data
  
  

You can programmatically interact with the cache using the simple .NET Framework API. You can also configure the cache as a provider for ASP.NET session state and page output.

How does the Windows Azure Caching service relate to Windows Server AppFabric Caching?

They are built on the same underlying technology platform. The Windows Azure Caching service is a service that you can use on Windows Azure. For Windows Azure Caching, Microsoft has created all of the underlying cache infrastructure for you and automated the provisioning and management of the cache on Windows Azure). For more information, see Windows Azure Caching Service on MSDN.

Does the caching service have any usage quotas?

Once you provision a cache of a certain size, the service limits the amount data you put in the cache to that size. If you try to put more data into the cache than the size you provisioned, the caching service will automatically remove data to make space for the new data that you are adding. The data deletion process is asynchronous and follows the least-recently-used (LRU) policy. The process also runs in a controlled manner to achieve maximum efficiency. Because of this, your application might temporarily have more data in the cache than the size for which you signed up, but the system will soon take corrective action and delete data from your cache to keep your cache size within the provisioned size.

As with other services in the Windows Azure platform, in order to make sure there is fair usage of resources, the service might enforce limitations based on the number of transactions being made against the cache, the total bandwidth being consumed, or the number of concurrent connections being used. If you exceed the limitations enforced by the service, your application will be notified by receiving an exception specifying the specific quota limit you have reached.

The table below provides general guidance that can help you plan your usage of the service. This guidance is a high-level estimate and is subject to revision in the future.

 

Cache SizeTransactions Per HourBandwidth MB Per HourConcurrent Connections

128MB

400000

1400

10

256MB

800000

2800

10

512MB

1600000

5600

20

1GB

3200000

11200

40

2GB

6400000

22400

80

4GB

12800000

44800

160

Build Date: 2011-12-12

ACS FAQ

Updated: December 9, 2011

This document contains FAQ information for Windows Azure Access Control Service (ACS). If you have other questions about the Windows Azure pricing structure, you can visit the Windows Azure Platform pricing FAQ for general Windows Azure pricing information.

Section Heading

• What is ACS, and what is different in the April 2011 release from the previous January 2010 release? 
  
  
• How do I purchase ACS? 
  
  
• Is the new version of the service released on April 2011 replacing the previous January 2010 version? 
  
  
• If I decide to move from the previous version of the service to the new version, should I expect any changes to my bill? 
  
  
• Why are existing Windows Azure subscription customers not being offered a discount while Pay-As-You-Go customers enjoy the benefit of the promotion until January 1, 2012? 
  
  
• Will customers who continue to use the January 2010 version of the service be able to take advantage of the promotion until January 1, 2012? 
  
  
• What is the process of moving from the existing service to the new version of the service? 
  
  
• If I am a new user, can I still sign up to use the previous version of the service? 
  
  

What is ACS, and what is different in the April 2011 release from the previous January 2010 release?

Access Control makes it easy to add identity and access control capabilities to web applications and services through industry standard protocols. The new version of the service that was released in April 2011 adds the following capabilities:

• Integrated federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, and Facebook.
  
  
• Delegation using OAuth 2.0.
  
  
• New web-based management portal.
  
  
• Full programmatic management using OData.
  
  
• Works with Windows Identity Foundation and tooling.
  
  
• WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13).
  
  

For more information, see Differences between Access Control Service 1.0 and Access Control Service 2.0.

How do I purchase ACS?

Access Control is included in the Windows Azure subscription offers, as well as the Pay-As-You-Go offers. There is no difference in the inclusion in offers or the price between the previous and the new version of the service.

The Pay-As-You-Go Compute price is $1.99 per 100,000 transactions. However, we are running a promotion and will not charge for the usage of the service until January 1st 2012. Additionally, if you buy the subscription offers or the introductory special Pay-As-You-Go plan, you will not be charged for overage above and beyond the allotted amount that is part of your offer.

Is the new version of the service released on April 2011 replacing the previous January 2010 version?

No. The new version of the service is not completely backward compatible with the previous version, and it is running in parallel to the previous version. Existing customers will not be automatically migrated to the new version, and the previous version remains fully supported. For more information on the differences between the January 2010 release and the April 2011 release versions of the service, see the product documentation on MSDN. On MSDN, we will also provide guidance on how to migrate applications from the January 2010 version to the April 2011 version.

If I decide to move from the previous version of the service to the new version, should I expect any changes to my bill?

If you are on a subscription offer, your subscription fee will not change. However, you will not have to pay for overage beyond the allocated amount that is part of your offer until January 1, 2012. If you are on a Pay-As-You-Go plan, you will see a temporary drop in your bill due to the promotion that ends on January 1, 2012.

Why are existing Windows Azure subscription customers not being offered a discount while Pay-As-You-Go customers enjoy the benefit of the promotion until January 1, 2012?

The promotion is available to Windows Azure subscription customers and you will not be charged for overage beyond the allocated amount that is included in your offer.

Will customers who continue to use the January 2010 version of the service be able to take advantage of the promotion until January 1, 2012?

Yes, the promotion will cover both versions of the service.

What is the process of moving from the existing service to the new version of the service?

The new version of the service is not completely backward compatible with the previous version, and it is running in parallel to the previous version. Existing customers will not be automatically migrated to the new version, and the previous version remains fully supported. For more information on the differences between the January 2010 release and the April 2011 release of the service, see the product documentation onMSDN. On MSDN, we will also provide guidance on how to migrate applications from the January 2010 release to the April 2011 release.

If I am a new user, can I still sign up to use the previous version of the service?

Yes, you can.