What is the cloud, and what do AWS and Google actually sell?

What is the cloud, and what do AWS and Google actually sell?

The cloud is computing power rented from another company by the hour. AWS, Google Cloud, and Azure are the three largest sellers of it, and what they sell is the use of their machines: servers, storage, databases, and the network that connects them, billed by usage the way a utility bills for electricity.

The name misleads. Nothing floats. The cloud is warehouses full of computers, owned by a handful of companies, and "in the cloud" means "running on machines we rent instead of machines we own". The word caught on because diagrams of the internet used to draw the far side of the network as a cloud shape, a fuzzy region whose insides did not matter to the drawing. The sections below open that fuzzy region up: where code physically runs, what the big providers sell, what infrastructure covers, and what two of the most common words in engineering conversation, scaling and latency, actually mean.

Where does code physically run?

Every piece of backend code runs on a real computer in a real building. That building is called a data center: a warehouse holding thousands of servers in racks, with industrial power, cooling, and security. The frontend runs on the user's own phone or browser, which is why this section is about everything else.

A company has two choices for those machines. It can own them and run its own data center, or rent space in one. That arrangement is called on-premises, usually shortened to on-prem. Banks, hospitals, and governments still run a lot of on-prem systems, and experience with them signals comfort with strict rules and older technology that still carries the business. The second choice is renting the machines themselves from a cloud provider, and that is where most new software runs today.

Providers group their data centers by geography into regions. A region is a named cluster of data centers in one part of the world, like "US East" in Virginia or "Europe West" in Belgium. Teams pick regions to be near their users and to satisfy laws about where data may live. A developer who has dealt with multi-region systems has dealt with one of the harder classes of problem in the field, because keeping data consistent across an ocean is genuinely difficult.

What is the cloud?

The cloud is the rental model itself: computing bought as a metered service from someone else's data centers. Before it, launching a product meant buying servers, waiting weeks for delivery, and guessing how many you would need. Guess low and the product falls over on its best day. Guess high and money sits in a rack doing nothing.

The cloud replaced that guess with a dial. A team rents one server for a prototype, a hundred for launch week, and turns the dial back down after. Payment follows usage. This is the single biggest reason small teams can now build products that reach millions of users: the up-front cost of computing dropped to nearly zero, and capacity became a setting a team changes in an afternoon.

For reading a resume, the practical fact is that cloud experience is now the default. Most working developers touch a cloud provider in some form, so the useful information is which provider and how deep, which is the next section.

What do the big providers sell?

AWS, Amazon Web Services, is the largest cloud provider in the world and the most common one on a resume. Google Cloud (often written GCP) is Google's, and Azure is Microsoft's. Azure shows up most in large enterprises that already run on Microsoft, and Google Cloud is strong in data-heavy work. Each sells hundreds of individual services, from plain rented servers to managed databases, and the individual service names on a resume, like EC2 or S3 on AWS, are products within these catalogs.

The three differ in pricing, naming, and specific strengths, and they overlap almost completely in concept. A rented server is a rented server. A developer with years of AWS works in Azure after a ramp of weeks, because the ideas transfer even though every button is in a different place. Provider names on a resume mark familiarity rather than a boundary.

Two younger companies round out the names worth recognizing. Cloudflare started by protecting and speeding up websites and now sells computing that runs in hundreds of small locations near users instead of a few large regions. Vercel sells hosting aimed at frontend developers, built so that a web app goes live in minutes with the machinery hidden. Both appear often on the resumes of developers from small companies, where one person carries a product end to end and picks tools that remove work.

What is infrastructure?

Infrastructure is everything underneath the application: the servers, the network, the storage, and the tools that manage them. If the product is the restaurant menu, infrastructure is the kitchen, the plumbing, and the power. Users never see it, and everything they do see depends on it.

It is also a job. Infrastructure engineers, with titles like DevOps engineer, platform engineer, or SRE, spend their days on this layer rather than on features. They decide how the machines are arranged, automate their care, and carry the pager when something breaks at night. The keeping-it-alive lesson covers those roles in depth. The short version for now: when a hiring manager says a req is "more infra than product", they mean the work lives in this layer, and depth with a cloud provider matters more for it than polish in the visible app.

What does it mean when something "does not scale"?

Scaling means keeping a product fast and working as the number of users grows. A system that serves a hundred users can collapse at a hundred thousand, because every request does a little work, and a thousand times the requests is a thousand times the work landing on the same machines and the same database.

When a hiring manager says the current system "does not scale", they are saying it works today and would fail at the size the business is heading toward. That sentence is usually the reason the req exists. The fix means changing how work is spread across machines: adding servers behind a traffic-splitter, reworking how the data is stored, caching answers that get requested repeatedly. This is redesign work measured in months, and it is the classic project a company hires a senior backend or infrastructure engineer to lead.

The word also carries the most inflated phrase in the field: "worked at scale". Scale is relative. At one company it means ten thousand users, at another it means a hundred million, and the phrase alone says nothing about which. A developer who states their numbers plainly, users served, requests handled, is giving real information, and the numbers mean more than the phrase ever does.

What is latency?

Latency is the delay between a request and its answer, measured in milliseconds. A user taps a button, the request crosses the network to a server, the server does its work and answers, and latency is the total wait. Under about a hundred milliseconds feels instant. A few hundred feels sluggish. Whole seconds feel broken, and users leave.

Latency is the number engineering teams argue about most because every choice in this article feeds it. Region choice sets the physical distance a request travels, and distance is time: a signal from Sydney to Virginia and back spends around two hundred milliseconds on the trip alone, which is why global products run in multiple regions. Database design sets how long each answer takes to find. Scaling problems surface first as rising latency, since an overloaded system slows down before it fails. A developer who talks in these numbers unprompted, "we got checkout from four hundred milliseconds down to eighty", has been accountable for how a system feels to real users, and that accountability is the thread connecting everything this lesson covered. The module overview shows where this layer sits in the full path from an idea to a running product.