Award-winning Cloud Engineer specializing in building secure AWS infrastructure, automating manual configuration tasks, and keeping systems highly available. Recognized as the Overall Best Learner in the School of Engineering and the Best Learner in Cloud Engineering. Skilled at shifting outdated manual configurations into resilient, automated cloud setups and finding root causes during live production outages.
To avoid application downtime caused by regional hardware failures, I built a multi-zone Drupal CMS platform on AWS. I used Terraform to provision a network across two availability zones, configuring public subnets for an Application Load Balancer and private subnets for two EC2 application servers and an Amazon RDS MySQL database. I wrote Ansible playbooks to dynamically configure the Linux servers, install PHP, set up Apache, handle database connection strings, and establish data synchronization across the runtime environments. I built a multi-stage GitHub Actions pipeline to compile the code, create Docker container versions, run automated smoke tests in a staging partition, and run a production update requiring a manual manager check. Finally, I deployed an ELK stack to gather log streams and linked Prometheus and Grafana dashboards to monitor web server response latency and trigger resource alerts.
For the AltSchool Cloud Engineering graduation examination, I built an automated infrastructure platform to run a microservices retail application. I used Terraform to establish a remote S3 backend and provision an Amazon EKS cluster named project-bedrock-cluster within a dedicated multi-AZ VPC in us-east-1. I migrated the application data layer from in-cluster containers to managed AWS resources, setting up secure private Amazon RDS instances and Amazon DynamoDB tables with credentials retrieved via AWS Secrets Manager. I installed the AWS Load Balancer Controller to expose the store interface through an Application Load Balancer and configured CloudWatch to collect both EKS control plane and container logs. Finally, I built a serverless pipeline where an S3 asset bucket triggers a Python Lambda function to process product images, and automated all changes using a GitHub Actions pipeline that plans on pull requests and applies on code merge.
To implement a complete deployment pipeline for a growing full stack application, I separated corporate codebases into an application repository and an infrastructure repository. I wrote modular Terraform configurations to provision an Auto Scaling Group for a Golang backend API, an Application Load Balancer, an AWS ElastiCache Redis cluster, and an Amazon S3 static website bucket connected to a CloudFront CDN. I connected the backend to a MongoDB Atlas cluster and set up target CloudWatch log groups with IAM instance profiles for system auditing. I built independent GitHub Actions workflows that run security audits and tests, sync React assets directly to S3 with automated CloudFront cache invalidations, and package the Golang API as a Docker container for rolling updates on the auto scaling web nodes.
🔗 Application Repository | Infrastructure Repository
To prevent application downtime from single-point-of-failure issues, I built a self-healing, multi-zone web server infrastructure on AWS. I used Terraform to provision a multi-AZ VPC containing public and private subnets, redundant NAT Gateways, and an Application Load Balancer. I configured an Auto Scaling Group in the private subnets to scale Apache web servers based on traffic, and set up a Bastion Host for secure system updates. Storing the infrastructure state in an S3 bucket with DynamoDB locks stopped configuration conflicts and created a repeatable network setup.
Configuring web servers manually and exposing SSH credentials creates security vulnerabilities. I resolved this by designing an automated infrastructure setup that keeps all application servers hidden from the public internet. I created a multi-tier AWS network using a Bastion Host with an SSH ProxyJump configuration to protect the application tier. I wrote Ansible playbooks to handle OS configurations, install runtime packages, and deploy the web applications over these private channels. This process closed port 22 to the public internet and standardized configuration management across all web servers.
Using static AWS keys in automation code creates security risks if the repository is compromised. I built a continuous integration and deployment pipeline to securely ship a Node.js application to cloud hosting. I set up GitHub Actions workflows to authenticate via OpenID Connect, allowing the pipeline to fetch short-lived AWS session tokens instead of using hardcoded secrets. The pipeline builds a multi-stage Docker image, runs tests, pushes the build to Amazon ECR, and triggers a rolling update on AWS ECS Fargate. The project keeps credentials safe and guarantees the application stays online during code updates.
|
|
|
"If an infrastructure isn't documented and automated, it isn't production-ready."