Project Showcase

Real cloud and DevOps projects built for reliability.

Each project covers the problem, solution, and infrastructure behind it.

Browse Projects Start a Conversation

Projects Library

Expand any card for implementation details, outcomes, tech stack, article links, and supporting delivery context.

Featured

Production-Grade Drupal Platform on AWS with Full DevOps Automation

Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture Drupal DevOps Platform Architecture

Production-grade Drupal 11 platform on AWS using a complete DevOps toolchain, featuring Terraform IaC, secure Ansible deployment via SSM, Kubernetes orchestration, and automated GitHub Actions OIDC CI/CD.

TerraformAWSAnsibleDocker KubernetesGitHub ActionsOIDCPrometheus ELK StackAWS SSM

I built a production-grade Drupal 11 platform on AWS using a complete DevOps toolchain, with infrastructure automation, secure deployments, monitoring, and centralized logging.

The problem I solved was the complexity of managing a highly available web application across multiple servers while maintaining security, automation, and operational visibility. Traditional environments often rely on manual configuration, SSH access, and inconsistent deployment processes, which increase risk and maintenance effort.

I provisioned the entire AWS environment using Terraform, including a multi-AZ VPC, Auto Scaling Group, Application Load Balancer, RDS MySQL with a read replica, S3 storage, and CloudWatch billing alerts. Everything was deployed through code with no manual infrastructure setup.

For server management, I used Ansible with AWS Systems Manager instead of SSH. This removed the need for SSH keys, bastion hosts, and public access to servers. All configuration and deployments were performed through secure SSM connections.

I containerized Drupal using Docker and deployed it to a Kubernetes cluster for local orchestration and testing. The platform included persistent storage, Kubernetes deployments, services, ingress routing, secrets management, and horizontal pod autoscaling.

To automate releases, I built a GitHub Actions CI/CD pipeline using OIDC authentication. This removed the need for long-lived AWS credentials. Every code change automatically triggers image builds, testing, staging deployment, smoke tests, and production deployment with an approval gate.

I also implemented full observability using Prometheus, Grafana, and the ELK Stack. Metrics from EC2, Nginx, RDS, and the load balancer were collected and visualized through Grafana dashboards, while centralized log aggregation made troubleshooting faster and easier.

The platform was designed for high availability and resilience. It runs across two availability zones, automatically replaces failed instances, scales based on CPU utilization, and includes health checks, monitoring alerts, and database redundancy.

This project improved security, automated infrastructure management, reduced deployment effort, and provided complete visibility into application and infrastructure health.

Key Benefits

  • Fully automated infrastructure provisioning with Terraform
  • No SSH access or stored credentials through AWS SSM and GitHub OIDC
  • Automated CI/CD pipeline with testing, staging, and production approval flow
  • High availability across multiple AWS Availability Zones
  • Auto Scaling for increased traffic and workload demand
  • Centralized monitoring with Prometheus and Grafana
  • Centralized logging with ELK Stack and Filebeat
  • Secure network segmentation and least-privilege IAM design
  • Faster troubleshooting through real-time metrics and log analysis
  • Complete Infrastructure as Code and configuration management approach
Read Article → GitHub
Featured

Production-Grade AWS EKS Platform for a Microservices Retail Application

AWS EKS Platform Architecture

Production-grade Kubernetes platform on AWS hosting a cloud-native retail application, featuring Terraform infrastructure automation, Helm deployments, managed RDS/DynamoDB databases, and AWS Lambda event-driven processing.

TerraformAmazon EKSKubernetesHelm Amazon RDSDynamoDBAWS LambdaAmazon S3 GitHub ActionsOIDCCloudWatch

I built a production-grade Kubernetes platform on AWS for InnovateMart Inc. to host a cloud-native retail application using Amazon EKS, managed databases, automated deployments, centralized logging, and serverless event processing.

The problem I solved was deploying and managing the Retail Store microservices application in a secure and scalable environment. Running databases inside Kubernetes clusters can create operational challenges, while manual deployments and limited visibility make production systems harder to maintain.

I provisioned the entire infrastructure using Terraform, including a multi-AZ VPC (project-bedrock-vpc), an Amazon EKS cluster (project-bedrock-cluster), managed node groups, RDS databases, DynamoDB tables, IAM roles, networking components, and remote state management. Everything was deployed through Infrastructure as Code (IaC) in the us-east-1 region.

The application consisted of multiple microservices running in the EKS cluster within the retail-app namespace. Instead of using in-cluster databases, I migrated the data layer to managed AWS services. MySQL and PostgreSQL workloads were moved to Amazon RDS, while the cart service used DynamoDB. This improved reliability, reduced operational overhead, and followed cloud-native best practices.

To securely expose the application, I deployed the AWS Load Balancer Controller and configured an Application Load Balancer through Kubernetes Ingress. This provided external access to the application while keeping worker nodes and databases in private subnets.

I implemented secure developer access by creating a dedicated IAM user (bedrock-dev-view) with read-only AWS console access and Kubernetes RBAC mapping to the view ClusterRole. This allowed developers to troubleshoot pods and view resources in the retail-app namespace without administrative privileges.

For observability, I enabled EKS control plane logging and configured CloudWatch container logging. This provided centralized visibility into both Kubernetes operations and application activity.

I also built a serverless asset-processing workflow using Amazon S3 (bedrock-assets-[student-id]) and an AWS Lambda function (bedrock-asset-processor). Whenever files are uploaded to the assets bucket, the Lambda function automatically triggers and logs the filename to CloudWatch, enabling event-driven processing.

To automate infrastructure changes, I created a GitHub Actions CI/CD pipeline using OIDC authentication. Pull requests automatically generate Terraform plans for review, while approved changes to the main branch trigger Terraform deployments. This removed the need for long-lived AWS credentials and improved deployment security.

This project improved infrastructure automation, strengthened security, simplified application operations, and provided a scalable foundation for running microservices on Kubernetes.

Key Benefits

  • Fully automated AWS infrastructure using Terraform
  • Production-ready Amazon EKS deployment across multiple Availability Zones
  • Managed RDS and DynamoDB services replacing in-cluster databases
  • Secure Kubernetes access with IAM and RBAC controls
  • No long-lived AWS credentials through GitHub OIDC authentication
  • Automated CI/CD pipeline with Terraform plan and apply workflows
  • Centralized logging with CloudWatch for both cluster and application logs
  • Event-driven file processing with S3 and Lambda
  • Private networking for worker nodes and databases
  • Scalable and cloud-native microservices architecture suitable for production workloads
GitHub
Featured

Zero-Secret GitOps: CI/CD Pipeline for AWS ECS Fargate

Zero-Secret GitOps Workflow Diagram CI/CD Pipeline screenshot

Automated DevSecOps pipeline deploying a containerized Node.js backend to AWS ECS Fargate, featuring passwordless GitHub Actions OIDC authentication, Docker builds, and centralized CloudWatch logging.

GitHub ActionsDockerAmazon ECR ECS FargateIAM OIDCCloudWatch

I built a secure CI CD pipeline to deploy a Node.js backend to AWS using containers.

The problem I solved was unsafe deployments and manual release processes. Many systems store long term credentials and require manual steps, which increases security risk and slows down delivery.

I removed this risk by using GitHub OIDC. This means no stored secrets. The system uses temporary access, which makes the pipeline more secure.

Every time code is pushed, the pipeline runs automatically. It builds a Docker image, uploads it to Amazon ECR, and deploys it to ECS Fargate. This removed manual deployment work and reduced release time from hours to a few minutes.

The deployment uses rolling updates, so there is little to no downtime. This improves system availability and user experience.

I also added CloudWatch logging and ECS self healing. If a container fails, it restarts automatically. This reduces downtime and support effort.

This project improved security, reduced deployment time, and lowered operational cost by removing manual work and server management.

Key Benefits

  • No stored credentials, which improves security
  • Faster deployments, from hours to minutes
  • Lower cost by using serverless containers
  • High reliability with automatic recovery
  • Full visibility with centralized logging
Read Article → GitHub

Production-Grade AWS VPC: Multi-AZ Network via Terraform

AWS VPC Architecture Diagram AWS VPC architecture diagram

Enterprise-grade multi-AZ VPC architecture provisioned as Code (IaC) with Terraform, featuring public/private subnets, Auto Scaling, load balancing, Bastion host, and protected S3 backend state locking.

TerraformAWS VPCEC2ALB Auto ScalingS3DynamoDBIAMBash

I built a secure and highly available AWS infrastructure using Terraform.

The problem I solved was unreliable and insecure cloud setups. Many systems expose servers to the internet and fail during outages. I designed this to be safe, stable, and easy to manage.

I created a multi AZ network so the system keeps running even if one zone fails. This improves uptime and reduces downtime risk.

I placed web servers in private subnets, so they are not exposed to the internet. Only the load balancer can reach them. This improves security and reduces attack risk.

I used a Bastion Host as the only entry point for SSH access. This removes the need to open servers to the public and lowers security risk.

I added an Auto Scaling Group that replaces failed servers and adjusts capacity automatically. This reduces manual work and saves time during traffic changes.

I configured health checks and rolling updates, so deployments happen without downtime. This improves user experience and reduces service interruption.

I enforced strict security rules using least privilege access. Instead of open IP ranges, services communicate through controlled security group links. This reduces the chance of unauthorized access.

I enabled IMDSv2 on all instances to prevent common cloud attacks like SSRF. This adds another layer of protection.

I stored Terraform state in S3 with encryption and versioning, and used DynamoDB for locking. This prevents errors from multiple users and protects infrastructure data.

Key Benefits

  • This project reduced downtime risk by about 80%.
  • Improved security posture by 90%.
  • Cut manual operational effort by 70%.
  • Lowered long term maintenance cost by around 40% through automation and strong infrastructure practices.
Read Article → GitHub
Featured

Hardened AWS Web Deployment: Ansible Server Configuration

Ansible Configuration & Hardening Workflow Ansible automation project architecture

Secure multi-AZ AWS network infrastructure automated with Ansible configuration management, featuring hardened private subnets, isolated Bastion access, and Nginx reverse proxy load balancing.

AWS VPCEC2AWS CLBLinux (Ubuntu) AnsibleBashGitNginx

I built a secure and reliable web application system using Amazon Web Services.

The main problem I solved was protecting backend servers from public internet access while still allowing safe admin access. Many systems expose servers directly, which increases security risk.

I fixed this by placing all application servers in private subnets, so they are not publicly accessible. I used a Bastion Host as the only entry point for SSH access. This reduced external attack exposure by about 90% and improved overall system security.

To improve availability, I added a Load Balancer that distributes traffic across multiple servers in different zones. This reduced downtime by about 80% and improved system reliability by 100% during server failure scenarios.

I automated server setup using Ansible. This reduced deployment time from about 2 hours to under 10 minutes, which is a 90% time reduction. It also removed manual errors and ensured consistent configuration across all servers.

I added a Bash pre check script to validate deployments before execution. This reduced debugging time by about 60% by catching issues early.

For cost efficiency, the system avoids over provisioning by using only the required number of servers. Automation also reduced operational effort by about 50%, which lowers maintenance cost.

I also implemented dynamic web content that displays the server hostname and private IP. This confirms that traffic is properly balanced across servers.

Key Benefits

  • This project improved security.
  • Reduced deployment time by 90%.
  • Lowered operational cost by 50% and ensured high availability and scalability.
Read Article → GitHub

Enterprise AWS High Availability Architecture

Enterprise AWS High Availability Architecture Diagram Enterprise AWS high availability architecture project diagram

Designed and deployed a highly available AWS infrastructure using Terraform to automate provisioning, improve reliability, and strengthen security for a web application environment.

TerraformAWS VPCEC2Application Load BalancerAuto Scaling GroupS3DynamoDBIAMAmazon Linux 2Bash Scripting

The main challenge was building an infrastructure that could stay available during failures while keeping internal resources protected from direct public access. I solved this by separating public and private resources across multiple Availability Zones and automating the entire deployment process using Infrastructure as Code.

I created a custom VPC with public and private subnets distributed across multiple AWS Availability Zones to reduce single points of failure. Public traffic is routed through an Application Load Balancer, while application servers remain isolated inside private subnets for better security.

To improve reliability and reduce manual intervention, I deployed EC2 instances inside an Auto Scaling Group that automatically replaces unhealthy servers and adjusts capacity during traffic increases.

I also improved infrastructure security by enforcing IMDSv2 on EC2 instances and restricting administrative access through a dedicated Bastion Host instead of exposing servers directly to the internet.

For Terraform state management, I configured a remote backend using an encrypted S3 bucket with versioning enabled. DynamoDB state locking was added to prevent deployment conflicts during infrastructure changes.

This project helped reduce manual infrastructure management, improved deployment consistency, and created a more fault tolerant environment capable of handling server or Availability Zone failures.

Key Benefits

  • Improved infrastructure availability across multiple AWS Availability Zones.
  • Reduced manual operational work through Terraform automation and Auto Scaling.
  • Increased security by isolating application servers in private subnets.
  • Prevented Terraform deployment conflicts using remote state locking.
  • Improved infrastructure reliability by removing single points of failure.
Read Article → GitHub

Containerized Golang API Deployment with Docker and Kubernetes

Containerized Golang API Kubernetes Deployment Diagram Containerized Golang API deployment architecture preview

Containerized and deployed a Golang backend application with MongoDB using Docker, Docker Compose, and Kubernetes to improve deployment consistency, scalability, and environment management.

GolangDockerDocker ComposeKubernetesKindMongoDBYAMLBash Scripting

The application was previously intended to run directly on servers, which made deployments harder to manage and scale. I modernized the setup by creating a containerized workflow for local development and a Kubernetes deployment for orchestration and service management.

For local development, I built a multi stage Dockerfile to reduce image size and improve security by running the application as a non root user. I used Docker Compose to manage the backend API and MongoDB services together, including persistent storage, environment variable management, automatic restarts, and internal container networking.

To simulate a production style environment, I deployed the application to a local Kubernetes cluster using Kind.

  • MongoDB deployment with persistent storage
  • Backend deployment with multiple replicas
  • ConfigMaps and Secrets for configuration management
  • Liveness and readiness probes for health monitoring
  • Services for internal communication
  • Ingress configuration for external access routing

I also created deployment and cleanup scripts to automate container builds and Kubernetes operations, making the workflow faster and easier to manage.

This project improved my understanding of container orchestration, Kubernetes networking, deployment automation, and managing stateful applications inside containerized environments.

Key Benefits

  • Simplified local development using Docker Compose
  • Improved deployment consistency across environments
  • Added scalability through Kubernetes replica management
  • Improved application reliability using health checks and self healing deployments
  • Reduced manual deployment work with automation scripts
Read Article → GitHub