AWS Cloud Architecture — Fundamentals & Scenario Design
AWS Cloud Architecture — Fundamentals & Scenario Design
Why Cloud Infrastructure Exists
Before AWS, teams ran their own physical servers. That meant:
- Buying hardware upfront, even if usage was unpredictable
- Paying for idle capacity during quiet periods
- No redundancy — one server failure = downtime
- Long lead times to scale up
AWS solves this by letting you rent infrastructure on demand, pay only for what you use, and spin resources up or down in minutes.
Core Concepts
Regions and Availability Zones
AWS operates data centres across the world, organised into regions — named locations like eu-west-2 (London), us-east-1 (Virginia), or ap-southeast-1 (Singapore).
Within each region, AWS runs multiple Availability Zones (AZs) — physically separate data centres a few miles apart. For example, eu-west-2 has three: 2a, 2b, and 2c.
Why this matters for reliability: Hardware fails. If your entire app runs in a single AZ and that AZ loses power, your app goes down. Spreading your resources across multiple AZs means a failure in one doesn’t take everything with it.
Shared Responsibility Model
| AWS is responsible for | You are responsible for |
|---|---|
| Physical hardware and data centres | Your data and who can access it |
| Network infrastructure | IAM users, roles, and policies |
| Hypervisor and host OS | Security groups and firewall rules |
| Managed service availability | Patching your EC2 OS and applications |
Core AWS Services
EC2 — Elastic Compute Cloud
Virtual machines in the cloud. You choose the OS, instance type (CPU/RAM), and region. EC2 instances run your application code.
- Use when you need full control over the OS and runtime
- Can be placed in multiple AZs for redundancy
- Combined with an Auto Scaling Group to scale based on demand
S3 — Simple Storage Service
Object storage for files, images, backups, and static assets. S3 exists independently of any EC2 instance — files stored there survive reboots, crashes, and terminations.
- Highly durable (designed for 99.999999999% durability)
- Not a file system — objects are accessed via URLs or the AWS SDK
- Use for anything that needs to persist beyond a single server’s lifetime
ALB — Application Load Balancer
Distributes incoming HTTPS traffic across multiple EC2 instances. If one instance is unhealthy, the ALB stops sending traffic to it.
- Works with Auto Scaling Groups to route to new instances automatically
- Performs health checks on registered instances
- Essential for zero-downtime deployments and multi-AZ redundancy
Auto Scaling Group (ASG)
Automatically launches or terminates EC2 instances based on demand or a schedule. Defines a minimum, desired, and maximum number of instances.
- Instances can be spread across multiple AZs
- Integrates with ALB to register/deregister instances automatically
- Use scaling policies (e.g. scale out when CPU > 70%, scale in when < 20%)
RDS — Relational Database Service
Managed relational database (MySQL, PostgreSQL, etc.). AWS handles backups, patching, and failover — you just use it like a regular database.
- Should live in a private subnet — never exposed to the public internet
- Use Security Groups to allow only EC2 instances to connect
- Supports Multi-AZ for automatic failover
CodeDeploy
AWS deployment service that automates rolling code changes to EC2 instances (or Lambda, ECS). Integrates with GitHub Actions for CI/CD.
- In-place deployment — updates existing instances one at a time
- Blue/green deployment — launches a new set of instances with the new code, then switches traffic over. Old instances stay running until the new ones pass health checks. Automatic rollback if they fail.
SQS — Simple Queue Service
A managed message queue. Services put jobs on the queue; other services (Lambda, workers) consume and process them asynchronously.
- Decouples services so they don’t have to call each other directly
- If the consumer is slow or down, jobs wait in the queue — nothing is lost
- Use when you want to offload background work from your main server
Lambda
Serverless function-as-a-service. Runs code in response to a trigger (SQS message, API call, S3 event) without you managing any servers.
- Scales automatically with demand
- Billed per invocation and duration
- Ideal for short-lived, event-driven tasks (processing emails, resizing images, etc.)
SES — Simple Email Service
AWS’s email sending service. Used by Lambda or EC2 to send transactional emails (order confirmations, password resets, etc.).
CloudWatch
AWS’s monitoring and observability service. Collects metrics, logs, and events from all AWS services.
- Set alarms that trigger actions (e.g. scale out, roll back a deployment) when a metric crosses a threshold
- View dashboards for CPU, memory, request counts, error rates
- Essential for diagnosing performance issues
Scenario A — Snapgram (Photo Sharing App)
The Problems
| Problem | Root Cause |
|---|---|
| Photos vanish on restart | Files stored on the EC2 instance’s local disk |
| App goes down when server goes down | Single EC2 instance, no redundancy |
| 30-second downtime on every deploy | SSH deploy stops and restarts the process |
| No performance visibility | No monitoring in place |
The Architecture
[GitHub] → [GitHub Actions] → [CodeDeploy] ─── deploys ──→ [EC2 in AZ-2a]
└── deploys ──→ [EC2 in AZ-2b]
[Users] → [Internet Gateway] → [ALB] → [EC2 in AZ-2a] → [S3 Bucket]
└→ [EC2 in AZ-2b] → [S3 Bucket]
[CloudWatch] ←── monitors ──── [EC2 instances]How Each Problem Is Solved
Photos vanish → S3
Store uploaded photos in S3 instead of the EC2 local disk. S3 exists independently of any EC2 instance. Restarting, replacing, or terminating an instance has no effect on photos stored in S3.
EC2 receives upload → writes to S3 → serves photo from S3 URLSingle point of failure → ALB + Auto Scaling Group + Multi-AZ
Run two (or more) EC2 instances across different Availability Zones. The ALB performs health checks — if an instance becomes unhealthy, it removes it from rotation and the remaining instances absorb the traffic.
ALB health check fails on AZ-2a instance
→ ALB stops routing to it
→ AZ-2b instance handles all traffic
→ ASG launches a replacement in AZ-2aDeploy downtime → CodeDeploy rolling deployment
CodeDeploy takes instances out of the load balancer one at a time, deploys new code, runs health checks, then returns them to the ALB. The app stays live throughout.
Step 1: Take EC2-a out of ALB rotation
Step 2: Deploy new code to EC2-a
Step 3: Run health checks
Step 4: Return EC2-a to ALB
Step 5: Repeat for EC2-bNo monitoring → CloudWatch
CloudWatch collects metrics (CPU, memory, request count, error rate) and logs from EC2 and the ALB. Set alarms to alert the team or trigger auto-scaling when thresholds are crossed.
Scenario B — ShopFast (E-commerce)
The Problems
| Problem | Root Cause |
|---|---|
| Site crashes during flash sales | Single EC2 instance, fixed capacity |
| Paying for huge server 24/7 when idle | No auto-scaling |
| Email delays of 45 minutes | Email processing blocking the main server |
| Broken deployments kill checkout | No automated rollback |
| Database security concerns | DB potentially exposed |
The Architecture
[GitHub] → [GitHub Actions] → [CodeDeploy blue/green] → [EC2 in AZ-2a]
↑ rollback → [EC2 in AZ-2b]
[CloudWatch] ─── alarm ───────────────┘
[Users] → [ALB] → [EC2 in AZ-2a] → [RDS in Private Subnet]
└→ [EC2 in AZ-2b] → [RDS in Private Subnet]
[EC2] → [SQS Queue] → [Lambda] → [SES] → [Email Recipients]How Each Problem Is Solved
Flash sale crashes + idle overpaying → ALB + Auto Scaling Group
The ASG watches a CloudWatch metric (e.g. CPU or request count). When the flash sale starts and traffic spikes, it automatically launches additional EC2 instances and registers them with the ALB. After the sale, it terminates the extra instances. You only pay for what you use.
Flash sale starts → CPU hits 70% → CloudWatch alarm
→ ASG scales from 2 to 10 instances
→ ALB registers new instances
→ Flash sale ends → CPU drops → ASG scales back to 2Email delays → SQS + Lambda + SES
Instead of the main server processing and sending emails synchronously (blocking the checkout flow), it puts a job on an SQS queue and immediately returns a response to the user. Lambda picks up jobs from the queue and sends the emails via SES asynchronously. The main server is never blocked.
User places order
→ EC2 writes job to SQS queue (instant)
→ EC2 returns "Order confirmed" to user
→ Lambda picks up job from SQS
→ Lambda sends email via SES
→ User receives confirmation emailBroken deployments → CodeDeploy blue/green + CloudWatch alarms
Blue/green deployment launches a completely new set of instances (the “green” group) with the new code. CloudWatch health checks run against them. If they pass, the ALB switches traffic from the old (“blue”) instances to the new ones. If they fail, traffic stays on the blue group — zero impact on users.
Deploy new code → launch green EC2 instances
→ Run health checks on green
→ Health checks fail? → rollback, keep blue live
→ Health checks pass? → switch ALB to green, terminate blueDatabase security → RDS in private subnet + Security Groups
RDS lives in a private subnet with no internet gateway attached. It is unreachable from the public internet. A Security Group on the RDS instance allows inbound connections only from the Security Group attached to the EC2 instances.
Internet → ✗ blocked (no route to private subnet)
EC2 instances → ✓ allowed (Security Group rule)
Any other source → ✗ denied by defaultKey Principles to Remember
Stateless application servers
Keep your EC2 instances stateless — they should not store anything locally that isn’t also somewhere else (S3, RDS, Redis). This makes it safe to terminate or replace instances at any time.
Decouple services with queues
When Service A needs to trigger work in Service B, don’t call B directly if you can avoid it. Putting a message on a queue lets A continue immediately and lets B process at its own pace, independently.
Defense in depth for databases
- Private subnet: no internet route
- Security Groups: whitelist only your EC2 instances
- IAM roles: EC2 should use a role with minimal DB permissions
- Encryption at rest and in transit
Auto Scaling requires health checks
Auto Scaling only works correctly if your ALB health checks accurately reflect whether your app is ready to serve traffic. A /health endpoint that checks DB connectivity is better than one that just returns 200.