Building Resilient Public Networking on AWS: Part 2

Deploy Secure Public Web Endpoints

Welcome to Building Resilient Public Networking on AWS—our comprehensive blog series on advanced networking strategies tailored for regional evacuation, failover, and robust disaster recovery. Here’s a summary of this engaging journey:

Revisiting networking concepts from the client’s perspective: If you missed our exploration of fundamental networking concepts in the first installment, catch up here. We laid the groundwork for understanding the essentials that underpin the forthcoming discussions.
Deploy Secure Public Web Endpoints: In this blog post, we’ll dive into the intricacies of deploying a web server and fortifying its public endpoint on AWS. Additionally, we’ll demystify the management of a DNS hosted zone with Route 53, including its seamless integration with third-party DNS hosting providers.
Region Evacuation with DNS approach: At this point, we will deploy the previous web server infrastructure in several regions, and then we will start reviewing the DNS-based approach to regional evacuation, leveraging the power of AWS Route 53. We’ll study the advantages and limitations associated with this technique.
Region Evacuation with static anycast IP approach: Again, we will deploy the web server infrastructure in several regions, and then we’ll start exploring the concept of region evacuation using the robust Global Accelerator with a static anycast IP approach. Gain insights into its benefits and considerations for implementation.
Client’s TCP persistent connections and why this could be a problem: Concluding our series, we’ll shed light on the critical role of addressing one of the most common HTTP client behaviors—TCP persistent connections. Uncover why overlooking this aspect can lead to the potential failure of previously discussed approaches.

Moreover, we’ve prepared a GitHub repository to complement this blog series. It provides Infrastructure as Code (IaC) using AWS Cloud Development Kit (CDK) and CloudFormation, allowing you to deploy and manage the necessary infrastructure effortlessly.

Introduction

In this second post in our Building Resilient Public Networking on AWS series, designed for readers with intermediate knowledge, we’ll embark on a guided journey to deploy a secure public endpoint fortified with HTTPS. While there are more automated methods for this process, our goal is to make it understandable and accessible for readers who want to delve into the intricacies.

To set up the necessary infrastructure in the Cloud, we’ll employ Infrastructure as Code (IaC) using AWS CDK with TypeScript along with CloudFormation. You can find the corresponding code for this blog post here.

If you’re new to AWS CDK, I recommend reading "Getting started with the AWS CDK" to understand its basics.

Deployment and Configuration Phases

We approach the deployment and configuration of our infrastructure in different phases, utilizing different CDK stacks and incorporating some manual steps for resources outside of AWS. Here’s a concise overview of each phase:

Manual Step

Create a free domain in ClouDNS; we need to pick a unique name that is available on the public internet

First CDK Stage- Foundational Infrastructure

VPC Creation: Spans the entire region, automatically dividing the provided VPC CIDR range. Creates public and private subnets per Availability Zone, ensuring outbound access via an Internet Gateway and resilient NAT Gateways.
Fargate Cluster: Establishes the Elastic Container Service (ECS) in AWS, providing a scalable and serverless container execution environment.
Route53 DNS Public Zone: Sets up a public DNS zone using AWS Route53, laying the groundwork for managing our domain’s DNS records.

Manual Step

Once the foundational infrastructure is in place, we’ll manually configure ClouDNS with the NS records from the public zone created in AWS Route53. This will make our public zone created in Route53 available on the internet.

Second CDK Stage- Web Container Deployment

Web Container Deployment: Utilizes the Fargate Cluster to deploy web container tasks, ensuring scalable and efficient execution.
SSL/TLS Certificate Creation: Creates a public certificate in AWS Certificate Manager (ACM), a crucial step for securing our web public endpoint.
Public Application Load Balancer (ALB): Establishes an ALB, integrating the previous SSL/TLS certificate for enhanced security.
Route53 DNS Records: Configures Route53 DNS records to direct traffic to the deployed ALB, which will be the front door of the web container, ensuring accessibility.

Architecture Overview

The accompanying diagram illustrates the architecture of our deployed infrastructure, showcasing the relationships between key components. While the CDK stacks deploy infrastructure inside AWS Cloud, for external components like the DNS provider (ClouDNS), we will need to execute manual steps, highlighted in the following diagram.

Deployment and Configuration Guide

Now that we have a clear understanding of the role played by each component and AWS product in our infrastructure, let’s streamline the deployment process using powerful automation tools provided by AWS — specifically, AWS CDK and AWS CloudFormation. By leveraging these tools, you can automate the creation and management of your secure public endpoint, ensuring consistency and scalability across your infrastructure.

