vpc: PRIVATE_WITH_EGRESS not getting applied with route to TransitGateway

[bruecktech]

Describe the bug

When I do Vpc.fromLookup in a VPC that has subnets with a default route to a TransitGateway the subnet is detected as PRIVATE_ISOLATED instead of PRIVATE_WITH_EGRESS

This PR that introduced it talks about TransitGateway too but it doesn't seem to get applied.

Expected Behavior

Detect subnet with a default route to a TransitGateway as PRIVATE_WITH_EGRESS

Current Behavior

Subnets with a default route to a TransitGateway are detected as PRIVATE_ISOLATED

Reproduction Steps

Use Vpc.fromLookup in a VPC that has subnets with a default route to a TransitGateway

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.66

Framework Version

No response

Node.js Version

16.16

OS

MacOS

Language

Typescript

Language Version

No response

Other information

No response

[peterwoodworth]

You're right, I'm finding the same behavior.

When we set the type of imported subnets, we are first checking that the subnet has the type explicitly declared with a tag. If it doesn't, then we will cross reference with the describeRouteTable response to check if the subnet is associated with a route table.

aws-cdk/packages/aws-cdk/lib/context-providers/vpcs.ts

Lines 72 to 77 in b60876f

	const subnets: Subnet[] = listedSubnets.map(subnet => {
	let type = getTag('aws-cdk:subnet-type', subnet.Tags);
	if (type === undefined && subnet.MapPublicIpOnLaunch) { type = SubnetType.Public; }
	if (type === undefined && routeTables.hasRouteToIgw(subnet.SubnetId)) { type = SubnetType.Public; }
	if (type === undefined && routeTables.hasRouteToNatGateway(subnet.SubnetId)) { type = SubnetType.Private; }
	if (type === undefined) { type = SubnetType.Isolated; }

This doesn't account for transit gateway route tables, which are separate. And unfortunately, it doesn't appear we can fetch subnet information from this call. Maybe there's another way we could detect this?

[bruecktech]

From what I understand we don't actually need to look at TransitGateway route tables, but just incorporate routes to TransitGatewayIds in the regular route tables.

This is how the route looks like in the describe-route-table CLI command

{
    "DestinationCidrBlock": "0.0.0.0/0",
    "TransitGatewayId": "tgw-02261c6cd4750fc3c",
    "Origin": "CreateRoute",
    "State": "active"
},

So I think what's missing is something like this before line 77

if (type === undefined && routeTables.hasRouteToTransitGateway(subnet.SubnetId)) { type = SubnetType.Private; }

whereas hasRouteToTransitGateway could be implemented as

  public hasRouteToTransitGateway(subnetId: string | undefined): boolean {
    const table = this.tableForSubnet(subnetId) || this.mainRouteTable;

    return !!table && !!table.Routes && table.Routes.some(route => !!route.TransitGatewayId && route.DestinationCidrBlock === '0.0.0.0/0');
  }

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.