What is Transit VPC in AWS?

A common question that comes up during AWS designs is, “Should I use a transit
VPC?” The answer, like all good IT riddles is, “it depends.” There are a series of
questions that you must ask yourself before deciding whether to use a Transit VPC or
not.

1. The Basics
Before we can ask those tough questions, we first should answer the question, “What
is a Transit VPC?” Well, a transit VPC acts as an intermediary for routing between two
places. Just like a transit network bridges traffic between two networks, a transit VPC
ferries traffic between two VPCs or perhaps your data center.
There isn’t a product that you buy called a transit VPC, but rather a transit VPC is a
reference architecture. Multiple products can be used to build this transit VPC, but the
really good ones have a method to add some automation to the process.

2. Why Might I want a Transit VPC?

Now that we know what a Transit VPC is, what use cases might warrant me using a
transit VPC?

Simplify Networking
If you’ve got a multi-account, multi-VPC strategy for your deployments, connecting all
of those VPCs together can be a real mess. If you’re implementing peering
connections for a full mesh, the formula to calculate that is: [(n-1)*n]/2. Setting this up
and managing it can be a real chore. Take a look at the below example to see how
you can quickly get overwhelmed by the number of connections to maintain. Think
how this changes every time you add a new VPC.

Now we can avoid some of this complexity by moving to a hub and spoke model,
where the Transit VPC is the hub. We still need to setup connections, but we can at
least manage our connections to on-prem through a centralized location. Also, what
would happen if we added a new VPC to the hub and spoke model? That’s right, one
new connection back to transit instead of modifying all connections across every VPC.
Funnel Traffic
How do you want to manage your traffic out to the Internet, or in from the Internet? Do
you allow traffic in and out of each of your VPCs? You can certainly do just that, but
how comfortable are you with having multiple egress or ingress points to your
environment? The diagram below shows a full mesh of VPCs again, this time adding
a red line for an Internet connection and a connection back to your on-premises data
center.
NOTE: refusing to draw diagrams like the one below is another valid use case for
moving to a hub/spoke model instead of mesh.

Many times I hear the need to place restrictions on Internet ingress traffic such as
packet inspection, IDS/IPS, etc. AWS provides a Web Application Firewall, which is
nice, but some corporations will require something more than that. On the flip side,
some companies require things like content filtering for all outbound Internet traffic.
Does it make sense to deploy content filtering solutions in each of your VPCs, or
should you centralize it in a single place, like a Transit VPC? The hub spoke model
allows us to funnel all of our traffic through the Transit where a firewall or other device
might be able to take action on the traffic. Then a single ingress/egress point can be
managed in/out from the Internet and to the corporate data center.
3. Why Shouldn’t I use a Transit VPC?

Costs
A drawback to using a Transit VPC is costs. A Transit VPC will have a couple of
different effects on your AWS cloud costs. The first is obviously the need to deploy a
pair of EC2 instances in the transit VPC. You’ll be responsible for these two instances
running as either On-Demand or Reserved Instances to save on costs. In addition to
the EC2 costs, you might also need to purchase a license from Cisco, Aviatrix, etc., to
run their software. These costs are pretty easy to calculate, once you size your
instances appropriately.
A more difficult cost consideration is around your network traffic. AWS charges you for
any network traffic exiting (egress) your VPC. In the diagram below (left), you can see
how this works with a single VPC directly accessing the Internet. On the right side, you
can see what happens to egress costs when you have a transit VPC instead. With a
transit VPC we’d get billed twice for the traffic because it exits two VPCs. Keep this in
mind for traffic inter-VPC as well, between a Shared Services and Prod environment
for example.
One other cost consideration is your VPN tunnels. AWS also charges for VPN tunnel
connection hours. The transit VPC relies on VPN tunnels to spoke VPCs to provide
the overlay networking. These VPN tunnels come with a small charge per month to
have them up and running.