In continuation of my first wish list, I will present another set of potential improvements and ideas for Amazon Web Services in this post. The focus lies on security groups and virtual private cloud.
Many people have written about potential improvements for Amazon security groups, see for example Dmitriy’s write-up, and I just want to emphasis one point from their wish lists: the possibility to filter outbound traffic. I understand that Amazon is quite pragmatic with their feature set and only provides what the majority of their customers require. For the majority the current situation with filtering inbound traffic might be good enough, but with an increase in cloud usage for “serious” purposes, filtering outbound traffic will be of importance. And honestly, I doubt the technical difficulty in implementing that feature when they are already able to filter inbound traffic.
AMIs can contain services which might not have a strong authentication and authorization mechanism, for example consider memcached. The problem is to ensure that instances of such an AMI are properly secured with rules of an appropriate security group, e.g., only allow web/application server to access the memcached. An AMI could be accompanied by a policy specifying the properties of a security group the instances of that AMI can only be a member of.
Logging is a crucial part of IT infrastructure and I am surprised that Amazon has not released such a service, although the idea was already proposed in a post in the Amazon forum.
For one thing, they could publish logs of the underlying architecture relevant for specific VMs, e.g., logs from the security group filtering. On another thing, they could provide a syslogd interface to VMs in order to gather logs from customer instances. The aggregated logs can then either be processed by Amazon (for example running a simple logcheck) or further processing can be done by third-party applications (for example an IDS).
I know that Amazon VPC is still considered a service in beta phase, and I won’t pick on the limit of one VPC per customer, but still I want to share two points.
A VPC subnet can further be divided into multiple subnets (up to 20), which are aggregated in a star topology with a router in the middle. I am looking forward in having access to filtering capabilities of that a router, in order to restrict traffic between the various subnets. This would greatly enhance the possibilities of VPC subnets.
In case subnet filtering on the router would not be possible, having security groups in combination with VPC would be great. A VPC subnet could just be considered as a security group, which allows regular filtering between the various subnets using security groups as sources. It would also allow filtering for the individual instances in the management layer, rather than doing filtering within the VMs.