Major clouds offer the same conceptual building blocks with different names: compute (VMs, containers, functions), managed databases, object storage, VPC networking, load balancers, and managed messaging. Design in concepts first, map to services second.

• VPC: private subnets for DB/workers; public subnets for LB only
• IAM: least-privilege roles per service — no long-lived keys in code
• Managed services reduce ops but create vendor coupling — acknowledge tradeoff
• Multi-AZ by default for production managed databases

Compute choice balances control, portability, scaling granularity, and operational overhead. VMs give full OS control. Containers (Docker + Kubernetes/ECS) package apps with dependencies. Serverless (Lambda, Cloud Functions) runs code on demand without managing servers.

• Kubernetes: declarative scaling, service mesh, but operational complexity
• Fargate / Cloud Run: container without managing nodes
• Serverless limits: max duration (15 min Lambda), memory, no persistent local disk
• Hybrid: API on containers, async workers on serverless

Cloud storage tiers serve different access patterns. Object storage holds unstructured blobs at massive scale. Block storage provides disk volumes for VMs. Managed databases offload backups, patching, replication, and failover.

• S3 storage classes: Standard, IA, Glacier — lifecycle policies auto-tier
• EBS vs instance store: EBS persists after stop; instance store is ephemeral but fast
• Read replicas and Multi-AZ are different — replicas for read scale, Multi-AZ for failover
• Egress cost: moving data out of cloud is expensive — design data locality

Autoscaling dynamically adjusts capacity based on metrics — CPU, request count, queue depth, or custom business metrics. Effective scaling matches the bottleneck resource and accounts for warmup time and scale-in safety.

• Target tracking: maintain 70% CPU → add/remove instances automatically
• Cooldown period prevents flapping during oscillating load
• Scale-out fast, scale-in slow — protect against removing needed capacity
• Predictive scaling (ML-based) for known patterns (Prime Day, Black Friday)

Multi-AZ deploys across availability zones within a region for zone-level fault tolerance — typically synchronous replication for databases. Multi-region adds geographic redundancy, lower global latency, and disaster recovery at the cost of complexity and consistency challenges.

        Global Load Balancer (GeoDNS / Anycast)
              /                          \
      Region US-EAST                 Region EU-WEST
      AZ-a  AZ-b  AZ-c               AZ-a  AZ-b  AZ-c
        App tier                       App tier
        Regional DB ◄──async repl──► Regional DB
        (conflict resolution / CRDTs for writes)

• RPO: max data loss on failover; RTO: max downtime to restore
• Route 53 health checks + DNS failover for regional DR
• Data residency regulations may require EU data stays in EU
• Global tables (DynamoDB) or Spanner for multi-region strong consistency

Event-driven architecture reacts to state changes (file uploaded, order placed, timer fired) rather than polling. Serverless functions are natural event handlers — pay per invocation, zero idle cost, but constrained by runtime limits and cold starts.

• Step Functions / Cloud Workflows for multi-step orchestration with retries
• EventBridge as central event bus with schema registry and routing rules
• Cold start mitigation: provisioned concurrency, smaller runtimes, ARM Graviton
• Avoid long chains of sync Lambda calls — use async events or Step Functions

Observability is the ability to understand system behavior from external outputs: metrics, logs, and traces. SLOs (Service Level Objectives) define target reliability (e.g. 99.9% availability, p99 < 200ms) and drive engineering priorities via error budgets.

1. Define SLIs: latency p99, availability, error rate, throughput
2. Set SLOs (target) and SLAs (contractual consequence)
3. Error budget = 1 - SLO; when exhausted, freeze features, fix reliability
4. Alert on symptoms (user-facing SLO burn rate), not every internal blip
5. RED method: Rate, Errors, Duration for services

Cloud costs scale with usage — compute hours, storage GB, egress bandwidth, and API calls. Cost optimization is a continuous practice: right-size resources, use reserved capacity, tier storage, and architect for efficient data transfer.

• Egress is often the surprise bill — CDN and regional data locality help
• Serverless can be cheaper at low volume; containers cheaper at steady high volume
• Tag resources by team/service for chargeback and anomaly detection
• Review top 10 cost drivers monthly; set billing alerts