EC2/VPC: Configure order of subnet creation
baumand-amazon opened this issue · comments
Describe the feature
Related to #5927 - but this is a smaller request to make the existing Vpc L2 construct more flexible and work in more situations.
The existing Vpc construct does not support adding AZs to a VPC without breaking, but it comes close. The SubnetConfiguration allows for a stable cidrMask to be specified, so that adding subnets doesn't impact the CIDRs of existing subnets. The below talks about the case when cidrMask is specified, because when it isn't adding new subnets without changing existing ones will never work.
The existing code loops on subnet cofiguration first then on AZ when creating subnets. For each configuration it adds subnets for each AZ.
aws-cdk/packages/aws-cdk-lib/aws-ec2/lib/vpc.ts
Line 1748 in 9295a85
This means that when adding a new subnet configuration to an existing VPC, the new subnets are added at the end and therefore the update can be performed without changing all existing subnets.
When adding an AZ however, subnets from the new AZ come before subnets from existing AZs and this throws off the CIDR allocations.
This could be addressed without breaking existing customers by adding a configuration parameter to the existing Vpc to specify whether to allocate subnets by configuration first or by AZ first. The default should be to allocate by configuration first so that it's backwards compatible, and users who want to keep the same configuration but add AZs will be able to change the option.
This would allow me to specify a Vpc like this and add AZs without replacing any existing subnets.
var v = new Vpc(this, "MyVpc", {
NEW_PARAM: byAz // the new param
subnetConfiguration: [
{
cidrMask: 22,
subnetType: SubnetType.PUBLIC,
name: "Public"
},
{
cidrMask: 22,
subnetType: SubnetType.PRIVATE_WITH_EGRESS,
name: "Private"
},
],
availabilityZones: this.availabilityZones.slice(0, N) // here N can be increased to add AZs
})
Use Case
I have an existing VPC and I want to add AZs. I can't do this today because it will require replacement of all subnets, and this will fail even if it could be tolerated because the new subnets will have CIDRs that clash with existing ones.
Proposed Solution
Described above.
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
CDK version used
2.x
Environment details (OS name and version, etc.)
any
Sure, done!
As #5927 seems like an issue with a larger scope and a lot more changes, I created this as a separate issue because it seems like something that could plausibly be implemented for the existing Vpc in a backwards compatible way and without needing as much work.