We are making the following two disclosures at WPC 2010: the Windows Azure platform appliance and a new invoicing capability.
Questions about Windows Azure™? Look through the FAQ below.
Please select one of the following faq categories:

We are making the following two disclosures at WPC 2010: the Windows Azure platform appliance and a new invoicing capability.
The Windows Azure platform “Appliance” consists of Windows Azure, SQL Azure and a Microsoft-specified configuration of compute, network and storage resources. The Windows Azure platform appliance enables service providers and large enterprises to run and manage Windows Azure and SQL Azure in their own datacenters.
Beginning on July 12, 2010, Windows Azure platform customers will have, upon request and subject to a possible credit review that will take approximately five business days to complete, the ability to pay for their usage of the Windows Azure platform via invoice. Most Microsoft Volume Licensing customers will not require a credit review and can have this ability enabled right away. We are introducing this functionality in direct response to consistent customer and partner feedback.
The Windows Azure platform is an internet-scale cloud computing services platform hosted in Microsoft data centers. The Windows Azure platform, which provides a range of functionality to build applications that span from consumer Web to enterprise scenarios, includes a cloud services operating system and a set of developer services. Windows Azure, Microsoft SQL Azure and AppFabric are the key components of the Windows Azure platform.
Windows Azure provides developers with on-demand compute and storage to host, scale and manage Web applications on the Internet through Microsoft data centers.
Microsoft SQL Azure delivers on Microsoft’s SQL Server® Data Platform vision of extending the Data Platform capabilities in cloud as web-based services. SQL Azure enables a rich set of services for relational database, reporting, and analytics and data synchronization with mobile users, remote offices and business partners.
Microsoft SQL Azure™ Database is a cloud-based relational database service built on SQL Server technologies. It provides a highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud. SQL Azure Database enables easy provisioning and deployment of multiple databases. Developers do not have to install, setup, patch or manage any software. High Availability and fault tolerance is built-in and no physical administration is required. SQL Azure Database supports Transact-SQL. Customers can leverage existing knowledge in Transact-SQL development and a familiar relational data model for symmetry with existing on-premises databases. SQL Azure Database provides a strong value proposition through helping to save in the cost of development by working with existing toolset and providing symmetry with on-premises and cloud database.
The Service Bus and Access Control, part of the Windows Azure platform AppFabric, are web-based developer services that help make it easier for Windows Azure applications and SQL Azure databases to connect and interoperate with existing or new Windows Server assets. These services are built on Windows Azure, and provide connectivity and access control for customers with the need to integrate cloud services with on-premises systems, or to perform business-to-business collaboration.
The Service Bus enables loosely-coupled connectivity between services and applications across firewall or network boundaries, using a variety of communication patterns. The Access Control Service provides federated, claims-based access control for REST web services. Developers can use these services to build distributed or composite applications and services.
Microsoft® Codename "Dallas" is a service that allows developers and information workers to easily discover, explore and acquire premium data and web services to power next generation apps as well as information worker scenarios such as reporting, analytics, visualizations, data mining, etc. Dallas is an information marketplace that brings data, imagery, and real-time web services from leading commercial data providers and authoritative public domain sources together into a single location, under a single provisioning and billing framework. Additionally, Dallas APIs allow developers and information workers to consume this premium content with virtually any platform, application or business workflow.
The Service Bus and Access Control services that were once collectively known as the .NET Services are now rebranded as Windows Azure platform AppFabric, as of the November 5th CTP. Ever since we released the first CTP of the Windows Azure platform last year, customers have made it clear that connectivity as a service is a key requirement of their modern computing architectures, which include both cloud applications and on-premises systems, and that security in such a service is important. In response to that feedback, the Windows Azure platform AppFabric now provides connectivity via Service Bus and Access Control. Although the .NET Services brand will no longer be used to describe these services, they remain essential components of the Windows Azure platform. In fact, they are now more closely integrated into the Windows Azure cloud services platform. We hope that this branding update helps to clarify that relationship for customers.
Customers will see this branding change take effect in several places, including web sites, downloadable materials, documentation, and within the services themselves.
This branding change is effective immediately. As we transition the Windows Azure platform from a CTP to a business, customers will see this take effect in several places, including web sites, downloadable materials, documentation, and within the services themselves.
Customers and partners who adopt the Windows Azure platform derive the following benefits:
A Windows Azure platform marketplace will need to address opportunities for both finished as well as building block services. The Microsoft Pinpoint application marketplace addresses the finished services opportunity and is targeted towards Business Decision Makers. Today, applications can be profiled and listed on Pinpoint directly from the Windows Azure platform Developer portal. Included in the Pinpoint application profile is a ‘Buy’ link to direct the customer to the publisher’s site or purchasing engine. For Windows Azure building block services, we are currently exploring the creation of a Windows Azure platform developer-to-developer exchange.
You can find case studies of customers and partners such as Kelly Blue Book, Associated Press, Origin Digital and Lokad that have built solutions on the Windows Azure platform here:
The Windows Azure platform is currently available in English
As of April 2010, Windows Azure is available in the following countries: Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, India, Italy, Japan, Netherlands, New Zealand, Norway, Portugal, Singapore, Spain, Sweden, Switzerland, UK, United States, Australia, Brazil, Chile, Colombia, Costa Rica, Cyprus, Czech Republic, Greece, Hong Kong, Hungary, Israel, Luxemburg, Malaysia, Mexico, Peru, Philippines, Poland, Puerto Rico, Romania, and Trinidad and Tobago.
Customers have access to a support phone number to call at any time to report potential issues with the Windows Azure platform service. Issues with the platform will be escalated to the Windows Azure platform operations team to investigate and correct. You can also call at any time for developer support to assist you with your application. Developer support is charged on a per incident basis. Premier customers, MSDN subscribers and MPN members can leverage support incidents and support hours provided as part of these program benefits. We will also continue to provide moderated forum support at no charge. You can access more information regarding your support options at the following URL: http://www.microsoft.com/windowsazure/support/.
CTP tokens will no longer be required to access Windows Azure, SQL Azure Database or AppFabric beginning January 2010. New customers seeking access to these technologies can use their Windows Live ID to create user account, and sign up for an offer to gain access to services running on the Windows Azure platform.
No. Windows Azure is not grid computing, packaged software, or a standard hosting service. Windows Azure is an integrated development, service hosting and management environment maintained at Microsoft datacenters. This environment includes a robust and efficient core of compute and simple storage capabilities and support for a rich variety of development tools and protocols.
You should expect that over time, we will further align our investments in Microsoft Online Services to take advantage of the scale and flexibility offered by the Windows Azure platform.
The current Business Productivity Online Suite (Exchange Online, SharePoint Online, Office Communications Online, and Live Meeting) was built and released before the introduction of the Windows Azure platform. While the two share common operational elements such as datacenters, provisioning and identity infrastructure, and underlying commerce platform, the initial BPOS services were created based on the current releases of each server e.g. Exchange 2007.
We don’t have any specific dates to share but you should expect a steady transformation over time. For example, the latest Exchange Hosted Archive now makes use of SQL Azure in its underlying storage technology.
We launched a CTP of the Windows Azure platform at PDC in October 2008 to collect feedback and input from the community. One of the strongest and most consistent pieces of feedback we’ve received from the community has been around the scope of the Windows Azure platform. Customers and Partners have indicated that they would like clarity around the composition of the platform, and that it should offer operating system, database and connectivity capabilities. We’re acting on this feedback: At this time, the Windows Azure platform comprises Windows Azure, SQL Azure and AppFabric.
Live Services are an integral part of Microsoft’s Software + Services story. While Live Services are not a part of the Windows Azure platform, developers can continue to use Live Services in building rich and compelling solutions on the Windows Azure platform. The same also holds true for SharePoint Services and CRM Services. Customers and partners will continue to have the opportunity to utilize these services, plus the Windows Azure Platform, to meet their business objectives.
Microsoft has partnered with VeriSign to provide SSL Certificates for Windows Azure applications and services. VeriSign is a leading provider of SSL certs globally. Visit http://www.verisign.com/ssl/ssl-for-azure/index.html for more information.
Microsoft has partnered with VeriSign to provide Code Signing Certificates for Windows Azure applications and services. VeriSign is a leading provider of Code Signing certs globally. Visit http://www.verisign.com/code-signing/code-signing-for-azure/index.html for more information.

The Windows Azure Drive allows Windows Azure applications to mount a Page Blob, which is a single volume NTFS VHD. All writes in the application are made durable to the blob, and reads come out of the local VM cache or the page blob if there is a cache miss. This allows applications to upload/download VHDs via blobs, and the VHD is durable and survives the failover of the VM, since it is backed by a paged blob.
The new diagnostics features in Windows Azure enable customers to perform logging using standard .NET APIs. This feature also enables the collection of such logs and other diagnostic data, e.g. performance counters, for monitoring the state of their application.
The Windows Azure Service Management APIs are REST based APIs that enable customers to automate the deployment, management and scaling of their application.
The inter-role communication functionality in Windows Azure provides direct communication between individual role instances in the user’s application. This enables creation of more complex applications, e.g. applications with state.
Yes. Developers now have the ability to choose the size of VMs to run their application based on the applications resource requirements. Windows Azure compute instances come in four unique sizes to enable complex applications and workloads.
| Compute Instance Size | CPU | Memory | Instance Storage | I/O Performance |
| Small | 1.6 GHz | 1.75 GB | 225 GB | Moderate |
| Medium | 2 x 1.6 GHz | 3.5 GB | 490 GB | High |
| Large | 4 x 1.6 GHz | 7 GB | 1,000 GB | High |
| Extra large | 8 x 1.6 GHz | 14 GB | 2,040 GB | High |
Each Windows Azure compute instance represents a virtual server. Although many resources are dedicated to a particular instance, some resources associated to I/O performance, such as network bandwidth and disk subsystem, are shared among the compute instances on the same physical host. During periods when a shared resource is not fully utilized, you are able to utilize a higher share of that resource.
The different instance types will provide different minimum performance from the shared resources depending on their size. Compute instance sizes with a high I/O performance indicator as noted in the table above will have a larger allocation of the shared resources. Having a larger allocation of the shared resource will also result in more consistent I/O performance.
The certificate management feature in Windows Azure enables the automated deployment of service-specific certificates to services hosted on Windows Azure.
Yes, Microsoft will add Virtual Machine functionality to Windows Azure to expand the set of existing applications that can be run on it. This Virtual Machine deployment functionality will enable developers to run a wide range of Windows applications in Windows Azure, while taking full advantage of the built in automated service management.
We are not announcing pricing for the proposed Windows Azure VM functionality right now. However, this pricing will be consistent with our current Windows Azure pricing model.
No. However, moving applications from Windows Azure to Windows Server, or vice versa, is eased by the shared core Windows programming model.
Microsoft will ensure that Windows Azure technology is made available to them for running in their own datacenters over a period of time. This will be enabled by incorporating functionality from Windows Azure into our on-premises offerings such as Windows Server and System Center.
Microsoft will ensure that Windows Azure technology is made available to them for running in their own datacenters over a period of time. This will be enabled by incorporating functionality from Windows Azure into our on-premises offerings such as Windows Server and System Center.

