Connectivity is just the beginning. Amazon Web Services and Deloitte are committed to empowering, optimizing, and integrating digital solutions that give businesses in every industry the power to adapt and thrive.
How Transit Gateway Can Be Used to Scale Connectivity in the Cloud and your Data Center
BrandPosts are written and edited by members of our sponsor community. BrandPosts create an opportunity for an individual sponsor to provide insight and commentary from their point-of-view directly to our audience. The editorial team does not participate in the writing or editing of BrandPosts.
By Syed Gardezi (AWS) and Philippe Le Gal (Deloitte Germany)
AWS connectivity services allow customers to create and run different network architectures in their accounts. VPCs have been instrumental in allowing organizations to scale application deployments and allow for secure design patterns when it comes to migration of their on-premises services to the cloud.
A key factor is the ability to provide connectivity in a scalable fashion between applications running in the cloud and on-premises data centres. Before Transit Gateway, customers used VPC peering or Transit VPCs (which also require extra network devices) to create a mesh topology. Neither solution was scalable and this limited the ability to provide connectivity to on-premise data centres, especially as the number of VPCs grew.
Using Transit Gateway, customers can enable connectivity between different VPCs across different AWS accounts and on-premises via AWS Direct Connect or VPN. Transit gateway is a fully managed network hub that allows customers to interconnect VPCs and on-premises networks.
Transit Gateway Overview
Transit Gateway is an easy-to-setup network hub that interconnects VPCs and on-premises networks. Transit Gateway supports different attachments:
AWS Direct Connect Gateway
SD-WAN network appliance
Another Transit Gateway through Transit Gateway Peering
Let’s go through some of the features and configurable options of a Transit Gateway deployment.
A VPC attachment to the Transit Gateway results in the creation of a network interface (ENI) in the subnet selected in the Availability Zone. Once an AZ is enabled, any subnet in the AZ can route traffic through the Transit Gateway.
Multiple routing tables can be defined on a Transit Gateway to manage complex routing options. Routing tables can have dynamic and static routes in order to evaluate the next hop. Routes can be dynamically propagated to the routing tables based on the attachments. You can also add static routes and blackhole routes in case you want to isolate attachments from each other. The most specific routes are always used in the Transit Gateway. If there is overlap in the routes, they are evaluated in a specific order:
Direct Connect Gateway propagated routes
Transit Gateway Connect propagated routes
S2S VPN propagated routes
Transit Gateway for Cross Account Connectivity
The AWS Resource Access Manager is used to share a Transit Gateway between accounts for VPC attachments. The owner of the Transit Gateway can control the communication between these VPC attachments and other attachments based on the routing tables and the routes added to the routing tables.
Transit Gateway for Inter Region Peering
Transit Gateways in different regions can be peered with each other using an Inter Region peering attachment. In this way customers can create truly global network topologies for their applications. This allows customers to utilize the AWS Global Networking backbone for low-latency communication between their application resources hosted in different regions.
On-Premises Connectivity to Transit Gateway
By using a Direct Connect Gateway customers can connect from their on-premises enterprise data centres to the Transit Gateway. Redundant connectivity can also be implemented by having multiple Direct Connect connections to a Direct Connect Gateway. S2S VPN connection from a Transit Gateway can provide a backup.
Multicast protocols deliver a single stream of data to multiple receiving hosts simultaneously. It is extremely beneficial for customers running applications supporting video transcoding, financial trading systems and multimedia broadcast systems. In 2019 AWS announced support for multicast in AWS Transit Gateway becoming the first public cloud provider to offer such a service natively. Previously customers had to implement complicated overlay networks in order to migrate applications designed to use multicast.
Types of Transit Gateway Network Topologies
Here are some of the types of network topologies you can implement with Transit Gateways:
In this topology the Transit Gateway acts as a centralized router. The Transit Gateway connects all the attached VPCs, Direct Connects and S2S VPN sessions. All attachments can route packets to each other. This supports transitive connectivity (VPC A to VPC C for example.)
In this topology different VPCs are able to route to the on-premises environment via the Direct Connect or S2S VPN attachment but are isolated from each other. Here the transit gateway acts as multiple isolated routers by having different routing tables for the attachments.
Isolated VPC with Shared Services
This topology is similar to the previous one with the addition of the Shared Services VPC. Each VPC attachment can route to on-premises and the Shared Services VPC but not each other. This pattern is quite common in production scenarios.
Peering Transit Gateways
In this topology Transit Gateways in different regions are peered together to create a global network backbone that allows VPCs in different regions to route traffic between each other. It also allows customers to route traffic from their on-premises environments to VPCs hosted in different regions.
Centralized Outbound Routing
In this topology, you can set up all outbound internet routing to go through a central VPC with an Internet Gateway attached, and thus none of the other VPCs need an Internet Gateway or public subnets. This is sometimes a requirement for enterprise-grade deployments.
Appliance Shared Services VPC
This topology allows you to host Shared Services appliances (such as a security appliance) in a VPC and have all traffic from other attachments routed via this appliance. The appliance can be used to inspect all traffic that passes through it.
Deloitte Using Transit Gateway to Simplify Spoke Accounts VPCs Deployments
Deloitte Continental Europe (DCE) has implemented a networking solution based upon the AWS Transit Gateway service using the Appliance Shared VPC design. Transit Gateway is a key component that allows Deloitte to scale the deployment of their service to their customers in a cost-effective manner.
By peering with other AWS Transit Gateways in identical or other regions the connection is rapidly globally enabled and available between Deloitte member firms and customer’s VPCs. It also makes the overall customer solutions global by default.
In this architecture the Transit Gateway acts as the central point to connect to another internal Service Hub which provides applications VPCs with a number of services like service publishing, ISP, North/South filtering, IDP, DNS. Customer spoke VPCs are attached to the Transit Gateway in a multi-account setup. The whole solution uses infrastructure as code to provide automation and thus teams can support a large number of clients with diverse connectivity requirements.
Transit Gateway allows the above architecture to be implemented in simplified manner with connectivity centrally managed between the different service VPCs and also on-premises.
For Deloitte DCE the AWS transit gateway is used to interconnect core networks, spoke accounts as well as some shared services the likes of DNS and network inspection services. Using multiple routing tables, Deloitte DCE can segregate traffic and enforce traffic inspection, especially East-West traffic.
The AWS transit gateway fulfils connectivity needs both inter- and intra-AWS regions. With transit gateway peering (at the moment inter region) Deloitte DCS has built a backbone of pan-European network connectivity between the Deloitte internal networks and pre-existing edge networks. This allowed Deloitte to deploy within weeks a backbone of core European connectivity on the top of the AWS global infrastructure over multiple AWS European regions.
The use of the AWS Transit Gateway product allows Deloitte to offer a network deployment process for new spoke accounts which is repeatable, automated and scalable.
AWS Transit gateway also allowed Deloitte to deploy spoke VPCs efficiently and in a scalable way. By using Infrastructure as Code (IaC), Deloitte can deploy a security vetted and pre-configured multi-AZ network topology inside a VPC in a spoke account, and attach the VPC to the AWS transit gateway, giving a spoke account access to Deloitte services in a matter of minutes.
This blog post shows how you can use Transit Gateway to implement different network topology that can be crucial to your application design. It also shows an example of how Deloitte has used the Transit Gateway as a key central component of our global architecture.