What AWS actually is

AWS is a utility, not a product

The clearest way to understand AWS is by analogy to the electrical grid. You do not run a generator in your basement; you draw power from a shared utility, pay for what you consume, and the utility handles generation, distribution, and reliability. AWS — Amazon Web Services, launched in 2006 — is that utility for computing. Instead of buying servers, racking them in a data center, wiring networking, and replacing failed disks at 3 a.m., you rent those capabilities over an API and pay only for what you use.

That phrase “over an API” is the whole shift. Every resource in AWS — a virtual server, a terabyte of storage, a database, a DNS record, a firewall rule — is created, changed, and destroyed by a programmatic call. The web console you click through is just a front end over the same API the SDKs and Terraform use. This is why infrastructure becomes code, why a script can stand up an entire environment in minutes, and why the same elasticity that saved the startup in the hook can, run carelessly, spin up a thousand instances and a five-figure bill just as fast.

AWS today is not one service but over 200 of them, available on-demand with pay-as-you-go pricing, running in 190+ countries. Nobody learns all 200. The skill is not memorizing services — it is knowing the categories, so that when you have a problem you know which shelf to look on.

The mental model: service categories

Treat AWS as a hardware store organized by aisle. You do not need to know every product; you need to know what each aisle is for. Six categories cover the vast majority of what a working application uses:

A typical web app touches one service from most of these aisles: code on EC2 or Lambda, files in S3, data in RDS, traffic via a VPC behind an ELB with Route 53 out front, access governed by IAM, and the whole thing watched by CloudWatch. Learn the aisles first; the specific product names attach themselves naturally once you know what problem they solve.

Managed vs self-managed: the axis that defines AWS

The single most important distinction in the whole platform is how much of the operational work AWS does for you. The same capability — say, a Postgres database — is available at several points along a spectrum, and the choice is a real tradeoff, not a default.

At the self-managed end, you run EC2 (a raw virtual machine), install Postgres yourself, and own everything above the hypervisor: OS patches, Postgres upgrades, backups, replication, failover, monitoring. You get total control and the lowest per-hour price, and you inherit all the 3 a.m. pages. At the managed end, you use RDS: AWS runs the database engine, applies patches, takes automated backups, and can fail over to a standby in another Availability Zone automatically. You pay more per hour and give up some knobs, but you stop owning the operational toil. Further still are serverless services like Lambda and DynamoDB, where there is no instance to size at all — you are billed per request and per millisecond, and capacity is the provider’s problem entirely.

This managed-vs-self-managed axis is the lens for almost every AWS decision. “Should we use RDS or run Postgres on EC2?” is really “is the operational work worth the premium for this workload?” For most teams, most of the time, the answer is to buy the managed version and spend the saved hours on the product — but it is a decision, and senior engineers make it deliberately.

Global infrastructure, in one paragraph

AWS runs in physical locations called Regions (39+ of them worldwide, e.g. us-east-1, eu-west-1), each an independent geographic area. Inside every Region are multiple Availability Zones (AZs) — 120+ in total — which are physically separated groups of data centers with independent power and cooling but joined by low-latency links, so spreading your app across AZs survives a single data center failure. Out at the edge are hundreds of edge locations (CloudFront points of presence) that cache content close to users for low latency. You will deepen all of this in the next lesson; for now, hold the hierarchy Region → Availability Zone → edge, and the rule that high availability on AWS means running across at least two AZs.

Why teams choose AWS — and what it costs

Teams pick AWS for two reasons above all. Breadth: 200+ services mean you can almost always assemble what you need without inventing it, from a queue to a managed Kubernetes cluster to a machine-learning endpoint. Elasticity: you scale up in seconds for a traffic spike and scale down when it passes, paying only for what you used — exactly the property that saved the startup in the hook. Add the maturity of the platform and a deep hiring pool, and AWS is the safe institutional default.

The downsides are equally real and worth naming as a senior engineer would. Cost complexity: pay-per-use is a double-edged sword — pricing spans compute hours, storage GB-months, request counts, and data transfer out (egress), which surprises teams more than anything else; an idle-but-forgotten resource or a chatty cross-region call can quietly bleed money. Lock-in: the more you lean on proprietary managed services (DynamoDB, Lambda, SQS), the harder and costlier it is to leave — the convenience and the lock-in are the same feature. Operational surface: AWS hands you enormous power and an enormous number of ways to misconfigure it; IAM alone is a deep discipline, and a single over-permissive policy or public bucket is a breach. None of these are reasons not to use AWS; they are the things you manage deliberately because you chose to use it.