Modularity

Having just talked about reusability, it's hard to shake the notion that this sounds a lot like reusability by another name: modularity. Although they are related concepts, they are not the same. Essentially, reuse is an outcome of modular code. As you structure code, focus on modularity and let the reuse flow naturally from it. I wanted to introduce the concept formally, though, because I'll be teasing apart the VPC and networking aspects of the stack from the application-specific resources by creating modules.

The other critical piece in designing a good, robust module is ensuring consistent and clean interfaces that hide (or abstract, if you prefer the academic term) the inner workings of the module that aren't necessary for the consumer of the module. The primary focus will be the construction of two modules: one for shared services (i.e., the networking elements), which I'll cover in this article, and one for a web application running behind a load balancer, to be covered in a future article.

Next, I'll look at how to orchestrate these individual modules to produce all of the infrastructure needed for the application, and finally, I'll look at some lifecycle considerations, while considering the tightly knit relationship between CloudFormation, the CDK code, and CDK resources.

VPC from the Ground Up, CDK Style

To keep your code not only logically but also physically modular, create a new file in the lib directory that will contain the code for the networking resources:

$ touch lib/hello-cdk-base.ts

Listing 4 contains the code that should go in this file [20]. When the time comes to build, you'll need the @aws-cdk/aws-ec2 npm module installed, so you should take care of that now:

$ npm install --save @aws-cdk/aws-ec2

01 import cdk = require('@aws-cdk/cdk');
02 import ec2 = require('@aws-cdk/aws-ec2');
03
04 export class HelloCdkBase extends cdk.Stack {
05   public readonly vpc: ec2.VpcNetworkRefProps;
06
07   constructor(parent: cdk.App, name: string, props?: cdk.StackProps, env?: string) {
08     super(parent, name, props);
09
10     const maxZones = this.getContext('max_azs')[`${env}`]
11
12     const helloCdkVpc = new ec2.VpcNetwork(this, 'VPC', {
13       cidr: this.getContext('cidr_by_env')[`${env}`],
14       natGateways: maxZones,
15       enableDnsHostnames: true,
16       enableDnsSupport: true,
17       maxAZs: maxZones,
18       natGatewayPlacement: { subnetName: 'DMZ' },
19       subnetConfiguration: [
20         {
21           cidrMask: 24,
22           name: 'Web',
23           subnetType: ec2.SubnetType.Public,
24         },
25         {
26           cidrMask: 24,
27           name: 'App',
28           subnetType: ec2.SubnetType.Private,
29         },
30         {
31           cidrMask: 27,
32           name: 'Data',
33           subnetType: ec2.SubnetType.Isolated,
34         },
35       ],
36       tags: {
37         'stack': 'HelloCdkCommon',
38         'env': `${env}`,
39         'costCenter': 'Shared',
40         'deleteBy': 'NEVER',
41       },
42     });
43
44     this.vpc = helloCdkVpc.export();
45   }
46 }

Although I won't cover the complexities of VPCs, subnets, and all of the accompanying network elements that accompany them in depth, I will mention them for the sake of discussing how they appear in the CDK code.

Subnets, AZs, and NAT Gateways

A look through the VPC code in Listing 4 shows a build-out of a reference three-tier networking architecture with dedicated subnets for a front end, where resources like load balancers, proxies, or ingress controllers live. Accordingly, these subnets are designated Web (line 22). The ec2.SubnetType.Public designation used for the subnetType parameter for these particular subnets tells the CDK that this subnet will receive public traffic.

The natGateways parameter (line 14) tells the VpcNetwork constructor function how many AWS NAT Gateways you'd like to provision. By changing the number of availability zones (AZs) that are being used according to environment type (e.g., the "dev" environment will only use two AZs, compared with three for the "qa" and "prod" environments; see the "How Context Works in the AWS CDK" box for more details on specifying context), you're limiting cost in lower environments by restricting the number of AZs into which to deploy resources. Accordingly, the maxAZs parameter is what tells the constructor function the number of AZs you want to use; omitting this parameter will cause the aforementioned default behavior of utilizing all AZs available for a given region.

{
  "app": "node bin/hello-cdk.js"
}

this.getContext('cidr_by_env')[`${env}`]
this.getContext('max_azs')[`${env}`]

cdk -c VAR=value

cdk -c VAR1=value1 -c VAR2=value2

01 {
02   "app": "node bin/hello-cdk.js",
03   "context": {
04     "cidr_by_env": {
05       "dev": "10.100.0.0/16",
06       "qa": "10.200.0.0/16",
07       "prod": "10.300.0.0/16"
08     },
09     "max_azs": {
10       "dev": 2,
11       "qa": 3,
12       "prod": 3
13     }
14   }
15 }

From the code in the subnetConfiguration block, you can see three types of subnets: Public, Private, and Isolated. As mentioned, the Web subnets are of the Public type. The Web and App subnets are provisioned with /24 netmasks, meaning you have 251 usable IP addresses (256 addresses total minus five AWS-reserved addresses; see the "AWS Networking Primer" box for more details on networking within AWS). For the Data subnets (e.g., where databases and other data-related services might reside), smaller subnets are used: a /27, yielding 27 usable addresses per subnet (32 theoretical available addresses minus five AWS-reserved addresses).

For subnet and subnet types, the natGatewayPlacement parameter tells the CDK where you want it to place your NAT gateways when you create your VPC. The DNS tags parameters (lines 36-41) give additional flexibility for the use of custom internal DNS domains within your VPC. The tags parameter, while providing conventional AWS tag sets on all the networking resources (which are abundantly useful in and of themselves within the AWS ecosystem for a multitude of reasons), also take on additional functionality within the context of the CDK, which I will cover in future discussions.