Our Case Studies
Real AWS projects, not mockups — see the architecture and read the code yourself.
Cloud Security Engineer
Sentinel — Autonomous Cloud Security Governance
A self-healing SOAR platform that finds and fixes AWS misconfigurations in under 60 seconds.
The Problem. In regulated industries, the biggest predictor of a breach isn’t a zero-day — it’s the gap between a misconfiguration happening and someone noticing. A developer opens SSH to the whole internet for a quick test, or an S3 bucket gets flipped to public during a demo, and it sits there until a scanner (theirs or an attacker’s) finds it. Manual audit cycles, even weekly ones, can’t close that window fast enough.
The Design. Sentinel treats this as a five-stage pipeline: AWS Config continuously evaluates resources against CIS Benchmarks, EventBridge catches the exact moment something goes non-compliant, Step Functions works out whether it’s a network, storage, or database issue, and a dedicated Lambda function fixes only that specific problem. Every remediation Lambda runs under its own least-privilege IAM role — the role that revokes a bad security group rule can’t touch S3, and none of them can provision new infrastructure. That containment was a deliberate choice: an automation system with too much power is its own risk.
The Result. Example from the build: a security group gets created allowing SSH from 0.0.0.0/0. AWS Config flags it non-compliant, and within seconds Sentinel’s Lambda revokes only that ingress rule, leaving the rest of the security group untouched, then logs the action to DynamoDB and alerts the team over SNS — end to end, under 60 seconds, with a full audit trail. The same pattern handles public S3 buckets, disabled bucket versioning, publicly-accessible RDS instances, and disabled EBS encryption. Runs at roughly $2/month idle since almost everything in it is serverless.
Stack: Python (Boto3), AWS Config, EventBridge, Step Functions, Lambda, DynamoDB, Terraform
Solutions Architect
Fortress — Zero-Trust 3-Tier Banking Architecture
A PCI-DSS-aligned architecture for hosting sensitive financial applications on AWS.
The Problem. Financial applications have to hit availability and compliance bars that a normal web stack doesn’t. A single public-facing tier, SSH open for admin access, and hardcoded database credentials might work for a side project — none of it survives a PCI-DSS review, and none of it survives an actual attacker either.
The Design. Fortress runs a hub-and-spoke network across two Availability Zones, and the design principle throughout is “assume the network is hostile.” AWS WAF filters SQL injection and XSS before traffic reaches anything. The web tier sits in a private subnet with no public IPs at all — it only receives traffic forwarded by the load balancer. The database sits one layer deeper, in a subnet with no route to the internet whatsoever. SSH is disabled account-wide; admin access goes through Systems Manager Session Manager instead, which means every session is authenticated and logged, not just “whoever has the key.” Database credentials are pulled from Secrets Manager at boot time and rotated automatically, so nothing sensitive lives in a config file.
The Result. This wasn’t just designed on paper — it was tested. A simulated SQL injection attack against the WAF was blocked with a 403. The private subnet’s route table was checked directly to confirm there really is no path to the internet gateway. The failover story is concrete too: if an Availability Zone goes down, RDS fails over to its standby automatically (under 60 seconds, near-zero data loss), and the Auto Scaling Group replaces unhealthy instances in the surviving zone without anyone paging on-call. Maps to PCI-DSS 1.3, NIST AC-4, and GDPR Article 32.
Stack: VPC, AWS WAF, ALB, EC2, RDS Multi-AZ, Secrets Manager, Systems Manager, KMS, Terraform
DevOps Engineer
Olympus — Cloud-Native Microservices on EKS
Modernizing a monolithic platform into a zero-downtime microservices architecture.
The Problem. A monolithic shipment-tracking platform meant every release risked downtime, and scaling for peak shipping season meant scaling the whole application whether it needed it or not. Feature delivery was slow because nobody wanted to be the one deploying on a Friday.
The Design. Olympus breaks the platform into a containerized Flask microservice running on Amazon EKS, with a control plane spread across three Availability Zones for real high availability. The deployment side is fully GitOps: a push to the main branch on GitHub triggers CodePipeline, CodeBuild builds and tags the Docker image with the commit hash, pushes it to a private ECR registry, and rolls it out to the cluster — no manual deployment step, and no human touching production directly.
The Result. The pipeline was proven live with an actual v1-to-v2 rolling deployment: the API stayed healthy and responsive throughout, Kubernetes brought up the new pods, waited for them to pass health checks, and only then retired the old ones — zero downtime, verified. Two real problems came up during the build and got fixed rather than glossed over: Docker Hub started rate-limiting the build (fixed by pulling the base image from Amazon ECR Public Gallery instead), and CodeBuild initially couldn’t authenticate against the cluster (fixed by mapping its IAM role into Kubernetes RBAC). Deployment time went from a days-long manual process to minutes.
Stack: Amazon EKS, Docker, AWS CodePipeline, CodeBuild, Amazon ECR, Kubernetes
