Chapter 35 AWS I: CLI, IAM, S3 & KMS
The AWS CLI v2 from install to the credential chain, IAM users, roles and policies and how AWS evaluates them, AccessDenied messages read like a stack trace, roles and temporary credentials for people and CI, access key rotation and a leaked key, S3 from buckets to Block Public Access, versioning, lifecycle and encryption, and KMS key policies - against a simulated account with real outputs and real errors.
In plain words
Think of AWS as a huge building full of machines you can rent by the minute. Your company gets a private floor (an account). Every door on that floor has a guard who checks a list before letting anyone through, and the list says exactly who may open which door and do what behind it. People get badges (users and roles), some badges are temporary visitor passes that expire after an hour, and every door opening is written in a logbook.
This chapter teaches the remote control for that building (the AWS CLI), how the guards read their lists (IAM policies), the storage rooms (S3 buckets) and the safes (KMS keys).
Why it matters on call
Most platform and SRE job ads name AWS, and most AWS incidents start with one of four things this chapter covers: the CLI using credentials you did not expect, an AccessDenied nobody can explain, a bucket that went public, or an access key that leaked. Knowing how policies are evaluated turns a two-hour Slack thread into a five-minute read of the error message.
You already know Azure. Many ideas map one to one (subscription and account, role assignment and policy, storage account and bucket, Key Vault and KMS), and the chapter calls out where AWS differs, so the knowledge transfers in both directions.
Lessons
- AWS for Azure people: accounts, regions, ARNs and the API
- The AWS CLI v2: install, configure, profiles and the credential chain
- Output, --query, pagination and reading errors
- IAM: principals, groups, policies and the policy language
- Policy evaluation: how AWS decides, and reading AccessDenied
- Roles and STS: trust policies, assume-role and temporary credentials
- Access keys: rotation, leaks and CloudTrail
- S3: buckets, keys, prefixes and the s3 commands
- S3 security: Block Public Access, bucket policies and object ownership
- Versioning, lifecycle rules and encryption at rest
- KMS: keys, key policies, grants and the kms:Decrypt gotcha
- Who can do what? Reviewing an account
23 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Is this a real AWS account?
No. The chapter runs against a simulated account (simulator): 111122223333, Regions eu-central-1 and eu-west-1, with the real CLI v2 output formats, the real error messages and the real policy evaluation rules. Nothing leaves your box and nothing costs money. Every command you type works the same way against a real account, so you can repeat the labs in a free-tier account later.
Do I need to know Azure for this chapter?
It helps but is not required. The first lesson has a mapping table (subscription to account, Entra ID to IAM and Identity Center, storage account to bucket, Key Vault to KMS) for readers coming from Azure. Everything else is explained from the ground up: principals, policies, buckets, keys. Where the two clouds behave differently, the lesson says so.
Which AWS CLI version does the lab use?
AWS CLI v2, version 2.37.10, installed with the official installer for Linux arm64 (the box is an Apple Silicon VM running Ubuntu 26.04). Version 1 is the old Python package and is not covered. The lesson on the CLI also shows the apt and snap packages and why the official installer is the usual choice on a server.
What comes after this chapter?
AWS II covers networking and compute in the same simulated account (VPCs, security groups, EC2, load balancers), and AWS III covers running workloads (EKS, ECR, CloudWatch and the cost side). The IAM, S3 and KMS skills from this chapter are used in both: every service there is reached through the same CLI and checked by the same policy evaluation.
Why so much time on IAM?
Because almost every AWS problem an on-call engineer sees is an identity problem in disguise: a pipeline that cannot deploy, a pod that cannot read its bucket, a role that can do too much. IAM is also the part interviewers ask about most, and the part where a mistake turns into a security incident. Reading an AccessDenied correctly is worth more than knowing a hundred services.