AWS: Zero to Hero

From your first authenticated CLI call to a mental model of the services every DevOps engineer touches daily — IAM, networking, compute, storage, and how it all fits together securely. This is a concepts-and-hands-on guide, not a click-through of 200 services. Work top to bottom, or jump to a part.

The journey:

The mental model — regions, accounts, the shared responsibility line
Authenticate the right way (no long-lived keys)
IAM — the service that governs everything
Networking — VPC, subnets, security groups
Compute — EC2, containers, and serverless
Storage — S3, EBS, and the rest
Cost and observability
Infrastructure as Code, not the console
Production security baseline

Prerequisites

You need	Why
An AWS account	The free tier covers everything here
The AWS CLI v2 installed	You'll authenticate and make calls
Basic networking + Linux familiarity	Subnets, ports, SSH come up constantly

Cost warning: most of this fits the free tier, but always run terraform destroy / delete resources when done, and set a billing alarm first (Part 7). Confirm the CLI: aws --version.

Part 1 — The mental model

AWS is a global platform organized into a few key boundaries:

Concept	What it is
Account	The top-level container + billing boundary. Real orgs use many accounts (prod/dev/security) under AWS Organizations
Region	A geographic location (`us-east-1`) with its own isolated infrastructure. You choose one; data mostly stays there
Availability Zone (AZ)	One or more datacenters within a region. Spread across AZs for high availability
Service	A managed capability (EC2, S3, RDS…) accessed via API

The shared responsibility model is the mindset: AWS secures the cloud infrastructure; you secure what you put in it — IAM policies, security groups, encryption, patching your instances. Most breaches are the customer's side (a public S3 bucket, an over-broad IAM role), not AWS's.

Part 2 — Authenticate the right way

The #1 AWS security mistake is long-lived access keys. Prefer IAM Identity Center (SSO) for humans:

aws configure sso           # set up SSO once
aws sso login               # short-lived session, refreshed on demand
aws sts get-caller-identity # confirm WHO you are — run this constantly

For scripts and CI, use IAM roles, never static keys:

On EC2/ECS/Lambda → an instance/task/execution role (temporary creds, auto-rotated).
In GitHub Actions/other CI → OIDC federation to assume a role (see the GitHub Actions tutorial).

If you must use aws configure with an access key for a quick test, treat it as temporary and delete the key after. aws sts get-caller-identity is your "who am I / am I authenticated" reflex.

Part 3 — IAM: the service that governs everything

Every API call is authorized (or denied) by IAM. The pieces:

Term	Meaning
Principal	Who's acting — a user, role, or service
Policy	A JSON document granting/denying actions on resources
Role	An identity you assume temporarily (the secure default for workloads)
Permission	`Effect` + `Action` + `Resource` (+ optional `Condition`)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Least privilege is the whole game: grant the narrowest actions on the narrowest resources. An explicit Deny always wins over an Allow. Never attach AdministratorAccess to workloads, and never use the root account for daily work — lock it with MFA and put it away.

Part 4 — Networking: VPC, subnets, security groups

A VPC is your private network in a region. Inside it:

Subnets carve the VPC's IP range across AZs. Public subnets have a route to an Internet Gateway; private ones don't (they reach out via a NAT).
Security groups are stateful virtual firewalls on resources — you allow inbound/outbound by port and source. Return traffic is automatic.
Route tables decide where traffic goes; NACLs are a coarser, stateless subnet-level filter.

aws ec2 describe-vpcs
aws ec2 describe-security-groups --group-ids sg-0abc123

The rule that prevents most incidents: put databases and app servers in private subnets, expose only a load balancer publicly, and open security-group ports to the narrowest source (a specific SG or CIDR, never 0.0.0.0/0 for SSH/DB ports).

Part 5 — Compute: EC2, containers, and serverless

Three tiers, increasingly managed:

Option	You manage	Use when
EC2	The whole VM (OS, patching, scaling)	You need full control or lift-and-shift
ECS / EKS (containers)	Containers; AWS runs the plane	You've containerized (see Docker)
Lambda (serverless)	Just your function code	Event-driven, spiky, or glue workloads
Fargate	Containers without managing servers	ECS/EKS without node ops

# Launch a tiny instance (free-tier eligible)
aws ec2 run-instances --image-id ami-xxxx --instance-type t3.micro \
  --key-name mykey --security-group-ids sg-xxxx --subnet-id subnet-xxxx

Pair compute with an Auto Scaling Group behind an Application Load Balancer across multiple AZs — that's the standard resilient web tier. Prefer the most managed option that fits; every VM you own is a VM you must patch.

Part 6 — Storage

Service	Shape	Use for
S3	Object storage (buckets)	Files, backups, static sites, data lakes, logs
EBS	Block volumes attached to EC2	An instance's disk
EFS	Shared network filesystem	Many instances mounting the same files
RDS / DynamoDB	Managed SQL / NoSQL databases	App data — don't self-host DBs on EC2

aws s3 mb s3://my-unique-bucket-name
aws s3 cp file.txt s3://my-unique-bucket-name/
aws s3 ls s3://my-unique-bucket-name/

S3 buckets are private by default — keep them that way. Enable Block Public Access at the account level, turn on default encryption and versioning, and never make a bucket public unless it's genuinely a public website. A public S3 bucket is the classic AWS data-leak headline.

Part 7 — Cost and observability

Cloud bills surprise everyone once. Guardrails:

Set a billing alarm / AWS Budget on day one so a runaway resource pages you, not accounting.
CloudWatch collects metrics, logs, and alarms; CloudTrail records every API call (your audit + forensics trail — enable it everywhere).
Tag everything (Environment, Owner, Project) so Cost Explorer can attribute spend.
Delete what you're not using — idle EC2, unattached EBS volumes, old snapshots, and NAT gateways quietly cost money.

aws cloudwatch describe-alarms
aws ce get-cost-and-usage --time-period Start=2026-07-01,End=2026-07-15 \
  --granularity MONTHLY --metrics UnblendedCost

Part 8 — Infrastructure as Code, not the console

Click-ops doesn't reproduce, review, or roll back. Define AWS in code:

Terraform (multi-cloud, huge ecosystem) — see the Terraform tutorial.
CloudFormation / CDK (AWS-native).

resource "aws_s3_bucket" "logs" {
  bucket = "acme-logs-prod"
}
resource "aws_s3_bucket_public_access_block" "logs" {
  bucket                  = aws_s3_bucket.logs.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Everything you provisioned by hand in this guide should ultimately live in a repo, reviewed via PR and applied by CI.

Part 9 — Production security baseline

Lock the root account — MFA, no access keys, never used for daily work.
No long-lived keys — SSO for humans, roles + OIDC for workloads.
Least-privilege IAM — narrow actions/resources; audit with IAM Access Analyzer.
Private by default — resources in private subnets, S3 Block Public Access on, security groups scoped tight.
Encrypt everything — S3, EBS, RDS at rest (KMS); TLS in transit.
CloudTrail on in all regions, logs to a locked-down bucket in a separate account.
Multi-account — separate prod/dev/security via AWS Organizations; blast-radius containment.
Billing alarms + tags from the start.

Common mistakes to avoid

Long-lived access keys in code or CI. The top cause of AWS breaches. Use roles + OIDC and SSO.
Using the root account. It bypasses IAM. Lock it with MFA and create IAM identities.
Public S3 buckets. Enable account-level Block Public Access; buckets are private for a reason.
0.0.0.0/0 on SSH/DB ports. Open only to a specific SG or CIDR; put databases in private subnets.
AdministratorAccess everywhere. Least privilege — an explicit deny beats a broad allow.
No billing alarm. A forgotten NAT gateway or GPU instance racks up a nasty bill silently.
Click-ops in the console. Unreproducible and unreviewable. Use Terraform/CloudFormation.
Single AZ. One datacenter blip takes you down. Spread compute and data across AZs.

Practice: try it yourself

Know who you are. Configure SSO (or a temporary key), then run aws sts get-caller-identity. Whose ARN is it, and what can it do?
Least-privilege policy. Write an IAM policy that allows read-only access to exactly one S3 bucket and nothing else. Attach it to a role, not a user.
Private-by-default bucket. Create an S3 bucket, enable Block Public Access, default encryption, and versioning. Upload and list an object via the CLI.
Guardrail first. Set an AWS Budget with an email alert at $5 before you launch anything else.
Codify it. Reproduce that bucket + public-access-block in Terraform and plan it. Then destroy everything you created by hand.

Self-check:

What's the shared responsibility model, and which side do most breaches come from?
Why prefer IAM roles/OIDC over access keys for workloads?
What makes a subnet "public" vs "private," and where do databases belong?
Name three things on the security baseline you'd set up on a brand-new account.

Where to go next

Codify your infrastructure with the Terraform tutorial — the way to run AWS at scale.
Run containers on AWS — the Docker and Kubernetes tutorials map directly onto ECS/EKS.
Manage secrets with the Vault tutorial or AWS Secrets Manager; deploy via GitHub Actions with OIDC.
Handy tools: grade a policy with the IAM Policy Analyzer, and design subnets with the VPC Planner and CIDR Calculator.
Practice with AWS interview questions in the question bank.

You now have the mental model: account/region/AZ → authenticate with roles → IAM least privilege → private networking → managed compute → private storage → cost guardrails → IaC. That's AWS the way it's run in production.