Skip to content
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

Using VPC in Cluster with CDK 0.32.0 does not work: Error: There are no 'Private' subnets in this VPC. Use a different VPC subnet selection #2631

Closed
markusl opened this issue May 24, 2019 · 5 comments · Fixed by #2649

Comments

@markusl
Copy link
Contributor

markusl commented May 24, 2019

In CDK 0.31.0 our stack looked like this:

const vpcProps: ec2.VpcNetworkImportProps = {
  vpcId: 'vpc-xxxx',
  availabilityZones: ['eu-central-1a', 'eu-central-1b', 'eu-central-1c'],
  publicSubnetIds: ['subnet-xxxx', 'subnet-xxxx', 'subnet-xxxx'],
  privateSubnetIds: ['subnet-xxxx', 'subnet-xxxx', 'subnet-xxxx'],
};
    const cluster = ecs.Cluster.fromClusterAttributes(this, `Cluster`, {
      clusterName: clusterName,
      vpc: vpcProps,
      securityGroups: [ ]
    });

with CDK 0.32.0 we are forced to use a VPC with cluster import:

    const cluster = ecs.Cluster.fromClusterAttributes(this, `Cluster`, {
      clusterName: clusterName,
      vpc: vpcProps,
      securityGroups: [ ]
    });

which causes an error Error: There are no 'Private' subnets in this VPC. Use a different VPC subnet selection.

Somehow the cluster seems to lose the specified private subnets with this new model. Is there any workaround for this functionality?

@hoegertn
Copy link
Contributor

hoegertn commented May 24, 2019

I think the problem is that the class ImportedCluster uses the supplied property vpc as VpcAttributes to import the VPC but the type is IVpc.

@markusl
Copy link
Contributor Author

markusl commented May 25, 2019

Is this a bug in the CDK or is there a way to change the code to make it work again with the latest version?

@hoegertn
Copy link
Contributor

I think it is a bug, but I managed to patch around it:

        const cluster = Cluster.fromClusterAttributes(this, 'Cluster', {
            vpc: <any>{
                vpcId: 'someid',
                availabilityZones: ['eu-central-1a', 'eu-central-1b', 'eu-central-1c'],
                publicSubnetIds: [
                    'someid',
                    'someid',
                    'someid',
                ],
            },
            clusterName: 'someid',
            securityGroups: []
        });

So I used VpcAttributes and told TypeScript to ignore the type mismatch.

@AlexCheema
Copy link
Contributor

I also ran into this when using the VPC directly across stacks (in same app) on 0.31.0. The workaround was manually exporting/importing the VPC across stacks.

@EduardTheThird
Copy link

We reuse cluster for ECS Fargate services.

Importing a VPC is required to use an existing Cluster (ecs.Cluster.fromClusterAttributes).

When importing an existing VPC, ec2.Vpc.fromLookup and ec2.Vpc.fromVpcAttributes both results in the same error:

There are no 'Private' subnets in this VPC. Use a different VPC subnet selection.

This was using AWS CDK 0.32.

Previously in AWS CDK 0.31 I was able to work around this by first calling ec2.VpcNetwork.import
and entering vpcId, availabilityZones, publicSubnetIds and privateSubnetIds details.

Once the existing VPC was imported, I was able to import the cluster, without the error using:

cluster = ecs.Cluster.fromClusterAttributes(this,
                configuration.clusterName(), {
                    clusterName: configuration.clusterName(), 
                    securityGroups: [securityGroup],
                    vpc: {
                        vpcId: existingVpc.vpcId,
                        availabilityZones: existingVpc.availabilityZones,
                        privateSubnetIds: existingVpc.selectSubnets({ subnetType: SubnetType.Private }).subnetIds,
                        publicSubnetIds: existingVpc.selectSubnets({ subnetType: SubnetType.Public }).subnetIds
                    }
                });

rix0rrr pushed a commit that referenced this issue May 27, 2019
Remove unnecessary import.

Fixes #2631.
rix0rrr added a commit that referenced this issue May 28, 2019
Remove unnecessary import call.

Fixes #2631.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants