
## Table of Contents

1. [Introduction](#introduction)
2. [The Setup](#the-setup)
3. [Why 503 Happens — Bad Health Check Path](#why-503-happens--bad-health-check-path)
4. [Why 502 Happens — App Crash and OOM on t2.micro](#why-502-happens--app-crash-and-oom-on-t2micro)
5. [Fix 1 — Dedicated Health Check Endpoint](#fix-1--dedicated-health-check-endpoint)
6. [Fix 2 — Replace Single EC2 with an Auto Scaling Group](#fix-2--replace-single-ec2-with-an-auto-scaling-group)
7. [Fix 3 — Harden the Bootstrap Script](#fix-3--harden-the-bootstrap-script)
8. [Fix 4 — Reduce Per-Request Memory with Static Generation](#fix-4--reduce-per-request-memory-with-static-generation)
9. [Lessons Learned](#lessons-learned)
10. [Conclusion](#conclusion)

---

## Introduction

Running a Node.js web app on a single AWS EC2 instance behind an Application Load Balancer (ALB) is a common and affordable setup. However, it comes with some sharp edges that can cause **502 Bad Gateway** and **503 Service Unavailable** errors — often at the worst possible time: when real traffic is arriving.

This post walks through the exact root causes of both error types in this kind of setup and the changes made to eliminate them. No magic — just a clear explanation of what went wrong and what fixed it.

---

## The Setup

The application is a **Next.js** blog running on a **t2.micro** EC2 instance (1 vCPU, 1 GB RAM) in AWS `us-west-1`. Traffic flows through:

```
User → Route 53 → ALB (HTTPS/HTTP listeners) → Target Group → EC2 (port 80)
```

The EC2 instance was provisioned via Terraform and bootstrapped using a `user_data` shell script that:

- Installed Node.js
- Cloned the repo from GitHub
- Ran `npm install` and `npm run build`
- Started the app with PM2

Sounds simple. But several subtle mistakes caused recurring outages.

---

## Why 503 Happens — Bad Health Check Path

### Root cause

The ALB Target Group health check was configured to hit `/` — the homepage. The homepage used `getServerSideProps` in Next.js, which on every request:

1. Read all markdown files from disk
2. Called Firestore (cloud database) to look up a session
3. Returned the rendered HTML

If the app was **starting up** or **under memory pressure**, this SSR request would take too long or crash entirely. The ALB would mark the instance as **unhealthy** and return `503 Service Unavailable` to all incoming visitors — even if a static asset like `/health.html` would have responded fine.

### Why this is a problem

The ALB health check fires **every 30 seconds**. Each failed check counts toward the unhealthy threshold (typically 3 consecutive failures). With a heavy SSR endpoint as the health target, a brief spike of memory usage is enough to trigger a full outage.

```
ALB → GET / → SSR + Firestore call → timeout → instance marked unhealthy → 503
```

---

## Why 502 Happens — App Crash and OOM on t2.micro

### Root cause

A **502 Bad Gateway** from an ALB means the ALB reached the instance, but the instance returned no valid HTTP response — usually because the application process has crashed or is not listening on the expected port.

On a t2.micro with 1 GB of RAM, a Next.js app with SSR can consume 300–500 MB just at idle. Under daytime traffic spikes:

- Multiple concurrent SSR requests each consume memory
- Node.js default heap limit is around 700 MB on 32-bit-like environments
- The process hits the heap limit, triggers an OOM (Out of Memory) error, and crashes

PM2 is supposed to restart the process — but the original setup had several bugs in the init script that meant PM2 was not configured correctly, leading to longer downtime windows.

Additionally, the init script had a critical bug:

```bash
# WRONG — commands after sudo su run in a subshell and then exit
sudo su
cd /home/ec2-user
# ... rest of commands never run as expected
```

This caused the app to sometimes never start at all, leading to `502` from the very first health check.

---

## Fix 1 — Dedicated Health Check Endpoint

Create a minimal static HTML file at `public/health.html`:

```html
<!DOCTYPE html>
<html>
  <body>
    ok
  </body>
</html>
```

Then update the Terraform Target Group health check to point to it:

```hcl
health_check {
  path                = "/health.html"
  port                = "80"
  healthy_threshold   = 3
  unhealthy_threshold = 3
  interval            = 30
  timeout             = 10
  matcher             = "200"
}
```

**Why this works:** `/health.html` is served directly from disk by Next.js's static file handler. It never touches Node.js SSR logic, Firestore, or any database. It is always fast and always available as long as the process is running.

---

## Fix 2 — Replace Single EC2 with an Auto Scaling Group

A single EC2 instance with no self-healing means any crash = manual recovery. The fix is to use an **Auto Scaling Group (ASG)** with `desired=1`:

```hcl
resource "aws_autoscaling_group" "myAsg" {
  desired_capacity          = 1
  min_size                  = 1
  max_size                  = 2
  health_check_type         = "ELB"
  health_check_grace_period = 720

  launch_template {
    id      = aws_launch_template.myLaunchTemplate.id
    version = "$Latest"
  }
}
```

Key settings:

- **`health_check_type = "ELB"`** — ASG uses ALB health checks (not just EC2 ping). If the app stops responding, ASG terminates and replaces the instance automatically.
- **`health_check_grace_period = 720`** — give the bootstrap script 12 minutes to complete `npm install` + `next build` before the first health check fires. On a t2.micro this takes 8–10 minutes.
- **`version = "$Latest"`** — always boot from the newest launch template version, so deployments just require replacing the template and terminating the old instance.

Also ensure the launch template network interface has a public IP so the instance can reach GitHub and npm registries during bootstrap:

```hcl
network_interfaces {
  associate_public_ip_address = true
  security_groups             = [aws_security_group.mySecurityGroup.id]
}
```

---

## Fix 3 — Harden the Bootstrap Script

The original `user_data` script had several problems. Here is what was wrong and what replaced it:

### Problem: `sudo su` breaks subsequent commands

```bash
# WRONG
sudo su
cd /app
npm install   # this runs in a subshell, then exits
```

EC2 `user_data` scripts already run as root. Remove `sudo su` entirely.

### Problem: PM2 flags passed to the wrong process

```bash
# WRONG — --max-restarts and --restart-delay go to Next.js, not PM2
pm2 start npm --name "myApp" -- run "start" --max-restarts 10 --restart-delay 5000

# CORRECT — PM2 flags must come before --
pm2 start npm --name "myApp" --max-restarts 10 --restart-delay 5000 -- run "start"
```

### Problem: No PM2 startup persistence

If the instance reboots, PM2 processes are lost. Fix:

```bash
pm2 startup systemd -u root --hp /root
pm2 save
```

### Problem: Node.js heap unbounded

```bash
export NODE_OPTIONS="--max-old-space-size=512"
```

Cap the heap at 512 MB so Node.js throws a controlled OOM error and PM2 can restart it, rather than the OS killing the process unpredictably.

### Final bootstrap script (simplified)

```bash
#!/bin/bash
set -euo pipefail

# Install Node 18.x
curl -fsSL https://rpm.nodesource.com/setup_18.x | bash -
yum install -y nodejs git

# Install PM2
npm install -g pm2

# Clone and build
cd /home/ec2-user
git clone https://YOUR_TOKEN@github.com/YOUR_ORG/YOUR_REPO.git app
cd app
npm install
npm run build

# Start with memory cap
export NODE_OPTIONS="--max-old-space-size=512"
pm2 start npm --name "myApp" --max-restarts 10 --restart-delay 5000 -- run "start"

# Persist across reboots
pm2 startup systemd -u root --hp /root
pm2 save
```

---

## Fix 4 — Reduce Per-Request Memory with Static Generation

The most impactful application-level change was converting the highest-traffic pages from **Server-Side Rendering (SSR)** to **Static Site Generation (SSG)** with Incremental Static Regeneration (ISR).

### Before (SSR)

```ts
// Every single visitor triggers this — Firestore calls, markdown parsing, SSR
export async function getServerSideProps({ req, res }) {
  const posts = DataService.getPostByPaging(1);
  const sessionKey = await CookieHelper.GetSessionKey(req, res);
  const result = await GetSession(sessionKey); // Firestore call
  const user = result?.user ?? null;
  return { props: { posts, user, sessionKey } };
}
```

### After (ISR)

```ts
// Built once at deploy time, re-rendered in background every 5 minutes max
export async function getStaticProps() {
  const posts = DataService.getPostByPaging(1);
  return {
    props: { posts, sessionKey: '', user: null },
    revalidate: 300,
  };
}
```

**Result:** The homepage goes from "SSR + 2× Firestore calls per visitor" to "serve pre-built HTML from disk". On a t2.micro this is the difference between 200–400 MB of memory churn per traffic spike and near-zero.

For blog post detail pages, the same approach works with `getStaticPaths`:

```ts
export async function getStaticPaths() {
  const posts = DataService.getBlogPosts();
  return {
    paths: posts.map((p) => ({ params: { id: p.id } })),
    fallback: 'blocking', // new posts render on first hit, then cached
  };
}
```

`fallback: 'blocking'` means posts published after the last deploy are still accessible — the first visitor triggers a one-time build, and everyone after gets the cached static version.

---

## Lessons Learned

| Mistake                             | Impact                         | Fix                                  |
| ----------------------------------- | ------------------------------ | ------------------------------------ |
| Health check hitting SSR endpoint   | 503 on memory spikes           | Use static `/health.html`            |
| Single EC2 with no ASG              | Manual recovery after crash    | ASG with `health_check_type = "ELB"` |
| `sudo su` in user_data              | App never started              | Remove it — user_data runs as root   |
| PM2 flags after `--`                | Flags ignored by PM2           | Move flags before `--`               |
| No PM2 startup/save                 | App lost on reboot             | `pm2 startup && pm2 save`            |
| No Node.js heap cap                 | Uncontrolled OOM crash         | `--max-old-space-size=512`           |
| SSR with Firestore on every request | Memory pressure, latency       | `getStaticProps` + ISR               |
| No public IP on launch template     | Bootstrap failed silently      | `associate_public_ip_address = true` |
| Grace period too short (300s)       | ASG killed instances mid-build | Increased to 720s                    |

---

## Conclusion

502 and 503 errors on AWS ALB + EC2 setups are almost always one of three things:

1. **The health check target is too expensive** — use a static file
2. **The app process crashed and nothing restarted it** — use ASG with ELB health checks
3. **The bootstrap script has a subtle bug** — test it thoroughly; run it manually once before automating

The combination of a static health check endpoint, an ASG for self-healing, a correct bootstrap script, and converting hot pages to ISR eliminated recurring outages and significantly reduced memory pressure on the instance.

The changes described here apply to any Node.js application hosted on EC2 behind an ALB — not just Next.js blogs.


A deep-dive into why 502 and 503 errors appear on a Node.js app hosted on AWS EC2 behind an ALB, what causes them, and how to fix them properly with an Auto Scaling Group and a robust bootstrap script.

How to Fix 502 and 503 Gateway Errors on AWS EC2 with an Application Load Balancer


## Table of Contents

1. [Introduction](#introduction)
2. [Switch to the Correct Workspace Environment](#switch-to-the-correct-workspace-environment)
3. [Pull Latest State File](#pull-latest-state-file)
4. [Test by Running Terraform Plan](#test-by-running-terraform-plan)
5. [Run Import to Update State File](#run-import-to-update-state-file)
6. [Conclusion](#conclusion)

## Introduction

When working with Terraform and existing cloud resources, you may need to import those resources into your Terraform state file. This blog shows how to do that.

## Switch to the Correct Workspace Environment

For example, you can run the following command to create a QA workspace environment:

```
terraform workspace new qa
or
terraform workspace select qa
```

## Pull Latest State File

Run this command to get the latest state file for the environment from storage:

```
terraform state pull
```

This is what you get when you run `terraform state pull` — basically nothing is saved to the current workspace state:

```
{
  "version": 4,
  "terraform_version": "1.4.6",
  "serial": 1,
  "lineage": "59eb4435-e702-29bf-71de-1231231",
  "outputs": {},
  "resources": [],
  "check_results": null
}

```

## Test by Running Terraform Plan

If at this point you run `terraform plan`, you'll see some changes if you have active resources in your local files. This is incorrect if the same resource already exists in GCP, and you don't want to run `terraform apply`, which would end up creating duplicate resources or throwing errors.

## Run Import to Update State File

For instance, if you have an existing GCP BigQuery schedule query, you can run the following command to sync the state file:

```
terraform import google_bigquery_data_transfer_config.job projects/1233/locations/us/transferConfigs/12312312
```

The above command should update the state file, and if you run `terraform plan` again, you should not see any changes.

## Conclusion

Importing existing resources into your Terraform state file ensures that Terraform is aware of your current infrastructure. This prevents duplicate resource creation and keeps your state file in sync with your actual cloud resources.


This blog shows how to run Terraform to create a state file from existing resources.

How to Create Terraform State File for Current Resources


## Table of Contents

1. [About Terraform with GCP](#about-terraform-with-gcp)
2. [Preparation](#preparation)
3. [Create Terraform Files](#create-terraform-files)
4. [Start Deployment](#start-deployment)
5. [Conclusion](#conclusion)

## About Terraform with GCP

Terraform provides infrastructure automation to provision resources to many cloud providers. GCP is one of them. This article shows how to use Terraform to deploy a simple BigQuery Schedule Job to GCP.

## Preparation

Before getting started, ensure you have Terraform installed and a GCP account with the necessary permissions.

## Create Terraform Files

### Create `provider.tf` File

Start with the Terraform provider, Google credentials, and the GCP project.

```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "5.15.0"
    }
  }
}

provider "google" {
  credentials = file("{this is option but your can create GCP service account with BigQuery.job.create role}")
  project = "{your gcp project id}"
}
```

### Create Service Account

For the above credentials, below are a few steps to create a service account with the minimal role to perform the GCP operation.

- Go to the GCP Roles page and create a new custom role with `bigquery.job.create` permission.
- Go to the IAM Service Account page, create a new service account, and then assign the custom role you created.
- Once the service account is created, go to the KEYS tab and click `ADD KEY` to create a new JSON key. Save it locally so the above credentials can reference it.

### Create `backend.tf` File

Here, we're using a GCP Cloud Storage bucket to store the Terraform state file. This is similar to sharing the code within the team so that the same infrastructure is deployed no matter who runs it.

```
terraform {
 backend "gcs" {
   bucket  = "{create a GCP cloud bucket}"
   prefix = "test"
 }
}
```

### Create `schedule-job.tf`

Finally, here is the main code. We're writing a simple query and deploying it to a GCP BigQuery Schedule Job that runs every Sunday.

```
resource "google_bigquery_data_transfer_config" "job" {
    display_name = "test-query"
    project = "{your gcp project}"
    location = "us"
    data_source_id = "scheduled_query"
    schedule = "first sunday of quarter 00:00"
    params = {
      query = "select 1 as ID;"
    }
}
```

## Start Deployment

First, go to the folder containing the above Terraform files and run this command to initialize Terraform and download state files from the GCP Cloud Storage bucket:

```
terraform init
```

This command will create a new workspace called `test`. If it does not exist, the state will be saved to the cloud bucket:

```
terraform workspace new test
```

Run the plan command to check what resources will be created in GCP:

```
terraform plan
```

If you have confirmed the resources, run this command to deploy the changes to GCP:

```
terraform apply
```

## Conclusion

Using Terraform is a great way to deploy infrastructure resources to GCP for production environments. It provides reproducible, version-controlled infrastructure management.


This article demonstrates how to use Terraform to deploy a GCP Schedule Job.

How to Create GCP Schedule Job with Terraform


## Table of Contents

1. [Introduction](#introduction)
2. [Sample Terraform Code](#sample-terraform-code)
3. [Run the Sample Terraform](#run-the-sample-terraform)
4. [Use Variables](#use-variables)
5. [Different Values for Each Environment](#different-values-for-each-environment)
6. [Conclusion](#conclusion)

## Introduction

This blog shows how to use Terraform variables to move environment-specific values out of the code, so you can run the same Terraform configuration for different environments and inject the appropriate variables for each one.

## Sample Terraform Code

This blog uses the following Terraform code to get started.

**_provider.tf_**

```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "5.15.0"
    }
  }
}

provider "google" {
  # Configuration options
  credentials = file("your google credential file path")
  project = "{gcp project id}"
}
```

**_backend.tf_**

```
terraform {
 backend "gcs" {
   bucket  = "{gcp bucket for terraform}"
   prefix = "test"
 }
}
```

**_schedule-job.tf_**

```
resource "google_bigquery_data_transfer_config" "job" {
    display_name = "my_test_sj"
    project = "{your project id}"
    location = "us"
    data_source_id = "scheduled_query"
    schedule = "first sunday of quarter 00:00"
    params = {
      query = "call spTest();"
    }
}
```

## Run the Sample Terraform

Running the above sample Terraform should create a scheduled job.

## Use Variables

Now, let's say we want to move the **_display_name_** to a variable, because we want to reuse the same name later.

Let's create a new **_variable.tf_**. If you run `terraform plan`, you can see the display name as **_my_test_sj_**.

### Variable with Default

```
variable "bq_name" {
  type = string
  nullable = false
  default = "my_test_sj"
}
```

### Without Default Variable

Let's say we want to enter the name every time we run Terraform. We can remove the default so that every time we run **_terraform plan_**, it will ask for input for the variable. The example here might not be ideal, but there may be some areas where this approach is useful.

```
variable "bq_name" {
  type = string
  nullable = false
}
```

## Different Values for Each Environment

Assume we have 2 different workspaces: **_dev_** and **_qa_**.

For this case, we define the variables as below.

### variable.tf

```
variable "bq_name" {
  type = string
  nullable = false
}
```

### dev.tfvars

Create a **_dev.tfvars_** file and add the following key-value pairs.

```
name = "dev_job"
```

### qa.tfvars

Create a **_qa.tfvars_** file and add the following key-value pairs.

```
name = "qa_job"
```

At this point, nothing needs to be modified in the schedule job Terraform file. We'll run **_terraform plan_** with the option **_--var-file=dev.tfvars_**. This will run Terraform with the key/value environment variables defined in **_dev.tfvars_**.

```
terraform plan --var-file=dev.tfvars
```

## Conclusion

Using Terraform **_workspaces_** with **_var-file_** allows you to write Terraform configurations for different environments, keeping environment-specific values separate from your infrastructure code.


This blog shows how to use Terraform variables to move environment variables out of the code, so you can run Terraform for different environments and inject the variables for each one.

How to Run Terraform with Input Variables


## Table of Contents

1. [Introduction](#introduction)
2. [Prerequisites](#prerequisites)
3. [Configure AWS](#configure-aws)
4. [Architecture Overview](#architecture-overview)
5. [Project Structure](#project-structure)
6. [VPC and Networking](#vpc-and-networking)
7. [Security Group](#security-group)
8. [Application Load Balancer](#application-load-balancer)
9. [HTTPS Certificate and Route 53](#https-certificate-and-route-53)
10. [EC2 Instance with Bootstrap Script](#ec2-instance-with-bootstrap-script)
11. [Variables](#variables)
12. [Terraform Commands](#terraform-commands)
13. [Estimated Monthly Cost](#estimated-monthly-cost)
14. [Conclusion](#conclusion)

## Introduction

This blog walks through a production-ready AWS setup for hosting a Next.js blog using Terraform. The infrastructure includes a VPC, Application Load Balancer (ALB), HTTPS via ACM, Route 53 DNS, and an EC2 instance bootstrapped with Node.js and PM2 — all managed as code.

## Prerequisites

- Terraform CLI (>= 1.2.0)
- AWS CLI configured with credentials
- AWS Account with an IAM user
- A registered domain name pointed to Route 53
- VS Code extension: HashiCorp Terraform (for IntelliSense)

## Configure AWS

### Install and verify AWS CLI

```bash
aws --version
```

Reference: [AWS CLI installation guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

### Set up AWS credentials

Create an IAM user with the following permissions:
- `AmazonEC2FullAccess`
- `AmazonVPCFullAccess`
- `ElasticLoadBalancingFullAccess`
- `AmazonRoute53FullAccess`
- `AWSCertificateManagerFullAccess`
- `AmazonS3FullAccess`

Then configure your credentials locally — **never hardcode them in Terraform files**:

```bash
aws configure
```

Terraform reads credentials from `~/.aws/credentials` or environment variables:

```bash
export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"
```

## Architecture Overview

```
Internet
   │
   ▼
Route 53 (DNS — technoapple.com → ALB)
   │
   ▼
Application Load Balancer (HTTP:80 → redirect, HTTPS:443 → forward)
   │         └── ACM Certificate (HTTPS)
   ▼
EC2 t3.micro (Next.js app via PM2, port 80)
   │
   └── VPC → Subnet (us-west-1) → Internet Gateway
```

The EC2 instance runs the Next.js app directly on port 80 via PM2. The ALB handles HTTPS termination and forwards traffic to the instance.

## Project Structure

Split the Terraform code into two modules:

```
setup-vpc-network/     ← VPC, subnets, IGW, ALB, security group, Route 53, ACM cert
setup-ec2/             ← EC2 instance, key pair, bootstrap script
```

This separation lets you reprovision the EC2 (e.g. for a new year's environment) without touching the network/DNS layer.

## VPC and Networking

```hcl
# vpc.tf

resource "aws_vpc" "VPC" {
  cidr_block           = var.aws_ip_cidr_range
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "myVPC" }
}

resource "aws_internet_gateway" "IGW" {
  vpc_id = aws_vpc.VPC.id
  tags   = { Name = "myInternetGateway" }
}

resource "aws_subnet" "mySubnet" {
  cidr_block        = "10.0.0.0/28"
  vpc_id            = aws_vpc.VPC.id
  availability_zone = var.availability_zones["zone1"]
  tags              = { Name = "mySubnet" }
}

resource "aws_subnet" "mySubnet2" {
  cidr_block        = "10.0.0.16/28"
  vpc_id            = aws_vpc.VPC.id
  availability_zone = var.availability_zones["zone2"]
  tags              = { Name = "mySubnet2" }
}

resource "aws_route_table" "myRouteTable" {
  vpc_id = aws_vpc.VPC.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.IGW.id
  }
  tags = { Name = "myTable" }
}

resource "aws_route_table_association" "routeTableAssociate" {
  subnet_id      = aws_subnet.mySubnet.id
  route_table_id = aws_route_table.myRouteTable.id
}

resource "aws_route_table_association" "routeTableAssociate2" {
  subnet_id      = aws_subnet.mySubnet2.id
  route_table_id = aws_route_table.myRouteTable.id
}
```

Two subnets across two availability zones are required by the ALB.

## Security Group

```hcl
# security_group.tf

resource "aws_security_group" "mySecurityGroup" {
  name        = "mySecurity"
  description = "Security group for web app"
  vpc_id      = aws_vpc.VPC.id

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = { Name = "myWebAppSecurity" }
}
```

> **Tip:** In production, restrict the SSH `cidr_blocks` to your office IP instead of `0.0.0.0/0`.

## Application Load Balancer

```hcl
# elb.tf

resource "aws_lb" "myLb" {
  name               = "myLoadBalancer"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.mySecurityGroup.id]
  subnets            = [aws_subnet.mySubnet.id, aws_subnet.mySubnet2.id]
  tags               = { Environment = "prod" }
}

resource "aws_lb_target_group" "myTargetGroup" {
  name        = "my-target-group"
  port        = 80
  protocol    = "HTTP"
  target_type = "instance"
  vpc_id      = aws_vpc.VPC.id

  health_check {
    protocol            = "HTTP"
    path                = "/health.html"
    port                = "80"
    healthy_threshold   = 5
    interval            = 30
    unhealthy_threshold = 2
    timeout             = 5
  }
}

# Redirect HTTP → HTTPS
resource "aws_lb_listener" "lbListenerHttp" {
  load_balancer_arn = aws_lb.myLb.arn
  port              = "80"
  protocol          = "HTTP"
  default_action {
    type = "redirect"
    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }
}

# HTTPS listener
resource "aws_lb_listener" "lbListenerHttps" {
  load_balancer_arn = aws_lb.myLb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = aws_acm_certificate_validation.myCertificateValidation.certificate_arn
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.myTargetGroup.arn
  }
}
```

## HTTPS Certificate and Route 53

```hcl
# certificate.tf

resource "aws_acm_certificate" "myCertificate" {
  domain_name       = var.domainName
  validation_method = "DNS"
  tags              = { Environment = "Production" }
  lifecycle { create_before_destroy = true }
}

resource "aws_route53_zone" "primary" {
  name = var.domainName
}

# DNS validation records for ACM
resource "aws_route53_record" "my53Record" {
  for_each = {
    for dvo in aws_acm_certificate.myCertificate.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }
  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = aws_route53_zone.primary.zone_id
}

# Point domain apex to ALB
resource "aws_route53_record" "myALBRecord" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = var.domainName
  type    = "A"
  alias {
    name                   = aws_lb.myLb.dns_name
    zone_id                = aws_lb.myLb.zone_id
    evaluate_target_health = true
  }
}

# Point www to ALB
resource "aws_route53_record" "myALBRecordWWW" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = var.domainNameWWW
  type    = "A"
  alias {
    name                   = aws_lb.myLb.dns_name
    zone_id                = aws_lb.myLb.zone_id
    evaluate_target_health = true
  }
}

resource "aws_acm_certificate_validation" "myCertificateValidation" {
  certificate_arn         = aws_acm_certificate.myCertificate.arn
  validation_record_fqdns = [for record in aws_route53_record.my53Record : record.fqdn]
}
```

> **Important:** After Terraform creates the Route 53 hosted zone, copy the NS records and update your domain registrar (e.g. GoDaddy) to point to Route 53 nameservers. ACM certificate validation will not complete until DNS is delegated.

## EC2 Instance with Bootstrap Script

```hcl
# ec2.tf

resource "tls_private_key" "privatekey" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

resource "aws_key_pair" "myKeyPair" {
  key_name   = "ec2key"
  public_key = tls_private_key.privatekey.public_key_openssh
}

resource "local_file" "privatekey" {
  content         = tls_private_key.privatekey.private_key_pem
  filename        = "${path.module}/ec2key.pem"
  file_permission = "0600"
}

resource "aws_instance" "myInstance" {
  ami                         = "ami-051ed863837a0b1b6"  # Amazon Linux 2 us-west-1
  instance_type               = "t3.micro"
  key_name                    = aws_key_pair.myKeyPair.key_name
  subnet_id                   = data.aws_subnet.mySubnet.id
  vpc_security_group_ids      = [data.aws_security_group.mySecurity.id]
  associate_public_ip_address = true
  user_data                   = base64encode(data.template_file.ec2.rendered)

  root_block_device {
    volume_size = 8
    volume_type = "gp3"
  }

  tags = { Name = "myWebApp" }

  lifecycle { create_before_destroy = true }
}

resource "aws_lb_target_group_attachment" "myTargetGroupAttachment" {
  target_id        = aws_instance.myInstance.id
  target_group_arn = data.aws_lb_target_group.myTargetGroup.arn
  port             = 80
}

resource "aws_eip" "myEip" {
  instance = aws_instance.myInstance.id
  tags     = { Name = "myWebAppEIP" }
}
```

The bootstrap `user_data` script installs Node.js 18, PM2, clones the repo, builds, and starts the app:

```bash
#!/usr/bin/env bash
set -euo pipefail
exec > >(tee /var/log/user-data.log | logger -t user-data -s 2>/dev/console) 2>&1

curl -fsSL https://rpm.nodesource.com/setup_18.x | bash -
yum -y install nodejs git

npm i -g pm2

mkdir -p /app && cd /app
git clone https://github.com/YOUR_ORG/YOUR_REPO.git
cd YOUR_REPO

npm install
npm run build

export NODE_OPTIONS="--max-old-space-size=512"
pm2 start npm --name "myApp" --max-restarts 10 --restart-delay 5000 -- run start
pm2 startup systemd -u root --hp /root
pm2 save
```

> **Security note:** Never hardcode GitHub credentials in the bootstrap script. Use a [GitHub deploy key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys) or a fine-grained PAT stored as a Terraform variable instead.

## Variables

```hcl
# variables.tf

variable "aws_ip_cidr_range" {
  default     = "10.0.0.0/24"
  type        = string
  description = "IP CIDR range for the VPC"
}

variable "availability_zones" {
  type = map(string)
  default = {
    zone1 = "us-west-1c"
    zone2 = "us-west-1b"
  }
}

variable "domainName" {
  type    = string
  default = "yourdomain.com"
}

variable "domainNameWWW" {
  type    = string
  default = "www.yourdomain.com"
}
```

## Terraform Commands

```bash
# Initialise providers and modules
terraform init

# Preview changes without applying
terraform plan

# Apply infrastructure
terraform apply

# Destroy all resources
terraform destroy

# Inspect current state
terraform show
terraform state list

# Use workspaces to manage multiple environments
terraform workspace new prd-2025
terraform workspace select prd-2025
```

## Estimated Monthly Cost

All prices are approximate for **us-west-1** as of 2024.

| Resource | Spec | Est. monthly cost |
|---|---|---|
| EC2 t3.micro | 1 instance, 730 hrs | ~$8 |
| EBS gp3 | 8 GB | ~$0.64 |
| Elastic IP | Associated to running instance | Free |
| ALB | ~1 LCU, low traffic | ~$16–18 |
| Route 53 hosted zone | 1 zone | $0.50 |
| Route 53 queries | ~1M queries/month | ~$0.40 |
| ACM certificate | Public cert | Free |
| Data transfer out | ~1 GB/month | ~$0.09 |
| **Total** | | **~$26–28/month** |

> The ALB is the biggest cost driver at ~$16/month minimum. For a personal blog on a budget, you can skip the ALB and use nginx + certbot directly on the EC2 to terminate HTTPS — this brings the total down to ~$10/month.

## Conclusion

With this setup you get a production-ready, HTTPS-enabled blog hosting environment that is fully reproducible as code. The split between `setup-vpc-network` and `setup-ec2` lets you tear down and reprovision just the compute layer each year without touching DNS or certificates. Run `terraform workspace new prd-YYYY` and `terraform apply` to spin up a fresh environment in minutes.


This blog demonstrates how to set up a production-ready AWS infrastructure with EC2, ALB, Route 53, and HTTPS using Terraform.

How to Create AWS EC2 by Terraform


## Table of Contents

1. [Introduction](#introduction)
2. [Download Binary from HashiCorp](#download-binary-from-hashicorp)
3. [Install the HashiCorp Binary at macOS](#install-the-hashicorp-binary-at-macos)
4. [Conclusion](#conclusion)

## Introduction

The goal here is to be able to run the below command in your local terminal.

```
terraform -help
```

## Download Binary from HashiCorp

After downloading the binary for macOS (for instance, after the download you should see **_terraform_1.4.6_darwin_amd64_**), once you unzip the binary you should see the terraform binary file.

## Install the HashiCorp Binary at macOS

If you're getting an error like **_"terraform" cannot be opened because the developer cannot be verified_**, you can try the below setting to avoid this error:

- System Preferences
- Security & Privacy
- Choose General

Once the terraform binary file is allowed on your local machine, run the below code in the terminal to include the **_terraform_** file in the path.

Type this to check the current **_PATH_**:

```
echo $PATH
```

Type this to move the terraform file to the user's PATH folder:

```
mv ~/Downloads/terraform /usr/local/bin/
```

Now, if you type the below command and it works, you should see a list of help commands.

```
terraform -help
```

## Conclusion

Installing Terraform on macOS is straightforward — download the binary from HashiCorp, allow it in your security settings, and move it to a directory in your PATH. You can then verify the installation by running `terraform -help`.

A quick guide on how to download and install the Terraform binary on macOS.

Terraform

How to Fix 502 and 503 Gateway Errors on AWS EC2 with an Application Load Balancer

How to Create Terraform State File for Current Resources

How to Create GCP Schedule Job with Terraform

How to Run Terraform with Input Variables

How to Create AWS EC2 by Terraform

Install Terraform at macOS

Subscribe for Updates