In this section, we’ll guide you through a step-by-step execution of the actions required to deploy and configure the infrastructure illustrated in the previous image. Our aim is to provide clarity by explaining each step in detail. It’s important to note that, for the sake of clarity, we’ll be performing these actions manually. However, in a real-world scenario, this process should be automated.

To comprehensively understand the automation process and introduce improvements for real-world scenarios, we’ll delve into necessary changes in the "Enhancements and Automation" section later in this blog post. Let’s begin by executing and explaining each step in the deployment process.

Step 0 – Install required tools

To begin the deployment process, you’ll need to install the appropriate tools on the machine where you intend to run these steps. Follow the instructions below based on your operating system:

AWS account credentials
- Install AWS CLI https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
- Get AWS credentials https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
NodeJS installation https://nodejs.org/en/download/

Step 1 – Confirm AWS credentials

Before proceeding, let’s ensure that your AWS credentials are correctly configured and functioning as expected. Follow the steps below to confirm:

List AWS Profiles: Execute the command below to display a list of available AWS profiles.

aws configure list-profiles

Set Default AWS Profile (Optional): If you have multiple AWS profiles and want to specify a default profile, use the following command. Replace xxxxxxxxxx with your desired profile name.

export AWS_DEFAULT_PROFILE=xxxxxxxxxx

Set AWS Default Region: Set the default AWS region.

export AWS_DEFAULT_REGION=us-east-1

Confirm AWS Credentials: Verify that your AWS credentials are correctly set by running the following commands.

aws configure list
aws sts get-caller-identity

Step 2 – DNS Configuration

In this step, you’ll need to choose a unique name for your free domain. As an example, we’ll use "subdomain-1.cloudns.ph" but it’s crucial to select a different public domain name that is available for your use.

Create Free DNS Hosted Zone in ClouDNS:
- Use the template “subdomain-xx.cloudns.ph” to create a free DNS hosted zone in ClouDNS.
- Follow the guide to set up your free DNS zone. Note that if the chosen subdomain is already in use, you must select a different one.

Update Configuration in GitHub Repository:
- In the GitHub repository, locate the configuration file at ./infrastructure/config/environment.ts.
- Update the value of the variable DNS_ZONE_NAME with the chosen subdomain. Utilize the template “subdomain-2.subdomain-xx.cloudns.ph”.

Step 3 – Build CDK project

Now that our GitHub repository is configured with a free public DNS domain name, let’s build and prepare it for deployment.

Make sure you are in the correct folder

cd infrastructure/blog_post_2

Install JavaScript Dependencies: Execute the following command to install the necessary JavaScript dependencies:

npm install -dd

Build the Project: Run the following command to build the CDK project and prepare it for deployment:

npm run build -dd

Step 4 – Bootstrap CDK and Review Infrastructure

This step involves setting up the necessary AWS resources and configurations to deploy your CDK Stacks using CloudFormation.

Bootstrap CDK: Execute the following command to bootstrap the CDK, preparing it for deployment:

npx cdk bootstrap –region us-east-1

Review and Update Initial Infrastructure Status: To review and update the initial status of the infrastructure in AWS, including availability zones for the specified region, use the following commands:

npx cdk context –clear
npx cdk synth –debug -vv

Step 5 – Deploy First CDK Stage(Basic Infrastructure)

Execute the following command to deploy the basic infrastructure requirements in the us-east-1 region:

