13.1 — The Cloud Mental Model

A team deploys three servers "in the cloud" for redundancy. All three land in the same availability zone, because that was the default. A power event takes out that zone and all three go down together.

Nothing was misconfigured. They bought three copies of a machine and believed they had bought resilience, which are different purchases. The difference is the physical layout underneath the console, and that layout is the first thing to understand — because almost every architectural rule in this Part is derived from it.

1. What is physically there

A data centre is a building: racks of servers, redundant power feeds, generators, batteries, cooling, and fibre entering from more than one direction. Nothing exotic — a warehouse with very good electricity.

An availability zone is one or more data centres that share a failure domain — power, cooling, physical site — while being isolated from other zones. A zone is a unit of correlated failure: if a transformer fails or a cooling system floods, everything in that zone is at risk together.

A region is a cluster of availability zones in one geography, typically three or more, physically separated by kilometres but linked by dedicated high-bandwidth fibre.

That last sentence is the whole design, and it is worth reading twice. The separation is far enough that one flood, fire or substation failure cannot take two zones, and close enough that the round trip between them is one to two milliseconds — low enough for synchronous replication (Chapter 10.5). That single engineering compromise is what the entire high-availability story of cloud computing rests on.

So the architectural rules fall out mechanically:

• Spread across zones within a region for availability. Cheap, low latency, and it survives the common failure.
• Spread across regions only for disaster recovery, data residency, or user latency — because cross-region latency is tens to hundreds of milliseconds and traffic between regions is charged.
• A region is also a failure domain. Regional control planes have failed, and a single-region system has an outage mode you cannot engineer away from inside it.

Two related terms. Edge locations (points of presence) are small facilities near users, holding caches and terminating connections — hundreds of them, versus dozens of regions. Local zones put a small amount of compute close to a city for latency-sensitive workloads.

2. The service models

IaaS — virtual machines, disks, networks. You manage the operating system upwards.

PaaS — you deploy code, the platform runs it. App Service, App Runner, Cloud Run.

SaaS — you use software. The vendor manages everything.

FaaS / serverless — you deploy a function, the platform runs it per request. Chapter 13.3.

The useful way to read the ladder: each step up removes work and removes control, and the trade is almost always worth it until it is not. Managed databases, managed queues and managed load balancers are nearly always right. The point at which it stops being right is when you need behaviour the managed service does not expose, or when the volume makes the margin material.

3. The shared responsibility model

The most misunderstood contract in cloud computing, and misunderstanding it is how data leaks happen.

The provider is responsible for security of the cloud. Physical facilities, hardware, the hypervisor, the network fabric, the managed services' own software.

You are responsible for security in the cloud. Your data, your access control, your network rules, your patching above the line, your application.

Where the line sits depends on the service, and that is the part people miss:

Service type	Provider handles	You handle
Virtual machine	Hardware, hypervisor	OS patching, firewall rules, application, data
Managed database	OS, engine patching, backups	Schema, access control, encryption choices, data
Serverless function	Everything below your code	Code, permissions, dependencies, data
SaaS	Almost everything	Access control and data

Every row ends with your data, and the object-storage leaks that appear in the news every year are all the same story: a bucket made public by its owner. The provider's storage was never compromised.

Two practical consequences. Provider compliance certifications cover their half — they do not make your application compliant. And "managed" never means "you can stop thinking about backups": automated backups exist, and whether they are retained long enough, tested, and protected from deletion is yours.

4. What "cloud native" actually means

The phrase is used to mean "modern" and has a real definition worth holding: software designed for an environment where individual machines are unreliable, replaceable and dynamically allocated.

Concretely:

• Stateless where possible, so any instance can serve any request and instances can be replaced freely (Chapter 10.2).
• State in managed services, not on local disks.
• Configuration from the environment, not baked into the artefact.
• Health checks and graceful shutdown, so an orchestrator can move you (Chapter 9.9.7).
• Horizontal scaling, not a bigger machine.
• Infrastructure as code, so environments are reproducible (Chapter 13.8).
• Observability built in, because you cannot log into a machine that no longer exists (Chapter 10.10).

The honest version: "cloud native" is a design philosophy, not a technology choice, and running a monolith in a container on Kubernetes is not cloud native if it stores sessions on local disk. Lifting an application onto virtual machines unchanged is a legitimate strategy — it is called lift and shift, it is often the right first step, and it should be called what it is rather than dressed up.

5. On-premises versus cloud, without the marketing

Cloud advantages that are real:

Elasticity. Pay for what you use, scale in minutes. This is the genuine transformation — capacity that used to require a purchase order and eight weeks now takes a command.

No capital expenditure, which changes what a small company can attempt.

Managed services, so a small team runs infrastructure that used to need specialists.

Global reach — a region on another continent in minutes.

Cloud disadvantages that are equally real:

It is more expensive at steady high utilisation. Elasticity is the product, and if your load is flat and predictable, you are paying for flexibility you do not use. Several well-known companies have moved workloads back on-premises and published the arithmetic.

Egress charges. Data in is free, data out is not, and this is a deliberate structural cost that makes leaving expensive.

Lock-in through managed services. Virtual machines are portable; a system built on one provider's queue, database, identity and functions is not.

Less control over performance, over the timing of maintenance, and over debugging what you cannot see.

The honest position: use the cloud, and know your exit. Prefer portable interfaces where the cost is low — a container instead of a proprietary runtime, PostgreSQL instead of a proprietary engine — and accept lock-in deliberately where the managed service is genuinely better. Multi-cloud "for portability" usually costs more than the lock-in it avoids, because you build to the intersection of features and operate two of everything.

6. Storage performance, and IOPS

Storage is priced and provisioned on numbers that people quote without meaning, so define them once.

IOPS — input/output operations per second. Relevant for small random operations, which is what a database does (Chapter 7.3.1).

Throughput — megabytes per second. Relevant for large sequential reads, which is what analytics does.

Latency — how long one operation takes.

They trade against each other, and the workload decides which you buy. A database wants IOPS and low latency; a log archive wants throughput and cheap capacity.

The tiers you will meet:

• Local instance storage — physically attached, fastest, and it disappears when the instance stops. For caches and scratch space only.
• Network block storage — a virtual disk over the network. Survives the instance, and you provision IOPS and throughput.
• Network file storage — a shared filesystem several machines can mount.
• Object storage — HTTP-addressed blobs, effectively unlimited, cheapest, and not a filesystem (Chapter 13.4).

The trap worth naming: burst credits. Many entry-level volume types provide high performance in short bursts and drop to a low baseline when the credits run out. A database that was fast for three weeks and then became permanently slow, with no code change, is nearly always this — and it looks exactly like a mysterious application regression.

7. Cost, as an engineering property

Cloud cost is a function of architecture, which makes it an engineering concern rather than a finance one.

The pricing dimensions that dominate:

• Compute time — per second, with large discounts for commitment or interruptibility.
• Storage — per gigabyte-month, by tier.
• Data transfer — free in, charged out, charged between zones, charged more between regions.
• Requests — per million, for object storage, functions and API gateways.
• Managed service premiums — a managed database costs meaningfully more than the same instance running the engine yourself, and usually earns it.

The purchasing options are worth knowing precisely because the savings are large:

On-demand — full price, no commitment. Right for unpredictable load and for anything you might turn off.

Reserved instances / savings plans — commit to a level of usage for one or three years, save 30–70%. Right for the steady baseline, and the analysis is straightforward: whatever you have run continuously for six months should be committed.

Spot / preemptible — spare capacity at 60–90% less, reclaimable with a short warning. Right for anything interruptible and checkpointed (Chapter 12.9's training runs, batch jobs, CI runners), wrong for user-facing serving.

The architectural decisions that dominate the bill:

Cross-zone traffic. A chatty service mesh spread across three zones pays per-gigabyte for its own internal chatter. Zone-aware routing — prefer a local replica — is a real and frequently large saving.

NAT gateway data processing. Every byte a private instance sends to the internet is charged per gigabyte. A pipeline pulling terabytes from object storage through a NAT gateway is a classic surprise, and a VPC endpoint removes it entirely (Chapter 5.10).

Object storage tiers and lifecycle rules. Data nobody has read in ninety days does not belong in the hot tier.

Idle resources. Unattached disks, forgotten load balancers, stopped instances with provisioned storage, development environments running at weekends. These are boring and they are usually the largest immediate saving available.

Tag everything and make cost visible per team and per service. FinOps as a discipline is mostly that: attribution, so the people who can change the architecture can see what it costs. A cost anomaly alert catches the runaway job on day one instead of on the invoice.

What the interviewer will push on

"What is the difference between a region and an availability zone, and why does it matter?" A zone is a failure domain — shared power, cooling and site; a region is several zones separated by kilometres but linked with 1–2 ms fibre. That latency is what makes synchronous cross-zone replication possible, which is the whole basis of cloud high availability. Multi-zone for availability, multi-region only for disaster recovery, residency or user latency.

"Explain shared responsibility." The provider secures of the cloud, you secure in it — and the line moves per service. Then the point that matters: every row ends with your data, which is why every public-bucket incident is a customer misconfiguration rather than a provider breach.

"When is the cloud the wrong choice?" Steady, predictable, high utilisation, where you are paying for elasticity you never use — and where egress charges dominate. Naming that the exit cost is structural, and that multi-cloud usually costs more than the lock-in it avoids, is what makes this a considered answer rather than a slogan.

"How would you reduce a cloud bill?" In order of value: delete idle resources, commit the steady baseline with savings plans, move interruptible work to spot, fix cross-zone and NAT traffic with locality and VPC endpoints, apply storage lifecycle rules — and tag everything so cost is attributable to the team that can change it.

"Your database got slow after three weeks with no deploy. What do you check?" Burst credit exhaustion on the storage volume, and the working set outgrowing the buffer pool (Chapter 7.3.1). Both are gradual, both have no code change, and both look like a mysterious regression.

One thing to volunteer: point out that three instances in one availability zone is three copies of a machine, not redundancy — and that this is a default, not a mistake anyone makes deliberately. It is the simplest example of why the physical layout has to be understood rather than abstracted away.

Recall

• A data centre is a building; an availability zone is a shared failure domain; a region is several zones kilometres apart with 1–2 ms fibre between them — far enough to fail independently, close enough for synchronous replication. Every availability rule follows from that.
• Multi-zone for availability; multi-region only for disaster recovery, residency or latency, because cross-region is tens of milliseconds and charged.
• Shared responsibility: provider secures of the cloud, you secure in it, and the line moves per service. Every row ends with your data — which is why every public-bucket leak is a customer misconfiguration.
• "Cloud native" means designed for unreliable, replaceable, dynamically allocated machines: stateless, state in managed services, config from the environment, health checks and graceful shutdown, horizontal scaling, infrastructure as code, observability. Lift and shift is legitimate — call it what it is.
• Cloud wins on elasticity, no capital expenditure, managed services and reach. It loses on steady high utilisation, egress charges, lock-in and control. Know your exit; multi-cloud usually costs more than the lock-in it avoids.
• IOPS for small random operations, throughput for large sequential ones, and they trade off. Local instance storage disappears with the instance. Burst credit exhaustion is the cause of "the database got slow after three weeks with no deploy".
• Cost is architecture: cross-zone chatter, NAT gateway data processing (fixed by VPC endpoints), storage tiers, and idle resources. Commit the steady baseline, use spot for interruptible work.
• Tag everything. FinOps is mostly attribution, so the people who can change the design can see the bill — plus an anomaly alert that catches a runaway job on day one.

Self-test: Why are zones kilometres apart rather than adjacent or continents apart? · Where does the responsibility line move between a virtual machine and a managed database? · Name two real disadvantages of cloud that are not marketing. · What is the difference between IOPS and throughput, and which does a database want? · Which two gradual failures make a system slow with no deploy? · What is the first thing to do about an unexplained bill?

Next: 13.2 takes the networking primitives from Chapter 5.10 and covers what the cloud adds on top — address management at enterprise scale, why IPv4 now costs money, and how traffic actually enters and leaves a private network.