Vpc does not span over whole region

[lkoniecz]

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

class DevelopmentStack(core.Stack):
    def __init__(self, app: core.App, id: str, **kwargs) -> None:
        super().__init__(app, id, **kwargs)
        vpc = aws_ec2.Vpc(scope=self, id='Vpc', cidr='192.168.0.0/16'

app = core.App()
DevelopmentStack(app=app, id='Dev', env={'region': 'eu-west-1'})
app.synth()

Generated template contains 2 public subnets and 2 private equally distributed over eu-west-1a and eu-west-1b.

• What is the expected behavior (or behavior of feature suggested)?
  According to documentation: https://docs.aws.amazon.com/cdk/api/latest/python/aws_cdk.aws_ec2/Vpc.html subnets should span all over the whole region, eu-west-1a, eu-west-1b and eu-west-1c in this case.

• What is the motivation / use case for changing the behavior or adding this feature?
  To make the code working accordingly to the documentation.

• Please tell us about your environment:

  • CDK CLI Version: 0.36.0 (build 6d38487)
  • Module Version: 0.36.0
  • OS: [Ubuntu 19.4]
  • 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)

[mhuebner]

You have to explicitly set region and account for your Stack (Environment). Have a look at #3083

[kuhnboy]

@lkoniecz also I don't think you can create a network with /16 from a class C network (192.168.0.0) as it would only support /24 - /32. The maximum number of usable hosts from a class C network is 254 total.

[lkoniecz]

@mhuebner

thanks, it works, but I quite don't understand what the real root cause was - in particular, how does explicitly setting stack env affect number of AZs.

[mhuebner]

If you have a look at pull request #2922 you will find an explanation:

The AZ provider, which is now accessible through stack.availabilityZones will fall
back to use [ Fn::GetAZs[0], Fn::GetAZs[1] ] in case the stack is env-agnostic. This is
a safe fallback since all AWS regions have at least two AZs.

So if you won't set account and region the fallback will just set two (the first two) AZ. I think it would be very good to extend the docs as there are some other issues regarding this new behaviour @eladb? #3124, #3083 and #3110

[lkoniecz]

@mhuebner

this is what came to my mind but I was fooled by Osaka region that only has one AZ
https://aws.amazon.com/about-aws/global-infrastructure/regions_az/?p=ngi&loc=2

but I read it over again and seems its a special case, so 2 AZ per region setup will basically work everywhere

thanks for the explanation,
case closed.

[mhuebner]

You're welcome. Interesting - i wasn't ware of Osaka having only one AZ. Might also be of interest for @eladb

[eladb]

Thanks for bringing this to my attention. Perhaps we can embed a little CFN map with those defaults... I’ll open an issue. Closing for now