5

AWS Virtual Private Cloud allows several ways of restricting access to devices on the VPC network from the Internet.

1) Place devices into a private subnet (no Internet Gateway). Each device can communicate with other devices using private IP's. No device has a public IP, so no access from the Internet.

2) Place devices into a public subnet. Each device has a public IP, so they can communicate with other internal devices using either private or public IP's. Add Security Groups to restrict access from the Internet.

Questions:

  1. Are these two approaches identical from a security perspective?

  2. Are there any other considerations to take into account?

hellodanylo
  • 153
  • 6

2 Answers2

6

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.

Tim
  • 30,383
  • 6
  • 47
  • 77
  • > one is available on the internet and as such is only as secure as your software. Can you elaborate on this? The second approach uses security groups to disable access from the Internet. Maybe I should clarify that in the question. – hellodanylo Jan 05 '20 at 21:29
  • Private subnets are not accessible from the internet. Public subnets are accessible from the internet. You protect public subnets with a security group, but if you have an old, unpatched instance with security holes it can act as a proxy to let attackers into your private subnet. Firewalls are just one thing you do with security, you need to use a layered approach. – Tim Jan 05 '20 at 22:00
  • Assuming we are talking about EC2 instances. You say 'one is available on the internet and as such is only as secure as your software', I assume regarding the public subnet. But with a security group with no inbound rules attached to the EC2 host it will not be available to the internet. Or you could disable the 'Auto-assign public IP' option when launching the instance. Neither options rely on the software. Are those scenarios less secure than placing the EC2 instance in a private subnet with only a NAT Gateway for outbound internet traffic? – SeanOB Dec 03 '21 at 06:13
  • An instance in a single security group with no rules in a public subnet is not *accessible* from the internet, even though it's in a public subnet. It is however *addressable* from the internet in that you can try and send packets to it. – Nick Jan 02 '22 at 23:00
3

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.

Nick
  • 146
  • 4