Amazon Web Services introduced the AWS Transit Gateway service in November 2018 to enable customers to connect multiple Virtual Private Clouds (VPCs) without having to rely on point-to-point IPsec tunnels. AWS Transit Gateway enables a hub-and-spoke model with centralized control of traffic routed among VPCs. This reduces operational costs and management complexity and makes it easier to scale the network as more VPCs are added.
Figure: Thanks to AWS
First, some background. A VPC is a logically isolated section of the AWS cloud that gives you control over IP addresses, subnets, routing tables and network gateways. This makes it possible to put protected resources in a private-facing subnet and web services in a public-facing subnet, adding layers of security as needed to control access.
Amazon found that organizations were setting up Transit VPCs with firewalls or routing instances in their core to create a global network connecting multiple VPCs and remote resources. However, it required a lot of manual work or careful scripting to set up all of the IPsec tunnels needed for dynamic routing. The AWS Transit Gateway service was developed to address this common customer challenge.
The Transit Gateway makes it possible to create a shared VPN for multiple VPCs within one AWS region. The Transit Gateway contains a master routing table that also enables you to connect to services such as authentication and monitoring that are implemented in various VPCs. You can even create a security VPC that sits between the Transit Gateway and the Internet and provides a firewall, web application filtering, data loss prevention, and other services. The traffic flowing between the Internet and your protected resources gets allowed or denied according to policy.
You can leverage other Amazon tools, including the CloudFormation and provisioning tool, Lambda serverless computing, and the CloudWatch monitoring and alerting tool. However, the Transit Gateway only supports AWS connectivity, although it’s possible to link to other clouds through IPsec VPN connections.
Transit Gateways currently do have some limitations. Transit Gateways do not support multi-region connectivity. You are adding more hops before traffic is reviewed by the firewall, so added latency may be an issue. Also, your routing table is going to get bigger and bigger because you won’t be able to use route aggregation. You have to consider whether a Transit Gateway will be beneficial given these limitations.
When designing a Transit Gateway, we first look at the customer’s connectivity requirements. What is the data flow model between VPCs? Does anything need to be isolated or do all the VPCs need to talk to each other? These are some of the questions we will ask as we sit down with the customer to whiteboard the solution. We will then perform discovery and design the network according to best practices, and move forward with implementation, deployment, and validation.
One of the success criteria we look for is whether the Transit Gateway is able to “attach” to every resource that we have asked it to attach to. Is the routing information correct? Is the data traffic flowing as designed? Furthermore, given that we have a hub-and-spoke model, we also need to look for asymmetric routing. A packet needs to enter and exit the network in the same way to minimize any discrepancies.
Organizations with multiple VPCs need an efficient way to interconnect them and to connect to remote services. The Rahi Systems’ Network Services team can help you leverage the AWS Transit Gateway service to simplify this process.
Author: Shreyans Desai
Shreyans Desai is a Solutions Architect at Rahi Systems, on the Networking PSE team. Prior to Rahi Systems, he was a Solutions Engineer focusing on networking automation and systems. His experience includes enterprise data center and service provider routing, switching, and security solutions for multiple vendors (Juniper Networks, Cisco, Palo Alto Networks, Arista, and Huawei), and also has a deep understanding of cloud computing solutions from Amazon Web Services (AWS) and OpenStack.
