What the Cloud Is

00How This Course Works

This is a course about building and operating real systems, not a survey of vendor product names. Every week we develop a concept and then apply it to something that has to actually run. There is no textbook and no examination. Your entire grade comes from four projects, each worth 25%, and each project produces two things: a working deployment and a written document that explains and defends the architecture. If the system runs but you cannot explain why you built it that way, the project is not finished.

The sessions themselves are working sessions. This is a tutorial-size section, which means every one of you presents current work at essentially every meeting and takes part in critiquing everyone else's. Come with your development environment running and be ready to share your screen. The notes — this document and the fourteen that follow — are posted before the session they belong to. Read them first. Session time is for the parts that only work live: seeing something break, arguing about a trade-off, and watching each other debug.

01The Problem the Cloud Solves

Before you can define cloud computing usefully, you have to understand what was wrong with the alternative, because every property of the cloud is a response to a specific pain.

Suppose it is 2004 and you are launching a web application. To serve traffic you need servers. To get servers you must forecast demand months ahead, obtain capital approval, order hardware with a six-to-twelve-week lead time, rent rack space in a data center, buy network transit and power, install and configure the machines, and hire someone to be physically present when a disk fails at 3 a.m. Only then can you serve your first request.

This produces a specific and unavoidable trap. You must buy for your peak load, but you pay for that capacity continuously. A retailer sizing for Black Friday buys a fleet that sits at perhaps fifteen percent utilization for the other 360 days of the year. Meanwhile the cost of being wrong is asymmetric in an ugly way: over-provision and you have burned capital on idle metal; under-provision and your service falls over during the single event that mattered most, and the fix is twelve weeks away.

Notice that the binding constraint here is not really cost. It is time. Capacity decisions had to be made long before the information needed to make them existed. Cloud computing is, at bottom, the collapse of that lead time from months to seconds, and everything else follows from it. When capacity becomes available in seconds and is billed by the second, forecasting stops being a bet and becomes a feedback loop.

02A Working Definition

The most durable definition is the one NIST published in Special Publication 800-145, and it has aged well because it describes properties rather than products. It identifies five essential characteristics. A service that lacks any of them is probably just someone else's data center with a nicer sales page.

Two of these deserve emphasis because they are the ones students underweight. Resource pooling is the reason the economics work at all — the provider can run high aggregate utilization precisely because your peak and someone else's peak happen at different times. And measured service is the reason cost becomes an engineering concern rather than a procurement concern: when the meter runs per-second, a sloppy loop that leaves an instance running is not a paperwork problem, it is a bug with a dollar value attached.

03Service Models: IaaS, PaaS, SaaS, and FaaS

Service models answer one question: where is the line between what the provider operates and what you operate? Everything else — how much control you have, how much operational work you inherit, how portable you are, and how you are billed — falls out of where that line sits.

Think of the stack from the bottom up: facility and power, physical hardware, virtualization, operating system, runtime, application code, data, and access control. In every model the provider takes a bottom slice and you keep the top slice. The models differ only in where the cut is made. Move the cut and watch what you inherit.

IaaS hands you a virtual machine and gets out of the way. You have near-total control and near-total responsibility: if a kernel CVE is published on a Tuesday, patching it is your job. This is the model with the fewest constraints and the most operational surface area, and it is where Project 1 begins, because you cannot reason about the abstractions above it until you have felt what they abstract away.

PaaS takes the operating system away from you and gives back time. You push code; the platform builds, runs, patches, and scales it. The cost is constraint — you conform to the platform's supported runtimes, its deployment model, and its opinions. That trade is usually good until the day it isn't, and the day it isn't is expensive, because migrating off a platform you have built around is not a weekend of work.

SaaS is the model you are already a heavy consumer of. Architecturally the interesting question is not how it works internally — you cannot see that — but what your obligations become: you still own your data, your users' access, your configuration, and the integration points. Most publicized “cloud breaches” involving SaaS are not provider failures at all; they are customer misconfiguration.

FaaS, or serverless functions, pushes the line as far up as it goes. You supply a function; the provider supplies everything including the decision of when to run it, and if nothing invokes it you pay nothing. It is exceptional for spiky, event-driven, short-lived work. It is a poor fit for long-running jobs, workloads needing predictable low latency (cold starts are real), or anything holding significant state in memory between calls. “Serverless” is a billing and operations claim, not a physics claim — there is still a server.

Real systems mix all four, and mixing them well is the skill. A typical architecture in this course will run containers on managed infrastructure, store objects in a managed store, fire functions on events, and authenticate users against something you did not build. The models are a vocabulary for describing the parts, not a menu from which you pick one.

04Deployment Models

Where service models describe who operates what, deployment models describe who the infrastructure is shared with and where it physically sits.

Be skeptical of multi-cloud as a default posture. It is frequently justified by “avoiding lock-in,” but the practical effect is that you must operate against the intersection of the providers' capabilities rather than the union, which means giving up the managed services that made the cloud worth using and building the difference yourself. Your team also carries two of everything: two identity models, two networking models, two billing models, two on-call runbooks. Sometimes that price is worth paying. It should be a decision with a stated reason, and in this course, if you propose it, you will be asked to state the reason.

05The Economics of Elasticity

The headline framing is that the cloud converts capital expenditure into operating expenditure — instead of buying an asset you rent a service. That is true and it is also the least interesting part. The part that changes how you design systems is this: capacity you are not using costs you nothing, so utilization becomes an engineering variable you control.

5.1 The shape of a spiky workload

Take a service whose load is spiky in the ordinary way: it needs several instances for a few hours a day and one instance the rest of the time. Drag the controls and watch what happens to the shaded region — that region is capacity you bought and did not use, and under the owned model you pay for all of it.

Nothing about the application changed — only the provisioning policy. But note carefully what produced the saving: it was not “the cloud is cheaper per unit.” Per instance-hour, the cloud is more expensive than owning hardware you keep busy. The saving came entirely from not paying for the idle hours. Push the baseline slider up until the load is flat and the saving disappears — and at that point a well-run owned fleet or a reserved-capacity commitment may genuinely beat on-demand pricing. Elasticity pays when load varies. Know which case you are in before you claim a number.

5.2 The line everyone forgets

Compute is the cost students estimate. Storage is the cost they underestimate. Data transfer out is the cost they forget entirely, and it is regularly the largest line on a real bill. Drag the egress slider and watch which segment takes over.

Egress commonly dominates. This asymmetry — cheap to put data in, expensive to take it out — is deliberate and it shapes architecture. It is why content delivery networks exist, why you compress and cache aggressively, why you process data in the region where it lives rather than shipping it elsewhere, and why cross-region replication is a decision with a recurring price rather than a checkbox. It is also, not incidentally, a lock-in mechanism: the cost of leaving a provider scales with how much data you have accumulated there.

Prices move. The rates above reflect published US-region on-demand pricing as of Fall 2026 and are here to make the shape of a cloud bill concrete, not to be memorized. In your project cost estimates, always cite the provider's current pricing page and state the region, because rates vary meaningfully between regions.

5.3 Second-order costs

• Idle and orphaned resources. Unattached storage volumes, load balancers with no targets, and instances someone spun up for a test in March all bill indefinitely. This is the single most common source of surprise charges, including in this course.
• Cross-zone and cross-region traffic. Chatty services placed in different availability zones pay per gigabyte to talk to each other.
• Managed-service premiums. A managed database costs more per hour than the same database on a raw instance. You are buying backups, patching, failover, and someone else's on-call rotation. Usually worth it — but say so explicitly rather than pretending it is free.
• Overprovisioned instance sizes. Choosing a large instance “to be safe” is the old capacity-planning reflex, and it converts an elastic system back into a static one.

There is one more line the service models draw, and it is not about cost: not just who operates each layer, but who secures it. That is the shared responsibility model, and it gets its full treatment in Week 6, alongside identity, access management, and encryption. Until then, carry one preview with you: the dashed floor in Plate 3.1 — your data, and who can reach it — never transfers to the provider, in any model.

06Before Session 2 — September 9

Week 1 is a guided setup week. Everything below must be working before we meet again, because Session 2 assumes it. If you get stuck, email me — do not spend three hours on an install problem. Tick items off as you go; the list remembers your progress on this device.

• Create a free-tier cloud account with AWS, Google Cloud, or Azure. Pick one provider and stay with it for the whole term; switching mid-course will cost you a project. AWS's current free plan gives new accounts a $100 sign-up credit plus up to $100 more for completing setup activities, and it runs six months or until the credits are spent, whichever comes first — note that on the free plan the account closes when that window ends, so do not park anything you care about there without a backup.
• Set a billing alert immediately after signup. Before you create a single resource, configure a budget alert at a threshold you would actually notice — $5 is fine. This is not optional and it is not busywork; it is the habit that separates a $2 mistake from a $400 one.
• Install Git and create a personal GitHub account if you do not have one. All four projects are submitted as Git repositories, and your commit history is treated as evidence of individual work, so commit as you go rather than in one heroic push at the end.
• Join the course repository. Send me your GitHub username and I will add you. All notes, worked examples, and project specifications live there; pull the current version before every session.
• Install Docker Desktop or an equivalent container runtime, and confirm it runs by executing docker run hello-world. We start using it in Week 2.
• Install a code editor you are comfortable with. VS Code is recommended, mostly because its remote and container tooling will save you time later.

07Key Terms

Elasticity

The ability to acquire and release capacity quickly in response to actual demand.

Scalability

The ability of a system to handle increased load. Related to but distinct from elasticity: elasticity is about speed and reversibility.

Multi-tenancy

Multiple unrelated customers sharing the same underlying physical resources, isolated logically.

Provisioning

The act of allocating and configuring a resource.

On-demand pricing

Paying per unit of consumption with no commitment, at the highest per-unit rate.

Reserved / committed use

Discounted pricing in exchange for a usage commitment over one or three years.

Egress

Data leaving the provider's network, typically to the public internet. Usually billed; usually underestimated.

Region / Availability Zone

A region is a geographic location; an availability zone is an isolated failure domain within it.

No term matches that filter.