Subnet selection fails for an imported VPC defined in another stack

[strax]

Describe the bug
We have an imported VPC defined in one stack, expose it à la

class StackA extends Stack {
  readonly vpc: VpcAttributes
}

and then import the same VPC in another stack with

const vpc = Vpc.fromVpcAttributes(this, "Vpc", props.stackA.vpc)

Using this concrete vpc throws an error when it is used in subnet selection. Using this VPC in a subnet selection like

{ subnetType: SubnetType.Private }

throws an error

Error: There are no 'Private' subnets in this VPC. Use a different VPC subnet selection.
    at ImportedVpc.selectSubnetObjects (/Users/samikukkonen/atk/op-smart-compensation/packages/infra/node_modules/@aws-cdk/aws-ec2/lib/vpc.js:133:19)
    at ImportedVpc.selectSubnets (/Users/samikukkonen/atk/op-smart-compensation/packages/infra/node_modules/@aws-cdk/aws-ec2/lib/vpc.js:72:30)
    ...

To Reproduce

Create a stack that exposes VpcAttributes and another stack that uses Vpc.fromVpcAttributes with those attributes. The subnets of the VPC are not resolved correctly for the dependent stack.

Expected behavior

Behavior should be equal to 0.31.0 where importing an exported VPC would correctly resolve the VPC's subnets.

Version:

• OS: macOS 10.14.5
• Programming Language: TypeScript
• CDK Version: 0.32.0

[eladb]

@strax if the two stacks are in the same app, there is no need to export/import the VPC, just reference directly and the framework will produce the exports/imports as needed.

Is this your use case?

[strax]

@eladb Both stacks are in the same app, but in the first stack the VPC is imported with Vpc.fromLookup. As 0.32.0 removed export() the VpcAttributes property in the first stack is actually the imported IVpc object (just downcasted to VpcAttributes). This scenario produces the error above.

I debugged this a bit and it seems that during synthesis the VpcBase#selectSubnetObjects method is called on an instance that contains zero subnets (public or private) and its ID is vpc-12345, so it seems that the references are not somehow correctly resolved.

[strax]

#2631 might also be related.

[eladb]

You can't downcast VpcAttributes to IVpc. They are not compatible (VpcAttributes is just a bunch of attributes that represent the VPC).

I believe you should be able to just use the vpc object as-is without fromVpcAttributes.

Also, why not just call Vpc.fromLookup and use the VPC in two of the stacks (it will only perform the lookup once as long as it's the same account/region).

[strax]

You can't downcast VpcAttributes to IVpc. They are not compatible (VpcAttributes is just a bunch of attributes that represent the VPC).

@eladb Sorry, I actually meant upcasting as VpcAttributes is a supertype of IVpc (at least the TypeScript variant of CDK allows one to assign IVpc to VpcAttributes). In more concrete terms, what we're doing is roughly the following:

class StackA extends Stack {
   readonly vpc: VpcAttributes

   constructor(scope: App, id: string, props: any) {
      this.vpc = Vpc.fromVpcAttributes(this, "Vpc", new VpcProvider(...).vpcProps)
   }
}

interface StackBProps {
   stackAVpc: VpcAttributes
}

class StackB extends Stack {
   constructor(scope: App, id: string, props: StackBProps) {
     const stackAVpc = Vpc.fromVpcAttributes(this, "StackAVpc", props.stackAVpc)
     // Error happens when `stackAVpc` is used in a subnet selection
   }
}

const app = new App()
const stackA = new StackA(app, "StackA")
const stackB = new StackB(app, "StackB", { stackAVpc: stackA.vpc }) 

I believe you should be able to just use the vpc object as-is without fromVpcAttributes.

Also, why not just call Vpc.fromLookup and use the VPC in two of the stacks (it will only perform the lookup once as long as it's the same account/region).

Do you mean we could just model stackAVpc as IVpc and use it directly in StackB without having to use fromVpcAttributes again?

[strax]

It looks like directly reusing the same VPC object without importing it again in the second stack works flawlessly in our case, so closing this. Thanks for the help @eladb!

[eladb]

Glad to hear.