The cloud primer

At its foundation, cloud computing is about renting compute, storage, and networking capacity on demand, rather than purchasing physical servers and racking them in private data centers. Over the past decade, however, major cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—have shifted focus toward managed platforms: automated database engines, container orchestrators, event routers, and serverless runtimes.

While each hyperscaler wraps these capabilities in proprietary product names and distinct administrative consoles, the underlying systems architecture is remarkably consistent across all three. Once you understand how software-defined networks route traffic, how block volumes differ from object stores, or how distributed databases partition state, translating that knowledge across providers becomes straightforward catalog lookup rather than learning a new discipline.

This primer focuses on those core systems concepts and practical engineering trade-offs. Each page walks through the architectural mechanics, operational failure modes, and financial implications of a specific component. At the bottom of each page, provider-specific tabs map those concepts directly to AWS, Azure, and Google Cloud implementations.

What you are buying

Cloud services generally fall along a continuum of abstraction. Where a service lands on that spectrum determines how much operational burden remains with your engineering team versus how much is absorbed by the cloud provider:

Abstraction tier	What the provider manages	What your team manages	Typical service
Infrastructure as a Service (IaaS)	Physical hardware, power, physical networking, hypervisor layer	Operating system installation, kernel patching, network routing, and application runtime	Virtual machines
Managed platform (PaaS)	Hardware, hypervisor, OS maintenance, software patching, automated failover	Schema design, index tuning, query performance, and configuration flags	Managed SQL databases
Serverless (FaaS)	Hardware, operating system, container orchestration, automatic scaling down to zero	Application source code, event routing triggers, and execution timeouts	Event-driven functions

Higher abstraction levels command a higher price per unit of raw compute or storage, but they drastically reduce ongoing operational overhead. For a small engineering team with limited operational bandwidth, paying that premium to offload patching, high availability, and automated backups is almost always the rational economic choice. Conversely, large engineering organizations running tens of thousands of predictable, high-throughput instances often find that the raw compute savings of bare virtual machines justify maintaining dedicated infrastructure teams.

Shared responsibility

Every provider operates under what the industry terms the . In simple terms, the provider assumes responsibility for the security of the cloud, while you remain responsible for security in the cloud.

The provider protects the physical data centers, manages hypervisor isolation, patches host operating systems, and secures the physical backbones connecting facilities. Your responsibilities scale according to the abstraction tier you deploy. When running a raw virtual machine, your team must patch the guest operating system, configure local firewalls, and rotate access keys. When adopting a managed database or serverless runtime, the provider takes over operating system patching and hardware lifecycle, leaving you to manage access policies, transport security, and application-level secrets.

Critically, data classification and access control never leave your hands. Regardless of whether data sits in an unformatted block storage volume or an S3-compatible object bucket, misconfiguring public permissions or credential policies is your liability. The overwhelming majority of cloud security incidents stem not from hypervisor breaches, but from misconfigured permissions and exposed credentials in customer-managed environments.

Where things live

Providers partition their global footprint into geographic , and further subdivide each region into isolated . A region corresponds to a distinct metropolitan area—such as Northern Virginia, Frankfurt, or Tokyo—designed to keep local latency low and adhere to data residency mandates. Within that region, an availability zone consists of one or more physical data centers equipped with independent power feeds, backup generators, cooling infrastructure, and network links. Zones within the same region sit tens of kilometers apart: close enough to support single-digit millisecond round-trip times for synchronous replication, yet far enough to avoid sharing municipal flood plains or local power grids.

Selecting where to host workloads involves balancing three distinct requirements:

1. Network latency: Serving users from a region on the opposite side of the globe adds tens to hundreds of milliseconds of physics-dictated transit time to every network handshake.
2. Regulatory compliance: Many jurisdictions mandate that sensitive financial, healthcare, or personal records never cross sovereign borders.
3. Failure domains: While hardware components and single zones degrade frequently, an entire region-wide failure is catastrophic. Resilient systems treat the availability zone as the baseline unit of high availability, spreading active compute and database replicas across multiple zones. Multi-region deployments are reserved for business-critical systems that require disaster recovery guarantees or global low-latency edge delivery, as discussed in detail on the high availability page.

