From single-server risk to AWS architecture planning.
"Café Nimbus is an AWS architecture case study showing how a fragile single-server environment can be redesigned into a segmented, scalable, and automation-ready cloud platform."
The Engagement
Café Nimbus is a growing café brand preparing for national expansion. In this scenario, their online presence depends on a fragile single-server model: limited redundancy, limited backup strategy, limited scaling, and no automation plan for recurring operations work.
The mandate: design an AWS infrastructure that could grow with the business, reduce single points of failure, and automate repeatable reporting work where serverless services make sense. What followed was a five-phase architecture case study. Each phase solves a specific business problem and prepares the next layer.
Architecture Overview
This diagram is a conceptual architecture plan. The repository documents service choices, tradeoffs, validation steps, and production gaps; it does not currently include retained AWS console screenshots or source artifacts.
Five Phases
Amazon S3 · Versioning · Lifecycle Policies · Cross-Region Replication
Café Nimbus had no web presence. Customers were finding competitors instead. The site needed to be fast, cheap to run, and impossible to accidentally break during a content update.
Static website on Amazon S3 with public access controlled through bucket policy. S3 versioning, lifecycle policy, and cross-region replication are included as availability and recovery controls.
Cross-region replication from day one. The counter-argument: Café Nimbus is too small for it. My counter: a regional outage hitting their only S3 bucket takes their entire web presence offline with no recovery option. Replication costs pennies at this scale.
The principle: Replication from day one, not after the first outage. The cost of preventing a disaster is always lower than the cost of recovering from one.
EC2 · LAMP Stack · AMI · Multi-Region Deployment
A static site can display a menu. It cannot take orders, manage inventory, or run a real application. Café Nimbus needed a backend — and one that could be reproduced exactly if it ever had to be rebuilt.
EC2 running a LAMP stack — Linux, Apache, MySQL, PHP. After application validation, a golden AMI would be created so the application server can be rebuilt consistently.
AMI before repeat deployment. A manually configured server that only one person knows how to rebuild is a liability; a repeatable image gives the operations team a known recovery path.
The principle: A manually configured server is a liability. An AMI is an asset. The cost of creating it is an hour. The cost of not having it is a full rebuild under pressure.
Custom VPC · Bastion Host · NAT Gateway · Network ACLs
Café Nimbus was going public with their platform. Their infrastructure had no meaningful network boundaries — everything was reachable from everywhere. Security had to be layered. A single misconfigured security group should not be enough to expose the entire backend.
Custom VPC with public and private subnet separation. Public subnets host internet-facing entry points such as ALB and bastion access; private subnets host application and database resources. NAT Gateway provides outbound-only internet access for private resources, and NACLs add a stateless subnet control layer.
Security groups + NACLs in combination. Security groups are stateful — they remember connections. NACLs are stateless — they evaluate every packet independently. Having both means a misconfigured security group doesn't automatically become an open door.
The principle: Backend resources should avoid direct public exposure. Security groups and NACLs together provide layered controls, but production still needs logging, monitoring, and access review.
Application Load Balancer · Auto Scaling Group · Multi-AZ
A single EC2 instance — no matter how well configured — is a single point of failure. When traffic spikes during a promotion, the site goes down. When the instance fails, the business goes dark. Neither is acceptable for a company preparing for national expansion.
Application Load Balancer across two Availability Zones with an Auto Scaling Group. CPU utilization is used as the example scaling trigger, with health checks and replacement behavior included in the design.
CPU utilization trigger, not scheduled scaling. Traffic is demand-driven, not time-predictable. Scheduling assumes you know when customers will come. Utilization-based scaling responds to what's actually happening.
The principle: Multi-AZ is not a luxury. A single-AZ deployment with ten instances is still a single point of failure. Two AZs with healthy targets reduce single-AZ dependency and create a stronger availability posture.
AWS Lambda · Amazon SNS · Amazon EventBridge
Every morning, the operations team scenario requires repeatable report generation. The design goal is to remove manual report preparation and avoid idle compute for a short scheduled task.
Two Lambda functions: DataExtractor for collecting data and SalesAnalysisReport for formatting the report. SNS delivers the report to a distribution list, and EventBridge triggers the workflow on a daily schedule.
Lambda, not a cron job on EC2. Lambda runs only when triggered — at this workload, monthly cost is effectively zero. An EC2-based cron costs $15–30/month to idle 24/7 for a task that executes once per day. Serverless is not always the right answer. Here, it is the only answer.
The principle: The design reduces manual work by using managed services, health checks, Auto Scaling, and scheduled serverless execution. Implementation evidence would be needed before presenting this as a fully validated deployment.
Architecture Decision Log
Architecture is not a list of what was built. It is a record of what was chosen and what was rejected — and why those tradeoffs were made in this order, for this client, at this stage.
| Decision | Chosen ✓ | Rejected ✗ | Rationale |
|---|---|---|---|
| Static hosting | S3 + bucket policy | EC2-hosted static site | No reason to run compute for files that never change |
| Content protection | S3 versioning day one | No versioning | Accidental overwrites have no recovery path without it |
| Regional resilience | Cross-region replication | Single-region only | One regional outage = total web presence loss |
| Server reproducibility | AMI before second deploy | Manual reconfiguration | A manually built server cannot be rebuilt reliably under pressure |
| Backend access | Bastion host only | Direct SSH + public IP | No backend resource should ever have a direct public route |
| Outbound private traffic | NAT Gateway | Public subnet for EC2s | Private isolation requires outbound-only — not bidirectional |
| Network defence | SGs + NACLs combined | Security groups alone | One misconfigured SG without NACLs = open door |
| Scaling trigger | CPU utilization | Scheduled scaling | Traffic is demand-driven, not time-predictable |
| AZ strategy | Multi-AZ ALB + ASG | Single-AZ more instances | Single AZ is a single point of failure regardless of count |
| Reporting automation | Lambda + EventBridge | Cron job on EC2 | Idle compute 24/7 for a 30-second daily task |
Technologies Used
What I'd Add in Production
These are the gaps I would close before treating this design as production-ready for a real business.
The load balancer is publicly exposed. Without a Web Application Firewall, SQL injection and XSS have no automated defence at the network edge.
In a hardened environment, RDS credentials would be rotated automatically through Secrets Manager — no application code would contain a hardcoded password.
Every API call in the account should be logged. Without CloudTrail, there is no audit trail if something goes wrong or someone does something they shouldn't.
Traffic between EC2 and S3 currently routes through NAT Gateway. VPC Endpoints keep that traffic on the AWS private network and eliminate the NAT cost.
ALB request count, ASG instance count, Lambda errors, and RDS connections — all visible in one place, with SNS alarms when anything goes out of range.
For a nationally expanding café brand, DDoS protection at the ALB layer moves from a nice-to-have to a business continuity requirement.
The Result
The value of this case study is the architecture reasoning: what to build, why those services were chosen, what tradeoffs were rejected, and what production controls would still need to be added before a real go-live.