Forem: Shreyas Yadav

I Built a Nightly Pipeline That Deploys My App While I Sleep

Shreyas Yadav — Mon, 09 Mar 2026 04:07:07 +0000

Stack: Next.js 14 · Express.js · MySQL 8 · Docker · GitHub Actions · AWS EC2 · AWS ECR · AWS RDS · Route 53 · Nginx · Let's Encrypt

I built a Job Application Tracker, a full-stack SPA with GitHub OAuth login, and set up an automated nightly pipeline that builds Docker images, runs smoke tests on a temporary EC2, pushes verified images to ECR, and deploys to a persistent QA server, all without manual intervention. Here's exactly how I did it.

Architecture Overview
The Application: Job Application Tracker
Dockerizing the App
Local Development with Docker Compose
AWS Infrastructure Setup
GitHub Actions CI/CD Pipeline
Domain Name with Route 53 and SSL with Let's Encrypt
Nginx as a Reverse Proxy
Security Best Practices
Lessons Learned

1. Architecture Overview

The project is split into two repositories, a separation of concerns that keeps application code and infrastructure code independent:

Repo	Purpose
`job-application-tracker`	Application source code (frontend, backend, Dockerfiles, local docker-compose)
`job-application-tracker-infra`	Infrastructure: GitHub Actions workflows, Nginx config, smoke tests, prod docker-compose

High-Level Architecture

Developer pushes to source repo
         │
         ▼
  GitHub Actions (infra repo)
  Nightly at 2 AM UTC
         │
  ┌──────▼──────┐
  │  1. BUILD   │  Build Docker images with timestamp tag
  │             │  Push to AWS ECR
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │  2. SMOKE   │  Launch temporary EC2 (t3.micro)
  │    TEST     │  Run containers, execute curl tests
  │             │  Terminate EC2 (pass or fail)
  └──────┬──────┘
         │ (only if tests pass)
  ┌──────▼──────┐
  │  3. PROMOTE │  Retag timestamp → :latest in ECR
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │  4. DEPLOY  │  SSH-less deploy via AWS SSM
  │    TO QA    │  Pull :latest from ECR
  │             │  docker compose up on persistent EC2
  └─────────────┘
         │
  ┌──────▼──────┐
  │  QA EC2     │  Nginx (SSL/HTTPS)
  │  shri.      │  Frontend :3000 → /
  │  software   │  Backend  :5000 → /api/
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │  AWS RDS    │  MySQL 8 (persistent, managed)
  └─────────────┘

2. The Application: Job Application Tracker

The finished app running at shri.software with HTTPS enforced

The app lets users track their job applications (Applied → Interview → Offer / Rejected). Authentication is handled via GitHub OAuth using NextAuth.js, no username/password to manage.

Tech Stack

Frontend: Next.js 14.2 with React 18, Tailwind CSS, NextAuth.js
Backend: Express.js 4.18, JWT middleware
Database: MySQL 8 (local via Docker, production via AWS RDS)

Database Schema

-- Users created on first GitHub login
CREATE TABLE users (
  id                  INT AUTO_INCREMENT PRIMARY KEY,
  email               VARCHAR(255) UNIQUE NOT NULL,
  name                VARCHAR(255),
  avatar_url          TEXT,
  provider            VARCHAR(50),
  provider_account_id VARCHAR(255),
  UNIQUE KEY (provider, provider_account_id),
  created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

-- Each row belongs to one user (CASCADE delete keeps DB clean)
CREATE TABLE job_applications (
  id           INT AUTO_INCREMENT PRIMARY KEY,
  company      VARCHAR(255) NOT NULL,
  role         VARCHAR(255) NOT NULL,
  status       ENUM('applied','interview','offer','rejected') DEFAULT 'applied',
  date_applied DATE,
  user_id      INT NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
  created_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Dashboard view, filter by status, edit or delete entries inline

Backend API

Method	Route	Auth	Description
GET	`/health`	None	Health check for monitoring
POST	`/api/users/upsert`	None	Called by NextAuth on login
GET	`/api/applications`	JWT	List user's applications
POST	`/api/applications`	JWT	Create application
PUT	`/api/applications/:id`	JWT	Update application
DELETE	`/api/applications/:id`	JWT	Delete application

Authentication Flow

NextAuth.js handles the GitHub OAuth dance. The key insight: after OAuth completes, we generate a JWT signed with NEXTAUTH_SECRET that the frontend sends to the backend on every API call.

// frontend/src/app/api/auth/[...nextauth]/route.js (simplified)
export const authOptions = {
  providers: [GitHubProvider({ clientId, clientSecret })],
  callbacks: {
    async signIn({ user, account }) {
      // Store GitHub identity in our DB on first login
      await fetch(`${process.env.NEXT_PUBLIC_API_URL}/api/users/upsert`, {
        method: 'POST',
        body: JSON.stringify({
          email: user.email,
          name: user.name,
          provider: account.provider,
          provider_account_id: account.providerAccountId,
        }),
      });
      return true;
    },
    async session({ session, token }) {
      // Mint a JWT for API calls; embed it in the session
      session.backendToken = jwt.sign(
        { userId: token.userId, email: token.email },
        process.env.NEXTAUTH_SECRET,
        { expiresIn: '1h' }
      );
      return session;
    },
  },
};

The backend verifies this token on every protected route:

// backend/src/middleware/auth.js
const auth = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });
  const decoded = jwt.verify(token, process.env.NEXTAUTH_SECRET);
  req.user = decoded; // { userId, email }
  next();
};

3. Dockerizing the App

Backend Dockerfile

FROM node:20-alpine

# Non-root user for security
RUN addgroup -S shri && adduser -S shri -G shri

WORKDIR /app
COPY package.json .
RUN npm install --production
COPY src/ ./src/

RUN chown -R shri:shri /app
USER shri

EXPOSE 5000
CMD ["node", "src/index.js"]

Key decisions:

Alpine base, minimal attack surface, smaller image (~50 MB vs ~900 MB for node:20)
Non-root user, if the container is compromised, the attacker can't escalate to root on the host
--production install, excludes dev dependencies from the final image

Frontend Dockerfile (Multi-Stage Build)

# --- Stage 1: Build ---
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# --- Stage 2: Runtime ---
FROM node:20-alpine
RUN addgroup -S shri && adduser -S shri -G shri
WORKDIR /app

# Copy only the artifacts needed to run
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

RUN chown -R shri:shri /app
USER shri

EXPOSE 3000
CMD ["node_modules/.bin/next", "start"]

Multi-stage builds are critical for Next.js, the build stage pulls in all dev dependencies and compiles TypeScript/JSX. The final stage only contains the compiled output, shrinking the image dramatically.

4. Local Development with Docker Compose

The app running locally via Docker Compose at localhost:9000

The source repo's docker-compose.yml wires everything together for local development with a single command:

# docker-compose.yml
services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 5

  backend:
    build: ./backend
    ports:
      - "10000:5000"
    environment:
      DB_HOST: db
      DB_NAME: ${MYSQL_DATABASE}
      DB_USER: ${MYSQL_USER}
      DB_PASSWORD: ${MYSQL_PASSWORD}
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
    depends_on:
      db:
        condition: service_healthy  # Wait for MySQL, not just the container

  frontend:
    build: ./frontend
    ports:
      - "9000:3000"
    environment:
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      NEXTAUTH_URL: http://localhost:9000
      GITHUB_CLIENT_ID: ${GITHUB_CLIENT_ID}
      GITHUB_CLIENT_SECRET: ${GITHUB_CLIENT_SECRET}
      NEXT_PUBLIC_API_URL: http://localhost:10000
    depends_on:
      - backend

volumes:
  db_data:

To get started locally:

# 1. Clone the source repo
git clone https://github.com/Shreyas-Yadav/job-application-tracker
cd job-application-tracker

# 2. Copy and fill in the env file
cp .env.example .env
# Edit .env with your GitHub OAuth credentials and secrets

# 3. Launch everything
docker compose up

# App available at:
# Frontend: http://localhost:9000
# Backend:  http://localhost:10000

All three containers (db, backend, frontend) starting up successfully

The depends_on with condition: service_healthy is important, the backend waits for MySQL to be truly ready (not just the container running) before starting.

5. AWS Infrastructure Setup

5.1 GitHub OAuth App

Go to GitHub → Settings → Developer Settings → OAuth Apps → New OAuth App:

Homepage URL: https://shri.software
Authorization callback URL: https://shri.software/api/auth/callback/github

Save the Client ID and Client Secret, these go into GitHub Actions secrets.

5.2 AWS ECR (Elastic Container Registry)

Create two private repositories to store Docker images:

Both ECR repositories created and ready to receive images from the CI pipeline

aws ecr create-repository --repository-name job-tracker-backend --region us-east-1
aws ecr create-repository --repository-name job-tracker-frontend --region us-east-1

5.3 AWS RDS (MySQL 8)

Create a MySQL 8 RDS instance in the AWS Console:

Engine: MySQL 8.0
Instance class: db.t3.micro (Free Tier eligible)
Storage: 20 GB gp2
Important: Place in the same VPC as your EC2 instances
Set a master username and password
Create a database: jobtracker
Note the endpoint, it looks like job-tracker-db.xxx.us-east-1.rds.amazonaws.com

RDS MySQL 8 instance showing "Available" status with the endpoint used by the backend

Why RDS instead of a containerized DB? Managed backups, automated patching, and persistence across EC2 restarts without dealing with EBS volumes.

5.4 QA EC2 Instance

Launch a persistent EC2 instance (Ubuntu 22.04, t3.micro):

# After SSH-ing in, install Docker and the SSM agent
sudo apt-get update
sudo apt-get install -y docker.io docker-compose-plugin

# Enable SSM agent (usually pre-installed on Ubuntu 22.04 AMIs)
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

# Allow ubuntu user to run docker without sudo
sudo usermod -aG docker ubuntu

The persistent QA EC2 instance with LabRole attached, running Docker and Nginx

Attach the LabRole to this EC2 instance. In AWS Academy, LabRole is a pre-provisioned IAM role that already has the permissions needed for SSM, ECR, and EC2 operations, you don't create it yourself, it's provided by the lab environment.

5.5 IAM Credentials for GitHub Actions (AWS Academy)

AWS Academy accounts don't support OIDC federation or long-lived IAM users. Instead, you get temporary session credentials from the AWS Details panel in the Vocareum lab console. These rotate every session.

Store them as GitHub Secrets:

AWS_ACCESS_KEY_ID      → from AWS Details panel
AWS_SECRET_ACCESS_KEY  → from AWS Details panel
AWS_SESSION_TOKEN      → from AWS Details panel (required for temporary credentials)

Then configure credentials in your workflow using the static credential method:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }}
    aws-region: us-east-1

Note: AWS Academy session credentials expire when the lab session ends (~4 hours). You'll need to update these three secrets each time you start a new lab session. This is a limitation of the Academy environment, in a real AWS account you would use OIDC to avoid static credentials entirely.

6. GitHub Actions CI/CD Pipeline

The infra repo contains five workflow files that chain together via workflow_call. Each does one thing well.

6.1 Nightly Orchestrator (`nightly.yml`)

This is the entry point, triggered on a schedule or manually:

# .github/workflows/nightly.yml
name: Nightly Build and Deploy

on:
  schedule:
    - cron: '0 2 * * *'  # 2 AM UTC every day
  workflow_dispatch:        # Allow manual triggers

jobs:
  setup:
    runs-on: ubuntu-latest
    outputs:
      image_tag: ${{ steps.tag.outputs.image_tag }}
    steps:
      - id: tag
        run: echo "image_tag=$(date +%Y%m%d%H%M%S)" >> $GITHUB_OUTPUT

  build:
    needs: setup
    uses: ./.github/workflows/build.yml
    with:
      image_tag: ${{ needs.setup.outputs.image_tag }}
    secrets: inherit

  smoke-test:
    needs: [setup, build]
    uses: ./.github/workflows/smoke-test.yml
    with:
      image_tag: ${{ needs.setup.outputs.image_tag }}
    secrets: inherit

  promote:
    needs: [setup, smoke-test]  # Only runs if smoke test passes
    uses: ./.github/workflows/promote.yml
    with:
      image_tag: ${{ needs.setup.outputs.image_tag }}
    secrets: inherit

  deploy-qa:
    needs: promote
    uses: ./.github/workflows/deploy-qa.yml
    secrets: inherit

The timestamp tag (e.g., 20250307021530) makes every build uniquely identifiable. If a smoke test fails, the image stays tagged only with the timestamp, it's never promoted to :latest and never deployed.

6.2 Build and Push to ECR (`build.yml`)

# .github/workflows/build.yml
name: Build and Push to ECR

on:
  workflow_call:
    inputs:
      image_tag:
        required: true
        type: string

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source code
        uses: actions/checkout@v4
        with:
          repository: Shreyas-Yadav/job-application-tracker
          token: ${{ secrets.SOURCE_REPO_TOKEN }}

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }}
          aws-region: us-east-1

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push backend
        run: |
          docker build -t ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/job-tracker-backend:${{ inputs.image_tag }} ./backend
          docker push ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/job-tracker-backend:${{ inputs.image_tag }}

      - name: Build and push frontend
        run: |
          docker build -t ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/job-tracker-frontend:${{ inputs.image_tag }} ./frontend
          docker push ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/job-tracker-frontend:${{ inputs.image_tag }}

6.3 Smoke Test on Temporary EC2 (`smoke-test.yml`)

This is the most interesting part. Instead of testing on the QA instance (risking breaking it), we launch a fresh, temporary EC2 for every test run:

# .github/workflows/smoke-test.yml
jobs:
  smoke-test:
    runs-on: ubuntu-latest
    steps:
      - name: Launch temporary EC2
        id: launch
        run: |
          INSTANCE_ID=$(aws ec2 run-instances \
            --image-id ${{ secrets.TEMP_EC2_AMI }} \
            --instance-type t3.micro \
            --subnet-id ${{ secrets.TEMP_EC2_SUBNET_ID }} \
            --security-group-ids ${{ secrets.TEMP_EC2_SG_ID }} \
            --iam-instance-profile Name=LabInstanceProfile \
            --query 'Instances[0].InstanceId' \
            --output text)
          echo "instance_id=$INSTANCE_ID" >> $GITHUB_OUTPUT

      - name: Wait for SSM agent
        run: |
          # Wait up to 4 minutes for the instance to boot and SSM to connect
          for i in {1..24}; do
            STATUS=$(aws ssm describe-instance-information \
              --filters "Key=InstanceIds,Values=${{ steps.launch.outputs.instance_id }}" \
              --query 'InstanceInformationList[0].PingStatus' \
              --output text 2>/dev/null || echo "None")
            [ "$STATUS" = "Online" ] && break
            sleep 10
          done

      - name: Run smoke tests via SSM
        run: |
          COMMAND_ID=$(aws ssm send-command \
            --instance-ids ${{ steps.launch.outputs.instance_id }} \
            --document-name "AWS-RunShellScript" \
            --parameters commands='[
              "aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com",
              "IMAGE_TAG=${{ inputs.image_tag }} docker compose -f /tmp/docker-compose.smoke.yml up -d",
              "bash /tmp/smoke-test.sh"
            ]' \
            --query 'Command.CommandId' --output text)

          # Poll until complete
          aws ssm wait command-executed \
            --command-id $COMMAND_ID \
            --instance-id ${{ steps.launch.outputs.instance_id }}

      - name: Terminate temporary EC2
        if: always()  # Clean up even if tests fail
        run: |
          aws ec2 terminate-instances \
            --instance-ids ${{ steps.launch.outputs.instance_id }}

The smoke-test.sh script runs three checks:

#!/bin/bash
BACKEND=${1:-"http://localhost:5000"}
FRONTEND=${2:-"http://localhost:3000"}

# Wait up to 2 minutes for backend to be ready
for i in {1..12}; do
  curl -sf "$BACKEND/health" > /dev/null && break
  echo "Waiting for backend... ($i/12)"
  sleep 10
done

# Test 1: Backend health check
curl -sf "$BACKEND/health" | grep -q '"status":"ok"' || { echo "FAIL: /health"; exit 1; }
echo "PASS: Backend /health returns ok"

# Test 2: Auth middleware is working (unauthenticated request → 401)
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BACKEND/api/applications")
[ "$STATUS" = "401" ] || { echo "FAIL: /api/applications should return 401, got $STATUS"; exit 1; }
echo "PASS: /api/applications correctly requires authentication"

# Test 3: Frontend is serving pages
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$FRONTEND")
[ "$STATUS" = "200" ] || { echo "FAIL: Frontend returned $STATUS"; exit 1; }
echo "PASS: Frontend is serving pages"

echo "All smoke tests passed!"

6.4 Promote Image (`promote.yml`)

Once smoke tests pass, we retag the timestamp image as :latest:

# .github/workflows/promote.yml
jobs:
  promote:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        repo: [job-tracker-backend, job-tracker-frontend]
    steps:
      - name: Retag image as latest
        run: |
          REGISTRY="${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com"
          # Fetch the manifest of the tested image
          MANIFEST=$(aws ecr batch-get-image \
            --repository-name ${{ matrix.repo }} \
            --image-ids imageTag=${{ inputs.image_tag }} \
            --query 'images[0].imageManifest' --output text)

          # Push the same manifest with the :latest tag
          aws ecr put-image \
            --repository-name ${{ matrix.repo }} \
            --image-tag latest \
            --image-manifest "$MANIFEST"

This approach (retagging the manifest) is instant, no re-pulling or re-pushing layers. The :latest image is byte-for-byte identical to the tested timestamp image.

6.5 Deploy to QA EC2 (`deploy-qa.yml`)

The final step deploys to the persistent QA server using AWS SSM, no SSH keys needed:

# .github/workflows/deploy-qa.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check QA EC2 is running
        id: check
        run: |
          STATE=$(aws ec2 describe-instances \
            --instance-ids ${{ secrets.QA_EC2_INSTANCE_ID }} \
            --query 'Reservations[0].Instances[0].State.Name' \
            --output text)
          echo "state=$STATE" >> $GITHUB_OUTPUT

      - name: Sync config files
        if: steps.check.outputs.state == 'running'
        run: |
          # Base64-encode configs and decode them on the EC2 to avoid quoting issues
          COMPOSE_B64=$(base64 -w0 docker-compose.prod.yml)
          NGINX_B64=$(base64 -w0 nginx/nginx.conf)

          aws ssm send-command \
            --instance-ids ${{ secrets.QA_EC2_INSTANCE_ID }} \
            --document-name "AWS-RunShellScript" \
            --parameters commands="[
              \"echo $COMPOSE_B64 | base64 -d > /home/ubuntu/app/docker-compose.prod.yml\",
              \"echo $NGINX_B64 | base64 -d > /etc/nginx/sites-enabled/default\",
              \"nginx -t && systemctl reload nginx\"
            ]"

      - name: Deploy containers
        if: steps.check.outputs.state == 'running'
        run: |
          aws ssm send-command \
            --instance-ids ${{ secrets.QA_EC2_INSTANCE_ID }} \
            --document-name "AWS-RunShellScript" \
            --parameters commands="[
              \"aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com\",
              \"cd /home/ubuntu/app && docker compose -f docker-compose.prod.yml pull\",
              \"DB_HOST=${{ secrets.DB_HOST }} DB_NAME=${{ secrets.DB_NAME }} DB_USER=${{ secrets.DB_USER }} DB_PASSWORD=${{ secrets.DB_PASSWORD }} NEXTAUTH_SECRET=${{ secrets.NEXTAUTH_SECRET }} docker compose -f docker-compose.prod.yml up -d\",
              \"sleep 10 && curl -sf http://localhost:5000/health\"
            ]"

All 5 jobs in the nightly pipeline completing successfully in 5m 26s

The deploy-qa job expanded showing each SSM step: sync config files, deploy via docker compose, health check

7. Domain Name with Route 53 and SSL with Let's Encrypt

7.1 Get a Domain and Migrate to Route 53

Purchase a domain on Name.com (or any registrar)
Create a Hosted Zone in AWS Route 53 for your domain
Note the 4 NS (nameserver) records Route 53 provides
In Name.com's DNS settings, replace the default nameservers with Route 53's NS records
Wait 24-48 hours for propagation

7.2 Create DNS Records

In Route 53, create an A record pointing to your QA EC2's public IP:

Route 53 hosted zone for shri.software showing the A record, NS, and SOA records

Type: A
Name: shri.software
Value: <EC2 Public IP>
TTL: 300

Note: If you stop/start EC2 instances, the public IP changes. Consider using an Elastic IP for the QA instance to keep the IP stable.

7.3 Install Certbot and Get an SSL Certificate

SSH into your QA EC2 and run:

# Install Certbot with the Nginx plugin
sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx

# Obtain a certificate (Certbot automatically configures Nginx)
sudo certbot --nginx -d shri.software

# Verify auto-renewal is configured
sudo systemctl status certbot.timer
sudo certbot renew --dry-run

Certbot will:

Verify domain ownership by placing a file at /.well-known/acme-challenge/
Download the certificate to /etc/letsencrypt/live/shri.software/
Modify your Nginx config to use the certificate

8. Nginx as a Reverse Proxy

Nginx sits in front of both services, routing traffic and terminating SSL:

# /etc/nginx/sites-enabled/default

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name shri.software;
    return 301 https://$host$request_uri;
}

# HTTPS server
server {
    listen 443 ssl;
    server_name shri.software;

    ssl_certificate     /etc/letsencrypt/live/shri.software/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shri.software/privkey.pem;

    # NextAuth routes must go to the frontend (Next.js handles them)
    location /api/auth/ {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }

    # All other /api/ routes go to Express backend
    location /api/ {
        proxy_pass http://localhost:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Everything else goes to Next.js frontend
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

The order of location blocks matters: /api/auth/ must be listed before /api/ because Nginx uses longest prefix matching.

9. Security Best Practices

Here's what I did deliberately for security:

Containers

Non-root users in every container (adduser -S shri)
Alpine base images, smaller surface area, fewer CVEs
--production npm install, dev tools never ship to production
Multi-stage builds, build tools (compilers, test runners) never end up in production images

Authentication

GitHub OAuth, no password storage, no credential database to protect
Short-lived JWTs (1 hour expiry) between frontend and backend
User-scoped queries, every DB query filters by user_id from the verified JWT; users cannot access each other's data

Infrastructure

No SSH keys, AWS SSM for all remote execution; port 22 is closed
LabRole on EC2, AWS Academy's pre-provisioned role grants SSM and ECR access without custom policy authoring
RDS in private subnet, database is not publicly accessible
Secrets in GitHub Secrets, never hardcoded in workflow files or checked into git
HTTPS only, Nginx enforces HTTP → HTTPS redirect at the server level

Secrets Management

All secrets stored in GitHub, values are never visible after being saved

# GitHub Secrets used in this project:
AWS_ACCOUNT_ID          # AWS account number
AWS_ACCESS_KEY_ID       # From AWS Academy lab details panel
AWS_SECRET_ACCESS_KEY   # From AWS Academy lab details panel
AWS_SESSION_TOKEN       # From AWS Academy lab details panel (rotates each session)
TEMP_EC2_AMI            # AMI ID for smoke test instances
TEMP_EC2_SUBNET_ID      # VPC subnet for temporary instances
TEMP_EC2_SG_ID          # Security group ID
QA_EC2_INSTANCE_ID      # Persistent QA EC2 instance ID
DB_HOST                 # RDS endpoint
DB_NAME / DB_USER / DB_PASSWORD
NEXTAUTH_SECRET         # Shared secret for JWT signing
GITHUB_CLIENT_ID / GITHUB_CLIENT_SECRET  # OAuth app credentials
SOURCE_REPO_TOKEN       # PAT to check out source repo from infra repo

Conclusion

The full pipeline, from a git push to a verified deployment on HTTPS, runs without any manual steps. The key architectural wins:

Two repos for clean separation of application vs. infrastructure concerns
Timestamp-tagged images with promotion to :latest only after passing tests
Ephemeral test infrastructure that is created and destroyed per pipeline run
SSM-based deployment with no SSH keys to manage
Route 53 + Let's Encrypt for production-grade DNS and SSL at zero cost

The live app is running at https://shri.software. The source code is split across:

Source repo: github.com/Shreyas-Yadav/job-application-tracker
Infra repo: github.com/Shreyas-Yadav/job-application-tracker-infra

Building High-Availability Web Apps on AWS: Auto Scaling, ALB, and Private Subnets

Shreyas Yadav — Tue, 14 Oct 2025 22:26:38 +0000

This guide, we’ll see how to deploy a production ready weather application on AWS with enterprise grade architecture. We’l' use Auto Scaling Groups and Application Load Balancers for high availability, public-private subnets for security isolation, and Amazon ECR for containerized deployments. To make it production complete, we'll configure a custom domain with Route 53 and enable HTTPS using AWS Certificate Manager. The result? A fully scalable, secure web application accessible via your own domain with SSL encryption exactly how professional applications should be deployed.

GitHub Repository: https://github.com/Shreyas-Yadav/weather-aws

Clone the above repo and continue.

Our weather application uses a multi-tier architecture on AWS that separates the frontend and backend for better security and scalability.

Step 1: Creating the VPC

What is a VPC?

A VPC (Virtual Private Cloud) is your isolated network in AWS. Think of it as your own private data center in the cloud where all your servers and resources will live securely.

Setting Up the VPC

Navigate to VPC Creation

Go to AWS Console → Search "VPC" → Click "Your VPCs" → Click "Create VPC"

Choose "VPC and more"

You'll see two options:

VPC only - Manual setup (tedious)
VPC and more - Automatic setup(recommended)

Select "VPC and more" - AWS will automatically create all networking components for you.

Basic Configuration

Name tag auto-generation: weather-app
This prefix will be added to all resources, making them easy to identify.

IPv4 CIDR block: 10.0.0.0/16
This is your VPC's IP address range (65,536 available IPs).

IPv6: Select "No IPv6 CIDR block"
Tenancy: Keep as "Default"

Availability Zones and Subnets

Number of Availability Zones: Select 2
This is crucial for high availability - if one data center fails, your app continues running in the other.

Number of public subnets: 2
These will host your frontend servers (internet-accessible)

Number of private subnets: 2
These will host your backend servers (hidden from internet)

Subnet CIDR blocks: Keep the defaults:

Public subnet 1a:  10.0.0.0/20
Public subnet 1b:  10.0.16.0/20
Private subnet 1a: 10.0.128.0/20
Private subnet 1b: 10.0.144.0/20

NAT Gateways

Select "1 per AZ" (creates 2 total)

What's a NAT Gateway?
It allows your private backend servers to access the internet (for API calls, updates) while staying hidden from incoming internet traffic.

Why 2 NAT Gateways?
High availability each private subnet gets its own NAT Gateway for redundancy.

Additional Settings

VPC endpoints: None
DNS options: Enable both

Enable DNS hostnames
Enable DNS resolution

Create VPC

Click "Create VPC" and wait 2-3 minutes.

AWS will create:

1 VPC
4 Subnets (2 public, 2 private)
1 Internet Gateway
2 NAT Gateways
Route tables

Step 2: Creating Security Groups

What are Security Groups?

Security Groups are virtual firewalls that control inbound and outbound traffic to your AWS resources.

We'll create 4 security groups to control traffic between components.

Security Group 1: Frontend ALB Security Group

Navigate: EC2 → Security Groups → Create security group

Name: weather-frontend-alb-sg
Description: Security group for Frontend Application Load Balancer
VPC: weather-app-vpc

Inbound Rules:

HTTP (80) from 0.0.0.0/0
HTTPS (443) from 0.0.0.0/0

Outbound Rules: All traffic (default)

Security Group 2: Frontend EC2 Security Group

Name: weather-frontend-sg
Description: Security group for Frontend EC2 instances
VPC: weather-app-vpc

Inbound Rules:

HTTP (80) from Custom → weather-frontend-alb-sg
SSH (22) from My IP (optional for debugging)

Outbound Rules: All traffic (default)

Security Group 3: Backend ALB Security Group

Name: weather-backend-alb-sg
Description: Security group for Backend Application Load Balancer
VPC: weather-app-vpc

Inbound Rules:

HTTP (80) from Custom → weather-frontend-sg

Outbound Rules: All traffic (default)

Security Group 4: Backend EC2 Security Group

Name: weather-backend-sg
Description: Security group for Backend EC2 instances
VPC: weather-app-vpc

Inbound Rules:

Custom TCP (3000) from Custom → weather-backend-alb-sg
SSH (22) from My IP (optional for debugging)

Outbound Rules: All traffic (default)

Traffic Flow

Internet → Frontend ALB (80,443) → Frontend EC2 (80) → Backend ALB (80) → Backend EC2 (3000)

Step 3: IAM Role for EC2 Instances.

Note for AWS Academy/Lab Users

If you're using AWS Academy Labs or AWS Learner Lab, you cannot create custom IAM roles. Instead, use the pre-configured role provided:

Role name: LabRole

This role already has the necessary permissions for ECR, Parameter Store, and other AWS services.

When creating EC2 instances or Launch Templates, select LabRole as the IAM instance profile.

For Regular AWS Accounts

If you're using a personal/company AWS account (not AWS Labs), follow these steps to create a custom IAM role:

Navigate: IAM → Roles → Create role

Step 1: Select Trusted Entity

Trusted entity type: AWS service
Use case: EC2

Click Next

Add Permissions

Search and select these 2 managed policies:

AmazonEC2ContainerRegistryReadOnly
AmazonSSMManagedInstanceCore

Click Next

Name and Create

Role name: weather-ec2-role
Description: IAM role for Weather App EC2 instances

Click Create role

Add Parameter Store Policy

Click on weather-ec2-role → Permissions tab
Click Add permissions → Create inline policy → JSON tab

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:ssm:*:*:parameter/weather-app/*"
    }
  ]
}

Policy name: ParameterStoreReadPolicy
Click **Create

Step 4: Creating ECR Repositories

What is Amazon ECR?

Amazon Elastic Container Registry (ECR) is a Docker container registry where we'll store our frontend and backend Docker images. EC2 instances will pull images from here during deployment.

Create ECR Repositories

Navigate: Amazon ECR → Repositories → Create repository

Repository 1: Frontend

Repository name: weather-frontend
Image tag mutability: Mutable
Encryption: AES-256 (default)
Scan on push: Enable (optional)

Click Create repository

Repository 2: Backend

Repository name: weather-backend
Image tag mutability: Mutable
Encryption: AES-256 (default)
Scan on push: Enable (optional)

Click Create repository

Note Your Repository URIs

After creation, note down both repository URIs (format: account-id.dkr.ecr.region.amazonaws.com/repository-name):

Frontend URI: 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-frontend
Backend URI: 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-backend

You'll need these URIs to push Docker images and configure EC2 instances.

Step 5: Build and Push Docker Images to ECR

Prerequisites

Ensure you have installed:

AWS CLI (latest version)
Docker

Build Docker Images

Important: Build images compatible with EC2 architecture (Linux AMD64/ARM64).

Navigate to your project directory and build both images:

Build Backend:

docker buildx build --platform linux/amd64,linux/arm64 -t weather-backend --load ./backend

Build Frontend:

docker buildx build --platform linux/amd64,linux/arm64 -t weather-frontend --load ./frontend

Why --platform flag?

EC2 instances run Linux. This ensures your Docker images are compatible with EC2's operating system and CPU architecture.

Push Images to ECR

AWS provides ready-to-use push commands for each repository.

To view push commands: ECR → Repositories → Select repository → Click "View push commands"

Authenticate Docker to ECR

Replace us-east-1 with your region and 339712997278 with your AWS account ID:

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 339712997278.dkr.ecr.us-east-1.amazonaws.com

Tag Frontend Image

docker tag weather-frontend:latest 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-frontend:latest

Push Frontend Image

docker push 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-frontend:latest

Tag Backend Image

docker tag weather-backend:latest 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-backend:latest

Push Backend Image

docker push 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-backend:latest

Verify Images in ECR

Go to Amazon ECR → Repositories

Check both repositories:

weather-frontend - Should show latest tag
weather-backend - Should show latest tag

—

Step 6: Creating Target Groups

What are Target Groups?

Target Groups are used by Application Load Balancers to route traffic to registered EC2 instances. They also perform health checks to ensure traffic only goes to healthy instances.

We'll create 2 target groups - one for frontend and one for backend.

Target Group 1: Backend Target Group

Navigate: EC2 → Target Groups → Create target group

Step 1: Basic Configuration

Target type: Instances
Target group name: weather-backend-tg
Protocol: HTTP
Port: 3000
VPC: weather-app-vpc
Protocol version: HTTP1

Step 2: Health Checks

Health check protocol: HTTP
Health check path: /health

Advanced health check settings:

Healthy threshold: 2
Unhealthy threshold: 3
Timeout: 5 seconds
Interval: 30 seconds
Success codes: 200

Step 3: Register Targets

Skip this step - instances will be added automatically by Auto Scaling Group.

Click Create target group

Target Group 2: Frontend Target Group

Step 1: Basic Configuration

Target type: Instances
Target group name: weather-frontend-tg
Protocol: HTTP
Port: 80
VPC: weather-app-vpc
Protocol version: HTTP1

Step 2: Health Checks

Health check protocol: HTTP
Health check path: /health

Advanced health check settings:

Healthy threshold: 2
Unhealthy threshold: 3
Timeout: 5 seconds
Interval: 30 seconds
Success codes: 200

Step 3: Register Targets

Skip this step - instances will be added automatically by Auto Scaling Group.

Click Create target group

Step 7: Creating Application Load Balancers

What is an Application Load Balancer?

An Application Load Balancer (ALB) distributes incoming traffic across multiple EC2 instances. We'll create two ALBs:

Frontend ALB (Internet-facing) - Receives traffic from users
Backend ALB (Internal) - Receives traffic from frontend instances

ALB 1: Backend Application Load Balancer

Navigate: EC2 → Load Balancers → Create load balancer → Application Load Balancer

Basic Configuration

Load balancer name: weather-backend-alb
Scheme: Internal
IP address type: IPv4

Network Mapping

VPC: weather-app-vpc
Availability Zones: Select both
  ☑ us-east-1a → Select private subnet
  ☑ us-east-1b → Select private subnet

Security Groups

Remove: default
Add: weather-backend-alb-sg

Listeners and Routing

Protocol: HTTP
Port: 80
Default action: Forward to weather-backend-tg

Click Create load balancer

Wait 2-3 minutes for the ALB to become active.

Important: Copy the Backend ALB DNS name - you'll need it later!

ALB 2: Frontend Application Load Balancer

Basic Configuration

Load balancer name: weather-frontend-alb
Scheme: Internet-facing
IP address type: IPv4

Network Mapping

VPC: weather-app-vpc
Availability Zones: Select both
  ☑ us-east-1a → Select public subnet
  ☑ us-east-1b → Select public subnet

Security Groups

Remove: default
Add: weather-frontend-alb-sg

Listeners and Routing

Protocol: HTTP
Port: 80
Default action: Forward to weather-frontend-tg

Click Create load balancer

Wait 2-3 minutes for the ALB to become active.

Verify Load Balancers

Go to EC2 → Load Balancers

Check both ALBs show State: Active

Note down both DNS names:

Frontend ALB DNS: weather-frontend-alb-xxxxx.us-east-1.elb.amazonaws.com
Backend ALB DNS: weather-backend-alb-xxxxx.us-east-1.elb.amazonaws.com

Step 8: Configure AWS Systems Manager Parameter Store

What is Parameter Store?

Parameter Store allows you to store configuration data and secrets centrally. EC2 instances will fetch these values at runtime, eliminating hardcoded configuration.

Create Parameters

Navigate: AWS Systems Manager → Parameter Store → Create parameter.

Create the following parameters:

Parameter 1: AWS Region

Name: /weather-app/aws-region
Type: String
Value: us-east-1 (or your region)

Parameter 2: Backend ALB Host (used by frontend to call an api)

Name: /weather-app/backend-host
Type: String
Value: <Your Backend ALB DNS without http://>
Example: internal-weather-backend-alb-xxxxx.us-east-1.elb.amazonaws.com

Parameter 3: Backend ALB Port (used by frontend to call an api)

Name: /weather-app/backend-port
Type: String
Value: 80

Parameter 4: Frontend ECR Registry

Name: /weather-app/ecr-registry-frontend
Type: String
Value: <Your account ID>.dkr.ecr.us-east-1.amazonaws.com/weather-frontend
Example: 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-frontend

Parameter 5: Backend ECR Registry

Name: /weather-app/ecr-registry-backend
Type: String
Value: <Your account ID>.dkr.ecr.us-east-1.amazonaws.com/weather-backend
Example: 339712997278.dkr.ecr.us-east-1.amazonaws.com/weather-backend

Parameter 6: OpenWeather API Key

Name: /weather-app/openweather-api-key
Type: String (or SecureString for encryption)
Value: <Your OpenWeatherMap API key>

Get your free API key from: https://openweathermap.org/api

Verify Parameters

All 6 parameters should now be visible in Parameter Store with the prefix /weather-app/

—

Step 9: Create Launch Templates

What is a Launch Template?

A Launch Template defines the configuration for EC2 instances that will be launched by Auto Scaling Groups. We'll create two templates - one for backend and one for frontend.

Launch Template 1: Backend Launch Template

Navigate: EC2 → Launch Templates → Create launch template

Launch Template Name and Description

Launch template name: weather-backend-lt
Template version description: Backend instances for weather app

Application and OS Images (AMI)

Quick Start: Ubuntu
Ubuntu Server 24.04 LTS (HVM), SSD Volume Type
Architecture: 64-bit (x86)

Instance Type

Instance type: t3.micro (or t2.micro for free tier)

Key Pair

Key pair name: Select your existing key pair

Network Settings

Subnet: Don't include in launch template
Firewall (security groups): weather-backend-sg

Storage

Keep default: 8 GiB, gp3

Advanced Details

IAM instance profile:

LabRole (for AWS Academy users)
OR weather-ec2-role (for regular AWS accounts)

Metadata accessible: Enabled

User data:

Copy the backend user data script from the repository:

Backend User Data Script →

This script:

Installs Docker and AWS CLI
Fetches configuration from Parameter Store
Pulls Docker image from ECR
Starts the backend container

Click Create launch template

Launch Template 2: Frontend Launch Template

Follow the same steps with these differences:

Launch template name: weather-frontend-lt
Template version description: Frontend instances for weather app
Security group: weather-frontend-sg

User data:

Copy the frontend user data script from the repository:

Frontend User Data Script →

This script:

Installs Docker and AWS CLI
Fetches backend ALB DNS from Parameter Store
Pulls Docker image from ECR
Starts the frontend container with backend configuration

Click Create launch template

Step 10: Create Auto Scaling Groups

What is an Auto Scaling Group?

An Auto Scaling Group (ASG) automatically manages EC2 instances - launching new instances when traffic increases and terminating them when traffic decreases. We'll create two ASGs - one for backend and one for frontend.

Note Create ASG first for backend and then create for frontend.

Auto Scaling Group 1: Backend ASG

Navigate: EC2 → Auto Scaling Groups → Create Auto Scaling group

Step 1: Choose Launch Template

Auto Scaling group name: weather-backend-asg
Launch template: weather-backend-lt
Version: Default (1)

Click Next

Step 2: Choose Instance Launch Options

VPC: weather-app-vpc

Availability Zones and subnets:
  ☑ weather-app-subnet-private1-us-east-1a
  ☑ weather-app-subnet-private2-us-east-1b

Click Next

Step 3: Configure Advanced Options

Load balancing:
  ☑ Attach to an existing load balancer

Choose from your load balancer target groups:
  ☑ weather-backend-tg

Health checks:
  ☑ Turn on Elastic Load Balancing health checks
  Health check grace period: 300 seconds

Click Next

Step 4: Configure Group Size and Scaling

Group size:
  Desired capacity: 2
  Minimum capacity: 2
  Maximum capacity: 4

Scaling:
  ☑ Target tracking scaling policy

  Scaling policy name: backend-cpu-scaling
  Metric type: Average CPU utilization
  Target value: 70
  Instance warmup: 300 seconds

Click Next → Next → Create Auto Scaling group

Wait 5-10 minutes for instances to launch and become healthy.

Auto Scaling Group 2: Frontend ASG

Follow the same steps with these differences:

Step 1: Choose Launch Template

Auto Scaling group name: weather-frontend-asg
Launch template: weather-frontend-lt

Step 2: Network

Availability Zones and subnets:
  ☑ weather-app-subnet-public1-us-east-1a
  ☑ weather-app-subnet-public2-us-east-1b

Step 3: Load Balancing

Target group: weather-frontend-tg

Step 4: Group Size and Scaling

Desired capacity: 2
Minimum capacity: 2
Maximum capacity: 4

Scaling policy name: frontend-cpu-scaling
Metric type: Average CPU utilization
Target value: 70

Click Create Auto Scaling group

Wait 5-10 minutes for instances to launch and become healthy.

Verify Auto Scaling Groups

Check Instances:

Go to EC2 → Instances
You should see 4 running instances:
- 2 backend instances (in private subnets)
- 2 frontend instances (in public subnets)

Check Target Health:

Go to EC2 → Target Groups
Select weather-backend-tg → Targets tab
- Both targets should show Healthy
Select weather-frontend-tg → Targets tab
- Both targets should show Healthy

—--

Step 11: Testing Your Application

Test Application via Frontend ALB

Get Frontend ALB DNS:

Go to EC2 → Load Balancers
Select weather-frontend-alb
Copy the DNS name

Example: weather-frontend-alb-841040545.us-east-1.elb.amazonaws.com

Test in Browser:

Open your browser and navigate to:

http://weather-frontend-alb-XXXXXXX.us-east-1.elb.amazonaws.com

You should see:

Weather Application interface
Search box to enter city name
Real-time weather data when you search

Test the Complete Flow:

Enter a city name (e.g., "Mumbai", "London", "New York")
Click Search
Weather information should display:
- Current temperature
- Weather condition (Haze, Clear, etc.)
- Feels like temperature
- Humidity
- Wind speed
- Pressure

Common Issues:

If the application doesn't work:

Check Target Health:
- EC2 → Target Groups → Check both target groups show "Healthy"
Check Instance Logs:
- Connect to instances via Session Manager
- View logs: sudo docker logs weather-frontend or sudo docker logs weather-backend
Check Security Groups:
- Verify all security group rules are correct
- Frontend ALB should allow 80 from internet
- Backend ALB should allow 80 from frontend SG

—--

Step 12: Add Custom Domain and Enable HTTPS

Prerequisites

You need a registered domain name from any registrar (Namecheap, GoDaddy, etc.)

Part A: Create Hosted Zone in Route 53

Navigate: Route 53 → Hosted zones → Create hosted zone

Configuration:

Domain name: shri.software
Type: Public hosted zone

Click Create hosted zone

Update Nameservers at Your Domain Registrar:

Copy the 4 NS (nameserver) records from Route 53
Go to your domain registrar (Namecheap, GoDaddy, etc.)
Replace existing nameservers with the 4 AWS nameservers
Save changes

Wait 15-30 minutes for DNS propagation

Part B: Request SSL/TLS Certificate

Navigate: AWS Certificate Manager (ACM) → Request certificate
Step 1: Request Certificate
Certificate type: Request a public certificate
Click Next

Step 2: Domain Names
Fully qualified domain name: shri.software
Add another name: *.shri.software (optional, for subdomains)

Step 3: Validation Method
Validation method: DNS validation - recommended

Step 4: Key Algorithm
RSA 2048 (default)
Click Request

Part C: Validate Certificate

After requesting the certificate, ACM will show validation details.
Click "Create records in Route”

This automatically adds the required CNAME validation records to your hosted zone.
Wait 5-10 minutes for validation to complete.
Certificate Status: Will change from "Pending validation" to "Issued"

Part D: Create A Record for Your Domain

Navigate: Route 53 → Hosted zones → shri.software

Create A Record:
Record name: (leave empty for root domain)
Record type: A - Alias
Route traffic to: Alias to Application Load Balancer
Region: us-east-1
Load balancer: weather-frontend-alb

Click Create records

Part E: Add HTTPS Listener to Frontend ALB

Navigate: EC2 → Load Balancers → weather-frontend-alb
Add HTTPS Listener:

Click Listeners tab
Click Add listener

Protocol: HTTPS
Port: 443
Default action: Forward to weather-frontend-tg
Default SSL/TLS certificate: From ACM → Select your certificate (shri.software)

Click Add

Part F: Redirect HTTP to HTTPS

Edit HTTP:80 Listener:

Select HTTP:80 listener
Click Actions → Edit listener
Remove existing forward action
Add action → Redirect to...

Protocol: HTTPS
Port: 443
Status code: 301 - Permanently moved

Click Save changes

Verify Your Setup

Test in Browser:

Open: https://your_domain_name

You should see:
✅ Padlock icon (secure connection)
✅ Weather application loads
✅ HTTP automatically redirects to HTTPS

Congratulations! Your application is live.

Step 13: Cleanup and Delete Resources

It is essential to delete all resources created in this guide to avoid incurring unnecessary charges on your AWS account.

Cleanup Order

Auto Scaling Groups (ASGs):
Delete weather-frontend-asg and weather-backend-asg. (This action automatically terminates all running EC2 instances.)
Application Load Balancers (ALBs):
Delete weather-frontend-alb and weather-backend-alb.
Target Groups:
Delete weather-frontend-tg and weather-backend-tg.
Launch Templates:
Delete weather-frontend-lt and weather-backend-lt.
ECR Repositories:
Delete weather-frontend and weather-backend. (This deletes the stored Docker images.)
Route 53 & AWS Certificate Manager (ACM):
Delete the A Record pointing to the ALB.
Delete the ACM Certificate.
Delete the Hosted Zone in Route 53.
IAM Role & Security Groups:
Delete the IAM Role (weather-ec2-role).
Delete the 4 Security Groups (weather-frontend-alb-sg, weather-frontend-sg, etc.).
Systems Manager Parameters:
Delete all Parameters under the /weather-app/ path.
VPC:
Delete the VPC (weather-app-vpc). (This final step cleans up Subnets, Internet Gateway, and NAT Gateways.)

Conclusion and Thank You..!

Congratulations! You have successfully deployed a highly available, secure, and production-ready weather application on AWS using enterprise-grade architecture.

By completing this guide, you’ve mastered key AWS services including VPC, Auto Scaling Groups, Application Load Balancers, ECR, Route 53, and ACM. This foundational knowledge is crucial for deploying any modern, scalable web application.

Thank you for following along, and I hope this guide helps you on your cloud journey!

Forem: Shreyas Yadav

I Built a Nightly Pipeline That Deploys My App While I Sleep

Table of Contents

1. Architecture Overview

High-Level Architecture

2. The Application: Job Application Tracker

Tech Stack

Database Schema

Backend API

Authentication Flow

3. Dockerizing the App

Backend Dockerfile

Frontend Dockerfile (Multi-Stage Build)

4. Local Development with Docker Compose

5. AWS Infrastructure Setup

5.1 GitHub OAuth App

5.2 AWS ECR (Elastic Container Registry)

5.3 AWS RDS (MySQL 8)

5.4 QA EC2 Instance

5.5 IAM Credentials for GitHub Actions (AWS Academy)

6. GitHub Actions CI/CD Pipeline

6.1 Nightly Orchestrator (nightly.yml)

6.2 Build and Push to ECR (build.yml)

6.3 Smoke Test on Temporary EC2 (smoke-test.yml)

6.4 Promote Image (promote.yml)

6.5 Deploy to QA EC2 (deploy-qa.yml)

7. Domain Name with Route 53 and SSL with Let's Encrypt

7.1 Get a Domain and Migrate to Route 53

7.2 Create DNS Records

7.3 Install Certbot and Get an SSL Certificate

8. Nginx as a Reverse Proxy

9. Security Best Practices

Containers

Authentication

Infrastructure

Secrets Management

Conclusion

Building High-Availability Web Apps on AWS: Auto Scaling, ALB, and Private Subnets

Step 1: Creating the VPC

What is a VPC?

Setting Up the VPC

Step 2: Creating Security Groups

What are Security Groups?

Security Group 1: Frontend ALB Security Group

Security Group 2: Frontend EC2 Security Group

Security Group 3: Backend ALB Security Group

Security Group 4: Backend EC2 Security Group

Traffic Flow

Step 3: IAM Role for EC2 Instances.

Note for AWS Academy/Lab Users

For Regular AWS Accounts

Step 4: Creating ECR Repositories

What is Amazon ECR?

Create ECR Repositories

Repository 1: Frontend

Repository 2: Backend

Note Your Repository URIs

Step 5: Build and Push Docker Images to ECR

Prerequisites

Build Docker Images

Push Images to ECR

Verify Images in ECR

Step 6: Creating Target Groups

What are Target Groups?

Target Group 1: Backend Target Group

Target Group 2: Frontend Target Group

Step 7: Creating Application Load Balancers

What is an Application Load Balancer?

ALB 1: Backend Application Load Balancer

ALB 2: Frontend Application Load Balancer

Verify Load Balancers

Step 8: Configure AWS Systems Manager Parameter Store

What is Parameter Store?

Create Parameters

Verify Parameters

Step 9: Create Launch Templates

What is a Launch Template?

Launch Template 1: Backend Launch Template

Launch Template 2: Frontend Launch Template

Step 10: Create Auto Scaling Groups

6.1 Nightly Orchestrator (`nightly.yml`)

6.2 Build and Push to ECR (`build.yml`)

6.3 Smoke Test on Temporary EC2 (`smoke-test.yml`)

6.4 Promote Image (`promote.yml`)

6.5 Deploy to QA EC2 (`deploy-qa.yml`)