npx cdk deploy stage-1/* –require-approval never

The basic infrastructure includes:

VPC Creation:
- Spans the entire region, dividing the provided VPC CIDR (Classless Inter-Domain Routing) range.
- Creates public and private subnets per Availability Zone.
- Configures network routing for public subnets to allow outbound access via an Internet Gateway.
- Configures network routing for private subnets to allow outbound access via resilient NAT Gateways (one per AZ).
Create a Fargate Cluster
Create a Route53 DNS Public Zone

After executing this command, you can also review the status of your CDK deployment in CloudFormation from the AWS console.

Step 6 – Configure ClouDNS with the NS records from AWS route53

Go to the AWS Route 53 dashboard from the hosted zone created in the previous step. We will get the DNS records with type NameSever (NS).

Retrieve NS Records from AWS Route 53:
- Go to the AWS Route 53 dashboard and locate the hosted zone created in the previous step. (e.g., “subdomain-2.subdomain-1.cloudns.ph”.)
- Copy the NS records related to the authoritative DNS servers. Example values:

ns-123.awsdns-00.com.
ns-123.awsdns-00.co.uk.
ns-123.awsdns-00.org.
ns-123.awsdns-00.net.

Configure ClouDNS:
- Open your ClouDNS account and access your free DNS zone (e.g., subdomain-1.cloudns.ph).
- Add four NS records, one for each authoritative DNS server:
  - Type: NS record
  - Host: subdomain-2.subdomain-1.cloudns.ph
  - Points to: ns-123.awsdns-00.com

Verification: Before proceeding to the next step, ensure the NS records are correctly configured, and the information is widely spread on the Internet. You can use this online tool for verification. Make sure to replace the example domain with your own.

Step 7 – Clear and Update Infrastructure Status

After creating the basic infrastructure in Step 5, it’s essential to review and update in our CDK project the current status of the infrastructure in AWS before deploying the following CDK Stack. Execute the following commands:

npx cdk context –clear –debug -vv
npx cdk synth –debug -vv

After executing these commands, the file cdk.context.json will be updated. This file contains all the infrastructure dependencies the subsequent CDK stack needs to be deployed in your AWS account.

Step 8 – Deploy Second CDK Stage (Additional Infrastructure)

In this step, we will deploy the remaining infrastructure in the us-east-1 region.

npx cdk deploy stage-2/* –require-approval never

This command initiates the deployment of the following components:

Web Container Task: Deployed in the Fargate Cluster created previously
Public Certificate in ACM: Creates a public certificate in AWS Certificate Manager (ACM).
Public Application Load Balancer (ALB):
- Establishes an ALB, integrating the previous certificate.
- The ALB serves as the entry point for our web container.
Route53 DNS Record: Creates a public DNS record to route traffic to the ALB associated with the web container.

After executing this command, you can also review the status of your CDK deployment in CloudFormation from the AWS console.

Final Step – Remove Created Resources

Once you have finished all the validations, you can clean up all the infrastructure, following these steps to remove the deployed resources.

First, we need to remove the DNS record with type CNAME created by ACM in the public hosted zone in Route53. Ensure this step is completed before proceeding to the next one

The following step will remove the stacks created previously in the reverse order to avoid dependency issues between them.

npx cdk destroy stage-2/* stage-1/*

Following this sequence ensures a smooth and complete removal of all resources.

Testing and Verification

Now that all the necessary infrastructure is in place on your AWS account, it’s time to explore and confirm how the infrastructure behaves. Here are some useful tools for quick verification.

DNS Propagation Check

DNS Checker is an online tool to validate DNS propagation across the internet. Remember to update the given domain with the one you have picked. (e.g., "subdomain-2.subdomain-1.cloudns.ph".)

SSL/TLS Certificate Check

SSL Shopper is an online tool to validate SSL/TLS certificates. Remember to update the given domain with the one you have picked. (e.g., "subdomain-2.subdomain-1.cloudns.ph".)

HTTP Client Verification

cURL command-line tool can help us quickly confirm accessibility of your web server and review the HTTP protocols available (h2,http/1.1) to reach the public ALB and if the SSL connections work properly for the created domain.

curl -v https://web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph
*   Trying 35.173.227.251:443…
* Connected to web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph (35.173.227.251) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.subdomain-2.subdomain-1.cloudns.ph
* start date: Nov 27 00:00:00 2023 GMT
* expire date: Dec 25 23:59:59 2024 GMT
* subjectAltName: host “web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph” matched cert’s “*.subdomain-2.subdomain-1.cloudns.ph”
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
* SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x7fe9ef812c00)
> GET / HTTP/2
> Host: web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/2 200
< date: Mon, 27 Nov 2023 15:51:13 GMT
< content-type: application/json; charset=utf-8
< content-length: 456
< x-powered-by: Express
< etag: W/”1c8-5fXMveo7D3ZfVWsGIbMvSTgSbVQ”
<
* Connection #0 to host web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph left intact
{“MessageResponse”: “Region: us-east-1. HTTP Response code: 200. Delay response: 0 seconds.”, “SocketRequest”: “::ffff:10.0.2.105:41334”, “HeadersRequest” :{ “x-forwarded-for”: “79.116.196.168”, “x-forwarded-proto”: “https”, “x-forwarded-port”: “443”, “host”: “web-container-us-east-1.subdomain-2.subdomain-1.cloudns.ph”, “x-amzn-trace-id”: “Root=1-6564baf1-477d00c537a7da013a062f76”, “user-agent”: “curl/8.1.2”, “accept”: “*/*”}, “HeadersResponse” :{ “x-powered-by”: “Express”}}

