Cloud Foundations

Think of a commercial kitchen you rent by the hour, not a kitchen you build. You source it yourself through an app at 2 a.m. with no phone call (on-demand self-service). You can get to it from anywhere on any device (broad network access). Other chefs use the same building and equipment, and neither of you knows or cares which oven you were given (resource pooling). Friday night you take six stations, Tuesday you take one (rapid elasticity). And the bill is metered to the minute and itemised (measured service).

If a service is missing any one of these, it isn't cloud — it's hosting with a nice website. That's a genuinely useful test when a vendor calls something "cloud".

Each characteristic is implemented by a specific piece of machinery, and knowing which one helps you predict how a cloud behaves under stress:

• Elasticity has a floor and a ceiling. The floor is cold-start time; the ceiling is your quota, which starts near zero for scarce hardware. On every cloud, GPU quota is zero by default and must be requested. Plan for the request to take days, not minutes.
• Pooling means correlated failure. Your three "independent" instances can land on hardware that shares a power feed unless you explicitly spread them across fault domains. This is the entire reason zones exist.
• Measured service cuts both ways. Per-second billing is wonderful for bursty batch work and terrible for anything you forget to turn off. The classic beginner bill is not a runaway autoscaler — it's one idle GPU instance left running over a long weekend.
• Self-service without guardrails is a governance hole. The same API that lets a team ship in an afternoon lets them open a public bucket in an afternoon. This is why the hierarchy sessions (S2–S4) spend so much time on preventive policy.

Public cloud is the rented commercial kitchen: the provider owns everything, you share it with strangers, you pay per use. Private cloud is your own kitchen built to the same self-service, metered, API-driven standard — the cloud operating model without the shared building. Hybrid is running both and treating them as one system, usually because some ingredient is legally not allowed to leave your premises.

A fourth term you'll hear constantly: multicloud means using more than one public cloud provider. It is not a deployment model in the NIST sense — it's a procurement and architecture strategy — but Brown's source is right that "the cloud" was always plural.

What actually differs is who bears the capital cost and who holds the keys:

Brown's source has a genuinely good framing for hybrid that's worth stealing: an old mainframe or core-banking system of record (SoR) that can't be rewritten, fronted by a new cloud-hosted system of engagement (SoE) that handles the millions of concurrent web and mobile users and holds a small pool of connections back to the SoR. The cloud part scales; the legacy part doesn't have to.

The honest version of the multicloud debate: portability is a real cost you pay up-front for an option you may never exercise. If you abstract over three clouds' object storage, you get the intersection of S3, Blob Storage and Cloud Storage — which means no S3 Express One Zone, no Azure immutable-blob legal hold, no Cloud Storage Autoclass. The mature position is portable architecture, not portable code: keep your data formats open, keep your compute in containers, keep your IaC in a tool that speaks all three — and then use each cloud's best services without apology. Your own stack already does this well: a vLLM container is portable in the way that matters, even though the thing that schedules it is not.

For GPU work specifically, multicloud is often forced rather than chosen: capacity for a given accelerator is scarce and regional, so "which cloud" frequently reduces to "who has H200s in a region I'm allowed to use, this quarter".

Pizza, the canonical version, because it's canonical for a reason. IaaS is buying flour, yeast and an oven: maximum control, maximum work. PaaS is buying a par-baked base and adding toppings: the provider handles the hard, boring, repeatable part. SaaS is ordering delivery: you make zero decisions except what to order and who gets a slice.

The thing the pizza analogy hides, and the thing that actually matters: at every step you gave away control and gained back responsibility-someone-else-carries. Those are the same transaction viewed from two sides.

This is the visual to burn in. The stack below is the same for all three clouds. The dashed line is the shared-responsibility boundary. Click a service model to watch it move.

The non-obvious one is the cold-start row for GPU FaaS. Scale-to-zero is the headline benefit of serverless, and it's the benefit that a 14 GB model checkpoint destroys: you can't amortise a 90-second weight load over a 200 ms request. This is precisely the problem platforms like Modal solve with snapshotting and warm pools, and it's why "just make it serverless" is bad advice for inference until you've measured the load profile.

A well-architected framework is a checklist of the questions a senior architect would ask you in a design review — written down so you can ask them of yourself before the review. Nothing more mystical than that. All three vendors publish one, all three converge on roughly the same five questions, and the differences between them are smaller than the similarities.

The five shared pillars, in vendor-neutral phrasing:

On top of the pillars, vendors publish lenses (AWS) or perspectives (Google): the same pillars re-asked for a specific domain. Directly relevant to you: AWS shipped a Generative AI Lens in April 2025 and added a Responsible AI Lens plus updated ML and Generative AI lenses at re:Invent 2025; Google's WAF carries an AI & ML perspective; Microsoft publishes AI workload guidance under its five pillars.

