Amazon Web Services Blog

I want to be sure that all readers of this blog are aware of our self-service wiki powered scheduling system!

In advance of each trip that Mike, Jinesh, or I take, we create an entry on our Evangelists Wiki. We fill it in with the anchor events for our trip and leave some time open for meetings with interested parties -- often developers and entrepreneurs.

At that point, anyone who'd like to meet with us is more than welcome to find an open time and to reserve it by simply making an entry in the wiki. We do appreciate a confirming email which includes any information that you don't want to leave out in public.

To date every one of these meetings has been very worthwhile. Everyone has been very respectful and protective of our time and they've gone out of their way to make sure that the events on our schedule will fit together with just the right amount of time to spare. In fact they will often suggest ways to optimize our schedules, must-visit local restaurants, and so forth.

At first the wiki was used to make sure that pre-planned trips were action-packed. However, last year, one of our "fans" created an entry in the "Possible Trips" section at the bottom of the page. He invited us to come to New Zealand and promised that he would help to set up 4 or 5 meetings to get things rolling. Mike used this one wiki entry as the basis for a very successful trip to New Zealand and Australia.

The private meetings are very valuable to us. We get to hear from users and potential users, and we take their feedback seriously. Part of our discipline while on the road is to write a trip report at the end of each day. We recount the presentations and meetings and do our best to pass along what we've learned. If you give us some feedback in the course of a presentation or a private meeting, it will be in inbox of a number of members of the AWS team within a matter of hours. We take care to call out requests for new features and even for entirely new services and route these directly to the appropriate planners and managers.

-- Jeff;

We just added three important new features to Amazon EC2: Elastic IP Addresses, Availability Zones, and User Selectable Kernels. The documentation, the WSDL, the AMI tools, and the command line tools have been revised to match and there's a release note as well.

Read on to learn all about them...

The Elastic IP Addresses feature gives you more control of the IP addresses associated with your EC2 instances. Using this new feature, you use the AllocateAddress function to associate an IP address with your AWS account. Once allocated, the address remains attached to your account until released via the ReleaseAddress function.Separately, you can then point the address at any of  your running EC2 instances using the AssociateAddress function.The association remains in place as long as the instance is running, or until you remove it with the DisassociateAddress function.Finally, the DescribeAddresses function will provide you with information about the IP addresses attached to your account and  how they are mapped to your instances. Accounts can allocate up to 5 IP addresses top start; you can ask for more if you really need them. Addresses which you have allocated but not associated with an instance will cost you $.01 per hour.

Availability Zones give you additional control of where your EC2 instances are run. We use a two level model which consists of geographic regions broken down into logical zones. Each zone is designed in such a way that it is insulated from failures which might affect other zones within the region. By running your application across multiple zones within a region you can protect yourself from zone-level failures.

The new DescribeAvailabilityZones function returns a list of availability zones along with the status of each zone. The existing RunInstances function has been enhanced to accept an optional placement parameter. Passing the name of an availability zone will force EC2 to run the new instances in the named zone. If no parameter is supplied, EC2 will assign the instances to any available zone.

Finally, the User Selectable Kernels feature allows users to run a kernel other than the default EC2 kernel. Anyone can run a non-default kernel, but the ability to create new kernels is currently restricted to Amazon and select vendors. This feature introduces a new term, the AKI or Amazon Kernel Image. The AKI can be specified at instance launch time using another new parameter to RunInstances, or it can be attached to an AMI (Amazon Machine Image) as part of the image bundling process.

We are also rolling out 32 and 64 bit versions of Linux kernel version 2.6.18, all packaged up as AKIs and ready to run. And there's a new 32 bit Fedora Core 6 AMI and both 32 and 64 bit versions of Fedora Core 8.

The developers at RightScale are already supporting these new features in the  free version of their RightScale platform. They've also assembled three very informative blog posts.

The first post covers DNS and Elastic IPs and how they come in to play when upgrading a server. One sentence from this post really captures the essence of cloud computing as applied to the upgrade process:

The power of the cloud is that we don’t need to touch our existing web server and risk causing damage during the upgrade process. Instead we launch a second web server and install the new release on it.

The second post reviews the process of setting up a fault-tolerant site using the Availability Zones. This post describes two different ways to create a redundant architecture with the ability to load balance traffic across zones or to fail over to a second zone when the first one fails. When that happens redundancy can then be re-established by bringing another set of instances to life in yet another zone. As they note:

If you have never tried to set something like this up yourself starting from renting colo space, purchasing bandwidth to buying and installing servers, you really can’t appreciate the amount of capital expense, time, headache, and ongoing expense saved by EC2’s features! And best of all, using RightScale it’s just a couple of clicks away :-).

Finally, the third post  announces the fact that they now support the new Elastic IP and Availability Zone features. You'll need to read the entire post, but they are pretty excited by the opportunities that this new set of features open up:

What’s really exciting is that the combination of Elastic IPs and Availability Zones bring cloud computing to a different level. In the above example, when the app servers get relaunched in a new zone, EC2 allows the elastic IPs that were associated with the app servers to be reassigned from the old servers in the failed zone to the new ones. So now traffic doesn’t just get routed to new instances, it actually gets routed to a different datacenter. From the outside this may seem straightforward, but in reality the degree of engineering that is necessary to support this type of technical feature is quite staggering.

We're looking forward to hearing from more developers and system architects as they engineer these new features into their systems. As always, drop me a note at awseditor@amazon.com if you have done something that you'd like us to cover in this blog.

-- Jeff;

I just received word that James Murty's new book, Programming Amazon Web Services, has been published and that copies are now available. The Amazon site is still showing the book as available for pre-order but this should change within a day or two.

The book contained detailed information about the use of Amazon S3, Amazon EC2, Amazon SimpleDB, Amazon SQS, and the Flexible Payments Service. I've reviewed several drafts of the book; James has done a really good job of collecting and organizing the information that will allow you to make good use of each service.

In the space of 13 chapters and 2 appendices, James details each service -- what it is, what it does, how it fits in to the other services, and how to use it to solve real problems. There's plenty of Python and Ruby code too.

-- Jeff;