DEV Community: Faizan Raza

What Are AWS CDK Constructs, Stacks and How To Use Them

Faizan Raza — Tue, 17 May 2022 08:21:57 +0000

When getting started with the AWS CDK, one of the most confusing aspects are the new terminologies of apps, stacks and constructs. I will compare constructs vs stacks vs apps to explain what they are and when to use them.

At a glance

A table comparing apps vs stacks vs constructs

A sample of how constructs, stacks and apps may be organised

Constructs

AWS CDK constructs at their core represent one or more AWS resources - however, these come in three common and distinct flavours:

Level 1 Constructs

What are they

Level 1 constructs correspond directly to a single AWS resource, exactly how it is described within AWS Cloudformation. Examples of this would a single S3 Bucket, a Lambda function and a DynamoDB table.

When to use

When a new AWS service or resource is added to the AWS CDK, it initially is added as a level 1 construct. However, they are usually then followed by superior level 2 constructs described below. Level 1 constructs should primarily be used when level 2 constructs are not available.

Level 2 Constructs

What are they

Level 2 constructs are built on top of level 1 constructs, however, these include quality of life and usability improvements around a particular service. The lambda function construct is a prime example of this. The level 1 Lambda function construct requires a pre-existing s3 bucket object, containing the compressed Lambda source code and will only create the Lambda function resource itself.

The level 2 construct, however, requests the location of the uncompressed source code locally, automatically uploads this to an S3 bucket for you and then deploys this within the lambda function. Additionally, it will enable CloudWatch logs out of the box and give the lambda function the correct associated permissions.

When to use

Level 2 constructs are what you will mostly be working with when creating your AWS solution. The AWS CDK team put a lot of effort into providing these and are generally of very high calibre. It is possible to write your own but it is unlikely this will be required.

Level 3 Constructs

What are they

Level 3 constructs are opinionated units of reusable code which often deliver a service. Open source level 3 constructs are available from AWS Solutions Constructs - an extension to the CDK, CDK Patterns - a library of well-architected patterns, Construct Hub - a library of open-source constructs and some even come out of the box with the CDK - these are appended with 'patterns' to make them identifiable. Two examples are shown below:

A simple web service using API Gateway, Lambda and DynamoDB

A Static React/Angular Single Page Application Website

When to use

If you are able to find a level 3 construct which matches your desired architecture - you should use this level 3 construct. However, if one does not exist, you should evaluate whether your specific pattern is likely to be reused - either within your code or within your organisation. If the answer is yes, then you should be writing your own level 3 construct from the available level 1 and 2 constructs. If you are working on any enterprise or large scale project, you will find the majority of your time spent with the CDK is spent creating level 3 constructs.

Bonus: Tips for Building L3 Custom Constructs

While a construct should be opinionated and achieve one goal very well, it is important to add properties to allow configuration of the underlying resources and expose the resources created. For example, if you could not configure a lambda function's resources, it would prevent anyone who needs a larger function from using your construct.

But do not expose excessive amounts of the underlying infrastructure to the user to nullify any abstractions you provided. Recall how the Lambda Function construct automatically uploads the source code to an S3 bucket and then uses this in the lambda function. Providing the object name or path of the uploaded source code as a configurable option would be irrelevant to this construct and unnecessarily leak this abstraction to the user.

Stacks

What are they

Stacks correspond exactly to one single CloudFormation stack and the corresponding assets. The defining feature of a stack is that it is a unit of deployment - you can deploy stacks independently of each other, but all of the resources within a stack will be deployed together.

When to use

You should use stacks to combine resources which should be deployed together. A common split would be having frontend and backend resources in a separate stack. Additionally, having frequently changes and infrequently changed resources in separate stacks. For example, you may not want your infrequently changing networking and database layers in the same stack as your frequently changing compute and content layers.

Apps

Apps are the root object and contain stacks. The key feature here is that stacks housed within the same app can share resources with each other. For example, a backend stack can share resources with the front end stack. Multiple apps can exist in a single project folder, however:

CDK can only deploy or synthesise one stack at a time, whereas it can deploy multiple stacks.
Two apps can not be defined in the same file - they must live in separate files
Two apps can not reference each other's resources

When to use

This is always the root object in a CDK app and should contain all the stacks required for an application. Whether or not to house a stack in a separate app comes down to whether it needs to share resources with any other stacks. Examples of this could be load testing stacks and infrastructure testing stacks - these would most likely not need to have access to resources within the front end and backend stacks so could sit in a different app.

Follow Me

Follow me on LinkedIn

How to host a static website on AWS with S3, CloudFront, Route53 and Terraform

Faizan Raza — Mon, 16 May 2022 08:03:30 +0000

How to host a static website on AWS with S3, CloudFront, Route53 and Terraform

Hosting a website on AWS using Cloudfront, S3 and Route53 is a popular solution for Amazon web hosting. It typically costs $3 a month outside of the generous free tier and $0.50 within the free tier. Terraform can automate the deployment of this finicky architecture making it much easier to deploy, manage and automatically upload website content. We will use an open-source Terraform module to deploy a secure, scalable and performant website on AWS based on Route 53, CloudFront and S3.

Architecture

The vast majority of Terraform tutorials I see covering similar topics all focus on recreating an identical architecture from stack utilising resources which is simply a waste of time and effort. Existing tutorials and modules generally follow the architecture shown below which is based on the AWS tutorials Configuring a static website on Amazon S3 and Speeding up your website with Amazon CloudFront. Since they are based on tutorials, the following flaws remain:

The architecture that most tutorials and guides follow

Two buckets are created when only one is really required.
The root bucket is publicly exposed. Public S3 buckets have been at the centre of several high profile data leaks. Due to this, it is increasingly becoming corporate policy to completely disallow public S3 buckets.
The users still have the ability to access the bucket objects directly from the s3 website endpoint. This circumvents the CloudFront distribution and can nullify CloudFront features like geographic restrictions.
A manual activity remains to upload the website content onto the S3 bucket.

The improved architecture of what will be deployed in this guide

My module "s3-cloudfront-static-website" uses the architecture shown above which represents a much simpler, secure and straightforward architecture.

This only uses one bucket for both the root and www. domains.
The bucket is private and CloudFront accesses the website content utilising an Origin Access Identity with IAM permissions to the S3 Bucket.
Users can only access the website through CloudFront.
Website content can be automatically uploaded during Terraform deployment (uses AWS CLI).

Pre-requisites

Domain name
Route 53 Hosted Zone which is the DNS Provider for the domain
AWS CLI locally installed with a configured named profile
Terraform CLI locally installed

If you require assistance with the pre-requisites review the following subsections.

Domain Name

To use a domain name, you must purchase the domain from a registrar like Google, Go Daddy, 123-Reg, names.co.uk or AWS Route 53. Using AWS Route 53 is easiest since AWS will automatically create a hosted zone for the domain, assign four name servers to the hosted zone, and then update the domain registration to use those name servers. However, it is normally the most expensive option for a domain. I personally browse for the best price for my desired main domain and find names.co.uk is a great site for free domains for testing or development. Beware of the higher prices after the first year. I also turn off auto-renewal - especially for free domains.

Route 53 Hosted Zone as DNS Service for the Domain

If you bought your domain through AWS Route 53, you can skip this section. If you bought the domain from another website, you need to create a route 53 hosted zone and make Route 53 the DNS service for your domain. Put simply, the Domain Name Service (DNS) is the phonebook of the internet, when a user inputs your domain name, DNS will return the correct IP address to access your site. Name servers are underlying servers which contain and return the information of which IP addresses correspond to which services on your domain. To make Route 53 the hosted zone for your domain, you must change the name servers from your registrar's to your Route 53 hosted zone's.

How to create a Route 53 Hosted Zone

Sign in to the AWS Management Console and open the Route 53 console.
If you're new to Route 53, choose Get started under DNS management. If you're already using Route 53, choose Hosted zones in the navigation pane.
Choose Create hosted zone.
In the Create Hosted Zone pane, enter the name of the domain that you want to route traffic to. You can also optionally enter a comment. The domain name for this website is interweave.cloud - you do not need to include 'www.' or 'HTTPS://'.
For Type, accept the default value of Public Hosted Zone.
Choose Create.

Update the name servers for the domain

Open the Route 53 console at https://console.aws.amazon.com/route53/
In the navigation pane, choose Hosted zones.
On the Hosted zones page, choose the radio button (not the name) for the hosted zone, then choose View details.
On the details page for the hosted zone, choose Hosted zone details.
Make note of the four servers listed for Name servers.
Use the method provided by the registrar for the domain to change the name servers for the domain to use the four Route 53 name servers you got from step 5. NOTE: it can take up to 3 days for the change to become effective.

AWS CLI

To upload your files to the s3 bucket automatically, the AWS CLI tool is used. Therefore, it is required for the AWS CLI to be installed on your local machine - instructions can be found here. You also need to configure a local named profile using the aws configure --profile NAME command. Using named profiles is generally better than static credentials within Terraform.

Terraform Code

The terraform module is available on the Terraform Registry with the source code available on GitHub with examples shown. We would like to deploy a static website with the files automatically synced and a custom domain name.

Providers.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.10.0"
    }
  }
}

# Default provider for resource creation
provider "aws" {
  region  = ""
  profile = ""
}

# Provider required in useast1 for CloudFront, SSL Certificate
provider "aws" {
  alias   = "useast1"
  region  = "us-east-1"
  profile = ""
}

In providers.tf you will have two providers:

Default provider for the region where your main infrastructure will be deployed.
'useast1' provider for CloudFront and the SSL certificates. These sit in the us-east-1 region because they are global services.

main.tf

module "s3-cloudfront-static-website\_example" {
  source  = "InterweaveCloud/s3-cloudfront-static-website/aws"
  version = "0.0.1"

  resource\_uid   = "DevOpsNavy" 
  domain\_name    = "XXX" 
  hosted\_zone\_id = "XXX" 
  profile        = "XXX" 

  sync\_directories = \[{
    local\_source\_directory = "./website\_content"
    s3\_target\_directory    = ""
  }\] 

  providers = {
    aws.useast1 = aws.useast1
  }
}

Variable	Description
resource_uid	UID which will be prepended to resources created by this module
domain_name	The domain name for the website.
hosted_zone_id	The Hosted Zone ID. This is automatically generated and can be referenced by zone records.
profile	Credentials profile to use for AWS s3 sync command
sync_directories	Directories to sync with S3

Variables within sample code

Following the normal terraform init, terraform plan and terraform apply workflow will deploy the infrastructure and your site will be up and running! If you update your website content, you can rerun Terraform apply and a change will be detected and the content re-synced.

What Next?

Automated deployment through GitHub Actions

We are currently developing an associated GitHubActions pipeline which will automate the Terraform deployment and the build of the source code.

Monitoring and Budgeting Alarms

We are looking into creating a monitoring dashboard and budgeting alarms.

General quality of life updates

We are making general QoL updates such as making the domain name optional initially in case this is not readily available at the start.

Follow Me

Follow me on LinkedIn

Terraform - Understanding the Value - Declarative Language (TERF)

Faizan Raza — Sun, 07 Nov 2021 18:49:46 +0000

Introduction

I was asked at work recently by someone completely new to DevOps and coding in general - "Why would you use Terraform? It is so much easier to do things in the portal."

Today, we will be exploring my personal favourite feature of Terraform - the fact it is declarative.

Yes - I have ranked my favourite and most hated features of Terraform :).

This will be very beginner orientated. This is also a laying down some of the foundational concepts for the upcoming TERF series (Terraform Enterprise Ready Framework).

What does it actually mean to be declarative?

Terraform state on their website:

The Terraform language is declarative, describing an intended goal, rather than the steps to reach that goal.

A common explanation on google searches:

A language which describes what needs to be done, instead of how to do it.

If you are like me - when you first started using Terraform and following tutorials you probably thought, "I am telling Terraform to create these resources for me, but I am also telling it how to join these resources together, so, what exactly is declarative about this?"

The way I understand it:

Terraform allows you to create an image of exactly what you want your infrastructure to look like and then Terraform manages the underlying logic to transform the infrastructure into your desired state.

If no infrastructure currently exists, Terraform will create the new infrastructure in the correct sequence of steps to create what you coded.

If infrastructure currently exists, but does not match your coded image, then Terraform will orchestrate the sequence of events required to change the infrastructure to match what you coded.

Let's learn through an example - an AWS virtual machine

We will be using the example provided under "Network and Credit Example" at the following Link.

We will be creating:

A VPC with CIDR address 192.168.0.0/24.
A subnet with CIDR address 192.168.0.0/24.
A network interface card associated with the above subnet.
An EC2 instance with the above network interface card attached.

Creation through the portal

Creation through the portal requires the following steps:

Create the VPC through the VPC section of AWS.
Create subnet under that VPC in the VPC section of AWS.
Create a network interface in the subnet in the EC2 section of AWS.
Create an EC2 instance attaching the above network interface and selecting above subnet and VPCs during the configuration process.

Note: The above call be done from the EC2 launch wizard where you can select "Create VPC" and "Create Subnet" under stage "3. Configure Instance".

Let's say we want to change the VPC and subnet CIDR subnets to 192.168.1.0/24 - AWS documentation states:

It's not possible to modify the IP address range of an existing virtual private cloud (VPC) or subnet. You must delete the VPC or subnet, and then create a new VPC or subnet with your preferred CIDR block.

If you tried to go make this change within the portal you see this:

