aws_cdk.aws_ec2.vpc only utilizes 2 availability zones no matter what max_azs is set to

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 …

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behavior? If the current behavior is a 🪲bug🪲: Please provide the steps to reproduce

The following code I would expect to utilize 3 azs, but only utilizes 2. We have a requirement to specifically utilize 3 azs and I don’t see a way to make that happen.

from aws_cdk import (
  core,
  aws_ec2 as ec2
)

app = core.App()

subnets = []
subnets.append(ec2.SubnetConfiguration(name = "public", subnet_type = ec2.SubnetType.PUBLIC, cidr_mask = 20))
subnets.append(ec2.SubnetConfiguration(name = "private", subnet_type = ec2.SubnetType.PRIVATE, cidr_mask = 20))
subnets.append(ec2.SubnetConfiguration(name = "isolated", subnet_type = ec2.SubnetType.ISOLATED, cidr_mask = 20))

vpc = ec2.Vpc(app, "MyVpc", subnet_configuration = subnets, max_azs = 3)

app.synth()

• What is the expected behavior (or behavior of feature suggested)? I would expect the number of AZs to equal the number supplied to the max_azs variable.

• What is the motivation / use case for changing the behavior or adding this feature?

• Please tell us about your environment:

  • CDK CLI Version: 1.2.0
  • Module Version:
    “libraries”: { “@aws-cdk/cx-api”: “1.1.0”, “@aws-cdk/core”: “1.1.0”, “@aws-cdk/region-info”: “1.1.0”, “@aws-cdk/aws-iam”: “1.1.0”, “@aws-cdk/aws-cloudwatch”: “1.1.0”, “@aws-cdk/aws-ssm”: “1.1.0”, “@aws-cdk/aws-ec2”: “1.1.0”, “@aws-cdk/aws-events”: “1.1.0”, “@aws-cdk/aws-kms”: “1.1.0”, “@aws-cdk/aws-s3”: “1.1.0”, “jsii-runtime”: “Python/3.7.4” }
  • OS: OSX Mojave
  • Language: Python

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

[roger-reed]

Workaround I noticed the CDK CLI was setting OS environment variables based on the passed profile on the CLI. Method to build CDK Environment off of environment variables:

def get_cdk_environment():
    return Environment(account=os.environ['CDK_DEFAULT_ACCOUNT'], 
        region=os.environ['CDK_DEFAULT_REGION'])

When initializing Stack set environment:

env=cdk_util.get_cdk_environment() Correct number of subnets are created with this method.

[yogin]

I have the same issue using the Python framework. It only uses 2 AZs, and passing max_azs=3 didn’t help.

I invoke the cdk cli by specifying a config profile --profile xyz. My profile inherits from another profile and uses assume role to access another AWS account. The profile also sets the region to use (which is different from the source profile). I use this profile with the AWS cli and Terraform all the time so I know it’s correctly setup.

When deploying a stack with that profile, it is able to create the stack in the correct account and correct region. However it doesn’t use the expected number of availability zones.

After speaking to @skinny85 on gitter, he suggested passing the env to my stack and explicitly setting the account and region there

So instead of

NetworkStack(app, "Staging")

I have to use

NetworkStack(app, "Staging", env=core.Environment(account="123...", region="us-east-1"))

I think being able to override the environment for individual stack is awesome, so you can manage your infrastructure across multiple accounts and regions, but I expect it to be able to correctly use the default environment provided by my profile.

And it seems like it can do it, for the most part. It can create resources in the correct account and region defined in my profile, but for some reason, it can’t retrieve the full list of availability zones unless the account and region are explicitly passed to the Stack. And this seems like an issue to me. It obviously has the account and region information available from the profile since it is creating resources, so it should be able to determine AZs correctly.