Categories
AWS CDK

Troubleshooting AWS CDK: part 2 – Explicit Dependencies

In the previous article, we have overcome two relatively straightforward and expected issues (especially if you have some experience with CloudFormation). Now we have a much bigger problem that we need to face.

In the previous article, we have overcome two relatively straightforward and expected issues (especially if you have some experience with AWS CloudFormation). Now we face a much bigger problem.

Ooops, NAT Gateway cannot stabilize in some stacks!
Ooops, NAT Gateway cannot stabilize in some stacks!

Investigation

The problem is with dependencies between resources. It turns out that we are creating NAT Gateways before our IGW will be created. It happens not always in that order. For some nested stacks, we do that in the right order. However, in some cases, we hit the reverse situation, and that is causing trouble.

You need to be explicit!

In a typical AWS CloudFormation stack, you would slap DependsOn on the affected resource, and that’s it. Here we have a bit more work to do: as everything is related to the infrastructure graph.

To create an explicit dependency between resources, you need to select that affected resource and create an addiction to another node that you have to find. Sounds troublesome, isn’t it?

Luckily in one of the previous posts, I have explained to you how AWS CDK names particular nodes so you can craft your path. So we need to do the following:

// NAT Gateways must wait for IGW. // // We need to look for a NAT Gateway inside each // PublicSubnet according to the name convention // introduced in the AWS CDK pattern for VPC. // // After finding it, we are adding an explicit dependency // on the Internet Gateway. const igw = this.node.findChild('IGW'); for (i = 1; i < this.availabilityZones.length + 1; ++i) { const nat = this.node.findChild(`PublicSubnet${i}`) .node.findChild('NATGateway'); nat.node.addDependency(igw); }

And that is it! It will work in the same way as DependsOn, which can be observed with cdk synth and a resulting template:

"ParticipantVpcForUser03PublicSubnet1NATGatewayAB30A51C": { "Type": "AWS::EC2::NatGateway", "Properties": { "AllocationId": { // ... }, "SubnetId": { // ... }, "Tags": [ // ... ] }, "DependsOn": [ "ParticipantVpcForUser03IGW3417B09D" ], "Metadata": { "aws:cdk:path": "..." } },

Thanks to a call to addDependency, it created DependsOn entry for each AWS::EC2::NatGateway resource.

Summary

Yay, all nested stacks created successfully!
Yay, all nested stacks created successfully!

Okay, so we fought overall issues, and we can rest now? Not exactly, as we can improve a few things here and there, including AWS CDK Aspects, and compare this approach with other tools like Terraform.

By Wojciech Gawroński

Principal Cloud Architect at Pattern Match. Infrastructure as Code, DevOps culture and AWS aficionado. Functional Programming wrangler (Erlang/Elixir).

Comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.