Amazon Web Services and Cloud admin on 20 Feb 2009 05:14 am
Securing n-tier and distributed applications on EC2
In this post I will walk you through the high level of securing a normal tiered application running on EC2. First I will cover the basics of what EC2 provides and then briefly discuss how this can be used in a real life scenario.
Security Groups
For Network security EC2 provides a security groups, security groups are essentially inbound firewalls suited to the dynamic nature of EC2. Using security groups you can specify which incoming network traffic should be delivered to your instance.
- The default mode is to deny access, you have to explicitly open ports to allow for inbound network traffic
- If no security group is specified a special default group is assigned to the instance. This group allows all network traffic from other members of this group and discards traffic from other IP addresses and groups. You can change settings for this group
- You can assign multiple security groups to an AMI instance.
- The security groups for an instance are set at launch time and can not be changed. You can dynamically modify the rules in a security group and the new rules are automatically enforced for all running and future instance, there may be a small delay depending on the number of instances
- You can control access either from named security groups or source IP address range. You can specify the protocol(TCP, UDP, or ICMP) , individual ports or port range to open
- You can allow access to other users security groups using user-group pair
- The current API (Amazon EC2 on 2008-12-17) does not support port ranges for security group using command line tools or Query API, you will need to use SOAP API
- An account can have a maximum of 100 security groups
- Security groups are just access rules applied to a single or collection of instances, if two instances are part of the same security group this does not afford them any special access between them.
- An instance running in promiscuous can not sniff any traffic intended for a different instance.
- A running instance cannot change security group access rules. You need access keys or X 509 key to authorize change.
- In the instance you can get the security group information from the instance meta-data (curl http://169.254.169.254/1.0/meta-data/security-groups)
Key Pair
Amazon discourages the use of passwords and the normal way to access an instance is using ssh and a private key. Amazon EC2 provides facilities to generate the key(2048 bit RSA key), at instance startup you can attach the key name to the instance and this will allow root access. Normally you will customize the AMI with your own less privileged user public keys and disable root login
Securing Your Application
Now that we have covered the basics how can we use these to secure a distributed application. Below is the normal deployment architecture for a typical tiered application.

In the above deployment we have created 4 security groups
Web-Security group: Allows http (80) and https(443) to everyone to access the application
App security group: Only allows access from instances running in web security group on required ports e.g. 8080
DB security group : Only allows access from instances running in app security group on required ports e.g. 3306
ssh-admin security group: Only allows access to ssh port 22 and as a matter of policy access is allowed from specific host address or organization network. This allows easy management of permissions.
As you can start an instance with multiple security groups the web tier instances will run with web and ssh-admin security groups, app server instances with app and ssh-admin and finally database instances with db and ssh-admin.
You will not need to change web, app or db security groups, The cloud administrator will allow or revoke admin access by just adding or removing hosts from ssh-admin group with port 22 access. You can write scripts or use any GUI (Elasticfox, Amazon admin console) tool
Other Best practices
- Make secure requests to Amazon Web Services see
- Restrict ssh port(22) access to host or organization network
- You can and are encouraged by amazon to use an other firewall (e.g iptables) in conjunction with security groups on an instance to restrict inbound/outbound traffic and have finer control
- Dont open any port unnecessarily
- Have separate application administrator (ssh access to instances) and cloud administrator(setting up security groups and key-pair generation with access to amazon EC2 certificate and access keys but no ssh access to running instances)
- Disable password based login( set PasswordAuthentication no in /etc/ssh/sshd_config) see
- Customize the AMI with your own user public keys and disable root login. If you need root login use sudo see
- Keep your AMI up-to-date with security patches and fixes
At Jana, we specialise in Cloud Computing and are available for Cloud implementations or Cloud advisory services. Please contact us for more details


















on 20 Feb 2009 at 5:57 am # Securing Amazon EC2 for n-tier applications | TheBlogGuideTo HPC,Grid, DataGrid, Virtualisation and Cloud Computing
[...] is an excellent article on securing Amazon EC2 for distributed architectures over at Cloudiquity – well worth a read if you plan to deploy on Amazon [...]
on 11 May 2009 at 6:45 am # Cloud Best Practice – what to be aware of ! « DeinosCloud
[...] as IBM or Sun is that many of these security optimisations are already taken care of. See our prior blog entry for securing n-tier and distributed applications on the [...]