You can also use this feature to browse through your production data. You can access the data for reporting or analytic purposes, again without having to write any code.

Here's a tour to help you get started:

Select a table and click Explore Table:

You can scan through the table, ten items at a time, using the button controls:

You can also retrieve items by hash or range keys, as appropriate:

Last but not least, you can put new items. Since DynamoDB doesn't use a database schema, you have full control of the attributes associated with each item:

You can specify the type of each attribute:

Editing sets of strings or numbers is easy and straightforward:

-- Jeff;

Stay tuned for another exciting week!

-- Jeff;

With this update, you can add a new listener with a front-end protocol/port and back-end protocol/port:

If the listener uses encryption (HTTPS or SSL listeners), then you can create or select the SSL certificate:

In addition to selecting or creating the certificate, you can now update the SSL protocols and ciphers presented to clients:

We have also expanded IPv6 support for Elastic Load Balancing to include the US West (Northern California) and US West (Oregon) regions.

-- Jeff;

Amazon RDS removes the headaches of running a relational database reliably at scale, allowing Amazon RDS customers to focus on innovation for their customers. Read Replicas enables you to elastically scale out beyond the capacity constraints of a single DB Instance for read-heavy database workloads.

You can now create one or more replicas of a given “source” DB Instance and serve incoming read traffic from multiple copies of your data within a VPC environment. You can create a Read Replica with a few clicks of the AWS Management Console or using the CreateDBInstanceReadReplica API.

Amazon VPC allows you to customize the network configuration to closely resemble a traditional network that you might operate in your own datacenter. I described the process of launching a DB Instance inside of a VPC in an earlier post.

Amazon RDS in VPC enables you to have a DB instance within a private network powering a public web application. The DB instance is on a private subnet, which does not have a public IP address. You can also use Amazon RDS + VPC to run corporate applications that are not intended to be accessed from the Internet.

-- Jeff;

Using our new Categorization App, you can start categorizing your own items or data in minutes, eliminating the learning curve that has traditionally accompanied this type of activity. The app includes everything that you need to be successful including:

1. Predefined HITs (no HTML editing required).
2. Pre-qualified Master Workers (see Jinesh's previous blog post on Mechanical Turk Masters).
3. Price recommendations based on complexity and comparable HITs.
4. Analysis tools.

The Categorization App guides you through the four simple steps that are needed to create your categorization project.

First, you create the project, assign a name to it, and enter the question that you want to ask of the workers.

Next, you provide the categories that the Master Workers will use. You simply enter the names and the App will generate the HTML for you. You also have the opportunity to supply instructions as part of the step.

The next step is to upload the data to be categorized. You simply upload a CSV file and select the fields that you'd like the Workers to see. If one of your fields contains links to images to be displayed as part of the HIT, you can also set that up in this step.

Finally, you review the pricing information and the total cost for your HIT. Once everything looks good, you go ahead and Publish the HITs and await the results.

Two Master Workers will handle each HIT. After the Workers have finished all of the HITs in the project, you can use the Result Analysis tools to see a summary of the results. You'll be able to see how often both of the Master Workers agreed on a categorization, and how often they disagreed. You can also download the actual categorization data for each of your items.

Read more about this feature on the Mechanical Turk Blog.

-- Jeff;

With Elastic Beanstalk, you retain full control over the resources running your application and you can easily manage and adjust settings to meet your needs. Because Elastic Beanstalk leverages services like Amazon EC2 and Amazon S3, you can run your application on the same highly durable and highly available infrastructure.

Elastic Beanstalk automatically scales your application up and down based on default Auto Scaling settings. You can easily adjust Auto Scaling settings based on your specific application's needs.

You have your choice of three separate development languages and tools when you use Elastic Beanstalk:

• Java - AWS SDK for Java and the AWS Toolkit for Eclipse.
• PHP - AWS SDK for PHP and deployment via Git.
• .NET  - AWS SDK for .NET and the AWS Toolkit for Visual Studio.

To get started with Elastic Beanstalk, visit the AWS Elastic Beanstalk Developer Guide.

I should mention that we are looking for highly motivated software developers and product managers who want to work on leading edge, highly scaled services such as AWS CloudFormation and AWS Elastic Beanstalk. If you are interested, send us your resume to aws-cloudformation-jobs at amazon.com or aws-elasticbeanstalk-jobs at amazon.com. Come and help us make history!

-- Jeff;

PS - I recently interviewed Saad Ladki of the Elastic Beanstalk team on The AWS Report. You can watch the video to learn more about Elastic Beanstalk and how our customers are putting it to use.

As I described in my introductory post (Introducing the Amazon Simple Email Service), you must verify the email address (or addresses) that you plan to use to send messages. The initial verification process must be repeated for each email address.

Today we are introducing a new SES feature. You can now verify an entire domain, and then send email from any address in that domain. In addition to saving you time and effort, this new feature now allows you to use Amazon SES in situations where you don't accept email at the From address, or when you don't know the From address ahead of time.

 You verify a domain by creating a TXT record in the domain's DNS record using information that we provide you as part of the domain verification process. Most (not all) DNS providers allow you to create TXT records. 

If you are using Amazon Route 53 to provide DNS service for your domain, the process is very straightforward; you can verify the domain using the AWS Management Console. Here's a tour...

The first step is to visit the SES tab of the console and add your domain to the Domains tab in the Verified Senders section:

If you are not using Route 53, the next step is to update your domain's DNS settings using the TXT record information displayed in the console:

If you are using Route 53, push the Use Route 53 button and select the domains and subdomains that you want to verify:

Either way (Route 53 or your own DNS provider), Amazon SES will verify your domain within 72 hours. Once the domain has been verified, you'll receive an email and the domain will be marked as "verified" in the console.

You can now send email from any address in the domain!

If you would like to learn more about domain verification, please sign up for the June 12th webinar: Using Domain Verification with Amazon Simple Email Service. The webinar is free but space is limited!

We have also changed the limit on the number of verified addresses and domains allowed per AWS account from 100 to 1000. 

-- Jeff;

Our customers are using these services to implement cloud-based backup, disaster recovery, and archiving for entire enterprises.

In order to help you make sense of all of these options and to give you a better sense of how AWS can help you, we have created a day-long event devoted to cloud storage for the enterprise.

The AWS Cloud Storage for the Enterprise event will take place on June 6th in New York, and will run from 10:00 AM to 5:30 PM. In addition to keynotes from Stephen Schmidt (Vice President, Security Engineering and Chief Information Security Officer for AWS) and Matt Tavis (AWS Solutions Architect), you will get to hear directly from AWS customers. Stephen will focus on the all-important question of data security in the cloud, and Matt will discuss the ways in which the cloud is transforming the storage strategies that our enterprise customers are putting in to play.

They'll also coever some lesser-known topics such as cloud-as-a-tier, NAS-like functionality with the cloud, long term data archiving with high performance record retrieval, high speed data transfer in and out.

The event is free, but you will need to register.

-- Jeff;

Stay tuned for another exciting week!

-- Jeff;

Today we are introducing a set of features that, taken together, allow you to use CloudFront to serve dynamic, personalized content more quickly.

What is Dynamic Personalized Content?
As you know, content on the web is identified by a URL, or Uniform Resource Locator such as http://media.amazonwebservices.com/blog/console_cw_est_charge_service_2.png . A URL like this always identifies a unique piece of content.

A URL can also contain a query string. This takes the form of a question mark  ("?") and additional information that the server can use to personalize the request. Suppose that we had a server at www.example.com, and that can return information about a particular user by invoking a PHP script that accepts a user name as an argument, with URLs like http://www.example.com/userinfo.php?jeff or http://www.example.com/userinfo.php?tina.

Up until now, CloudFront did not use the query string as part of the key that it uses to identify the data that it stores in its edge locations.

We're changing that today, and you can now use CloudFront to speed access to your dynamic data at our current low rates, making your applications faster and more responsive, regardless of where your users are located.

With this change (and the others that I'll tell you about in a minute), Amazon CloudFront will become an even better component of your global applications. We've put together a long list of optimizations that will each increase the performance of your application on their own, but will work even better when you use them in conjunction with other AWS services such as Route 53, Amazon S3, and Amazon EC2.

Tell Me More
Ok, so here's what we've done:

Persistent TCP Connections - Establishing a TCP connection takes some time because each new connection requires a three-way handshake between the server and the client. Amazon CloudFront makes use of persistent connections to each origin for dynamic content. This obviates the connection setup time that would otherwise slow down each request. Reusing these "long-haul" connections back to the server can eliminate hundreds of milliseconds of connection setup time. The connection from the client to the CloudFront edge location is also kept open whenever possible.

Support for Multiple Origins - You can now reference multiple origins (sources of content) from a single CloudFront distribution. This means that you could, for example, serve images from Amazon S3, dynamic content from EC2, and other content from third-party sites, all from a single domain name. Being able to serve your entire site from a single domain will simplify implementation, allow the use of more relative URLs within the application, and can even get you past some cross-site scripting limitations.

Support for Query Strings - CloudFront now uses the query string as part of its cache key. This optional feature gives you the ability to cache content at the edge that is specific to a particular user, city (e.g. weather or traffic), and so forth. You can enable query string support for your entire website or for selected portions, as needed.

Variable Time-To-Live (TTL) - In many cases, dynamic content is either not cacheable or cacheable for a very short period of time, perhaps just a few seconds. In the past, CloudFront's minimum TTL was 60 minutes since all content was considered static. The new minimum TTL value is 0 seconds. If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. It will then make a GET request with an If-Modified-Since header, thereby giving the origin a chance to signal that CloudFront can continue to use the cached content if it hasn't changed at the origin.

Large TCP Window - We increased the initial size of CloudFront's TCP window to 10 back in February, but we didn't say anything at the time. This enhancement allows more data to be "in flight" across the wire at a given time, without the usual waiting time as the window grows from the older value of 2.

API and Management Console Support - All of the features listed above are accessible from the CloudFront APIs and the CloudFront tab of the AWS Management Console. You can now use URL patterns to exercise fine-grained control over the caching and delivery rules for different parts of your site.

Of course, all of CloudFront's existing static content delivery features will continue to work as expected. GET and HEAD requests, default root object, invalidation, private content, access logs, IAM integration, and delivery of objects compressed by the origin.

Working Together
Let's take a look at the ways that various AWS services work together to make delivery of static and dynamic content as fast, reliable, and efficient and possible (click on the diagram at right for an even better illustration):

• From Application / Client to CloudFront - CloudFront’s request routing technology ensures that each client is connected to the nearest edge location as determined by latency measurements that CloudFront continuously takes from internet users around the world. Route 53 may be optionally used as a DNS service to create a CNAME from your custom domain name to your CloudFront distribution. Persistent connections expedite data transfer.
• Within the CloudFront Edge Locations - Multiple levels of caching at each edge location speed access to the most frequently viewed content and reduce the need to go to your origin servers for cacheable content.
• From Edge Location to Origin - The nature of dynamic content requires repeated back and forth calls to the origin server. CloudFront edge locations collapse multiple concurrent requests for the same object into a single request. They also maintain persistent connections to the origins (with the large window size). Connections to other parts of AWS are made over high-quality networks that are monitored by Amazon for both availability and performance. This monitoring has the beneficial side effect of keeping error rates low and window sizes high.

Cache Behaviors
In order to give you full control over query string support, TTL values, and origins you can now associate a set of Cache Behaviors with each of your CloudFront distributions. Each behavior includes the following elements:

• Path Pattern - A pattern (e.g. "*.jpg") that identifies the content subject to this behavior.
• Origin Identifier -The identifier for the origin where CloudFront should forward user requests that match this path pattern.
• Query String - A flag to enable support for query string processing for URLs that match the path pattern.
• Trusted Signers - Information to enable other AWS accounts to create signed URLs for this URL path pattern.
• Protocol Policy - Either allow-all or https-only, also applied only to this path pattern.
• MinTTL - The minimum time-to-live for content subject to this behavior.

Tool Support
Andy from CloudBerry Lab sent me a note to let me know that they have added dynamic content support to the newest free version of the CloudBerry Explorer for Amazon S3.  In Andy's words:

I'd like to let you know that CloudBerry Explorer is ready to support new CloudFront features by the time of release.  We have added the ability to manage multiple origins for a distribution, configure cache behavior for each origin based on URL path patterns and configure CloudFront to include query string parameters.

You can read more about this in their new blog post, How to configure CloudFront Dynamic Content with CloudBerry S3 Explorer .

Andy also sent some screen shots to show us how it works. The first step is to specify the Origins and CNAMEs associated with the distribution:

The next step is to specify the Path Patterns:

With the Origins and Path Patterns established, the final step is to configure the Path Patterns:

Update: Tej from Bucket Explorer wrote in to tell me that they are now supporting this feature:

Hi, I am one of the developer of Bucket Explorer. I am excited to announce that Bucket Explorer new version is supporting CloudFront Dynamic Content feature. Try Its 30 day trial version with full featured. Dynamic Content (Steps and Images).

And Here You Go
Together with CloudFront's cost-effectiveness (no minimum commits or long-term contracts), these features add up to a content distribution system that is fast, powerful, and easy to use.

So, what do you think? What kinds of applications can you build with these powerful new features?

-- Jeff;

PS - Read more about this new feature in Werner's new post: Dynamic Content Support in Amazon CloudFront.