Connecting VPCs using the AWS Cloud Development Kit

Welcome to Ping Me!: a short series of articles in which we are going to build out and compare three different solutions — VPC Peering, Site-to-Site VPN and Transit Gateway — for connecting VPCs together.

We will be doing the building using AWS Cloud Development Kit. Then, we will prove that each connection works by deploying two EC2 instances, one on each end of the connection, and making a successful ping between them.

Before we jump headfirst into hacking out our infra, I’d like to take a minute to talk about infrastructure as code (IaC), and why it is important.

Infrastructure as code (IaC) on AWS

IaC is a powerful concept. With IaC, instead of clicking through graphical user interfaces you can code your infrastructure exactly the same way you would code any other application. And since it is code, you can apply all the best coding practices to it, e.g. version control, static code analysis, peer review, etc.

With IaC your infra can be immutable, replicable, less error-prone than manual changes (especially when a lot of repetitiveness is involved); it works great at scale, can be automated, you can write tests for it… I’d daresay there’s no DevOps without IaC. Everything as Code? Hell yeah!

There are many tools to pick and choose from when it comes to implementing infrastructure as code; Puppet, Chef and Ansible just to name a few. Terraform is one that shines exceptionally bright on the IaC firmament. Despite just reaching v1.0, it is a mature and battle-tested tool that has been used by organizations of all shapes and sizes for years.

Nonetheless, a new kid showed up on the block recently — the name’s AWS CDK, and it may soon disrupt the status quo. AWS CDK is a software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation.

What that means is that instead of declaring your resources and their interconnections in YAML (like you would do in Ansible, for instance) or in JSON (like you could do in CloudFormation, which also supports YAML) or in a Domain-Specific Language (as is the case with Terraform and its Hashicorp Configuration Language (HCL); JSON is also supported if you’re a masochist) you can actually code in TypeScript, Javascript, Python, Java, C# and Go.

One apparent limitation of the CDK is that, at least for the nonce, it can only be used with AWS (there are two notable projects in the work right now that will greatly expand CDK’s reach: cdk8s and cdktf). With Terraform, you can choose from a plethora of providers. Hell, I was able to set up my home network running on Unifi Dream Machine using Terraform. How cool is that?!

PS Pulumi, deserves an honorable mention in this little digression of mine, since it might be just the right mix of Terraform’s providers and CDK’s general-purpose languages support.

Prerequisites

If you want to follow me along, you’ll need to have:

1. Access, with adequate permissions, to an AWS account;

2. AWS CLI v2 that’s properly configured;

3. Node v10.3 or higher — I’ll be using node v14.14.0 with npm v6.14.9. I recommend installing it with NVM:

   nvm install v14.14.0nvm use v14.14.0

4. AWS CDK:

   npm install -g aws-cdk

5. TypeScript:

   npm install -g typescript

6. Some dollars to spend — even with the free tier on, be prepared to incur a few dollars of costs. Be sure to destroy your stacks as soon as possible to avoid incurring much bigger costs!

Preparations

Before we commence with provisioning any resources, we ought to do some prep work. Let’s start by creating a working directory for our project:

➜  ~$ mkdir ping-me-cdk-example && cd $_

Next, we scaffold our project using CDK’s neat init command specifying app as the template and typescript as the language:

➜  ping-me-cdk-example$ cdk init app --language=typescriptApplying project template app for typescript# Welcome to your CDK TypeScript project!This is a blank project for TypeScript development with CDK.The `cdk.json` file tells the CDK Toolkit how to execute your app.## Useful commands * `npm run build`   compile typescript to js * `npm run watch`   watch for changes and compile * `npm run test`    perform the jest unit tests * `cdk deploy`      deploy this stack to your default AWS account/region * `cdk diff`        compare deployed stack with current state * `cdk synth`       emits the synthesized CloudFormation templateExecuting npm install...npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142npm WARN deprecated request-promise-native@1.0.9: request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142npm WARN deprecated har-validator@5.1.5: this library is no longer supportednpm notice created a lockfile as package-lock.json. You should commit this file.npm WARN ping-me-cdk-example@0.1.0 No repository field.npm WARN ping-me-cdk-example@0.1.0 No license field.✅ All done!

You should end up with the following structure:

ping-me-cdk-example├── bin│   └── ping-me-cdk-example.ts├── lib│   └── ping-me-cdk-example-stack.ts├── node_modules│   └── ... # Many, many subfolders here├── test│   └── ping-me-cdk-example.test.ts├── .gitignore├── .npmignore├── cdk.json├── jest.config.js├── package-lock.json├── package.json├── README.md└── tsconfig .json

As you can see, CDK has created a rather intimidating host of files and subdirectories for us. Well, not so intimidating if you’ve ever worked with Node and/or TypeScript before. Most of it is boilerplate and throughout these articles we shall only deal with the ping-me-cdk-example/bin/ping-me-cdk-example.ts file and the ping-me-cdk-example/lib directory.

Let’s remove ping-me-cdk-example/lib/ping-me-cdk-example-stack.ts and ping-me-cdk-example/test/ping-me-cdk-example.test.ts as they’d just get in the way:

➜  ping-me-cdk-example$ rm lib/ping-me-cdk-example-stack.ts test/ping-me-cdk-example.test.ts

Also, let’s wipe clear the contents of the ping-me-cdk-example/bin/ping-me-cdk-example.ts file:

➜  ping-me-cdk-example$ > bin/ping-me-cdk-example.ts

With the groundwork done, we’re now ready to connect Amazon VPCs with VPC peering. Please remember that all the code is available on GitHub.