AWS Generative AI Lens Three AI lenses, re:Invent 2025 Azure WAF: AI workloads Google Cloud WAF

The pillars conflict on purpose. Reliability wants three zones; cost optimisation wants one. Security wants a private endpoint and a bastion; operational excellence wants a developer to debug at 3 a.m. without a VPN ticket. A well-architected review isn't a scorecard where you maximise all six — it's a forcing function to make the trade-off explicit and recorded. The output of a good review is not "we scored 92%", it's "we accepted a 4-hour RTO for the reporting service to save $3.1k/month, signed off by the product owner on this date."

That's also the honest answer to why Azure has five pillars and the others six. Microsoft's position is that sustainability is a cross-cutting concern rather than a peer of reliability. Google took the opposite view in January 2026 and promoted it. Neither is wrong; they're editorial choices about a checklist.

A region is a city. An AZ is a building in that city, far enough from the next building that the same flood or substation failure won't take both, close enough that you can walk between them in the time it takes to say a sentence. An edge location is a parcel locker in a neighbourhood somewhere else entirely: it doesn't manufacture anything, it just holds copies so people nearby get them fast.

Deploying into one AZ is renting one building. Deploying across three is renting in three buildings and accepting that one may burn down. Deploying into two regions is opening in two cities, which is a different and much larger commitment.

Click any element to see what it means for a design decision.

• AZ letters are per-account aliases. Your us-east-1a and my us-east-1a are probably different physical zones — AWS randomises the mapping so customers don't all pile into "a". If you need to coordinate placement across accounts (shared VPC subnets, cross-account clusters), use the stable AZ ID (use1-az4), not the name. This catches people constantly.
• Not every service exists in every region. AWS publishes a list of core services present at every region launch, with a second tier that typically arrives within 12 months. New and specialised services — including much of the AI portfolio — land in us-east-1 first and diffuse outward. "Is it in my region?" is a real design constraint, not a footnote.
• Cross-AZ traffic is billed, in both directions. Roughly $0.01/GB each way. A chatty microservice mesh spread across three AZs for resilience can generate a surprising data-transfer line item. This is a genuine reliability-vs-cost pillar conflict, and the right answer is workload-specific.
• Multi-AZ ≠ multi-region. Multi-AZ buys you high availability within one region and is often nearly free architecturally. Multi-region buys you disaster recovery and regional-outage survival, and costs you data replication, config drift, a global traffic policy, and roughly double the operational surface. The material's caution list flags this exact confusion, and it's a favourite exam trap.
• Latency is physics plus routing. Distance sets the floor; congestion, hop count and endpoint processing add the rest. Measure before you assume — CloudPing-style tools and CloudWatch/X-Ray traces are how you find out, rather than reasoning from a map.
• Compliance is regional, and specialised. GovCloud regions are a separate partition, FedRAMP- authorised and isolated from commercial regions, and the European Sovereign Cloud opened on its own partition in January 2026. HIPAA-eligible services and BAAs, GDPR data-residency, ISO and SOC coverage all vary by region. Choose the region against the regulation first, then optimise latency inside what's left.

Other clouds treat their top-level container as something you create rarely and carefully. AWS treats accounts like disposable rooms with concrete walls. Making a new one is free and takes minutes. The expected pattern in a serious AWS estate is dozens or hundreds of them: one per workload per environment, plus dedicated accounts for logging, security tooling, shared networking and sandbox.

Why so many walls? Because AWS's isolation between accounts is far stronger than its isolation inside one. Inside an account, separation depends on IAM policies being written correctly. Between accounts, separation is the default and access is the exception. Given a choice between "trust that every policy is right" and "make the mistake impossible", the second is the better bet.

The policy types, precisely

This is the part that changed most recently, and the part the material predates.

AWS Organizations — authorization policies AWS Cloud Operations Blog — enterprise-wide preventive controls

Global vs regional vs zonal — a service-scope cheat sheet

Getting this wrong is how people accidentally build a single point of failure inside an otherwise multi-AZ design.

The material is exam scaffolding, and it's accurate: the AWS Certified Solutions Architect – Professional exam (code SAP-C02) is 75 questions in 180 minutes, $300, scored 100–1000 with a 750 pass mark, compensatory scoring across four domains — Design Solutions for Organizational Complexity (26%), Design for New Solutions (29%), Continuous Improvement for Existing Solutions (25%), Accelerate Workload Migration and Modernization (20%). Verified current as of 2026.

The detail worth extracting: Domain 1 is a quarter of the exam and it is entirely about the hierarchy axis. Multi-account strategy, cross-account access, network topology across accounts, centralised logging, policy inheritance. AWS's own view of what separates a professional-level architect from an associate-level one is precisely the material the material defers to §3 — which is why we're covering it here in session 2 rather than waiting.

