I’m starting a video series: AWS for Python Developers. This post is the written companion to Episode 01 — if you’d rather watch, the video is embedded below and covers the same ground, ending with a live account setup.
The 60-second mental model
Strip away the marketing and AWS is this: someone else’s data centers, rented by the second.
Servers, storage, databases, message queues, DNS, networking — every building block your backend needs, exposed as an API instead of hardware you own. You don’t file a ticket with an infrastructure team and wait three weeks for a server. You make an API call and have one in ninety seconds.
My working definition as a developer is even simpler: if I can call it from boto3, it’s a service. That’s the lens this whole series uses.
Why did AWS win?
AWS launched in 2006, years before anyone else took public cloud seriously, and that head start compounded. Today it holds roughly 30% of global cloud infrastructure spend — the largest share of any provider — and runs at around a $150B annualized revenue pace. But market share is the result. The causes are more interesting, and there are four of them.
Pay as you go. No servers to buy, no contracts to sign. A student with a free-tier account and an enterprise running thousands of instances use the exact same console and the exact same APIs. You pay for seconds of compute and gigabytes of storage, which means the cost of experimenting rounds to zero. That single property is why an entire generation of startups defaulted to it.
Everything lives in one account. Compute, queues, databases, ML, DNS — over 200 services under one bill, one IAM, one SDK. The services are designed to compose: S3 can notify SQS, SQS can trigger Lambda, Lambda can write to DynamoDB. When your architecture grows a new requirement, the answer is usually already inside the account you have.
Mature docs and SDKs. Two decades of documentation and battle-tested SDKs in every mainstream language. For Python that’s boto3, and its maturity is something you feel daily: whatever error you hit, someone hit it in 2014 and wrote about it. Compare that to being an early adopter of anything, where every error message is a research project.
It’s where the jobs are. This is the unromantic one, and for many of us the most practical. The biggest cloud means the most companies building on it, which means AWS is the cloud most likely to appear in your next job description. If you’re a backend engineer, AWS familiarity has quietly become table stakes — I say this as someone whose stack was Python and GCP for years and who felt the gap in interviews.
What this series is (and isn’t)
It’s not certification cram, and it’s not console click-tours.
Every topic is chosen with one filter: will you call this service from application code? We learn AWS the way a backend engineer actually meets it — through the SDK, in Python, with real errors and real IAM policies. The roadmap follows the services boto3 supports and backend teams genuinely use:
- IAM — users, roles, policies, least privilege
- S3 — objects, presigned URLs, direct browser uploads
- SQS + SNS — queues, fan-out, dead-letter queues
- DynamoDB — NoSQL from a developer’s seat
- Lambda — running code without servers
- …and onward through API Gateway, EventBridge, and friends
Every episode ships with a written tutorial here on the blog, so you can copy the commands and code instead of pausing a video to squint at my terminal.
The day-one mistake almost everyone makes
Here’s where Episode 01 gets practical. When you create an AWS account, the email and password you sign up with become the root user — and the single most important habit you can build is to stop using it, immediately.
Root has unrestricted power. It can close the account, change billing, and delete everything, and no IAM policy can limit it. If those credentials leak, there is no smaller blast radius. Yet most beginners use root as their daily login for months, because nothing in the signup flow tells them not to.
The professional pattern — the one every real company enforces — takes about ten minutes to set up: root gets MFA and goes in a drawer, an IAM admin user becomes your daily driver, and billing budgets stand guard so you never get one of those famous surprise-bill horror stories.
I’ve written the exact sequence up as a step-by-step tutorial: Set up a new AWS account the right way: IAM admin user, MFA, and billing budgets. It’s the same setup I run on my own practice account, and it’s what Episode 02 (IAM for developers) builds on.
If you’re starting your AWS journey alongside this series — welcome. Create the account, secure it properly, and meet me in Episode 02, where we make our first boto3 call.