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 Design

Comparing customer vs provider management across hardware, OS, runtime, and application layers

100%
Loading system design canvas…

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 Design

Combining Route53 Geo-DNS routing, sub-millisecond Multi-AZ sync replication, and cross-region DR async sync

100%
Loading system design canvas…

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 Design

Stateless process models, environment configuration isolation, disposability, and backing service attachments

100%
Rendering diagram…

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 Design

Tracing microVM container provisioning (Firecracker), runtime bootstrapping, and sub-30ms warm executions

100%
Rendering diagram…

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.

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 Design

Automated Pull Request plan generation, DynamoDB state locking, and S3 remote state management

100%
Rendering diagram…

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.

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 Design

Leveraging Spot/Savings Plans, S3 Intelligent-Tiering, and CDN edge egress reduction

100%
Loading system design canvas…

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?