SHOULD I USE A 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. In this post, I’ll try to help formulate those questions so you can answer this question yourself.

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. AWS’s website highlights Aviatrix and Cisco solutions, but I’ve also seen Palo Alto firewalls used as well. Really any virtual router should be able to be used with this process, so you pick your favorite solution.

The reference architecture uses a pair of virtual routers split between Availability zones. Routing between VPCs, etc would spin up a VPN tunnel to the transit routers so that routing can then be controlled through these routers installed on ec2 instances.

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 set up 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.

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.

Its Traditional Data Center Methodologies

One of the bigger considerations to contemplate is how you want to operate your cloud. Some of the benefits of cloud are things like Infrastructure-as-Code (IAC). Developers may be looking to spin up their resources and have them access the Internet through their own means. Application code and infrastructure code is coupled together to provide a full solution all on their own. If you add a transit VPC to the mix to provide service chaining, for example, the application developers may need to open a ticket to have a network engineer set up NAT on the transit routers. Or perhaps open up some ACLs within the router so that the app can talk to the outside. This is a common scenario in on-premises environments, so nothing new, but do we need to change how we think when moving to the cloud? This ideology is a conversation that should happen early on when developing a cloud strategy.

Summary

Transit VPCs are a pretty nifty solution to provide some controls to your AWS cloud. There are pros and cons for using a transit VPC, but hopefully this post has shown you what sort of things should be discussed and considered before jumping into your architecture designs. The table below should help formulate your decisions.

A transit VPC should be considered early on so that a retrofit isn’t required for your cloud environment.

To stay up-to-date on the latest in tech news and events, follow AHEAD on Twitter and LinkedIn or subscribe to our newsletter above.

Contributing Author: Eric Shanks