Today, I spoke at the Citrix Synergy 2011 Conference in San Francisco where they announced Citrix's Support for XenApp - On-demand Application Delivery Solution - on Amazon Web Services Cloud. I am particularly excited about this announcement because now you can spin up a Secure XenApp Farm in the cloud within minutes that instantly delivers Windows Applications as-a-service to users anywhere on any device. It leverages the CloudFormation template that kicks off PowerShell scripts and launches the pre-configured Windows AMIs in Amazon VPC subnet.

One of their principal architects blogged about this automated setup on Citrix's community blog. The blog also embeds a video that shows how quickly you can setup a XenApp farm in the AWS Cloud using a simple JSON file, shows the the private and public subnets in Amazon VPC, and the various security groups settings and configurations.

We are looking forward to a strategic partnership with Citrix so that will allow Citrix customers to take advantage of of the cloud and AWS customers to take advantage of the Citrix Applications. If you are a Citrix customer and would like to take advantage of the cloud, we would love to hear back from you.

You can use a new alias feature to map the root or apex of your hosted zone to your Elastic Load Balancer.

Route 53 is now considered Generally Available, and now has a Service Level Agreement, or SLA.

You can now provide multiple answers to a single DNS question using a Weighted Round Robin model.

Aliases and the Zone ApexA number of our customers use an Elastic Load Balancer in front of a fleet of EC2 instances. The EC2 instances host the web tier of their application. Unfortunately, due to the way that the DNS protocol works, there was no way to refer to the Elastic Load Balancer from the root (also known as the apex) of the domain. In Plain English, you could create a DNS entry that maps http://www.example.com to an Elastic Load Balancer but you couldn't do the same for http://example.com.

Because short, memorable URLs are always desirable, we've created a new aliasing system for Route 53. You can now map the apex of a hosted zone to an Elastic Load Balancer using an Alias record. When Route 53 encounters an Alias record, it looks up the A records associated with the target DNS name in the Alias, and returns the IP addresses from that name.

The DNS entries associated with an Elastic Load Balancer have a short (60 second) time to live, or TTL. This means that changes to the entries will be recognized and respected as quickly as possible. In order to allow all of our customers to benefit from this new feature, there is no charge for queries to alias records when the target is an Elastic Load Balancer (the only allowable target in this release).

General Availability and SLAWe launched Route 53 in beta form in December of 2010. Developers all over the world have eagerly adopted Route 53 and it now provides DNS services for a multitude of websites. The service is now officially generally available. The Route 53 Service Level Agreement offers 100% availability (measured at 5 minute intervals) and provides service credits as follows:

A one day credit for 5-30 minutes of unavailability.

A one week credit for 31 minutes to 4 hours of unavailability.

A one month credit for more than 4 hours of unavailability.

Weighted Round RobinA primary task of a DNS service like Route 53 is to answer the question "What is the IP address associated with this name?" You can now provide multiple answers for a name, and you can also control the relative frequency with which each one is used. This model is called Weighted Round Robin (WRR) DNS. You can use this new feature to implement a variety of different scenarios. For example, you could route different amounts of traffic to EC2 instances with varied amounts of processing power. Or, you could do some A/B or functional testing.

We've added three new features to EC2's Elastic Load Balancing feature:

IPv6 Support - All Elastic Load Balancers in the US East (Northern Virginia) and EU (Ireland) regions now have publicly routable IPv6 addresses in addition to their existing IPv4 addresses.

Zone Apex Support - You can now point the root or apex of your Route 53 hosted zone to your Elastic Load Balancer.

EC2 Security Group Support - You can now configure an EC2 Security Group for your application instances such that they accept traffic only from an Elastic Load Balancer.

Here's the scoop:

IPv6 SupportYou've probably read some panic-inducing articles about the fact that the Internet is running out of IP addresses! In order to support the continued growth in the number of devices connected to the Internet, it will soon become necessary to use a new version of the IP protocol, commonly known as IPv6. This version of the protocol raises the theoretical limit on the number of devices to an incredible 2128, and also lays the groundwork for other capabilities in the future.