Placing a workload

Select regions based on compliance and user latency, then use zones for fault tolerance.

1. Deploy workloads into the region closest to the majority of active users, verifying that local data privacy regulations permit that choice.
2. Distribute all stateful services and stateless compute pools across at least two independent availability zones within that region.
3. Adopt multi-region active replication only when business requirements justify the additional egress bandwidth costs, data synchronization latency, and architectural complexity.

How you pay

Cloud billing structures hinge on three core dimensions: compute duration, data transfer, and storage consumption:

• Compute allocation: Standard virtual machines bill for allocated CPU cores and memory by the second, regardless of whether the guest operating system is running at full capacity or sitting idle. Serverless functions and event-driven containers break this model by billing strictly for execution duration and consumed memory, scaling to zero cost when idle.
• Network data transfer: Ingress traffic—data flowing into a provider's data center—is almost universally free. In contrast, outbound traffic leaving for the public internet or transiting between distinct regions incurs metered charges known as . Cross-zone traffic within the same region also carries small per-gigabyte costs. Egress frequently catches engineering teams off guard, especially when streaming large datasets, serving heavy media files without a content delivery network, or setting up uncompressed replication across regions.
• Storage and read/write operations: Disks and object stores bill for total gigabytes stored per month, combined with charges per thousand API read/write operations and provisioned IOPS. High-performance tiers cost significantly more per gigabyte, while archival cold tiers reduce storage rates at the expense of steep retrieval fees, as outlined on the storage page.

Managed against self-run

Virtually every infrastructure component—from relational databases and message brokers to Kubernetes clusters—can either be provisioned as a fully managed cloud service or deployed manually across bare virtual machines. For example, running PostgreSQL on a raw virtual machine gives complete control over custom extensions, local filesystem tuning, and configuration parameters, but places the burden of automated failover, point-in-time backups, minor version patching, and replication monitoring entirely on your team.

A managed database charges an hourly premium over the raw compute instances it provisions under the hood. However, that price differential generally pales in comparison to the engineering hours spent troubleshooting broken replication slots, testing recovery scripts, or responding to midnight storage exhaustion alerts. Unless a workload requires specific kernel modifications, unsupported database extensions, or massive scale where managed margins become prohibitive, defaulting to managed services preserves engineering focus for core business applications.

Talking to it

Every resource in a cloud platform is governed by control plane APIs. The web console and command-line utilities (CLIs) are simply HTTP clients issuing requests against those endpoints. While the graphical console is invaluable for interactive troubleshooting and initial exploration, configuring production environments manually through the browser introduces drift and human error.

Repeatable infrastructure relies on (IaC). Declarative frameworks such as Terraform, OpenTofu, AWS CloudFormation, and Pulumi allow teams to define networks, compute instances, database clusters, and access control policies in version-controlled configuration files. Treating infrastructure like application source code enables peer review, automated pull-request validation, reproducible staging environments, and rapid disaster recovery orchestration.

How this primer is organised

The primer is arranged into four sections, building upward through the infrastructure stack. Each page assumes familiarity with the foundations established in preceding chapters:

Section	Core architectural question	Starting page
Compute	Where does application code execute, and how do compute abstractions balance control against automation?	Virtual machines
Data and messaging	How is durable state stored and accessed, and how do distributed services communicate asynchronously?	Storage
Network and identity	How are software-defined boundaries established, and how are machine and human permissions enforced?	Networking
Operations	How do systems survive the loss of individual components, physical data centers, or entire geographic regions?	High availability

