Cloud Architecture Patterns on Software Engineering Learning Paths

Cloud Computing Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Computing Fundamentals#

Cloud computing is renting someone else’s computers — but the architecture decisions you make on those rented computers are entirely different from on-premises. This section covers the service models, shared responsibilities, and design principles that underpin every cloud-native system.

Cloud Service Models#

Every cloud provider offers services across a spectrum of abstraction. Understanding where each model sits determines what you manage versus what the provider manages.

┌─────────────────────────────────────────────────────────────────┐
│ YOU MANAGE EVERYTHING │
│ On-Premises │
│ ┌──────────┬──────────┬──────────┬──────────┬──────────┐ │
│ │ App │ App │ App │ App │ App │ │
│ │ Runtime │ Runtime │ Runtime │ Runtime │ Runtime │ │
│ │ OS │ OS │ OS │ OS │ OS │ │
│ │ Compute │ Compute │ Compute │ Compute │ Compute │ │
│ │ Storage │ Storage │ Storage │ Storage │ Storage │ │
│ │ Network │ Network │ Network │ Network │ Network │ │
│ └──────────┴──────────┴──────────┴──────────┴──────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ IaaS PaaS FaaS SaaS │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ App ▲ │ │ App ▲ │ │ Code ▲ │ │ ▲ │ │
│ │ Runtime│ │ │ │ │ │ │ │ │ │ │ │
│ │ OS │Y│ │ Runtime│P│ │ Runtime│P│ │ App │P│ │
│ │ ───────│O│ │ OS │R│ │ OS │R│ │ Runtime│R│ │
│ │ Compute│U│ │ ───────│O│ │ ───────│O│ │ OS │O│ │
│ │ Storage│ │ │ Compute│V│ │ Compute│V│ │ Compute│V│ │
│ │ Network│ │ │ Storage│ │ │ Storage│ │ │ Storage│ │ │
│ └────────┘ │ │ Network│ │ │ Network│ │ │ Network│ │ │
│ │ └────────┘ │ └────────┘ │ └────────┘ │ │
│ YOU ▲ │ │ │ │ │
│ PROVIDER ─ │ │ │ │ │
└─────────────────────────────────────────────────────────────────┘

Service Model Comparison#

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, app, data	Hardware, networking, virtualisation	EC2, Compute Engine, Azure VMs
PaaS	App code, data	OS, runtime, scaling, patching	App Engine, Elastic Beanstalk, Azure App Service
FaaS	Function code	Everything else, including scaling to zero	Lambda, Cloud Functions, Azure Functions
SaaS	Configuration, data	The entire application	Gmail, Salesforce, Datadog
CaaS	Container images, orchestration config	Infrastructure, container runtime	ECS, GKE, AKS
DBaaS	Schema, queries, data	Engine, patching, backups, scaling	RDS, Cloud SQL, Cosmos DB

Choosing a Service Model#

