This technique is no longer necessary because it has been obsoleted by the boot from EBS feature.

Thanks in advance,

The SSH key is not related to the use of the EBS snapshot here. It's also not necessarily related to the use of an Elastic IP. Let me explain.

This article presents a way to mount an EBS volume created at startup time from a snapshot. That's not like hibernating because the snapshot is a copy of an existing drive, while in hibernating there is no copying of drives, only creating a faster bootup next time the power is restored. So, in this article the newly-launched instance should be regarded as a "different" computer, and it should get a different SSH host key than the instance from which the AMI was bundled.

The SSH host key is also not necessarily related to the use of an Elastic IP. An IP address can be transferred from one computer to another (via DHCP or Elastic IPs or reconfiguring the network properties) and it is different than the SSH identity of the machine. A single machine may have many IP addresses with a single host key (not in EC2, but in general), and a single SSH host key can be shared by many machines with different IP addresses. If you're using SSH host keys and IP addresses to determine the "identity" of an instance then you need to consider each use case and decide on the definition of "identity" you want to employ.

In my article about booting an instance from an EBS volume http://www.shlomoswidler.com/2009/07/boot-ec2-instances-from-ebs.html I present a technique to "hibernate" an instance. In that case, the SSH host key should not change between boots from the EBS volume, and therefore the instructions there do not cause the SSH host key to be regenerated each time a new instance boots from the EBS volume. The only question is, should the instances that boot from the EBS volume have the same SSH host key as the instance that was used to create the AMI in the first place. The instructions in that article to create the AMI do not include chmod +x'ing ec2-ssh-host-key-gen, but that is definitely something to be considered when preparing that AMI. Here too the use of an Elastic IP is not necessarily related to booting an instance from an EBS volume.

Let me know if that explanation clarifies things.

The ec2-ssh-host-key-gen is a script on most public linux AMIs that generates a new SSH host key for the instance. It is executed only on the first boot – since you don't want the host key to change after a reboot. After it is executed in the first boot, the startup sequence prevents it from running again by chmod -x'ing it.

When I bundle a new AMI I don't want it to have the same SSH host key as the instance it was bundled from. So I chmod +x that script to allow it to run again when the AMI is launched.

It's not strictly necessary to do this, but it's a good idea I think.

ec2-ssh-host-key-gen

Why is that needed and where is that found?

[Otherwise this follows nicely.]

Thanks for the pointer to Chef. I had looked at it a while back but didn't use it. I shall look at it again.

I do wonder if Chef doesn't provide a way to do what you want? I looked at RightScale's approach but, to my mind, Chef offered a more attractive route and community experiences wider than just EC2.

I don't /think/ Chef would provide a proxy service in exactly the way you describe. However, I am hoping a Chef recipe, or sequence of recipes, can be coerced to have an AMI boot from an EBS volume.
Chef seems to be making rapid progress so the community/wiki documentation/how-to is a little out of synch:

http://wiki.opscode.com/display/chef/Chef+0.7.0+on+EC2+Rails+Infrastructure+Notes

Do you use Chef at all?