Cloud Architecture
Intermediate 15 min read Cloud Architecture

Cloud Architecture Principles

Design by axioms, not by accident

The axioms behind every good cloud design: statelessness, failure design, elasticity, security defaults, and cost awareness. Framed by the Well-Architected pillars and the anti-patterns they kill (spiky monoliths, single points of failure, gold-plated capacity).

principlesstatelesselasticityfailure designpillarsWAFanti-patterns
Prerequisites: HA Fundamentals Cost Fundamentals
Before we start

What you will learn

  • Articulate the core principles (stateless, elastic, failure-first)
  • Map them to the Well-Architected pillars
  • Identify the anti-patterns in designs you review
In 60 seconds

Principles: design for failure (anything can die), stateless tiers (compute re-creatable), elastic scale (right-size + autoscale), security by default (least privilege baked in), cost-aware (shape-matched). Pillars (AWS: operational excellence, security, reliability, performance, cost; Azure unified; GCP reliability/security/cost) turn axioms into review checklists.

Introduction

What is this?

Principles in practice: statelessness (sessions/caches outside instances; anything re-creatable within minutes), elasticity (autoscale for load, cost shape-matched), failure isolation (blast-radius, AZs, per-service failure), redundancy (N+1/Zones), data safety (backups + replication + immutable), least privilege + encryption everywhere, observability-first (every release measurable), cost at design (unit economics from day one). Pillars/frameworks: AWS Well-Architected five; Azure Well-Architected Framework (reliability, security, cost, ops, performance); GCP Architecture Framework. Anti-patterns: the monolithic all-in-one server, sticky-state in request path, single-AZ 'HA', gold-plated always-on capacity, security as an afterthought, unmeasured releases.

Motivation

Why do you need it?

  • Principles turn 'fix it later' into the default-right decision on the drawing board.
  • Failure design is the cheap pre-payment: designing for 'a region dies' on paper is far cheaper than uncovering it in the incident.
  • The pillars give teams a shared checklist so reviews are fast and honest.
  • Anti-patterns are the parsimony gauge: spot them in a diagram and you've learned the principle behind them.
Think about it

Mental model

Imagine

A city's zoning code: fire exits, water, power redundancy are the law, not afterthoughts

Think of

Cloud principles

The city doesn't decide after a fire that it needed a second water main — the code (principles) forced it in before. Architecture reviews are zoning review for services.

Mechanics

How it works

  • Start from failure design: name the failures your system must survive (instance, AZ, region).
  • Keep tiers stateless: state outside instances, everything re-creatable.
  • Apply elasticity: autoscale with the cost shape matched.
  • Security + cost as design gates (least privilege, unit economics at review).
  • Run the pillars as a review checklist before each release/ADR.

Principles at work.

Failure-first
Stateless tiers
Elastic
Security/cost gates
Pillars review
Hands-on

Examples

Principle spelled out

Principle spelled out
# Design principle: stateless web tier
# - sessions/state out of instances (cookies/Redis/DB)
# - uploads to object storage (S3/GCS), never EBS-mounted web dirs
# - instance image = code + config only; anything else = drift
# Consequence: kill any instance, autoscaler replaces in minutes;
# nothing survives a deploy, restart or brain-slap.

One principle, concrete consequences, and an enforced rule of thumb — that's how axioms become code.

Real world

In production

  • ADR template lists which principle-ish each design satisfies.
  • Well-Architected review quarterly (or on incident) scores the stack.
  • Non-negotiables: stateless tier, multi-AZ, least privilege, unit-cost dashboard.
Guidelines

Best practices

  • Encode pillars as a PR/ADR checklist so review isn't vibes.
  • Make the stateless rule structural (no instance-local state storage; Etc. policy).
  • Design failures in writing: the 'survivable failure' statement per service.
  • Review anti-patterns explicitly at design time (spike monoliths, single points).
  • Keep principles short and phraseable — a team that can't say them can't use them.
Watch out

Common mistakes

  • Principles discussed once, then every dev sorts their own judgment.
  • Stateless tier but state sneaks back (uploads to the instance, sessions on-disk).
  • Elasticity as a wall: autoscale exists but costs blow because shape never matched.
  • Reviewing pillars after the incident instead of before the design.
When things break

Debugging tips

  • An instance holds state you thought stateless → trace the writes; the last 'quick fix' usually reintroduced it.
  • Autoscaling thrash → elasticity params vs billing shape mismatch; review the policy with cost in view.
  • A design 'passes review' but fails in incident → the checklist wasn't failure-first; lead with the survivable-failure statement.
  • Cost creep despite principles → the unit-cost gate wasn't wired into releases; add it to CI/ADR.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

The principle that makes autoscaling + draining painless:

2

Where principles do most of their saving:

Go deeper

Official documentation

AWS Well-Architected
docs
Azure Well-Architected
docs
GCP Architecture Framework
docs