AWS Transit Gateway isolated routing with Shared Services
Hello,
We are working with a client that has the following setup: 1 TGW that has 5 VPC attachments
- non-prod a attachment
- non-prod b attachment
- prod-a attachment
- prod-b attachment
- shared-services attachment
Requirements: The client would like to allow only for inter-communication of both the non-prod VPCs, as well as the prod VPCs. Additionally, the client would like for shared-services to be able to reach any of the VPCs.
My initial approach and the problem: Initially, my thought was to create 3 isolated routing domains, which were represented by 3 separate TGW route tables. I was unable to achieve this because there is a limitation of only being able to associate 1 attachment with 1 TGW route table. If we were able to make more than one attachment for the same VPC, we could get around this issue, but unfortunately that is not possible.
Looking for recommendations on the best way to address the above requirements.
The only other option I can think of to accomplish these requirements is to use 1 TGW route table, associate all of the attachments with it, and then ultimately use NACLs in the individual VPCs to restrict traffic. To me, this seems like a pain to maintain, so I wanted to see if there are any other ways to address this problem.
More Information on what I've already tried
My initial idea was to have 3 TGW route tables (one for each "routing domain"):
- non-prod (associated with the non-prod-* attachments)
- prod (associated with the prod-* attachments)
- shared (associated with all attachments)
The problem with this approach is the shared TGW route table because as I mentioned above, you can't associate an attachment with more than one route table. In essence this is a "flat" routing architecture rather than isolated and directly contradicts with what I'm trying to do causing this problem.
Thanks in advance!
I think this gets what you need?
NPA and NPB attachment Route Table:
NPA CIDR --> NPA attachment
NPB CIDR --> NPB attachment
SS CIDR --> SS attachment
Traffic arriving from NPA or NPB attachment can go SS, NPA, or NPB
PRA and PRB attachment route table
PRA CIDR --> PRA attachment
PRB CIDR --> PRB attachment
SS CIDR --> SS attachment
Traffic arriving from PRA or PRB attachment can go SS, PRA or PRB
SS Attachment route table
NPA CIDR --> NPA attachment
NPB CIDR --> NPB attachment
PRA CIDR --> PRA attachment
PRB CIDR --> PRB attachment
Traffic from SS attachment can go NPA, NPB, PRA, or PRB
Relevant questions
AWS Transit Gateway through BGP propagation and routing behavior
Accepted Answerasked 2 years agoAWS Transit Gateway Routing Features
Accepted Answerasked 3 years agoTransit Gateway - number of prefixes from TGW->CGW
Accepted Answerasked 3 years agoAWS Transit Gateway isolated routing with Shared Services
Accepted Answerasked 2 years agoAWS Transit Gateway attachment pricing
Accepted Answerasked 2 years agoModify Transit Gateway Properties After Creation
Accepted Answerasked 3 years agoMulticast support with a VPC and Transit Gateway (TGW)
Accepted Answerasked 2 years agoMigrate from Private VIF to Transit VIF
Accepted Answerasked 2 years agoNew VPC Subnets and Transit Gateway attachment
Accepted AnswerTransit Gateway attachment cost to VPC and subnets
Accepted Answerasked 2 years ago