This means that you have to do the following in this order:

Delete the EC2 instance
Delete the network interface
Delete the subnet
Delete the virtual machine

You would then have to recreate all the resources all over again. Now, just imagine this change with multiple EC2 instances and other virtual infrastructure created within that VPC.

Creation through Terraform

The sample Terraform could be used for this slightly more semantic code:

resource "aws_vpc" "DemoVPC" {
  cidr_block = "192.168.0.0/24"

  tags = {
    Name = "DemoVPC"
  }
}

resource "aws_subnet" "DemoSubnet" {
  vpc_id            = aws_vpc.DemoVPC.id
  cidr_block        = "192.168.0.0/24"
  availability_zone = "us-west-2a"

  tags = {
    Name = "DemoSubnet"
  }
}

resource "aws_network_interface" "DemoNIC" {
  subnet_id   = aws_subnet.DemoSubnet.id

  tags = {
    Name = "DemoNIC"
  }
}

resource "aws_instance" "DemoVM" {
  ami           = "ami-005e54dee72cc1d00" # us-west-2
  instance_type = "t2.micro"

  network_interface {
    network_interface_id = aws_network_interface.DemoNIC.id
    device_index         = 0
  }

  credit_specification {
    cpu_credits = "unlimited"
  }
}

Terraform would create the following plan:

  # aws_instance.DemoVM will be created
  # aws_network_interface.DemoNIC will be created
  # aws_subnet.DemoSubnet will be created
  # aws_vpc.DemoVPC will be created
Plan: 4 to add, 0 to change, 0 to destroy.

Terraform would then create these resources

aws_vpc.DemoVPC: Creation complete
aws_subnet.DemoSubnet: Creation complete
aws_network_interface.DemoNIC: Creation complete
aws_instance.DemoVM: Creation complete

Notice how Terraform created the infrastructure in the correct order? Well it is not too evident here but it will become more evident in the following example.

To make change the VPC and Subnet CIDR we would change the code :

resource "aws_vpc" "DemoVPC" {
  cidr_block = "192.168.1.0/24"

  tags = {
    Name = "DemoVPC"
  }
}

resource "aws_subnet" "DemoSubnet" {
  vpc_id            = aws_vpc.DemoVPC.id
  cidr_block        = "192.168.1.0/24"
  availability_zone = "us-west-2a"

  tags = {
    Name = "DemoSubnet"
  }
}

resource "aws_network_interface" "DemoNIC" {
  subnet_id   = aws_subnet.DemoSubnet.id

  tags = {
    Name = "DemoNIC"
  }
}

resource "aws_instance" "DemoVM" {
  ami           = "ami-005e54dee72cc1d00" # us-west-2
  instance_type = "t2.micro"

  network_interface {
    network_interface_id = aws_network_interface.DemoNIC.id
    device_index         = 0
  }

  credit_specification {
    cpu_credits = "unlimited"
  }
}

Terraform would make the following plan:

Terraform has picked up that to make this change, all the resources must be deleted and recreated:


Terraform will perform the following actions:

  # aws_instance.DemoVM must be replaced
  # aws_network_interface.DemoNIC must be replaced
  # aws_subnet.DemoSubnet must be replaced
  # aws_vpc.DemoVPC must be replaced

Plan: 4 to add, 0 to change, 4 to destroy.

However Terraform also knows the sequence in which these events needs to occur. For example it can not delete the VPC until everything else is deleted. You can see this in the simplified output from the console:

aws_instance.DemoVM: Destruction complete 
aws_network_interface.DemoNIC: Destruction complete
aws_subnet.DemoSubnet: Destruction complete
aws_vpc.DemoVPC: Destruction complete
aws_vpc.DemoVPC: Creation complete
aws_subnet.DemoSubnet: Creation complete
aws_network_interface.DemoNIC: Creation complete
aws_instance.DemoVM: Creation complete

This time, it is evident that Terraform orchestrated the destruction and creation of resources into the correct order.

We did not have to tell Terraform to destroy the old infrastructure, to recreate new infrastructure or explicitly state the order of events. This is the declarative nature of Terraform.

Concluding Remarks

In complex and layered deployments - this declarative nature is a game changer and lets you focus on delivering business value and functionality. Terraform abstracts away underlying logic and sequencing of events.

I work on a Terraform code base over 2000 lines long and managing over 250 resources in AWS. Whenever I have made changes to a resource which are sequenced in the beginning or middle of the deployment, Terraform has been comfortably able to orchestrate the change.

Support Me

Follow me here on Dev.to
Follow me on LinkedIn
Comment below feedback to help me improve my series!