Best practices for cross-stack CDK to CFN and vice versa

I wanted to see whether something was at all possible - whether a VPC created using a CDK construct could be used with a LoadBalancer created via cloudformation and vice versa.

This is important for me as:

• the constructs currently aren’t fine grained enough for us to use instead of cloudformation primitives in some cases (eg, no accessLoggingPolicy on the load balancer)
• we may want to use our existing cloudformation-based VPCs with CDK constructs

The example is here: https://gist.github.com/mipearson/aeaf303b0770c25f8b5f6e360594cfbf

Is this what is recommended for solving this sort of problem?

[rix0rrr]

Sharing between CDK apps and CloudFormation templates

You got it. If there is information that needs to be shared between stacks, the mechanisms we have are Outputs & Parameters, and Exports & Fn::ImportValues.

We could also use SSM Parameter Store values, which work much like Exports but without the “foreign key constraints” that Exports bring.

CDK to CloudFormation

If you define a VPC inside a CDK app and want to use it from a CFN template, it actually functions much the same as how you would share the template between plain CFN templates. You would output/export in the one template and parameter/import in the other.

The exporting works by calling vpc.export() inside your CDK app. What that does is create Exports for all attributes of your VPC that another CDK stack would need to import it again… but those outputs and exports are available to any CFN stack as well! Deploy a template and pick your favorite method of getting the VPC information into your template.

If you’re unhappy about the default names of the Exports (understandable since they are designed to be consumed transparently), you’re free to add some new Output()s to your CDK stack, which translate directly into CloudFormation Outputs and can be made into Exports as well.

CloudFormation to CDK

So you already have an existing VPC (deployed through CloudFormation or otherwise) that you want to consume in a CDK application. As you figured out, what you want to do is get a VpcNetworkRef instance from VpcNetworkRef.import(), which expects a number of properties (https://awslabs.github.io/aws-cdk/refs/_aws-cdk_aws-ec2.html#@aws-cdk/aws-ec2.VpcNetworkRefProps):

vpcId, availabilityZones, publicSubnetIds, privateSubnetIds

Again, use your favorite way of getting those values in there. You now have 3 options:

• CloudFormation Parameters–add a new Parameter() to your Stack and use that as the value (but you’re now responsible of specifying the parameter when deploying your synthesized template, which you can no longer do through the CDK toolkit).
• CloudFormation Imports–use a new FnImportValue() expression with the name of the existing export for your VPC.
• Synthesis-time parameters: not ideal in all cases, but you can choose to pass in the concrete values when RUNNING the CDK app (either as context values, or as a parameter to your constructs that are hardcoded into main.ts with different values for every account/region, for example) so the CloudFormation template comes out with the identifiers already filled in.

Of all these, Exports and Imports will give you the most transparent experience.

And from your example, I love how you abstract away the importing of the VPC inside a VpcCFNDemoStack class. For consumers, it is totally awesome to be able to write:

const vpc = OurStandardVPC.obtain(this);

new ThingThatNeedsAVPC(..., { vpc });

Or similar, and not have to worry where the VPC is coming from. It might be constructed on the spot, it might be loaded from another environment.

[rix0rrr]

Sharing between higher-level and lower-level Constructs

If this is what you’re trying to do, it depends on how you want to deploy: in a single stack or across multiple stacks.

Multiple stacks

If it’s across multiple stacks, the solution will be basically the same as what I described in my previous post, except the CloudFormation template will not be handwritten but generated by CDK. The mechanism used will be the same.

To make matters simpler, in the consuming stack you could forego the VpcNetworkRef.import() and just use the properties of VpcNetworkRefProps directly; you probably don’t need the logic built into the VpcNetwork class anymore anyway.

Single stack

This would be even easier, because you can simply access the properties of VpcNetwork directly, such as vpc.vpcId.