Using Transit Gateways on AWS for Network Optimization

?? **Elevating Network Infrastructure with Transit Gateways: A Terraform Success Story**

Our team at GMS (gmobility.com) is thrilled to share a recent triumph where we collaborated with a client to revamp their network infrastructure using Terraform. One of the key highlights of this transformation was the introduction of transit gateways, which replaced the previous VPN tunnels connecting to each VPC. This strategic shift brought significant benefits in terms of network management, scalability, and security. Let’s dive into the details! ??

Here is a similar example of how the network architecture looked before the transit gateway implementation:

**The Challenge:**

• The client’s network architecture consisted of VPN tunnels connecting each VPC, resulting in a complex network configuration and a heavy burden on the onprem network team.
• The client wanted to add a new app into their infrastructure that would be managed by an external team. They would give this team access to the environment through AWS Workspaces. However their current Workspace account had a single VPC designed for internal users only. Creating external users in this workspace VDI would create a security hazard because they would have access to internal resources.
• Managing multiple VPN connections became challenging, time-consuming, and prone to errors. Moreover, it limited the client’s ability to scale and adapt their network infrastructure efficiently.
• The client wanted to add on more AWS accounts to onboard an external app team and limit their access to their existing AWS accounts.
• The new AWS accounts they wanted to add had to be designed to communicate with specific instances inside their existing AWS accounts to only select few VPC’s.
• The new app accounts needed failover configured to us-west-2

**The Solution:**

• Working closely with the client, we introduced transit gateways as a scalable and efficient alternative to VPN tunnels, providing a centralized hub for routing traffic between VPCs. Our client was using site to site vpn connections directly from on prem customer gateways to different AWS accounts. Each account had two vpn connections to multiple vpc’s inside of it for failover. The client was running out of address space and having a hard time managing so many vpn connections. We decided to introduce a network hub account which has two vpn connections to on prem (one connection for failover) and a transit gateway to route traffic to the rest of the aws accounts.
• The cool thing about this setup was there’s no need for a vpn gateway on the AWS side. You can directly connect customer gateway to the transit gateway.
• Another thing to keep in mind is that transit gateways have their own routing table. They exist at the account level and not inside a VPC, therefore not using normal routing tables
• From the network hub account we used AWS Resource Access Manager and transit gateway attachments to associate each of the AWS accounts to the network hub. Transit gateway attachments allow traffic to be sent to the transit gateway and back.

• You can see from looking at this diagram that each of the vpc’s has a transit gateway attachment that points to the transit gateways in the network hub account
• There are two transit gateways in the network hub account (one for us-east-1 and the other for us-west-2 designed for high availability)
• There are two VPN tunnels from the customer gateway connecting directly to the transit gateways (instead of connecting to a vgw as before) from two different providers (WOW and Comcast) for high availability
• If you look at the Workspaces account, you can see we added a new VPC named “New App VDI”. This segments the new app users from the rest of the environment. We used new route tables to specify routes for this new Workspace VPC to only the new app accounts (new app non prod & new app prod). This was great way to ensure security by not allowing external users access to the existing resources

Below is a high level example of how we configured our terraform code to include transit gateway configuration including connecting the customer gateway to the network hub.

provider "aws" {
  region = "us-west-2"  # Replace with your desired AWS region
}

resource "aws_ec2_transit_gateway" "network_hub" {
  description = "Network Hub Transit Gateway"
}

# Network Hub (Account A) - Customer Gateway Connection
resource "aws_ec2_transit_gateway_vpn_attachment" "vpn_attachment" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpn_gateway_id           = "your_customer_gateway_id"  # Replace with the ID of your Customer Gateway
  transit_gateway_default_route_table_association = true
  transit_gateway_default_route_table_propagation = true
}

# Network Hub (Account A) -> Workspaces (Account B) Connection
resource "aws_ram_resource_share" "share_account_b" {
  name        = "Transit Gateway Share - Workspaces (Account B)"
  allow_external_principals = true
}

resource "aws_ram_principal_association" "associate_account_b" {
  resource_share_arn = aws_ram_resource_share.share_account_b.arn
  principal          = "account_b_id"  # Replace with the ID of Workspaces (Account B)
}

resource "aws_ram_resource_association" "associate_transit_gateway_b" {
  resource_share_arn = aws_ram_resource_share.share_account_b.arn
  resource_arn       = aws_ec2_transit_gateway.network_hub.arn
}

# Network Hub (Account A) -> New App Non Prod (Account C) Connection
resource "aws_ram_resource_share" "share_account_c" {
  name        = "Transit Gateway Share - New App Non Prod (Account C)"
  allow_external_principals = true
}

