Open ranrotx opened 4 years ago
This is true, and solving this will require CDK applications to be able to keep state between runs.
We can use this use case as a motivating example for that feature.
Got the same issue today, while setting my maxAzs
from 1
to 2
for the CIDR 10.1.0.0/16
using the CLI in version 1.39.0
.
Any updates on this? @rix0rrr
It looks like that the same happens if you increase the number of subnets in the following way
const vpc = new Vpc(this, `base-vpc`, {
cidr: "11.0.0.0/16",
subnetConfiguration: [
{
name: "public",
subnetType: SubnetType.PUBLIC,
},
{
name: "myPrivateSubnet",
subnetType: SubnetType.PRIVATE,
},
],
maxAzs,
});
if you add another subnet after a deployment like
const vpc = new Vpc(this, `base-vpc`, {
cidr: "11.0.0.0/16",
subnetConfiguration: [
{
name: "public",
subnetType: SubnetType.PUBLIC,
},
{
name: "myPrivateSubnet",
subnetType: SubnetType.PRIVATE,
},
{
name: "myOtherPrivateSubnet",
subnetType: SubnetType.PRIVATE,
},
],
maxAzs,
});
=> conflicts with another subnet error
Related to https://github.com/aws/aws-cdk/issues/5927 (and other issues in that area)
this happened to me today, when reducing maxazs
from 2 to 1.
Is there a workaround to do this ?
Happened to me when set maxAzs to 1. I had to destroy the stack and create again. Good thing we have nothing else in the VPC. I guess in production, one have to create a new VPC and move everything
This is true, and solving this will require CDK applications to be able to keep state between runs.
We can use this use case as a motivating example for that feature.
that state is held in AWS and it should be cloudformations to job to cope
suffering from the same issue. increase or decrease :(
Having the same problem adding another subnet
I'm trying to remove my Isolated subnet and am running into the same issue. CDK deployment wants to create all subnets from scratch, rather than just removing the one I want to get rid of. This causes the issue with the CIDRs already in use.
This is the code where I just removed the first subnet:
subnet_configuration=[
ec2.SubnetConfiguration(
name="Isolated",
cidr_mask=24,
reserved=False,
subnet_type=ec2.SubnetType.ISOLATED,
),
ec2.SubnetConfiguration(
name="Private",
cidr_mask=22,
reserved=False,
subnet_type=ec2.SubnetType.PRIVATE,
),
ec2.SubnetConfiguration(
name="Public",
cidr_mask=23,
reserved=False,
subnet_type=ec2.SubnetType.PUBLIC,
),
],
Different but related, I received the same error when trying to change NatGateways from 1 to 0.
It's unfortunate that devs don't give priority to fix this Vpc construct; without these problems fixed, relying on it is very dangerous.
Is there any workaround? I encountered the same issue without tweaking the AZ.
I've encountered this issue several times. It doesn't really matter what you're changing--if you attempt to change the subnet structure of an already-created VPC with CDK, you'll get this error.
Has anyone come up with a workaround, or even an order of operations for making changes to a VPC? My thought is that the previous VPC subnets would have to be completely destroyed prior to an update (since the CIDR reservations are not editable, even in the console)
+1
Related to the tracking state between deployments issue: #13676.
Would also like to be able to change AZ count.
Also experiencing this issue. Not uncommon to need to tweak VPC and if that means having to tear down your entire stack that is a huge dealbreaker for using this in production
I just ran into this issue today too. Would be nice to not have to destroy the stack in order to update this.
same issue here. has aws ever phsically added an AZ to a Region? I would think if they did that, lots of CDK users would not be happy
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 ofInvalidSubnet.Conflict;
Reproduction Steps
Changing
to
produces the error below.
Error Log
Environment
node --version v13.10.1
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