Hub and spoke network with AWS Transit Gateway

AWS Transit Gateway isn’t a new AWS service, but it is a significant one when your AWS environments grow. Why? Well, as your environments expand and mature, and as more workloads are moved to the AWS cloud, services need to communicate with one another. 

One way to do this is to have a copy of every service which needs to be accessed by each environment in each and every AWS account’s VPC. However, this then leads to vast amounts of wasted cost. Before long, you’re answering sticky questions about why your AWS usage bills are so high, such as:

“Wait, isn’t cloud meant to be cheaper? That’s what I was told when we started this journey.” This is definitely something I have heard on my travels. 

The answer to this is “Yes, it can be”, but like with everything, a mis-architected environment will always cost more than one which has been carefully planned and executed.

So for the problem we brought up earlier, one way around it is to implement an VPC peering between your VPCs in your AWS accounts. This provides a great and easy method to allow communication to travel between VPCs, and therefore an easy approach to creating that shared services environment. 

However, although this method has great advantages, as you start to link more and more VPCs together — and as the communication flows become more complex — this becomes a real issue to manage. This is especially true when your environment develops beyond using hub and spoke connectivity for shared services, and you find more business requirements surfacing, which then pushes you towards deploying a full mesh architecture. 

As you can see from the diagram below, even with just four VPC peered in a full mesh, this requires six peering connections. Although these are still very small numbers, it doesn’t take long before the number of peering connections becomes exhausted at the maximum of 125 per VPC.

So, how do you overcome this? How can you connect many VPCs together, simply and efficiently, without the need to manage your own software network appliance? This is where Transit Gateway comes into play.

Now, I am not saying Transit Gateway is the only method for this solution, and there are other solutions out there which will achieve the same result. However, these solutions have a greater level of management overhead. But first, a bit about Transit Gateway.

Transit Gateway was first released in the back end of 2018, and has received a raft of improvements such as peering Transit Gateways together (both cross region and within region), and more recently giving you the ability to use flow logs to monitor traffic between Transit Gateways.

With Transit Gateway, you can connect your VPCs through Transit Gateway endpoints, which are configured in a subnet in the VPC per VPC needing connectivity. Transit Gateway endpoints are configured at the availability zone level. What this means is if you configure a Transit Gateway Endpoint into a subnet in us-east-1a, all subnets which are in the same availability zone will be able to use the Transit Gateway Endpoint. 

Services running from other availability zones (let's say us-east-1b or us-east-1c) will not be able to use the Transit Gateway unless they have a Transit Gateway Endpoint added to a subnet in the same availability zone.

Now as a picture speaks a thousand words, what does this actually look like?

As you can see, from the examples above, Transit Gateway is a pretty useful service! However as with everything in the cloud, Transit Gateway has its own limitations. I have listed out several of these limitations specifically comparing Transit Gateway with VPC peering, as this is what the focus of the article has been about so far.

• VPC peering has the edge over Transit Gateway with latency, as Transit Gateway adds an additional hop for your traffic to traverse.

• There is no limit to the bandwidth for VPC peering connections, whereas with Transit Gateway you can have up to 50 Gbps per attachment.

• It is more expensive to use Transit Gateways over VPC peering as you also pay for attachment costs, as well as data processing and data transfer.

• Finally, you are unable to cross reference security groups when using Transit Gateway, whereas you can do this with VPC peering.

• You have up to 5000 attachments per region when using Transit Gateway, compared to only 125 active peers with VPC peering.

• Complexity increases as you add more Transit Gateways and as you can add 5,000 attachments per Transit Gateway this enables you to connect a large amount of VPC’s together, VPC peering on the other hand experiences a gradual increase in complexity based on the number of VPC’s you wish to connect together.

• Not only do you have the option of VPC Flow Logs with Transit Gateway as you also do with VPC peering but you also have visibility through Network Manager and Cloudwatch Metrics.

• Transit Gateway provides the ability to connect your AWS environment to a VPN or Direct Connect Connection, so all of your connected VPC’s are reachable through the Transit Gateway as well as traffic from your AWS VPC’s destined for your on premises networks.

• Lastly Transit Gateways provide the ability to control segmentation through Transit Gateway route tables whereas with VPC peering you are only able to control this through Security Groups.

Even though there are some areas VPC peering does well, the benefits for Transit Gateway in my opinion far outweigh any negatives. If you’re trying to create a properly architected environment that can scale, using AWS Transit Gateway is the best choice.

AWS provides some excellent documentation, but if you’re comfortable with AWS and networking is an area you’re interested in, I’d recommend studying for the AWS Advanced Network Speciality Certification. A Cloud Guru (A Pluralsight company) offers a certification course which can help you ace your exam. As of the time of posting, this course is being worked on to make sure you have the very latest knowledge to snag that certification.

If you’re interested in learning more about how to centralize egress traffic to the internet, check out my new course: “Centralizing Egress Traffic via AWS Transit Gateway.” In it, I cover:

• How to connect VPCs together using VPC peering

• How to connect VPCs with AWS Transit Gateway

• All about AWS Network Firewall and NAT Gateway

• How to bring this all together to build your end-to-end environment.

Keep being awesome, and good luck with your studies!