logo

AWS Exam GuidesNewsletterBlogContact

👋 Hey! My name is Wojciech Gawroński, but others call me AWS Maniac.

My goal is to safely guide you through the cloudy and foggy space of the AWS portfolio.

Troubleshooting AWS CDK: part 2 - Explicit Dependencies

2 min read, last updated on 2020-12-22

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!

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 (let 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 a DependsOn entry for each AWS::EC2::NatGateway resource.

Summary

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.

Subscribe to the newsletter and get notifications about new posts.

Subscribe

👋 Hey! My name is Wojciech Gawroński, but some people call me AWS Maniac. I am your trusted guide through the AWS Madness. If you want to learn more about me, you can start here.

Share it:

YouTube, Twitter, LinkedIn, Instagram, Facebook
awsmaniac.com © 2021, built with Gatsby and template from @kjendrzyca