resource "aws_ram_principal_association" "associate_account_c" {
  resource_share_arn = aws_ram_resource_share.share_account_c.arn
  principal          = "account_c_id"  # Replace with the ID of New App Non Prod (Account C)
}

resource "aws_ram_resource_association" "associate_transit_gateway_c" {
  resource_share_arn = aws_ram_resource_share.share_account_c.arn
  resource_arn       = aws_ec2_transit_gateway.network_hub.arn
}

# Network Hub (Account A) -> New App Prod (Account D) Connection
resource "aws_ram_resource_share" "share_account_d" {
  name        = "Transit Gateway Share - New App Prod (Account D)"
  allow_external_principals = true
}

resource "aws_ram_principal_association" "associate_account_d" {
  resource_share_arn = aws_ram_resource_share.share_account_d.arn
  principal          = "account_d_id"  # Replace with the ID of New App Prod (Account D)
}

resource "aws_ram_resource_association" "associate_transit_gateway_d" {
  resource_share_arn = aws_ram_resource_share.share_account_d.arn
  resource_arn       = aws_ec2_transit_gateway.network_hub.arn
}

# Workspaces (Account B) VPCs
resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_attachment_b1" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpc_id                   = "vpc_b1_id"  # Replace with the ID of Workspaces (Account B)'s VPC 1
  subnet_ids               = ["subnet_b1_id"]  # Replace with the IDs of Workspaces (Account B)'s VPC 1 subnets
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_attachment_b2" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpc_id                   = "vpc_b2_id"  # Replace with the ID of Workspaces (Account B)'s VPC 2
  subnet_ids               = ["subnet_b2_id"]  # Replace with the IDs of Workspaces (Account B)'s VPC 2 subnets
}

# New App Non Prod (Account C) VPCs
resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_attachment_c1" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpc_id                   = "vpc_c1_id"  # Replace with the ID of New App Non Prod (Account C)'s VPC 1
  subnet_ids               = ["subnet_c1_id"]  # Replace with the IDs of New App Non Prod (Account C)'s VPC 1 subnets
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_attachment_c2" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpc_id                   = "vpc_c2_id"  # Replace with the ID of New App Non Prod (Account C)'s VPC 2
  subnet_ids               = ["subnet_c2_id"]  # Replace with the IDs of New App Non Prod (Account C)'s VPC 2 subnets
}

# New App Prod (Account D) VPC
resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_attachment_d" {
  transit_gateway_id       = aws_ec2_transit_gateway.network_hub.id
  vpc_id                   = "vpc_d_id"  # Replace with the ID of New App Prod (Account D)'s VPC
  subnet_ids               = ["subnet_d_id"]  # Replace with the IDs of New App Prod (Account D)'s VPC subnets
}        

**The Benefits of Transit Gateways:**

? **Simplified Network Management:** The introduction of transit gateways reduced the complexity of network management by consolidating network traffic routing and eliminating the need for individual VPN connections to each VPC.

? **Enhanced Scalability:** With transit gateways, the client gained the ability to easily add new VPCs without the hassle of setting up additional VPN tunnels. This streamlined expansion ensured their network infrastructure could scale effortlessly as their business grew.

? **Improved Security and Control:** Transit gateways offered granular control over network traffic flow, enabling the client to implement consistent security policies and manage access to resources across all VPCs from a centralized location.

? **Simplified Connectivity:** The deployment of transit gateways simplified connectivity between VPCs, eliminating the need for complex and error-prone VPN configurations. This resulted in improved network performance and reduced latency.

? **Cost Optimization:** By replacing multiple VPN tunnels with a single transit gateway, the client achieved cost savings by reducing the licensing, maintenance, and operational expenses associated with managing numerous VPN connections.

Through our Terraform-powered approach, we seamlessly incorporated transit gateways into the client’s network infrastructure. By leveraging infrastructure-as-code principles, we ensured that the deployment of transit gateways was consistent, repeatable, and easily auditable.

This transformative shift to transit gateways and the use of Terraform allowed us to orchestrate this change efficiently, empowering the client to optimize network management, enhance scalability, and fortify their security posture.

Join us on this journey of network transformation and leverage the power of transit gateways to unlock the full potential of your network infrastructure.

Check out our website at?www.gmobility.com.?We provide AWS Cloud & DevOps solutions to enhance your infrastructure.

#GMS #NetworkInfrastructure #Terraform #TransitGateways #NetworkManagement #Scalability #Security #Innovation