AWS certification page

EC2's accelerated families, from "you can probably get one today" to "call your account team":

P6e-GB300 GA announcement, Dec 2025 AWS PCS adds UltraServer support, Jun 2026

The placement rule that matters. GPU capacity is not evenly spread. A given accelerator exists in a handful of regions and often only some AZs within them, which means your region choice for a training run is frequently made for you by capacity — and then your data-residency and latency requirements have to fit around it, rather than the other way round. For tightly-coupled multi-node training you also need the instances physically close, which is what EC2 UltraClusters and cluster placement groups exist to guarantee.

A corporate campus. The tenant is the company itself — the entity that issues ID badges. The management groups are divisions, nested as deeply as your org chart deserves. A subscription is a building with its own utility meter and its own capacity limits. A resource group is a floor of that building, rented to one project, where everything on the floor gets renovated and vacated together. The resources are the furniture.

The badge system (Entra ID) is campus-wide. The meters (subscriptions) are per building. The lease terms (RBAC and Policy) can be set at any level and flow downward.

Click any layer to see what it actually controls — and, importantly, what it doesn't.

Two governance systems, not one

This is the Azure concept that most often gets muddled, and the distinction is clean once you see it:

Both attach at any level of the hierarchy and inherit down. An Owner role assignment at a management group makes you Owner of every subscription beneath it — which is why Microsoft's guidance is unusually stern about the root management group: nobody has access by default, only Entra Global Admins can elevate themselves into it, and assignments there should be strictly "must have".

Bicep — the readable face of ARM

Here the configuration is the mechanism, so a short snippet earns its place. This is the shape of every Bicep resource declaration:

resource stg 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: uniqueStorageName          // the real name in Azure
  location: location
  sku: { name: storageSKU }
  kind: 'StorageV2'
  properties: { supportsHttpsTrafficOnly: true }
}

Two things to read off it. (1) stg is a symbolic name used only inside the template; name: is the actual resource name in Azure. The material flags this confusion explicitly and it's worth heeding. (2) The type string Microsoft.Storage/storageAccounts@2023-05-01 is provider/type@API-version — pinning the API version is what makes the template reproducible over time.

• The resource group's location is metadata only. Genuinely counter-intuitive. You pick a region when creating an RG, and that region stores the group's metadata — not its contents. Resources inside can be anywhere. Practical consequence: if that metadata region has a regional outage you may be unable to manage resources that are themselves running perfectly elsewhere. Keeping the RG in the same region as its resources is the usual advice, when compliance allows.
• 980 resource groups per subscription. Sounds enormous until you're vending one RG per microservice per environment via a pipeline. Worth knowing before you design the automation.
• Management groups: 6 levels deep, 10,000 per directory, one parent each. The CAF reference architecture uses about three levels, and going deeper than four is usually a sign the tree is modelling the org chart rather than the governance requirements.
• Quotas are per-subscription and per-region. A GPU core quota granted in West Europe does nothing for you in Sweden Central. Every region you expand into needs its own quota request. This is the single most common Azure surprise for ML teams.
• Not every Azure region has availability zones. Around 35 of the 70+ regions advertise AZ support. A region without zones can still be paired with another for geo-redundancy, but you cannot build zone-redundant HA there. Check before you promise an SLA.
• Paired regions are not universal any more. Azure historically paired every region for geo-replication and staged updates. Newer regions may be non-paired, relying on availability zones plus your own cross-region design instead. Don't assume a pair exists — look it up.
• Moving resources between subscriptions or resource groups is possible but uneven. Some resource types move cleanly, some can't move at all, and some move but break their dependencies. Design the placement correctly the first time; treat moves as a migration project, not an afternoon.

Limits verified July 2026: management group limits Azure regions and zones

Azure's geography is the one piece of vocabulary here with no clean equivalent elsewhere, and it's the one a compliance officer will care about. Think of it as the country or bloc — "Europe", "United States", "India" — inside which Microsoft commits to keeping your data. Regions are cities inside that country. Zones are buildings inside the city.

The practical effect: on AWS you answer "where does the data live?" by naming regions and hoping nobody asks what binds them together. On Azure you answer with a single word, because Microsoft named the layer. That's a small thing that makes conversations with auditors substantially shorter.

Azure adds one layer above the region that the others don't name as clearly:

Zonal vs zone-redundant is the Azure vocabulary worth memorising. A zonal resource is pinned to one zone you chose — if that zone fails, it fails, and redundancy is your job. A zone-redundant resource is spread across zones by the platform, which handles failover for you. Whether a given SKU supports zone-redundancy varies by service and by region, and it's the first thing to check when someone asks for a availability guarantee.

The ND and NC families

Microsoft Learn — ND GB300 v6 series

Those rack-scale numbers are not something you'll provision from a portal, but they're the right units to think in when comparing vendors' training capacity — tokens/second per rack is a more honest comparison than FLOPS.

• The zone-coverage gap is the big one. Roughly half of Azure's 70+ regions don't advertise availability zones. If a compliance requirement pins you to a geography whose only region is single-zone, zone-redundant HA is simply unavailable and your resilience story has to bebefore you commit to an SLA, not after.
• Zone-redundancy is a per-SKU property, not a per-service one. A service may support it on its premium tier and not its standard tier, and support can differ by region within one tier. "Does Azure SQL support zones?" is the wrong question; "does this tier, in this region?" is the right one.
• Paired regions are a fading guarantee. Azure historically paired every region for staged platform updates and geo-replication. Newer regions increasingly ship non-paired, on the reasoning that availability zones plus explicit customer-designed replication is the better model. Don't assume a pair exists because one always used to.
• Region names understate and overstate distance. eastus and eastus2 are both in Virginia; westus is California and westus2 is Washington state. Deploying to "east" and "west" gives you real separation; deploying to eastus and eastus2 gives you considerably less than the names suggest.
• GPU capacity concentrates in a handful of regions. The ND-series doesn't exist everywhere, and within a supported region it can be constrained. As on AWS, capacity frequently decides your region, and your latency and residency requirements then have to fit inside what's left.

A university. The organisation is the university itself. Folders are faculties and departments, nested however the institution is actually shaped. A project is a single research project: it has its own budget code, its own key-card list, its own lab space, and it ends. The resources are the equipment in the lab.

The billing account is the finance office. It isn't inside the biology department — it's a separate entity that departments charge to. Two projects in completely different faculties can both charge the same grant, and moving a project between departments doesn't change which grant funds it. That's exactly Google's model, and once you see it that way the "sideways" billing link stops being weird and starts being obviously correct.

Click any node to see what it controls and where the inheritance flows.

Project identifiers — three of them, and they aren't interchangeable

Two governance systems, again — but shaped differently from Azure's

Scope in practice — why the global VPC changes designs

The three-scope model isn't trivia; it's the thing that makes Google Cloud designs look structurally different from their AWS and Azure equivalents. Worth three passes, because it's the concept most likely to mislead someone arriving from another cloud.

The gcloud CLI, structurally

Google's CLI is the most consistently-shaped of the three, and worth learning as a grammar rather than a list of commands: gcloud <group> <subgroup> <verb> [args].

gcloud compute instances list           # group=compute, subgroup=instances, verb=list
gcloud projects describe MY_PROJECT_ID
gcloud resource-manager folders list --organization=ORG_ID
gcloud config set project MY_PROJECT_ID # sets the ambient project for later commands

The gcloud config ambient state is a real footgun: commands silently operate on whichever project is currently configured. In scripts, always pass --project explicitly rather than trusting the ambient value.

• Folder depth 10, 300 children per parent, one parent each. Deeper than Azure's 6 and AWS's 5. Almost nobody needs 10 — three or four levels is a healthy tree, and more usually means you're modelling the org chart instead of the governance requirements.
• A folder requires an organisation resource. On a personal free-trial account with no Cloud Identity domain, projects are the top of your hierarchy and folders are simply unavailable. GCP guidance's source notes this explicitly and it surprises people who follow enterprise tutorials on a personal account.
• Deleting a project is reversible for ~30 days. The project moves to a pending-deletion state and can be restored. Genuinely more forgiving than deleting an Azure resource group. Don't rely on it, but it has saved people.
• Quotas are per-project, and GPU quota starts at zero. Same story as the other two clouds. Because projects are cheap, the natural GCP pattern is a dedicated project per GPU workload with its own quota.
• Global resources are a shared blast radius. A global VPC's firewall rules apply everywhere in it. A bad rule is a global bad rule. Shared VPC — a host project owning the network, service projects attaching — is how you keep the convenience while putting a governance boundary around who can change it.
• P100 GPUs reach end of support on 15 September 2026 — after that you cannot create or access resources using them. Google's own recommendation is to migrate to T4 or L4. Checked I want to flag this explicitly because there is third-party content circulating claiming Google is retiring the T4 in 2026. That is wrong — the T4 is one of the recommended migration targets, and it's still listed as attachable to N1 instances in current documentation. Your T4-based Vertex AI work is not on a deprecation path.

Google Cloud — NVIDIA P100 end of support GPU machine types

AI zones — the 2026 addition that changes GPU placement

Compute Engine release notes list AI zones as generally available; access must be enabled per project. Google Cloud — About AI zones TPU regions and zones