Is your team managing the OS and patching today?
├── Yes, and we want to keep control → IaaS
├── Yes, but we'd rather not → PaaS or CaaS
└── We just want to ship code
 ├── Stateless, event-driven → FaaS
 ├── Long-running processes → PaaS or CaaS
 └── Standard business app → SaaS (buy, don't build)

The Shared Responsibility Model#

Security and operations responsibilities split between you and the provider. The split point varies by service model.

Multi-Account & Organisation Strategy

Mon, 01 Jan 0001 00:00:00 +0000

Multi-Account & Organisation Strategy#

A single cloud account for everything is the number one architectural mistake organisations make. It creates a blast radius that spans your entire business: one misconfigured IAM policy can expose production data, development experiments can exhaust production quotas, and cost attribution becomes impossible. This section covers how to structure accounts, enforce guardrails, and automate provisioning.

Why Multiple Accounts?#

A single account conflates environments, teams, and workloads into one security and billing boundary. Multiple accounts provide:

Networking Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Networking Architecture#

Cloud networking is not just “VPC plus subnets.” It’s the connective tissue between every service, account, region, and on-premises data centre. Mistakes here are expensive to fix because networking underpins everything above it. This section covers the design patterns that scale from one VPC to hundreds of accounts across multiple regions.

VPC Design Patterns#

A Virtual Private Cloud (VPC / VNet) is your isolated network within the provider’s infrastructure. The design of your VPC determines how workloads communicate, how traffic enters and exits, and where security boundaries lie.

Compute Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Compute Patterns#

Choosing the right compute model is one of the highest-leverage architecture decisions you’ll make. It affects cost, operational complexity, scaling behaviour, and team velocity. This section provides frameworks for making that decision and patterns for getting the most out of each model.

Compute Decision Framework#

Every workload has different characteristics. Match the compute model to the workload, not the other way around.

What is the workload profile?
│
├── Stateless request/response, runs < 15 min
│ ├── < 1M requests/day → FaaS (Lambda / Cloud Functions)
│ └── > 1M requests/day → Containers (cost-optimised)
│
├── Long-running process, always-on
│ ├── Needs OS-level control → VMs
│ └── Doesn't need OS-level control → Containers
│
├── Batch processing, can tolerate interruption
│ └── Spot/preemptible instances (VMs or containers)
│
├── GPU/ML training or inference
│ ├── Training → GPU VMs or managed ML (SageMaker, Vertex AI)
│ └── Inference → GPU containers or serverless inference
│
└── Legacy app, can't be modified
 └── VMs (lift and shift)

Compute Model Comparison#

Factor	VMs	Containers	FaaS
Startup time	Minutes	Seconds	Milliseconds (warm) to seconds (cold)
Scaling granularity	Per VM	Per container	Per request
Min cost at idle	VM cost 24/7	Cluster cost 24/7	Zero (scale to zero)
Max control	Full OS access	User-space control	Code only
Operational burden	Patching, hardening, monitoring	Orchestration, image management	Near-zero ops
State handling	Local disk available	Ephemeral by design	Stateless
Cold start	N/A (always running)	N/A (always running)	100ms–10s (varies by runtime)
Cost at scale	Lower per-unit (reserved)	Lower per-unit (bin-packing)	Higher per-unit (per-invocation)

Auto-Scaling Patterns#

Auto-scaling adjusts compute capacity based on demand. The goal is to match capacity to load with minimal lag and minimal waste.

Data Architecture Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Data Architecture Patterns#

Data outlives applications. The services you build today will be rewritten, but the data they produce will still matter in ten years. Cloud data architecture is about choosing the right storage for each workload, placing data where it needs to be, and ensuring it’s protected, governed, and accessible.

Polyglot Persistence#

Using a single database for everything is an anti-pattern. Different data access patterns require different storage engines.

Cloud Migration Strategies

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Migration Strategies#

Migration is not a technical project — it’s a business transformation with technical components. Most migration failures are caused by poor planning, not poor execution. This section covers the strategic patterns for moving workloads to the cloud and the tactical patterns for cutting over with minimal risk.

The 6 Rs of Migration#

Every workload in your portfolio maps to one of six strategies. The right strategy depends on the workload’s business value, technical complexity, and cloud readiness.

Serverless Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Serverless Architecture#

Serverless doesn’t mean “no servers.” It means you don’t manage, provision, or think about servers. The provider handles scaling, patching, and availability. You write code, define triggers, and pay per execution. This section covers when serverless is the right choice, how to design serverless systems, and the anti-patterns that make serverless expensive or fragile.

Event-Driven Serverless#

Serverless functions are inherently event-driven: something happens, a function runs, and it stops. This model maps naturally to many workloads.

Multi-Cloud & Hybrid Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Multi-Cloud & Hybrid Patterns#

Multi-cloud is one of the most over-sold and under-scrutinised strategies in cloud architecture. Vendors and analysts promote it as best practice; practitioners know it doubles operational complexity. This section separates the legitimate use cases from the cargo-cult adoption and covers the patterns that make multi-cloud and hybrid architectures work when they’re genuinely needed.

When Multi-Cloud Makes Sense#

Legitimate Reasons#

Reason	Scenario	Example
Best-of-breed services	A specific provider has a uniquely superior service	BigQuery for analytics + AWS for everything else
M&A inheritance	Acquisition brings workloads on a different cloud	Company A (AWS) acquires Company B (Azure)
Regulatory requirement	Regulator mandates no single-vendor dependency	Financial services in some jurisdictions
Data sovereignty	Provider lacks a region in a required country	GCP has no region in a required market; Azure does
Negotiation leverage	Credible multi-cloud capability improves pricing negotiations	Demonstrably portable workloads

Bad Reasons (But Commonly Cited)#

Claimed Reason	Reality
“Avoid vendor lock-in”	You trade one lock-in (cloud) for another (abstraction layer). The abstraction layer is your own code, which is harder to maintain than managed services.
“Redundancy across clouds”	Cross-cloud failover is extraordinarily complex. Within-cloud multi-region is far simpler and better tested.
“We want flexibility”	Flexibility without usage is waste. Design for portability only when you’ll actually port.
“Our team knows both”	Your team will become mediocre at two clouds instead of excellent at one.

The Cost of Multi-Cloud#

Multi-cloud is not free. Quantify these costs before committing:

Security Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Security Architecture#

Cloud security is fundamentally different from on-premises security. There’s no physical perimeter to defend. Instead, identity becomes the perimeter, encryption becomes the default, and automation replaces manual audit. This section covers the architectural patterns for securing cloud environments without slowing down delivery.

Zero-Trust in the Cloud#

Zero-trust is not a product — it’s an architecture principle: never trust, always verify. Every request is authenticated and authorised, regardless of its origin.

Cost Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Cost Architecture#

Cost is an architecture concern, not a finance concern. Every design decision — the database engine, the compute model, the replication strategy — has a cost implication. Engineers who understand cost architecture build systems that are both performant and economically sustainable. This section covers the principles, patterns, and organisational structures for cost-aware cloud design.

Cost-Aware Architecture Principles#

The Five Principles#

Principle	What It Means
Cost is a first-class requirement	Treat cost like latency or availability — it has targets, is measured, and is reviewed
Right-size, don’t over-provision	Match resources to actual usage, not theoretical peak
Pay for what you use	Prefer per-request/per-second pricing when workloads are variable
Design for cost visibility	Every resource is tagged, every cost is attributable to a team/service
Review continuously	Cost optimisation is not a one-time project; it’s a recurring practice

Cost as a Non-Functional Requirement#

Just as you specify SLOs for latency and availability, specify cost targets: