SIMPLIFYING YOUR AWS NETWORK ARCHITECTURE WITH TRANSIT GATEWAY
If you’ve been following the updates out of AWS re:Invent 2018, you know it was a crazy week of Launches, Pre-Views, Announcements, and Pre-Announcements. There was one announcement in particular that may not have been as flashy as AWS DeepRacer, but caused many Cloud Architects like us to perk up nonetheless. Last week, AWS announced the launch and general availability of AWS Transit Gateway. There is no doubt that this will have a critical impact on enterprise cloud networking and will significantly reduce complexity. In this post, we’ll break down just how much this simplifies cloud operating models so that you can see why we’re so excited.
The Old Way: AWS Transit VPC
Before we get into the details of what AWS Transit Gateway is, it’s important to first lay the groundwork of ‘why?’.
Most organizations are faced with implementing security controls between internal and external users and public cloud workloads, driven primarily by security policies and/or regulatory requirements. In some cases, native AWS controls like security groups are sufficient, but in others, a deeper level of control and auditability–not to mention consistency with existing on-premises systems–may be required.
Within public cloud providers like AWS, this has led to segmenting resources in separate accounts and VPCs as a form of compartmentalization and control. On its face, this is not so different than what can be readily found in customer-owned environments–i.e., DMZs controlled by firewalls. Exactly how to implement and monitor these controls comes down to cost, functionality, and integration capabilities.
This architecture has pushed organizations to use third-party, EC2-based appliances and VPNs to interconnect VPCs together when native VPC peering wasn’t sufficiently functional to meet their needs. Using EC2-based solutions also allows organizations to limit traffic between applications and resources residing in different VPCs. For the past few years, the AWS Transit VPC has been a go-to solution for organizations looking to provide connectivity between shared resources across VPCs to on-premises based resources, or as a method to aggregate egress traffic to the Internet.
Although functional and–if designed carefully–scalable, the AWS Transit VPC solution introduces complexities. Namely, for some organizations, the design and operation of complex BGP policies for AWS environments often present a series of challenges. If organizations wanted a more DevOps-friendly Transit VPC solution, the complexities that came with providing a method to fully-automate and manage the creation of VPN tunnels and BGP peering sessions could also be challenging to adopt. Most pre-written automated transit VPC solutions are community-supported and often require customization.
The New and Simple Way: AWS Transit Gateway
This brings us to the AWS Transit Gateway announcement. Freshly unveiled at AWS re:Invent 2018, Transit Gateway brings the same hub and spoke design that we all know and love from Transit VPC, but sans some of the challenges associated with leveraging non-native AWS solutions and EC2 based appliances (i.e. Cisco CSRs).
AWS Transit Gateway allows customers to connect multiple VPCs, on-prem data centers, remote offices, etc. to a single managed AWS Transit Gateway while also providing full control of network routing and security. Most excitingly, AWS Transit Gateway enables you to attach up to 5,000 VPCs, which is the scalability that enterprise customers have been asking for. Based on the documentation, there does appear to be a soft limit of 1,000 attachments, which can be increased, though the impact of increasing past 1,000 is yet to be determined.
In its current implementation, AWS Transit Gateway allows dynamic propagation of routes from VPCs as well as VPN connections attached to the TGW. Direct connect support is expected in 2019. It’s also important to note that the AWS Transit Gateway is only available in select regions at the time of this writing, with the expectation that AWS will soon roll this out to other regions.
Digging deeper, there are two ways in which routes are propagated in the AWS Transit Gateway. First is via BGP for external routes from VPN attachments (AWS Direct Connect is coming soon) and then via internal APIs for VPC attachments. One difference between routing with TGW vs. a Virtual Private Gateway (used in VPN-based Transit VPC designs) is that routes from the TGW are not dynamically propagated to the VPC subnet routing table (not to be confused with the TGW routing tables, which can/will be propagated to dynamically depending on the attachment type). In order to send traffic to the TGW, you have to add static routes to send traffic a TGW. The TGW’s route table limit far exceeds the number of routes a VPC route table can handle, so network summary addresses that are statically configured can be used to get traffic to TGW.
Lastly, the biggest stand-out feature of AWS Transit Gateway is the concept of Routing Tables (VRFs for the networking folks) TGW route tables, which will allow you to create multiple routing domains for isolating specific VPC-to-VPC connectivity. To us, this introduces the simplified enterprise networking capabilities via the TGW that our customers demand.
In the example below, we’re using the same Transit Gateway with three Route Tables to control traffic to security zones on our Palo Alto VM-Series running in AWS. This allows us to leverage the feature-rich packet inspection we want and need and does so with a level of simplicity that was previously not available.
It is important to continue to reference AWS documentation for updated limitations. Availability and limitations are continuously being updated and expanded. Also, as is true with traditional networking, cloud networking designs are very much dependent on requirements and uses cases. For more information on public cloud networking, you can schedule time with our experts at the AHEAD Executive Briefing Center and request this topic specifically.