A hands‑on, end‑to‑end cloud engineering project demonstrating containerization, image delivery, infrastructure provisioning, and manual orchestration on AWS.

Overview

This project walks through the full lifecycle of deploying the HumanGov application using a modern, container‑based architecture. I implemented the solution in three phases:

1. Containerization & Image Delivery — Packaging the Flask backend and NGINX reverse proxy into Docker images and publishing them to Amazon ECR.
2. Infrastructure Provisioning with Terraform — Automating the creation of S3, DynamoDB, and an ECS cluster using clean, modular Terraform code.
3. Manual Deployment on ECS Fargate — Creating task definitions, configuring networking, and deploying the application through an ECS service fronted by an Application Load Balancer.

The goal was to demonstrate not only technical execution, but also the operational reasoning behind each step — why the architecture works, how the components interact, and how to keep the environment secure, reproducible, and cost‑controlled.

Part 1 — Containerization & Image Delivery (Docker + ECR)

Objective

Prepare the HumanGov application for a cloud‑native runtime by packaging both the backend and the webserver into lightweight, production‑ready Docker images.

1. Application Container (Flask + Gunicorn)

I created a Dockerfile that builds a minimal Python 3.8 environment, installs dependencies, and runs the Flask app behind Gunicorn:

• Base image: python:3.8-slim-buster
• Dependency installation via pip — no-cache-dir
• Application served through Gunicorn on port 8000
• Image tested locally before publishing

This ensures a deterministic runtime and eliminates configuration drift between local and cloud environments.

2. ECR Repository & Image Push

I created an ECR repository (humangov-app), authenticated the Docker client, and pushed the image. This step validates the full image lifecycle:

• Build
• Tag
• Authenticate
• Push
• Verify in ECR console

Once the application image was published, I repeated the process for the NGINX reverse proxy.

3. Webserver Container (NGINX Reverse Proxy)

To front the Flask app, I built a second container using nginx:alpine:

• Removed default NGINX config
• Added a custom nginx.conf and proxy_params
• Configured reverse proxy to forward traffic to the backend on port 8000
• Exposed port 80 for external access

This separation of concerns mirrors real production patterns: application logic isolated from webserver responsibilities.

Part 2 — Infrastructure Provisioning (Terraform)

Objective

Provision the foundational AWS resources required by the application using clean, modular Terraform code.

1. Remote State & Code Adjustments

Since this deployment uses ECS Fargate instead of EC2, I removed EC2‑related resources from the module while preserving:

• DynamoDB (PAY_PER_REQUEST)
• S3 bucket (randomized suffix for global uniqueness)

This keeps the infrastructure minimal, cost‑efficient, and aligned with the container‑based architecture.

2. Terraform Execution

From the human-gov-infrastructure/terraform directory:

• terraform plan → 3 resources to add
• terraform apply -auto-approve → S3 + DynamoDB successfully provisioned

I captured the outputs for later use in ECS:

• AWS_DYNAMODB_TABLE
• AWS_BUCKET
• AWS_REGION
• US_STATE

These values become environment variables inside the application container.

Part 3 — Manual Deployment on AWS ECS Fargate

Objective

Deploy the full stack manually to highlight the operational complexity that automation (CI/CD, IaC) eventually removes.

1. IAM Role for Task Execution

I created a dedicated IAM role (HumanGovECSExecutionRole) granting:

• AmazonS3FullAccess
• AmazonDynamoDBFullAccess
• AmazonECSTaskExecutionRolePolicy

This ensures the running containers can securely access required AWS services.

2. ECS Cluster Creation

I created an ECS cluster (humangov-cluster) using the console. Although the cluster uses Fargate (serverless), ECS still requires a logical cluster boundary for task scheduling.

3. Task Definition (Full‑Stack)

I built a task definition (humangov-fullstack) with two containers:

Container 1 — Application

• Image: humangov-app
• Port: 8000
• Essential: Yes
• Environment variables: S3 bucket, DynamoDB table, region, state

Container 2 — NGINX

• Image: humangov-nginx
• Port: 80
• Essential: No
• Protocol: HTTP

This creates a clean separation between backend logic and webserver routing.

4. ECS Service + Load Balancer

I deployed the task definition as a service (humangov-svc) with:

• Launch type: Fargate
• Desired count: 2 tasks (HA)
• Networking: Default VPC + default SG (port 80 allowed)
• Load Balancer: Application Load Balancer
• Target group: humangov-tg

The ALB routes traffic to the NGINX container, which forwards requests to the Flask backend.

Once the service stabilized, ECS automatically distributed tasks across multiple AZs for resilience.

Validation

I accessed the ALB DNS name and tested the application end‑to‑end:

• Submitted employee data
• Uploaded a PDF
• Verified S3 storage
• Confirmed DynamoDB record creation

The full workflow executed successfully across the containerized architecture.

Cleanup

To avoid unnecessary cost, I removed all resources:

• Deleted ECS service, task definition, and cluster
• Deleted ECR repositories
• Removed uploaded PDFs from S3
• Ran terraform destroy to remove S3 + DynamoDB

This returned the environment to a clean state.

Key Takeaways

This project demonstrates:

• Containerization discipline (multi‑container architecture, reverse proxying, lightweight images)
• Cloud‑native deployment patterns using ECS Fargate
• Infrastructure automation with Terraform modules
• Secure IAM design for least‑privilege execution
• Operational awareness around cost, cleanup, and lifecycle management

It’s a complete, production‑aligned workflow that mirrors how modern organizations deploy microservices and containerized workloads at scale.

🧱 Part 1 — Provisioning the Foundation with Terraform

I started by validating and extending the recently created Terraform module to support everything the HumanGov application needed:

• IAM Role + Instance Profile for EC2
• S3 bucket and DynamoDB table with dynamic naming
• Security groups for SSH, HTTP, and app traffic
• A validated Ubuntu AMI
• Provisioners that automatically update Ansible’s inventory

This phase reinforced why I rely on IaC: one plan, one apply, and the entire environment stands up identically every time. No drift, no guesswork.

💡 Why I Hosted the Project on GitHub

I HOSTED the entire HumanGov deployment in a public GitHub repository. This allowed me to treat the project like a real engineering deliverable — versioned, reviewable, and easy for others to clone and reproduce. It also gave recruiters and hiring managers a transparent view into my Terraform modules, Ansible roles, and the overall structure of the deployment.

🤖 Part 2 — Automating Deployment with Ansible

With Terraform handling provisioning, Ansible took over configuration and application deployment. I built a complete Ansible role with:

• Tasks for package installation, directory creation, and virtual environment setup
• Handlers for restarting Nginx and Gunicorn
• Jinja templates for the systemd service and Nginx proxy
• Defaults and variables for clean parameterization

Running the playbook transformed a raw set of four EC2 instances into fully configured HumanGov environments — consistently, repeatably, and in a fraction of the time.

Designed to be a national project, a new instance could be added for any state by adding the state’s name to the Terraform module.

As someone passionate about cloud engineering, automation, and incoming AI strategy, I wanted to explore how large language models (LLMs) could be deployed affordably — without enterprise infrastructure or massive budgets. So, I built a public-facing AI app using:

This project helped me sharpen my skills in container orchestration, API integration, and cost modeling — while creating a live demo I could share with recruiters and hiring managers. You can see it in action:

https://garyscloudmart.gbnetassure.com

🛠️ Technical Setup

1. AWS Lightsail Container

• Specs: 1 GB RAM, 0.25 vCPU
• Cost: $7/month (90-day free trial!)
• Deployment: Docker container running a lightweight frontend that calls OpenRouter’s API

2. OpenRouter API (OpenRouter.ai)

• Model: Initially launched with DeepSeek-V3 Free but was upgraded to Standard version after noticing inconsistent performance even with light usage.
• As for the Upgrade:
• Faster response times
• More reliable output
• Better user experience for recruiters and hiring managers

3. Custom Domain

• Configured via an external DNS provider (Azure DNS) and used AWS’s own generated SSL/TLS certificates. Required modest effort for proof of domain ownership to complete.
• Public endpoint: garyscloudmart.gbnetassure.com

💰 Cost Analysis

🔑 Key Highlights of the Project:

• LLMs can be deployed affordably with the right architecture and token strategy.
• OpenRouter’s flexible tiers make it easy to scale from free experimentation to reliable public demos.
• Lightsail’s simplicity is perfect for quick deployments and public showcases.
• DeepSeek-V3 Standard offers strong performance in reasoning, coding, and multilingual tasks — ideal for showcasing AI capabilities.

🎯 What’s Next

I’m exploring:

• Adding analytics to track usage and engagement
• Writing scenario-based prompts to demonstrate real-world applications (e.g. resume rewriting, SQL generation, cybersecurity Q&A)
• Comparing performance across models like Claude 3, Gemini Pro, and GPT-4

🤝 Let’s Connect

If you’re hiring for roles in cloud engineering, automation, or AI strategy — or just curious about deploying LLMs in lean environments — I’d love to chat.

Feel free to try the app, share feedback, or reach out directly!

#AWS #GenerativeAI #CloudComputing #PortfolioProject #TechInnovation #Ecommerce

In another project based in a real-world scenario, I acted as the Cloud Specialist responsible for migrating a workload running in a Corporate DataCenter to AWS.

The application and database were migrated to AWS using the Lift & Shift (rehost) model, moving both application and database data.

I followed some migration steps: Planning (sizing, prerequisites, resource naming), Execution (resource provisioning, best practices), Go-live (validation test — Dry-run, final migration — Cutover) and Post Go-live (ensure the operation of the application and user access).

After drawing up the plan to do the lift and shift the VPC was created and an EC2 VM was built for the application to reside on:

A MySQL database was provisioned in Amazon’s RDS service, and attached to our new VPC:

After this I needed to download some app dependencies and the backup to the MySQL database but could not connect at first. An Internet Gateway was needed:

Now that the downloads were completed, installed the application dependencies on the Ubuntu app server:

Getting close now, attaching to the database:

I failed to get screenshots of creating and restoring the database and installing the app. I hope you’ll forgive! The final result was this website, and you can see I was able to insert an article at the end:

Thank you for checking out my project, if you have any comments or questions, please add them!

In this project based on a real-world scenario, I acted as a Cloud Specialist with the mission to migrate users in an automated way and manage AWS IAM (Identity and Access Management) resources.

There were 100 users that needed to be migrated and have MFA (Multi-factor authentication) enabled on their accounts, as this is a security best practice. They also needed to be added to groups to ensure their permissions.

To avoid repetitive and manual tasks in the AWS console, I needed to think about automating the processes.

Using GitBash with AWS CLI and Shell Script, I added 5 users to the IAM interface as a POC of the process:

And here is the result:

Thank you for taking a look at this project! If you have any comments or questions, please add them!