Some of the new features of SQL Azure Database incorporated since PDC’09 include firewall support, bulk insert, updates to the properties, portals, Multiple Active Result Sets (MARS), Multi-Server Management support, the ability to rename a database and additional TSQL capabilities. For selected customers, we have added 50 GB database. For more details please visit Blog post.
The benefits of using SQL Azure are manifold. These include manageability, high availability, scalability, a familiar development model, and a relational data model.
Manageability: SQL Azure offers the scale and functionality of an enterprise data center without the administrative overheads that are associated with on-premise instances of SQL Server. This self-managing capability enables organizations to provision data services for applications throughout the enterprise without adding to the support burden of the central IT department or distracting technology-savvy employees from their core tasks in order to maintain a departmental database application. With SQL Azure, you can provision your data storage in minutes. This reduces the initial costs of data services by enabling you to provision only what you need. When your needs change, you can easily extend your cloud-based data storage to meet those needs.
High Availability: SQL Azure is built on proven Windows Server and SQL Server technologies, and is flexible enough to cope with any variations in usage and load. The service replicates multiple redundant copies of your data to multiple physical servers to maintain data availability and business continuity. In the case of a hardware failure, SQL Azure provides automatic failover to optimize availability for your application.
Scalability: A key advantage of SQL Azure is the ease with which you can scale your solution. After partitioning your data, the service scales as your data grows. A pay-as-you-grow pricing model makes sure that you only pay for the storage that you use, so that you can also scale down the service when you do not need it.
Familiar Development Model: When developers create on-premise applications that use SQL Server, they use client libraries that use the tabular data stream (TDS) protocol to communicate between client and server. SQL Azure provides the same TDS interface as SQL Server so that you can use the same tools and libraries to build client applications for data that is stored in SQL Azure. For more about TDS, see Network Protocols and TDS Endpoints.
Relational Data Model: SQL Azure will seem very familiar to developers and administrators because data is stored in SQL Azure just like it is stored in SQL Server, by using Transact-SQL. Conceptually similar to an on-premise instance of SQL Server, a SQL Azure server is logical group of databases that acts as an authorization boundary.
Within each SQL Azure server, you can create multiple databases that have tables, views, stored procedures, indices, and other familiar database objects. This data model makes good use of your existing relational database design and Transact-SQL programming skills, and simplifies the process of migrating existing on-premise database applications to SQL Azure. For more about Transact-SQL and its relationship to SQL Azure, see Transact-SQL Support (SQL Azure Database). SQL Azure servers and databases are virtual objects that do not correspond to physical servers and databases. By insulating you from the physical implementation, SQL Azure enables you to spend time on your database design.
The driver will enable developers to build PHP applications with relational database capabilities to both SQL Server as well as SQL Azure databases. There are some key performance improvements as well as new features such as support for UTF-8 encoding and scrollable result sets.
Although SQL Azure plays an active role in managing the physical resources of the database, the DBA plays a very important role in administering SQL Azure-based database applications. Using SQL Azure, DBAs manage schema creation, statistics management, index tuning, query optimization, and security administration (logins, users, roles, etc.). For more information about security administration in SQL Azure, see Managing Logins and Users in SQL Azure. Database administration in SQL Azure differs most from SQL Server in terms of physical administration. SQL Azure automatically replicates all data to provide high availably. SQL Azure also manages load balancing and, in case of a server failure, transparent fail-over. To provide this level of physical administration, you cannot control the physical resources of SQL Azure. For example, you cannot specify the physical hard drive or file group where a database or index will reside. Because the computer file system is not accessible and all data is automatically replicated, SQL Server backup and restore commands are not applicable to SQL Azure.
When preparing an on-premises SQL Server deployment, it may be the role of the DBA or IT department to prepare and configure the required hardware and software. When using SQL Azure, these tasks are performed by the SQL Azure provisioning process. You can begin provisioning your SQL Azure databases after you create a Windows Azure Platform account. This account allows you to access all the services, such as Windows Azure, Windows Azure platform Service Bus and Access Control and SQL Azure, and is used to set up and manage your subscriptions. Each SQL Azure subscription is bound to one SQL Azure server at the Microsoft data center. Your SQL Azure server is an abstraction that defines a grouping of databases. To enable load-balancing and high availability, databases associated with your SQL Azure server may reside on separate physical computers at the Microsoft data center. For more information about provisioning, see SQL Azure Provisioning Model.
Many SQL Server Transact-SQL statements have parameters that allow you to specify file groups or physical file paths. These types of parameters are not supported in SQL Azure because they have dependencies on the physical configuration. In such cases, the command is considered partially supported. For more information about Transact-SQL support, see Support (SQL Azure Database).
SQL Azure does not support all of the features and data types found in SQL Server. Analysis Services, Replication, Reporting Services, and Service Broker are not currently provided as services on the Windows Azure Platform. Because SQL Azure performs the physical administration, any statements and options that attempt to directly manipulate physical resources will be blocked, such as Resource Governor, file group references, and some physical server DDL statements. It is also not possible to set server options and SQL trace flags or use the SQL Server Profiler or the Database Tuning Advisor utilities. SQL Azure supports many SQL Server 2008 data types; it does not support data types that have been deprecated from SQL Server 2008. For more information about data type support in SQL Azure, see Data Types (SQL Azure Database). For more information about SQL Server 2008 deprecated types, see Deprecated Database Engine Features in SQL Server 2008.
Using the Visual Studio tooling provided for SQL Azure Data Sync you can create applications that cache data locally in SQL Server Compact. Cached mode applications provide the benefits of lower latency and higher availability for client applications as well as lower network utilization and the better ability to schedule work on servers. These aspects can become particularly important when working with applications on the internet.
The Sync Framework team is currently investigating what the final packaging for this functionality will be and is targeting releasing it in CY 2010.
The management too provided for SQL Azure Data Sync will walk you through the steps of selecting the database and tables you wish to synchronize and then create a SQL Agent task to automatically synchronize the data with SQL Azure based on a periodic schedule. This can be useful in scenarios where for instance you want to create a Web App in Windows Azure and connect that Web App to on premises data sources for reporting or other purposes.
Microsoft SQL Azure Data Sync is tooling and runtime to enable data synchronization with SQL Azure. This technology facilitates two key scenarios that are not available with other cloud platforms today, extending current on-premises infrastructure to the cloud, and producing clients with offline/cached-mode support. Extending on-premises data to the cloud allows for information to be easily shared with mobile users, business partners, remote offices and enterprise data sources all while taking advantage of new services in the cloud. This technology provides a bridge, allowing on-premises and off-premises applications to work together. Using cached mode enables developing clients with an improved user experience through lower latency and higher availability. Additionally cached mode provides the benefits of lower network utilization and better server scale through lower load and a better ability to schedule work.
SQL Azure Data Sync is available as a CTP in a download called Microsoft Sync Framework Power Pack for SQL Azure. For more information about SQL Azure Data Sync in general, please visit http://www.microsoft.com/windowsazure/sqlazure/datasync. The power pack CTP is not included in the SQL Azure CTP and needs to be downloaded separately.
The Sync Framework Power Pack for SQL Azure Database contains three key components: a Sync Framework Provider that is tuned for SQL Azure Database; a management tool that can be used to synchronize on-premises SQL Server to SQL Azure databases automatically; and an add-in for Visual Studio that helps to enable cached mode scenarios with SQL Azure.
With the move to a T-SQL based relational data model, SQL Azure Database will not support the SOAP and REST based Authority-Container-Entity (ACE) programming model. Based on extensive feedback from our early adopter customers and partners, most customers will greatly benefit from the relational capabilities in SQL Azure and will continue to develop their applications against this. Customers who wish to expose REST access to their SQL Azure data can easily do so by building custom services with ADO.NET Data Services. On the other hand, customers who wish to use a REST based programming model and whose needs are met with non-relational simple structured data storage have the option of using Windows® Azure storage.
SQL Azure Database will target the following audiences:
SQL Azure Database will target the following scenarios:
In its initial release, SQL Azure Database will support relational capabilities suitable for relational apps, including multi-tenant apps requiring large levels of scale. Future releases of SQL Azure will support advanced features like distributed queries across partitions and auto-partition.
SQL Azure Database will continue to be built on the proven SQL Server technology foundation and architecture, which offers reliability, availability and enterprise-level security features. By harnessing these capabilities SQL Azure Database offers a business-ready service level agreement that is designed to provide built-in automatic high-availability and fault tolerance for unlikely event of a failure.
Previously, SQL Azure Database supported a flexible, Entity based data model. After getting valuable customer feedback it was apparent that there was a need for a fully relational data model in the cloud. SQL Azure represents the move from the ACE programming model to a relational data model with many familiar SQL Server-like programming concepts. Developers will be able to utilize existing Transact-SQL code to access their data in the cloud. They will also create and modify applications that utilize existing Transact-SQL code to interact with the fully relational cloud database service. In addition, they can expose REST and SOAP services on top of their data easily using existing data access frameworks, such as ADO.NET Data Services.
SQL Azure Database is built on SQL Server database technologies, used for running mission-critical applications in the enterprise as well as on the Web. Since SQL Server is a broad data platform that can handle all data from birth to archival, there are many capabilities that our data platform provides. SQL Azure Database is exposing a large subset of those relational capabilities and extending them as services in the cloud in ways that make it easy for customers and partners to consume and build upon over the Internet. In addition to this, SQL Azure Database provides built-in high scale, availability, utility, and other such capabilities. Although SQL Azure Database in its first iteration exposes only the core RDBMS capabilities of what is in the full SQL Server data platform, Microsoft expects this to increase over time, with likely future features including Reporting, Analytics, ETL and other premium services etc.
Unlike administration for an on-premise instance of SQL Server, SQL Azure abstracts the logical administration from the physical administration; you continue to administer databases, logins, users, and roles, but Microsoft administers the physical hardware such as hard drives, servers, and storage. This approach helps SQL Azure provide a large-scale multi-tenant database service that offers enterprise-class availability, scalability, security, and self-healing. Because Microsoft handles all of the physical administration, there are some differences between SQL Azure and an on-premise instance of SQL Server in terms of administration, provisioning, Transact-SQL support, programming model, and features. For more information see the Similarities and Differences - SQL Azure vs. SQL Server whitepaper.
SQL Azure Database provides highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud. SQL Azure Database is self-managing and enables easy provisioning and deployment of multiple databases. Developers do not have to install, setup, patch or manage any software. High Availability and fault tolerance is built-in and no physical administration of hardware, storage or servers is required. SQL Azure Database supports Transact-SQL (T-SQL). Customers can leverage existing knowledge in T-SQL development and a familiar relational data model for symmetry with existing on-premises databases. SQL Azure Database provides a strong value proposition through savings in the cost of development by working with existing toolset and providing symmetry with on-premises and cloud database With hosted database, developers are still responsible for installing, setting up, updating and patching OS & managing database software. Additionally, hosted database solutions have to device high availability and fault tolerance. Manage multiple scale-out databases.
In the short term, we are working to enable SQL Azure as a data source for your BI solutions which would include Analysis Services and Reporting Services. When deployed with SQL Server 2008 R2, you can, however, access SQL Azure from within your locally running Reporting Services and Analysis Services projects.
Currently you can use the Microsoft Sync Framework Power Pack for SQL Azure CTP to enable these scenarios.
SQL Azure customers can provision unlimited number of databases based on their application needs. Data can be partitioned across multiple databases without any size limitation.
SQL Azure Database service will offer a scalable distributed relational database service in the Cloud that is used for storing, processing and analyzing structured, semi-structured & unstructured data. Windows Azure Table storage is a non-relational, scalable, simple structured storage (ISAM style) in the cloud. Since SQL Azure Database will offer database service for applications developed on Windows Azure, customers can pool these services based on the needs.
With the TSQL based relational data model support in SQL Azure over TDS protocol, customers can utilize existing tools such as Microsoft Visual Studio® and SQL Server Management Studio so they can work with both on-premises SQL Server and cloud-based SQL Azure Database deployments. This will enable customers to build applications that use combinations of databases on and off premises.
Business partners will continue to build multi-tenant packaged or custom LOB applications and use SQL Azure Database with the similar knowledge and tools as they do with on-premises SQL Server. Partners can also extend their existing LOB applications to use SQL Azure with minimal friction. ISVs and partners can also develop and offer new consumer Saas applications powered by SQL Azure and Windows Azure multi-tenant capabilities.
Yes. SQL Azure Database provides a cloud-based relational database service for Windows Azure Developers who write Windows Azure applications will be able to access SQL Azure based on their database needs.
Developers will be able to use Visual Studio to create new applications or modify existing applications for SQL Azure. Developers can also use existing ASP.NET controls, designers, and tools to develop applications. In the future, developers will also use web based Management tools, , to access and manage their cloud-based data. In the future, SQL Azure will also provide tools and documentation to support additional programming languages.
SQL Azure database is charged based on the number of databases created and consumed by the application per day and billed monthly.
No. Currently you can’t bring your existing on-premises Windows Server, SQL Server to Windows Azure, SQL Azure.
Windows Azure and SQL Azure SLAs are independent of our on-premises Microsoft licensing agreements. Our SLAs for the Windows Azure platform provide you a monthly uptime guarantee for those services you consume in the cloud, with SLA credits against what we have billed you in the event we fail to meet the guarantee.

With AppFabric, Microsoft is delivering services that enable developers to build and manage composite applications more easily for both server and cloud environments. Windows Azure platform AppFabric, formerly called “.NET Services”, provides cloud-based services that help developers connect applications and services across Windows Azure, Windows Server and a number of other platforms. Today, it includes Service Bus and Access Control capabilities. Windows Server AppFabric includes caching capabilities and workflow and service management capabilities for applications that run on-premises.
Windows Azure platform AppFabric is built on Windows Azure, and provides secure connectivity and access control for customers with the need to integrate cloud services with on-premises systems, to perform business-to-business integration or to connect to remote devices.
The Service Bus enables secure connectivity between services and applications across firewall or network boundaries, using a variety of communication patterns. The Access Control Service provides federated, claims-based access control for REST web services. Developers can use these services to build distributed or composite applications and services.
Ever since we released the first CTP of the Windows Azure platform last year, customers have made it clear that connectivity as a service is a key requirement of their modern computing architectures, which include a mixture of cloud applications and on-premises systems. In response to that feedback, Windows Azure platform AppFabric now provides secure connectivity natively via Service Bus and Access Control, in much the same way that it also provides Compute and Storage as cloud services.
From simple eventing scenarios to service remoting and complex protocol tunneling, the Service Bus gives developers the flexibility to connect applications and to choose how they communicate. This helps them build distributed and composite applications while also helping address the challenges presented by firewalls, NATs, dynamic IP, and disparate domains and identity systems. Access Control enables developers to externalize authorization decisions in a federated, claims-based manner, which helps them develop simple, easier-to-manage access control logic for REST web services and Service Bus communications. All of that means developers can be more efficient when they extend existing software to the cloud, more agile when they collaborate with business partners, and more focused when they need to reach new customers.
Because they are built on Windows Azure, Service Bus and Access Control work in concert with your cloud applications and data, scaling with them as your business grows. What’s more, Service Bus and Access Control naturally bring the benefits of the Windows Azure platform, such as dynamic scaling, automated service management, pay-as-you-go pricing, and SLA-backed reliability – all hosted in Microsoft datacenters so you can focus on developing your business logic and spend less time building and managing infrastructure.
Service Bus makes it easy to connect applications together over the Internet. Services that register on the Service Bus can easily be discovered and accessed, across any network topology. The Service Bus provides the familiar Enterprise Service Bus application pattern, while helping to solve some of the hard issues that arise when implementing this pattern across network, security, and organizational boundaries, at Internet-scale.
Access Control provides an easy way to control access to REST web services and Service Bus communications while integrating with standards-based identity providers, including enterprise directories and web identity systems such as Windows Live ID. Authorization decisions can be pulled out of the application and put into a set of declarative rules hosted in Windows Azure that can transform incoming security claims into developer-defined claims that web services can consume directly.
The AppFabric LABS environment is a new environment which the team will use to showcase some early bits, showcase new features and get feedback from the community. AppFabric LABS is a way for customers to test out and play with experimental AppFabric technologies. These are upcoming capabilities that excite us very much and we want to get your feedback on them as soon as possible. As a result, there is no support or SLA associated with the LABS environment, but in return you will be able to preview the future of AppFabric while helping us shape it. Though similar to a Community Technology Preview, LABS technologies may occasionally be even farther away from commercial availability.
AppFabric LABS have been launched in early March, in the MIX’10 timeframe, and are available now for developers to access, test out the features, and provide feedback.
To get started:
In this release of the LABS environment, we’re shipping two features:
To provide feedback, customers can visit the Windows Azure platform AppFabric forum and connect with the AppFabric team.
The commercial Windows Azure platform AppFabric service and the AppFabric LABS are two entirely separate services, with separate development environments. Even if a user has accounts in both, they are not connected and cannot be used together.
There are no SLAs for the AppFabric LABS environment. While we will try to support customers using this environment as best we can, support for the commercial environment will take strong precedence.
Since this is an early preview environment without specific SLAs, usage for this environment will not be billed.
Yes, customers will not be charged for any usage on the AppFabric LABS environment.
At this time, we do not have specific timelines.
The LABS features are exploratory ideas, which may or may not make it to the commercial product. A CTP on the other hand, is a preview of future versions of the feature or product.
Ever since we released the first CTP of the Windows Azure platform last year, customers have made it clear that connectivity as a service is a key requirement of their modern computing architectures, which include a mixture of cloud applications and on-premises systems. In response to that feedback, Windows Azure platform AppFabric provides secure connectivity via Service Bus and Access Control.
From simple eventing scenarios to service remoting and complex protocol tunneling, the Service Bus gives developers the flexibility to connect applications and to choose how they communicate. This helps them build distributed and composite applications while also helping address the challenges presented by firewalls, NATs, dynamic IP, and disparate domains and identity systems. Access Control enables developers to externalize authorization decisions in a federated, claims-based manner, which helps them develop simple, easier-to-manage access control logic for REST web services and Service Bus communications. All of that means developers can be more efficient when they extend existing software to the cloud, more agile when they collaborate with business partners, and more focused when they need to reach new customers.
Because they are built on Windows Azure, the AppFabric services (Service Bus and Access Control) work in concert with your cloud applications and data, scaling with them as your business grows. What’s more, AppFabric naturally brings the benefits of the Windows Azure platform, such as dynamic scaling, automated service management, pay-as-you-go pricing, and SLA-backed reliability – all hosted in Microsoft datacenters so you can focus on developing your business logic and spend less time building and managing infrastructure.
The March 2010 release of AppFabric includes a Billing Preview which provides usage information to customers in order for them to familiarize themselves with their AppFabric usage prior to actual billing starting in April 2010.
The November 2009 release focused on making some key design changes to Service Bus (SB) and Access Control (AC), and introduced the commercial feature set. Notably, Service Bus and Access Control now run on Windows Azure. Updates and changes for the November CTP are:
Based on the fact that REST web services have become increasingly popular with both web and enterprise developers, we received feedback from the community that the lack of controlling access to REST web services is one of the major pain points faced by service developers today. As interoperability remains a goal of ours, this means that we will simplify the approach to ACS so that access control scenarios integrate well with REST. The approach is also designed to continue to appeal to all developers that want an easy way to take advantage of Service Bus and Access Control or use these services from non-Microsoft platforms. Meanwhile, we remain committed to our ongoing goals of enabling SSO and authorization for websites, supporting WS-*, and federating with a greater variety of web and enterprise identity providers, in a future release.
To capitalize on the opportunities presented by cloud computing, customers need the flexibility to run their applications and services on a variety of hardware and software platforms, across a myriad of deployment scenarios. Service Bus and Access Control simplify how businesses connect loosely-coupled on-premises and cloud-based applications, and integrate between businesses.
The November 2009 CTP release contains some reductions in functionality relative to the July 2009 CTP release. These reductions primarily concern Routers and Queues, which the Service Bus team is in the process of improving to facilitate expanded functionality in coming releases.
We have made the decision to remove Routers temporarily, beginning with the November 2009 CTP. While we know that some customers will be negatively impacted, we have determined that the current Router implementation will require some re-work to lay a strong foundation for planned expansions to the feature set. Removing Routers temporarily will allow us to accelerate the re-work and reinstatement of robust Router functionality.
We believe that Routers are a critical feature of the Service Bus for enabling a variety of messaging architectures. Thus, while we are cutting Routers from the November 2009 CTP, we are committed to performing the required rework and expect to reinstate Router functionality in a future release.
For customers who have built applications that rely on Router functionality, we have provided a sample to demonstrate a method for implementing Router-like functionality—including multicast, anycast and push-style message operations—using existing Service Bus features. This sample is part of the November 2009 SDK for Service Bus and Access Control.
In the November 2009 CTP release, Queues will be temporarily replaced with a simpler offering called Message Buffers. The motivation for this change is our desire to lay the groundwork for buffer durability, message delivery guarantees and other enhanced message delivery semantics.
Differences from the existing Queue implementation are summarized below.In all other respects, Message Buffers will behave much like the July 2009 CTP implementation of Queues.
The WSHttpRelay Binding will no longer be available beginning in the November 2009 CTP release. Customers who were using the WSHttpRelay Binding are advised to consider migrating to the WS2007Relay Binding, which provides support for the updated versions of the Security, ReliableSession, and TransactionFlow binding elements.
Beginning with the November 2009 CTP release, it will no longer be possible to register external (non-Service Bus) endpoints in the Service Registry. We expect to re-instate this functionality in a future release.
Service Bus has transitioned to commercial availability since January 2010. Microsoft will start charging for these services in April 2010. While we do not expect that Routers and Queues will be fully reinstated by that time, work on these features is ongoing and will be a high priority for the team. We are confident that our next iteration of Queues and Routers will offer enhanced functionality and much improved reliability and performance in comparison to the earlier CTP implementation. Thank you for your continued interest and support!
With the November 2009 CTP release, we are focusing on addressing the large, unmet need around access control for REST web services. This means that the WS-Trust features that we support in previous CTP releases will be temporarily unavailable while we focus on delivering a robust infrastructure for REST web services authorization. Once the infrastructure is in place, ACS features, such as web single sign on and rich enterprise WS*- support that span REST/SOAP spectrum will be available in a future release.
No. Microsoft has made significant, long-term investments in security and identity management using the WS-* protocols: WS-Trust, WS-Federation, WS-Security and others. The WS-* protocols are proven and widely adopted by enterprises, and will continue to be a central focus for ACS and other Microsoft groups working on enterprise security and identity management.
We do not have a specific timeline to announce at this point in time. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the Access Control offering in a way that spans the REST/SOAP spectrum.
As REST web services have become increasingly popular with both web and enterprise developers, a gap has emerged in the market place for identity and access control technology. Today, developers of REST web services lack an easy, accessible means to secure their services. They face a lack of consistency and common patterns for managing identity and access control in a way that is compatible with the REST focus on simplicity. As REST developers move towards the enterprise, they will have an increasing need for robust security. They will be required to address the more systematic security concerns of enterprise customers as well as the more complex identity management scenarios that enterprises present. They will need a way to address these requirements that is simple and that integrates well with REST.
Taking this problem as an opportunity to differentiate the Access Control offering and serve an even broader range of developers, we have experimented over the past several months with a simplified approach to the way that Access Control packages and transits security tokens. Although this simplified approach has been designed to meet the needs of REST web service developers, it will appeal to all developers that want an easy way to take advantage of our services or that wish to use Service Bus and Access Control from non-Microsoft platforms.
At MIX09 we exposed some of our thinking about this new approach as a way to gauge customer interest. In addition to talking about our goals for simplicity and broad interoperability, we demonstrated the ability to control access to SaaS web sites using a variety of different consumer identities. Consistent with our theme, we showed that this approach can radically simplify the REST developer experience. Response to the MIX09 presentations was overwhelmingly positive and confirmed our sense that we were on the right track.
From this and other feedback, we have come to the conclusion that the lack of tools for controlling access to REST web services is one of the major pain points faced by service developers today. We believe that Access Control is well-positioned to address this need in a way that complements other MSFT offerings in the security and identity management space. The combination of simplicity and support for key enterprise integration scenarios will ensure that Access Control appeals to our enterprise customers, while simultaneously meeting the needs of an even broader developer audience. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the Access Control offering in a way that spans the REST/SOAP spectrum.
Following is a summary of the current Access Control roadmap: PDC 2009: Authorization for REST Web Services and the Service Bus
To align with the updated roadmap and make it possible to efficiently support and extend our release post v1, we have invested in extending the foundations of the Access Control platform. As a consequence, we have had to constrain the features that are in scope for commercial release and carefully identify the scenarios that we are targeting.
Access Control, WIF, and AD FS v2 can be used together to develop web services that combine the security and capability of Active Directory with the flexibility and control of custom access control rules, within a simple, closely integrated developer experience.
Access Control allows developers to manage access to RESTful web services using a cloud-based service. Active Directory Federation Services 2.0 can federate with ACS, so users in Active Directory can be granted access to these RESTful web services.
At PDC 2009, there will be community samples that demonstrate how to use WIF and Geneva Server with ACS. WIF will be used to acquire a SAML token from Geneva Server and to extract the claims from an Access Control-issued token. Note that extracting claims from an Access Control-issued token will require custom extensions to WIF. The WIF and ADFS teams are currently investigating native support for this type of token in the future versions of both WIF and ADFS. At PDC 2009, there will also be a community sample that demonstrates how to use WLID with Access Control.
It is too early to speculate on when Microsoft will build the Workflow Service back. After .NET Framework 4 ships, we will solicit customer feedback to determine the most appropriate way to provide Workflow Service for the cloud.
After .NET Framework 4 ships, we will solicit customer feedback to determine the most effective way to leverage the features of Service Bus and Access Control for customers.
We are not publically disclosing Service Bus and Access Control adoption statistics at this time. However we encourage developers to try out the download at: http://www.microsoft.com/windowsazure/developers/appfabric
ACS, WIF, and AD FS v2 can be used together to develop web services that combine the security and capability of Active Directory with the flexibility and control of custom access control rules, within a simple, closely integrated developer experience.
Access Control allows developers to manage access to RESTful web services using a cloud-based service. Active Directory Federation Services 2.0 can federate with ACS, so users in Active Directory can be granted access to these RESTful web services.

Windows Azure platform appliance consists of Windows Azure, SQL Azure and a Microsoft-specified configuration of network, storage and server hardware. It is a turnkey cloud platform you can deploy in your datacenter. Service providers, governments and large enterprises who would, for example, invest in a 1000 servers at a time, will be able to deploy the Windows Azure platform on their own hardware in their datacenter. Microsoft Windows Azure platform appliance is optimized for scale out applications – such as eBay– and datacenter efficiency across hundreds to thousands to tens-of-thousands servers .
The main benefit of the appliance is that it provides the benefits of the Windows Azure platform with greater physical control, geographic proximity, regulatory compliance and data sovereignty.
The appliance will run only on network, storage and server hardware that meets the Windows Azure platform reference specifications. Microsoft has invested significant engineering resources to ensure that the hardware required by the appliance is optimized to enable service availability, automated management and power, cooling and operational efficiency across tens of thousands of servers. This hardware is based on industry-standard x64 hardware in order for customers to be able to purchase the appliance from a choice of partners.
Today we announced the Limited Production Release of the Windows Azure platform appliance to a small set of customers and partners. We will develop our roadmap depending on what we learn from this set of customers and partners. We have no additional details at this time.
Microsoft offers the Windows Azure platform as a fully managed service in Microsoft’s datacenter. Microsoft manages the entire platform including hardware and day-to-day operations. The appliance allows customers and partners to deploy the Windows Azure platform in their own datacenter which some customers and partners have requested because of their need to for physical control, data sovereignty and regulatory compliance as well as geographic proximity. Microsoft will, however, continue to provide updates to the Windows Azure platform service running on the appliance, just as we currently manage updates to more than 750 million individual PCs worldwide running Windows update.
The Microsoft Windows Azure platform appliance allows customers and partners to deploy Windows Azure and SQL Azure in their own datacenters.. The appliance is a turnkey cloud platform that runs on hundreds to thousands of servers optimized to deliver hosting services and massive scale-out applications, PaaS, SaaS, IaaS or high performance computing. Windows Server, Hyper-V and System Center is a versatile, customizable server platform that allows customers and partners to build and run a dynamic, virtualized infrastructure and private clouds.
You can think of it as an appliance because it is a turn-key cloud solution on highly standardized, preconfigured hardware. Think of it as hundreds of servers in pre-configured racks of networking, storage, and server hardware. We intentionally are using the term appliance to convey that the Microsoft Windows Azure platform appliance consists of highly-specified networking, storage, and server hardware that is pre-configured. The Windows Azure platform appliance is similar to typical server appliances in that it is designed to be easy-to-use, the hardware will be locked down, and the platform software is typically updated by the vendor.
We are still evaluating timeline, partner and customer requirements. Please return to this site for further updates.

Microsoft codename ‘Dallas’ is a community technology preview (CTP) of a Windows Azure and SQL Azure-powered Information service that provides developers and information workers access to third party premium data sets and web services. ‘Dallas’ also enables self-service business intelligence and analytics over stored data sets using existing Microsoft technologies.
With the power and scale of the Windows Azure platform (Windows Azure, SQL Azure Database), Dallas provides developers with the ability to build and manage innovative applications across the desktop and mobile devices by bringing together disparate sets of private and public data, both on premises and in the cloud. Via a single marketplace, Dallas enables developers to access complex data sets to build entirely new analytic and reporting scenarios. And content providers are able to expose their data to millions of developers on a global level enabling new growth and revenue opportunities. And with support for OData, Dallas makes it easy to support rich query capabilities to power mash-ups and associations.
Dallas brings data and imagery together from leading commercial data providers and authoritative public data sources together into a single location, under a unified provisioning and billing framework. Additionally, Dallas APIs allow developers and information workers to consume this premium content with any platform, application or business workflow. In addition, Dallas allows Office Excel and SQL Server customers to instantly ‘mash up’ private data with Dallas content to enable new scenarios around analytics and reporting.
Dallas uses secure REST based APIs to deliver information to any client. It uses Windows Azure platform components such as Windows Azure compute, storage, tables, SQL Azure Database, and App Fabric to handle all aspects of an information marketplace.
Microsoft codename ‘Dallas’ is an information and brokerage service that utilizes Windows Azure and SQL Azure Database platform services. The entire service and user experience leverages Windows Azure compute for maximum scale. Blob data such as imagery and videos are stored in Windows Azure blob storage. All relational content is stored in SQL Azure Database. The Windows Azure platform AppFabric ACS allows federated identity scenarios for Dallas.
At the PDC ’09, ‘Dallas’ was available as free CTP by invitation only. At MIX, invitation codes will be removed and any customer will be able to access the Dallas public CTP for free. We will not begin charging until the service is commercially available in CY 2010. Please stay tuned for more details on Dallas pricing model but here are guidelines: Content providers set pricing and terms. Microsoft provides the brokerage. The goal for Microsoft is the larger platform play – indirect monetization is the key. There will be a percentage markup to cover the cost of bandwidth, compute, and billing expenses but this is not the primary driver of the business.
With the power and scale of the Windows Azure platform, via a differentiated killer marketplace for data that will be unveiled at the project’s launch, Dallas provides content providers with the ability to reach new markets, data provisioning, a flexible billing model, increased storage, and compute power with their data running on Dallas.
In addition, partners get not only developer productivity through automatically generated APIs and client side libraries, but also the ability to expose this content easily within Microsoft Office and SQL Server assets. Best of all – content providers get reports on data usage, sales, as well as the ability to set pricing, terms, and constraints for per-transaction and subscription offers.
Dallas provides developers and information workers access to third party data, web services, and self-service business intelligence and analytics which they can access either on the desktop or mobile device(s). Dallas allows clean, consistent APIs to all datasets and simple, easy to understand payloads in ATOM & RAW formats with support for OData. In addition, developers get proxy classes to use these services, removing the tedious job of dealing with XML code
Dallas allows content providers to offer their products through Microsoft’s marketplace, opening a frictionless distribution channel on a global scale. Additionally, Dallas allows content providers to explore new growth opportunities by targeting their high-value data sets to target consumers and developers.
‘Dallas’ provides developers with the ability to create entirely new scenarios by building applications with private and public disparate data sets from any platform, (Microsoft or 3rd party such as iPhone or Google App Engine) which can be consumed across the web, desktop, and mobile devices. ‘Dallas’ provides developers with:
Through new BI and reporting tools, information workers will be able to discover and consume reference data in entirely new ways inside Excel and SQL Server. Dallas will provide information workers with a simple, predictable business model for acquiring Reporting and BI content, in the future, the ability to consume data from SQL Server, SQL Azure Database, and other Microsoft Office assets.
Dallas leverages content providers data in an entirely new way which creates new revenue opportunities by providing a new channel to reach Microsoft’s global developer community to build new applications with disparate data sets. Dallas provides content providers with:
As content providers in the following verticals/ focus areas: premium news, locations, financial, real estate and demographic data continue to make their data available in the ‘Dallas’ service, developers have the opportunity to access, share, and build compelling applications, which utilize 3rd party data. As well as extract 3rd party data in ‘Dallas’ via the OData web protocol to run applications cross platform creating new growth and revenue opportunities.
Content providers have the ability to control use rights and the data is secured by Microsoft via the Windows Azure platform; access is also SSL secured.
Dallas enables the consumption of data via deep integration in Microsoft’s Information Worker software. Today, via plug-ins developers can port their data to Microsoft PowerPivot for Excel 2010 and Microsoft Excel with just one click. In the future, we will support similar functionality for SQL Server and SQL Azure Database and other Microsoft products
Dallas uses the Pinpoint marketplace to enable discovery of the content catalog and has a landing page on Pinpoint.
Yes. We will share additional details Dallas SLAs at a later date.
Developers can discover and consume disparate sets of data via a single marketplace to build applications for the Windows Azure platform that can scale in a way that other cloud platforms today cannot, allowing them to reach millions of information workers on a global scale. Dallas also enables content providers to reach millions of developers on a global scale with their data and web services in a virtually frictionless experience. This means new growth and revenue opportunities for content providers that do not exist today.
The data can be stored in the Windows Azure platform as well as 3rd party platforms and is accessed via secure REST based web services. Through the Dallas APIs, developers experience the same clean interface no matter where their data is stored, whether that be over Windows Azure Blob Store, Windows Azure Tables, SQL Azure Database, or 3rd party web services. Content providers have full control of whether or not the data they supply to Dallas can be consumed for private or public use. Content providers grant end consumer use rights on their data to ensure they are in control of how their data is consumed.
Today, Dallas includes data from content providers including the Associated Press, ESRI, Citysearch, NAVTEQ, National Geographic, UNdata (United Nations), Weather Central, First American, RiskMetrics Group, WaveMarket, NASA, DATA.GOV, infoUSA and more.
Take a company that wants to open store locations in new global markets that they are not familiar with. They can use Dallas to access demographic and crime data to gain insight into where higher crimes are happening in order to identify the best location. They can then use this data to identify new store locations as well as demographic data to create effective marketing campaigns providing an opportunity to increase sales. Or another example, if a company is trying to determine why their sales of winter clothes are up in specific region or market in a given month, they can use weather data in Dallas to figure out that the weather was unusually cold in that region accounting for the spike of winter clothes sales. This also helps plan for inventory needs in specific regions.
Dallas is a unique service that brings together premium, private data on premise with data in the cloud which allows developers to access and consume commercial content and data via secure REST APIs across the desktop, mobile, and web. Microsoft differentiates itself from Amazon, Google or any other competitor in a fundamental way by providing customers the flexibility to use on-premises technology, cloud technology or both, as part of Microsoft’s software-plus-services (S+S) strategy. Dallas is an example of how Microsoft can deliver the most comprehensive set of services, spanning from consumer to business and offering developers the most inclusive onramp to the cloud.
Dallas connects data stored on-premise with data stored in the cloud to enable not just new application development scenarios but also BI, reporting, trending, etc on interesting data, either local or remote.
The data that is available in Dallas today can be consumed on any platform such as Windows Azure, Apple’s iPhone and Google’s App Engine platform. For example, developers can write an iPhone app or Google App Engine app that uses data stored in and connects to Dallas. However, other platform providers cannot purchase Dallas as a service to run on their platform at this time.
Dallas will be commercially available in CY 2010. Microsoft will announce specific details around commercial availability and business model at a later date.
Potential partners can fill this out to start.

As part of Microsoft’s continued commitment to interoperability, the Windows Azure has been built from the ground up with interoperability in mind. As an open platform, Windows Azure offers choices to developers. It allows them to use multiples languages (.NET, PHP, Ruby, Python or Java) and development tools (Visual Studio or Eclipse) to build applications which run on Windows Azure and/or consume Windows Azure from any other cloud or on premise platform. With its standards-based and interoperable approach, Windows Azure supports multiple Internet protocols, including HTTP, REST, SOAP, and XML which are key pillars to enable data portability.
At PDC, we are announcing the release of four solution accelerators built by our partners. These four solution accelerators relate to MySQL, memcached, Tomcat and Instance Management. The solution accelerators were all built by Infosys. These solution accelerators enable developers to build solutions using MySQL, memcached and Tomcat on Windows Azure while taking advantage of the Windows Azure automated service management capabilities. The Instance Manager solution accelerator gives developers console access to role instances hosted in Windows Azure.
The Microsoft Windows platform supports a host of Microsoft and non-Microsoft languages, protocols and technologies. Our vision is to apply that same principle to Windows Azure. The Windows Azure platform supports popular standards and protocols including SOAP, REST, and XML. Developers can use their preferred programming frameworks including .NET, and PHP, now. The recent inclusion of Windows Azure support in the Zend framework is a case in point. We have partnered with Soyatec to create Eclipse tooling for PHP developers building Windows Azure applications. We have also enabled external endpoints (inbound traffic) to worker roles, which enables applications that receive internet traffic that aren’t running under IIS
In March 2009, we enabled .NET full trust and native code applications. This functionality allowed developers to spawn xcopy deployable processes. As a result, you can package and run Java applications. At PDC 09, we are delivering a solution accelerator for Tomcat. Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. The Windows Azure solution accelerator leverages a PDC09 feature that enable arbitrary processes to bind to inbound service endpoints. Also at PDC09, we are launching a Java SDK for Windows Azure Storage (tables, blogs, and queues). We’ve also enabled external endpoints (inbound traffic) to worker roles, which enables applications that receive internet traffic that aren’t running under IIS.
Microsoft has partnered with Soyatec on the creation of Windows Azure tools for Eclipse: A feature-rich open source PHP application development environment in Eclipse. The Windows Azure tools for Eclipse extension builds upon the PHP Development Toolkit (PDT) and integrates Web Tools Platform (WTP) to provide a complete toolkit for Windows Azure web application development.

How to Buy: There are two basic offers to choose from when purchasing a Windows Azure platform subscription. The first is the consumption offer. This offer require no commitment, and you pay monthly only for what you use. The second is a subscription offer that gives you a discounted price level of the service(s) in return for a six-month commitment to pay a monthly base fee. Any excess use of this subscription amount is charged at our normal consumption rates). Below is a summary description of our different plans:
Consumpton
Subscription
For all of our offers except the MSDN Premium offer, we provide members of the Microsoft Partner Network an additional 5% discount on all charges except storage and data transfers.
The Introductory Special comes with a limited amount per month of compute hours, storage, data transfers, a SQL Azure database (for the initial 3 months only), AppFabric Service Bus connections and Access Control transactions at no charge. This small amount of service each month at no charge is sufficient to try out your application for a short duration but is not adequate to run an application 24 x 7. For example, this offer comes with 25 compute hours each month. This does allow you to deploy a small application and see how it runs in the cloud but is not sufficient to allow for extensive testing or for running your application for any extended period of time. If you do not want to be charged, be sure to monitor your usage carefully and to delete your deployments after trying out your application. Please visit our offers page for full details on what is included in this offer and for details on our other offers.
The maximum level of usage that you may consume each month is either twice your base commitment (i.e., if you purchase a commitment offer) or the standard quotas outlined below, as calculated on an item by item basis with usage aggregated across all of your subscriptions.
Windows Azure
SQL Azure
AppFabric
Data Transfers (exclusive of CDN)
To illustrate how to calculate your quota if you purchase a commitment offer, let’s assume you purchase 20 base units of a commitment offer. Since each base unit includes 750 compute hours which roughly approximates one small compute instance, your quota would be 40 concurrent small compute instances.
You may request an increase in the default quotas at any time by contacting customer support. While we 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 prior to disabling an account. Customers are still responsible for charges on usage that exceed their quotas.
*Customers purchasing Service Bus connections through Reserved Packs will have quotas equal to the midpoint between the Pack they purchased and the next highest Pack amount. Customers choosing a 500 Pack will have a quota of 750.
If you are a participant in one of the Windows Azure platform CTPs, you have the option of migrating your CTP application(s) and corresponding data to a production subscription of the Windows Azure platform. To migrate your CTP account(s), you merely need to purchase an offer using the same Windows Live ID as that associated to your CTP account(s). Your CTP account(s) are automatically associated with the first offer you purchase with that Windows Live ID.
Your usage from your CTP account(s) will start being billed based on the terms of the offer you purchase as of your purchase date. If you do not want to upgrade your CTP account(s) to a paid subscription, either utilize a different Windows Live ID than your CTP account(s) when ordering or remove all of your applications and data associated with your CTP account(s) prior to sign up.
| Region | Time Zone | UTC |
| North America | Pacific Standard Time | UTC-8 |
| Europe | Western European Time | UTC |
| Asia Pacific | Singapore Standard Time | UTC+8 |
The off-peak time periods are not adjusted for daylight savings time. For example, during daylight savings time, the off-peak times in the North America region will be 11:00 p.m. – 7:00 a.m. Pacific Daylight Time (PDT) during weekdays and 11:00 p.m. PDT on Friday through 7:00 a.m. PDT on Monday for weekends.
Windows Azure compute instances come in four unique sizes to enable complex applications and workloads.
| Compute Instance Size | CPU | Memory | Instance Storage | I/O Performance |
| Small | 1.6 GHz | 1.75 GB | 225 GB | Moderate |
| Medium | 2 x 1.6 GHz | 3.5 GB | 490 GB | High |
| Large | 4 x 1.6 GHz | 7 GB | 1,000 GB | High |
| Extra large | 8 x 1.6 GHz | 14 GB | 2,040 GB | High |
Each Windows Azure compute instance represents a virtual server. Although many resources are dedicated to a particular instance, some resources associated to I/O performance, such as network bandwidth and disk subsystem, are shared among the compute instances on the same physical host. During periods when a shared resource is not fully utilized, you are able to utilize a higher share of that resource.
The different instance types will provide different minimum performance from the shared resources depending on their size. Compute instance sizes with a high I/O performance indicator as noted in the table above will have a larger allocation of the shared resources. Having a larger allocation of the shared resource will also result in more consistent I/O performance.
The Windows Azure platform will have Consumption-based pricing when they become commercially available. The details for the US are as follows:
Windows Azure
Compute
Storage
Content Deliver Network
SQL Azure
AppFabric
*These rates are effective for usage beginning in April, 2010. All AppFabric usage prior to April, 2010 will not be charged.
Data Transfers
As we start billing, the following currencies will be used for these countries: Austria € EUR , Belgium € EUR , Canada $ CAD, Denmark kr DKK , Finland € EUR , France € EUR , Germany € EUR , Ireland € EUR , India $ USD, Italy € EUR, Japan ¥ JPY, Netherlands € EUR, New Zealand $ NZD, Norway kr NOK, Portugal € EUR, Singapore $ USD, Spain € EUR, Sweden kr SEK, Switzerland Fr CHF, United Kingdom £ GPB, United States $ USD.
In the April 2010 timeframe, the following currencies will be used for these countries: Australia $ AUD, Brazil $ USD, Chile $ USD, Colombia $ USD, Costa Rica $ USD, Cypress € EUR Czech Republic € EUR, Greece € EUR, Hong Kong $ USD, Hungary € EUR, Israel $USD, Luxemburg € EUR, Malaysia $ USD, Mexico $ USD, Peru $ USD, Philippines $ USD, Poland € EUR, Puerto Rico $ USD, Romania € EUR AND Trinidad & Tobago $ USD.
Prices were determined based a number of key factors, including the cost of hosting the service in different geographic regions, competitive offerings and spot FX rates for applicable currencie
Pricing will be reviewed quarterly to evaluate material changes in costs of hosting the service, competitive analysis, local costs of operations, as well as spot FX rates. It is understood that maintaining consistent pricing is important to our customers, and changes will only be made when necessary.
Available currencies are consistent with the currencies currently approved and published in Volume Licensing.
Windows Azure compute hours are charged only when your application is deployed. When developing and testing your application, developers will want to remove the compute instances that are not being used to minimize compute hour billing. Please note that suspending your deployment will still result in compute charges since the compute instances are still allocated to you and cannot be allocated to another customer. Compute hours are billed based on the number of clock hours your service was deployed multiplied by the number of compute instances.
All compute hours are converted into small instance hours when presented on your bill. For example, one elapsed hour of a medium compute instance would be presented as two small compute instance hours at the small instance rate of $0.12 per hour on your bill. This table describes how each of the compute instance sizes correlates to the number of small compute instance hours:

