In Weeks 1–9 you learned to build and run containers, then orchestrate them on Kubernetes on your own machine. This week we move that same mental model — compute, storage, networking — onto infrastructure you don't own. That shift raises three questions every new cloud user has to answer: which provider, what does "free" actually mean, and how do I make sure nothing runs away with my wallet? Get these wrong and you either overpay on day one or get an unexpected bill for something you thought was free. Get them right and you can build, test, and even train small models without spending a dollar — and without losing sleep over it.
As of Q1 2026, AWS holds roughly 28% market share (≈19% YoY growth), Microsoft Azure ≈21% (40–63% YoY growth), and Google Cloud ≈14% (40–63% YoY growth). AWS is still the largest provider and operates the most mature ecosystem of services — which matters when you need a specific managed database, queueing system, or ML tool. But Azure and GCP are growing two to three times faster, often on the strength of enterprise Microsoft relationships (Azure) or data/ML tooling (GCP). Market share is a weak signal on its own. Better questions: Does the provider have the GPU instance types I need, in a region close to my users or data? Does it meet any compliance requirements my project has? What's the total cost, including the free tier, for my first three months of experimentation?
"Free" on a cloud provider's website usually means one of three distinct offers: signup credits (a lump sum, e.g. AWS's \$200/6-month or GCP's \$300 trial credit, that burns down as you use any paid service and then stops); an always-free tier (a capped quantity of specific resources, e.g. GCP's e2-micro VM and 30GB disk, free indefinitely as long as you stay under the cap); and time-limited trials (a resource free for a fixed window regardless of credit balance, e.g. legacy AWS accounts' 750 EC2 hours/month for 12 months). Knowing which layer you're looking at changes your risk calculus: a signup credit disappearing mid-project can surprise you with a bill; an always-free resource generally can't; a trial has a hard expiration date you should calendar.
A region is a geographic area (e.g. us-east-1) containing multiple physically separate data center clusters, or Availability Zones (AZs) — AWS alone runs 37 regions and 100+ AZs. Each AZ has independent power, cooling, and networking, so a failure in one AZ shouldn't take down another. This is why AZs, not regions, are the unit of fault tolerance: "Multi-AZ" places redundant copies within one region at modest added cost and latency; "multi-region" spans separate geographic regions and protects against a whole-region outage, but adds real complexity (replication lag, cross-region latency, roughly double the cost). Default to Multi-AZ unless you have a specific reason for multi-region. Free-tier limits are also commonly misread as per-instance when they're actually account-wide: AWS's 750 free EC2 hours/month are shared across all running instances combined, and adjacent resources — NAT Gateway hours, egress beyond the free allowance, extra CloudWatch storage — are excluded from free tier entirely. Before you provision anything beyond always-free, sanity-check cost with the AWS Pricing Calculator or instances.vantage.sh to compare instance pricing across regions.
Once you're inside a provider, the next question is who can do what. The principle of least privilege means every identity — human or workload — gets only the permissions it needs, and nothing more. In AWS IAM this means: human users sign in through an IAM administrative user (not root) for daily work; workloads (an EC2 instance, a Lambda function, a CI/CD pipeline) assume an IAM role for temporary, auto-expiring credentials rather than a long-lived access key baked into code; and every policy is scoped to specific resources and actions — "read-only access to this one bucket," not "full S3 access." As organizations grow past one account, they add multi-account guardrails (e.g. AWS Control Tower) that use preventive controls (Service Control Policies that block an action outright) and detective controls (config rules that flag violations after the fact) to isolate blast radius between Production and Staging. That deeper account- and network-isolation architecture — along with secrets management — is covered in depth in AIINFRA 302; for now, the IAM habit that matters is scoping every policy tightly.
This is the single most important — and most misunderstood — idea this week. AWS Budgets lets you set a monthly cost threshold and get alerts at layered percentages (e.g. 80% of actual spend, 100% of forecasted spend). These alerts are useful, but by themselves they are only notifications — nothing stops running, nothing gets shut down. To actually enforce a budget you need Budget Actions: automated responses such as attaching an SCP that denies further resource creation, or invoking a Lambda that stops instances. Budget Actions are the airbag; alerts are just the dashboard warning light. Making this harder, billing data is delayed — Cost Explorer doesn't update in real time, so an alert can fire after the charges already happened. The fix is to layer proactive controls before you need an alert to save you: tight IAM policies that simply don't allow expensive actions, service quotas, and Budget Actions — combined with, not replacing, notifications.
Get comfortable with this mindset now, while the stakes are a few dollars of free-tier credit. It's the exact same mindset that protects real production budgets later.