Beyond the default: a Multi-VPC architecture

Andreas Wittig – 14 Oct 2016

I created my first AWS account on December 23, 2012. The one thing that surprised me most was the possibility to define private networks with Virtual Private Cloud (VPC). As this allowed me creating isolated areas, a fundamental prerequisite for building a high-security infrastructure.

Default VPC

Each AWS account created after December 2013 contains a Default VPC in each region. If you have not created a custom VPC you are using the Default VPC automatically when launching EC2 instances. That’s fine for a quick start on AWS, but if you are planning to run a production workload on AWS you should read on to learn how to use isolated networks.

Isolated networks

To secure your infrastructure you need to define who is allowed to access data and services. This is typically done by creating a set of rules. For example a firewall rule.

Defining rules is easy and less prone to error if you isolate independent parts of your infrastructure.

Typical reasons to create isolated networks:

  • Separating customers.
  • Separating applications.
  • Separating environments (development, testing, and production).


Imagine the following scenario. Your company is hosting eCommerce applications for two customers: Yellow Shop and Blue Shop. Part of the deal with your customers is an agreement guaranteeing an isolation of their networking infrastructure. Your task is to design the networking architecture for the system consisting of three parts:

  • Load Balancer
  • Web Application
  • SQL Database

Multi-VPC architecture

Instead of using the Default VPC for your whole infrastructure use multiple VPCs to enable isolation between your two customers. The following figure shows two VPCs. The VPC of the Yellow Shop is highlighted yellow, the VPC of the Blue Shop is highlighted blue.

Multi VPC

Andreas and Michael Wittig

Hej, Andreas & Michael here!

We launched the cloudonaut blog in 2015. Since then, we have published 325 articles: small tips and tricks, best practices, and service reviews. We enjoy writing about all things AWS a lot.

Do you like our blog posts and podcast episodes? Have you learned something new? Consider supporting us create in-depth and independent AWS content. Please help us with a monthly or one-time payment through GitHub Sponsors.

Start supporting us today!

Each VPC defines a solid boundary. Network traffic from the Yellow Shop’s VPC is not able to reach the Blue Shop’s VPC.

The next figure shows the components of a VPC:

  • Public Subnet
    • Attached to an Internet Gateway enabling incoming and outgoing Internet traffic.
    • Contains the Load Balancer which forwards requests to the EC2 Instances running in the Private Subnet.
  • Private Subnet
    • Attached to a NAT Gateway enabling outgoing Internet traffic.
    • Contains the Web Application running on EC2 and the SQL Database (Amazon RDS).
    • Neither the Web Application nor the SQL database are accessible from the Internet.


Why should you use two subnets of each kind? Because a subnet is linked to an Availability Zone. To be able to distribute your infrastructure among two Availability Zones for high availability you need a subnet of each kind in each Availability Zone you want to use.

The VPC is isolating your networks. On top of that you should use Network ACLs and Security Groups to control network traffic within your VPC.

CloudFormation templates

CloudFormation is the Infrastructure as Code service offered by AWS. Using CloudFormation allows you to automate the creation of a Multi-VPC architecture. We are sharing our CloudFormation templates on GitHub. Use our CloudFormation templates for VPC to get started quickly.


Using a Multi-VPC architecture allows you to isolate different parts of your infrastructure. Following the principle of divide and conquer simplifies and improves security due to less error prone and more precise access control.

Tags: aws vpc security
Andreas Wittig

Andreas Wittig

I'm an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I'm writing this blog and all other projects together with my brother Michael.

In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.

We are available for projects.

Feedback? Questions? Drop me a line: Email, Twitter, LinkedIn.

Briefcase icon
Hire me