What are the differences in segmenting my development VPCs from my production VPCs when using multiple AWS Transit Gateways (TGW) or a single Gateway?

While it is possible to segment instances in VPCs with security groups, there has not been an easy way to segment groups of VPCs and on-premises networks until the AWS Transit Gateway (TGW).

AWS Transit Gateway (TGW), is a new service announced at Re:Invent 2018 that allows customers to interconnect thousands of Virtual Private Clouds (VPCs) and on-premise networks. The service is available per region. While it is possible to segment instances in VPCs with security groups, there has not been easy way to segment groups of VPCs and on-premises networks until the AWS Transit Gateway (TGW). With AWS Transit Gateway (TGW) there are two main approaches:

1. segmenting VPC and on-prem networks with multiple AWS Transit Gateways (TGW), or
2. segmenting with multiple route domains in a single AWS Transit Gateway (TGW)

Of these, using route domains has many advantages. Let’s look at a basic scenario and walk through both approaches. First, we’ll consider a typical environment consisting of:

• 2 shared services VPCs
• 3 development VPCs
• 3 production VPCs
• 1 on-premises network with site-to-site VPN

With the additional requirement that:

• development VPCs cannot reach the production VPCs
• shared services VPCs can reach all other VPCs and on-premises networks
• on-premises can reach all VPCs

Using two transit gateways to achieve segmentation: Additional configuration needed

In this case, you would create one AWS Transit Gateway (TGW) for development VPCs and one transit gateway for production VPCs. Each VPC would be attached to their corresponding AWS Transit Gateway (TGW) default route table. Each AWS Transit Gateway (TGW) could be thought of as switches which are completely separated from each other. To handle the on-prem connections, the switch-like separation means creating multiple site-to-site VPNs to the on-premises networks. This reduces one of the benefits of edge consolidation, the more AWS Transit Gateways (TGW), the more edge VPN connections that typically require change control processes. To handle the VPC-to-VPC connections, the shared service VPCs would need to be attached to each of the two AWS Transit Gateways (TGW). This would increase the number of attachments and AWS Transit Gateway (TGW) attachment charges.

Using one transit gateway and multiple route domains to achieve segmentation: Simple and secure

Instead of a separate switch concept, this would be like using VLANs. In this case, you would create one AWS Transit Gateway (TGW) and four route domains: development, production, shared services, and on-prem.

Here is where AWS Transit Gateway (TGW) route table propagations come in handy. The propagations would be enabled for these route tables:

• Shared Services to Dev, Prod, On-Prem
• On-Prem to Shared Services, Dev, and Prod.

Then the routes would need to be updated in the route tables. This can be a very manual process without automation – keep reading to see how Aviatrix does this with 3 simple steps. To configure #1, the routes from the Shared Services VPCs would need to be added to the Dev, Prod, and On-Prem route table. The VPC CIDR ranges from the Dev, Prod, and On-Prem route table would need to be added to the Shard Services Domain route table. A similar set of configurations would need to happen for #2.

As you can see, route domains provide an easy way to provide isolation between your VPCs while providing policy-based connectivity between them. When you have new VPCs, simply attach them to their corresponding VPC and update the route tables. Is there any scenario where you’d want multiple AWS Transit Gateways (TGW)? The answer is likely, no. If you know about route domains, you know they can solve for segmentation with more completeness and flexibility rather than deploying an additional AWS Transit Gateway (TGW). One possible scenario would be if you had two completely separate departments in your organization that would like their own gateway to control for themselves, with little need for sharing data between departments.

Aviatrix orchestration of AWS Transit Gateway (TGW) and Route Domains

The Aviatrix mantra is to make networking simple. As such, Aviatrix co-developed further simplicity by include orchestration of AWS Transit Gateway (TGW). This automates the ability to segment your VPCs when using route domains even easier. Instead of tedious route table updates, Aviatrix software-defined approach provides dynamic route propagation of the spoke VPC CIDR ranges. Click here to read more about AWS Transit Gateway (TGW) Security Domains. As part of the orchestration, Aviatrix provides you with the added benefits of auditable policies, compliant connectivity, and a whole host additional edge and multicloud support capabilities.

The key takeaways

• AWS Transit Gateway (TGW) Route Domains provides a flexible way to provide both connectivity and segmentation
• Aviatrix provide orchestration of AWS Transit Gateway (TGW) to make it even easier for cloud engineers to create grouping of VPCs