CODEWITHSUNDEEP
amazon-web-services
Garreth
Garreth

Reputation: 1095

AWS Transit Gateway Routing

I am implementing a Transit Gateway in a dedicated Transit Gateway account. Im then looking at connecting upto 6 AWS VPCs from separate accounts. I believe I need to add all 6 Transit Gateway attachments to the same Transit Gateway route table to allow connectivity between them - as AWS does not let you associate a TGW Attachment with more than one TGW Route Table.

This works and all VPCs can talk to each other - but what's the best practice to control access between VPCs. Lets say D is the Transit Gateway account.

VPC A/B/C/D are all on the TGW route table. What if I don't want VPC A to talk to VPC B, but allow VPC A to talk to VPC C. I know that this won't occur unless I add the subnet VPC routes in/propagate them but Id like more control.

For example two TGW route tables, one with the TGW Attachment (D), VPC A, VPC B. Another TGW route table with the TGW Attachment (D), VPC A, VPC C.

I presume one way to do it would be to add NACLs to the Transit Gateway subnets, but that would only block entire VPCs.

Upvotes: 1

Views: 2539

Answers (4)

deepanmurugan
deepanmurugan

Reputation: 2113

You have to design you network according to your needs.

For example we have 4 VPC - VPC A,B,C,D.

Requirement:

What if I don't want VPC A to talk to VPC B, but allow VPC A to talk to VPC C. I know that this won't occur unless I add the subnet VPC routes in/propagate them but Id like more control.

In Design:

VPC A <--> VPC C VPC A <--> VPC D

You need to create couple of things:

  1. Transit gateway - tgw

  2. Transit Gateway Attachments: Attach all VPC A, C, D to transit gateway which you created. Attachment A (VPC A) --> tgw Attachment C (VPC C) --> tgw Attachment D (VPC D) --> tgw

  3. Transit Gateway route table (tgw-rt1): Create transit gateway route table and associate with all the attachments (A,C and D). Create propagation and add all the attachments A, C and D. That will generate a routes automatically.

Here is the the flow, when traffic originates from VPC A to VPC C. Subnet in VPC A should have a route to tgw, so the traffic reaches tgw. tgw looks from which attachment the traffic came from and its attachment A (i.e. VPC A) and finds the respective route table tgw-rt1. Now the tgw-rt1 has routes to propagate the traffic to respective attachment (i.e. VPC C). And this is just a one way, in order to make the traffic flow back to VPC A, you should have route in your VPC C also.

Upvotes: 1

risker
risker

Reputation: 46

As of September 2020, there were quite a few changes on the TGW configuration, so an update could be helpful here.

We deployed something similar with a TGW and 3 Routing tables (Hub and Spoke model as stated earlier).

TGW Attachments

  • TransitVPC
  • VPC A
  • VPC B
  • VPN On-Premise

Routing tables:

  • Isolation (Default association table)
    • 0.0.0.0/0 with next hop TransitVPC
  • On-Prem (association: attachment VPN)
    • Static route entries for all attached VPCs with next hop TransitVPC. Routing entries as necessary for BGP propagation
  • TransitVPC (Default propagation table)
    • contains routes for all attached VPCs with the related VPC as next hop

The TransitVPC contains now a NVA (Network virtual applicance, e.g. Fortigate, Barracuda, Palo Alto). The NVA has two interfaces for private and public connection and therefore two routing tables:

  • Private subnet (attached to Transit gateway!)
    • 0.0.0.0/0 private eni of first firewall node (routing table will be rewritten, when cluster fails over to the second node. See related documeantation of the vendor).
  • Public subnet (optional, needed in case of inet access for VPCs)
    • 0.0.0.0/0 IGW/NatGW (depends on your needs)

The NVA will use its own builtin routing table with transit gateway eni IP addresses as next hop, otherwise it will loop in the private subnet routing table.

You are able to deploy a working access control/IDS/IPS/AV/xxx solution with this setup and isolate all traffic based on firewall policies.

This setup is also able to host a shared service (VPC Endpoints) VPC with the help of route53.

Upvotes: 0

Yalavarthi Narendra
Yalavarthi Narendra

Reputation: 1

In a Hub and Spoke model : Account A = Hub Account B, C, and D = Spokes

Usecase 1 - Accounts B , C & D can communicate with Account A.

Usecase 2 - Accounts B and C can communicate with each other directly

Only difference between them as for as setting up TGW is, the route tables . VPC Route tables : Account B VPC will have a route to Account C CIDR & TGW ID ( TGW defined in account A ) Account C VPC will have a route to Account B CIDR & TGW ID ( TGW defined in account A )

and

TGW Route tables : Account B TGW Route table is propagated to Account C Attachment Account C TGW Route table is propagated to Account B Attachment

In this scenario Account B and C do not communicate with A because there is no VPC route table and there is no TGW route propagation to VPC A attachment.

refer to this documentation for complete terraform code and explanation for this scenario

http://i-cloudconsulting.com/aws-transit-gateway-hub-and-spoke-model/

Upvotes: 0

Garreth
Garreth

Reputation: 1095

In answer to the question, the pattern should be as follows...

Each VPC should have one Transit Gateway Attachment. Each VPC should have a Transit Gateway Route Table created. Each Transit Gateway Route Table should be associated to that Transit Gateway Attachment. Routing rules should then be added to the Transit Gateway Route Table as egress rules.

In this example, VPC A and B can communicate and A and C. But B can only talk to A.

VPC A (10.10.10.0/16) <-> TGW ATT A
VPC B (10.10.11.0/16) <-> TGW ATT B
VPC C (10.10.12.0/16) <-> TGW ATT C

TGW RT TBL A
10.10.11.0/16 (VPC B) -> TGW ATT B
10.10.12.0/16 (VPC C) -> TGW ATT C

TGW RT TBL B
10.10.10.0/16 (VPC A) -> TGW ATT A

TGW RT TBL C
10.10.10.0/16 (VPC A) -> TGW ATT A

In addition subnet routing rules will need to be added to VPCs and SGs opened.

Upvotes: 0

Related Questions