VPC fromLookup fails with asymmetric subnets

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

ec2.Vpc.from_lookup(self, "VPC", is_default=True)

Returns the following error when subnets/types are not symmetric across AZs.

Not all subnets in VPC have the same AZs: eu-west-1a,eu-west-1b,eu-west-1c vs eu-west-1b

• What is the expected behavior (or behavior of feature suggested)? As the name of the lookup function implies, it should return any VPC configuration.

• What is the motivation / use case for changing the behavior or adding this feature? Deploying an App to existing VPCs should not be predicated on an opinionated view of the VPC.

• Please tell us about your environment:

ℹ️ CDK Version: 1.1.0 (build 1a11e96) ℹ️ AWS environment variables:

• AWS_CLOUDWATCH_HOME = /opt/aws/apitools/mon
• AWS_PATH = /opt/aws
• AWS_AUTO_SCALING_HOME = /opt/aws/apitools/as
• AWS_ELB_HOME = /opt/aws/apitools/elb ℹ️ No CDK environment variables

• 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)

[sublimemm]

Your setup has:

• 1 PRIVATE subnet group composed of:

  • subnet-123 in eu-west-1b

• 1 PUBLIC subnet group composed of:

  • subnet-234 in eu-west-1c
  • subnet-345 in eu-west-1a
  • subnet-456 in eu-west-1b

Currently, the Vpc construct requires that all subnet groups cover the same list of availability zones. You are missing two PRIVATE subnets (in eu-west-1c and eu-west-1a) to satisfy this constraint.

I tend to agree with your point that this seems to force opinions on you, we’re currently investigating ways we could meet this more flexible.

Please keep in mind that the vast majority of your users will have no control over this. We’re developers, our company’s cloud/network engineers have worked hand in hand with AWS contractors to set up our configuration. There is no way they’re changing any of this to accommodate these CDK constraints

[vaneek]

In general, lookup functions should not be opinionated and just return the current state. If it exists, it obviously met any AWS requirements to create it in the first place. Further more, the ability to use the information should not be predicated on arbitrary tags. Tags can be useful but in this case, its just a label the may or may not reflect the resource itself.