Sören Bleikertz
23 Feb 2010

My Short Wish List for Amazon Web Services

In the short time I have used AWS, I came across a few issues which I would like to see changed by Amazon in the foreseeable future. It mainly concerns the management side of AWS rather than the technical one.

Fine-Grained Access Control for the API

Cloud computing is destined to be used by applications and automation infrastructure, therefore the API is an essential component in the cloud provider’s offering. So far I am pleased with the functionality of the existing API, but the access control is very rigid and inflexible. Although Amazon supports multiple types of credentials and allows multiple instances of each credential, the access associated with these can not be controlled.

If a credential is getting compromised, the attacker would get full control over ones IT infrastructure in the cloud and could use additional resources, e.g. for further malicious purposes, which are billed by the victim’s account. A typical scenario is an application running on a dedicated server using additional resources from the cloud, therefore requires the access key, or another kind of credential, to be stored on the server. If the server is getting compromised, the access key will be compromised as well and the attacker can use it for the previously mentioned cases.

Specifying in a fine-grained way for which purposes a credential can be used would limit the impact of a compromised credential. This can be on a high-level at the beginning, e.g. specifying a credential can be used for write or read access. I define write access as operations modifying the cloud, e.g. creating new instances or shutting down instances, and read access as ones only obtaining information. The latter type of access is useful for monitoring applications, where access for modifying the cloud is generally not required. In the long-term, this could be extended to limit credentials for certain kind of operations, only allowing credentials to operate on specific services, or limit the issuer of operations using a credentials (e.g. only the operations issued from the corporate network are allowed).

Notifications of Resources Usage

AWS provides usage information for the resources in the cloud in a XML format, but does not have a functionality of sending notifications for what kind of resources were used and how much they cost in a specific interval. For example I would like to receive a daily email summarizing the resources I have used and how much they cost for that specific day. I am sure one could implement such a feature with the provided usage information, but it would be much more convenient if it is provided by Amazon out of the box. Especially since the session lifetime for viewing the account activity is very short.

Resource Usage Limitations

Consider the scenario that you want your developer team to use the cloud for testing or development purposes, but you also want to limit the amount of money they are allowed to spend. If one of the developers forgets to terminate his 20 extra large instances for a longer time-frame, it will be charged at the end of the month on your credit card. Of course the previously mentioned notifications would probably prevent such a scenario, but it also makes sense to have a soft and hard limit on the resource usage, in case one is not interested in daily usage notifications.

For example you allow your developers to spend $500 on EC2, and after that limit is reached they are not able to launch new instances. Furthermore you specify $550 as the hard limit, i.e. after that amount is reached all running instances are terminated.

Of course these kind of limitations can be tricky in certain situations, e.g. when dealing with storage. Are you deleting storage if the limit is reached or not? The combination of hard and soft limits, and notifications could maybe make it feasible.

Outlook

I am also very interested in what kind of problems you are having with AWS and what you would like to see changed. I am in particular interested in security concerns and issues.