What We Do
How We Do It
Innablr Story
Our Team
Careers
Blog
Get In Touch

Implementing Transit Gateway in a Multi Account ecosystem

By Mahesh Rayas on Mar 14, 2019

What is AWS Transit Gateway?

AWS Transit Gateway is a managed service which provides a hub-and-spoke model to connect AWS VPCs and your datacentres over VPN. AWS Transit Gateway was made generally available in Sydney region just after the re:Invent 2018.

Prior to AWS Transit Gateway

As the AWS accounts grow or the number of VPCs increase, it became hard to manage the interconnection between VPCs as the only managed available solution was VPC Peering. There are various AWS partners provided solutions but these are not supported by the AWS Support. Since VPC Peering didn’t support transitive peering the number of connections grew and thus became tough to manage. Imagine if you have 10 VPCs and they all had to be inter-connected. It would require 45 peering connections. Moreover, getting these VPCs connected to on-premises networks would require a VPN Gateway to be created in each account as well as connecting every AWS VPC to its corresponding AWS VPN.

How Transit Gateway Simplifies the Network Layout in a Multi-account Set-up?

TGW Screenshot

As mentioned earlier in the blog, AWS Transit Gateway acts as a hub-and-spoke network topology. As in the diagram above, once the Transit Gateway is created, all the routing will get configured using the route tables in a single account.

How we implemented Network layout at a client location using AWS Transit gateway?

Note: Client had only Microsoft Active Directory on-premises and we connected to it over AWS VPN.

Setting up AWS Transit Gateway

  • Create AWS Transit Gateway in Shared Services Account either using AWS CloudFormation or AWS Console. Set the property of ‘AutoAcceptSharedAttachments’ to ‘enable’ so that the VPC attachment created in other AWS Accounts can be automatically accepted by the AWS Transit gateway. It takes ~2 mins for the AWS Transit Gateway to be created. It would also create a default Transit Gateway Route Table. We would not use this default Transit Gateway Route Table instead create our own Route Table and set up smart routing.

  • Create Transit Gateway VPC Attachment TGW-ATTACH-1 by selecting the VPC that needs to be attached to the AWS Transit Gateway.

  • Share the AWS Transit Gateway with the accounts or at the AWS Organization level using the AWS Resouce Access Manager. Sharing with the AWS Organization would require a check in the settings of AWS Resource Access Manager in Master Account.

  • Once Sharing is done, login to the client account ‘Account 1’ and in VPC Dashboard -> Transit Gateway Section, the AWS Transit Gateway created in Shared Services would be visible.

  • Create Transit Gateway VPC Attachment TGW-ATTACH-2 by selecting the VPC that needs to be attached to the AWS Transit Gateway.

  • Select the Route Tables under VPC Dashboard, select the Route Table which has the subnet associated and then add the routes by adding the destination CIDR (For example, Shared Services VPC CIDR) and select Target as tgw-{id}

  • Similar setup should be done in Account 2 which would result in TGW-ATTACH-3

  • Now log into Shared Services Account, and in Transit gateway attachment, 3 VPC Attachment would be visible.

  • Create the VPN Attachment TGW-ATTACH-4 using the AWS Console or AWS Cloud formation. The VPN Attachment needs customer gateway Id to be created in prior.

  • Once VPN Attachment Id is created, a VPN Connection is created automatically in Site-to-Site VPN Connection. Download the configuration and handover to Network Team to configure the on-premises routers.

  • Configure the Subnet routing tables by adding routes of destination CIDR (For example, Account 1 CIDR & Account 2 CIDR) and select Target as tgw-{id}. Make sure there is no overlapping CIDR between the accounts.

Network Rules: we had the rules set up in such a way that the Account-1 and Account-2 could individually connect to Shared Services and also to VPN without any connections between Account -1 and Account -2. This scenario holds good if you are having PROD and DEV Accounts.

TGW Screenshot

Aws Transit Gateway Route Tables Entities in Simple Words

  • Association: FROM which Attachment (VPC/VPN) the traffic can be initiated. You can associate a transit gateway attachment with a single route table.
  • Propagation: TO which Attachment(VPC/VPN) traffic can be routed to. You can create a propagation of transit gateway attachment with multiple route tables.

Create Transit Gateway Route tables

  • Create 3 AWS Transit Gateway Route Tables using AWS Console or AWS Cloud formation.
  • FROM-Shared-Services: Route Traffic from Shared Services.
  • TO-Shared-Services-VPN: Route Traffic to Shared Services.
  • FROM-VPN: Route Traffic from on-premises to rest of other VPC.

Configuring Smart Routing Using the above Route Tables

  • FROM-Shared-Services:
    • Create Association and add the attachment created in Shared Services.
    • Create Propagation and add attachment created in Account 1 and Account 2.
    • Create Route and Add the CIDR of on-premises network by selecting the VPN Attachment.
    • The above three setups would let Shared Services route traffic to Account 1, Account 2 and on-premises.
  • TO-Shared-Services-VPN:
    • Create Association and add the attachment created in Account 1 and Account 2.
    • Create Propagation and add attachment created in Shared Services.
    • Create Route and Add the CIDR of on-premises by selecting the VPN. Attachment.
    • The above three setups would let Account 1, Account 2 route traffic to Shared Services and on-premises.
  • FROM-VPN:
    • Create Association and add the VPN attachment created in Shared Services.
    • Create Propagation and add attachments to where the traffic from on-premises needs to flow. For example Account-1, Account -2, Shared Services.

Many More Smart Rules can be created using AWS Transit Gateway Route Tables.

All above setups are automated using the AWS CloudFormation and AWS JavaScript SDK >v2.393.0.

Shortcomings while automating:

  • Currently AWS CloudFormation doesn’t support below list, but has an SDK API which doesn’t stop from Automating.
    • Sharing of AWS Transit Gateway using RAM.
    • Setting Transit gateway id as Target in Subnet Route tables.
    • Associating VPN Attachment in Transit Gateway Route Tables.
  • Name Tag created for Attachment in Client Accounts doesn’t appear in Shared Services which becomes hard to see which attachment belongs to account in Shared Services Account Web Console.

Observability

AWS Transit Gateway supports AWS CloudWatch and lets you visualise some of the key metrics. By setting a proper threshold on the metrics it can raise an alarm when the on-premises connectivity goes down. Few of key metrics are

  • BytesIn: Number of bytes received by the AWS Transit gateway.
  • BytesOut: Number of bytes sent from the AWS Transit gateway.
  • PacketsIn: Number of packets received by the AWS Transit gateway.
  • PacketsOut: Number of packets sent from the AWS Transit gateway.

Conclusion

AWS Transit Gateway is a great managed service from AWS which simplifies the network configuration. It lets the user create smart rules for network traffic across multiple AWS Accounts. And top of all the entire network layout can be 99% automated using AWS CloudFormation and APIs provided by AWS SDK.

Share this post:

Image