Back to top
4 minute read

Getting started with AWS VPC (Virtual Private Cloud)

Some best practice guidelines for using this fundamental feature of AWS

When you first get started with AWS there is a lot of to learn, understanding VPCs and how to use them is one of the fundamental subjects. This article will give you some ideas about how best to design your VPCs.

Here is a diagram of a standard VPC setup, we will refer to this as we go along:

Use multiple availability zones (AZ)

We recommend you take full advantage of AWS's highly available services by using at least two preferably three different AZ's within a region. This means when running a system you can replicate that system in another AZ and use the Elastic Load Balancing (ELB) service to distribute traffic between those systems. This protects you against a failure of a particular AZ. When using Amazon's Relational Database Service (RDS) if you use all three AZs you will get one primary database and two standbys. If the AZ where the primary resides fails, one of the standbys will automatically become the primary.

Decide on your network allocation

To create a multi-AZ VPC you need to allocate different network ranges to the AZs, we always start off with a /16 subnet and break that down into /24 network ranges. 

Subnets chosen

In our example we are using as the VPC subnet. From this we allocate nine /24 subnets, three public, three private and three RDS. Each one of these is allocated to one of the three AZs (1a, 1b or 1c):

  • Public 1a -
  • Public 1b -
  • Public 1c -
  • Private 1a -
  • Private 1b -
  • Private 1c -
  • Break in subnets for future services
  • RDS 1a -
  • RDS 1b -
  • RDS 1c -

Public and private networks

Amazon allows you to have public and private subnets. Public subnets are a little confusingly named because although the instances within that subnet still have a private IP you are also allowed to assign a public IP to the instances. 

This public and private split means we are going to have 3 public subnets and 3 private, these are spread out across the three AZ's. You can see them as the first and second layers in the diagram above. In addition to this we also recommend adding 3 additional subnets for RDS if it is used, this is the third layer in the diagram. This allows us to separate access via the use of NACLs (Network Access Control Lists) and only allow direct access from the private subnets. This gives us an extra layer of security over and above the standard Security Groups and should prevent accidental exposure of databases on public routable networks.


When you assign a public (internet routable) IP to your instances in the public subnets, their default route will point at the Internet Gateway (IGW) service. This is a highly-available router that will route network traffic to and from your public instances. Routing for the private and RDS networks would go through a NAT gateway so you can allow outbound traffic from the private subnets and the response will get back to your instance.

Network access control lists (NACLs)

Typically we use NACLs to control access to network ranges, for the public NACL we need to allow everything ( so that all addresses on the Internet will get to our public services. We can lock down which ports are allowed via Security Groups (SGs). Unfortunately, in order for us to use Elastic Load Balancers (ELBs) to access services in the private subnets we again need to allow all addresses and lock down ports using SGs. You should note that Internet routable addresses are not routable to private subnets, so whilst this seems like a bad idea it is not in practice. NACLs are most effective when we look at the RDS layer, we can lock this down so only the network ranges of the private subnets can access the RDS servers. SGs would again lock down which ports are allowed.

VPC endpoints

Make use of VPC endpoints where you can, for example to access S3, as they allow you to exchange traffic with that service without it leaving your VPC, see this document for more information.

So what goes where?

Only publicly accessible services should go in the public subnet, so this will mainly be ELBs, but you could have other services like a VPN server or bastion host in there too. 

Your servers will go in the private subnets, you then restrict access to these servers bythe use of Security Groups. You can create additional layers with more subnets if you can segment your application further, for example you may create three more subnets to house services such as elasticache or even workspaces.

Only RDS servers live in the RDS subnets.

Contact us

Please feel free to contact us using the details below if you want to discuss what services ngineered can provide to your company.

Ian MacDougall

Ian is responsible for Ngineered’s customer builds. An expert in the requirements of the enterprise, he is known for his rock-solid builds, and his sensitivity to legacy systems.