Thanks for your comment! I’ve written an article showing how to implement this technique.

I have been struggling with the same challenge of getting AWS credentials on an EC2 instance. I came up with roughly the same list of options as you, until tonight, when I thought of another possibility:

when launching an instance, one can specify a snapshot to automatically create an EBS volume from and bind it to a block device. What if you created an EBS volume, put your credentials on it, create a snapshot from that, and then use the mentioned approach? One could use the user-data script (or whatever) to mount the block device and read the credentials. And when an instance terminates, by default the created EBS volume gets deleted (unless you turned it off in the –block-device-mapping option). Make sure the snapshot is private though. And I assume traffic between EC2 and EBS is secure, however I’m not sure of that, but there are many EBS boot images now, so that would be awkward then. Finally, it’s possible to encrypt the EBS volume at filesystem level, and pass the key for it in your user-data script; it doesn’t add security, but prevents someone else from reading the raw storage after having deleted the volume.

That still leaves the ‘How to Keep AWS Credentials on an EC2 Instance’ part, probably you would need to look at SELinux or AppArmor to fix that one, if EC2 even supports that (since EC2 provides the kernels). Also, one could use a read-only filesystem on the EBS volume and have some credentials broker there which takes proper measures to prevent unauthorized retrieving of the credentials; but no idea how to really secure that yet, if it is even possible (since root can do anything, but one could look at the pid of the process requesting the credentials, see which binary it belongs to and check whether the binary is untampered with for example, one could store a list of binaries and sha1sums in the read-only filesystem; but the filesystem itself might be unmounted/recreated/mounted as well).

Try putting the URL you give to wget in quotes. Some of these URLs have special characters that the shell interprets and quoting the URL argument will prevent the shell from interpreting those special characters.

SimpleDB requires AWS credentials to access. So it’s equivalent to the option “4. Put the secret in a private S3 object and provide the object’s path” discussed above.

Absolutely, I agree that fine-grained credentials would help mitigate the risk of compromised credentials.

That's also a good suggestion. Even better would be to use a single-use URL, which would cease to work after the first retrieval. Then it would not need to be deleted.