AWS: Zero to Hero — Week 3: Who's Actually Responsible for Securing What
Week 3 of learning AWS from zero, with Claude as my research partner. Before touching a single service: the Shared Responsibility Model, why the security line between AWS and me actually slides depending on the service, IAM users/roles/policies explained, and why AWS now forces MFA on every root user account as of 2025.
Series: AWS: Zero to Hero (9 articles)
- …
- 3AWS: Zero to Hero — Week 3: Who's Actually Responsible for Securing What This article
Two weeks in, and I've deliberately avoided touching a single AWS service — Regions, AZs, and the Nitro System from last week are all still just infrastructure I don't personally manage. This week is the last stop before that changes, because there's one question worth answering properly first: once I do start creating things in AWS, who's actually on the hook if something goes wrong — AWS, or me?
The answer has a name: the Shared Responsibility Model. And once it clicks, it quietly explains a huge chunk of "why does AWS have a setting for that" questions before they even come up.
The Deep Dive
The split: "security of the cloud" vs. "security in the cloud"
AWS draws the line with one deliberately memorable phrase: AWS is responsible for the security of the cloud, and you're responsible for security in the cloud.
"Of the cloud" is everything we covered the last two weeks — the physical data centers, the Regions and AZs, the racks, the cooling, the power, and (this is where last week connects directly) the Nitro System handling hardware-level virtualization and isolation. All of that is entirely AWS's job. You never see it, patch it, or configure it, and you can't opt out of trusting it — it's the foundation everything else sits on.
"In the cloud" is everything you actually do on top of that foundation: how you configure the guest operating system on your EC2 instance, whether you patch it, how you write your IAM policies, whether your S3 bucket { Amazon S3 (Simple Storage Service) is a scalable, durable, and secure cloud object storage service provided by AWS that allows users to store and retrieve any amount of data from anywhere on the web. An S3 bucket is the fundamental container within this service, functioning as a top-level directory that holds objects (files and their metadata) } is accidentally public, how you encrypt your data, and how you configure your network's firewall rules (Security Groups). None of that is AWS's job — and this is the part that surprised me most: the majority of real-world cloud security incidents are customer-side misconfigurations, not AWS infrastructure failures. An S3 bucket left public isn't a failure of "security of the cloud" — it's a failure of "security in the cloud," and it's entirely preventable on the customer's side.
The split isn't fixed — it slides with how much AWS manages for you
Here's the detail that took the model from "a slogan" to "actually useful" for me: the line between the two responsibilities moves depending on which service you're using, because it tracks how much of the stack AWS is managing on your behalf.
- EC2 (you manage more) — AWS handles the physical hardware and the hypervisor. You're still responsible for patching the guest OS, managing your own security updates, and configuring your firewall rules.
- RDS (a managed service, AWS takes more) — AWS now also handles OS patching and database engine maintenance. You're still responsible for your actual data, who can access it, and your network configuration around it.
- Lambda (serverless, AWS takes the most) — AWS manages everything down to the runtime environment. Your responsibility narrows down to your own code and the IAM permissions you grant it.
Same underlying model, different boundary line — and it's a genuinely useful mental shortcut: the more "as-a-service" something is, the more of the security burden AWS has absorbed for you, and the more your own responsibility narrows to configuration, access, and your own code.
IAM: the toolkit for the "in the cloud" half
Identity and Access Management (IAM) is AWS's system for controlling exactly that — who (or what) can do what, to which resources. A few core pieces:
- Users — an identity with long-term credentials, generally meant for one specific human or application.
- Groups — a way to attach the same permissions to multiple users at once, instead of repeating yourself.
- Roles — an identity with temporary credentials, assumed by something trusted (an EC2 instance, a Lambda function, a federated human user) rather than logged into directly. Modern AWS guidance leans hard toward roles over long-lived user credentials wherever possible, precisely because temporary credentials are much less dangerous if they ever leak.
- Policies — JSON documents that actually define permissions: which action, on which resource, is allowed or denied, sometimes with conditions attached (a very common one: deny an action entirely unless MFA is present on the session).
Everything in IAM defaults to denied. Nothing is accessible until a policy explicitly allows it — which is the practical meaning behind "least privilege": grant exactly the access something needs, and nothing more, rather than starting broad and trying to lock things down later.
The root user: powerful enough that AWS now forces you to protect it
Every new AWS account starts with a single root user — and it's uniquely dangerous, because it has complete, unrestricted access to everything in the account (including billing) and, critically, cannot be restricted by IAM policies at all. You can't scope it down. It's meant to be used essentially once, to set the account up, and then locked away.
This isn't just a "best practice" anymore, either — it's worth knowing this changed recently, because it's exactly the kind of thing a beginner following an older tutorial might miss: as of June 2025, AWS enforces MFA on the root user for every account type (standalone, management, and member accounts), with new accounts required to register MFA within 35 days of first console sign-in. AWS also now specifically recommends phishing-resistant methods — FIDO2 passkeys or hardware security keys — over older app-based one-time-code MFA, for anything protecting a root account.
The practical rule that falls out of all of this, and the one I'm actually applying to my own account: sign in as root exactly once, enable MFA immediately, then create a separate IAM identity (a user or, better, a role) with the permissions actually needed for day-to-day work — and never touch the root login again unless there's genuinely no other option.
One more piece worth knowing: IAM Identity Center
If you're managing access for more than just yourself — a team, multiple AWS accounts — AWS now steers people toward IAM Identity Center (formerly called AWS SSO) rather than creating individual long-term IAM users for every person. It centralizes identity through a proper identity provider and hands out temporary, MFA-protected access to whichever accounts someone's actually supposed to touch — one login, centrally managed, instead of scattered credentials across every account. Not something I need solo right now, but worth knowing exists before I ever end up on a team AWS account.
A practical checklist for anyone opening their first account
Since I just went through this myself:
- Sign in as root, enable MFA immediately (passkey or hardware key if you have one).
- Never use root again for daily work — create an IAM user or role for that instead.
- Give that identity only the permissions it actually needs, not full admin, if you can help it.
- Set a strong account password policy.
- Turn on billing alerts before you start experimenting, so "I was just testing something" never turns into a surprise invoice.
My Take
This time, we learned about the difference between security of the cloud and security in the cloud, as well as the IAM (Identity and Access Management) system, which helps manage who can access what and what actions they are allowed to perform.
Next week — Part 4: Actually creating something — EC2, Auto Scaling, and Load Balancing, now that the account behind them is locked down properly.
Series: AWS: Zero to Hero (9 articles)
- …
- 3AWS: Zero to Hero — Week 3: Who's Actually Responsible for Securing What This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article