cdk 0.36.0 generates wrong number of Subnets for VPC

[mhuebner]

• I'm submitting a ...

  • 🪲 bug report

• What is the current behavior?
  Create a VPC with the following Setup:

    new ec2.Vpc(this, 'TheVPC', {
      cidr: '10.0.0.0/16',
      subnetConfiguration: [
        {
          cidrMask: 22,
          name: 'Pub',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 22,
          name: 'Priv',
          subnetType: ec2.SubnetType.PRIVATE,
        },
        {
          cidrMask: 22,
          name: 'Iso',
          subnetType: ec2.SubnetType.ISOLATED,
        }
      ],
      maxAZs: 3
    });

This code produces a CloudFormation Template with the following Subnets:

• TheVPCPubSubnet1SubnetB7756B9D (10.0.0.0/22) (AZ with Index 0)
• TheVPCPubSubnet2SubnetAA2580CE (10.0.4.0/22) (AZ with Index 1)
• TheVPCPrivSubnet1SubnetCBA4D729 (10.0.8.0/22)(AZ with Index 0)
• TheVPCPrivSubnet2SubnetAC5C58CC (10.0.12.0/22) (AZ with Index 1)
• TheVPCIsoSubnet1Subnet25E741C3 (10.0.16.0/22) (AZ with Index 0)
• TheVPCIsoSubnet2Subnet6D81C33F (10.0.20.0/22) (AZ with Index 1)

These are 6 Subnets distributed over 2 AZ but it should have been 9 Subnets distributed over 3 AZ.

Missing Subnets:

• TheVPCPubSubnet3Subnet (AZ with Index 2) missing !
• TheVPCPrivSubnet3Subnet (AZ with Index 2) missing !
• TheVPCIsoSubnet3Subnet (AZ with Index 2) missing !

Maybe the AvailabilityZones are not correctly resolved or is there a new way of defining AvailabilityZones for the Stack anywhere (can't find anything)?

Even when I try to configure the region (Environment) not all 3 Zones of eu-central-1 are resolved.

• What is the expected behavior (or behavior of feature suggested)?
  CloudFormation Template should contain 9 Subnets (3 for each AZ)

• Please tell us about your environment:

  • CDK CLI Version: 0.36.0
  • Module Version: 0.36.0
  • OS: [OSX Mojave]
  • Language: [TypeScript]

[mhuebner]

Ok, I got it. I wasn't aware of a the new configuration behavior which was introduced with #2922

From my example above I would have to setup the stack like so:

new TestStack(app, 'TestStack', {
    env: {
        region: "eu-central-1",
        account: "XXXXXXXX"
    }
});

[eladb]

Yap... Thanks for following up. If you wish to use the default environment (as configured in the CLI), you could use the environment variables CDK_DEFAULT_ACCOUNT and CDK_DEFAULT_REGION:

new TestStack(app, 'TestStack', {
    env: {
        region: process.env.CDK_DEFAULT_REGION,
        account: process.env.CDK_DEFAULT_ACCOUNT,
    }
});

This is not a recommended practice for production stacks, but awesome for dev stacks.