Compute hours are billed based on the number of clock hours your service was deployed multiplied by the number of equivalent small compute instances included in your deployment. Partial compute instance hours (prior to conversion) are billed as full compute hours for each clock hour an instance is deployed. For example, if you deploy a small compute instance at 10:50 AM and delete the deployment at 11:10 AM, you will be billed for two small compute hours, one hour for usage during 10:50 AM to 11:00 AM and another hour for usage during 11:00 AM to 11:10 AM. For other compute instance sizes you deploy, your hours will be converted into the equivalent small instance hours by multiplying by 2, 4 or 8, depending on the compute instance size deployed. In addition, each time you delete your deployment and redeploy your service, you will be billed a minimum of one clock hour for each compute instance deployed. However, any instances deployed for less than five minutes within one clock hour will not be charged.
If you have two tenants deployed for a hosted service, one for staging and one for production, both will be charged as both are utilizing Windows Azure platform resources.
The Account Owner of your subscription can view usage information by logging into the Microsoft Online Services Customer Portal and clicking on the “View my bills” link. On the page that displays you have the ability to view and download both your billed and unbilled usage. Please note that there can be a delay of up to 12 hours for your unbilled usage data to appear.
Storage is metered in units of average hourly amount of data stored (in GB) over a monthly period. E.g. if a user uploaded 730GB of data and stored it on Windows Azure for one hour, her monthly billed storage would be 1 GB, since there are 730 hours in the average month. If the same user uploaded 730GB of data and stored it on Windows Azure for an entire billing period, her monthly billed storage would be 730GB. Storage is also metered in terms of storage transactions used to add, update, read and delete storage data. These are billed at a rate of $0.01 for 10,000 (10k) transaction requests
Data transfer is charged based on the total amount of data going in and out of the Windows Azure platform services via the internet in a given 30-day period. All data transfers within a sub-region are free.
When developing our pricing model for data transfers, we first took into account the underlying data transfer costs. There are two reasons for inbound traffic being priced lower: First, data transfer costs are significantly driven by outbound traffic; second, lower inbound traffic pricing helps overcome initial barriers to adoption. We are lowering this barrier even further from commercial launch through June 30, 2010 by providing free off-peak inbound data transfer
SQL Azure Web Edition DB includes
The SQL Azure Business Edition DB includes
Beginning in April 2010, we will send alert emails to all Windows Azure platform customers, regardless of offer. Anyone with a commitment offer is being emailed at 75/100/125% of their prepaid monthly service level, and once a consumption offer has been in play for 3 months, we will alert them in the same manner but instead of referring to a prepaid monthly service level, we will utilize a 3 month rolling average.
We are not announcing pricing for the proposed Windows Azure VM functionality right now. However, this pricing will be consistent with our current Windows Azure pricing model.
SQL Azure customers can provision unlimited number of databases based on their application needs. Data can be partitioned across multiple databases without any size limitation.
SQL Azure database is charged based on the portion of database consumed by the application.
The customer/partner needs to have a valid billing address and be physically located in one of the supported countries to use the Windows Azure platform. The one exception is we will allow our existing CTP participants from non-supported to maintain their CTP accounts until their country is supported or we decide to end the CTP for their country.
At PDC, we released a cost calculator that makes it easier to predict costs based on your usage. Because predicting usage can often be problematic, we are also providing examples of common application types, including with the cost of running them on the Windows Azure platform.
The Windows Azure platform services are designed in such a way that partners and customers can consume component services such as Windows Azure compute, Windows Azure storage, SQL Azure databases, or AppFabric Service Bus on a standalone basis. The pricing for these component services also reflects this design principle.
Windows Azure platform AppFabric usage is charged separately for each component, Services Bus and Access Control.
AppFabric Service Bus costs $3.99 per Connection-month on a consumption (pay-as-you-go) individual basis, plus the associated Windows Azure platform data transfer at a price of $0.10/GB for ingress and $0.15 for egress. Or, if you are able to forecast your needs ahead of time, you can purchase “Packs” of Connections. For example: $9.95 for a pack of 5 Connections, $49.75 for a pack of 25, $199.00 for a pack of 100, or $995 for a pack of 500, plus data transfer charges. Connection Packs represent an effective rate of $1.99 per Connection-month.
AppFabric Access Control will be priced at $1.99 per 100,000 Transactions, which includes token requests and management operations, plus associated data transfer. Typically, Service Bus developers depend on Access Control to secure their Connections.
Windows Azure platform AppFabric provides secure connectivity as a service via the Service Bus in much the same way that Windows Azure provides general-purpose computation and storage as a service. In fact, the Service Bus runs directly on Windows Azure compute instances. Because of this, the pricing model for the Service Bus is similar to compute and storage pricing. That is to say, you pay for connectivity resources while you are using them. In the case of the Service Bus, the underlying resources that you use include (portions of) compute instance resources, storage resources, and networking resources.
Because we designed the Service Bus for high efficiency and fluid scale, we are able to offer a pricing structure that reflects both resources in a single pricing meter that maps directly with your usage. We call that a “Connection,” which reflects the basic function of the Service Bus: to connect two (or more) applications. To send data to or from the Service Bus, whether it’s a transactional message or a data stream, you need a Connection to the Service Bus. You can think of these Connections as communication sessions between your application and the Service Bus, which your application can “open” or “close” at any time. When you create applications that are connected to the Service Bus, we charge you for each Connection, rather than the number of messages or the volume of data. These Connections result from opening services, opening client channels, or making HTTP requests against the Service Bus.
In most cases, a minimum of one Connection will be needed for each device or application instance that connects to the Service Bus. For example, if 20 devices each have one application that connects to the Service Bus, then 20 Connections would be required; if one device has ten applications that each connect to the Service Bus, then 10 Connections would be required. In certain cases, fewer or more Connections may be required.
When your application becomes very active and makes heavier use of that Connection, for example by sending a higher volume of messages, your price for that Connection is the same (net of the associated data transfer). This per-Connection pricing model helps customers predict their monthly price effectively, while still giving them the flexibility to increase and decrease their usage as needed.
Your usage may fluctuate, with Connections being opened and closed frequently during a month. To accommodate this pattern, we calculate the maximum number of open Connections that you use during a day. During each monthly billing period, we will charge for the average of that daily number, which amounts to a daily pro rata charge.
That means you don’t need to pay for every Connection that you create; you’ll only pay for the maximum number of Connections that were in simultaneous use on any given day during the billing period. It also means that if you increase your usage, the increased usage is charged on a daily pro rata basis; you will not be charged for the entire month at that increased usage level.
For example, a given client application may open and close a single Connection many times during a day; this is especially likely if an HTTP binding is used. To the target system, this might appear to be separate, discrete Connections, however to the customer this is a single intermittent Connection. Charging based on simultaneous Connection usage ensures that a customer would not be billed multiple times for a single intermittent Connection.
Example 1: A composite application that connects an on-premises database to a cloud service makes use of two Connections. In a given month, this customer could pay for both Connections on an individual basis and the bill would be $7.98. If this customer believed that the number of Connections might increase throughout the month, (s)he could also opt for the greater predictability of a reserved pack of 5 Connections. In this case, the bill would be $9.95 per month even if the number of Connections increased from 2 all the way to 5.
Example 2: A second application uses the AppFabric Service Bus to connect a series of handheld devices to an on-premises database. In this case, there is a Connection for the database and for the devices. If the customer used 8 Connections in the first half of the month and 15 in the second half of the month, the bill could be one of three amounts. (S)he could choose to pay on a pure consumption basis, where the bill would be $45.891; (s)he could buy a reserved pack of 25 Connections for $49.75, which would result in a more predictable price in case the number of Connections increased further; or (s)he could buy a reserved pack of 5 Connections and pay for any Connections above this amount on a consumption basis for a total bill of $35.892, which in this example leads to the lowest bill.
In each case there are no additional charges for payload, but customers would be responsible for ingress and/or egress charges at the Windows Azure platform rates. Should customers use Access Control to secure their Connections, they would also incur a charge according to the Access Control pricing schedule.
1Note: $3.99 per connection-month is $0.133 per connection-day. This example has (8 x 15) + (15 x 15) = 225 connection-days. $0.133 x 225 = $45.89.
2Note: A reserved pack of 5 Connections is $9.95 per month. Connections beyond 5 are $0.133 per connection-day. This example has (3 x 15) + (10 x 15) = 195 connection-days beyond the reserved pack amount. ($0.133 x 195) + $9.95 = $35.89.
Although applications interact with Access Control in a somewhat similar manner to how they interact with the Service Bus, by sending and receiving messages, Access Control has some fundamental differences in the way it is used. Most importantly, those connections are lightweight and short-lived. That means a single Access Control token processing endpoint can handle connections with a great number of external applications that send token requests. Because of these factors, the primary resource usage corresponds directly to the processing of token requests: unpackaging & decrypting tokens, performing claims transformation against rules, repackaging & reencrypting them to be returned to the requestor, and creating & modifying rules. We use the “ACS Transactions” meter to reflect the direct relationship between these transactional operations and resource usage.
When customers choose to purchase a Connection Pack, they are in a sense “reserving” those Connections. This allows Microsoft to plan ahead to provide these Connections, before a customer needs them. When a very high number of customers purchase Connections in this way, we can plan Connection capacity in a much more efficient manner, which substantially lowers the costs of providing those Connections. For customers, the resulting benefit is a more predictable bill that is less subject to month-to-month fluctuations. Still, many customers will prefer the flexibility of purchasing Connections on a pay-per-use basis. Customers who need both predictability and flexibility can combine a Connection Pack with standard pay-per-use Connections within a single account. In that case, Connections that exceed the purchased Pack quantity will be charged at the individual pay-per-use rate, and only when the Connection usage exceeds the purchased Pack quantity.
Service Bus Connections are opened against a Service Bus endpoint (a URI in a Service Bus domain) and become billable once an application performs one of the following actions:
1: billable until closed, deleted, or expired, as appropriate
2: includes NetOnewayRelay, NetEventRelay and NetTcpRelay
3: includes retrieval (Retrieve, Peeklock, Delete, Unlock) and insertion (Enqueue). The first request to retrieve a message from an existing message buffer is free.
For billing purposes, Connections are measured and recorded in 5-minute intervals. The average number of open Connections during each interval is recorded. We do this to protect customers against undue charges for brief increases in open Connections. Therefore, if Connections are open for only a short time within an interval, e.g. 10 seconds, you will not be unduly impacted.
Special considerations for direct connections: should the AppFabric Service Bus be configured to attempt a direct socket connection between Client and Service endpoints, there is no charge for Connections after this type of connection has been established. Note that connections are billable both before the direct connection is made, and if the direct socket connection fails and data again flows through the Service Bus.
Customers may purchase as many pay-per-use individual Connections as they like during any billing period, subject to system quotas and credit limits. They may also purchase up to one Connection Pack per solution per billing period. If a customer decides that a larger or smaller Pack is needed during a billing period, (s)he may choose a different Pack size and the difference in price will be incorporated on a pro rata basis. The Pack size for a given Service Namespace cannot be changed more than once every seven (7) days. Customers may not combine multiple Connection Packs in a single Namespace.
The motivation for this change was to make the pricing meter simpler for customers both to understand and to predict, for a wide range of uses. Feedback from early customers clearly showed that the Message Operations pricing model made it difficult for customers to anticipate their consumption and thus to forecast their costs. While computation time and storage volume have corresponding concepts in traditional on-premises computing environments, frequency of message traffic is not something that most customers are accustomed to calculating, let alone forecasting. We chose the Connection pricing meter because it corresponds to a more familiar unit of measure for more developers and IT professionals.
The Message Operations meter was well suited for uses such as discrete transactional messaging, but it proved more complicated in other cases. For example, what happens if you stream a large file, tunnel a protocol that stays open, or deploy a lot of devices that all "listen" idly all day? In these cases, it can be very difficult to determine what counts as a message, and to predict usage from day to day.
It turns out that our customers have many of these uses in mind. Our pricing is now more applicable to those situations, incorporating uses such as streamed data, protocol tunneling, and transactional messaging. In addition, the Connections meter provides increased predictability, because the price stays the same whether you use a Connection more or less from one month to the next. We believe this Service Bus pricing model does a better job of satisfying our “simple, predictable, and versatile” philosophy, and ultimately of serving you, our customer.
The Windows Azure platform usage report is provided in the form of a downloadable text file containing values in comma-separated format (CSV) for the following AppFabric usage meters:
The Account Owner of your subscription can view usage information by logging into the Microsoft Online Services Customer Portal and clicking on the “View my bills” link. On the page that displays you have the ability to view and download both your billed and unbilled usage. Please note that there can be a delay of up to 12 hours for your unbilled usage data to appear.
This report is most easily reviewed in a spreadsheet program like Microsoft Excel.
The report contains the following columns: 
There are three different kinds of usage records: Service Bus Connections, Access Control Transactions, and Data Transfer (as indicated by the resource column):
The maximum number of open Connections is used to calculate your daily charges. For the purposes of billing, a day is defined as the period from midnight to midnight, Coordinated Universal Time (UTC).Each day is divided into 5-minute intervals, and for each interval, the time-weighted average number of open Connections is calculated. The daily maximum of these 5-minute averages is then used to calculate your daily Connection charge.
Because the average number of open Connections during a 5-minute interval is used to calculate your Connection charge, you will not be unduly impacted if your number of open Connections increases briefly. For example, if one Connection is open for an entire interval and another Connection overlaps with it by ten seconds, your 5-minute average would be 1 + 10 ÷ (5 x 60) = 1.0333 Connections.
You may select a different size Connection Pack at any time. You may increase or decrease that Pack size as you wish. These changes are limited to once every seven days.
Customers can use Individual Connections to purchase the exact number of Connections they need, anywhere between 1 and 500 Connections. If they are able to forecast their needs in advance, they may select a Connection Pack in the amount of 5, 25, 100, or 500 Connections. In addition, customers may supplement their Connection Packs with Individual Connections, for example 5 of Pack + 2 of Individual = 7 total Connections. At this time, other pack sizes smaller than 500 are not available, and customers may not purchase more than one Pack at a time within a service namespace. Pack sizes larger than 500 may be available on request.
Customers who wish to have more than one pack will need to create additional service namespaces. For example, if a customer wishes to have 200 Connections, they would need to purchase a 100- Pack in a first Namespace, and an additional 100-Pack in a second Namespace.
Any data transfer within a given Windows Azure platform sub-region is provided at no charge. Any data transfer that meets the requirements for the off-peak ingress limited time promotion is provided at no charge. Any data transfer outside a sub-region is subject to ingress and/or egress charges at the Windows Azure platform rates. For example, if you use Service Bus to communicate between two Windows Azure applications within the same sub-region, you will not incur data transfer charges. However, if you use Service Bus to communicate between regions or sub-regions, for instance to send data from one Windows Azure application in the North Central sub-region to another Windows Azure application in the South Central sub-region, you will incur egress charges at North Central rates and ingress charges at South Central rates. If you use Service Bus to send and not receive data from a Windows Azure application to an application within your own datacenter, you will incur egress charges for your Windows Azure platform usage.

