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.
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!
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.
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:
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:
From One To Many: Evolving VPC Design
Practical VPC Design
VPCs and Subnets