AWS - Are security groups enough or is there a need for private and public subnets?

Question

Let's suppose I have a web server which is an EC2 instance and an RDS.

The EC2 instance communicates with the RDS.

For security, I could have this set up behind an Application Load Balancer and use security groups to only allow inbound traffic through the ALB. The ALB will communicate with the inte.net only through HTTPS.

Internally I could set up a security group that accepts only incoming traffic from the security group of the ALB. I would attach this security group to the EC2 instance. I could then have another security group that allows incoming traffic only from the EC2 instance. This security group would be attached to the RDS.

The security group of the EC2 instance would allow outbound traffic over HTTPS for the purpose of updates, downloading packages, etc.

From my (limited) understanding of how this setup would work, communication with the RDS would have to happen strictly from the EC2 instance and inbound communication to the EC2 instance would have to happen strictly from the ALB which is configured to accept only requests through SSL.

In terms of security, is this setup safe?

What risks are there from running a set up like this?

What benefits, if any, are there from configuring private and public subsets like is shown here ?

Answer 1

It all depends upon your risk appetite .

Additional layers of security make things safer, but they also make things more difficult to use -- just look at airport security, applying for a new passport or using a NAT Gateway to obtain Inte.net access.

By putting resources in a private su.net , there is an additional layer of security . It can be reassuring knowing that resources in a private su.net cannot be accidentally made public by a mis-configuration of a security group (but can be made public by a mis-configuration of the su.nets.).

Network security people are familiar with traditional methods of security by using public/private su.nets, and don't have the luxury having having Security Groups in a traditional.network. Therefore, they are more 'comfortable' using the old-style security methods together with modern Security Groups.

So, if you feel comfortable with putting your resources in a public su.net and using Security Groups to restrict them, then that is up to you. You can further protect resources if you do not give public IP addresses to private resources , which will further protect them from access.

At the very least, set your database to Publicly Accessible = No .

Answer 2

Here are some of the best practices I could think of -

1. Have a 3 tier enterprise architecture with 1 public su.net, 1 private su.net and 1 for database. Only public su.net has direct inte.net connectivity, rest of them have a NAT gateway
2. Do not keep your RDS (DBs) in public su.net. It's not good to publicly expose your DB (even if you have SGs)
3. Implement ACLs as well along with SG for allow and deny statements. ACLs operate at a su.net level

For an enterprise grade you surely need more security depending on the architecture