The Windows Azure platform Partner model has ‘Embedded Windows Azure Platform’ and ‘Built for Windows Azure Platform‘ elements. In the ‘Embedded Windows Azure Platform’ Channel model, a partner can build a service or set of offerings on the Windows Azure platform and sell these to their customers without requiring the customer to have a relationship with Microsoft. In this case, Microsoft will give partners a discount for consuming platform resources. In the ‘Built for Windows Azure Platform’ Channel model, a partner builds and sells services or offerings which are accessible via the Windows Azure platform. Customers are responsible for any Windows Azure platform usage associated from the partner’s service and pays Microsoft for that.
Hosters can offer tools and solutions for Windows Azure platform development and aggregate customer offerings. Examples are:
The business opportunities for Hosters are:
The Windows Azure Platform is a development platform for cloud-based services. Microsoft is offering a cloud services platform that could be used to build and run many types of web applications, from simple web sites to complex ERP systems. Microsoft expects many partners, including hosters, to develop finished market-ready services on top of the Windows Azure Platform. By providing and managing the underlying infrastructure, Microsoft frees the partner to develop value-added cloud services without having to wrestle with the complexities and costs of scale-out compute and storage. In providing the Windows Azure Platform and its accompanying partner pricing models, Microsoft is providing all types of Microsoft partners the means to innovate and use the platform as a springboard to success in their market.
Microsoft is releasing the Windows Azure Platform with a detailed partner channel model. We have an “embedded” Windows Azure platform partner model in which the partner purchases capacity from Microsoft and “resells” it through an application to its end customers. We also have a “built for” Windows Azure platform model in which the end customer purchases an account, and then maps the service usage from a partner application or service to that account. Microsoft is a partner-oriented company: we are committed to our partner channel and making our partners successful. Hosters who are worried that the Windows Azure Platform is competing with them should keep in mind that they are free to develop lightweight wrappers (control panels, etc.) on top of the platform that enable their customers to run web sites and databases on Windows Azure while still buying directly from the hoster. Microsoft is not requiring you to disclose anything about the end customers you bring to the platform. In fact, we encourage hosters to develop innovative new types of hosting services on top of the Windows Azure Platform that make them successful in market.
Today, as a mass market shared hosting provider, you supply tools, a control panel and sometimes an online marketplace to web customers looking for dedicated and shared capacity. With The Windows Azure Platform, you can do the same to reach customers. The Windows Azure platform may also enable new scenarios for mass market shared hosting providers are follows:
Today, as a Managed Hosting Provide, your primary focus is providing solutions that combine Windows Server with management services; and you probably aim at customers needing dedicated or virtual dedicated environments. Yet many customers have need of both dedicated and shared hosting for different workloads and business scenarios. The Windows Azure platform provides managed hosting providers an opportunity to expand their business. Two potential scenarios are as follows:
Customers who purchase your services today typically also have a variety of hosting needs that you currently do not service. You can now consider the value of providing a more complete bundle of capabilities to your customer by mixing complementary Windows Azure platform-hosted services alongside your current business platform. Some potential scenarios are:
The first choice you must make is whether you wish to bill the customer for their Windows Azure platform usage yourself or have Microsoft bill them for you. Microsoft has two partner models, an ‘Embedded’ Windows Azure platform model and a ‘Built For’ Windows Azure platform model.
If you choose the ‘Embedded’ model, then you will have your own account with Microsoft, you will build tools and utilities on top of the Windows Azure platform that your customers will access to make use of the platform, and any resulting usage will be billed to your account. If you want to map your aggregate Windows Azure platform usage back to individual end customers for rebilling purposes, it is up to you to include the appropriate usage tracking in your tools and utilities.
If you choose the ‘Built For’ model, your end customer will sign up for a Windows Azure platform account directly with Microsoft, and then access your tools and utilities after they have logged in so that usage is billed directly to their own Windows Azure platform account. In this scenario you have no involvement in the Windows Azure platform billing but may charge additional fees for the use of your tools and utilities.
In either case, your job is to provide the custom screens, tools and utilities that your customers will use to simplify and streamline their use of the Windows Azure platform and make it appropriate to their needs.
Today the Windows Azure Platform does not have a publicly accessible, programmable account management and billing API. All account provisioning, logon and usage reporting are managed through a web user interface. Partners, therefore, have an opportunity to build out their own provisioning and account management layer that supports all their customers within a single Windows Azure platform account owned and controlled by the partner.
The security necessary to segregate one end customer’s usage of the platform from another within the same billing account is readily available in the Windows Azure and Windows Azure platform Service Bus and Access Control APIs and in the SQL Azure database offering. This is in fact the standard multi-tenant approach used by major Software-as-a-Service ISVs in their applications today. What a hoster must do if they wish to re-bill underlying Windows Azure platform usage (expressed in service hours, storage and data transfers) directly to their customers is develop the tools necessary to track and record their individual customers’ usage of the Windows Azure Platform services.
One of your most valuable assets is your SMB customer base. SMB customers prefer to buy from fewer providers and would rather purchase certain value-added services in a bundle with their voice and data network. Instead of building out your own value-added services infrastructure for products such as cloud storage, simple web sites and simple databases, you now have the opportunity to enable these features without the infrastructure investment risk by deploying them on the Windows Azure platform. You can even consider scenarios where you integrate your unified messaging system with the Windows Azure platform to create new and compelling solutions that combine presence and data access across your network and the cloud.
OEMs can bundle backup services with their devices to generate a reoccurring revenue stream.
Web Agency / VAP can quickly and easily create, deploy, manage, and distribute web applications and services. The business opportunities for Web Agency / VAP are:
ISVs can quickly and easily build, deploy, scale, and manage web applications and services using the Windows Azure platform. The business opportunities for ISV’s are:
Systems Integrator can leverage the efficiency of the Windows Azure platform to connect and manage infrastructure required for your projects. The business opportunities for Systems Integrator are:
Custom Software Developers (CSD) can build solutions for customers that use the Windows Azure platform to simplify the infrastructure requirements for their projects. The business opportunities for CSD’s are:
Technical guidance, resources, training, and partner marketing kits to help early adopter IDV’s successfully build and take applications to market. Azure Front Runner is for ISV’s based in the US, Green Light is for ISV’s outside the US.
A host of partners have developed solutions on Windows Azure and SQL Azure. For additional information, please visit http://www.microsoft.com/windowsazure/evidence
Members of the Microsoft Partner Network will receive a 5% discount on all Windows Azure Platform Services and offers with the exception of Windows Azure Storage and Data Transfers (bandwidth):
Free for all partners
Gold / Certified / MAPS / Empower
Exclusive to Certified/Gold
Additional Technical Support Paid
The Windows Azure Platform Partner Resource Guide outlines all available programs, readiness resources, and partner offers. The Guide can be accessed from either www.windowsazure.com/partners or www.azurehub.com
Programs include:
Resources:
Demand Generation/Marketing:
Partner Sales:
Yes, commercially available applications and services built upon the Windows Azure platform can be published in Microsoft Pinpoint
Microsoft Pinpoint is a dynamic technology marketplace that helps you successfully connect with business customers who need the software and professional services you offer. Use Pinpoint’s powerful tools and resources to:
No, as long as your offering is commercially available, leverages the Windows Azure Platform, and you use the Windows Azure portal to list your application or service, you can get listed on Pinpoint.
Yes, a 5% (except for storage and data transfer) promotional discount is available to all Microsoft Partners that are registered in the Microsoft Partner Network. At commercial launch, additional promotional discounts will be offered to help partners rapidly develop and deploy apps to the Windows Azure platform.
Using the cloud has the potential to increase a partner’s revenue and/or decrease costs. Running code and storing data on computers in large Internet-accessible data centers owned by somebody else can offer compelling advantages. Anyone responsible for charting the course of an ISV ought to be thinking seriously about how cloud computing will affect their business.
The Microsoft Partner Program will incorporate support for the Windows Azure platform into the standard set of support offerings available for other Microsoft products. We expect that partners using the Windows Azure platform will find significant value in the Partner Program’s Online Technical Communities, Technical Advisory Services, and Solution Accelerators.
Partners need to evaluate their existing assets to understand the impact of adopting the cloud. For partners that have .NET or PHP developers and are developing new apps, web apps, or already have a SaaS business the investment should be relatively light. Partners looking to use the Windows Azure platform as the first step to the cloud can begin by augmenting their existing applications with cloud based components. Partners looking to port their existing on-premises applications to the cloud will require investment in training and will likely have to re-architect portions of the code for the cloud.
We suggest that all partners start their investment by visiting www.windowsazure.com/partners and www.azurequickstart to get business and technical resources. We will use these portals to share upcoming events, announcements, and opportunities. Additional readiness materials can be found on the Microsoft Partner Portal and Partner Learning Center where the Microsoft Partner Program has created a specific Windows Azure platform learning path.
Lastly, the best way to truly understand the investment required is to have your developers spend time exploring these services. Start with the Partner Resource Guide from either of the above portals.
Microsoft sees opportunities for all partner types to leverage the Windows Azure platform in providing solutions to their customers. We expect developer focused partners such as ISVs, Custom Software Developers, Hosters, System Integrators, and Web Agencies to be early adopters of the platform.
At the Windows Azure commercial launch, the Microsoft Partner Program will provide partner benefits that focus on partner readiness, support, and services discounts. In the medium term (1-2 years) we expect the Windows Azure platform to be integrated across a variety of competencies and included in appropriate partner marketing campaigns. We will do limited joint marketing with a few hand selected partners during the next year, but expect broader partner oriented marketing efforts to begin in FY11 once partners have been trained and have solutions ready to take to market.
The changes to the Microsoft Partner Network were largely driven by the changing needs of partners, and in part by changes brought on by shifts in business models and customer needs. In making those changes, we have paid close attention to the ways that we can better support partners who choose to build solutions and practices around the Windows Azure platform. Stay tuned for further announcements.
Microsoft has a history of working with partners to build our businesses together. It’s been widely quoted that Microsoft partners earn nearly $8 for every dollar Microsoft earns, and that 42% of global IT employment stems from the Microsoft ecosystem. What this means is that Microsoft depends on a healthy partner ecosystem to deliver value to customers, and partners can expect this trend to hold true with the Windows Azure platform as well. We understand that partner success is absolutely instrumental in driving Microsoft’s success, and this will continue to be reflected in partner programs and offerings.
At launch, the Windows Azure platform will offer special discounts and new offerings targeted exclusively at partners, integrated into the established, familiar ways that partners already do business. For example, the Microsoft Partner Program is a well-established program, and a special discount will be made available through MSPP. MSDN is another mechanism through which partners can enrich their relationship with Microsoft; the Windows Azure platform will have a targeted offering optimized for MSDN subscribers.
What Microsoft brings to the partner ecosystem is a cohesive, integrated development platform and developer experience that gives partners and customers the power of choice to deploy server-side applications in the cloud, on-premises, at-hoster, or in a combination of deployments, as well as on desktops and mobile devices – with the same set of skills and tools. With the Windows Azure platform, Microsoft partners have yet another development and deployment tool in the toolbox. This means that partners get more out of their software investments when choosing Microsoft, and it means they can best suit their solutions to customer needs. Partner monetization is answered in the To-Partner and Through-Partner questions.
Online Services (BPOS & CRM) are finished services where we offer partners a fee for selling the services to customers. The Windows Azure platform comprises of a cloud services operating system and developer services that partners can leverage to create either a Finished Service or a Building Block service that can be used by other partners to create a finished service. We are currently investigating other options that would support partners in a variety of business models.
It is up to the partner to ensure the legality of their finished services offering in the jurisdiction where they offer the finished service.

