In the past three and a half years, Amazon CloudFront has changed the content delivery landscape. It has demonstrated that a CDN does not have to be complex to use with expensive contracts, minimum commits, or upfront fees, such that you are forcibly locked into a single vendor for a long time. CloudFront is simple, fast and reliable with the usual pay-as-you-go model. With just one click you can enable content to be distributed to the customer with low latency and high-reliability.

Today Amazon CloudFront has taken another major step forward in ease of use. It now supports delivery of entire websites containing both static objects and dynamic content. With these features CloudFront makes it as simple as possible for customers to use CloudFront to speed up delivery of their entire dynamic website running in Amazon EC2/ELB (or third-party origins), without needing to worry about which URLs should point to CloudFront and which ones should go directly to the origin.

Dynamic Content Support

Recall that last month the CloudFront team announced lowering the minTTL customers can set on their objects, down to as low as 0 seconds to support delivery of dynamic content. In addition to the TTLs, customers also need some other features to deliver dynamic websites through CloudFront. The first set of features that CloudFront is launching today include:

Multiple Origin Servers: the ability to specify multiple origin servers, including a default origin, for a CloudFront download distribution. This is useful when customers want to use different origin servers for different types of content. For example, an Amazon S3 bucket can be used as the origin for static objects and an Amazon EC2 instance as the origin for dynamic content, all fronted by the same CloudFront distribution domain name. Of course non-AWS origins are also permitted.

Query String based Caching: the ability to include query string parameters as part of the object's cache key. Customers will have a switch to turn query strings 'on' or 'off'. When turned off, CloudFront's behavior will be the same as today - i.e., CloudFront will not pass the query string to the origin server nor include query string parameters as a part of the object's cache key. And when query strings are turned on, CloudFront will pass the full URL (including the query string) to the origin server and also use the full URL to uniquely identify an object in the cache.

URL based configuration: the ability to configure cache behaviors based on URL path patterns. Each URL path pattern will include a set of cache behaviors associated with it. These cache behaviors include the target origin, a switch for query strings to be on/off, a list of trusted signers for private content, the viewer protocol policy, and the minTTL that CloudFront should apply for that URL path pattern. See the graphic at the end of this post for an example configuration.

More new features

In addition to these features, there are other things the CloudFront team has achieved to speed up delivery of content, but all customer will get these benefits by default without additional configuration. These performance optimizations are available for all types of content (static and dynamic) delivered via CloudFront. Specifically:

Optimal TCP Windows. The TCP initcwnd has been increased for all CloudFront hosts to maximize the available bandwidth between the edge and the viewer. This is in addition to the existing optimizations of routing viewers to the edge location with lowest latency for that user, and also persistent connections with the clients.

Persistent Connection to Origins. Connections are improved from CloudFront edge locations to the origins by maintaining long-lived persistent connections. This helps by reducing the connection set-up time from the edge to the origin for each new viewer. When the viewer is far away from the origin, this is even more helpful in minimizing total latency between the viewer and the origin.

Selecting the best AWS region for Origin Fetch. When customers run their origins in AWS, we expect that our network paths from each CloudFront edge to the various AWS Regions will perform better with less packet loss given that we monitor and optimize these network paths for availability and performance. In addition, we have shown an optional configuration in the architecture diagram how developers can use Route 53’s LBR (Latency Based Routing) to run their origin servers in different AWS Regions. Each CloudFront edge location will then go to the “best” AWS Region for the origin fetch. And Route 53 already understands very well which CloudFront host is in which edge location (this is integration we’ve built between the two services). This helps improve performance even further.

Amazon CloudFront is expanding it functionality and feature set at an incredible pace. I am particularly excited about these features that help customers deliver both static and dynamic content through one distribution. CloudFront stays true to its mission in making a Content Delivery Network dead simple to use, and now they also do this for dynamic content.

For more details, see the CloudFront detail page and the posting on the AWS developer blog.

Invention comes in many forms and at many scales. The most radical and transformative of inventions are often those that empower others to unleash their creativity – to pursue their dreams.

Hundreds of thousands of businesses in over 190 countries are relying on AWS to support some or all of their business and IT needs. From SAP and Oracle production installations to risk management HPC, from Internet banking to protein folding, from social gaming to mobile collaboration tools, from video distribution to hotel reservations systems, supply chain management and medical archiving, the list of what our customers achieve using the AWS cloud is fascinating. Many of our customers will tell you that although the cost savings that AWS brings them are important, more important is that they are able to be more agile, that they are able to move faster in a world with murderous competition and highly compressed time-to-markets. They will tell you that because of the new resource models they are able to reinvent the way they are doing business and have entered into a new world where they are no longer constrained by access to resources and can focus their best people on adding value to the customer instead of managing infrastructure.

We want to help businesses to continue to reinvent themselves by sharing our experiences, sharing our great customer and partner’s stories, and to present our vision for the future. AWS re: Invent is our inaugural global customer and partner conference that will be held November 27-29 at The Venetian in Las Vegas. Well over 100 sessions from deep technical workshops to strategy sessions for executives, there will high quality content for everyone. And enough food for thought for everyone about how to continue to reinvent...

Save the date, and watch this page for more details.

The software that powers today’s world of Internet services has become incredibly diverse. Today’s announcement of Amazon RDS for Microsoft SQL Server and .NET support for AWS Elastic Beanstalk marks another important step in our commitment to increase the flexibility for AWS customers to use the choice of operating system, programming language, development tools and database software that meet their application requirements.

Using the AWS Toolkit for Visual Studio, you can now deploy your .NET applications to AWS Elastic Beanstalk directly from your Visual Studio environment without changing any code. You can then off load the management and scaling of your database and application stack to Amazon RDS and AWS Elastic Beanstalk, and focus on adding value to your customers.

Amazon RDS for SQL Server

Managing databases has been a stumbling block for many of our customers, shifting their time away from developing innovative applications to the “muck” of administrative tasks such as OS and database software patching, storage management, and implementing reliable backup and disaster recovery solutions. Amazon RDS manages all these time consuming database administration tasks including patch management, striping the storage for better performance, and database and log backups for disaster recovery, enabling developers to focus more on their applications.

Since we launched Amazon RDS for MySQL in October 2009, it has become one of the most popular services on AWS, with customers such as Intuit using the service to keep up with the steep increase in traffic during the tax season. We introduced Amazon RDS for Oracle last year, and based on the demand from our Windows customers, are introducing Amazon RDS for SQL Server today. Amazon RDS currently supports SQL Server 2008 R2 and plans to add support for SQL Server 2012 later this year.

Depending on your requirements, you can choose from four different SQL Server Editions: Express, Web, Standard and Enterprise to run on Amazon RDS. If you are a new Amazon RDS customer, you can get started with Amazon RDS for SQL Server with a Free Usage Tier, which includes 750 hours per month of Amazon RDS micro instances with SQL Server Express Edition, 20GB of database storage and 10 million I/O requests per month.

After the Free Usage Tier, you can run Amazon RDS for SQL Server under two different licensing models - "License Included" and Microsoft License Mobility. Under the License Included service model, you do not need to purchase SQL Server software licenses. “License Included” pricing starts at $0.035/hour and is inclusive of SQL Server software, hardware, and Amazon RDS management capabilities. The Microsoft License Mobility program allows customers who already own SQL Server licenses to run SQL Server deployments on Amazon RDS. This benefit is available to Microsoft Volume Licensing customers with SQL Server licenses covered by active Microsoft Software Assurance contracts. The Microsoft License Mobility program is suited for customers who prefer to use existing SQL Server licenses or purchase new licenses directly from Microsoft.

.NET support for Elastic Beanstalk

In our effort to let a thousand platforms bloom on AWS, I am excited to introduce .NET support for AWS Elastic Beanstalk. Elastic Beanstalk gives developers an easy way to quickly build and manage their Java, PHP and as of today, their .NET applications in the AWS cloud. As discussed here, Elastic Beanstalk targets both application developers by providing a simple set of tools to get started with development quickly and the platform developers by giving control over the underlying technology stack. Developers simply upload their application and Elastic Beanstalk automatically creates the AWS resources and application stack needed to run the application, freeing developers from worrying about server capacity, load balancing, scaling their application, and version control.

Using the AWS Toolkit for Visual Studio, developers can now deploy their .NET applications directly to Elastic Beanstalk, without leaving their development environment. The incremental deployment capabilities allow for quick development and testing cycles by only uploading modified files. Within seconds, new application versions get updated on a set of Amazon EC2 instances.

To get started with Amazon RDS for SQL Server and AWS Elastic Beanstalk, visit http://aws.amazon.com/rds/sqlserver and http://aws.amazon.com/elasticbeanstalk. For a hands-on demo on how to deploy .NET applications on Elastic Beanstalk with Amazon RDS for SQL Server, visit the AWS Elastic Beanstalk Developer Guide.