Title: Lecture 10 — Providers, Free Tiers, and the Guardrails That Keep Them Free
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 10 — Cloud Foundations for AI: Providers, IAM & Cost Guardrails

📖 Lecture — Providers, Free Tiers, and the Guardrails That Keep Them Free

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.

The Big Three, and why market share isn't the whole story

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 tier is not one thing — it's three things

"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.

Regions, Availability Zones, and reading the free-tier fine print

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.

Least privilege: the rule that runs everything

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.

Budgets: notifications are not enforcement

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.

Correcting this week's misconceptions

- "750 free EC2 hours means 750 hours per instance." False — it's a shared, account-wide monthly pool across all running instances, and NAT Gateway hours, excess egress, and extra CloudWatch storage are excluded from free tier regardless.
- "Multi-AZ and multi-region give the same protection, so pick whichever is cheaper." False — Multi-AZ protects against a single data-center failure at modest cost; multi-region protects against a whole-region outage but costs and complicates far more. Default to Multi-AZ.
- "It's fine to use my root account's access keys for day-to-day work." No — create an IAM administrative user for daily work and lock root credentials behind MFA, used only for the rare tasks that require root.
- "Budget alerts will stop my spending automatically." No — without a separately configured Budget Action, billed resources keep running right past every threshold.

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.