A content delivery network (CDN) enhances end user performance and reliability by placing copies of data, at various points in a network, so that they are distributed closer to the user. A client accesses a copy of the data near to the client, as opposed to all clients accessing the same set of central servers (called Origins), thereby causing a bottleneck near these Origin servers. Content types include web objects (e.g. JPG, CSS, and JavaScript), downloadable objects (media files, software, documents) and other components for Internet delivery. Windows Azure CDN supports HTTP delivery of public content stored in Windows Azure storage.
Content owners should consider performance benefits and trade-offs of using the Content Delivery Network. Benefits include 1) Better performance and user experience for end users who are farther from the source of the content, and are using applications where many ‘internet trips’ are required to complete the loading of a WEB page, and 2) Large distributed scale to better handle instantaneous high load, say at the start an event such as a product launch. Trade-offs include higher cost for delivery, and limited ability to quickly remove content, and potential performance reduction of delivery performance for content rarely retrieved.
Content owners use the Windows Azure portal to enable CDN caching for their storage account. Windows Azure will generate a CDN specific domain name at this time, and within 60 minutes the configuration will go live around the world, allowing the Windows Azure content owner to use this CDN specific domain name in all references of the object to enable retrieval of the object through the CDN.
The Windows Azure CDN can enhance performance of any file 10GB and smaller. Performance increases proportionally as the number of active users and/or distance from origin increase. Content can vary – for example from a static jpg 4KB file to a 6GB movie, stored in Windows Azure storage.
When an HTTP request for an object reaches an edge server, if the object is not already in the server’s local cache a request is made against the Windows Azure storage (origin), and the object is pulled into the edge server’s cache. From there it is served in response to the initial request, and every subsequent requests reaching this edge location will be served from the edge cache. By delivering the content from edge servers located close to the user, the latency to deliver the content is greatly reduced, improving the performance of the delivery over retrieving the object from the origin for each request.
The Windows Azure CDN supplements Windows Azure storage to enable in-region delivery of the content. The content is stored in Windows Azure storage and can be delivered either directly from the Windows Azure store or from the Windows Azure store through the CDN.
Both services are capable of delivering the same stored content. Content owners need to decide which content will benefit more from CDN delivery (multiple repeated accesses by many users) or from direct Windows Azure Storage delivery (more customized or less-used content, for example) balanced with overall price and performance goals. The application needs to render the correct URLs (Windows Azure CDN or direct Windows Azure Storage) accordingly.
Any public content of 10GB or less in size stored in Windows Azure storage can be retrieved through the CDN through HTTP requests. Performance improvements from the use of the CDN is optimum for popular content (requested frequently, resulting in high cache hit ratio). Secure content not supported at this time.
Through the Windows Azure Portal the content owner can enroll a different domain name to be used to retrieve the content from the CDN. That different domain name must be CNAME’d to the Windows Azure CDN domain name for requests to be routed to the CDN, and that domain name must be enrolled with the CDN in order for the CDN to recognize and service requests routed through this domain name
You can suspend Windows Azure CDN caching through the Windows Azure Portal by unchecking the CDN caching option.
You can control the approximate lifetime of an object in the CDN’s caches by attaching a “Cache-Control: public, max-age=<val>” header to the object metadata in Windows Azure Storage with the appropriate value in seconds. For example, to set a one year max-age, the HTTP header would appear as “Cache-control: public, max-age=31556926”. This can be performed with Storage management tools or with code by simply setting the CacheControl property on the CloudBlob.Properties in StorageClient.
Remember that max-age is a “guideline” for caches and is not a complete guarantee of expiration from all points on the CDN or downstream caches elsewhere in the Internet. It is a freshness hint, not a security or compliance mechanism.
As you remove the content from the Windows Azure store the content will expire from the Edge caches at the end of the content caching duration as specified in the original’s content HTTP expiration header or within 72 hours if no content expiration header was specified in the Windows Azure storage.
The Windows Azure Content Delivery Network (CDN) is used to deliver static files from Windows Azure Storage to users around the world. All content is “public readable” from the CDN and is optimized for end-user delivery.
Microsoft project code named Velocity is an in-memory cache of application objects for fast access by executing services.
Not at this time, but we are currently evaluating this. The Windows Azure CDN does support HTTP progressive download delivery of media files to the Silverlight player. You can even set your Expression Encoder to upload the file to Windows Azure Storage after encoding for easy implementation.
Although both use HTTP to deliver the video, Smooth Streaming can detect connection speeds, and in real time adjusts the data-rate being delivered to adjust for network congestion. Progressive Download delivers the file to the end user as fast as it can in the background as its being viewed.
No, at this point the Windows Azure CDN only supports HTTP delivery of files.
True “streaming” is normally delivered by proprietary formats in real time to the end user, and only delivers the content being viewed and a small buffer. Progressive Download delivers content at a maximum speed in the background to the viewer, as its being viewed.
The Windows Azure CDN works in conjunction with Windows Azure storage to enable in-region delivery of the content. The content is stored in Windows Azure storage and can be delivered either directly from the Windows Azure store or from the Windows Azure store through the CDN.
Any public content of 10GB or less in size stored in Windows Azure storage can be retrieved through the CDN through HTTP requests. Performance improvements from the use of the CDN is optimum for popular content (requested frequently, resulting in high cache hit ratio). Secure content not supported at this time. Through the Windows Azure Portal the content owner can register with the CDN a different domain name to be used to retrieve the content from the CDN. That different domain name must be CNAME’d to the Windows Azure CDN domain name for requests to be routed to the CDN, and that domain name must be registered with the CDN in order for the CDN to recognize and service requests routed through this domain name.

Windows Identity Foundation (formerly called code name Geneva framework) is a new extension to the Microsoft .NET Framework that helps developers build claims-aware applications that externalize user authentication from the application, improving developer productivity, enhancing application security, and enabling interoperability. Based on interoperable, standard protocols, WIF and the claims-based identity model can be used to enable single sign on, personalization, federation, strong authentication, identity delegation, and other identity capabilities in ASP.Net and WCF applications running both on-premises and in the cloud.
With Windows Identity Foundation, developers have a single programming model for handling identity in an application, regardless if that application is hosted on-premises or in Windows Azure. Productivity is enhanced since you only need to learn one model and one set of tools, and those skills translate quickly if you change hosting environment. Since the model is the same regardless of where the application is hosted, using Windows Identity Foundation will make it easier to move an application (from an identity perspective) from on-premises to Windows Azure, and vice versa.
Yes. Windows Identity Foundation can be used to build on-premises software as well as cloud services, including those running in Windows Azure.
Active Directory Federation Services 2.0 is an extension to Active Directory that enables Active Directory to become an infrastructure service for claims-aware applications. Called a Security Token Service (STS), AD FS 2.0 enables users in Active Directory to authenticate to claims-aware applications, and acts as the authoritative source of claims (attributes) about those users – whether the information about the users is stored in Active Directory, a SQL database, or other store. Used as a federation service, AD FS 2.0 provides a single point of management for federation relationships, and using industry standard protocols like SAML 2.0 can enable single sign on for Active Directory users to applications at partner organizations or in the cloud.
Active Directory Federation Services 2.0 is an extension to Active Directory that enables Active Directory to become an infrastructure service for claims-aware applications. Called a Security Token Service (STS), AD FS 2.0 enables users in Active Directory to authenticate to claims-aware applications, and acts as the authoritative source of claims (attributes) about those users – whether the information about the users is stored in Active Directory, a SQL database, or other store. Used as a federation service, AD FS 2.0 provides a single point of management for federation relationships, and using industry standard protocols like SAML 2.0 can enable single sign on for Active Directory users to applications at partner organizations or in the cloud.
No. While WIF does work with AD FS 2.0, it is not a requirement. WIF is a standards-based framework and works with any Security Token Service that supports open standards.
AD FS 2.0 will RTM in H1 CY10.
AD FS 2.0 is an on-premises Windows Server role. AD FS 2.0 can federate with Windows Azure hosted applications. Alternatively, it can federate with the Microsoft Federation Gateway (a component of Windows Azure) to access a wide range of Microsoft online services (including the Windows Azure platform) through a single federation relationship.
ACS, WIF, and AD FS v2 can be used together to develop web services that combine the security and capability of Active Directory with the flexibility and control of custom access control rules, within a simple, closely integrated developer experience. Access Control allows developers to manage access to RESTful web services using a cloud-based service instead of writing complex authorization code into their application. This means developers can more easily build REST services that require federation with multiple AD FS instances and/or need fine-grained authorization rules. Active Directory Federation Services 2.0 can federate with ACS, which accepts tokens from AD FS 2.0 and repackages them with new claims.
At v1, there will be community samples that demonstrate how to use WIF and Active ADFS 2.0 with Access Control. WIF will be used to acquire a SAML token from ADFS 2.0and to extract the claims from an ACS-issued token. Note that extracting claims from an Access Control-issued token will require custom extensions to WIF. The WIF and ADFS teams are currently investigating native support for this type of token in the future versions of both WIF and ADFS.
At v1, there will also be a community sample that demonstrates how to use WLID with Access Control.

