Control over VPC AZs

[hljadmin]

❓ General Issue

Attempting to create a VPC in ap-northeast-1 with 2 AZs and one NatGateway. Upon deploy the stack fails with the error "Nat Gateway is not available in this availability zone"

apne1-az3 in this region does not have NATGateway support, unfortunately it is mapped to AZ ap-northeast-1a in my account.

example:

vpc = aws_ec2.Vpc(
            self,
            id='prod_vpc',
            cidr='10.199.0.0/16',
            enable_dns_hostnames=False,
            enable_dns_support=True,
            nat_gateways=1,
            max_azs=2,
            subnet_configuration=[
                aws_ec2.SubnetConfiguration(
                    cidr_mask=24,
                    name='public',
                    subnet_type=aws_ec2.SubnetType.PUBLIC
                ),
                aws_ec2.SubnetConfiguration(
                    cidr_mask=20,
                    name='application',
                    subnet_type=aws_ec2.SubnetType.PRIVATE
                )
            ]
        )

Running this in a different account in the same region can also have the same issue.

expected behavior:

If a NATGateway is requested then the CDK should check for support in the AZ before selection. It appears that the CDK is processing in logical order?

question:

Is there a workaround for this?

Environment

• CDK CLI Version: 1.21
• OS: OSX Catalina
• Language: Python

[hljadmin]

Same issue with add_interface_endpoint

Not all regions/az are created equally it seems. Some control over what AZ to put use with a VPC into would be helpful.

[hljadmin]

As an infrastructure designer having the ability to determine a list of AZs to use in a VPC would be invaluable. This is especially important in situations where deployments across accounts as well as regions come into play.

[rix0rrr]

It would entail adding an availabilityZones?: string[] construction parameter to the construct props. I will accept a PR adding this.

As a workaround, you can edit the AZs saved in cdk.context.json, or set them on the stack in the source code using setContext.

[hljadmin]

Thank you. Unfortunately my skills in node are not up to doing this task. Hopefully someone can pick up this request. I think it would be clearer if the AZ was a param in the create of the VPC.

Had to do some digging but finally figured out one way to do this in python:

#only use these availability zones
self.node.set_context(
    key=f'availability-zones:account={self.account}:region={self.region}',
    value=['zone-1b', 'zone-1c']
)

[johnschultz]

Could we allow specifying physical zones here as well? The use case is trying to use PrivateLinks to communicate across accounts and needing to guarantee that subnets are brought up in the same physical zones (e.g. use1-az1).

[martinnabhan]

We're having the same issue in the ap-northeast-1 region.
Following @hljadmin's example, here's the same thing in TypeScript (with ap-northeast-1a being the culprit):

if (this.region === 'ap-northeast-1') {
  this.node.setContext(`availability-zones:account=${this.account}:region=ap-northeast-1`, [
    'ap-northeast-1b',
    'ap-northeast-1c',
    'ap-northeast-1d',
  ]);
}
``

[rix0rrr]

Also somewhat related to #5927

[lengebre]

Use the following to take control of the VPC AZ. The example will create a subnets in the us-east-1d, us-east-1e availability zones.

Best regards,
Mo

@property
def availability_zones(self):
    return ['us-east-1d', 'us-east-1e']

def __init__(self, scope: core.Construct, construct_id: str, **kwargs) -> None:
    super().__init__(scope, construct_id, **kwargs)

    # The code that defines your stack goes here
    vpc = ec2.Vpc(
        self, "TestVpc",
        max_azs=2,
        cidr="10.0.0.0/16",
    )

[fabiopaiva]

Could we allow specifying physical zones here as well? The use case is trying to use PrivateLinks to communicate across accounts and needing to guarantee that subnets are brought up in the same physical zones (e.g. use1-az1).

I had the same questions and found out that it's possible to check the AZ zone name/id mapping in AWS Resource Access Manager Console.
For eu-west-1 for example:

eu-west-1a | euw1-az3
eu-west-1b | euw1-az1
eu-west-1c | euw1-az2

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[m17kea]

For anyone looking for consistency across availability zones I came across the following repo https://github.com/aws-samples/multi-account-az-mapping