-
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
Unable to use deploy-time parameters for privateSubnetIds for Vpc.fromVpcAttributes #4118
Comments
It would work for now if you made the AZs an argument as well. |
The solution is for the VPC construct to not validate anything about subnets if the input is a token. |
@rix0rrr - thanks. I actually stumbled by accident across doing that last night and the following works.
|
Ha, that works as well. The |
I see the same error for
|
I have gotten this to work by using the |
This does not work, and the reason it does not work is that a lot of the CDK makes assumptions that subnets can be represented an subnets.map(s => s.subnetId)
subnets.map(s => s.routeTableId) And so on. Obviously the function that will have to translate: importSubnets(Fn.importValue('subnetIds')) // => ISubnet[] ???? Is going to be hard to write. It may accidentally work today. That is because the token:
This needs a lot of hacky code to make work in the current design, but more properly we should take it up as part of the Vpc redesign and introduce a class represent Tackle as part of #5927 |
…ime lists Even though using `Vpc.fromVpcAttributes()` using deploy-time lists like from `Fn.importValue()`s and `CfnParameters` was never really supposed to work, it accidentally did. The reason for that is: ```ts // Encoded list token const subnetIds = Token.asList(Fn.importValue('someValue')) // [ '#{Token[1234]}' ] // Gets parsed to a singleton `Subnet` list: const subnets = subnetIds.map(s => Subnet.fromSubnetAttributes({ subnetId: s })); // [ Subnet({ subnetId: '#{Token[1234]}' }) ] // This 'subnetId' is illegal by itself, and if yould try to use it for, // say, an ec2.Instance it would fail. However, if you treat this single // subnet as a GROUP of subnets: new CfnAutoScalingGroup({ subnetIds: subnets.map(s => s.subnetId) }) // [ '#{Token[1234]}' ] // And this resolves back to: resolve(cfnSubnetIds) // SubnetIds: { Fn::ImportValue: 'someValue' } ``` -------- We introduced an additional check in #11899 to make sure that the list-element token that represents an encoded list (`'#{Token[1234]}'`) never occurs in a non-list context, because it's illegal there. However, because: * `Subnet.fromSubnetAttributes()` logs the subnetId as a *warning* to its own metadata (which will log a string like `"there's something wrong with '#{Token[1234]}' ..."`). * All metadata is resolved just the same as the template expressions are. The `resolve()` function encounters that orphaned list token in the metadata and throws. -------- The *proper* solution would be to handle unparseable list tokens specially to never get into this situation, but doing that requires introducing classes and new concepts that will be a large effort and not be backwards compatible. Tracking in #4118. Another possible solution is to stop resolving metadata. I don't know if we usefully use this feature; I think we don't. However, we have tests enforcing that it is being done, and I'm scared to break something there. The quick solution around this for now is to have `Subnet.fromSubnetAttributes()` recognize when it's about to log a problematic identifier to metadata, and don't do it. Fixes #11945.
…ime lists (#12040) Even though using `Vpc.fromVpcAttributes()` using deploy-time lists like from `Fn.importValue()`s and `CfnParameters` was never really supposed to work, it accidentally did. The reason for that is: ```ts // Encoded list token const subnetIds = Token.asList(Fn.importValue('someValue')) // [ '#{Token[1234]}' ] // Gets parsed to a singleton `Subnet` list: const subnets = subnetIds.map(s => Subnet.fromSubnetAttributes({ subnetId: s })); // [ Subnet({ subnetId: '#{Token[1234]}' }) ] // This 'subnetId' is illegal by itself, and if yould try to use it for, // say, an ec2.Instance it would fail. However, if you treat this single // subnet as a GROUP of subnets: new CfnAutoScalingGroup({ subnetIds: subnets.map(s => s.subnetId) }) // [ '#{Token[1234]}' ] // And this resolves back to: resolve(cfnSubnetIds) // SubnetIds: { Fn::ImportValue: 'someValue' } ``` -------- We introduced an additional check in #11899 to make sure that the list-element token that represents an encoded list (`'#{Token[1234]}'`) never occurs in a non-list context, because it's illegal there. However, because: * `Subnet.fromSubnetAttributes()` logs the subnetId as a *warning* to its own metadata (which will log a string like `"there's something wrong with '#{Token[1234]}' ..."`). * All metadata is resolved just the same as the template expressions are. The `resolve()` function encounters that orphaned list token in the metadata and throws. -------- The *proper* solution would be to handle unparseable list tokens specially to never get into this situation, but doing that requires introducing classes and new concepts that will be a large effort and not be backwards compatible. Tracking in #4118. Another possible solution is to stop resolving metadata. I don't know if we usefully use this feature; I think we don't. However, we have tests enforcing that it is being done, and I'm scared to break something there. The quick solution around this for now is to have `Subnet.fromSubnetAttributes()` recognize when it's about to log a problematic identifier to metadata, and don't do it. Fixes #11945. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ime lists (aws#12040) Even though using `Vpc.fromVpcAttributes()` using deploy-time lists like from `Fn.importValue()`s and `CfnParameters` was never really supposed to work, it accidentally did. The reason for that is: ```ts // Encoded list token const subnetIds = Token.asList(Fn.importValue('someValue')) // [ '#{Token[1234]}' ] // Gets parsed to a singleton `Subnet` list: const subnets = subnetIds.map(s => Subnet.fromSubnetAttributes({ subnetId: s })); // [ Subnet({ subnetId: '#{Token[1234]}' }) ] // This 'subnetId' is illegal by itself, and if yould try to use it for, // say, an ec2.Instance it would fail. However, if you treat this single // subnet as a GROUP of subnets: new CfnAutoScalingGroup({ subnetIds: subnets.map(s => s.subnetId) }) // [ '#{Token[1234]}' ] // And this resolves back to: resolve(cfnSubnetIds) // SubnetIds: { Fn::ImportValue: 'someValue' } ``` -------- We introduced an additional check in aws#11899 to make sure that the list-element token that represents an encoded list (`'#{Token[1234]}'`) never occurs in a non-list context, because it's illegal there. However, because: * `Subnet.fromSubnetAttributes()` logs the subnetId as a *warning* to its own metadata (which will log a string like `"there's something wrong with '#{Token[1234]}' ..."`). * All metadata is resolved just the same as the template expressions are. The `resolve()` function encounters that orphaned list token in the metadata and throws. -------- The *proper* solution would be to handle unparseable list tokens specially to never get into this situation, but doing that requires introducing classes and new concepts that will be a large effort and not be backwards compatible. Tracking in aws#4118. Another possible solution is to stop resolving metadata. I don't know if we usefully use this feature; I think we don't. However, we have tests enforcing that it is being done, and I'm scared to break something there. The quick solution around this for now is to have `Subnet.fromSubnetAttributes()` recognize when it's about to log a problematic identifier to metadata, and don't do it. Fixes aws#11945. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Hi, we faced this issue multiple times, as a workaround we wrap the subnetIds with select statements:
This will create a list with three tokens, which will be resolved in cfn later. |
and it can also be used with higher level constructs like |
This worked beautifully. A real lifesaver, thank you! |
Here is another nice workaround const vpcIdParam = new CfnParameter(this, 'YourVpcId', { type: 'AWS::EC2::VPC::Id' });
const pubSubnetsParam = new CfnParameter(this, 'PubSubnets', { type: 'List<AWS::EC2::Subnet::Id>' });
const privSubnetsParam = new CfnParameter(this, 'PrivSubnets', { type: 'List<AWS::EC2::Subnet::Id>' });
const azs = ['eu-west-2a', 'eu-west-2b', 'eu-west-2c'];
const vpc = ec2.Vpc.fromVpcAttributes(this, 'VpcAttr', {
vpcId: vpcIdParam.valueAsString,
vpcCidrBlock: Aws.NO_VALUE,
availabilityZones: azs,
publicSubnetIds: azs.map((_, index) => Fn.select(index, pubSubnetsParam.valueAsList)),
privateSubnetIds: azs.map((_, index) => Fn.select(index, privSubnetsParam.valueAsList)),
}); |
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
I got resolved this issue by using below code in cdk for lambda function in vpc import * as iam from 'aws-cdk-lib/aws-iam'; export class VpcStack extends cdk.Stack { //get VPC Info form AWS account, FYI we are not rebuilding we are referencing
const lambdaFunction = new lambda.Function(this, 'lambda-function', { |
Unable to pass
CommaDelimitedList
CfnParameter
toVPC.fromVpcAttributes
privateSubnetIds
Reproduction Steps
When trying to use existing
VPC
for alambda function
When runing
npn run build
npx synth
for a stack with the above in it it will declare the following error:Environment
The text was updated successfully, but these errors were encountered: