DEV Community: Fidelis Ikoroje

My DevOps Portfolio Site Is Live – Built with Real Infrastructure, Real Tools

Fidelis Ikoroje — Sun, 03 Aug 2025 16:49:02 +0000

I finally built my portfolio website, and it is live! Built to reflect my DevOps expertise, cloud projects, and technical journey, this isn’t just another portfolio—it’s a real-world demonstration of modern infrastructure, automation, and best practices.

👉 Check it out here: Live Site

Why This Portfolio Stands Out

Most portfolios focus only on design, but mine goes further—it’s a fully automated, cloud-native project that highlights my DevOps and cloud engineering skills. Every component, from hosting to analytics, was built with scalability, security, and cost efficiency in mind.

Behind the Scenes: Tech Stack & Infrastructure

Frontend: Simple Yet Powerful

HTML5, CSS3, Vanilla JS – No bloated frameworks, just clean, fast code.
Mobile-first design – Flawless on any device.
SEO-optimized – Proper meta tags for better visibility.
Font Awesome icons – For a polished look.

AWS Cloud Architecture

The site runs on a highly available, low-cost AWS setup:

S3 – Static website hosting (cost-effective & reliable).
CloudFront – Global CDN with SSL/TLS for fast loading worldwide.
Route 53 – Secure DNS management.
ACM – Free SSL certificates for HTTPS.
Lambda + CloudWatch – Real-time log processing & monitoring.
Athena – Deep log analytics without third-party trackers.

DevOps & Automation

Terraform (IaC) – Entire infrastructure defined as code.
GitHub Actions CI/CD – Auto-deploys on git push to main.
Auto-destroy feature – Trigger infrastructure teardown with a commit keyword (great for testing).

Privacy-First Analytics (No Google Tracking!)

Instead of invasive trackers, I built my own GDPR-compliant analytics:
✔ CloudFront logs → Lambda → CloudWatch → Real-time metrics.
✔ 10+ key insights (visitors, page views, errors, geolocation).
✔ Athena for SQL-based log analysis – No external dependencies.

Key Features at a Glance

✅ Global performance (CloudFront CDN)
✅ Zero manual deployments (GitHub Actions CI/CD)
✅ Real-time privacy-safe analytics
✅ Mobile-optimized & SEO-friendly
✅ Direct CV download (PDF hosted securely on S3)
✅ Project showcase with case studies
✅ Cost-efficient (~$6-7/month for enterprise-grade infra)

Why This Matters

This project isn’t just a portfolio—it’s a working example of:

Infrastructure as Code (Terraform)
Automated CI/CD pipelines
Serverless cloud architecture
Security & compliance by design
Cost optimization in the cloud

What’s Your Favorite Feature?

I’d love to hear your thoughts! Which part of this setup do you find most interesting? Let me know in the comments!

Follow Me

Website: https://fidelis.fozdigitalz.com
LinkedIn: Connect with me
GitHub: See the full project code here

How to Install Amazon Q CLI on Windows

Fidelis Ikoroje — Wed, 30 Jul 2025 10:51:24 +0000

Amazon Q CLI is part of Amazon Q Developer, a powerful generative AI assistant that helps you build, troubleshoot, and understand code directly from your terminal. It integrates with your local development environment, enabling you to ask questions, generate boilerplate code, fix bugs, and even explain complex logic — all from the command line.

While Amazon Q is primarily available in the AWS Management Console and VS Code (via AWS Toolkit), you can also interact with it via the AWS CLI. Whether you're working in Python, JavaScript, Java, or other languages, Amazon Q is designed to boost your productivity as a developer.

In this guide, you’ll learn how to install and set up the Amazon Q Command Line Interface (CLI) on a Windows machine using a smooth and reliable process. Alternatively, I have included a video walkthrough of this installation and where I used Amazon Q Developer to build an arcade game.

Steps to Install Amazon Q CLI on Windows

Step 1. Install WSL ( Windows Subsystem for Linux)

Run the following command in PowerShell. wsl --install or wsl --distrubution Ubuntu enables the WSL feature on Windows. It enables the Virtual Machine Platform required for WSL and sets up Ubuntu by default, unless you specify another distro. The command is equivalent to dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart)

wsl --install

Note: The system will ask you to choose a username and password. Ensure you remember your password.

Step 2: Start Ubuntu in WSL

This command runs a Linux shell session inside Ubuntu, right from Windows

wsl -d Ubuntu

Step 3: Install unzip from your home directory

cd ~
sudo apt install unzip

Step 4: Download Amazon Q CLI Installer

curl --proto '=https' --tlsv1.2 -sSf "https://desktop-release.q.us-east-1.amazonaws.com/latest/q-x86_64-linux.zip" -o "q.zip"

Step 5: Unzip the Installer, Setup & Run

unzip q.zip
cd q
chmod +x install.sh
./install.sh

Step 6: Reload & login

Optionally reload the shell with updates path setting and use your AWS Builder ID credentials to log in to use AWS Q Developer free version.

bash
q login

Note: To use the Pro version of Amazon Q Developer, you need to have AWS IAM Identity Center configured, and ensure the user is subscribed to Amazon Q Developer under your AWS organization

Step 7: Start Amazon Q Developer

q chat

Tips for Using Amazon Q CLI

Run q in any project folder to start chatting with Amazon Q about your codebase.
You can ask things like: -- “Explain what this function does” -- “Fix this error” -- “Write a Python script to sort JSON data.”
Combine it with VS Code + WSL for a full AI-enhanced dev experience. Run the command below to use it in VS Code. Ensure you install the Microsoft WSL VS Code Extension.

mkdir -p ~/project/amazonq_game
cd ~/project/aws_amazonq_game
code .

🧠 Things to Know About Amazon Q CLI

Amazon Q CLI is still evolving — you may need to sign into your AWS account for access.
It supports multiple languages (Python, JavaScript, Java, TypeScript, etc.)
It works best when run inside your project folder
There are GUI versions too, but the CLI version is perfect for terminal lovers and power users

Video Guide

Game Development with Amazon Q CLI

✅ Conclusion

Installing Amazon Q CLI on Windows is straightforward once you have the right files and path setup. With the CLI installed, you get a smart AI pair programmer right inside your terminal. Whether you're building apps, debugging, or exploring unfamiliar code, Amazon Q helps you work faster and smarter — without leaving your shell.

Serverless Image Resizer on AWS

Fidelis Ikoroje — Sat, 14 Jun 2025 20:24:17 +0000

The Serverless Image Resizer is a cloud-native application that enables users to upload images and automatically resize them to predefined dimensions optimized for various social media platforms. Built on AWS serverless architecture, it provides a simple web interface for image management while handling the complex image processing behind the scenes.

The application offers a comprehensive set of features including:

📤 Secure image upload using pre-signed URLs
⚙️ One-click image resizing with predefined dimensions for popular social media platforms (Instagram, Facebook, X, LinkedIn, YouTube)
🤖 Automatic image processing using AWS Lambda
🔍 Modal-based Original Image Preview
📥 Download Resized Images
❌ Delete Images via API Gateway
🕓 Timestamps and File Size Display
🌍 CloudFront CDN integration for fast global content delivery
🔐 CORS-enabled API for secure cross-origin requests
🖼️ Responsive web interface with image preview and management capabilities

All of the above happens without managing any server - AWS services handle the scaling automatically.

Here, I'll walk you through how I built the solution using AWS services, including Lambda, S3, CloudFront, and API Gateway, all deployed with Terraform.

In order to keep the lenght of this article moderate, I kept the project configuration out of this post. Please find them in my Github Page.

Prerequisites

AWS Account with appropriate permissions
Node.js 18.x or later
Terraform 1.0 or later
AWS CLI configured with appropriate credentials
Domain name registered in Route 53
SSL certificate in AWS Certificate Manager

Project Structure

.
├── frontend/                    # Web interface files
│   ├── app.js                  # Frontend JavaScript application logic
│   └── index.html             # Main HTML interface
├── lambda/                     # AWS Lambda functions
│   ├── delete/                # Image deletion function
│   ├── list/                  # Image listing function
│   ├── presign/              # Pre-signed URL generation
│   └── resize/               # Image resizing function
└── terraform/                 # Infrastructure as Code
    ├── api_gateway.tf        # API Gateway configuration
    ├── cloudfront.tf         # CDN distribution setup
    ├── iam+s3.tf            # IAM roles and S3 bucket configuration
    ├── lambda.tf            # Lambda functions configuration
    ├── main.tf              # Main Terraform configuration
    ├── outputs.tf           # Output variables
    ├── route53.tf           # DNS configuration
    └── variables.tf         # Input variables

🧱 Architecture Overview

Frontend: HTML, Bootstrap, jQuery, and Handlebars.js
Storage: Amazon S3 (Original and Resized Buckets)
Compute: AWS Lambda for:
- Generating pre-signed URLs
- Resizing images using Sharp
- Listing images with metadata
- Deleting images
Routing: API Gateway
Delivery: CloudFront (backed by S3 for secure and fast access)
Security: IAM roles and bucket policies for fine-grained access control
Infrastructure Management:
- Defined via Terraform
- Deployed through GitHub Actions

🧩 The Development Process

1. Bucket Setup

I created three S3 buckets:

original-images-bucket-foz - Stores original image uploads
resized-images-bucket-foz - Stores Resized images
Image-resizer.fozdigitalz.com - Hosts the front end

With appropriate IAM roles and bucket policies to support Lambda functions and CloudFront delivery. Users can only access the original and resized buckets via CloudFront.

2. Frontend UI

Used Bootstrap for responsive layout.
Handlebars templates for dynamic image card rendering.
Modal for viewing original images.
Buttons to Load, Download, View, and Delete images.

Users can click "View Original" to open a Bootstrap modal. This dynamically loads the full-size original image via CloudFront.

I defined grouped resize sizes dynamically in JavaScript. Users can select any of these sizes from the front end.

const resizeOptionsGrouped = [
  {
    groupName: "Social Media Sizes",
    options: [
      { platform: "Instagram 📸", label: "Post", size: "1080x1080" },
      { platform: "Facebook 📘", label: "Shared Image", size: "1200x630" },
      { platform: "Twitter/X 🐦", label: "Summary", size: "1200x675" },
      { platform: "LinkedIn 💼", label: "Link Image", size: "1200x627" },
      { platform: "YouTube ▶️", label: "Thumbnail", size: "1280x720" }
    ]
  },
  {
    groupName: "Standard Sizes",
    options: [
      { platform: "Thumbnail 🗃️", label: "", size: "150x150" },
      { platform: "Medium", label: "", size: "640x480" },
      { platform: "Large", label: "", size: "800x600" },
      { platform: "Full HD", label: "", size: "1920x1080" }
    ]
  }
];

3. Backend: Serverless Power with API Gateway & Lambda

The backend orchestrates image processing through a seamless AWS serverless stack:

API Gateway: The Traffic Controller

Serves as the single entry point for all frontend requests
Configured with CORS to securely allow requests only from your frontend domain
Routes requests to specific Lambda functions based on path/verb:

  # Example route definition for Presigm Lambda in Terraform
  resource "aws_apigatewayv2_route" "presign_route" {
    api_id = aws_apigatewayv2_api.image_api.id
    route_key = "GET /presign"  # Routes to presign Lambda
    target    = "integrations/${aws_apigatewayv2_integration.presign_integration.id}"
  }

Lambda Functions: Specialized Workers

Four dedicated functions handle distinct tasks:

I. Presign Lambda

Generates secure S3 upload URLs with metadata

   const signedUrl = await getSignedUrl(s3, putCommand, { expiresIn: 300 });

II. Resize Lambda

Triggered by S3 upload events, uses sharp to resize image with fit: 'inside' and kernel: 'lanczos3' for quality.

   await sharp(imageBuffer).resize(width, height).toBuffer();

III. List Lambda

Returns all uploaded images for the UI gallery with file name timestamp, and size.

   const data = await s3.send(new ListObjectsV2Command({ Bucket: BUCKET_NAME }));

IV. Delete Lambda

Removes images from S3 when requested

   await s3.send(new DeleteObjectCommand({ Bucket: BUCKET_NAME, Key: fileName }));

4. CloudFront Distribution

I used Origin Access Control (OAC) to ensure only CloudFront can read from the buckets and an Ordered cache behaviors in CloudFront for different prefixes (/uploads/, /resized-*/uploads/). Also, I added 3 origins to my Cloudfront distribution - one for the S3 that hosts the frontend, one each for the bucket that keeps the original image upload, and the one that stores the resized images.

CI/CD with GitHub Actions

Deployed with a workflow triggered on push to main. My workflow can also be manually triggered to run or destroy my infrastructure using Terraform.

Applies Terraform
Syncs frontend files to the S3 bucket
Secrets like AWS credentials and hosted zone IDs are stored in GitHub Secrets

- name: Deploy Frontend to S3
  run: aws s3 sync ./frontend s3://image-resizer.fozdigitalz.com --delete

🌐 Live Project

Check the application with the URL below.

URL: https://image-resizer.fozdigitalz.com

How to Use the Application

Open the web app – Your browser loads files from CloudFront, which fetches them from a secure S3 bucket.
Select an image & size – Choose a file and a preset dimension (e.g., Instagram’s 1080x1080).
Request upload URL – The frontend gets a secure S3 upload link via API Gateway + Lambda.
Upload directly to S3 – Your browser sends the image to S3 using the generated link.
Auto-resize triggered – S3 detects the upload, fires a Lambda to resize with Sharp, and saves the result in a resized folder.
View/download images – Click "Load My Images" to see originals/resized versions, delivered via CloudFront and download the resized if you want.
Delete anytime – Hit delete, and a Lambda removes the file from S3.

✅ Results

Fully functional, scalable image upload and processing system
No need for EC2 or persistent servers
Dynamic resize and preview without exposing S3 directly
CloudFront accelerates delivery globally

🔭 Next Steps

My further enhancements for this project will include the following:

Auto-tagging via Amazon Rekognition
Auto-expiring unused images using lifecycle policies
Authentication using Cognito
Optimising storage costs with compression and format conversion (e.g., WebP)
Analytics for site users and image uploads.

🏁 Conclusion

This project was a powerful introduction to building production-grade serverless applications on AWS. With zero backend servers and minimal cost, it delivers a clean UX and powerful functionality — ideal for developers, startups, or any media-heavy app.

💬 Connect With Me

Feel free to star, fork, or clone the repository or build your own version.
Please drop your thoughts in the comment section
Reach out to me on LinkedIn

Deploying DeepSeek Model R1 on AWS via Terraform & GitHub Actions - Update

Fidelis Ikoroje — Thu, 13 Mar 2025 11:41:28 +0000

Hey there! In this project documentation, I’m going to walk you through how I deployed the DeepSeek Model R1 on AWS using Terraform and GitHub Actions. If you’ve ever tried deploying a machine learning model, you know it can get pretty complicated—especially when you’re juggling multiple AWS services. To make things easier, I decided to automate the whole process using Terraform for infrastructure as code and GitHub Actions for CI/CD. Spoiler alert: it worked like a charm!

This project involved setting up an EC2 instance, an Application Load Balancer (ALB), security groups, IAM roles, and even a custom domain using Route 53. The best part? Everything was automated, so I didn’t have to manually configure resources every time I made a change. Whether you’re a seasoned DevOps pro or just getting started with cloud deployments, I hope this walkthrough gives you some useful insights (and maybe saves you a few headaches along the way).

See the video below for the project breakdown and result

In this update, I’ve migrated my EC2 instance to a private subnet for improved security while still ensuring seamless access for application configuration and management. Here’s what changed compared to my first deployment:

✅ Private Subnet Deployment – The EC2 instance now runs in a private subnet instead of a public one.

✅ Internet Access via NAT Gateway – The instance can pull updates and dependencies while remaining inaccessible from the public internet.

✅ AWS Systems Manager (SSM) for Secure Access – Instead of SSH, I’m using SSM to manage and interact with the instance securely.

✅ AWS WAF for Backend Protection – Added AWS Web Application Firewall (WAF) to safeguard against malicious traffic and attacks.

This approach enhances security while maintaining full operational control over the deployment. Next steps? Further optimizing performance and security!

Introduction
Project Overview
Terraform Configuration
- Provider Configuration
- Security Groups
- Load Balancer (ALB)
- EC2 Instance
- IAM Roles and Instance Profile
- Route 53 DNS Record
- Terraform Backend (S3)
- AWS WAF Configuration
GitHub Actions Workflow
- Workflow Triggers
- Setup Job
- Apply Job
- Post-Apply Job
- Destroy Job
Challenges Faced
Lessons Learned
Future Improvements
Conclusion

1. Introduction

Deploying machine learning models in production can be a complex task, especially when it involves multiple AWS services. To streamline this process, I used Terraform to define the infrastructure as code and GitHub Actions to automate the deployment pipeline. This approach ensures consistency, scalability, and repeatability.

2. Project Overview

The goal of this project was to deploy the DeepSeek Model R1 on AWS, making it accessible via a web interface (OpenWebUI) and an API (Ollama). The infrastructure includes:

EC2 Instance: Hosts the DeepSeek model in a Docker container and associated services in a private subnet.
AWS Systems Manager (SSM): Provides secure connection to EC2 in private subnet via VPC Endpoints.
Application Load Balancer (ALB): Distributes traffic to the EC2 instance and handles SSL termination.
Security Groups: Control inbound and outbound traffic to the ALB and EC2 instance.
IAM Roles: Provide the necessary permissions for the EC2 instance to allow AWS Systems Manager Access
Route 53: Manages DNS records for the ALB. I just employed a cetificate I already have in us-east-1 and a ready public hosted zone in same region.
Terraform Backend: Stores the Terraform state file in an S3 bucket for team collaboration.
AWF: Protects the backend against bad requests

3. Terraform Configuration & Data

The Terraform configuration is the backbone of this project. It defines all the AWS resources required for the deployment. Below is a breakdown of the key components:

AWS Provider & VPC Configuration

The first step in the Terraform configuration is to define the AWS provider and specify the region:

provider "aws" {
  region = "us-east-1"
}

# Fetch existing VPC
data "aws_vpc" "main_vpc" {
  id = var.vpc_id
}

Security Groups

I created 3 security groups: one for the ALB and one for the EC2 instance and the last for the VPC endpoints. The ALB security group allows HTTPS traffic (port 443). The EC2 security group restricts traffic to only allow communication from the ALB on ports 8080 (OpenWebUI) and the security group of the VPC endpoints.

## Security Group for EC2 (Only ALB can access it)
resource "aws_security_group" "deepseek_ec2_sg" {
  name        = "deepseek_ec2_sg"
  description = "Security group for EC2 instance"
  vpc_id      = data.aws_vpc.main_vpc.id

  # Allow traffic from ALB 
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id]
  }

  ingress {
    from_port       = 11434
    to_port         = 11434
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id]
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

## Security Group for ALB (Allows direct access)
resource "aws_security_group" "alb_sg" {
  name        = "deepseek_alb_sg"
  description = "Security group for ALB"
  vpc_id      = data.aws_vpc.main_vpc.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

## Security Group for VPC Endpoints
resource "aws_security_group" "endpoint_sg" {
  name        = "vpc-endpoint-sg"
  description = "Security group for VPC Endpoints"
  vpc_id      = data.aws_vpc.main_vpc.id

  # Allow traffic from EC2 to VPC Endpoints
  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.deepseek_ec2_sg.id]
  }

  ingress {
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    security_groups = [aws_security_group.deepseek_ec2_sg.id]
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Load Balancer (ALB) & Listener

The ALB is configured to listen on ports 443 (HTTPS) and forwards traffic to the target group that has the EC2.

# Load Balancer
resource "aws_lb" "deepseek_lb" {
  name               = "deepseek-alb"
  internal           = false   # Public ALB
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = var.public_subnet_ids  # ALB must be in public subnets
}

## Listener for ALB (HTTPS) forwards traffic to OpenWebUI
resource "aws_lb_listener" "https_listener" {
  load_balancer_arn = aws_lb.deepseek_lb.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = var.certificate_arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.deepseek_tg.arn
  }
}

# Target Groups
resource "aws_lb_target_group" "deepseek_tg" {
  name     = "deepseek-target-group"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = data.aws_vpc.main_vpc.id

  health_check {
    path                = "/"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

EC2, IAM & VPC Endpoints

The EC2 instance is configured with a gp3 EBS volume (48GB) and an IAM role for necessary permissions. The instance is placed in a public subnet and associated with the EC2 security group. Note: An instance with GPU support like p3.2xlarge, g4dn.xlarge etc would do better here to handle bigger model and process responses faster but I didn't get one approved by AWS at the time of project execution. So, I used c4.4xlarge.

# IAM Role for SSM
resource "aws_iam_role" "ssm_role" {
  name = "EC2SSMRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
      Action = "sts:AssumeRole"
    }]
  })
}

# Attach AmazonSSMManagedInstanceCore policy
resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# IAM Instance Profile
resource "aws_iam_instance_profile" "ssm_instance_profile" {
  name = "EC2SSMInstanceProfile"
  role = aws_iam_role.ssm_role.name
}

# EC2 Instance
resource "aws_instance" "deepseek_ec2" {
  ami                  = var.ami_id
  instance_type        = var.instance_type
  subnet_id            = var.private_subnet_ids[0]
  security_groups      = [aws_security_group.deepseek_ec2_sg.id]
  iam_instance_profile = aws_iam_instance_profile.ssm_instance_profile.name

  root_block_device {
    volume_size           = 48
    volume_type           = "gp3"
    delete_on_termination = true
  }

  tags = {
    Name = "DeepSeekModelInstance"
  }
}

# Attach EC2 Instance to Target Group
resource "aws_lb_target_group_attachment" "deepseek_tg_attachment" {
  target_group_arn = aws_lb_target_group.deepseek_tg.arn
  target_id        = aws_instance.deepseek_ec2.id
  port             = 8080
}

# VPC Endpoints for SSM
resource "aws_vpc_endpoint" "ssm" {
  vpc_id            = data.aws_vpc.main_vpc.id
  service_name      = "com.amazonaws.us-east-1.ssm"
  vpc_endpoint_type = "Interface"
  subnet_ids        = var.private_subnet_ids
  security_group_ids = [aws_security_group.endpoint_sg.id]
  private_dns_enabled = true
}


# VPC Endpoint for EC2 Messages (Used by SSM)
resource "aws_vpc_endpoint" "ec2_messages" {
  vpc_id            = data.aws_vpc.main_vpc.id
  service_name      = "com.amazonaws.us-east-1.ec2messages"
  vpc_endpoint_type = "Interface"
  subnet_ids        = var.private_subnet_ids
  security_group_ids = [aws_security_group.endpoint_sg.id]
  private_dns_enabled = true
}

# VPC Endpoint for SSM Messages (Used by SSM)
resource "aws_vpc_endpoint" "ssm_messages" {
  vpc_id            = data.aws_vpc.main_vpc.id
  service_name      = "com.amazonaws.us-east-1.ssmmessages"
  vpc_endpoint_type = "Interface"
  subnet_ids        = var.private_subnet_ids
  security_group_ids = [aws_security_group.endpoint_sg.id]
  private_dns_enabled = true
}

Route 53 DNS Record

A Route 53 DNS record is created to map the ALB’s DNS name to a custom domain. Like I mentioned above, I used an already existing certificate to enable SSL and I also employed an existing hosted zone in us-east-1.

resource "aws_route53_record" "deepseek_dns" {
  zone_id = var.hosted_zone_id
  name    = "deepseek.fozdigitalz.com"
  type    = "A"

  alias {
    name                   = aws_lb.deepseek_lb.dns_name
    zone_id                = aws_lb.deepseek_lb.zone_id
    evaluate_target_health = true
  }
}

AWS WAF Configuration

#AWS Web Application Firewall
resource "aws_wafv2_web_acl" "deepseek_waf" {
  name        = "deepseek-waf"
  description = "WAF for ALB protecting backend"
  scope       = "REGIONAL"

  default_action {
    allow {}
  }

  # Rate Limiting Rule
  rule {
    name     = "RateLimitRule"
    priority = 1

    action {
      block {}
    }

    statement {
      rate_based_statement {
        limit              = 150
        aggregate_key_type = "IP"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimit"
      sampled_requests_enabled   = true
    }
  }

# Amazon IP Reputation List (Blocks known bad IPs, reconnaissance, DDoS)
  rule {
    name     = "AmazonIPReputationRule"
    priority = 2

    override_action { 
      none {} 
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesAmazonIpReputationList"

        # OPTIONAL: Override specific rules inside the group
        rule_action_override {
          action_to_use {
            block {}
          }
          name = "AWSManagedIPReputationList"
        }

        rule_action_override {
          action_to_use {
            block {}
          }
          name = "AWSManagedReconnaissanceList"
        }

        rule_action_override {
          action_to_use {
            count {}
          }
          name = "AWSManagedIPDDoSList"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AmazonIPReputationRule"
      sampled_requests_enabled   = true
    }
  } 

# AWS Managed Known Bad Inputs Rule Set
  rule {
    name     = "KnownBadInputsRule"
    priority = 3

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesKnownBadInputsRuleSet"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "KnownBadInputsRule"
      sampled_requests_enabled   = true
    }
  }

# AWS Managed Common Rule Set
rule {
  name     = "CommonRuleSet"
  priority = 4

  override_action {
    none {}  # Ensures AWS WAF applies its built-in block actions
  }

  statement {
    managed_rule_group_statement {
      vendor_name = "AWS"
      name        = "AWSManagedRulesCommonRuleSet"

      # Override specific rules that are set to "Count" by default, so they actually block bad traffic.
      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_URIPATH_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_BODY_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_QUERYARGUMENTS_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_COOKIE_RC_COUNT"
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "CommonRuleSet"
    sampled_requests_enabled   = true
  }
}

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "deepseek-waf"
    sampled_requests_enabled   = true
  }
}

#WAF Attachment to ALB
resource "aws_wafv2_web_acl_association" "deepseek_waf_alb" {
  resource_arn = aws_lb.deepseek_lb.arn
  web_acl_arn  = aws_wafv2_web_acl.deepseek_waf.arn
  depends_on = [aws_lb.deepseek_lb,
  aws_wafv2_web_acl.deepseek_waf
  ]
}

Terraform Backend (S3)

The Terraform state file is stored in an S3 bucket to enable team collaboration and state management.

terraform {
  backend "s3" {
    bucket         = "foz-terraform-state-bucket"
    key            = "infra.tfstate"
    region         = "us-east-1"
    encrypt        = true
  }
}

Variables Configuration

The variables.tf file defines all the input variables required for the Terraform configuration. These variables make the configuration reusable and customizable.

variable "vpc_id" {
  description = "The VPC ID where resources will be deployed"
  type        = string
}

variable "public_subnet_ids" {
  description = "List of public subnet IDs for ALB"
  type        = list(string)
}

variable "private_subnet_ids" {
  description = "List of private subnet IDs for EC2 instances"
  type        = list(string)
}

variable "ami_id" {
  description = "AMI ID for the EC2 instance"
  type        = string
}

variable "instance_type" {
  description = "Instance type for the EC2 instance"
  type        = string
}

variable "certificate_arn" {
  description = "ARN of the SSL certificate for HTTPS"
  type        = string
}

variable "hosted_zone_id" {
  description = "Route 53 hosted zone ID for the domain"
  type        = string
}

Terraform.tfvars

The terraform.tfvars file is used to assign values to the variables defined in variables.tf. This file is typically not committed to version control (e.g., Git) for security reasons, as it may contain sensitive information like AWS credentials. I added terraform.tfvars to .gitignore so it won't be tracked. I provided the variables and secrets in github using environment variables and secrets. Also, the values below are made up and not real.

vpc_id = "vpc-012345678910"
private_subnet_ids = ["subnet-0012345678910", "subnet-0012345678910", "subnet-0012345678910"]
instance_type = "c4.4xlarge" # bigger for production but t2.2xlarge test
ami_id = "ami-04b4f1a9cf54c11d0"
certificate_arn   = "arn:aws:acm:us-east-1:012345678910:certificate/697cf89b-9931-435f-a5f0-c8f012345678910c"
hosted_zone_id    = "Z012345678960X9UZZVPUYYW0H"
public_subnet_ids = ["subnet-0012345678910","subnet-012345678910"]

Output Configuration

The output.tf file defines the outputs that Terraform will display after applying the configuration. I used these outputs for retrieving information like the EC2 instance’s public IP or the ALB’s DNS name that are needed for my Github Action workflow to configure my EC2 instances.

output "ec2_public_ip" {
  description = "Public IP of the EC2 instance"
  value       = aws_instance.deepseek_ec2.public_ip
}

output "lb_url" {
  description = "DNS name of the ALB"
  value       = aws_lb.deepseek_lb.dns_name
}

output "deepseek_ec2_sg_id" {
  value = aws_security_group.deepseek_ec2_sg.id
}

output "deepseek_ec2_id" {
  value = aws_instance.deepseek_ec2.id
}

4. GitHub Actions Workflow

The GitHub Actions workflow automates the deployment process. It consists of four main jobs: setup, apply, post-apply, and destroy. My workflow will be triggered by pushing to the main branch or manually through the GitHub UI using workflow dispatch with an input to choose the action (apply/destroy).

Workflow Triggers

The workflow is triggered on a push to the main branch or manually via the workflow_dispatch event. The manual trigger allows you to choose between apply (to create resources) and destroy (to tear down resources).

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      action:
        description: "Choose action (apply/destroy)"
        required: true
        default: "apply"
        type: choice
        options:
          - apply
          - destroy

Setup Job

The setup job initializes the environment by checking out the code, setting up Terraform, and configuring AWS credentials.

name: Deploying DeepSeek Model R1 on AWS via Terraform & GitHub Actions

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      action:
        description: "Choose action (apply/destroy)"
        required: true
        default: "apply"
        type: choice
        options:
          - apply
          - destroy

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

Apply Job

The apply job runs Terraform to create the infrastructure. It generates a terraform.tfvars file using GitHub Secrets, initializes Terraform, and applies the configuration. This is where my Github Actions Runner SSH into my EC2 to install docker, pulls the images and deploy Ollama and OpenWebUIusing Docker.

  apply:
    runs-on: ubuntu-latest
    outputs:
      ec2_instance_id: ${{ steps.get_ec2_id.outputs.ec2_id }}
    needs: setup
    if: |
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'apply') ||
      (github.event_name == 'push' && !contains(github.event.head_commit.message, 'destroy'))
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform.tfvars
          ami_id = "${{ secrets.AMI_ID }}"
          certificate_arn = "${{ secrets.CERTIFICATE_ARN }}"
          vpc_id = "${{ secrets.VPC_ID }}"
          hosted_zone_id = "${{ secrets.HOSTED_ZONE_ID }}"
          instance_type = "${{ secrets.INSTANCE_TYPE }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          public_subnet_ids = ${{ secrets.PUBLIC_SUBNET_IDS }}
          private_subnet_ids = ${{ secrets.PRIVATE_SUBNET_IDS }}
          EOF

      - name: Mask AWS Account ID in Logs
        run: echo "::add-mask::${{ secrets.AWS_ACCOUNT_ID }}"

      - name: Terraform Init & Apply
        run: |
          terraform init \
            -backend-config="bucket=${{ secrets.TERRAFORM_STATE_BUCKET }}" \
            -backend-config="key=infra.tfstate" \
            -backend-config="region=${{ secrets.AWS_DEFAULT_REGION }}"
          terraform apply -auto-approve -var-file=terraform.tfvars

      - name: Retrieve EC2 Instance ID
        id: get_ec2_id
        run: |
          echo "Retrieving EC2 Instance ID..."
          EC2_ID=$(terraform output -raw deepseek_ec2_id)
          echo "EC2_INSTANCE_ID=$EC2_ID" >> $GITHUB_ENV
          echo "::set-output name=ec2_id::$EC2_ID"


      - name: Verify EC2 Instance ID
        run: |
          echo "EC2_INSTANCE_ID=${{ env.EC2_INSTANCE_ID }}"
          if [ -z "${{ env.EC2_INSTANCE_ID }}" ]; then
            echo "EC2 instance ID is empty or invalid."
            exit 1
          fi

      - name: Wait for EC2
        run: sleep 60

Post-Apply Job

The post-apply job configures the EC2 instance after Terraform provisions it. It verifies the instance's connection via AWS SSM, checks if the SSM agent is running, and installs Docker along with necessary dependencies. After rebooting the instance, it deploys the DeepSeek Model R1 inside an Ollama container and sets up Open WebUI for interaction. Finally, it confirms that the WebUI is accessible via https://deepseek.fozdigitalz.com. This ensures a fully automated deployment of the model and web interface on AWS.

  post_apply:
    runs-on: ubuntu-latest
    needs: apply
    if: success()
    env:
      EC2_INSTANCE_ID: ${{ needs.apply.outputs.ec2_instance_id }}
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}


      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform.tfvars
          ami_id = "${{ secrets.AMI_ID }}"
          certificate_arn = "${{ secrets.CERTIFICATE_ARN }}"
          vpc_id = "${{ secrets.VPC_ID }}"
          hosted_zone_id = "${{ secrets.HOSTED_ZONE_ID }}"
          instance_type = "${{ secrets.INSTANCE_TYPE }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          public_subnet_ids = ${{ secrets.PUBLIC_SUBNET_IDS }}
          private_subnet_ids = ${{ secrets.PRIVATE_SUBNET_IDS }}
          EOF

      - name: Verify SSM Connection
        run: |
          echo "Verifying SSM Connection..."
          aws ssm describe-instance-information --region ${{ secrets.AWS_DEFAULT_REGION }} \
            --query "InstanceInformationList[?InstanceId=='${{ env.EC2_INSTANCE_ID }}']" \
            --output json

      - name: Check SSM Agent Status
        run: |
          aws ssm send-command \
            --document-name "AWS-RunShellScript" \
            --instance-ids "${{ env.EC2_INSTANCE_ID }}" \
            --parameters '{"commands":["sudo systemctl status amazon-ssm-agent"]}' \
            --region ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Install Docker via SSM
        run: |
          aws ssm send-command \
            --document-name "AWS-RunShellScript" \
            --targets "[{\"Key\":\"InstanceIds\",\"Values\":[\"${{ env.EC2_INSTANCE_ID }}\"]}]" \
            --parameters commands='[
              "sudo apt-get update",
              "sudo apt-get install -y docker.io docker-compose",
              "sudo systemctl enable docker",
              "sudo systemctl start docker",
              "sudo usermod -aG docker ubuntu",
              "sudo sed -i s/^ENABLED=1/ENABLED=0/ /etc/apt/apt.conf.d/20auto-upgrades",
              "sleep 10",
              "sudo reboot"
            ]' \
            --region ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Wait for EC2 instance to reboot ..."
        run: sleep 50

      - name: Run DeepSeek Model and WebUI via SSM
        run: |
          aws ssm send-command \
            --document-name "AWS-RunShellScript" \
            --targets "[{\"Key\":\"InstanceIds\",\"Values\":[\"${{ env.EC2_INSTANCE_ID }}\"]}]" \
            --parameters commands='[
              "docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama",
              "sleep 20",
              "docker exec ollama ollama pull deepseek-r1:8b",
              "sleep 15",
              "docker exec -d ollama ollama serve",
              "sleep 15",
              "docker run -d -p 8080:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main",
              "sleep 15"
            ]' \
            --region ${{ secrets.AWS_DEFAULT_REGION }}

          echo "Waiting for WebUI to start..."
          sleep 30              

      - name: Confirm WebUI is Running
        run: |
          aws ssm send-command \
            --document-name "AWS-RunShellScript" \
            --targets '[{"Key":"instanceIds","Values":["${{ env.EC2_INSTANCE_ID }}"]}]' \
            --parameters '{"commands":["curl -I https://deepseek.fozdigitalz.com"]}' \
            --region ${{ secrets.AWS_DEFAULT_REGION }}

Destroy Job

The destroy job tears down the infrastructure when triggered manually or via a commit message containing "destroy".

  destroy:
    runs-on: ubuntu-latest
    needs: setup
    if: |
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'destroy') ||
      (github.event_name == 'push' && contains(github.event.head_commit.message, 'destroy'))
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform.tfvars
          ami_id = "${{ secrets.AMI_ID }}"
          certificate_arn = "${{ secrets.CERTIFICATE_ARN }}"
          vpc_id = "${{ secrets.VPC_ID }}"
          hosted_zone_id = "${{ secrets.HOSTED_ZONE_ID }}"
          instance_type = "${{ secrets.INSTANCE_TYPE }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          public_subnet_ids = ${{ secrets.PUBLIC_SUBNET_IDS }}
          private_subnet_ids = ${{ secrets.PRIVATE_SUBNET_IDS }}
          EOF

      - name: Mask AWS Account ID in Logs
        run: echo "::add-mask::${{ secrets.AWS_ACCOUNT_ID }}"

      - name: Terraform Destroy
        run: |
          terraform init -reconfigure \
            -backend-config="bucket=${{ secrets.TERRAFORM_STATE_BUCKET }}" \
            -backend-config="key=infra.tfstate" \
            -backend-config="region=${{ secrets.AWS_DEFAULT_REGION }}"
          terraform destroy -auto-approve -var-file=terraform.tfvars

Completed workflow run

5. The Application in Action (Result)

After successfully deploying the DeepSeek Model R1 on AWS, I was able to access the OpenWebUI and interact with the model. Below are some screenshots demonstrating the setup and functionality:

1. OpenWebUI Interface

The OpenWebUI provides a user-friendly interface for interacting with the DeepSeek Model R1. Here’s a screenshot of the dashboard:

The OpenWebUI dashboard, accessible via the custom domain deepseek.fozdigitalz.com.

2. Model Interaction

I tested the model by asking it a few questions. Here’s an example of the model’s response:

Sample model response 11
The DeepSeek Model R1 generating a response to a sample query.

Sample model response 12

Sample model response 21

Sample model response 22

3. Infrastructure Clean Up

I can destroy my infrastructure when I trigger my workflow in different ways. My workflow will be triggered by pushing to the main branch or manually through the GitHub UI using workflow dispatch with an input to choose the action (apply/destroy).

By manually triggering the workflow from the GitHub UI and selecting the destroy action.
By pushing to the main branch with a commit message that contains the word destroy.
By running the command gh workflow run "workflow name" --field action=destroy locally but you must have the Github CLI installed for this to work.

Infrastructure cleanup using terraform

6. Challenges Faced & Lesson Learned

Learning from the challenges in my first deployment, modifying the setup was easier—I moved the EC2 instance to a private subnet, switched from SSH to AWS SSM for secure access, and integrated AWS WAF for better protection. However, I still researched best practices for implementing AWS-managed WAF rules to enhance security effectively.

7. Future Improvements

While the deployment process is now functional, there are opportunities I may consider to enhance scalability, security, and cost-efficiency.

In my first deployment, I considered improvements like moving EC2 to a private subnet, using SSM instead of SSH, and adding WAF, which I have now implemented. Additionally, I’m exploring CloudWatch for monitoring, auto-scaling for better resource management, and GPU instances for enhanced performance, though AWS approval for GPU is still pending. These refinements aim to make the deployment more secure, scalable, and cost-efficient.

8. Conclusion

This deployment has evolved significantly from the initial setup, incorporating better security, automation, and scalability based on lessons learned. Moving EC2 to a private subnet, using AWS SSM instead of SSH, and integrating AWS WAF has strengthened security, while CloudWatch and auto-scaling are now key considerations for future improvements. As I continue refining the architecture, I’m also exploring GPU-powered instances for better performance once AWS approval is granted. These enhancements ensure a more resilient, efficient, and secure deployment of the DeepSeek Model R1 on AWS.

Hosting a Serverless Resume Website on AWS with Terraform and CI/CD

Fidelis Ikoroje — Mon, 03 Mar 2025 18:26:55 +0000

Building a serverless resume website on AWS isn’t just about hosting a static page. It is like assembling a high-performance engine. When I decided to create my resume website, I wanted it to be more than just a digital placeholder—it had to be scalable, secure, and cost-efficient.

Each component—S3, CloudFront, Lambda, DynamoDB, API Gateway, Route53+DNSSEC to Monitoring tools and AWS WAF—plays a critical role, while Terraform and GitHub Actions CI/CD act as the control systems, ensuring everything runs smoothly. Along the way, I encountered several challenges at different stages, from infrastructure setup to automation, and documented my approach to resolving them. The result? A scalable, secure, and cost-efficient website. Let’s take a closer look under the hood!

Project Overview

The goal of this project was to enhance the accessibility and visibility of my resume by hosting it as a responsive website. The website is built using serverless technologies, ensuring minimal operational overhead and maximum scalability. Here’s a high-level breakdown of the architecture:

Terraform Configuration

I. Provider, Identity Configuration + Terraform State Management: Terraform version specified while AWS S3 stores Terraform state.

II. Frontend: A static HTML resume hosted on Amazon S3 and served via CloudFront for global content delivery.

III. Backend: A serverless REST API built with AWS Lambda and API Gateway to handle dynamic functionality & DynamoDB to store visitor count.

IV. Monitoring and Alerts: CloudWatch, SNS, PagerDuty, and Slack for monitoring and notifications.

V. Security & DNS: AWS WAF, Route53 & DNSSEC WAF to protect the website from common web exploits while Route53 for DNS management and DNSSEC for enhanced domain security.

Code Test+ CI/CD: Automated deployment pipeline using GitHub Actions.
End-to-End Test: Automated test of site functionality and app backend using Cypress.
Results: The resume website is globally available, secure, and scalable. The visitor count updates dynamically via the backend, and CloudWatch monitors API health. CI/CD ensures quick updates with automated testing, improving reliability.
Conclusion: Summary of the project and lessons learnt.

1. Terraform Configuration

The entire infrastructure is defined using Terraform (Infrastructure as Code), ensuring reproducibility and scalability. Below is a detailed explanation of the Terraform configuration. Note: You can find all configuration files in my Github.

I. Provider Block & Terraform State Management

The configuration uses Amazon S3 for centralized state management, storing the infrastructure.tfstate file in the foz-terraform-state-bucket with encryption enabled. The AWS provider (version >= 5.8.0) is configured for deployment in the us-east-1 region, and the Terraform version is set to >= 1.10.3. Additionally, the aws_caller_identity data resource retrieves information about the currently authenticated AWS account. This setup ensures secure, reliable state management and deployment configuration.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.8.0"
    }
  }
  required_version = ">= 1.10.3"
}

provider "aws" {
  region = "us-east-1" # Set the deployment region
}
# Declare the caller identity data resource
data "aws_caller_identity" "current" {}

#Terraform Backend (S3 for State Management)
terraform {
  backend "s3" {
    bucket  = "foz-terraform-state-bucket"
    key     = "infrastructure.tfstate"
    region  = "us-east-1"
    encrypt = true
  }
}

II. Frontend: S3 & CloudFront

The frontend consists of a static HTML file hosted on an S3 bucket and served via CloudFront. The bucket is configured with versioning, CORS, and a policy to allow access only via CloudFront. Terraform uses template_file to replace the API-Gateway invocation URL place holder in the script on my html document with the real URL once API-Gateway is created & deployed. Once that is done, terraform copies the html to the s3 bucket.

S3, Policy & CORS

# S3 bucket for static website
resource "aws_s3_bucket" "cloud_resume_bucket" {
  bucket        = var.bucket_name
  force_destroy = true

  tags = {
    Name        = "Cloud Resume Bucket"
    Environment = "Production"
  }
}

# Enable versioning on S3 bucket
resource "aws_s3_bucket_versioning" "cloud_resume_versioning" {
  bucket = aws_s3_bucket.cloud_resume_bucket.id

  versioning_configuration {
    status = "Enabled"
  }
}

# S3 bucket CORS configuration
resource "aws_s3_bucket_cors_configuration" "cloud_resume_bucket_cors" {
  bucket = aws_s3_bucket.cloud_resume_bucket.id

  cors_rule {
    allowed_methods = ["GET", "HEAD"]
    allowed_origins = ["https://fidelis-resume.fozdigitalz.com"] # Replace with your domain
    allowed_headers = ["*"]
    max_age_seconds = 3000
  }
}

# S3 bucket policy for CloudFront access
resource "aws_s3_bucket_policy" "cloud_resume_policy" {
  bucket = aws_s3_bucket.cloud_resume_bucket.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Sid    = "AllowCloudFrontAccess",
        Effect = "Allow",
        Principal = {
          Service = "cloudfront.amazonaws.com"
        },
        Action   = "s3:GetObject",
        Resource = "${aws_s3_bucket.cloud_resume_bucket.arn}/*",
        Condition = {
          StringEquals = {
            "AWS:SourceArn" = "arn:aws:cloudfront::${data.aws_caller_identity.current.account_id}:distribution/${aws_cloudfront_distribution.cloud_resume_distribution.id}"
          }
        }
      }
    ]
  })
}

# Read and replace placeholder in the HTML file dynamically
data "template_file" "cloud_resume_html" {
  template = file("${path.module}/cloud-resume.html")

  vars = {
    api_gateway_url = "https://${aws_api_gateway_rest_api.cloud_resume_api.id}.execute-api.${var.region}.amazonaws.com/${aws_api_gateway_stage.cloud_resume_stage.stage_name}"
  }
}

# Upload the updated HTML file to S3 after API Gateway is created
resource "aws_s3_object" "cloud_resume_html" {
  bucket              = aws_s3_bucket.cloud_resume_bucket.id
  key                 = "cloud-resume.html"
  content             = data.template_file.cloud_resume_html.rendered
  content_type        = "text/html"
  content_disposition = "inline"

  depends_on = [aws_api_gateway_stage.cloud_resume_stage]

  tags = {
    Name        = "Cloud Resume HTML"
    Environment = "Production"
  }
}

CloudFront Distribution

#Cloudfront Origin Access Control (OAC)
resource "aws_cloudfront_origin_access_control" "cloud_resume_oac" {
  name                              = "cloud-resume-oac"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

# CloudFront distribution
resource "aws_cloudfront_distribution" "cloud_resume_distribution" {
  web_acl_id = aws_wafv2_web_acl.cloudfront_waf.arn # Attach WAF to CloudFront

  origin {
    domain_name = aws_s3_bucket.cloud_resume_bucket.bucket_regional_domain_name
    origin_id   = "S3-cloud-resume-origin"

    origin_access_control_id = aws_cloudfront_origin_access_control.cloud_resume_oac.id
  }

  enabled             = true
  default_root_object = "cloud-resume.html"

  aliases = [var.domain_name] # Custom domain name

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3-cloud-resume-origin"

    viewer_protocol_policy = "redirect-to-https"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  # Viewer certificate for HTTPS
  viewer_certificate {
    acm_certificate_arn      = var.acm_certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2019"
  }

  # Restrictions block to meet CloudFront requirements
  restrictions {
    geo_restriction {
      restriction_type = "none" #Allows requests from all geographic locations
    }
  }
}

Challenges & Strategies

CORS setting was my major challenge here as browsers were blocking requests to S3 bucket due to incorrect CORS headers. I checked AWS documentation & used browser developers tools to debug and setup cache invalidation as Cloudfront was still serving old contents even though my CORS is now updated. For HTTPS & custom domain, I followed AWS best practices to set up ACM and Route 53, ensuring a secure and reliable custom domain setup.

III. Backend: Lambda, DynamoDB, and API Gateway

The Lambda function handles the logic for retrieving and incrementing the visitor count, with environment variables passing the DynamoDB table name. The DynamoDB table stores the visitor count using a primary key id, while API Gateway exposes my Visitor_Counter Lambda function as a REST API, integrating it seamlessly for dynamic functionality.

Lambda Function for Visitor Count

# Lambda function for visitor count
resource "aws_lambda_function" "visitor_counter" {
  filename         = "visitor_counter_lambda.zip" # Prebuilt zip with your Python code
  function_name    = "VisitorCounter"
  role             = aws_iam_role.lambda_exec.arn
  handler          = "visitor_counter_lambda.lambda_handler"
  runtime          = "python3.9"
  source_code_hash = filebase64sha256("visitor_counter_lambda.zip")

  environment {
    variables = {
      DYNAMODB_TABLE = aws_dynamodb_table.visitor_count.name
    }
  }
}

# IAM Role for Lambda
resource "aws_iam_role" "lambda_exec" {
  name = "lambda_exec_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Effect = "Allow",
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}


# Custom IAM Policy for Lambda to interact with DynamoDB & write to Cloudwatch logs
resource "aws_iam_policy" "lambda_policy" {
  name = "lambda_dynamodb_cloudwatch_policy"

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:UpdateItem",
          "dynamodb:Query",
          "dynamodb:Scan"
        ],
        Resource = "arn:aws:dynamodb:*:*:table/${aws_dynamodb_table.visitor_count.name}"
      },
      {
        Effect = "Allow",
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ],
        Resource = "arn:aws:logs:*:*:*"
      }
    ]
  })
}

# Attach policy to lambda
resource "aws_iam_role_policy_attachment" "lambda_policy_attachment" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = aws_iam_policy.lambda_policy.arn
}

DynamoDB Table

# DynamoDB table for visitor count
resource "aws_dynamodb_table" "visitor_count" {
  name           = "VisitorCount"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

API-Gateway Integration

# REST API Resource
resource "aws_api_gateway_rest_api" "cloud_resume_api" {
  name        = "CloudResumeAPI"
  description = "API for visitor counter"
}

# Root Resource ("/")
resource "aws_api_gateway_resource" "visitors" {
  rest_api_id = aws_api_gateway_rest_api.cloud_resume_api.id
  parent_id   = aws_api_gateway_rest_api.cloud_resume_api.root_resource_id
  path_part   = "visitors"
}

# API Gateway Method
resource "aws_api_gateway_method" "get_visitors" {
  rest_api_id   = aws_api_gateway_rest_api.cloud_resume_api.id
  resource_id   = aws_api_gateway_resource.visitors.id
  http_method   = "GET"
  authorization = "NONE"
}

# API Gateway Integration with Lambda
resource "aws_api_gateway_integration" "lambda_integration" {
  rest_api_id             = aws_api_gateway_rest_api.cloud_resume_api.id
  resource_id             = aws_api_gateway_resource.visitors.id
  http_method             = aws_api_gateway_method.get_visitors.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.visitor_counter.invoke_arn
}

# Enable CORS for API Gateway- API Method Response
resource "aws_api_gateway_method_response" "cors_response" {
  rest_api_id = aws_api_gateway_rest_api.cloud_resume_api.id
  resource_id = aws_api_gateway_resource.visitors.id
  http_method = aws_api_gateway_method.get_visitors.http_method
  status_code = "200"

  response_parameters = {
    "method.response.header.Access-Control-Allow-Origin"  = true
    "method.response.header.Access-Control-Allow-Methods" = true
    "method.response.header.Access-Control-Allow-Headers" = true
  }
}

#API Gateway Integration Response
resource "aws_api_gateway_integration_response" "cors_integration_response" {
  rest_api_id = aws_api_gateway_rest_api.cloud_resume_api.id
  resource_id = aws_api_gateway_resource.visitors.id
  http_method = aws_api_gateway_method.get_visitors.http_method
  status_code = aws_api_gateway_method_response.cors_response.status_code

  response_parameters = {
    "method.response.header.Access-Control-Allow-Origin"  = "'https://fidelis-resume.fozdigitalz.com'"
    "method.response.header.Access-Control-Allow-Methods" = "'GET,OPTIONS'"
    "method.response.header.Access-Control-Allow-Headers" = "'*'"
  }

  depends_on = [aws_api_gateway_integration.lambda_integration]
}

# API Gateway Deployment Stage with Throttling
resource "aws_api_gateway_deployment" "cloud_resume_deployment" {
  rest_api_id = aws_api_gateway_rest_api.cloud_resume_api.id

  depends_on = [
    aws_api_gateway_integration.lambda_integration,
    aws_api_gateway_method.get_visitors,
    aws_api_gateway_method_response.cors_response
  ]
}

#API Gateway Stage 
resource "aws_api_gateway_stage" "cloud_resume_stage" {
  deployment_id = aws_api_gateway_deployment.cloud_resume_deployment.id
  rest_api_id   = aws_api_gateway_rest_api.cloud_resume_api.id
  stage_name    = "prod"

  access_log_settings {
    destination_arn = aws_cloudwatch_log_group.api_gateway_log_group.arn  
    format = jsonencode({
      requestId       = "$context.requestId"
      ip              = "$context.identity.sourceIp"
      requestTime     = "$context.requestTime"
      httpMethod      = "$context.httpMethod"
      resourcePath    = "$context.resourcePath"
      status          = "$context.status"
      responseLength  = "$context.responseLength"
    })
  }

  tags = {
    Environment = "Production"
  }

  depends_on = [
    aws_api_gateway_account.api_logging,
    aws_cloudwatch_log_group.api_gateway_log_group
    ] 
}

#Enabled Logging & detailed Metrics for API Gateway Stage
resource "aws_api_gateway_method_settings" "cloud_resume_metrics" {
  rest_api_id = aws_api_gateway_rest_api.cloud_resume_api.id
  stage_name  = aws_api_gateway_stage.cloud_resume_stage.stage_name

  method_path = "visitors/GET"
  settings {
    metrics_enabled    = true
    data_trace_enabled = true
    logging_level      = "ERROR"
  }
}

# Permission for API Gateway to invoke Lambda
resource "aws_lambda_permission" "allow_apigateway" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.visitor_counter.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.cloud_resume_api.execution_arn}/*/*"
}

#Grant API Gateway Permissions to Write to CloudWatch Logs
resource "aws_iam_role" "api_gw_cloudwatch_role" {
  name = "APIGatewayCloudWatchLogsRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Service = "apigateway.amazonaws.com"
      }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy_attachment" "api_gw_logging_policy" {
  name       = "ApiGatewayLoggingPolicy"
  roles      = [aws_iam_role.api_gw_cloudwatch_role.name]
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs"
}

#Attach the IAM Role to API Gateway
resource "aws_api_gateway_account" "api_logging" {
  cloudwatch_role_arn = aws_iam_role.api_gw_cloudwatch_role.arn
}

Challenges & Strategies

I spent time here writing the Lambda Function code that checks DynamoDB table, retreive the count and updates it. My function needed a paramenter to recognise a unique visitor. I tried Browser LocalStorage but it increments count when I refresh the page on thesame browser. I also tried Session and Cookie until I settled for IP address. My function stores the hash of unique IPs in my DynamoDB table to check unique visitors. The hash is a One-Way process, so I can't see the IPs and I can't recover them from the hashes. I ran Postman to test my API-Gateway and fixed permission issues not allowing API-Gatway to invoke my Lambda.

IV. Monitoring and Alerts

In this section of the project, I set up comprehensive monitoring and alerting using AWS CloudWatch, SNS, PagerDuty, and Slack to ensure timely responses to issues. I created a CloudWatch alarm to monitor API Gateway errors, triggering notifications through SNS when certain thresholds are met. I also configured an SNS topic to handle notifications and a policy to restrict publishing to CloudWatch only. For incident management, I integrated PagerDuty to alert on critical issues and used AWS Lambda to forward messages to PagerDuty. Additionally, I set up Slack integration to notify the team in real-time via a Lambda function that listens to the SNS topic, ensuring the team is always in the loop.

CloudWatch Alarms

# CloudWatch Alarm for API Gateway
resource "aws_cloudwatch_metric_alarm" "api_errors_alarm" {
  alarm_name          = "API-Error-Alarm"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "1"
  metric_name         = "IntegrationLatency"
  namespace           = "AWS/ApiGateway"
  period              = "60"
  statistic           = "Sum"
  threshold           = "1"

  dimensions = {
    ApiId = aws_api_gateway_rest_api.cloud_resume_api.id
  }

  alarm_description = "Triggers when API Gateway returns a 502 error"
  actions_enabled   = true
  alarm_actions     = [aws_sns_topic.api_alerts.arn]
}

SNS Topic for Notifications

# SNS topic resource for notifications
resource "aws_sns_topic" "api_alerts" {
  name = "CloudResumeAlerts"
}

SNS Policy to Allow Subscriptions & Limit Publish to Only CloudWatch

# Allow HTTPS, email, & Lambda subscriptions to SNS & restrict publish to SNS to only CloudWatch
resource "aws_sns_topic_policy" "api_alerts_policy" {
  arn = aws_sns_topic.api_alerts.arn
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "AllowCloudWatchPublish"
        Effect    = "Allow"
        Principal = { Service = "cloudwatch.amazonaws.com" }
        Action    = "SNS:Publish"
        Resource  = aws_sns_topic.api_alerts.arn
      },
      {
        Sid       = "AllowEmailSubscription"
        Effect    = "Allow"
        Principal = "*"
        Action    = "SNS:Subscribe"
        Resource  = aws_sns_topic.api_alerts.arn
        Condition = { StringEqualsIfExists = { "sns:Protocol" = "email" } }
      },
      {
        Sid       = "AllowHttpsSubscription"
        Effect    = "Allow"
        Principal = "*"
        Action    = "SNS:Subscribe"
        Resource  = aws_sns_topic.api_alerts.arn
        Condition = { StringEqualsIfExists = { "sns:Protocol" = "https" } }
      },
      {
        Sid       = "AllowLambdaSubscription"
        Effect    = "Allow"
        Principal = "*"
        Action    = "SNS:Subscribe"
        Resource  = aws_sns_topic.api_alerts.arn
        Condition = { StringEqualsIfExists = { "sns:Protocol" = "lambda" } }
      }
    ]
  })
}

Email Subscription

#Email subscription to SNS topic
resource "aws_sns_topic_subscription" "email_alert" {
  topic_arn = aws_sns_topic.api_alerts.arn
  protocol  = "email"
  endpoint  = var.email_address
}

Lambda Error Email Notification

PagerDuty Integration


#Store PagerDuty Integration URL in Secret Manager
resource "aws_secretsmanager_secret" "pagerduty_integration_url" {
  name = "pagerduty_integration_url"
}

resource "aws_secretsmanager_secret_version" "pagerduty_integration_url_value" {
  secret_id     = aws_secretsmanager_secret.pagerduty_integration_url.id
  secret_string = var.pagerduty_integration_url
}


#IAM Role for PagerDuty Lambda
resource "aws_iam_role" "sns_to_pagerduty_lambda_role" {
  name = "lambda_to_pagerduty_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action    = "sts:AssumeRole"
        Effect    = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

# IAM policy attachement for PagerDuty Lambda
resource "aws_iam_role_policy_attachment" "sns_lambda_secrets_access" {
  policy_arn = aws_iam_policy.lambda_sns_pagerduty_access.arn
  role       = aws_iam_role.sns_to_pagerduty_lambda_role.name
}

#IAM Policy for PagerDuty Lambda to Access Secret Manager & Make Requests to PagerDuty API
resource "aws_iam_policy" "lambda_sns_pagerduty_access" {
  name        = "lambda_sns_pagerduty_access"
  description = "Allow Lambda to access SNS, send events to PagerDuty, and write to CloudWatch Logs"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = [
          "sns:Subscribe",
          "sns:Publish",
          "sns:ListSubscriptions",
          "sns:ListSubscriptionsByTopic"
        ]
        Resource = aws_sns_topic.api_alerts.arn
      },
      {
        Effect   = "Allow"
        Action   = "secretsmanager:GetSecretValue"
        Resource = aws_secretsmanager_secret.pagerduty_integration_url.arn
      },
      {
        Effect   = "Allow"
        Action   = "execute-api:Invoke"  # Permission for making API calls to PagerDuty
        Resource = "arn:aws:apigateway:*::/*"  # Allow Lambda to call any API
      },
      {
        Effect   = "Allow"
        Action   = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "arn:aws:logs:*:*:*"  # Allow Lambda to write logs to any CloudWatch Log group/stream
      }
    ]
  })
}

#Create Lambda Layer to hold dependencies that can forward request to PagerDuty
resource "aws_lambda_layer_version" "pagerduty_lambda_layer" {
  layer_name  = "pagerduty_lambda_layer"
  filename    = "lambda_layer.zip"  # Path to your Lambda layer zip file
  source_code_hash = filebase64sha256("lambda_layer.zip")  # Ensures Terraform tracks changes

  compatible_runtimes = ["python3.12"]  #
}

# Lambda function for PagerDuty integration + layers
resource "aws_lambda_function" "lambda_to_pagerduty" {
  filename         = "lambda_to_pagerduty.zip"  # Prebuilt zip in my terraform directory
  function_name    = "lambda_to_pagerduty"      # Lambda name
  role             = aws_iam_role.sns_to_pagerduty_lambda_role.arn
  handler          = "lambda_to_pagerduty.lambda_handler"  
  runtime          = "python3.12"  # Or your preferred runtime
  source_code_hash = filebase64sha256("lambda_to_pagerduty.zip")  # Ensures Terraform tracks the zip file changes

  environment {
    variables = {
      PAGERDUTY_SECRET_ARN = aws_secretsmanager_secret.pagerduty_integration_url.arn
    }
  }

  layers = [
    aws_lambda_layer_version.pagerduty_lambda_layer.arn  # Attach the Lambda layer here
  ]
}

#PagerDuty Lambda subscription to SNS
resource "aws_sns_topic_subscription" "pagerduty_subscription" {
  topic_arn = aws_sns_topic.api_alerts.arn
  protocol  = "lambda"
  endpoint  = aws_lambda_function.lambda_to_pagerduty.arn
  depends_on = [aws_lambda_function.lambda_to_pagerduty]
}

#Ensure SNS can Invoke PageDuty_lambda
resource "aws_lambda_permission" "allow_sns_invoke" {
  statement_id  = "AllowExecutionFromSNS"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.lambda_to_pagerduty.function_name
  principal     = "sns.amazonaws.com"
  source_arn    = aws_sns_topic.api_alerts.arn
}

PagerDuty Getting Alerts from Lambda

Slack Integration

# Create IAM Role for Slack Lambda
resource "aws_iam_role" "sns_to_slack_lambda_role" {
  name = "sns_to_slack_lambda_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect   = "Allow",
        Principal = {
          Service = "lambda.amazonaws.com"
        },
        Action   = "sts:AssumeRole"
      }
    ]
  })
}

#Policy to allow Lambda Read from Secret Manager
resource "aws_iam_role_policy" "sns_to_slack_lambda_role_policy" {
  name = "sns-to-slack-lambda-policy"
  role = aws_iam_role.sns_to_slack_lambda_role.name

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect   = "Allow",
        Action   = "secretsmanager:GetSecretValue",
        Resource = aws_secretsmanager_secret.slack_webhook_url.arn
      }
    ]
  })
}

# Attach Policies to Allow Slack Lambda to Read from SNS and Write Logs to slack
resource "aws_iam_role_policy" "sns_to_slack_policy" {
  name = "sns_to_slack_policy"
  role = aws_iam_role.sns_to_slack_lambda_role.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect   = "Allow",
        Action   = "logs:CreateLogGroup",
        Resource = "arn:aws:logs:*:*:*"
      },
      {
        Effect   = "Allow",
        Action   = ["logs:CreateLogStream", "logs:PutLogEvents"],
        Resource = "arn:aws:logs:*:*:*"
      },
      {
        Effect   = "Allow",
        Action   = ["sns:Subscribe", "sns:Receive"],
        Resource = "${aws_sns_topic.api_alerts.arn}"
      },
      {
        Effect   = "Allow",
        Action   = "lambda:InvokeFunction",
        Resource = "${aws_lambda_function.sns_to_slack.arn}"
      },

      {
        # this policy allows Lambda to publish messages to SNS
        Effect   = "Allow",
        Action   = "sns:Publish",
        Resource = "${aws_sns_topic.api_alerts.arn}"
      }

    ]
  })
}

#Store the Webhook URL in AWS Secrets Manager
resource "aws_secretsmanager_secret" "slack_webhook_url" {
  name        = "slack-webhook-url"
  description = "Slack Webhook URL for Lambda"
}

resource "aws_secretsmanager_secret_version" "slack_webhook_url_version" {
  secret_id     = aws_secretsmanager_secret.slack_webhook_url.id
  secret_string = jsonencode({
    slack_webhook_url = var.slack_webhook_url
  })
}

# Create Lambda_to_Slack Function & retrieve slack webhook URL from AWS Secret Manager
resource "aws_lambda_function" "sns_to_slack" {
  filename      = "lambda_to_slack.zip"  # Zip your Python script before deployment
  function_name = "SNS-to-Slack"
  role          = aws_iam_role.sns_to_slack_lambda_role.arn
  handler       = "lambda_to_slack.lambda_handler"
  runtime       = "python3.9"
  timeout       = 10

  environment {
    variables = {
      SLACK_WEBHOOK_SECRET_NAME = aws_secretsmanager_secret.slack_webhook_url.name  # Reference to the secret
    }
  }

  # Lambda function's permission to access the secret (already done via IAM role policy)
  depends_on = [
    aws_secretsmanager_secret.slack_webhook_url
  ]
}

# Grant SNS permission to invoke Lambda
resource "aws_lambda_permission" "allow_sns" {
  statement_id  = "AllowSNSInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.sns_to_slack.function_name
  principal     = "sns.amazonaws.com"
  source_arn = aws_sns_topic.api_alerts.arn
  depends_on    = [aws_lambda_function.sns_to_slack]
}

# Subscribe Slack Lambda to SNS Topic
resource "aws_sns_topic_subscription" "sns_to_slack_subscription" {
  topic_arn = aws_sns_topic.api_alerts.arn
  protocol  = "lambda"
  endpoint  = aws_lambda_function.sns_to_slack.arn
  depends_on = [aws_lambda_permission.allow_sns] #Waits for Lambda perssion before subscription
}

Slack Alert from SNS-Lambda

Challenges & Strategies

While SNS allowed HTTPS subscription for PagerDuty integration, it can't retrieve my integration URL from AWS Secret Manager and it can't natively forward messages to Slack App. So, I employed two Lamba functions, which subsribed to SNS and forwared alerts generated by CloudWatch to my Slack App & PagerDuty for phone notifications.

V. Security & DNS: AWS WAF, Route53 & DNSSEC

The WAF configuration protects the website by blocking excessive traffic from a single IP (rate limiting), known bad IPs associated with reconnaissance and DDoS attacks, and malicious inputs. It also applies AWS-managed rule sets to prevent common vulnerabilities like cross-site scripting (XSS) and SQL injection, while providing visibility through CloudWatch metrics. Activating DNSSEC for my domain enhances security by preventing attackers from tampering with DNS responses and ensuring the integrity and authenticity of the domain's DNS data while Route53 provides the custom domain.

WAF Integration with Cloudfront

# AWS WAF resource to front CloudFront
resource "aws_wafv2_web_acl" "cloudfront_waf" {
  name        = "cloudfront-waf"
  description = "WAF for CloudFront"
  scope       = "CLOUDFRONT"

  default_action {
    allow {}
  }

  # Rate limiting rule
  rule {
    name     = "RateLimitRule"
    priority = 1

    action {
      block {}
    }

    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimitRule"
      sampled_requests_enabled   = true
    }
  }

  # Amazon IP Reputation List (Blocks known bad IPs, reconnaissance, DDoS)
  rule {
    name     = "AmazonIPReputationRule"
    priority = 2

    override_action { 
      count {} 
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesAmazonIpReputationList"

        # OPTIONAL: Override specific rules inside the group
        rule_action_override {
          action_to_use {
            block {}
          }
          name = "AWSManagedIPReputationList"
        }

        rule_action_override {
          action_to_use {
            block {}
          }
          name = "AWSManagedReconnaissanceList"
        }

        rule_action_override {
          action_to_use {
            count {}
          }
          name = "AWSManagedIPDDoSList"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AmazonIPReputationRule"
      sampled_requests_enabled   = true
    }
  }

  # AWS Managed Known Bad Inputs Rule Set
  rule {
    name     = "KnownBadInputsRule"
    priority = 3

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesKnownBadInputsRuleSet"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "KnownBadInputsRule"
      sampled_requests_enabled   = true
    }
  }

  # AWS Managed Common Rule Set
rule {
  name     = "CommonRuleSet"
  priority = 4

  override_action {
    none {}  # Ensures AWS WAF applies its built-in block actions
  }

  statement {
    managed_rule_group_statement {
      vendor_name = "AWS"
      name        = "AWSManagedRulesCommonRuleSet"

      # Override specific rules that are set to "Count" by default, so they actually block bad traffic.
      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_URIPATH_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_BODY_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_QUERYARGUMENTS_RC_COUNT"
      }

      rule_action_override {
        action_to_use {
          block {}
        }
        name = "CrossSiteScripting_COOKIE_RC_COUNT"
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "CommonRuleSet"
    sampled_requests_enabled   = true
  }
}

  # Visibility config for the WAF ACL itself
  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "CloudFrontWAF"
    sampled_requests_enabled   = true
  }
}

Route53 Custom Domain & DNSSEC

# Fetch the Route 53 hosted zone info for fozdigitalz.com
data "aws_route53_zone" "fozdigitalz_com" {
  name = "fozdigitalz.com"
}

# Route 53 DNS configuration
resource "aws_route53_record" "cloud_resume_record" {
  zone_id = data.aws_route53_zone.fozdigitalz_com.zone_id
  name    = "fidelis-resume.fozdigitalz.com"
  type    = "CNAME"
  ttl     = 300
  records = [aws_cloudfront_distribution.cloud_resume_distribution.domain_name]
}

# Create the KMS key (without setting the policy initially)
resource "aws_kms_key" "dnssec_key" {
  description             = "KMS key for Route 53 DNSSEC signing"
  deletion_window_in_days = 30
  key_usage               = "SIGN_VERIFY"
  customer_master_key_spec = "ECC_NIST_P256"
}

# Define the KMS key policy
resource "aws_kms_key_policy" "dnssec_key_policy" {
  key_id = aws_kms_key.dnssec_key.key_id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect    = "Allow"
        Principal = { Service = "dnssec-route53.amazonaws.com" }
        Action   = [ "kms:Encrypt", "kms:Decrypt", "kms:GetPublicKey", "kms:Sign", "kms:DescribeKey" ]
        Resource = aws_kms_key.dnssec_key.arn
      },
      {
        Effect    = "Allow"
        Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
        Action   = [ "kms:*"]
        Resource = aws_kms_key.dnssec_key.arn
      },
      # Allow my IAM User to get and put key policies
      {
        Effect    = "Allow"
        Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:user/Fidelisesq" }
        Action   = [
          "kms:*"
        ]
        Resource = aws_kms_key.dnssec_key.arn
      }
    ]
  })
}

# Create the DNSSEC key signing key
resource "aws_route53_key_signing_key" "dnssec_kms_key" {
  hosted_zone_id = data.aws_route53_zone.fozdigitalz_com.zone_id
  name           = "dnssec-kms-key"
  key_management_service_arn = aws_kms_key.dnssec_key.arn
}

# Enable DNSSEC for the hosted zone
resource "aws_route53_hosted_zone_dnssec" "dnssec" {
  hosted_zone_id = data.aws_route53_zone.fozdigitalz_com.zone_id
  depends_on = [ aws_route53_key_signing_key.dnssec_kms_key ]
}

DNSSEC Activated

Challenges & Strategies

Not really a challenge here but I discovered that AWS WAF won't work with the HTTP API. So, instead of just throttling rate, I opted for the REST API with WAF to protect it. Later on, I placed WAF before my Cloudfront. When WAF worked, using AWSManagedRules gave me issues. So, I checked the documentation for each rule and discovered the issue was me overriding some rules in my terraform config when the default actions was already set by AWS either as count or block. Secondly, I initially created a KMS key needed for my DNSSEC without an active policy that grants me necessary permission like PutKeyPolicy & Disable + DeleteKey so it locked me out when I needed to modify Sign & Verify permission for Route53. I had to contact AWS support for help because I can't modify it nor schedule for deletion.

2. Code Test + CI/CD Pipeline

In this workflow, I set up a GitHub Actions pipeline to deploy and manage infrastructure using Terraform. The pipeline includes steps for testing the Lambda function that counts visitors on the website and ensures the tests are successful before proceeding with the infrastructure deployment. I also added functionality for both creating and destroying resources based on user input or commit messages. For deployment, I configured Terraform to provision the necessary resources on AWS, including creating and applying a Terraform plan with secrets securely stored in GitHub. Additionally, I implemented a cleanup process that destroys infrastructure when required, ensuring efficient resource management.

GitHub Actions Workflow

The workflow is triggered on a push to the main branch or manually via the workflow_dispatch event. It supports two actions: create (deploy infrastructure) and destroy (tear down infrastructure).

name: Deploy Infrastructure

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      action:
        description: "Action to perform (create or destroy)"
        required: true
        type: choice
        options:
          - create
          - destroy

jobs:
  visitor-count-lambda-function-test:
    name: "Visitor Count Lambda Function Test"
    runs-on: ubuntu-latest
    if: >-
      !(github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'destroy') &&
      !(github.event_name == 'push' && contains(github.event.head_commit.message, 'destroy'))
    steps:
      - name: Checkout the code
        uses: actions/checkout@v4.2.2

      - name: Set up Python
        uses: actions/setup-python@v5.4.0
        with:
          python-version: '3.8'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements-test.txt

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

      - name: Run tests with pytest
        run: |
          pytest tests/visitor_counter_testscript.py

  infrastructure-deployment:
    if: >-
      (github.event_name == 'push' && !contains(github.event.head_commit.message, 'destroy') && needs.visitor-count-lambda-function-test.result == 'success') ||
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'create' && needs.visitor-count-lambda-function-test.result == 'success')
    name: "Infrastructure Deployment"
    runs-on: ubuntu-latest
    needs: visitor-count-lambda-function-test
    defaults:
      run:
        shell: bash
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.10.3

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform/terraform.tfvars
          acm_certificate_arn = "${{ secrets.ACM_CERTIFICATE_ARN }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_REGION }}"
          bucket_name = "${{ secrets.BUCKET_NAME }}"
          domain_name = "${{ secrets.DOMAIN_NAME }}"
          email_address = "${{ secrets.EMAIL_ADDRESS }}"
          pagerduty_integration_url = "${{ secrets.PAGERDUTY_INTEGRATION_URL }}"
          pagerduty_integration_key = "${{ secrets.PAGERDUTY_INTEGRATION_KEY }}"
          slack_webhook_url = "${{ secrets.SLACK_WEBHOOK_URL }}"
          EOF

      - name: Mask AWS Account ID in Logs
        run: echo "::add-mask::${{ secrets.AWS_ACCOUNT_ID }}"

      - name: Terraform Init
        id: init
        run: cd terraform && terraform init

      - name: Terraform Validate
        id: validate
        run: cd terraform && terraform validate

      - name: Terraform Plan
        id: plan
        run: cd terraform && terraform plan -out=tfplan

      - name: Terraform Apply
        id: apply
        run: cd terraform && terraform apply -auto-approve tfplan

  infrastructure-cleanup:
    if: >-
      (github.event_name == 'push' && contains(github.event.head_commit.message, 'destroy')) ||
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'destroy')
    name: "Infrastructure Cleanup"
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.10.3

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform/terraform.tfvars
          acm_certificate_arn = "${{ secrets.ACM_CERTIFICATE_ARN }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          bucket_name = "${{ secrets.BUCKET_NAME }}"
          domain_name = "${{ secrets.DOMAIN_NAME }}"
          email_address = "${{ secrets.EMAIL_ADDRESS }}"
          pagerduty_integration_url = "${{ secrets.PAGERDUTY_INTEGRATION_URL }}"
          pagerduty_integration_key = "${{ secrets.PAGERDUTY_INTEGRATION_KEY }}"
          slack_webhook_url = "${{ secrets.SLACK_WEBHOOK_URL }}"
          EOF

      - name: Mask AWS Account ID in Logs
        run: echo "::add-mask::${{ secrets.AWS_ACCOUNT_ID }}"

      - name: Terraform Init
        id: init
        run: cd terraform && terraform init

      - name: Terraform Destroy
        id: destroy
        run: cd terraform && terraform destroy -auto-approve

Deployment workflow run

Challenges & Strategies

When I started I had partial success of deployment here and there. I actually lost count of the number of Workflow Runs before I got a clean successful run. This section came with lots of debugging, learning to use eventstatus and conditions to achieve my goal.

3. End-to-End Test with Cypress

In this Cypress workflow, I run tests on the deployed resume website to ensure its functionality after the infrastructure is successfully deployed. The workflow triggers once the Deploy Infrastructure workflow completes, confirming the deployment was successful before starting the Cypress tests.

The tests check various elements on the page, such as verifying that my name appears, confirming the presence of key sections like "Professional Summary" and "Personal Project Experience," and ensuring links to my GitHub, LinkedIn, and blog work correctly. Additionally, I check the visitor count and ensure that no images are broken on the page. The results are then recorded and accessible in the Cypress Dashboard for analysis.

Cypress Workflow

name: Cypress Tests

on:
  workflow_run:
    workflows: ["Deploy Infrastructure"]
    types:
      - completed
    branches:
      - main  # Specify the branch(es) where the workflow should run

jobs:
  cypress-run:
    runs-on: ubuntu-latest
    if: github.event.workflow_run.conclusion == 'success'  # Ensure the workflow only runs if the deployment succeeded
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '16'

      - name: Install dependencies
        run: npm install

      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          wait-on: 'https://fidelis-resume.fozdigitalz.com/'
          wait-on-timeout: 60
          record: true
        env:
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Save Cypress status
        id: cypress-status
        run: |
          if [ "${{ job.status }}" == "success" ]; then
            echo "Cypress tests passed!"
            echo "cypress-status=success" >> $GITHUB_OUTPUT
          else
            echo "Cypress tests failed!"
            echo "cypress-status=failure" >> $GITHUB_OUTPUT
          fi

Screenshot of successful End-to-End Design Test

Challenges & Strategies

Using Cypress made it easy to run the test. I got a good part of my workflow from my Cypress Cloud dashboard after creating an account and a project on the platform. I got the Cypress Token, which I added as CYPRESS_RECORD_KEY in my GitHub Actions workflow. This allowed Cypress to upload test logs, screenshots, and videos to the Cypress Cloud dashboard for easier debugging. With this setup, I could monitor test history and quickly identify any failures after each deployment.

4. Results

The implementation of this architecture has resulted in a highly reliable, secure, and scalable personal website. Using Cypress, I conducted end-to-end tests to validate critical functionalities, including the visitor count, custom domain with HTTPS, API Gateway integration, and other site components, ensuring everything works as expected. Screenshots of the test results and videos demonstrating the functionality are included below. The combination of serverless components (Lambda, API Gateway, DynamoDB), global content delivery via CloudFront, and robust security measures (DNSSEC, AWS WAF, HTTPS) ensures a performant, secure, and cost-efficient solution.

A quick rundown of the resume page

5. Conclusion & Lessons Learnt

This project demonstrates how to build a scalable, secure, and cost-efficient serverless resume website on AWS. By leveraging Terraform for infrastructure as code and GitHub Actions for CI/CD, the entire deployment process is automated and reproducible.

The use of serverless technologies ensures minimal operational overhead, while monitoring and alerting systems provide visibility into the system’s health. This project reinforced the importance of automation, security, and monitoring in cloud deployments.

Overcoming challenges with API integrations, Terraform state management, and Lambda execution improved my troubleshooting skills and deepened my understanding of AWS services.

DeepSeek-R1 Deployment on AWS via Terraform & GitHub Actions

Fidelis Ikoroje — Sun, 09 Feb 2025 17:14:23 +0000

Hey there! In this blog post, I’m going to walk you through how I deployed the DeepSeek Model R1 8B on AWS using Terraform and GitHub Actions. If you’ve ever tried deploying a machine learning model, you know it can get pretty complicated—especially when you’re juggling multiple AWS services. To make things easier, I decided to automate the whole process using Terraform for infrastructure as code and GitHub Actions for CI/CD. Spoiler alert: it worked like a charm!

Introduction
Project Overview
Terraform Configuration
- Provider Configuration
- Security Groups
- Load Balancer (ALB)
- EC2 Instance
- IAM Roles and Instance Profile
- Route 53 DNS Record
- Terraform Backend (S3)
GitHub Actions Workflow
- Workflow Triggers
- Setup Job
- Apply Job
- Post-Apply Job
- Destroy Job
The Application in Action (Result)
Challenges Faced & Lessons Learned
Future Improvements
Conclusion

1. Introduction

2. Project Overview

The goal of this project was to deploy the DeepSeek Model R1 on AWS, making it accessible via a web interface (OpenWebUI) and an API (Ollama). The infrastructure includes:

EC2 Instance: Hosts the DeepSeek model in a Docker container and associated services.
Application Load Balancer (ALB): Distributes traffic to the EC2 instance and handles SSL termination.
Security Groups: Control inbound and outbound traffic to the ALB and EC2 instance.
IAM Roles: Provide the necessary permissions for the EC2 instance.
Route 53: Manages DNS records for the ALB. I just employed a cetificate I already have in us-east-1 and a ready public hosted zone in same region.
Terraform Backend: Stores the Terraform state file in an S3 bucket for team collaboration.

3. Terraform Configuration

The Terraform configuration is the backbone of this project. It defines all the AWS resources required for the deployment. Below is a breakdown of the key components:

Provider Configuration

The first step in the Terraform configuration is to define the AWS provider and specify the region:

provider "aws" {
  region = "us-east-1"
}

Security Groups

Two security groups were created: one for the ALB and one for the EC2 instance. The ALB security group allows HTTPS traffic (port 443) and HTTP traffic (port 80) for testing purposes. It also allows TCP traffic on port 11434 for the Ollama API. The EC2 security group restricts traffic to only allow communication from the ALB on ports 8080 (OpenWebUI) and 11434 (Ollama API).

resource "aws_security_group" "alb_sg" {
  name        = "deepseek_alb_sg"
  description = "Security group for ALB"
  vpc_id      = var.vpc_id

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

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

  ingress {
    from_port = 11434
    to_port = 11434
    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"]
  }
}

Load Balancer (ALB)

The ALB is configured to listen on ports 443 (HTTPS) and 80 (HTTP). The HTTP listener redirects traffic to HTTPS for secure communication. Additionally, I set up a separate listener for the Ollama API on port 11434. Although this is not needed because the OpenWebUI already exposes the Ollama API. I just needed to have it as a standby maybe for direct API access programmatically.

resource "aws_lb" "deepseek_lb" {
  name               = "deepseek-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = var.subnet_ids

  enable_deletion_protection = false
}

EC2 Instance

resource "aws_instance" "deepseek_ec2" {
  ami             = var.ami_id
  instance_type   = var.instance_type
  key_name        = data.aws_key_pair.existing_key.key_name
  subnet_id       = var.public_subnet_id
  security_groups = [aws_security_group.deepseek_ec2_sg.id]
  #iam_instance_profile = aws_iam_instance_profile.deepseek_ec2_profile.name

  root_block_device {
    volume_size           = 48
    volume_type           = "gp3"
    delete_on_termination = true
  }

  tags = {
    Name = "DeepSeekModelInstance"
  }
}

IAM Roles and Instance Profile

An IAM role is created for the EC2 instance, allowing it to assume the role and access necessary AWS resources. At first, I wanted to copy the model from an S3 bucket, so I created this EC2 resource. So, I don't need this now because I opted to use a docker image but will keep it for future modifications.

resource "aws_iam_role" "deepseek_ec2_role" {
  name = "deepseek_ec2_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_instance_profile" "deepseek_ec2_profile" {
  name = "deepseek_ec2_profile"
  role = aws_iam_role.deepseek_ec2_role.name
}

Route 53 DNS Record

resource "aws_route53_record" "deepseek_dns" {
  zone_id = var.hosted_zone_id
  name    = "deepseek.fozdigitalz.com"
  type    = "A"

  alias {
    name                   = aws_lb.deepseek_lb.dns_name
    zone_id                = aws_lb.deepseek_lb.zone_id
    evaluate_target_health = true
  }
}

Terraform Backend (S3)

The Terraform state file is stored in an S3 bucket to enable team collaboration and state management.

terraform {
  backend "s3" {
    bucket         = "foz-terraform-state-bucket"
    key            = "infra.tfstate"
    region         = "us-east-1"
    encrypt        = true
  }
}

Variables Configuration

The variables.tf file defines all the input variables required for the Terraform configuration. These variables make the configuration reusable and customizable.

variable "aws_region" {
  description = "AWS region to deploy resources"
  type        = string
  default     = "us-east-1"
}

variable "vpc_id" {
  description = "Existing VPC ID where resources will be deployed"
  type        = string
}

variable "subnet_ids" {
  description = "Subnet ID for the ALB"
  type        = list(string)
}

variable "public_subnet_id" {
  description = "Public subnet ID for the EC2 instance"
  type        = string
}

variable "key_name" {
  description = "Key ID for EC2 instance"
  type        = string
}

variable "key_id" {
  description = "The ID of the key pair to use for the EC2 instance"
  type        = string
}

variable "ami_id" {
  description = "Amazon Machine Image (AMI) ID"
  type        = string
}

variable "certificate_arn" {
  description = "ARN of the SSL certificate for HTTPS"
  type        = string
}

variable "hosted_zone_id" {
  description = "ID of the existing Route 53 hosted zone for fozdigitalz.com in us-east-1"
  type        = string
}

variable "terraform_state_bucket" {
  description = "The name of the S3 bucket for Terraform state"
  type        = string
}

variable "instance_type" {
  description = "Instance type for the EC2 instance"
  type        = string
}

variable "my_ip" {
  description = "IP address allowed to SSH"
  type        = string
}

Terraform.tfvars

The terraform.tfvars file is used to assign values to the variables defined in variables.tf. This file is typically not committed to version control (e.g., Git) for security reasons, as it may contain sensitive information like AWS credentials. I added terraform.tfvars to .gitignore so it won't be tracked. I provided the variables and secrets in GitHub using environment variables and secrets. Also, the values below are made up and not real.

aws_region              = "us-east-1"
vpc_id                  = "vpc-1234567890abcdef0"
subnet_ids              = ["subnet-1234567890abcdef0", "subnet-0987654321abcdef0"]
public_subnet_id        = "subnet-1234567890abcdef0"
key_name                = "my-key-pair"
key_id                  = "key-1234567890abcdef0"
ami_id                  = "ami-0abcdef1234567890"
certificate_arn         = "arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012"
hosted_zone_id          = "Z1234567890ABCDEF"
terraform_state_bucket  = "foz-terraform-state-bucket"
instance_type           = "c4.4xlarge"
my_ip                   = "192.168.1.1/32"

Output Configuration

output "ec2_public_ip" {
  description = "Public IP address of the EC2 instance"
  value       = aws_instance.deepseek_ec2.public_ip
}

output "lb_url" {
  description = "DNS name of the Application Load Balancer"
  value       = aws_lb.deepseek_lb.dns_name
}

output "deepseek_ec2_sg_id" {
  description = "Security Group ID of the EC2 instance"
  value       = aws_security_group.deepseek_ec2_sg.id
}

4. GitHub Actions Workflow

Workflow Triggers

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      action:
        description: "Choose action (apply/destroy)"
        required: true
        default: "apply"
        type: choice
        options:
          - apply
          - destroy

Setup Job

The setup job initializes the environment by checking out the code, setting up Terraform, and configuring AWS credentials.

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

Apply Job

  apply:
    runs-on: ubuntu-latest
    needs: setup
    if: |
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'apply') ||
      (github.event_name == 'push' && !contains(github.event.head_commit.message, 'destroy'))
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform.tfvars
          ami_id = "${{ secrets.AMI_ID }}"
          certificate_arn = "${{ secrets.CERTIFICATE_ARN }}"
          vpc_id = "${{ secrets.VPC_ID }}"
          subnet_ids = [${{ secrets.SUBNET_IDS }}]
          key_name = "${{ secrets.KEY_NAME }}"
          key_id = "${{ secrets.KEY_ID }}"
          hosted_zone_id = "${{ secrets.HOSTED_ZONE_ID }}"
          instance_type = "${{ secrets.INSTANCE_TYPE }}"
          my_ip = "${{ secrets.MY_IP }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          public_subnet_id = "${{ secrets.PUBLIC_SUBNET_ID }}"
          terraform_state_bucket = "${{ secrets.TERRAFORM_STATE_BUCKET }}"
          EOF

      - name: Terraform Init
        run: |
          terraform init \
            -backend-config="bucket=${{ secrets.TERRAFORM_STATE_BUCKET }}" \
            -backend-config="key=infra.tfstate" \
            -backend-config="region=${{ secrets.AWS_DEFAULT_REGION }}"

      - name: Terraform Plan
        run: terraform plan -out=tfplan -var-file=terraform.tfvars

      - name: Terraform Apply
        run: terraform apply -auto-approve -var-file=terraform.tfvars

Post-Apply Job

The post-apply job retrieves Terraform outputs, updates the EC2 security group to allow SSH access from the GitHub runner, installs Docker on the EC2 instance, and deploys the DeepSeek Model and OpenWebUI using Docker.

  post_apply:
    runs-on: ubuntu-latest
    needs: apply
    if: success()
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Retrieve Terraform Outputs
        id: tf_outputs
        run: |
          echo "Retrieving Terraform Outputs..."
          echo "EC2_PUBLIC_IP=$(terraform output -raw ec2_public_ip)" >> $GITHUB_ENV
          echo "LB_DNS=$(terraform output -raw lb_url)" >> $GITHUB_ENV

      - name: Retrieve EC2 Security Group ID
        id: get_sg_id
        run:  |
          SECURITY_GROUP_ID=$(terraform output -raw deepseek_ec2_sg_id)
          echo "SECURITY_GROUP_ID=$SECURITY_GROUP_ID" >> $GITHUB_ENV

      - name: Add GitHub Runner IP to Security Group
        run: |
          RUNNER_IP=$(curl -s https://checkip.amazonaws.com)
          echo "Runner IP: $RUNNER_IP"
          aws ec2 authorize-security-group-ingress \
            --group-id "${{ env.SECURITY_GROUP_ID }}" \
            --protocol tcp \
            --port 22 \
            --cidr "$RUNNER_IP/32" || echo "Failed to add rule to EC2 Security Group"

      - name: Wait for Security Group to Update
        run: sleep 12

      - name: Save SSH Private Key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" | base64 --decode > ~/.ssh/my-key.pem
          chmod 600 ~/.ssh/my-key.pem

      - name: Verify SSH Connection
        run: |
           ssh -o StrictHostKeyChecking=no -i ~/.ssh/my-key.pem ubuntu@${{ env.EC2_PUBLIC_IP }} 
           echo "SSH Connection Successful"

      - name: Install Docker on EC2
        run: |
          ssh -o StrictHostKeyChecking=no -i ~/.ssh/my-key.pem ubuntu@${{ env.EC2_PUBLIC_IP }} <<EOF
          sudo apt-get update
          sudo apt-get install -y docker.io docker-compose
          sudo systemctl enable docker
          sudo systemctl start docker
          sudo usermod -aG docker ubuntu
          sudo sed -i 's/^ENABLED=1/ENABLED=0/' /etc/apt/apt.conf.d/20auto-upgrades
          sudo reboot
          EOF

      - name: Wait for EC2 Instance to Reboot
        run: sleep 60

      - name: Run DeepSeek Model and WebUI via Docker
        run: |
          ssh -o StrictHostKeyChecking=no -i ~/.ssh/my-key.pem ubuntu@${{ env.EC2_PUBLIC_IP }} <<EOF
          docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
          sleep 20
          docker exec ollama ollama pull deepseek-r1:8b
          sleep 15
          docker exec -d ollama ollama serve
          sleep 15
          docker run -d -p 8080:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
          sleep 15
          EOF

      - name: Confirm WebUI is Running & Accessible via Custom Domain
        run: |
          ssh -o StrictHostKeyChecking=no -i ~/.ssh/my-key.pem ubuntu@${{ env.EC2_PUBLIC_IP }} <<EOF
          curl -I https://deepseek.fozdigitalz.com
          EOF

      - name: Remove GitHub Runner IP from Security Group
        if: always()
        run: |
            RUNNER_IP=$(curl -s https://checkip.amazonaws.com)
            echo "Removing Runner IP: $RUNNER_IP"
            aws ec2 revoke-security-group-ingress \
              --group-id "${{ env.SECURITY_GROUP_ID }}" \
              --protocol tcp \
              --port 22 \
              --cidr "$RUNNER_IP/32"

Destroy Job

The destroy job tears down the infrastructure when triggered manually or via a commit message containing "destroy".

  destroy:
    runs-on: ubuntu-latest
    needs: setup
    if: |
      (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'destroy') ||
      (github.event_name == 'push' && contains(github.event.head_commit.message, 'destroy'))
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3

      - 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-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Create terraform.tfvars
        run: |
          cat <<EOF > terraform.tfvars
          ami_id = "${{ secrets.AMI_ID }}"
          certificate_arn = "${{ secrets.CERTIFICATE_ARN }}"
          vpc_id = "${{ secrets.VPC_ID }}"
          subnet_ids = [${{ secrets.SUBNET_IDS }}]
          key_name = "${{ secrets.KEY_NAME }}"
          key_id = "${{ secrets.KEY_ID }}"
          hosted_zone_id = "${{ secrets.HOSTED_ZONE_ID }}"
          instance_type = "${{ secrets.INSTANCE_TYPE }}"
          my_ip = "${{ secrets.MY_IP }}"
          aws_access_key_id = "${{ secrets.AWS_ACCESS_KEY_ID }}"
          aws_secret_access_key = "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
          aws_region = "${{ secrets.AWS_DEFAULT_REGION }}"
          public_subnet_id = "${{ secrets.PUBLIC_SUBNET_ID }}"
          terraform_state_bucket = "${{ secrets.TERRAFORM_STATE_BUCKET }}"
          EOF

      - name: Terraform Init & Destroy
        run: |
          terraform init -reconfigure \
            -backend-config="bucket=${{ secrets.TERRAFORM_STATE_BUCKET }}" \
            -backend-config="key=infra.tfstate" \
            -backend-config="region=${{ secrets.AWS_DEFAULT_REGION }}"
          terraform destroy -auto-approve -var-file=terraform.tfvars

Completed workflow run

5. The Application in Action (Result)

After successfully deploying the DeepSeek Model R1 on AWS, I was able to access the OpenWebUI and interact with the model. Below are some screenshots demonstrating the setup and functionality:

I. OpenWebUI Interface

The OpenWebUI provides a user-friendly interface for interacting with the DeepSeek Model R1. Here’s a screenshot of the dashboard:

The OpenWebUI dashboard, accessible via the custom domain deepseek.fozdigitalz.com.

II. Model Interaction

I tested the model by asking it a few questions. Here’s an example of the model’s response:
The DeepSeek Model R1 generating a response to a sample query.

Sample model response 11

Sample mode response 12

Sample model response 21

Sample model response 22

III. Infrastructure Clean Up

By manually triggering the workflow from the GitHub UI and selecting the destroy action.
By pushing to the main branch with a commit message that contains the word destroy.
By running the command gh workflow run "workflow name" --field action=destroy locally but you must have the Github CLI installed for this to work. Infrastructure cleanup using terraform

IV. Model Performance Metrics & Instance Metrics

I measured the model’s response time and resource utilization. Here’s a summary of the performance:

Average Response Time: 3.06 minutes
CPU Utilization: 26.8%
Memory Usage: 13.65GB

6. Challenges Faced & Lessons Learned

Deploying the DeepSeek Model R1 on AWS using Terraform and GitHub Actions presented several challenges, each of which taught valuable lessons for improving the deployment process and infrastructure design.

1. Security Configuration

Challenge: Configuring security groups and IAM roles to balance accessibility and security was complex. Misconfigurations could expose the EC2 instance or over-privilege IAM roles.
Lesson Learned: Follow the principle of least privilege. Restrict SSH access to specific IPs, limit IAM permissions, and ensure only necessary ports are open.

2. Workflow Reliability

Challenge: My workflow failed countless times owing to different issues from terraform config to secerts and variables and I had to troubleshoot the issue on different ocassions employing debugging. The EC2 instance required a reboot after Docker installation, causing delays in the GitHub Actions workflow. Without proper handling, subsequent steps could fail.
Lesson Learned: Automate delays (e.g., sleep) and post-reboot tasks to ensure smooth workflow execution. Modularize the workflow for better reliability.

3. State and Code Management

Challenge: Managing the Terraform state file in S3 and maintaining a monolithic configuration led to potential security risks and reduced reusability.
Lesson Learned: Use versioning, encryption, and access controls for the Terraform state. Break configurations into reusable modules for better organization and maintainability.

7. Future Improvements

While the deployment process is now functional, there are opportunities I may consider to enhance scalability, security, and cost-efficiency.

1. Scalability

Implement auto-scaling for the EC2 instance to handle varying loads and ensure optimal performance during peak usage.

2. Monitoring and Security

Add CloudWatch alarms and logs for real-time monitoring and troubleshooting. Enhance security by using AWS Systems Manager for instance management instead of SSH.

3. Cost Optimization

Explore spot instances or reserved instances to reduce costs. Additionally, consider upgrading to GPU-powered instances for better performance if the model is computationally intensive.

8. Conclusion

Deploying the DeepSeek Model R1 on AWS using Terraform and GitHub Actions was a rewarding experience. It not only streamlined the deployment process but also provided a scalable and secure infrastructure. By automating the deployment pipeline, I ensured consistency and repeatability, making it easier to manage and update the infrastructure in the future.

RabbitMQ Monitoring with Prometheus and Grafana

Fidelis Ikoroje — Sat, 28 Dec 2024 20:15:12 +0000

In this project, I completed two setups for RabbitMQ monitoring with Prometheus and Grafana. The first setup is a local Docker Compose setup for quick testing while the other is a 3-node RabbitMQ cluster setup on AWS EC2 for scalability and real-world applications.

Overview of the Project

RabbitMQ is a popular message broker that plays a crucial role in distributed systems. This project aimed to:
I. Set up a RabbitMQ environment both locally and on AWS.
II. Monitor RabbitMQ metrics using Prometheus and visualize them with Grafana.
III. Test the message queuing system using Python scripts.

Part 1: Local RabbitMQ Setup Using Docker Compose

Why Local Setup?

The local setup serves as a quick testing environment before deploying to the cloud.

Steps to Set Up:

I. Clone the RabbitMQ Repository:

   git clone https://github.com/rabbitmq/rabbitmq-server.git
   cd rabbitmq-server/deps/rabbitmq_prometheus/docker

II. Run Docker Compose:
Use Docker Compose to start the RabbitMQ cluster and Prometheus instance, along with a basic workload to generate meaningful metrics. This will start a RabbitMQ cluster, Prometheus, and Grafana with predefined configurations, collecting metrics from RabbitMQ.

   docker-compose -f docker-compose-metrics.yml up -d
   docker-compose -f docker-compose-overview.yml up -d

III. Access RabbitMQ Dashboard:

URL: http://localhost:15672
Default credentials: Username: guest Password: guest

IV. Access Grafana Dashboard:

URL: http://localhost:3000
Default credentials: Username: admin Password: admin

Part 2: RabbitMQ 3-Node Cluster on AWS EC2

Why a Cluster?

To ensure high availability and load distribution in production.

Prerequisites

3 AWS EC2 instances running Ubuntu 24.04 for RabbitMQ and one each for Prometheus and Grafana. Configure the Security Groups as follows:

RabbitMQ Security Groups:
- Allow SSH (port 22) from your IP.
- Allow RabbitMQ Management UI (port 15672) from your IP.
- Allow RabbitMQ Prometheus Metrics (port 15692) from Prometheus instance SG.
Prometheus Security Groups:
- Allow HTTP (port 80) from your IP.
- Allow HTTPS (port 443) from your IP.
- Allow Grafana (port 3000) from your IP.
Grafana Security Groups:
- Allow HTTP (port 80) from your IP.
- Allow HTTPS (port 443) from your IP.

Step-by-Step Guide

I. Install RabbitMQ on All 3 Nodes:
Use a bash script as EC2 user data during instance launch or save it and run it on each EC2 instance. The bash script I used is named rabbitmq_installation.sh in my git repository. It includes all the plugins needed to help Prometheus scrape metrics from RabbitMQ.

II. Cluster Configuration:

Verify Erlang cookie consistency:
```
 sudo cat /var/lib/rabbitmq/.erlang.cookie
```
Ensure the same cookie is on all 3 RabbitMQ EC2 nodes.

Join nodes to form a cluster:
Pick one EC2 as reference and run the commands below on the other two EC2's.

 sudo rabbitmqctl stop_app
 sudo rabbitmqctl reset
 sudo rabbitmqctl join_cluster rabbit@<master-node-hostname>
 sudo rabbitmqctl start_app

III. Verify Cluster Status:

   sudo rabbitmqctl cluster_status

Part 3: Monitoring with Prometheus and Grafana

Prometheus Setup on AWS EC2

I. Install Prometheus Using a Bash Script:
I used a Bash script named prometheus.sh saved in my git repository to install Prometheus and it includes all the plugins needed. Save this script on your Prometheus EC2 and run the script.

   ./prometheus.sh

II. Configure Prometheus:
Edit prometheus.yml to scrape RabbitMQ metrics:

   scrape_configs:
     - job_name: 'rabbitmq'
       static_configs:
         - targets: ['<rabbitmq-node-1-ip>:15692', '<rabbitmq-node-2-ip>:15692', '<rabbitmq-node-3-ip>:15692']

III. Run Prometheus:

   /usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml

Grafana Setup on AWS EC2

I. Install Grafana Using a Bash Script:

   #!/bin/bash
   sudo apt update -y
   sudo apt install -y wget unzip
   wget https://dl.grafana.com/enterprise/release/grafana-enterprise-11.4.0.linux-arm64.tar.gz
   tar xvf grafana-enterprise-11.4.0.linux-arm64.tar.gz
   sudo mv grafana-11.4.0 /usr/local/grafana
   echo 'Grafana installed.'

II. Configure Grafana:

Add Prometheus as a data source in Grafana
Import RabbitMQ dashboards - the file is named RabbitMQ-Overview.json

III. Verify Metrics on Grafana:

URL: http://<grafana-ip>:3000
Navigate to imported RabbitMQ dashboards to monitor metrics.

Part 4: Testing the Message Queue

Using Python scripts, I tested message publishing and consumption:

import pika

# Connection setup
credentials = pika.PlainCredentials('guest', 'guest')
connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq-node-ip', credentials=credentials))
channel = connection.channel()

# Declare queue
channel.queue_declare(queue='test_queue')

# Publish message
channel.basic_publish(exchange='', routing_key='test_queue', body='Hello RabbitMQ!')
print("Message published.")

# Consume message
def callback(ch, method, properties, body):
    print(f"Received: {body}")

channel.basic_consume(queue='test_queue', on_message_callback=callback, auto_ack=True)
channel.start_consuming()

Grafana showing metrics scrapped by Prometheus

Final Thoughts

This project showcased the power of RabbitMQ in a distributed setup and the importance of monitoring using Prometheus and Grafana. Whether for testing or production, the tools and techniques used here ensure a scalable and observable messaging system.

Distributed Logging System with RabbitMQ

Fidelis Ikoroje — Sat, 07 Dec 2024 08:14:25 +0000

I have covered the setup procedure for my centralised distributed logging system. This system is essential for log management, message queues, and monitoring, which are critical to modern DevOps practices. The system setup includes a log producer and consumer system using RabbitMQ, which can aggregate them into a file for analysis.

System Setup Guide

1. Install RabbitMQ

First, install RabbitMQ on your server. Follow the installation instructions for your specific operating system from the official RabbitMQ website: https://www.rabbitmq.com/download.html. I installed RabbitMQ on AWS EC2 running Ubuntu

sudo apt update
sudo apt install rabbitmq-server -y

Note: Ensure you add an inbound rule in the EC2 Security Group that allows SSH preferably from your IP alone

2. Enable RabbitMQ Management Plugin

The management plugin provides a user interface and HTTP-based API for managing RabbitMQ. Run the following command to enable it:

sudo rabbitmq-plugins enable rabbitmq_management

This command enables the RabbitMQ management plugin, allowing access to the web-based management interface.

3. Create a New User

Create a new RabbitMQ user with a specific username and password:

rabbitmqctl add_user rabituser secret_password

This command creates a new user named rabbituser with the password secret_password.

4. Set Permissions for the User

Grant the user permissions to access and manage resources:

rabbitmqctl set_permissions -p / rabbituser ".*" ".*" ".*"

This command gives the user rabbituser full permissions (read, write, and configure) on the default virtual host /.

5. Add Management Tag to the User

Grant the user access to the RabbitMQ management interface:

rabbitmqctl set_user_tags rabbituser management

This command adds the management tag to the user rabbituser, allowing them to log in to the RabbitMQ management interface.

6. Configuring External Network Access

Edit the /etc/rabbitmq/rabbitmq.conf file to allow external access because RabbitMQ blocks localhost access by default. Add the configuration.

listeners.tcp.default = 5672

Now restart the system

sudo systemctl restart rabbitmq-server

7. Add a Queue

Once logged in, follow these steps to add a queue:

Click on the "Queues" tab.
Click on "Add a new queue".
Enter the name of the queue (e.g., logs_queue) and configure any additional settings as needed.
Click the "Add queue" button to create the queue.

8. Adding Queue via CLI (Optional)

Alternatively, you can add a queue using the rabbitmqadmin command-line tool:

Download rabbitmqadmin: Navigate to http://<your_rabbitmq_server>:15672/cli/rabbitmqadmin to download the tool.
Make it executable:

   chmod +x rabbitmqadmin

Declare a Queue:

   ./rabbitmqadmin declare queue name=logs_queue durable=true

This command creates a durable queue named logs_queue.

9. Access the RabbitMQ Management Interface

Open your web browser and navigate to http://<your_rabbitmq_server>:15672/. Log in with the username rabbituser and the password you set to verify that logs_queue that you created exists.
You may also verify using CLI command to see the queue

sudo rabbitmqctl list_queues

10. Install Required Python Libraries

Install pika and write a python script that will produce logs and consume them. See tutorial on Rabbitmq Documentation https://www.rabbitmq.com/tutorials/tutorial-one-python or check my script log_producer.py & log_aggregtor.py on my github

Install pika

pip install pika

Run the producer script

python3 log_prodcer.py "Log Entry 1: Data ready for processing in AWS Lambda"

Run the consumer script.

python3 log aggregator.py

Note: Perform step 10 several times with different messages to send and capture multiple logs

11. Verify Logs

Open the aggregated_logs.txt file to ensure all logs are captured

Challenges

Port configuration and permission management. At first, I could not create the logs_queue as it was returning Access Denied. Then, I granted my user the needed permission to vHosts and created EC2 Security group that allows TCP port 15672 to access the RabbitMQ management console.
After creating a queue successfully, I could not log in to the RabbitMQ Management console with the credentials I created. I discovered I had to tag the user as part of Management to be able to log in.

rabbitmqctl set_user_tags username management

Key Learnings

Enabling Management Plugin: I learnt to enable and use the RabbitMQ management plugin for web-based monitoring and management.
User and Permission Management: Gained skills in creating users, setting passwords, and managing permissions in RabbitMQ.
Queue Management: I learned how to create and manage queues both via the management interface and command line.
Port Configuration: Understanding the importance of configuring and managing RabbitMQ ports (5672 for AMQP traffic and 15672 for the management console).

Advanced AWS S3 Bucket Metadata Manipulation

Fidelis Ikoroje — Fri, 29 Nov 2024 23:14:11 +0000

Objective

Using a Python script to analyse, modify, and optimise AWS S3 bucket metadata from a JSON file. The script should achieve the following:

Print a summary of each bucket: Name, region, size (in GB), and versioning status
Identify buckets larger than 80 GB from every region which are unused for 90+ days.
Generate a cost report: total s3 buckets cost grouped by region and department. Highlight buckets with:
- Size > 50 GB: Recommend cleanup operations.
- Size > 100 GB and not accessed in 20+ days should be added to a deletion queue.
Provide a final list of buckets to delete (from the deletion queue). For archival candidates, suggest moving to Glacier.

Prerequisite

Install Python 3 on your system
JSON file (buckets.json) containing S3 bucket metadata

Script Documentation & Explanation

Task 1: Importing Necessary Modules

import json
from datetime import datetime, timedelta

json: This module is used to parse JSON data.
datetime, timedelta: These are used to handle dates and times.

Task 2: Load & Parse the JSON file

with open('buckets.json') as file:
    data = json.load(file)
    buckets = data["buckets"]

Opens the buckets.json file.
Parses the JSON data from the file.
Extracts the list of buckets from the parsed data.

Task 3: Define Helper Function

def days_since_created(created_on):
    created_date = datetime.strptime(created_on, '%Y-%m-%d')
    return (datetime.now() - created_date).days

def print_bucket_summary(bucket):
    print(f"Name: {bucket['name']}")
    print(f"Region: {bucket['region']}")
    print(f"Size (GB): {bucket['sizeGB']}")
    print(f"Versioning: {'Enabled' if bucket['versioning'] else 'Disabled'}\n")

days_since_created: Calculates the number of days since a bucket was created.
print_bucket_summary: Prints a summary of each bucket’s details (name, region, size, and versioning status).

Task 4: Initialise Data Structure for Report

large_unused_buckets = []
cleanup_candidates = []
deletion_queue = []
region_costs = {}
department_costs = {}

large_unused_buckets, cleanup_candidates, deletion_queue: Lists to store specific buckets based on defined criteria.
region_costs, department_costs: Dictionaries to store cost data grouped by region and department.

Task 5: Analyse & Modify Bucket Data

for bucket in buckets:
    print_bucket_summary(bucket)

    if bucket['sizeGB'] > 80 and days_since_created(bucket['createdOn']) > 90:
        large_unused_buckets.append(bucket)

    if bucket['sizeGB'] > 50:
        cleanup_candidates.append(bucket)
    if bucket['sizeGB'] > 100 and days_since_created(bucket['createdOn']) > 20:
        deletion_queue.append(bucket)

    cost_per_gb = 0.023
    region_costs.setdefault(bucket['region'], 0)
    region_costs[bucket['region']] += bucket['sizeGB'] * cost_per_gb

    department = bucket['tags']['team']
    department_costs.setdefault(department, 0)
    department_costs[department] += bucket['sizeGB'] * cost_per_gb

Loop through buckets: Iterates over each bucket in the list.
Print summary: Calls print_bucket_summary to display details.
Identify large unused buckets: Adds buckets larger than 80 GB and unused for over 90 days to large_unused_buckets.
Highlight cleanup candidates: Adds buckets larger than 50 GB to cleanup_candidates.
Add to deletion queue: Adds buckets larger than 100 GB and not accessed for more than 20 days to deletion_queue.
Calculate costs: Computes and updates the costs for each region and department.

Task 6: Generate Cost Report & Cleanup Recommendation

print("\nCost Report by Region:")
for region, cost in region_costs.items():
    print(f"{region}: ${cost:.2f}")

print("\nCost Report by Department:")
for department, cost in department_costs.items():
    print(f"{department}: ${cost:.2f}")
print("\nBuckets Recommended for Cleanup:")
for bucket in cleanup_candidates:
    print(f"- {bucket['name']} (Size: {bucket['sizeGB']} GB)")

Cost Report by Region: Prints the total cost grouped by region.
Cost Report by Department: Prints the total cost grouped by department.
Buckets Recommended for Cleanup: Prints the list of buckets recommended for cleanup (those larger than 50 GB).

Task 7: Generate Deletion Queue & Buckets to Archive

print("\nBuckets in Deletion Queue:")
for bucket in deletion_queue:
    print(f"- {bucket['name']} (Size: {bucket['sizeGB']} GB)")
print("\nFinal List of Buckets to Delete or Archive:")
for bucket in deletion_queue:
    if bucket['sizeGB'] > 100:
        print(f"- {bucket['name']} (Size: {bucket['sizeGB']} GB) [Move to Glacier]")
    else:
        print(f"- {bucket['name']} (Size: {bucket['sizeGB']} GB) [Delete]")

Buckets in Deletion Queue: Prints the list of buckets in the deletion queue (those larger than 100 GB and not accessed for more than 20 days).
Final List of Buckets to Delete or Archive: Prints the final list of buckets to delete or move to Glacier, based on their size.

Sample Output

Here is my output when I ran python s3-analysis.py

Input: Name: prod-data, Region: us-west-2, Size: 120 GB, Versioning: Enabled
Name: dev-app-logs, Region: us-east-1, Size: 10 GB, Versioning: Disabled
Name: backup, Region: eu-central-1, Size: 80 GB, Versioning: Enabled
Name: audit-logs, Region: ap-southeast-1, Size: 50 GB, Versioning: Enabled
Name: test-results, Region: us-west-1, Size: 15 GB, Versioning: Disabled
Name: old-backups, Region: us-east-2, Size: 200 GB, Versioning: Enabled
Name: staging-resources, Region: eu-west-1, Size: 30 GB, Versioning: Disabled
Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Versioning: Enabled
Name: raw-data, Region: us-west-2, Size: 90 GB, Versioning: Disabled
Name: compliance-data, Region: ca-central-1, Size: 300 GB, Versioning: Enabled

Cost Report by Region:
us-west-2: $4.83
us-east-1: $0.23
eu-central-1: $1.84
ap-southeast-1: $1.15
us-west-1: $0.34
us-east-2: $4.60
eu-west-1: $0.69
ap-northeast-1: $5.75
ca-central-1: $6.90

Cost Report by Department:
analytics: $8.51
engineering: $0.23
ops: $6.44
security: $1.15
qa: $0.34
development: $0.69
data-engineering: $2.07
compliance: $6.90

Buckets Recommended for Cleanup:
- Name: prod-data, Region: us-west-2, Size: 120 GB
- Name: backup, Region: eu-central-1, Size: 80 GB
- Name: old-backups, Region: us-east-2, Size: 200 GB
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB
- Name: raw-data, Region: us-west-2, Size: 90 GB
- Name: compliance-data, Region: ca-central-1, Size: 300 GB

Buckets in Deletion Queue:
- Name: prod-data, Region: us-west-2, Size: 120 GB, Days Unused: 414
- Name: old-backups, Region: us-east-2, Size: 200 GB, Days Unused: 1567
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Days Unused: 1352
- Name: compliance-data, Region: ca-central-1, Size: 300 GB, Days Unused: 1063

Final List of Buckets to Delete or Archive:
- Name: prod-data, Region: us-west-2, Size: 120 GB, Days Unused: 414 [Move to Glacier]
- Name: old-backups, Region: us-east-2, Size: 200 GB, Days Unused: 1567 [Move to Glacier]
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Days Unused: 1352 [Move to Glacier]
- Name: compliance-data, Region: ca-central-1, Size: 300 GB, Days Unused: 1063 [Move to Glacier]
Name: prod-data, Region: us-west-2, Size: 120 GB, Versioning: Enabled
Name: dev-app-logs, Region: us-east-1, Size: 10 GB, Versioning: Disabled
Name: backup, Region: eu-central-1, Size: 80 GB, Versioning: Enabled
Name: audit-logs, Region: ap-southeast-1, Size: 50 GB, Versioning: Enabled
Name: test-results, Region: us-west-1, Size: 15 GB, Versioning: Disabled
Name: old-backups, Region: us-east-2, Size: 200 GB, Versioning: Enabled
Name: staging-resources, Region: eu-west-1, Size: 30 GB, Versioning: Disabled
Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Versioning: Enabled
Name: raw-data, Region: us-west-2, Size: 90 GB, Versioning: Disabled
Name: compliance-data, Region: ca-central-1, Size: 300 GB, Versioning: Enabled

Cost Report by Region:
us-west-2: $4.83
us-east-1: $0.23
eu-central-1: $1.84
ap-southeast-1: $1.15
us-west-1: $0.34
us-east-2: $4.60
eu-west-1: $0.69
ap-northeast-1: $5.75
ca-central-1: $6.90

Cost Report by Department:
analytics: $8.51
engineering: $0.23
ops: $6.44
security: $1.15
qa: $0.34
development: $0.69
data-engineering: $2.07
compliance: $6.90

Buckets Recommended for Cleanup:
- Name: prod-data, Region: us-west-2, Size: 120 GB
- Name: backup, Region: eu-central-1, Size: 80 GB
- Name: old-backups, Region: us-east-2, Size: 200 GB
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB
- Name: raw-data, Region: us-west-2, Size: 90 GB
- Name: compliance-data, Region: ca-central-1, Size: 300 GB

Buckets in Deletion Queue:
- Name: prod-data, Region: us-west-2, Size: 120 GB, Days Unused: 414
- Name: old-backups, Region: us-east-2, Size: 200 GB, Days Unused: 1567
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Days Unused: 1352
- Name: compliance-data, Region: ca-central-1, Size: 300 GB, Days Unused: 1063

Final List of Buckets to Delete or Archive:
- Name: prod-data, Region: us-west-2, Size: 120 GB, Days Unused: 414 [Move to Glacier]
- Name: old-backups, Region: us-east-2, Size: 200 GB, Days Unused: 1567 [Move to Glacier]
- Name: app-analytics, Region: ap-northeast-1, Size: 250 GB, Days Unused: 1352 [Move to Glacier]
- Name: compliance-data, Region: ca-central-1, Size: 300 GB, Days Unused: 1063 [Move to Glacier]

I left out the bucket metadata and script to avoid overstretching this post.

Check my Github for the full Python script and the AWS S3 Bucket Metadata

Challenges

Data Parsing Issues: Initially faced issues with JSON parsing due to structure variations. 🛠️
Colorisation in Terminal: Implementing colored output for better readability took some trial and error. Copilot helped me here 🎨
Debugging and Validation: Ensuring accurate bucket metadata and handling edge cases was critical. 🕵️‍♂️

Conclusion

This analysis is crucial for organisations to manage their cloud resources effectively, optimise costs, and ensure efficient storage utilisation. Regular audits and optimisations can lead to significant savings and better resource allocation.

Building a Scalable, High-Availability Web Application on AWS with Managed Services

Fidelis Ikoroje — Mon, 11 Nov 2024 22:14:38 +0000

In this post, I’ll walk through the architecture and implementation of a redesigned multi-tier web application hosted on AWS. This updated design leverages AWS-managed services such as Amazon MQ, RDS MySQL, and ElastiCache to enhance scalability, reliability, and ease of management. I also used AWS Elastic Beanstalk for deploying the front-end application. From setting up the infrastructure to securing and optimizing it, here’s a complete look at how I implemented the architecture.

Just before the implementation, let us see the importance and benefits of this architecture compared to the previous architecture which does not include AWS-managed services.

1. Enhanced Reliability with Managed Services
By adopting services like Amazon RDS for MySQL, Amazon MQ, and ElastiCache, we've minimized the need for manual intervention, reducing the risk of service outages and improving overall system stability. For example, RDS offers automated backups and failover support, ensuring the application can handle disruptions seamlessly.

2. Simplified Application Deployment with Elastic Beanstalk
Elastic Beanstalk automates application deployment, including autoscaling and load balancing. This allows us to focus on developing new features rather than managing infrastructure. For instance, the app can now auto-scale during high traffic, reducing the risk of downtime.

3. Optimized Global Performance through CloudFront
With CloudFront as our CDN, users from different regions experience faster load times by caching content closer to them. For example, users in Europe or Asia access cached content locally instead of waiting for data to travel from a single data center.

4. Improved Security and Compliance
Using AWS-native services strengthens security with automatic encryption and compliance controls. ACM certificates for HTTPS, combined with fine-grained IAM permissions, protect user data and comply with global standards.

5. Cost Efficiency through Automation
Elastic Beanstalk and managed services optimize resource use, which can reduce overall costs. For example, auto-scaling ensures we only pay for resources when needed, instead of maintaining idle servers.

Overall, this architecture improves user experience, scales effortlessly, and simplifies management, making it a sustainable solution for long-term growth.

Enhanced Implementation Outline with Steps:

1. Create Security Key Pairs and Security Groups

Key Pair: Generate a key pair for SSH access should there be a need to access the EC2 instances.
Security Groups: Define security groups for:
- Frontend (Elastic Beanstalk): I allowed Elastic Beanstalk to create this with inbound rules for HTTP (port 80) and HTTPS (port 443) on its Application Load Balancer.
- Backend Services: I created one security group for RDS, Amazon MQ, and ElastiCache with rules that allow inbound access only from the Elastic Beanstalk environment. Also, I allowed all traffic from itself (the backend security group) so that each backend service can communicate with the other.

2. Backend Services (RDS, Amazon MQ, ElastiCache)

Parameter Groups and Subnet Groups:
- RDS: Configure custom settings in a parameter group for optimized performance and create a subnet group for database availability.
- Amazon MQ and ElastiCache: Create separate parameter and subnet groups to set up specific configurations for Amazon MQ and ElastiCache.
Launch Instances:
- Launch RDS (MySQL), Amazon MQ (ActiveMQ), and ElastiCache (Memcached) instances with the backend security group.

RDS mysql running

3. Initialize Database on RDS

Ubuntu EC2 Instance:
- Launch an EC2 instance with SSH access to connect to RDS. This Ubuntu instance will be our mysql client. Ensure RDS security group (backend) allows traffic from mysql client.
- Once launched, SSH to the mysql client, update packages, and install necessary tools like git to clone the repository containing database files.

ssh -i "abc-keypair.pem" ubuntu@ec2-35-179-168-111.eu-west-2.compute.amazonaws.com
sudo -i
apt update && apt install mysql-client git -y

Database Initialization:
- Clone the repository that contains the database info and switch to the branch awsrefactor, which contain db_backup.sql from here.

git clone repourl
git checkout awsrefactor

Import the db_backup.sql file into the accounts database on a MySQL server hosted on Amazon RDS

mysql -h [RDS endpoint] -u admin -p accounts < src/main/resources/db_backup.sql

Verify tables using MySQL commands; then terminate the mysql client instance if needed because we don't need it anymore.

mysql -h [RDS endpoint] -u admin -p accounts
show tables;

4. Set Up Elastic Beanstalk Environment

Service Role Creation: Create a role with permissions (AdministratorAccess-AWSElasticBeanstalk, AWSElasticBeanstalkCustomPlatformforEC2Role, AWSElasticBeanstalkRoleSNS, AWSElasticBeanstalkWebTier) to manage Elastic Beanstalk and handle S3 and SNS notifications.
Setting Up Elastic Beanstalk Environment:
- Choose Tomcat 10 with Corretto 21 on Amazon Linux 2023.
- Configure health checks on /login.
- Set up HTTPS listener on port 443 for the Elastic Load Balancer (ELB).
Update Backend Security Group: Allow traffic from Elastic Beanstalk to the backend services (RDS, MQ, and ElastiCache).
Artifact Deployment: Deploy your built web application, including backend information, to Elastic Beanstalk. I simply uploaded the artifact from my system to Elastic Beanstalk. However, you can also upload to S3 and point Elastic Beanstalk to the bucket containing the file. See the process to build the artifact and also upload it to S3 in this project.

Beanstalk Environment Launched

6. Set Up CloudFront and SSL Certificate

SSL Certificate: Request an SSL certificate in us-east-1 for CloudFront distribution.
CloudFront Distribution:
- Create a CloudFront distribution and set the Elastic Load Balancer as the origin domain.
- Enable HTTP and HTTPS protocols for improved compatibility and security.
DNS Mapping: Use Route 53 to create a CNAME record in the public hosted zone, linking the CloudFront endpoint to the App custom domain.

CloudFront endpoint mapped to App domain name in Route53

7. Testing and Verification

Application Testing: Access the application via the custom domain to confirm traffic routing through CloudFront.
CloudFront Validation: Use development tools or AWS CloudFront analytics to ensure CloudFront is serving content.

App is reachable on HTTP port 80 and HTTPS port 443

App connected to backend services

Mozilla Firefox showing traffic is coming into the App via AWS CloudFront

8. Challenges & Lessons Learned

I learned a lot from this project but one stood out - checking documentation first before considering other resources. I ran into issues creating my Elastic Beanstalk Environment. I saw the notification that launch configuration is now deprecated in favour of launch template from October 1, 2024 details here. However, I thought I would breeze through and consult other resources including ChatGPT which proffered some complex solutions. I managed to crack it by checking AWS Elastic Beanstalk documentation after spending a few hours researching other resources. See the error screenshots below.

Conclusion

Building this multi-tier web application with AWS-managed services provided me with valuable insights into scalable architecture, automated deployment, and cloud security. Leveraging services like Amazon MQ, RDS MySQL, and ElastiCache simplified management and improved performance. Using Elastic Beanstalk for deployment streamlined the process and provided built-in support for scaling and load balancing.

For future enhancements, I may decide to containerize my application with further automating deployment with CI/CD pipelines, or exploring serverless options for even greater scalability and cost efficiency.

Building a Scalable Multi-Tier Web Application on AWS

Fidelis Ikoroje — Fri, 01 Nov 2024 20:17:59 +0000

Introduction

In this post, I’ll walk through the architecture and implementation of a multi-tier web application hosted on AWS. Designed for scalability and high availability, this application uses an autoscaling group of EC2 instances to serve web requests, with a dedicated backend infrastructure for queue management, database storage, and caching. From setting up the infrastructure to securing and optimizing it, here’s a complete look at how I brought this project to life on AWS.

Requirements

Before diving into the implementation, let’s start with the requirements:

Web Application Server: Hosted on Tomcat 10, listening on port 8080 on EC2 instances.
Web Application Source Code: Build one or fork from github. Also, all the EC2 userdata scripts are in the GitHub repository to reduce the length of this post.
Load Balancing and Autoscaling: Application Load Balancer (ALB) in front of an EC2 Autoscaling Group to handle web traffic.
Backend Servers:
- RabbitMQ for message queuing services.
- MySQL for user data and web app credentials.
- Memcached for caching content to improve performance.
Domain and SSL: A custom domain with HTTPS enabled using AWS Certificate Manager (ACM).
DNS Management: Route 53 to manage DNS for both public and private traffic.
AWS CLI & Maven: AWS CLI to interact with AWS environment & Maven to build code

Architecture Design

This is a classic three-tier architecture:

Presentation Layer (Web App Frontend): Autoscaling EC2 instances running Tomcat.
Application Layer (Service Backend): Consists of RabbitMQ, MySQL, and Memcached instances.
Data Layer (Database and Caching): MySQL for persistence and Memcached for caching.

Implementation Steps

1. Creating Key Pairs and Security Groups

Key Pair: Create a key pair to access all EC2 instances via SSH.
Security Groups: Configured three security groups:
- Web Application Security Group: Allow inbound traffic on port 8080 from the ALB.
- Backend Security Group: Allow traffic from the web application for communication with RabbitMQ (port 5672), MySQL (port 3306), and Memcached (port 11211). Also, add a rule to the backend security group that allow traffic from itself. This ensures the backend instances can communicate with themselves internally.
- Application Load Balancer Security Group: Allow inbound traffic on ports 80 (HTTP) and 443 (HTTPS) for the ALB. Also, allow SSH on port 22 into all your instances and pick the source as MYIP so only your permitted IP can access instances.

2. Launching EC2 Instances with User Data Scripts

Database Instance: Launch MySQL instance and include a user data script to automatically install the MySQL server upon boot. It will also create a user to access your webapp. SSH into the MYSQL instance from your local system then confirm the database is running.

ssh -i "keypair.pem" ubuntu@ec2-public-ip

systemclt status mariadb

mysql -u username -p accounts

show tables;

Memcached Instance: Launch a separate instance for Memcached, using a user data script to install and configure the service.

Confirm the service is running

systemctl status memcached

RabbitMQ Instance: Also, using the user data script, launch and configure Rabbitmq instance for message queue handling.

Confirm the service is running

systemctl status rabbitmq-server

Web Application EC2: Launch a Tomcat 10 server instance to serve the web application using Ubuntu AMI. Create EC2 role that grants read and write access to s3 and attach it to the EC2.

3. Configuring Route 53 for DNS

Domain Registration and SSL: Register a domain with Route 53, request an SSL certificate through ACM, and create a public hosted zone.
Public DNS: Add a CNAME record pointing the ALB’s endpoint to the domain for HTTPS access.
Private DNS: Create a private hosted zone with A records for the backend services’ private IP addresses to allow internal communication by name. Ensure you update the route53 internal record in your application.properties file.

4. Building and Deploying the Application Code

S3 Bucket Creation: Create an S3 bucket to store the application artifact.
IAM Role: Assign an IAM role to the web application EC2 instance to allow S3 access.
Application Build: Build the application using Maven on the local machine and uploaded the artifact to S3.
Code Deployment: SSH into the web application EC2, downloaded the artifact from S3, and deployed it to the Tomcat server. Each step is defined below.

create a bucket that will hold the web app artifact

aws s3api create-bucket --bucket fozwebapp-artifact --region eu-west-2 --create-bucket-configuration LocationConstraint=eu-west-2

Run Maven from the directory that holds the source code in your local system

mvn install

Copy the artifact from your local system to the s3 bucket. Then, SSH into the instance, install AWS CLI and copy the artifact from s3 into the EC2 instance.

aws s3 cp target/vprofile-artifact s3://fozwebapp-artifact

Install AWS CLI and copy artifact from s3 to /tmp/ in EC2

snap install aws-cli --classic

aws s3 cp s3://fozwebapp-artifact/vprofile-v2.war /tmp/

Now, stop tomcat10 on the EC2, remove the default directory of tomcat10, and replace it with the artifact the restart. Run each of the commands one after the other. Lastly, you can confirm tomcat10 is running

systemctl daemon-reload
systemctl stop tomcat10
rm -rf /var/lib/tomcat10/webapps/ROOT
cp /tmp/vprofile-v2.war /var/lib/tomcat10/webapps/ROOT.war
systemctl start tomcat10

5. Setting Up the Application Load Balancer

Target Group Creation: Configure an ALB target group for the autoscaling EC2 instances, setting listener and health checks on port 8080 to ensure only healthy instances serve traffic.
HTTPS Configuration: Configure the ALB to use the SSL certificate from ACM.
DNS Mapping: Map the domain’s CNAME record in Route 53 to the ALB for secure, HTTPS-enabled access.

Application Loadbalance Endpoint mapped to app domain name

6. Connecting to the Web Application and Verifying

Access Verification: Access the web app through the custom domain and verify load balancer forwarding by inspecting responses from the Tomcat server.
Service Checks: SSH into each backend instance to ensure that RabbitMQ, MySQL, and Memcached services were running and accessible by the web application server.

7. Configuring Auto Scaling for the Web Application EC2 Instances

Autoscaling Policies: Set up scaling policies to adjust the number of EC2 instances in response to application load.
Monitoring and Logging: Enabled CloudWatch metrics to monitor CPU and request metrics, triggering autoscaling when defined thresholds were met.

How the Web Application Works

User Access: Users access the application via the custom domain. The ALB handles the HTTPS requests and forwards them to Tomcat servers running in the autoscaling group.
Backend Processing: When a web request involves queuing or caching, the application server communicates with RabbitMQ and Memcached instances. For user data requests, it connects to MySQL.
Scaling and Availability: The autoscaling group dynamically adjusts based on load, ensuring efficient handling of fluctuating traffic.

Possible Improvements for the Architecture

Containerization of applications and deployment with kubernetes Enhanced scalability, automated management, and flexibility for microservices deployment.
Employ AWS serverless solutions like Lamba, API Gateway, AWS RDS in place of MYSQL, ElastiCache, and MQ in place of Memcached & Rabbitmq
Elastic Beanstalk to simplify deployment, scaling, and monitor without direct server management.
Front load balance with Cloudfront or AWS Global Accelerator depending on the type of content the app is serving.

Lessons Learned and Final Thoughts

Building this multi-tier web app on AWS provided valuable insights into scalable architecture, automated deployment, and cloud security. Leveraging AWS services, I achieved a setup that balances performance with resilience, laying a foundation for future applications. Lastly, I will look into the possible improvements above in my next project.

DEV Community: Fidelis Ikoroje

My DevOps Portfolio Site Is Live – Built with Real Infrastructure, Real Tools

Why This Portfolio Stands Out

Behind the Scenes: Tech Stack & Infrastructure

Frontend: Simple Yet Powerful

AWS Cloud Architecture

DevOps & Automation

Privacy-First Analytics (No Google Tracking!)

Key Features at a Glance

Why This Matters

What’s Your Favorite Feature?

Follow Me

How to Install Amazon Q CLI on Windows

Steps to Install Amazon Q CLI on Windows

Step 1. Install WSL ( Windows Subsystem for Linux)

Step 2: Start Ubuntu in WSL

Step 3: Install unzip from your home directory

Step 4: Download Amazon Q CLI Installer

Step 5: Unzip the Installer, Setup & Run

Step 6: Reload & login

Step 7: Start Amazon Q Developer

Tips for Using Amazon Q CLI

🧠 Things to Know About Amazon Q CLI

Video Guide

Game Development with Amazon Q CLI

✅ Conclusion

Serverless Image Resizer on AWS

Prerequisites

Project Structure

🧱 Architecture Overview

🧩 The Development Process

1. Bucket Setup

2. Frontend UI

3. Backend: Serverless Power with API Gateway & Lambda

API Gateway: The Traffic Controller

Lambda Functions: Specialized Workers

4. CloudFront Distribution

CI/CD with GitHub Actions

🌐 Live Project

How to Use the Application

✅ Results

🔭 Next Steps

🏁 Conclusion

💬 Connect With Me

Deploying DeepSeek Model R1 on AWS via Terraform & GitHub Actions - Update

Table of Contents

1. Introduction

2. Project Overview

3. Terraform Configuration & Data

AWS Provider & VPC Configuration

Security Groups

Load Balancer (ALB) & Listener

EC2, IAM & VPC Endpoints

Route 53 DNS Record

AWS WAF Configuration

Terraform Backend (S3)

Variables Configuration

Terraform.tfvars

Output Configuration

4. GitHub Actions Workflow

Workflow Triggers

Setup Job

Apply Job

Post-Apply Job

Destroy Job

5. The Application in Action (Result)

1. OpenWebUI Interface

2. Model Interaction

3. Infrastructure Clean Up

6. Challenges Faced & Lesson Learned

7. Future Improvements

8. Conclusion

Hosting a Serverless Resume Website on AWS with Terraform and CI/CD

Project Overview

1. Terraform Configuration

I. Provider Block & Terraform State Management

II. Frontend: S3 & CloudFront

S3, Policy & CORS

CloudFront Distribution

Challenges & Strategies