The SLAs for Windows Azure and SQL Azure went into effect on Feb 1st, 2010. SLAs for the Windows Azure platform AppFabric will go into effect for all customers in April, 2010
Not at the current time. This is under consideration and availability is being reviewed.
Windows Azure has separate SLA’s for compute and storage. For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains your Internet facing roles will have external connectivity at least 99.95% of the time. Additionally, we will monitor all of your individual role instances and guarantee that 99.9% of the time we will detect within two minutes when a role instance’s process is not running and initiate corrective.
For storage, we guarantee that at least 99.9% of the time we will successfully process correctly formatted requests that we receive to add, update, read and delete data. We also guarantee that your storage accounts will have connectivity to our Internet gateway.
Windows Azure SLA Credits are calculated as a percentage of the bill for that service in the month the SLA was missed and then applied to the next month’s bill. Details are as below:
Uptime percentage commitments and SLA credits for Service Bus and Access Control are equivalent to those specified above in the Windows Azure SLA.
Due to inherent differences between the technologies, underlying SLA definitions and terms differ for the Service Bus and Access Control services. Using the Service Bus, customers will have connectivity between a customer’s service endpoint and our Internet gateway; when our service fails to establish a connection from the gateway to a customer's service endpoint, then the service is assumed to be unavailable. Using Access Control, customers will have connectivity between the Access Control endpoints and our Internet gateway. In addition, for both Service Bus and Access Control, the service will process correctly formatted request for the handling of messages and tokens; when our service fails to process a request properly, then the service is assumed to be unavailable. SLA calculations will be based on an average over a 30-day monthly cycle, with 5-minute time intervals. Failures seen by a customer in the form of service unavailability will be counted for the purpose of availability calculations for that customer.
The Windows Azure platform offers uniform credit levels to make it easier for customers to understand their SLAs. For the Service Bus and Access Control services, SLA credits are equivalent to the Windows Azure compute and storage SLAs. Specifically:
SQL Azure customers will have connectivity between the database and our Internet gateway. SQL Azure will maintain a “Monthly Availability” of 99.9% during a calendar month. “Monthly Availability Percentage” for a specific customer database is the ratio of the time the database was available to customer to the total time in a month. Time is measured in 5-minute intervals in a 30-day monthly cycle. Availability is always calculated for a full month. An interval is marked as unavailable if the customer’s attempts to connect to a database are rejected by the SQL Azure gateway.
SQL Azure Database SLA Credits are calculated as a % of the bill for that service in the month the SLA was missed and then applied to the next month’s bill. Details are as below:
Except for Compute Role Instance monitoring, where the SLA requires that the customer have at least two running role instances in order to qualify for the SLA, we do not exclude maintenance windows
Windows Azure, SQL Azure, and AppFabric are independent of our on-premises Microsoft licensing agreements. Our SLAs for the Windows Azure platform provide you a monthly uptime guarantee for those services you consume in the cloud, with SLA credits against what we have billed you in the event we fail to meet the guarantee.
No. Currently you can’t bring your existing on-premises Windows Server, SQL Server or .NET licenses to Windows Azure, SQL Azure or AppFabric.
There are currently no plans to offer Windows Azure through SPLA.
There are currently no plans to offer SQL Azure through SPLA.
A cloud platform such as Windows Azure is different from traditional hosting. From a technical perspective, Windows Azure provides a unique platform for developing highly available applications that can be quickly scaled up or down. With Windows Azure, customers pay for what they use and focus on building and managing the application while Microsoft manages the hardware and provides automated service management. In traditional hosting, the hoster provides and manages the hardware, while the customer is responsible for installing, setting up, updating and managing both the operating system and the application.
SQL Azure is a highly available, scalable, distributed database service hosted by Microsoft in the cloud. SQL Azure enables easy provisioning and deployment of relational database service. Developers do not have to install, setup, patch or manage any software. HA, backup and recovery, geo-distribution and disaster recovery will be built-in. With a dedicated hosted database, developers and IT Pros are still responsible for installing, setting up, updating and patching OS & database software. Additionally, users of hosted database solutions have to devise their own HA, scale out and disaster recovery solutions thus increasing the total cost of administration.
There are currently no plans to offer SQL Azure through SPLA.
At commercial launch, Windows Azure will not have specific audit or security certifications. You can expect to see us pursue key certifications, such as the ISO27001, in the near future. The Windows Azure Platform and Windows Azure apply the rigorous security practices incorporated in the Security Development Lifecycle (SDL) process. SDL introduces security and privacy early and throughout the development process. The Windows Azure Platform and Windows Azure also benefit from the security capabilities afforded by the Microsoft Global Foundation Services’ (GFS) infrastructure. The GFS assurances are validated by external auditors on a regular basis and include a comprehensive security program that covers the entire delivery stack.
Microsoft makes no claim regarding PCI standards for 3rd party hosting. There are ways to develop cloud based applications to use 3rd party PCI data processers that may keep the cloud application itself out of scope.

The promise of cloud is choice, and Microsoft is best positioned to offer businesses and developers the greatest breadth of choice as they engage in cloud computing. Microsoft differentiates itself from Amazon, Google or any other competitor in a fundamental way by providing customers the flexibility to use on-premises technology, cloud technology or both, as part of Microsoft’s software-plus-services (S+S) strategy. Microsoft is poised to deliver the most comprehensive set of services, spanning from consumer to business and offering developers the most inclusive onramp to the cloud.
While Windows Azure is a cloud service that uses (and charges via) computation resources that are analogous to physical computers, it differs in important ways from platforms such as AWS that offer VMs on demand. With a purely VM-based platform, the situation is much like hosting: You bear full responsibility for configuring and managing the VMs and the software they contain. With Windows Azure, you only need to supply the application, along with instructions about how many instances to run. The platform itself takes care of everything else, including updating system software when required.
The Windows Azure platform also offers functionality to make it easy to connect applications and databases hosted in the cloud with other hosted and on-premises software assets. This functionality is provided by the Service Bus and Access Control. While other offerings such as AWS provide features primarily intended to connect one EC2 instances with another EC2 instance, Service Bus and Access Control are designed to connect applications regardless of their location. That means Windows Azure applications and SQL Azure databases can connect to applications across organizational boundaries and firewalls, with a variety of connection and configuration options. This gives partners and customers the flexibility and freedom to deploy applications in the locations that make sense for their business.
Windows Azure offers four unique instance sizes: small, medium, large, and extra-large. The smallest instance in the AWS offering is 32-bit, whereas all instances in Windows Azure are 64-bit. Further, the smallest instance of Windows Azure has more processing capability (1.4-1.6Ghz) relative to AWS’s smallest instance (1.1-1.2 Ghz). Google App Engine does not offer any flexibility in instance sizes.
First, Amazon is an IaaS provider, whereas the Windows Azure platform is a PaaS offering from Microsoft. That means, capabilities such as the operating system, database, load balancing, backup, automated service management, auto high availability, physical administration, integrated development environment, and monitoring are built into the Windows Azure platform.
Second, Amazon has multi-tiered pricing for its various AWS offerings. Based on publicly available data and customer conversations, it’s clear that most customer needs map to the higher Amazon pricing tiers. The Windows Azure pricing is lower as compared to many of these higher Amazon price points. Instead of adding the complexity of multiple tiers, we give our customers flat pricing based on their consumption of compute, storage, data transfers etc. As a design principle, we’ve reduced the complexity around multiple standalone meters - E.g. While Amazon EC2 has 9 meters to track usage, Windows Azure has only 4. These pricing meters are consistent across the different instance sizes for Windows Azure. SQL Azure has only one simple meter and is priced per Database per month for both Web and Business Edition. Developers using Amazon’s hosted database pay for VM instance uptime independent of actual database usage. Since VMs are not persistent, databases need to be persisted in an external storage that is billed separately. Additionally, developers would incur additional cost for database backup and replication. We also have special pricing in place to drive partner participation and development.
The Windows Azure platform pricing is comparable with that of Google AppEngine (GAE) on storage and data transfers. Our storage transaction fee is more favorable than GAE’s storage execution fee. GAE is also not favorable in the pricing as it’s not backed by a service level agreement. GAE does not offer any relational database service. SQL Azure offers a relational database service that has only one simple meter and is priced per Database per month for both Web and Business Edition.
Unlike Amazon’s SimpleDB, SQL Azure Database offers you the familiarity of developing against a traditional relational database model using T-SQL and provides you with the benefits associated with this model like powerful and familiar querying experience, tools and knowledge base.
On Oct 27, 2009, Amazon announced beta availability of their new “Relational Database Service (Amazon RDS)”. The service offers MySQL 5.1 hosted “in the cloud”, with limited management of the database (backups and patches), and charging per database compute time. Amazon offers the full MySQL capabilities, so existing MySQL 5.1 based applications, tools and code can run unchanged in Amazon. Customers need to use Amazon “Cloudwatch” to monitor, manage and grow their instances. Amazon is positioning the service for both developers and companies that use MySQL, and highlights benefits such as simple to deploy, managed, compatible, scalable, reliable, works with other Amazon services, secure and inexpensive.
SQL Azure offers a self- managed database with the following key significant advantages:

Windows Azure and Windows Server are different platforms designed to work together easily so that customers have choice about the platform that most directly addresses their business needs. Windows Azure and Windows Server share some technologies and will share some innovations bilaterally. For instance, a customer can use their existing Active Directory infrastructure to provide user access to a Windows Azure application.
Although Windows Server and Windows Azure at-times will address overlapping application workloads, one is an operating system with a software licensing model while the other is a cloud operating system as a service, running in Microsoft’s global datacenters, available in pay-as-you go or commitment rate plan models to developers and customers. These offerings provide our customers with the flexibility to choose the platform and business model best suits their technology needs.
Windows Server is an enterprise-class operating system that addresses a broad set of on-premises scenarios including core infrastructure workloads (print, security, networking, etc.), web applications, business applications and scenarios where on-premises IT infrastructure is needed to full-fill regulatory, data privacy, or performance requirements. Windows Server is not a service offering and is not based on a pay-as-you-go consumption model. Windows Server is licensed per server or per processor and covers an extensive class of server hardware that customers can run in their own datacenters or on a server hosted by one of our thousands of Service Provider/Hosting partners.
Windows Azure is a scale-out platform service that provides customers with on-demand compute and storage to develop, host, scale, and manage applications that span from consumer web to enterprise scenarios in Microsoft® data centers. Windows Azure provides a unique platform for applications and services because it enables simplified development of highly available and scalable applications and automates scale management of both the application and the underlying infrastructure.
Because Windows Azure abstracts hardware and operating system management, customers and partners can focus on their core competence of building solutions as opposed to procuring, managing, patching, and licensing hardware, virtual machines, operating systems, and applications platform software.
Although Windows Azure and Windows Server are separate platforms, the goal would be to allow seamless inter-operability of applications and services between the two environments over a period of time so that customers have the flexibility to choose the platform and business model that best suits their needs.
Because these are different products – one is an operating system, the other is a cloud service – the two products cannot be compared based on price. Windows Server is purchased via a software license. In contrast, Windows Azure is a cloud service whose pricing reflects costs associated with server hardware, software, network bandwidth, storage and the management of the hardware running Windows Azure. We have designed each offering to offer customers the flexibility to choose the platform and business model that best suits their needs
Because these are different products – one is an operating system, the other is a cloud service – the two products cannot be easily compared based on price. Windows Server is purchased via a software license. In contrast, Windows Azure is a cloud service whose pricing reflects costs associated with server hardware, software, network bandwidth, storage and the management of the hardware running Windows Azure. We have designed each offering to offer customers the flexibility to choose the platform and business model that best suits their needs.
Some Windows Azure ASP.NET and PHP applications that utilize SQL Azure can be easily ported to run on Windows Server. Other applications may need some re-architecting to run on Windows Server on-premises or at a hoster. E.g. Applications that take advantage of Windows Azure APIs and blob storage will need to be refactored to run on Windows Server. SQL Azure supports existing T-SQL based relational model over TDS Proxy, hence existing custom application and LOB packaged applications can easily extend to the cloud with minimal changes to the solution
No. We do not currently allow Windows Server license mobility. We are evaluating this request from our customers and partners.
Microsoft currently offers the Dynamic Infrastructure Toolkit for Hosters that enables our hosting partners to build private clouds (including higher server utilization via a virtualization fabric, more automated management, self-service provisioning portals) by leveraging Hyper-V, Live Migration, Windows Server 2008 R2, and System Center Virtual Machine Manager. In 2010, Microsoft will release a version of Dynamic Infrastructure Toolkit for Enterprises to enable customers to deploy private clouds within their datacenters.
With future releases of Windows Server, System Center, and Hyper-V, Microsoft will incorporate the innovations from Windows Azure. We already see boot-from-VHD in Windows Server 2008 R2. So overtime, our customers and hosting partners will be able to build private clouds based on the same technologies that underlie Windows Azure.
No. Windows Azure is a cloud operating system delivered as a service that is separate from Windows Server. Windows Azure is a scale-out platform service that provides customers with on-demand compute and storage to develop, host, scale, and manage applications in Microsoft® data centers. Although Windows Azure, Windows Server and System Center products have different development organizations, they are on parallel code paths and actively sharing new innovations developed by Microsoft—such as Boot-from-VHD and Microsoft’s new application server technology Windows Server AppFabric.
Microsoft provides customers the flexibility to use on-premises technology, cloud technology or both, as part of its software-plus-services (S+S) strategy. Customers have expressed a strong interest in having the flexibility to picking deployment options as their business needs dictate. Microsoft will continue to invest heavily, to innovate and to ship new versions of Windows Azure, SQL Azure, Windows Server, SQL Server and System Center to ensure that customers can have the benefit of cloud computing technologies whether their applications are running in their own datacenters, in a Microsoft Hosting partner’s datacenter or on Windows Azure.

Windows Azure and the Windows Azure Platform, the cloud-based service foundation underlying it, enable the transition to global scale computing with cloud-based developer capabilities. Windows Azure is hosted on servers operating within Microsoft’s global data center network. This provides developers the ability to deploy applications in the cloud or on-premises and enables experiences across a broad range of business and consumer scenarios.
The Windows Azure Platform and Windows Azure apply the rigorous security practices incorporated in the Security Development Lifecycle (SDL) process. SDL introduces security and privacy early and throughout the development process. The Windows Azure Platform and Windows Azure also benefit from the security capabilities afforded by the Microsoft Global Foundation Services’ infrastructure. The GFS assurances are validated by external auditors on a regular basis and include a comprehensive security program that covers the entire delivery stack.
The delivery of online services is a fairly new business model. We frequently engage with Washington State and local officials to identify ways the state can offer a competitive business climate for mega datacenter investments in the state. Microsoft continues to be committed to our business in the state of Washington and the data center in Quincy.
Because technology tends to drive economic growth, there is competition for business among states in the data center and online services markets today, with tax and other incentives being offered, and this is certainly true of the states in which Microsoft currently has mega data center commitments and investments. For example, both Texas and Illinois offer significant property tax incentives for data center operators today; Iowa offers property tax incentives as well as sales tax exemptions for all data center equipment.
At commercial launch, Windows Azure will not have specific audit or security certifications. You can expect to see us pursue key certifications, such as the ISO27001, in the near future. The Windows Azure Platform and Windows Azure apply the rigorous security practices incorporated in the Security Development Lifecycle (SDL) process. SDL introduces security and privacy early and throughout the development process. The Windows Azure Platform and Windows Azure also benefit from the security capabilities afforded by the Microsoft Global Foundation Services’ infrastructure. The GFS assurances are validated by external auditors on a regular basis and include a comprehensive security program that covers the entire delivery stack.
