-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VPC fromLookup fails with asymmetric subnets #3407
Comments
Hey, Could you provide your VPC's subnet description? You can obtain it using the AWS CLI (replace aws ec2 describe-subnets --filters "Name=vpcId,Values=${VPC_ID}" Before posting the result, it would be a good idea to remove references that are specific to your account (we don't need to see those anyway):
|
|
Your setup has:
Currently, the I tend to agree with your point that this seems to force opinions on you, we're currently investigating ways we could meet this more flexible. |
I haven't tested this but is this also the case with regions with more than 3 AZs if I were to use only 3 of 5, for example? What will happen when a new AZ is added to a region? Also is the determination based solely on the |
It's okay if you use only N of M available AZs in your region, but all the subnet groups need ot have the same set of AZs covered. The default determination is:
A In any case, all of the subnet groups must cover the same list of AZs. |
Same issue - and i have all subnets across all az's. It seems it's either considering the data and the private subnets twoce, or re-considering the database subnet group. Error message: Not all subnets in VPC have the same AZs: ap-southeast-2a,ap-southeast-2b,ap-southeast-2c vs ap-southeast-2a,ap-southeast-2a,ap-southeast-2b,ap-southeast-2b,ap-southeast-2c,ap-southeast-2c |
Subnet code: # aws ec2 describe-subnets --filters "Name=vpcId,Values=vpc-xxxxxxxxxxxxxxxxxxx
{
"Subnets": [
{
"AvailabilityZone": "ap-southeast-2b",
"AvailabilityZoneId": "apse2-az1",
"AvailableIpAddressCount": 8185,
"CidrBlock": "10.0.32.0/19",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "Purpose",
"Value": "AWS LZ Private Subnet for AZ 2"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "Name",
"Value": "private-subnet-az2"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PrivateSubnetAz2"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Environment",
"Value": "AWS LZ"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2b",
"AvailabilityZoneId": "apse2-az1",
"AvailableIpAddressCount": 2042,
"CidrBlock": "10.0.200.0/21",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Purpose",
"Value": "AWS LZ Data Subnet for AZ 2"
},
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "DataSubnetAz2"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "Name",
"Value": "data-subnet-az2"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2a",
"AvailabilityZoneId": "apse2-az3",
"AvailableIpAddressCount": 8187,
"CidrBlock": "10.0.0.0/19",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Purpose",
"Value": "AWS LZ Private Subnet for AZ 1"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PrivateSubnetAz1"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "Name",
"Value": "private-subnet-az1"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2b",
"AvailabilityZoneId": "apse2-az1",
"AvailableIpAddressCount": 4090,
"CidrBlock": "10.0.144.0/20",
"DefaultForAz": false,
"MapPublicIpOnLaunch": true,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Name",
"Value": "public-subnet-az2"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PublicSubnetAz2"
},
{
"Key": "Purpose",
"Value": "AWS LZ Public Subnet for AZ 2"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Environment",
"Value": "AWS LZ"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2c",
"AvailabilityZoneId": "apse2-az2",
"AvailableIpAddressCount": 2043,
"CidrBlock": "10.0.208.0/21",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Name",
"Value": "data-subnet-az3"
},
{
"Key": "Purpose",
"Value": "AWS LZ Data Subnet for AZ 3"
},
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "DataSubnetAz3"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2c",
"AvailabilityZoneId": "apse2-az2",
"AvailableIpAddressCount": 4090,
"CidrBlock": "10.0.160.0/20",
"DefaultForAz": false,
"MapPublicIpOnLaunch": true,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Purpose",
"Value": "AWS LZ Public Subnet for AZ 3"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PublicSubnetAz3"
},
{
"Key": "Name",
"Value": "public-subnet-az3"
},
{
"Key": "Environment",
"Value": "AWS LZ"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2c",
"AvailabilityZoneId": "apse2-az2",
"AvailableIpAddressCount": 8187,
"CidrBlock": "10.0.64.0/19",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Purpose",
"Value": "AWS LZ Private Subnet for AZ 3"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PrivateSubnetAz3"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "Name",
"Value": "private-subnet-az3"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2a",
"AvailabilityZoneId": "apse2-az3",
"AvailableIpAddressCount": 4088,
"CidrBlock": "10.0.128.0/20",
"DefaultForAz": false,
"MapPublicIpOnLaunch": true,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "Name",
"Value": "public-subnet-az1"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "PublicSubnetAz1"
},
{
"Key": "Purpose",
"Value": "AWS LZ Public Subnet for AZ 1"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
},
{
"AvailabilityZone": "ap-southeast-2a",
"AvailabilityZoneId": "apse2-az3",
"AvailableIpAddressCount": 2043,
"CidrBlock": "10.0.192.0/21",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false,
"State": "available",
"SubnetId": "xxxxxxxxxxxxxxxxxxx",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxxx",
"OwnerId": "xxxxxxxxxxxxxxxxxxx",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"Tags": [
{
"Key": "Name",
"Value": "data-subnet-az1"
},
{
"Key": "AWS_Solutions",
"Value": "LandingZoneStackSet"
},
{
"Key": "Environment",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:stack-name",
"Value": "StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e"
},
{
"Key": "Project",
"Value": "AWS LZ"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:stack/StackSet-AWS-Landing-Zone-Baseline-PrimaryVPC-e12d699b-c6e1-42a2-9087-bbac78b69b5e/63ed59c0-ac3e-11e9-8b69-0accf194060a"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "DataSubnetAz1"
},
{
"Key": "Purpose",
"Value": "AWS LZ Data Subnet for AZ 1"
}
],
"SubnetArn": "arn:aws:ec2:ap-southeast-2:xxxxxxxxxxxxxxxxxxx:subnet/xxxxxxxxxxxxxxxxxxx"
}
]
} |
This is quite bad issue if you have "legacy" infra. We had to create the security group and it took some time to find out how to workaround this if I want to use (Python) aws_ec2.SecurityGroup class for security group. So here's the workaround how I manage to get proper looking SG:
So please - fix this to something less hack looking. |
Seems that Route53 requires different kind of handling for VPC. I'm wondering if this is showstopper for us or should I just leave the legacy VPC to be legacy until this is fixed and then start to use it again. |
Hello @RomainMuller / @rix0rrr I'm experiencing this exact problem on one of my accounts that has been provisioned with LandingZones. There are multiple VPC configuration options in landing zones that will result in asymmetrical VPC configurations such as CDK Version: 1.3.0 / Typescript |
Looking into this more, I've found that VPC's created with LandingZones also only create a single route table for the public subnets. This is causing a violation here: ImportSubnetGroup:67 Regarding the issue with LZ creating 2 Public and 4 Private subnets above, I've actually traced the problem to VpcNetworkContextProviderPlugin:166. It seems to me this should also do a reduce to eliminate duplicates. That is the particular problem I'm seeing with the VPC created with the I've been able to work around this problem by manually defining the VPC in the |
This is a show stopper for me as well as I have to use a legacy VPC in our production environment. But since the subnets are not symmetric and I cannot easily fix this I would need some guidance regarding workarounds. @mmoulton could you share how to manually define a VPC in the context json file? |
So, the workaround that I am doing right now to be able to use the legacy VPC is to simply reference it by ID. And then pass it to the low level API when creating different resources, like this:
This works but this means that I cannot use the constructs in most cases which is defeating the purpose of CDK. You should look into this issue so that we do not need to implement hacky solutions like this. |
Please keep in mind that the vast majority of your users will have no control over this. We're developers, our company's cloud/network engineers have worked hand in hand with AWS contractors to set up our configuration. There is no way they're changing any of this to accommodate these CDK constraints |
I got the same issue: |
I need to map my vpc in cdk to create a simple ALB. Now we have 10 subnets split in 2 AZ: 6 public and 4 private. based on your definition it should work. Now I need only 2 subnet(not random). How can I do that? In the ApplicationLoadBalancer construct I need to refer only two specific private subnet. How? If I use the method from_lookup to get the IVPC I receive this error:
this is the piece of code. |
@joemcclane85 i cannot see the subnet tags set on your subnets as per this entire thread. you need PUBLIC, PRIVATE and ISOLATED tags on non-CDK generated subnets. |
@reeseyc ok, but How Can I use only the customer-prod-a-prv and the customer-prod-b-prv? |
I've to tag with aws-cdk:subnet-type: Public/Private and then You should update the documentation to say: if you use an existing VPC you must tag every single subnet with aws-cdk:subnet-type: 'Public' or 'Private' and aws-cdk:subnet-name: something |
We should make the following changes:
Changes to the VPC context provider and potentially the CX protocol should derive from these. |
In general, lookup functions should not be opinionated and just return the current state. If it exists, it obviously met any AWS requirements to create it in the first place. Further more, the ability to use the information should not be predicated on arbitrary tags. Tags can be useful but in this case, its just a label the may or may not reflect the resource itself. |
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes #3407
I'm still facing a similar issue with
CDK 1.102.0, Mac OS, node 14.16.1 |
Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.
I'm submitting a ...
What is the current behavior?
If the current behavior is a 🪲bug🪲: Please provide the steps to reproduce
Returns the following error when subnets/types are not symmetric across AZs.
What is the expected behavior (or behavior of feature suggested)?
As the name of the lookup function implies, it should return any VPC configuration.
What is the motivation / use case for changing the behavior or adding this feature?
Deploying an App to existing VPCs should not be predicated on an opinionated view of the VPC.
Please tell us about your environment:
ℹ️ CDK Version: 1.1.0 (build 1a11e96)
ℹ️ AWS environment variables:
ℹ️ No CDK environment variables
The text was updated successfully, but these errors were encountered: