Cloud Architecture for Cafe Business on AWS

Northeastern University, CS 6620 Cloud Computing · Spring 2024

AWS CloudFormation EC2 RDS S3
AWS architecture for cafe business

Overview

I designed and documented a multi-tier AWS architecture for a fictional café chain scaling past a single on-prem server. Compute sits behind Elastic Load Balancing with Auto Scaling across AZs; RDS holds transactional data with backups; S3 carries static and archive objects; CloudFormation templates reproduce the stack instead of relying on one-off console clicks.

The write-up spells out security-group and subnet boundaries so the database never sits on the public internet, and records production-style cost choices (Reserved Instances for steady load, S3 lifecycle rules so storage does not creep indefinitely). The diagram on this page matches the layout defended in that document.

Deliverables

  • A reference architecture for the café workload: web application tier, managed relational data, object storage for static assets and backups, and automation that can recreate the stack.
  • Highly available compute built around Elastic Load Balancing, Multi-AZ placement, and Auto Scaling Groups so traffic spikes or instance loss do not become full outages.
  • Infrastructure as code using AWS CloudFormation templates so environments stay versioned and reproducible.
  • Documentation that ties design choices to cost optimization (for example Reserved Instances for steady workloads and S3 lifecycle rules so storage does not grow without guardrails).

AWS services used

  • Amazon EC2: Virtual machines for the application tier behind the load balancer.
  • Elastic Load Balancing: Distributes requests across healthy instances.
  • Auto Scaling Groups: Adjusts capacity against demand while respecting Multi-AZ layout.
  • Amazon RDS: Managed relational database with replication and automated backup patterns suited to transactional café data.
  • Amazon S3: Durable object storage for static content, artifacts, and backup targets.
  • AWS CloudFormation: Declarative stacks for provisioning and change control.

Security groups and subnet layout keep the database tier off the public internet while exposing only what the application tier needs, following conventional public/private subnet separation on AWS.

Results

  • A clear thread from business needs (uptime, growth, cost) to concrete AWS services and connection patterns.
  • Operational patterns for compute, storage, relational data, scaling, and infrastructure as code that transfer to similar retail or hospitality workloads.
  • Explicit tradeoffs among performance, resilience, and monthly spend instead of an oversized default stack.