How the Cloud Actually Works

Someone Else's Computers, and Why That Matters

The joke is that there is no cloud, just someone else's computer, and it is true enough to be a decent starting point. Amazon, Microsoft and Google own enormous numbers of machines in buildings around the world, and they rent slices of them out by the hour. Everything else follows from that arrangement.

What is worth understanding is why that arrangement changed things, because it was not really about the hardware. Before it, running a website meant buying servers. You had to guess how much traffic you would get, buy enough machines for your best guess, pay for them all upfront, wait weeks for delivery, and then live with the answer for three years. Guess too low and the site fell over on your biggest day. Guess too high, which nearly everyone did, and you had paid for machines that sat idle.

Renting by the hour dissolves that whole problem. You can have one server this morning and forty this afternoon and one again tonight, and pay for exactly what you used. In accounting terms a large upfront purchase turned into a monthly running cost, which is the part that made finance departments care. In engineering terms, capacity stopped being a guess you were locked into and became a dial you could turn. That is the actual shift. The buildings full of machines are just what makes it possible.

What You Are Actually Renting

When you start a virtual machine - an EC2 instance, in Amazon's vocabulary - you are not given a computer. You are given a portion of one, running alongside other people's portions of the same physical machine, with a layer of software called a hypervisor dividing it up and keeping everyone apart.

This has practical consequences. The first is that a vCPU is not a CPU core. It is generally one hardware thread, and two threads typically share one physical core, so a 2 vCPU instance is closer to one core's worth of real capacity than two. Instance sizes read as bigger than they are, and this catches people out when they compare cloud pricing against a physical machine they already own.

The second is a genuinely nasty trap for beginners. The cheap t-family instances - t3, t4g, the ones every tutorial starts with - are burstable. They are not sold a steady share of the processor; they earn credits while idling and spend them while working. Run at full tilt for long enough and the credits run out, at which point the instance is throttled to a fraction of its rated speed and stays there. It does not crash and nothing appears in your logs. It just gets mysteriously, permanently slow, and people lose entire afternoons to this before discovering the credit balance graph exists.

Regions Are Not Buildings

Cloud providers divide the world into regions, and a region is a geographic area rather than a single site. Inside each one are several availability zones, and an availability zone is one or more physically separate data centres with their own power, cooling and network connections. They are close enough to each other to be a couple of milliseconds apart, and far enough apart that a fire, a flood or a failed substation should only take out one of them.

Which region you pick is a real decision with three separate consequences. There is latency, since a server in Frankfurt will always answer a user in Frankfurt faster than one in Virginia can. There is law, because data protection rules including GDPR care a great deal about which country your users' data physically sits in, and choosing a region is how you answer that question. And there is money: the same instance genuinely costs different amounts in different regions, sometimes by twenty or thirty percent, which is why so much of the world's infrastructure quietly lives in us-east-1.

The most important thing to internalise is the last line of that diagram. Regions are isolated from each other by design. Your data does not exist in another region unless you explicitly arranged for it to be copied there, and you will be paying for that copying. People assume the cloud is a single global thing that magically handles this. It is not.

What Failure Actually Looks Like

Availability zones exist so that you can survive losing one. Running your application in two zones means a lost building costs you half your capacity rather than all of it. Running a managed database in multi-AZ mode means there is a synchronised standby copy in a different building, ready to take over. This costs roughly double, because you are running two of everything, and that is the honest trade: you are buying insurance, priced accordingly.

It is worth being realistic about what actually goes wrong, though. Entire zones do occasionally fail, but the outages that take large parts of the internet down with them are usually not a building losing power. They are far more often a configuration change, a software bug, or a failure in something central like DNS or an authentication service that everything else quietly depended on. Spreading across zones is genuinely worth doing. It just does not protect you from the most common cause of a bad day, which is a change somebody made.

Who Is Responsible When Something Goes Wrong

This is the part people skip, and it is the part that ends up in the news. Cloud providers work on what they call a shared responsibility model, and the shortest version is that the provider is responsible for the security of the cloud, and you are responsible for security in the cloud. They keep the buildings locked, the hardware working and the hypervisor sound. What you put on top of it, who can reach it, and how it is configured, is entirely yours.

Read that diagram from left to right and the pattern is clear. On a plain virtual machine, patching the operating system is your job, and an unpatched machine is your problem. Move to a managed database and Amazon takes over the operating system and the database engine, leaving you the schema and the data. Move to managed storage and almost everything becomes theirs. But look at what never crosses the line: your data, and who is allowed to read it. That responsibility is yours at every level, no matter how managed the service is.

Which is precisely why the most famous category of cloud breach is not a break-in at all. It is a storage bucket left open to the public by whoever set it up. No firewall was defeated and no password was cracked. Someone ticked the wrong box, and the diagram above says plainly whose job that box was. Every one of those incidents sits in the top row.

How the Bill Actually Works

Cloud pricing looks complicated because it is quoted in tiny units, but almost everything reduces to four things: time that something is running, space that something occupies, data moving around, and the number of requests you make. The tiny units are genuinely misleading, though. A charge of $0.045 an hour reads as nothing and is $32 a month, every month, forever.

Here is what a small but real setup actually costs. These are approximate United States prices at the time of writing and they change, so treat the shape as the lesson rather than the exact figures.

A small production web application, one month

  EC2  t3.small, running 24/7             $0.0208/hr x 730     $15.18
  EBS  20 GB gp3 disk                     $0.08/GB             $ 1.60
  RDS  db.t3.micro Postgres, single AZ    $0.017/hr x 730      $12.41
  RDS  20 GB storage                      $0.115/GB            $ 2.30
  ALB  load balancer, just to exist       $0.0225/hr x 730     $16.43
  S3   50 GB of images                    $0.023/GB            $ 1.15
  Data 200 GB out to the internet         $0.09/GB after 100 GB $ 9.00
  ----------------------------------------------------------------------
                                                               $58.07

  Add multi-AZ for the database:                              +$12.41
  Add a NAT gateway (see below):                              +$32.85
  ----------------------------------------------------------------------
  The same application, done properly                          $103.33

Two lines in there deserve singling out, because they are where surprise bills come from. The first is data transfer. Sending data into AWS is free; sending it out to the internet is not, at roughly nine cents a gigabyte after the first hundred. That sounds trivial until you serve video, or large images, or let people download files, at which point it can quietly become the largest line on the bill. It is also, not coincidentally, the charge that makes leaving expensive.

The second is the NAT gateway from the previous lesson - the box that lets servers in a private subnet reach out to the internet. It costs about four and a half cents an hour simply for existing, which is $32 a month before it has moved a single byte, plus another four and a half cents for every gigabyte it processes. It is the single most common source of a first cloud bill being far larger than expected, because nothing about setting one up suggests it is a significant cost.

Why This Is Not Automatically Cheaper

There is a persistent assumption that moving to the cloud saves money. Often it does not, and it helps to understand why. Amazon is not running these data centres as a favour - AWS is consistently the most profitable part of Amazon's business, with operating margins that a retailer could only dream of. That margin is real, and you pay it. What you are buying with it is elasticity, someone else's operational staff, and the ability to start with no capital at all.

That trade is excellent when your load is variable, when you need to be near users on several continents, when you genuinely benefit from managed services you would otherwise have to run yourself, or when you cannot or do not want to spend money upfront. It is a much worse trade when your load is steady and predictable, because then you are paying a premium for flexibility you never use. A rented server at a hosting company, at a fixed monthly price, is frequently a third of the cost for that shape of workload. Several well-known companies have moved substantial systems back off the cloud for exactly this reason, and were not wrong to.

It is worth being concrete about this, so here is a real example: this site. Dawn runs on a small managed hosting platform with a managed Postgres database, and costs somewhere between nothing and about seven dollars a month. The equivalent arrangement built properly on AWS is the table above - somewhere between fifty and a hundred dollars. For a site with this traffic and this need for elasticity, which is to say almost none, paying that premium would buy nothing that matters. That is not an argument against AWS. It is an argument for knowing what you are buying, which is the entire point of this lesson.

What to Take Away

Four things. You are renting a share of a machine, not a machine, and the isolation between tenants is the actual product. A region is a geographic area containing several separate buildings, and nothing crosses between regions unless you arranged it. Responsibility is shared on a line that moves depending on how managed the service is, and your data and its permissions never cross that line. And the bill is driven by time, space, transfer and requests, with data leaving and a handful of always-on components being where the unpleasant surprises live.

The next lesson takes the first of those and pulls on it, because there is more than one way to rent a share of a machine, and choosing between them changes what you pay, how fast it starts, and how much of it you are allowed to touch.