12

In Amazon VPC, the VPC creation wizard allows one to create a single "public subnet" or have the wizard create a "public subnet" and a "private subnet". Initially, the public and private subnet option seemed good for security reasons, allowing webservers to be put in the public subnet and database servers to go in the private subnet.

But I've since learned that EC2 instances in the public subnet are not reachable from the Internet unless you associate an Amazon ElasticIP with the EC2 instance. So it seems with just a single public subnet configuration, one could just opt to not associate an ElasticIP with the database servers and end up with the same sort of security.

Can anyone explain the advantages of a public + private subnet configuration? Are the advantages of this config more to do with auto-scaling, or is it actually less secure to have a single public subnet?

1
  • 2
    For what it's worth, EC2 instances in the pubic subnet can be reached from the Internet, even without an ElasticIP -- they get a public IP address anyway. The difference between this public IP address, and an ElasticIP, is simply that the public IP address may change when you reboot your instance, whereas an ElasticIP sticks around as long as you want.
    – offby1
    Jun 17, 2014 at 22:12

2 Answers 2

4

It's a security boundary to have a private subnet that you can control with different security groups from the public subnet. If one of your instances in the public subnet were hacked, it will be that much more difficult to hack into instances in the private subnet if you are not too liberal in your access policies.

2
  • 2
    Thanks. VPC with pubic+private subnet seems the way to go if AWS would throw in a NAT instance for free. I'm thinking of small deployments and was trying to figure out if the cost of a NAT instance every month was worth the advantages of the 2 subnet config.
    – JKim
    Nov 19, 2012 at 1:23
  • 2
    @jkim It's considerably more affordable now that they finally support t1.micro in a VPC. Sep 4, 2013 at 23:56
2

As well as the security implications, there is also another aspect that comes into play: If you want to allow instances without Elastic IPs to access the internet, you might need 2 (or more) different subnets.

Paraphrasing the AWS documentation, within a VPC there a three ways to allow instances internet access:

  1. Elastic IPs - but you only get 5 by default I think, and then you have to pay for more
  2. Route traffic though a Virtual Private Gateway - this requires you to have a hardware VPN connection to your corporate (or home) network
  3. Setup a NAT instance and route all outbound traffic via the NAT

The third option is the interesting one in that the NAT instance has to sit inside a "public" subnet where all outbound traffic is routed to an Internet Gateway, but all other instances have to sit in a "private" subnet where all outbound traffic is routed to the NAT instance.

In short, if you're planning on using a NAT, you need at least 2 subnets.

4
  • 2
    Thanks Tom. I think it's also possible to have 1 public subnet but only assign an ElasticIP to the NAT instance. The other instances on the public subnet will have outbound internet access via the Internet Gateway, and inbound access could be configured via port forwards on the NAT instance. I got the feeling that 2 subnets is the "proper" way, but not seeing a crystal clear reason for it.
    – JKim
    Sep 17, 2013 at 3:11
  • Almost ten years after, now you can increase the number of EIP allowed and, provided they are attached to a running instance as the only EIP, you won't pay anything.
    – nnsense
    Jan 29, 2023 at 22:43
  • And a year later than @nnsense's comment, AWS now charges for all EIPs, regardless of whether they're attached or not Feb 14 at 13:22
  • Yeah, apparently the lack of public IPv4 IPs was hurting them.. or lack of money.. who knows :D
    – nnsense
    Feb 16 at 14:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .