AWS Multi VPC Design

- networking aws

This post is part of my note taking while studying for the AWS Certified Advanced Networking - Specialty certification.

Using multiple VPCs in an AWS network design can be advantageous for designing secure, flexible networks. I go over a couple of scenarios below. It is crucial to think through VPC design when putting services in AWS. It can make life a lot easier or a whole lot harder in the short, medium, and long term.

Shared Services

This design could be used for one team to create shared services and share them with other business units. These business units could have their own AWS accounts or could have separate accounts. Pre-planning your IP usage is crucial here!

vpc-shared

Shared Services with overlapping IP ranges

You can’t always get what you want. Sometimes, you have overlapping IP ranges. This shared services design addresses that by having two different subnets with separate routing tables. Only one subnet would serve each other VPC and this should be taken into consideration when extrapolating this to a real-world design that supports HA and failover.

vpc-overlap

No Transitive Traffic as a Design Feature

The prohibition of transitive traffic through a VPC is a design feature and creates security by default. For example, you could peer a Dev and Test VPC together and peer a Test and Production VPC together. If these VPCs are in different accounts, you can use IAM policies to restrict users to only certain environments, enforcing a development lifecycle where certain admins could only push dev to test and others could push test to prod:

vpc-dev-test-prod

Additionally, this could be extremely useful when another VPC from another entity, for exmaple a provider or an acquisition needs to acceses certain AWS resources but not all:

vpc-merge

Sources

From One To Many: Evolving VPC Design

Practical VPC Design

VPCs and Subnets