Who patches the guest OS on an EC2 in 10.51.0.0/16?

Correct: b. Shared responsibility: guest OS is customer.

Root on 111122223333 should be used for…

Correct: b. Root is the account owner.

A stolen IAM access key can read S3 even from a private subnet because…

Correct: a. Identity vs network.

Preferred human login to this dummy account?

Correct: b. Identity Center for humans.

T Techclick ← All lessons

Amazon · AWS security · Lesson 1 of 10

Shared responsibility: AWS secures the cloud, IAM is your perimeter

Chat says “AWS was hacked.” Usually it was an IAM user key, a public bucket, or root used as a daily login. AWS is responsible for security of the cloud. You are responsible for security in the cloud — data, identity, OS, network config. Account 111122223333 root is not a person.

Updated 2026-08-18·18 min read·L2 primary·Quiz at end

After this page you can

Draw of-the-cloud vs in-the-cloud for EC2, S3, and Lambda.
Treat IAM (and Identity Center) as the account perimeter, not the VPC edge.
Lock root: MFA, no access keys, no daily console.
Prove who you are with sts get-caller-identity before you change anything.

The ticket

Priya’s laptop has a screenshot of the root console for account 111122223333. Yesterday she created sg-web as root. Today the same password is in a shared chat. That is not an AWS outage. That is you handing over the account.

Quick interview answer

AWS Shared Responsibility Model: AWS secures the cloud (regions, hardware, hypervisor, managed-service plane). You secure in the cloud — customer data, IAM, guest OS, security groups, encryption choices, application. The more managed the service, the less OS work you do; identity and data stay yours. Root is the account owner, not a daily user. Humans use IAM Identity Center. Workloads assume roles. Long-lived access keys are not a login method.

AWS of-the-cloud versus customer in-the-cloud with IAM as the perimeter — The hypervisor is theirs. The access key on the laptop is yours.

Lab data · dummy only

Account 111122223333 · OUs Security / Workloads · hub VPC 10.50.0.0/16 · app VPC 10.51.0.0/16 · SG sg-web · NACL acl-app · bucket tc-lab-app-logs · role AppEC2Role · TGW tgw-lab · VGW public 203.0.113.60 · on-prem FortiGate WAN 203.0.113.10. Dummy account ID. Not yours.

Mental model

Service style	AWS still owns	You still own
EC2 in app VPC 10.51.0.0/16	Host, hypervisor, facilities	Guest OS, `sg-app`, IAM role, data, patches
S3 `tc-lab-app-logs`	Storage plane, durability of the service	Block Public Access, bucket policy, encryption, objects
Lambda / managed	Runtime host and patching	Code, execution role, secrets, what the function can reach

The line

IAM sits on your side. A VPC is not a substitute for identity.

How to choose

Who	How they enter 111122223333	Never
Human (Priya)	IAM Identity Center permission set → temporary creds	Root, long-lived IAM user access keys
EC2 / app	Instance profile `AppEC2Role`	Keys in user-data or ~/.aws
Break-glass	Root + hardware MFA, offline, rare	Shared root password in chat

https://111122223333.signin.aws.amazon.com/console

Training mock · not live

AWS console

VPCIAMS3CloudTrail

IAM → Dashboard

Account 111122223333 · identity hygiene

Root MFA

Enabled — hardware preferred, not a daily login

Root access keys

None

Human access

IAM Identity Center (SSO) — no IAM user keys

Workload role

AppEC2Role · instance profile

Caller check

aws sts get-caller-identity

IAM is the perimeter. Root is the owner, not a teammate. Training mock.

Runbook

Side A — who am I
aws sts get-caller-identity. If the ARN is root or a personal IAM user with access keys, stop. Identity Center assumed-role is the expected human path.
Side B — root lock
Root: MFA on, no access keys, no daily console. Delete any root keys. Humans get permission sets, not AdministratorAccess pasted on an IAM user.
Side C — prove the split
Name one thing AWS patches for you (hypervisor) and one thing you patch (guest OS on the app VPC instance). Write it on the ticket.

aws cli · dummy 111122223333

aws sts get-caller-identity
# Account: 111122223333
# Arn: arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_SecurityAudit_aabb/priya

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
# 1

aws iam list-access-keys --user-name root
# do not create these; empty is the proof

Four failures

1 · Root as daily admin

Every click is unbounded. MFA on root does not make root a person.

2 · “AWS was hacked”

Usually a leaked key or a public bucket. Start with IAM and S3, not a region outage story.

3 · VPC as the only perimeter

A private subnet does not stop a stolen access key from calling s3:GetObject on tc-lab-app-logs.

4 · IAM user keys for humans

They live for years. Identity Center issues temporary credentials. Next lesson is the org; this lesson is the person.

How to prove it

Close the ticket only when

1) Caller identity is not root. 2) Root MFA is on and root keys are absent. 3) You can say of-cloud vs in-cloud for the sick service. 4) You did not “fix” it by creating another long-lived key.

Traps

Symptom	Your side	Wrong fix
Someone listed all buckets	IAM / leaked key	“AWS breach, wait for AWS”
EC2 CVE on the guest	You patch the AMI / instance	Open a hypervisor ticket
S3 object public	Bucket policy / ACL / BPA	Blame S3 durability

AWS security class series: Shared + IAM · Org / OU · SG vs NACL · Role not key · KMS + Secrets · VPC endpoint · Trail + GuardDuty · TGW hub · S3 public · Interview