Page	Key topic addressed
Virtual machines	Sizing, lifecycle, persistent block attachments, immutable images, and scaling pools.
Containers and Kubernetes	Process isolation, image registries, declarative orchestration, and cluster resource scheduling.
Serverless	Event-driven function execution, cold start mechanics, concurrency limits, and managed container runtimes.
Storage	Object buckets, network-attached block volumes, shared network filesystems, and lifecycle tiering.
SQL databases	Automated patching, point-in-time recovery, multi-zone failover, and connection pooling.
NoSQL databases	Horizontal partitioning, partition key selection, hot partitions, and eventual consistency models.
Messaging and streaming	Point-to-point worker queues, pub/sub topics, append-only event logs, and dead-letter queues.
Networking	Virtual private clouds, CIDR planning, public versus private subnets, and security groups.
Identity, access, and secrets	Human and service identities, least privilege policies, workload federation, and secrets managers.
High availability	Failure domains, multi-zone active-passive setups, multi-region replication, and recovery objectives.

Each page concludes with a glossary of introduced terms. The complete glossary references every term back to the page where it was first introduced, and the quiz bank provides interactive checkpoints to validate your understanding of the concepts.

Terms introduced

• Shared responsibility model: the split between what the provider secures and what you secure.
• Region: a geographic area with its own set of data centres, chosen for latency and law.
• Availability zone: an isolated data centre or group of them inside a region, the unit of everyday resilience.
• Egress: data leaving the provider's network or a region, billed per gigabyte.
• Infrastructure as code: describing cloud resources in versioned files and letting a tool make the provider match them.

---

How providers do it

While AWS, Microsoft Azure, and Google Cloud share the same foundational systems architecture, they organize resource hierarchies, regional boundaries, and administrative tooling differently. Understanding these structural distinctions is essential when migrating workloads or operating multi-cloud estates.

Concept	AWS	Azure	Google Cloud
Isolation and billing boundary	Account, organized under AWS Organizations	Subscription, grouped under Management Groups	Project, organized within Folders and an Organization
Region	Region	Region, historically coupled in regional pairs	Region
Availability zone	Availability zone (e.g. us-east-1a)	Availability zone (numbered 1–3; available in designated regions)	Zone (e.g. europe-west2-b)
Broader geographic scope	Regional or Global services	Regional or Global services	Dual-region, Multi-region, and Global resources
Infrastructure as code	CloudFormation, AWS CDK, Terraform	Bicep, ARM templates, Terraform	Terraform, Google Cloud Infrastructure Manager
Command-line interface	aws CLI	az CLI	gcloud CLI

Every provider name and mapping above is confirmed against official documentation. The provider tabs below provide in-depth configuration details and specific operational notes, including metered egress pricing.

Two key structural differences stand out across the platforms:

1. Azure Resource Groups: Azure introduces an explicit grouping container between subscriptions and resources. A resource group manages the collective lifecycle of related services; deleting a resource group automatically deprovisions every resource contained within it.
2. Google Cloud API Activation: Unlike AWS and Azure where services are generally accessible once IAM permissions are granted, Google Cloud requires individual service APIs to be explicitly enabled per project before resources can be provisioned.

AWS

What this maps to: AWS is the oldest and largest of the three. Most of the vocabulary on these pages was set by it, so where another provider uses a different word, the core page usually sticks with the AWS one.

Concept	On AWS	Status
Region and availability zone	The same words. A region has several AZs, named like us-east-1a. The letter-to-zone mapping differs per account	confirmed
Unit of isolation and billing	An account. Accounts sit under AWS Organizations, which rolls up billing and pushes policies down	confirmed
Shared responsibility model	Published by AWS under that name	confirmed
Infrastructure as code	CloudFormation (YAML or JSON templates) and the CDK, which generates CloudFormation from code. Terraform is widely used and fully supported	confirmed
Console, CLI, API	The console, the aws CLI, and SDKs all call the same APIs	confirmed
Egress	Inbound traffic is free. Outbound to the internet and between regions is charged per GB, with a small free allowance per month	unconfirmed; check current pricing

Their vocabulary

Standard term	Their term
Account or project	Account
Organisation	Organization
Managed service	Usually the service name with no qualifier, e.g. "RDS" rather than "managed RDS"

Where to look

The AWS Well-Architected Framework is the provider's own guide to the rungs, resilience, and cost trade-offs on this page. Billing and Cost Management shows spend by service and region.

Last verified: never.

Azure

What this maps to: Azure organises resources in a hierarchy with one more level than the others. Where a Microsoft on-premises product exists, the Azure service is usually named after it, so if you know Windows Server and Active Directory you will recognise much of the vocabulary.

Concept	On Azure	Status
Region and availability zone	Region and availability zone. Zones are numbered 1 to 3 in the regions that have them, which is not all of them. Regions come in pairs for disaster recovery	confirmed
Unit of isolation and billing	A subscription. Subscriptions sit under management groups. Every resource lives in a resource group inside a subscription	confirmed
Shared responsibility model	Published by Microsoft under that name	confirmed
Infrastructure as code	ARM templates (JSON) and Bicep, a language that compiles to them. Terraform with the AzureRM provider is common	confirmed
Console, CLI, API	The Azure portal, the az CLI, Azure PowerShell, and SDKs all call the Azure Resource Manager API	confirmed
Egress	Inbound is free. Outbound to the internet and between regions is charged per GB	unconfirmed; check current pricing

Their vocabulary

Standard term	Their term
Account	Subscription
Organisation	Tenant, which is the Microsoft Entra directory, with management groups beneath
Group of related resources	Resource group, which has a lifecycle: delete it and everything inside goes

Where to look

The Azure Well-Architected Framework is the provider's guide to the trade-offs on this page. Cost Management shows spend by subscription, resource group, and service.

Last verified: never.

Google Cloud

What this maps to: Google Cloud organises everything around the project. Several of its networking and storage products are also global where AWS and Azure sell them per region. Most of what looks odd on the pages that follow comes back to one of those two differences.

Concept	On Google Cloud	Status
Region and availability zone	Region and zone, named like europe-west2-b. Some products are also sold as multi-region or global	confirmed
Unit of isolation and billing	A project. Projects sit in folders under one organization. Each project has a billing account attached to it	confirmed
Shared responsibility model	Published as the shared responsibility and "shared fate" model	confirmed
Infrastructure as code	Infrastructure Manager, which runs Terraform for you. Terraform with the Google provider is the common choice. Deployment Manager is the older tool	unconfirmed; check Deployment Manager's current status
Console, CLI, API	The console, the gcloud CLI, and client libraries all call the same APIs. Every API must be enabled per project before use	confirmed
Egress	Inbound is free. Outbound to the internet and between regions is charged per GB; the Standard and Premium network tiers price it differently	unconfirmed; check current pricing

Their vocabulary

Standard term	Their term
Account	Project
Availability zone	Zone
Organisation	Organization, with folders beneath it

Where to look

The Google Cloud Architecture Framework is the provider's guide to the trade-offs on this page. Billing reports show spend by project and SKU.

Last verified: never.

---

Check your understanding

0 of 4 answered

1. You run a managed database. Whose job is it to decide which identities can read the data?

   Yours. Data and access rules stay your responsibility on every rung.The provider's, because the database is managed.Shared, with the provider deciding defaults and you approving exceptions.Nobody's until the database is exposed to the internet.
2. What does putting a database's second copy in another availability zone protect against?

   The loss of one data centre, from a fire, flood, or power failure.The loss of a whole region.A bad deployment corrupting the data.Latency for users in another country.
3. A team of three engineers must run a new HTTP service. Which rung should they start on, and why?

   As high as the workload allows, because their scarce resource is people rather than compute.Virtual machines, because they are the cheapest per unit.Virtual machines, because the higher rungs hide too much.Whatever the other teams use, to keep the bill on one line.
4. A design copies a large dataset from one region to another every night. Which line on the bill grows because of it?

   Egress, because data leaving a region is charged per gigabyte.Compute, because the copy runs on a machine.Nothing, because traffic between a provider's own regions is free.Storage, because the data now exists twice.