System Design: Cloud Architecture Concepts
Master Cloud service models (IaaS, PaaS, SaaS), Multi-Region and Multi-AZ topologies, Twelve-Factor Cloud-Native design, Serverless architectures, Infrastructure as Code with Terraform, and FinOps cost optimization.
1. Cloud Service Models & The Shared Responsibility Model
Cloud computing architectures are categorized based on the abstraction layer provided to developers. Under the Shared Responsibility Model, security and operational duties divide between the cloud service provider (AWS, GCP, Azure) and the customer.
Cloud Service Models (IaaS, PaaS, FaaS, SaaS) & Ownership Stack
System DesignComparing customer vs provider management across hardware, OS, runtime, and application layers
IaaS vs PaaS vs FaaS
Selecting the appropriate control vs operational overhead trade-off.
- IaaS (EC2, GCE): Full OS control; maximum flexibility with high patch management burden
- PaaS (Beanstalk, Heroku): Managed OS and runtime; developers focus on application code
- FaaS (AWS Lambda, Cloud Functions): Ephemeral event-driven execution scaling from 0 to N
- SaaS (Slack, Salesforce): Fully managed turn-key software solutions
Shared Responsibility Model
Dividing security responsibilities.
- Security OF the Cloud (Provider): Physical datacenter security, power, hypervisor virtualization, and hardware firmware
- Security IN the Cloud (Customer): Network firewall rules (Security Groups), IAM role access, OS patching (IaaS), data encryption, and application vulnerabilities
2. Multi-Region and Multi-AZ (Availability Zone) Architecture
An Availability Zone (AZ) consists of one or more physically isolated datacenters with redundant power and networking. A Region contains 3+ AZs separated by geographical distance. Systems employ Multi-AZ for High Availability (HA) and Multi-Region for global low-latency and Disaster Recovery (DR).
Multi-Region & Multi-AZ Global Cloud High Availability Architecture
System DesignCombining Route53 Geo-DNS routing, sub-millisecond Multi-AZ sync replication, and cross-region DR async sync
Multi-AZ Architecture (High Availability)
Defends against local datacenter fires, power cuts, and hardware outages.
- Sub-millisecond fiber optic connections between AZs (<1ms latency)
- Synchronous database replication (Multi-AZ RDS / Aurora)
- Zero downtime automated failover during datacenter faults
Multi-Region Architecture (Disaster Recovery & Global Scale)
Defends against entire geographic cloud region outages.
- Geo-DNS & Anycast Routing: Routes users to nearest geographic region
- Cross-Region Replication (CRR): Asynchronous replication of S3 assets & DynamoDB Global Tables
- Compliance & Data Residency: Keeps citizen data stored in required sovereign boundaries (GDPR)
3. Cloud-Native Design Principles & The Twelve-Factor App
Cloud-native systems are purpose-built for elasticity and resilience in dynamic cloud environments. They embrace the Twelve-Factor App methodology, treating infrastructure as disposable Cattle, not Pets.
The Twelve-Factor Cloud-Native Architecture Ecosystem
System DesignStateless process models, environment configuration isolation, disposability, and backing service attachments
Core Tenets of Cloud-Native Architecture
Designing systems that thrive on change and failure.
- Cattle vs Pets: Never manually SSH into or configure servers; treat compute as ephemeral and replaceable via automated autoscaling
- Stateless Compute: Store zero session state on local server disks; persist state in distributed caches (Redis) and object stores (S3)
- Graceful Disposability: Fast startup and graceful handling of SIGTERM signals to finish in-flight requests during rolling updates
- Asynchronous Decoupling: Use event buses (EventBridge, SQS, Kafka) to prevent cascading failures across services
4. Serverless Architecture (AWS Lambda & Event-Driven Compute)
Serverless computing abstracts server management entirely. Functions execute on-demand in response to events (HTTP calls, S3 uploads, database stream changes), automatically scaling from 0 to tens of thousands of concurrent instances with pay-per-millisecond billing.
Serverless Event-Driven Invocation & Cold Start vs Warm Execution Lifecycle
System DesignTracing microVM container provisioning (Firecracker), runtime bootstrapping, and sub-30ms warm executions
Cold Starts & Mitigation Techniques
Understanding the latency penalty of spinning up new serverless instances.
- Cold Start Cause: Downloading code, provisioning microVM, and initializing language runtime
- Provisioned Concurrency: Keeps a pre-warmed pool of Lambda containers ready for instant sub-millisecond execution
- Global Connection Caching: Instantiate database clients outside the handler function to reuse connections across warm calls
Serverless Architectural Constraints
Designing around serverless execution boundaries.
- Execution Timeout: Max 15 minutes per function invocation (AWS Lambda)
- Stateless Memory: Temporary /tmp storage is ephemeral and cleared between instances
- Concurrency Limits: Account-level concurrency limits (e.g. 1000 concurrent executions) require SQS buffering
Production Serverless Image Optimizer Handler (AWS Lambda + S3 in Node.js)
An AWS Lambda handler that resizes images on-the-fly and stores the output back in S3.
Press Run to execute the code and see output here.
5. Infrastructure as Code (Terraform & GitOps Automation)
Infrastructure as Code (IaC) replaces manual cloud console clicking with version-controlled, declarative configuration files. Terraform (HCL) is the industry standard, allowing teams to plan, review, and automate infrastructure changes via GitOps pipelines.
Terraform GitOps Plan & Apply CI/CD Pipeline Architecture
System DesignAutomated Pull Request plan generation, DynamoDB state locking, and S3 remote state management
Terraform Core Principles & Remote State
Managing reproducible cloud environments.
- Declarative Syntax: Declare the desired end state (HCL); Terraform calculates the exact steps to achieve it
- State Management (terraform.tfstate): Maps your code definitions to real-world cloud resource IDs; stored securely in remote S3 buckets with encryption
- State Locking: Uses DynamoDB locks to prevent two engineers or CI pipelines from applying concurrent updates simultaneously
Production Terraform HCL Manifest: Multi-AZ VPC & S3 Cost Lifecycle Tiering
A Terraform configuration that provisions a multi-AZ VPC and applies S3 lifecycle rules for cost-efficient storage tiering.
Press Run to execute the code and see output here.
6. Cloud Cost Optimization Strategies (FinOps & Resource Right-Sizing)
Unmonitored cloud spending quickly spirals out of control. FinOps establishes financial accountability by combining compute purchasing commitments, automated resource right-sizing, storage lifecycle tiering, and data egress minimization.
Cloud Cost Optimization Strategy Matrix (Compute, Storage & Networking)
System DesignLeveraging Spot/Savings Plans, S3 Intelligent-Tiering, and CDN edge egress reduction
1. Compute Optimization
Slashing VM and container costs.
- Spot Instances: Up to 90% discount for stateless batch jobs & worker nodes
- Savings Plans: 1-3 year commitment for steady-state workloads (up to 72% discount)
- Auto-Shutdown: Scripted scheduled shutdown of non-production environments
2. Storage Lifecycle
Auto-migrating cold data.
- S3 Intelligent-Tiering: Automatically moves unaccessed objects to cheaper tiers with zero operational overhead
- Glacier Deep Archive: Long-term compliance archiving at $0.00099/GB/month
- EBS Snapshot Cleanup: Deleting orphaned volume snapshots
3. Network Egress
Minimizing cross-boundary data transfer.
- CloudFront CDN: Absorbs static asset requests at edge POPs, drastically lowering origin bandwidth costs
- VPC Endpoints (PrivateLink): Keeps internal S3/DynamoDB traffic off public internet to avoid NAT Gateway data fees
Knowledge Check
1. What does the customer manage under the Platform as a Service (PaaS) model?
2. What is the primary difference between an Availability Zone (AZ) and a Region?
3. What is a "Cold Start" in Serverless Function execution?
4. What is the purpose of the "terraform.tfstate" file in Infrastructure as Code?
5. How do Spot Instances help reduce cloud infrastructure compute costs?