Skip to content

Add an application load balancer to three Amazon EC2 instances belonging to three separate availability zones in a private subnet using Terraform and GitHub Actions.

License

Notifications You must be signed in to change notification settings

kunduso/add-aws-elb-ec2-private-subnet-terraform

Repository files navigation

License: Unlicense GitHub pull-requests closed GitHub pull-requests GitHub issues-closed GitHub issues terraform-infra-provisioning checkov-scan

Introduction

This repository contains code to provision various use cases involving Amazon Elastic Load Balancer, Amazon Route53, Amazon Certificate Manager and Amazon EC2 instances using Terraform and GitHub Actions.

Table of Contents

Use Case 1: Create Application Load Balancer and attach to Amazon EC2 instances in a private subnet

🔔 Attention: The code for this specific use case is located in the ec2-lb branch. Please refer to this branch instead of the default main branch. 🔔 Image The objective of this use case was to create an application load balancer and attach that to three Amazon EC2 instances hosted in three different availability zones in three separate private subnets in a region using Terraform and GitHub Actions.
For details please visit - attach an application load balancer to Amazon EC2 instances in a private subnet.

Use Case 2: Attach AWS WAF to load balancer using Terraform and GitHub Actions

🔔 Attention: The code for this specific use case is located in the add-waf branch. Please refer to this branch instead of the default main branch. 🔔 Image Building on use case 1, this implementation shows how to:

  • Protect the application load balancer with AWS WAF security rules
  • Implement AWS managed rules for common vulnerabilities and exploits
  • Configure rate limiting to prevent DDoS attacks
  • Set up geographic restrictions for access control
  • Enable monitoring and logging of WAF activities through CloudWatch

For details, please visit - attach-aws-waf-to-load-balancer-using-terraform-and-github-actions.

Use Case 3: Automate Amazon Route 53 hosted zone, ACM, and Load Balancer provisioning with Terraform and GitHub Actions

🔔 Attention: The code for this specific use case is located in the add-acm-r53 branch. Please refer to this branch instead of the default main branch. 🔔 Image Building on use case 2, this implementation shows how to:

  • Enable secure HTTPS (port 443) access to the static website
  • Configure a custom domain name with Amazon Route 53
  • Implement SSL/TLS security using AWS Certificate Manager
  • Replace the default load balancer DNS with a custom domain

For details please visit - automate-amazon-route-53-hosted-zone-acm-and-load-balancer-provisioning-with-terraform-and-github-actions.

Use Case 4: Enable Domain Name System (DNS) query logging for Amazon Route 53 hosted zones using Terraform

🔔 Attention: The code for this specific use case is located in the add-dns-query-r53 branch. Please refer to this branch instead of the default main branch. 🔔 Image Building on use case 3, this use case demonstrates how to implement DNS query logging for Route 53 hosted zones to enhance security monitoring and operational visibility. DNS query logging provides detailed information about DNS queries received by Route 53, helping teams detect security threats, troubleshoot issues, and maintain compliance requirements.

The solution includes:

  • Amazon Route 53 query logging configuration
  • Amazon CloudWatch log group with KMS encryption
  • KMS key with appropriate key policy

Regional Consideration

While most AWS resources in this project are provisioned in us-east-2, the CloudWatch log group and KMS key for DNS query logging must be created in us-east-1. This is a mandatory AWS requirement. To handle this, we use a separate AWS provider configuration specifically for these components.

For details please visit - enable-domain-name-system-dns-query-logging-for-amazon-route-53-hosted-zones-using-terraform.

Use Case 5: Configure DNSSEC for Amazon Route 53 hosted zone using Terraform

🔔 Attention: The code for this specific use case is located in the enable-dnssec-route53 branch. Please refer to this branch instead of the default main branch. 🔔 Image This use case demonstrates how to implement Domain Name System Security Extensions (DNSSEC) for Route 53 hosted zones using Terraform. DNSSEC adds an additional layer of security to DNS by cryptographically signing DNS records, protecting against DNS spoofing and cache poisoning attacks.

The solution includes:

  • KMS key configuration for DNSSEC signing
  • Route 53 DNSSEC signing enablement
  • Key Signing Key (KSK) creation
  • DS record management for establishing chain of trust

Regional Consideration

While most AWS resources in this project are provisioned in us-east-2, the KMS key for DNSSEC signing must be created in us-east-1. This is a mandatory AWS requirement for Route 53 DNSSEC implementation. To handle this, we use a separate AWS provider configuration specifically for the KMS components.

For details please visit - configure-dnssec-for-amazon-route-53-hosted-zone-using-terraform.

Prerequisites

For this code to function without errors, please create an OpenID connect identity provider in Amazon Identity and Access Management that has a trust relationship with this GitHub repository. You can read about it here to get a detailed explanation with steps.
Store the ARN of the IAM Role as a GitHub secret which is referred in the terraform.yml file.
Since this use case referred to Infracost in this repository, the INFRACOST_API_KEY was stored as a repository secret. It is referenced in the terraform.yml GitHub actions workflow file.
As part of the Infracost integration, I also created a INFRACOST_API_KEY and stored that as a GitHub Actions secret. I also managed the cost estimate process using a GitHub Actions variable INFRACOST_SCAN_TYPE where the value is either hcl_code or tf_plan, depending on the type of scan desired.

Supporting References

This use cases used Infracost to generate a cost estimate of building the architecture. If you want to learn more about adding Infracost estimates to your repository, head over to this note - estimate AWS Cloud resource cost with Infracost, Terraform, and GitHub Actions.

The resource provisioning process is automated using GitHub Actions pipeline which is discussed at - CI-CD with Terraform and GitHub Actions to deploy to AWS.

Usage

Ensure that the policy/ies attached to the IAM role whose credentials are being used in this repository has permission to create and manage all the resources that are included in this repository and push the Docker image to Amazon ECR repository.

If you want to check the pipeline logs, click on the Build Badges above the image in this ReadMe.

Contributing

If you find any issues or have suggestions for improvement, feel free to open an issue or submit a pull request. Contributions are always welcome!

License

This code is released under the Unlicense License. See LICENSE.

About

Add an application load balancer to three Amazon EC2 instances belonging to three separate availability zones in a private subnet using Terraform and GitHub Actions.

Resources

License

Stars

Watchers

Forks

Packages

No packages published