Be able to change AZ count on already deployed VPC (constructs need to be able to keep state)
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
When (in my case) increasing the maxAzs specified using the VPC construct from 3 to 4 and running ```cdk deploy```, the CloudFormation stack update fails with an error code of ```InvalidSubnet.Conflict;```
### Reproduction Steps
Changing
```
const vpc = new ec2.Vpc(this, 'VPC', {
cidr: "172.21.0.0/16",
maxAzs: 3,
natGateways: 1,
subnetConfiguration: [
{
cidrMask: 24,
name: 'public',
subnetType: ec2.SubnetType.PUBLIC,
},
{
cidrMask: 24,
name: 'private',
subnetType: ec2.SubnetType.PRIVATE,
}
]
});
```
to
```
const vpc = new ec2.Vpc(this, 'VPC', {
cidr: "172.21.0.0/16",
maxAzs: 4,
natGateways: 1,
subnetConfiguration: [
{
cidrMask: 24,
name: 'public',
subnetType: ec2.SubnetType.PUBLIC,
},
{
cidrMask: 24,
name: 'private',
subnetType: ec2.SubnetType.PRIVATE,
}
]
});
```
produces the error below.
### Error Log
```
1/28 | 5:55:19 PM | CREATE_FAILED | AWS::EC2::Subnet | VPC/publicSubnet4/Subnet (VPCpublicSubnet4Subnet46529D45) The CIDR '172.21.3.0/24' conflicts with another subnet (Service: AmazonEC2; Status Code: 400; Error Code: InvalidSubnet.Conflict; Request ID: 41f1d4ed-b249-4cfa-bb1e-c0148a4ddc30)
new Subnet (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1373:20)
\_ new PublicSubnet (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1588:5)
\_ /Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1239:32
\_ Array.forEach ()
\_ Vpc.createSubnetResources (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1221:28)
\_ Vpc.createSubnets (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1210:12)
\_ new Vpc (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1076:10)
\_ new CdkVpcTransitgatewayStack (/Users/username/workspace/cdk-vpc-transitgateway/lib/cdk-vpc-transitgateway-stack.ts:8:17)
\_ Object. (/Users/username/workspace/cdk-vpc-transitgateway/bin/cdk-vpc-transitgateway.ts:10:1)
\_ Module._compile (internal/modules/cjs/loader.js:1147:30)
\_ Module.m._compile (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/ts-node/src/index.ts:814:23)
\_ Module._extensions..js (internal/modules/cjs/loader.js:1167:10)
\_ Object.require.extensions. [as .ts] (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/ts-node/src/index.ts:817:12)
\_ Module.load (internal/modules/cjs/loader.js:996:32)
\_ Function.Module._load (internal/modules/cjs/loader.js:896:14)
\_ Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
\_ main (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/ts-node/src/bin.ts:226:14)
\_ Object. (/Users/username/workspace/cdk-vpc-transitgateway/node_modules/ts-node/src/bin.ts:485:3)
\_ Module._compile (internal/modules/cjs/loader.js:1147:30)
\_ Object.Module._extensions..js (internal/modules/cjs/loader.js:1167:10)
\_ Module.load (internal/modules/cjs/loader.js:996:32)
\_ Function.Module._load (internal/modules/cjs/loader.js:896:14)
\_ Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
\_ /usr/local/lib/node_modules/npm/node_modules/libnpx/index.js:268:14
```
### Environment
- **CLI Version :** 1.27.0 (build a98c0b3)
- **Framework Version:** ```node --version
v13.10.1```
- **OS :** macOS 10.14.6
- **Language :** us-english
### Other
At first glance, it appears that on subsequent deployments the VPC construct is not aware of what CIDR ranges may already be in-use.
---
This is :bug: Bug Report
Contributor guide
Research direction
Start with @aws-cdk/aws-ec2/lib/vpc.ts, especially Vpc.createSubnets and Vpc.createSubnetResources named in the stack trace, and compare them with the VPC construct call in lib/cdk-vpc-transitgateway-stack.ts. Reproduce the change from maxAzs 3 to 4 with cdk deploy; done means the existing VPC updates successfully without the InvalidSubnet.Conflict error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100