Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Private Subnets Are Broken on AWS

DZone's Guide to

Private Subnets Are Broken on AWS

VPC architectures containing a private subnet that includes EC2 instances and needs to connect to the public internet causes issues, especially if you have to do many requests or transfer a lot of data.

· Cloud Zone
Free Resource

Are you joining the containers revolution? Start leveraging container management using Platform9's ultimate guide to Kubernetes deployment.

Note: This blog post was written in July 2015 and is outdated. Amazon released Amazon VPC NAT Gateway in December 2015.

Being able to build a private network in the cloud with Virtual Private Cloud (VPC) is a key feature of AWS. But private subnets are broken on AWS.


A typical VPC setup consists of public and private subnets, as shown in the following figure. An EC2 instance in the private subnet running an application can’t connect to the internet by default. But often there is a need to do that for the following reasons:


  • The EC2 instance needs to call the AWS API (DynamoDB, Route 53, and so on).
  • The EC2 instance needs to download packages from a public repository (yum, apt, and so on) to be provisioned or to install updates.



Traffic to 0.0.0.0/0 from the private subnet is routed to a single EC2 instance: the NAT instance. You can configure this with the help of the route table attached to the private subnet.


Unfortunately, all traffic from the private subnet to the internet has to pass a single EC2 instance. This is a problem because


  • The NAT instance becomes a single point of failure.
  • The NAT instance can only be scaled vertically.


There are best practices for building a HA setup for your NAT instance (see, for example, the article High Availability for Amazon VPC NAT Instances: An Example at http://aws.amazon.com/articles/2781451301784570), and the limit for scaling vertically is sufficient for most use cases. But is using a private subnet to prevent access from the internet to your app server worth all the trouble?


Probably not. If you want an app server that can’t be reached from the internet but that can connect to other services over the internet, you can use the following setup (illustrated in the next figure):


  • App server running with a public IP address
  • App server running in a public subnet with a route to the internet gateway
  • App server running in a security group that prohibits all incoming traffic
  • ACL attached to the subnet allowing only incoming high ports from the public internet



If you need to, you can create an additional public subnet that allows connections from the public internet (for example, to run a SSH bastion host).


tl;dr: Think twice if you’re planning to use a VPC architecture containing a private subnet that includes EC2 instances that need to connect to the public internet, especially if you have to do many requests or transfer a lot of data.


Good news if you only need to connect to S3 from the private subnet: as of May 2015, you can use a VPC endpoint for S3 (see http://aws.amazon.com/de/about-aws/whats-new/2015/05/introducing-amazon-vpc-endpoints-for-amazon-s3). A NAT instance is no longer required for this use case.


What do you think? Let me know: andreas@widdix.de or @andreaswittig.


Are you interested in learning more about AWS? Michael and I are writing a book called Amazon Web Services in Action that will guide you into the AWS universe.


Using Containers? Read our Kubernetes Comparison eBook to learn the positives and negatives of Kubernetes, Mesos, Docker Swarm and EC2 Container Services.

Topics:
aws ,vpc ,cloud

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}