Closed adrianmace closed 1 year ago
@adrianmace i'm not sure I understand the use case for this new enum. The description of
PRIVATE_ISOLATED
says "Isolated Subnets do not route traffic to the Internet (in this VPC), and as such, do not require NAT gateways."
Your description of PRIVATE_WITH_TGW
matches this description.
You're correct that CDK is currently resolving this subnet as a PRIVATE_ISOLATED
type.
I am following this pattern to centralise egress.
PRIVATE_ISOLATED
implies that the VPC Is totally air-gapped and that if you try to ping 1.1.1.1
it'll fail. In my case that isn't true (I understand the inclusion of the parenthesis in the description covers my use-case).
Including a PRIVATE_WITH_TGW
lets me check for either a NGW attachment or a TGW Attachment and assume that if either exist, the resources within will be internet connected.
Maybe we need to deprecate PRIVATE_WITH_NAT
and add a new one, something like PRIVATE_WITH_EGRESS
so it can incorporate all cases where traffic is allowed out of the VPC.
@corymhall any thoughts on the PR; I am keen to work on an approach to allow transit gateway users to also consume these VPC constructs. Or do you have any suggestions for how I can work around this?
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.
Describe the feature
Create a new SubnetType enum that is used to identify a Private subnet with a Transit Gateway Attachment. This should work in an identical way to
PRIVATE_WITH_NAT
.Use Case
When importing existing VPCs to CDK using fromLookup, subnets which have no NAT Gateway are all considered
PRIVATE_ISOLATED
, even though some of these subnets do have an attached Transit Gateway and appropriate routes.Proposed Solution
PRIVATE_WITH_TGW
.fromLookup
function as necessary to ensure subnets are correctly identified.Other Information
In order to enable ZDT switching between NGW and TGW in the same VPC, we configure the routes to the TGW as
0.0.0.0/1
and128.0.0.0/1
. While it would be unreasonable to recursively search all of the IPv4 address space, I think the existence of these two routes pointing to the same location should be equivalent to a default route (0.0.0.0/0
) check.Acknowledgements
CDK version used
2.32.1
Environment details (OS name and version, etc.)
macOS 12.4