Enhancements and Automation

As we reflect on the deployment process outlined in this blog post, there are opportunities to refine and automate various aspects, contributing to a more seamless and efficient workflow.

1. Modular Deployment with Separate CDK Apps

Consider adopting a modular approach to deployment by separating the foundational infrastructure (VPC, Fargate Cluster, Route53 DNS Public Zone) from the web container-related resources. Create distinct AWS CDK apps (or even different GitHub repositories) for these components, allowing for independent updates and modifications. This modular structure promotes flexibility and better aligns with continuous integration and continuous deployment (CI/CD) practices.

2. Automate DNS Registration with AWS Route 53

Streamline the DNS registration process by utilizing AWS Route 53 as the DNS registrar. Instead of manually configuring NS records with external providers, automate the acquisition and management of DNS names directly within the same Cloud provider. Doing so eliminates the need for manual steps, enhancing the overall automation of the infrastructure setup.

3. CI/CD Integration

Integrate your deployment process with a CI/CD pipeline to automate testing, building, and deploying infrastructure changes. Leverage tools like GitHub Actions or other CI/CD services to ensure a consistent and reliable deployment pipeline. This integration automates the deployment steps and facilitates collaboration and version control.

4. Infrastructure as Code Best Practices

Review and adopt Infrastructure as Code (IaC) best practices to enhance code maintainability and scalability. Consider versioning your IaC code, implementing code reviews, and documenting changes. This ensures that your infrastructure evolves systematically, aligning with industry standards and making it easier for multiple team members to contribute.

Cloud Alternatives

This section offers a quick comparative overview of key AWS services and their counterparts in Azure and Google Cloud Platform (GCP). If you’re considering similar deployments in different cloud providers, this comparison could serve as a starting point for the reader.

	AWS	Azure	GCP
IaC (Infrastructure as Code)	AWS CDK	Pulumi, Terraform CDK	Pulumi, Terraform CDK
Networking	Amazon VPC	Azure Virtual Network	Google Virtual Private Cloud (VPC)
Container Service	ECS with Fargate	Azure Container Instances (ACI)	Google Kubernetes Engine (GKE)
Application Load Balancer	Application Load Balancer (ALB)	Azure Load Balancer	Google Cloud Load Balancing
DNS (Domain Name System)	Amazon Route 53	Azure DNS	Google Cloud DNS
Certificate Manager	AWS Certificate Manager (ACM)	Azure Key Vault	Google Cloud Certificate Manager

Conclusion and What’s Next in Our “Building Resilient Public Networking on AWS” Series

Congratulations! You’ve successfully navigated the intricacies of creating a secure public endpoint on AWS using ACM and Route53, mastering the management of a DNS hosted zone with AWS Route 53 and its seamless integration with third-party DNS hosting providers like ClouDNS.

As you’ve reached this milestone, our journey is far from over. With the ability to deploy a web server in one region, we’re now gearing up for a significant enhancement – deploying across multiple regions. This advancement paves the way for our exploration of solutions for region evacuation.

In the upcoming articles, we’re set to delve into key topics such as regional evacuation, failover, and disaster recovery, leveraging diverse approaches and utilizing various AWS products. Here is a quick spoiler:

We will review region evacuation using DNS approach with AWS Route53.
We will review region evacuation using anycast IP approach with Global Accelerator.

We’ll also review pros and cons of the previous approaches, and we will finish our blog post series explaining why the previous approaches can completely fail if we don’t address one of the most common HTTP client behaviors (TCP persistent connections).

Stay tuned for a deeper dive into building resilient and highly available applications in the cloud.

Additional Resources

AWS CDK Getting Started: This guide introduces essential AWS CDK concepts and outlines the installation and configuration process.
AWS ACM Documentation (ACM) Documentation: Access the official AWS documentation for AWS Certificate Manager to explore features, use cases, and best practices.
AWS Route 53 Documentation: Delve into the intricacies of AWS Route 53 with the official documentation, covering DNS management and domain registration.
ClouDNS Documentation: Refer to the official ClouDNS documentation for detailed insights into their DNS hosting services and configurations.
GitHub Repository for Practical Examples: Explore the GitHub repository used in this blog post series to access practical examples and infrastructure as code (IaC) configurations.