Security Considerations of AWS Private Subnet vs Private Security Group

Not quite. First, your numbered points.

  1. Yes this is correct, as far as it goes. You can also put a NAT gateway (or NAT instance) in a public subnet to provide for internet access, very useful for things like software updates.

  2. Devices always communicate with other internal servers using private IP addresses. They use public IP addresses for sites outside the VPC.

  3. Instead of putting servers in a public subnet you can have three tiers. Put a load balancer / proxy into the public subnet, put your web / app servers into the application subnet, and your database servers into a third subnet

Now, your questions

  1. No, they're completely different. One is isolated and secure unless you open it up somehow, one is available on the internet and as such is only as secure as your software.

  2. Yes. Many. All security groups do is restrict by port. You can also put in services that intercept traffic for full ingress and egress scanning, you can use cloud services to do similar, you can use Guard Duty to monitor your traffic.

Cloud security is a HUGE topic. I run a two day AWS workshop to educate and on-board new customers to AWS, of which more than half is related to security - and this is just high level stuff. There's then many, many details to cover and decisions made later. This is enterprise level though, with many integrations, corporate policies, national security standards, etc.

If you post a concrete question (a new question) about what you're trying to achieve, rather than something theoretical, you could get some practical advice.


There isn't really a difference in terms of security. Both an EC2 instance in a private subnet with an inbound allow all security group and an EC2 instance in a single security group with no rules are inaccessible from the internet.

However an instance in a public subnet is addressable from the internet, in that it has a globally unique IP which people on the internet can attempt to send packets to.

Private subnets give some additional security considerations - they make it clear that the instance is not accessible from the internet. It is also hard to change, whilst the security group approach can be changed by adding an inbound rule. Most importantly though, lots of people consider this approach best practice (regardless of whether it is) so it appeases tick box managers and security audits.

Interesting to the note that IPv4 in AWS always uses NAT, even without a NAT gateway. EC2 instances in the public subnet don't have public ips really -> if you inspect the destination packets they will go to the internal ip. This is because AWS are using NAT behind the scenes.

Personally I think the private subnets provide extra complexity for no extra benefit. If possible I would try and use IPv6 and disregard NAT entirely and just use security groups + application layer security. However IPv6 is poorly supported and many people don't understand NAT properly so use a private subnet unless these aren't issues.