In part 2, we covered some of the VPC's more advanced capabilities. In this final article of the series, we will cover how to work with multiple VPCs and how you can give your precious users access.
Let’s dig in. 👍
How many VPCs
Segregation must be considered when architecting on AWS, as you would in the data centre network.
VPCs provide a logical boundary to host your public and private subnets to support your workload; however, when running multiple workloads with different requirements, it is a good idea to consider multiple VPCs, possibly one per workload.
It's also one of the AWS best practices, so we should take note of it. But as with all things architecture, it depends.
Some people prefer to set up one big VPC and run multiple workloads within; however, multi-VPC architectures are a thing for organisations running multiple workloads across different teams.
So, how do we connect multiple VPC? Let's find out.
VPC Peering
VPC Peering allows you to connect two or more VPCs in the same or different AWS regions, enabling you to adjust your route tables to route traffic between them using private IP addresses.
For a refresher on routing, look back at part I
This connection allows resources in different VPCs to communicate with each other as if they are within the same network as long as the necessary security group rules are configured.
NOTE: CIDR ranges can't overlap, i.e., you can't VPC Peer two VPCs that both use 10.0.0.0/8.
The nice thing about VPC Peering is that it costs nothing. You will still pay for traffic across Availability Zones, but that happens within a single VPC.
The bad thing about VPC Peering is that it gets complicated quickly as soon as you grow to more than 3 VPCs.
Look at the number of peers with 3 VPCs, then 4. You get the idea. Establishing these is easy, but AWS has imposed a soft limit of 50 peering links. More than that, things get very complicated!
https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-connection-quotas.html
VPC Peering is also non-transitive. What does that mean?
If VPC A is Peered to VPC B, and VPC B is Peered to VPC C, then traffic from VPC A cannot "traverse" VPC B to get to C. This is why we have to use the pattern above if we want connectivity across all VPCs using Peering.
The cool thing about VPC Peering is that it can be done across Regions. So, if you have a workload that needs to replicate data from one EC2 instance to another across regions for DR purposes, you can easily set this up.
However, once the requirements get complicated, we bring in the big guns and consider implementing Transit Gateway.
Transit Gateway
AWS Transit Gateway is a service that enables you to connect multiple VPCs and on-premises networks through a single gateway. I like to think of it as a big network router that AWS manages and scales; all I need to do is manage the route tables.
A transit gateway significantly reduces the complexity introduced by multiple VPC peerings; however, it does come at a cost.
Comparing our peering example from above, 4 VPCS with Transit Gateway now looks like this. As the name eludes to it, it allows transitive traffic flows, so all the VPCs in this example are connected if the necessary routing & security groups are in place.
VPCs are attached to the transit gateway and charged by the hour. You also have to pay additional charges for traffic that passes through it. Don't let this scare you off, however. It also provides additional capabilities that are impossible without it, such as advanced routing control and native or appliance-based network firewalls.
Routing decisions are made by the transit gateway, and each VPC attachment is associated with a route table. It's a fairly advanced topic that is out of the scope of this article, but you can read more in the official documentation here
Client VPN
AWS Client VPN is a managed service that provides secure connectivity from any user's location to your AWS VPC networks. It allows users to securely access resources on AWS as if they are within the same network.
Firstly, you configure an endpoint, and then you have multiple options for authentication.
Active Directory
Certificates
Security Assertion Markup Language 2.0 (SAML 2.0)
For more information on each of these, see the documentation here
NOTE: The endpoint charges hourly, so you will be charged even when no users are connected!
Site-to-Site VPN
AWS Site-to-Site VPN securely connects your on-premises network sites to your Amazon VPC. It uses IPsec (Internet Protocol Security) tunnels to establish a secure connection. Each of the tunnels terminates to a device in an Availability Zone, providing redundancy across multiple availability zones.
AWS Site-to-Site VPN establishes persistent connectivity to your resources so your users on-premise can access them. However, it is established over the internet, so there is no guaranteed quality of the connection or bandwidth.
This is often a faster option for on-premise connectivity before establishing AWS Direct Connect, described next.
Direct Connect
AWS Direct Connect establishes a dedicated connection between your premises networks and AWS. This is where things in the Cloud get physical as the service provides a port on some physical device at a direct connect location.
Direct Connect provides dedicated bandwidth to your AWS resources but will require more work to establish. Depending on the configuration and location, you can order speeds from 50 Mbps to 100 Gbps.
As it provides a physical port, we need to consider availability. It is common to provision multiple direct connect ports to ensure an issue in the Direct Connect location doesn't disrupt our connectivity.
This is an advanced topic, and your on-premise network teams will need to be engaged. For more info, see the official documentation here.
Summary
This article discussed some options for connecting multiple VPCs and establishing connectivity for remote or on-premise users. As you progress in your AWS journey and begin to manage multiple systems, your VPCs will grow along with your AWS Accounts.
I hope you've enjoyed the VPC series!
Don't forget to check out the AWS Fundamentals VPC infographic here!
Related Reads
After reading about Amazon VPC in Part 3, continue your journey with these articles that cover the earlier parts of the series and delve into VPC endpoints. These reads will provide a comprehensive understanding of VPC: