Cloud Fundamentals

Cloud computing means renting computing capacity — servers, storage, networking, databases — from a provider who owns and operates the physical hardware. You do not buy machines, install them in a rack or replace failed disks. You request capacity through an API, use it, and stop paying when you release it.

That sounds simple, and the mechanics are. What takes time to internalise is the surrounding structure: where your resources physically live, how they are organised, who is allowed to change them, and how the bill is assembled.

Almost every wrong answer on a certification exam is wrong because of one of these fundamentals rather than the product being discussed. A design fails because the resource is in the wrong region, or the permission was granted at the wrong level of the hierarchy, or the cost model was misunderstood.

Get these right and the rest of the platform becomes much easier to reason about, because every product inherits the same rules about location, identity and billing.

• Region — a geographic area containing multiple independent data centres. Choosing a region decides latency to your users and, often, your legal data residency position.
• Zone — one isolated deployment area inside a region. Zones fail independently, which is why high availability designs spread across at least two of them.
• Multi-region — a service configuration that spans several regions, giving the highest durability and availability at a higher cost.
• Project — the fundamental container. Every resource belongs to exactly one project. Projects hold their own IAM policy, APIs, quotas and billing link.
• Folder — groups projects, typically by department, environment or team, so policy can be applied to many projects at once.
• Organisation — the root node representing your company. Policy set here applies to everything beneath it.
• Billing account — pays for one or more projects. Separating billing from the project structure is deliberate: who pays and who administers are different questions.
• Shared responsibility — the provider secures the underlying infrastructure; you secure what you put on it, including your identities, configurations and data.

The critical property is inheritance. A permission granted at the folder level applies to every project inside it, and every resource inside those projects. This is powerful and it is also the most common source of accidental over-permission: someone grants a broad role high in the hierarchy for convenience, and it silently applies to hundreds of resources.

Cloud pricing has a small number of recurring shapes. Once you recognise them, most cost questions become straightforward.

• Per-second compute — you pay for the time a machine is running, with automatic discounts for sustained use and larger committed discounts if you promise usage in advance.
• Storage by volume and class — you pay for gigabytes stored per month, at a rate that drops sharply for data you rarely read but rises for retrieving it.
• Network egress — data leaving the provider's network costs money; data coming in generally does not. This is the charge that surprises people most often.
• Per-request or per-query — many managed services bill by operation rather than by machine, which is why an idle serverless service can cost nothing at all.

A useful rule when comparing designs: the cheapest option at low volume is frequently the most expensive at high volume, and vice versa. Cost questions almost always specify a volume for exactly this reason.

• Separating development, staging and production into distinct projects so a mistake in one cannot affect another.
• Applying an organisation-wide policy that prevents any project from creating publicly accessible storage.
• Placing resources in a specific region to satisfy a data residency requirement.
• Setting a budget alert on a billing account so runaway spend is noticed within hours rather than at month end.