aws-cdk
aws-cdk copied to clipboard
(aws_apigatewayv2): VpcLink can't see Private_Isolated subnets
Describe the bug
VPC defined as:
this.vpc = new ec2.Vpc(this, 'Vpc', {
maxAzs: 2,
subnetConfiguration: [
{ cidrMask: 24, name: 'Isolated', subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
],
});
When trying to deploy the below APIGW definition:
const lb = new cdk.aws_elasticloadbalancingv2.ApplicationLoadBalancer(this, 'lb', { vpc: props.vpc });
const listener = lb.addListener('Listener', { port: 80 });
listener.addTargets('ecs', {
port: 80,
targets: [props.backendService.loadBalancerTarget({
containerName: 'backend',
containerPort: 8000,
})],
});
const vpcLink = new cdk.aws_apigatewayv2.VpcLink(this, 'VpcLink', { vpc: props.vpc });
new cdk.aws_apigatewayv2.HttpApi(this, 'HttpProxyPrivateApi', {
apiName: 'BackendApi',
defaultIntegration: new HttpAlbIntegration('DefaultIntegration', listener, { vpcLink }),
});
}
Expected Behavior
VpcLink is created using Isolated subnets automatically.
Current Behavior
Error: There are no 'Private' subnet groups in this VPC. Available types: Isolated,Deprecated_Isolated
Reproduction Steps
As above.
Possible Solution
Workaround:
const vpcLink = new cdk.aws_apigatewayv2.VpcLink(this, 'VpcLink', { vpc: props.vpc, subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED } });
Additional Information/Context
No response
CDK CLI Version
2.129.0
Framework Version
No response
Node.js Version
18.18.2
OS
MacOS
Language
TypeScript
Language Version
No response
Other information
No response
Yes if you don't specify props.subnets
it would filter and pick up with { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }
, which you don't have in your use case. So you will need to specify props.subnets
.
https://github.com/aws/aws-cdk/blob/f0af5b1b1551e03198098610f0377af11447e098/packages/aws-cdk-lib/aws-apigatewayv2/lib/http/vpc-link.ts#L101
I would challenge the fact of using PRIVATE_EGRESS as the default - having a VpcLink already means that someone is probably looking for strict security so:
- either look for PRIVATE_ISOLATED first then for PRIVATE_EGRESS if not found
- and then props should only be used for a custom config of some non-standard setup of subnets.
I know it's just an opinion but simplicity of the usage of constructs and minimising the number of props overrides is important in my opinion. Up to you to decide though!
Yeah I guess we need to improve the doc here.
I suggested something else rather than improving the docs.