The migration from IPv4 to IPv6 is now underway across the globe. This migration creates many technical and challenges for all concerned. We're providing this new support in order to allow you to test your systems on World IPv6 day (June 8, 2011).

IPv6 support is available in the US East (Northern Virginia) and EU (Ireland) regions to start.

If you currently use a CNAME to map your domain name to your Elastic Load Balancer, you can use one of two new domain names for your Elastic Load Balancer. The ipv6 DNS name will resolve to an AAAA record and can be used to test an IPv6 client. The dualstack name will return both A and AAAA records and can be used when some clients speak IPv4 and others speak IPv6.

If you use Route 53 to handle your DNS needs, you can create the appropriate alias records from your DNS name to the Elastic Load Balancer to support IPv4, IPv6, or both.

Your application can check the X-Forwarded-For header to see if it has been accessed by way of an IPv6 address.

Zone Apex SupportAs described in my post on new Route 53 features, you can now map the root or apex of your hosted zone to your Elastic Load Balancer. You can now host a web site using an Elastic Load Balancer at http://example.com just as easily as you can have one at http://www.example.com .

EC2 Security Group SupportYou can now configure EC2 instances sitting behind an Elastic Load Balancer to receive traffic only from the Load Balancer by using a special Security Group associated with the Elastic Load Balancer. To do this, you call the DescribeLoadBalancers API to get the name of the Security Group, and then include that group in the group list when you subsequently launch some EC2 instances. The name of the Security Group can also be obtained from the load balancer details pane in the AWS Management Console.

These features were motivated, in part, by requests from our customers. We love to get feedback. Please feel free to post yours to the appropriate AWS forum or as a comment to this post.

A few months ago I told you that we were planning to support Oracle Database 11g (Release 2) via the Relational Database Service (RDS). That support is now ready to go, and you can start launching Database Instances today.

We've set this up so that you have lots of choices and plenty of flexibility to ensure a good operational and licensing fit. Here are the choices that you get to make:

Database Edition

Standard Edition One

Standard Edition

Enterprise Edition

License Model

Bring Your Own License (all editions)

License Included (Standard Edition One)

Instance Class

Small

Large

High-Memory Extra Large

High-Memory Double Extra Large

High-Memory Quadruple Extra Large

Pricing Options

On-Demand DB Instances

Reserved DB Instances

If you already have the appropriate Oracle Database licenses you can simply bring them in to the cloud. You can also launch Standard Edition One DB Instances with a license included at a slightly higher price.

The AWS Management Console's Launch DB Instance Wizard will lead you through all of the choices, starting from the database engine and edition:

If you select an Oracle database engine, you can choose your license model:

And your engine version:

All of the instances are preconfigured with a sensible set of default parameters that should be more than sufficient to get you started. You can use the RDS DB Parameter Groups to exercise additional control over a large number of database parameters.

As is generally the case with AWS, we'll be adding even more functionality to this service in the months to come. Already on the drawing board is support for enhanced fault tolerance.

We have also added a new feature to the console that will make it easier for you to see the range of options available to you when you use RDS. Just click on Orderable DB Options to see which database engines, versions, instance classes, and options are available to you in each Region and Availability Zone:

When I demonstrate Amazon RDS to developers I get the sense that it really changes their conception of what a database is and how they can use it. They enter the room thinking of the database as a static entity, one that they create once in a great while and leave thinking that they can now create databases on a dynamic, as-needed basis for development, experimentation, testing, and the like.

It includes a description of the shared responsibility model, a summary of our control environment, a review of secure design principles, and detailed information about the security and backup considerations related to each part of AWS including the Virtual Private Cloud, EC2, and the Simple Storage Service.

The new AWS Risk and Compliance White Paper covers a number of important topics including (again) the shared responsibility model, additional information about our control environment and how to evaluate it, and detailed information about our certifications and third-party attestations. A section on key compliance issues addresses a number of topics that we are asked about on a regular basis.

The AWS Security team and the AWS Compliance team are complimentary organizations and are responsible for the security infrastructure, practices, and compliance programs described in these white papers. The AWS Security team is headed by our Chief Information Security Officer and is based outside of Washington, DC. Like most parts of AWS, this team is growing and they have a number of open positions:

You can now store your business and application metrics in Amazon CloudWatch. You can view graphs, set alarms, and initiate automated actions based on these metrics, just as you can for the metrics that CloudWatch already stores for your AWS resources.

This new custom metrics feature can be used in two different ways:

You can add to the metrics collected for Amazon EC2 Instances, EBS Volumes, Elastic Load Balancers, and Relational Database Service DB Instances. The metrics that you store can be technical (system performance indicators) or business-related (user activity over the monitoring period).

You can store metrics for any generic resource. You can use CloudWatch to create a single, integrated storage and aggregation point for all of the metrics that you want to watch and to monitor.

You don't have to pre-define the new metrics and you don't have to pre-allocate storage space. Instead, you simply store new values and the new metric will be created automatically. You can monitor resources that run on EC2, or anywhere else on the Internet.

You can access all of your metrics using the ListMetrics function. Any graphing or visualization tools that have the ability to pull existing data from CloudWatch should be able to access user-defined metrics with little or no change.

Metric values can be stored using the new PutMetricData function or the mon-put-data command-line tool.

CloudWatch metrics are scoped within namespaces, and can be further qualified by up to 10 dimensions. For example, latency could be tracked for a pair of applications ("App1" and "App2") while keeping the values isolated from each other:

Metrics that have different namespaces and dimensions are treated as discrete metrics. In this example, the application-level metrics are isolated from the host-level metrics. In other words, be sure to Put the metrics in the same format that you want to Get them.

CloudWatch lets you provide metric data from multiple sources. You can monitor scalable applications comprised of hundreds or even thousands of EC2 instances. New hosts can contribute to existing application-level metrics as they join the fleet. You can then retrieve the data for individual hosts or for the entire fleet.

Here's an example of the kinds of insights that can be gained when you use custom metrics. The following chart shows the amount of free memory (the jagged line) and the application's page latency:

As you can see, page latency increases as free memory decreases (looks like there's some garbage collection going on as well).

You can choose from among a list of standard units (Seconds, Bits, Bytes, Percent, Count, Bytes/Second, Bits/Second, and Count/Second) when you store metrics. Metrics with different units will not be included in CloudWatch's statistical calculations. All metrics are retained for a period of two weeks.

Once your metrics are stored in CloudWatch, you can treat them as if they were metrics on AWS resources. You can use the GetMetricStatistics function to calculate the Average, Min, Max, Sum, and Count for any time range and you can also graph the metrics in the AWS Management Console.

You can also create CloudWatch Alarms on your metrics. For example, if you monitor latency, you can set up an SNS notification to email you when average latency remains elevated for 15 minutes.

You can use any of the metrics to AutoScale your fleet of Amazon EC2 instances.This means that you could scale up and down on metrics that are only indirectly related to system load or performance, but that may be better indicators of application performance or customer experience: number of registered users, number of active sessions, page load times, or error rates.

The Custom Metrics are priced on a per-metric basis. You'll pay $0.50 per metric per month regardless of the number of values that you store for the metric. We are also reducing the price of EC2 Detailed Monitoring to $3.50 per month (7 metrics * $0.50 / metric). You can store 10 metrics per month at no charge; these can be used for both Custom Metrics and EC2 Detailed Monitoring metrics.

The HP SiteScope product now includes support for CloudWatch's new user-defined metrics. You can configure SiteScope to report any desired metrics to CloudWatch, and then use them to drive scaling decisions, raise alarms, or simply chart them. Integration is as easy as editing the new function in the SiteScope configuration file and creating a new SiteScope tag to define the data to be routed to CloudWatch. You can also embed HP diagnostics probes in your AMIs so that newly launched EC2 instances appear in the HP Diagnostics UI. Read more about both features in the HP APM (Application Performance Management) blog.

Some of our customers started to use this new feature during the private beta. Here's what they had to say:

Loggly.com provides log management and analysis for customers such as about.me, an AOL Inc. company that ties together multiple social networking site profiles into a unified personal homepage. Kord Campbell (Founder and CEO) told us:

Loggly makes it easy for businesses to handle the large amounts of log data they generate every day, and now customers like AOL’s about.me are asking us to deliver actionable alerts on subsets of the log data “About.me needs to know right away when response times from the social networking sites slow down or errors arise. By integrating with Amazon CloudWatch alarms, we can now automatically deliver this information to about.me and retain our focus on the core logging service.

Bizo is a business-to-business marketing platform operated as an online service. According to Larry Ogrodnek (Bizo's Director of Engineering):

Bizo is hyper-focused on the performance of our systems and data that our B2B marketing customers count on every day. The new functionality in Amazon CloudWatch enables us to monitor the availability of our back-end services without managing our own monitoring system. We can now gain insight into the health and performance of our systems to a level of detail that simply wasn’t cost-effective before.

BitNami Cloud Hosting helps businesses deploy and manage applications on AWS, by automatically integrating those applications with Amazon CloudWatch, we’re able to easily help our customers monitor their Amazon EC2 instances and Amazon EBS volumes and scale up and down based on application-level metrics such as the number of simultaneous connections or the internal load of the database.

I thought it would be fun to show the new CloudWatch User-Defined metrics in action so I spent a couple of hours cooking up a little example. I launched an EC2 Micro instance, installed PHP, Emacs, the MySQL development package, and the AWS SDK for PHP.

A simple for loop is used to process each DB Instance in turn. Within the loop, we focus on the database instances that are available (as opposed to other states, such as modifying) and that are running MySQL:

This information is used to establish a connection to the MySQL server running on the DB Instance and to run the "show status" command on the instance. RDS knows (but refuses to divulge for security reasons) the password for the master user, so I've hard-coded it for this example.

Now we get to the heart of the matter, actually storing the information into CloudWatch. It took me a couple of tries to get the call to work, so feel free to start from where I left off! Here's all the code that's needed to store three separate user-defined metrics in CloudWatch:

We've added a second container type to AWS Elastic Beanstalk. Version 7 of Apache Tomcat is now available for use and is the default for all new environments (you can still choose version 6 if you'd like).

Tomcat 7 includes functional improvements such as support for the latest versions of a number of standards including Servlet 3.0 (JSR 315), JSP 2.2 (JSR 245), and JSP-EL 2.2. It also includes some security improvements such as CSRF request prevention using a nonce and a memory leak detection and prevention mechanism. For more information, check out the Apache Tomcat 7 documentation.

The AWS Toolkit for Eclipse also supports a new server type called "AWS Elastic Beanstalk for Tomcat 7." You will need to update your AWS Toolkit plugin using the Software Updates… menu item in the Eclipse Help menu.

If your application can run on Tomcat 7 and you would like to migrate your environment, here is how you can do it with minimal downtime:

In the AWS Management Console, make sure the application you’d like to migrate is selected.

Click on Launch New Environment in the top right corner.

From the Select an existing application version drop down, choose the application version that you’d like to run on Tomcat 7.

From the Container Type drop-down, select the Tomcat 7 container that best fits your application and complete the rest of the wizard with the settings that work for your application.

Once the environment has launched, test your application and make sure that it works as expected

Move your existing domain name to point to the new environment’s URL.

Once you’ve verified that the domain name is pointing to the new environment, use the Actions menu for the old environment, to Terminate this Environment.