AWS Learning Order

Level: beginner
Read: 12 min
Concepts: 1

The thirty-five steps are an order because each one removes a category of confusion from the ones after it, and they read most usefully as eight groups. Foundations come first — cloud fundamentals, accounts and Organizations, IAM, the CLI and SDK, Regions and Availability Zones — because they appear in every error message you will read afterwards, and skipping them turns each AccessDenied into a mystery rather than a lookup. The network is second, so that an unreachable resource becomes a routing question with five distinguishable causes rather than a reason to open a security group to the world. Compute and traffic follow, with load balancing deliberately ahead of EC2 so the mental model is a replaceable fleet instead of a pet server. Storage and delivery, then data, then decoupling and containers add the pieces a real application needs, and Docker sits beside ECS rather than months away because the two are learned together. Operating and delivering — secrets, observability, infrastructure as code, CI/CD, security and cost — comes before the senior material on purpose: those six are exactly the dimensions that are otherwise silent in a design review. The last five are synthesis and draw on nearly everything above. The gaps between groups are the real checkpoints, groups one and two are hard prerequisites while the middle ones are looser, and each group is best finished with something you built rather than something you read.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

Read it as eight groups, not thirty-five items.
Foundations and networking are hard prerequisites; the middle groups are looser.
Load balancing before EC2 teaches a fleet rather than a pet server.
Operating comes before architecture, because those are the dimensions reviews miss.
End each group with something you built — the artefacts compound.

What you will be able to do

Follow the thirty-five step order as eight groups with clear checkpoints
Say what each group unlocks and what skipping it costs later
Distinguish a hard prerequisite from a soft one when your job needs a detour
Turn the order into a schedule of eight builds rather than a reading list

AWS Learning Order

The thirty-five steps grouped into eight, what each group unlocks, the failure that follows from skipping it, and the single thing to build at the end of each.

The Thirty-Five Step Order, and Why It Is an Order

corebeginner

The thirty-five steps are an order, not a list, and each one is there because the next several are hard to understand without it. Learning EC2 before networking produces an instance you cannot reach and no idea why; learning Lambda before IAM produces a function that fails with AccessDenied and a guess about the cause. The order removes that entire category of confusion.

Think of it as

Read the order in eight groups, not thirty-five items. Foundations, then the network, then compute and traffic, then storage and delivery, then data, then decoupling and containers, then operating and delivering, then the senior work. Each group is only useful once the one before it is in place, and the boundaries between groups are where people who skip ahead get stuck.

What we're doing: Turn the order into a schedule you can actually follow.

schedule.txttext

The order is not a reading list. Each group ends with one thing
you build, and the build is what makes the next group make sense.

GROUP 1 — foundations
  Build: two accounts under one organization, an IAM role you
         assume from your own identity, and the CLI configured
         to use it. No access keys anywhere.
  Done : you can explain what happens when you run a CLI command.

GROUP 2 — the network
  Build: a VPC with public and private subnets across two zones,
         one instance in each, and connectivity you can trace.
  Done : you can say why the private one has no internet access
         and exactly what would change that.

GROUP 3 — compute and traffic
  Build: an Auto Scaling group behind an ALB. Then terminate an
         instance while watching the target group.
  Done : the fleet healed and you watched it happen.

GROUPS 4-5 — storage and data
  Build: an app that stores uploads in S3 and rows in RDS, with
         a cache in front of one read.
  Done : you can state what a cache miss costs, in milliseconds.

GROUP 6 — decoupling and containers
  Build: the same app containerised on ECS, with one slow step
         moved onto a queue.
  Done : the response no longer waits for the slow step.

GROUP 7 — operating and delivering
  Build: all of it from Terraform or CDK, deployed by a pipeline,
         with secrets in Secrets Manager and one real alarm.
  Done : you deleted the stack and recreated it from the repo.

GROUP 8 — synthesis
  Build: nothing new. Run the drills, review it against §65, and
         write the runbook.
  Done : someone else recovered it using your document.

Eight builds. Each one is small, each one is demonstrable, and
each one is the reason the next group is comprehensible.

1: The distinction between a reading list and a build order is the whole point — capability comes from operating things, not from covering material.
9: Tracing connectivity in a network you built yourself is what makes the five candidate causes distinguishable later.
21: Deliberately terminating an instance and watching the fleet heal converts the replaceable-fleet idea from a claim into something you have seen.

Why this works: A thirty-five item list invites reading and reading does not produce capability. Eight builds produce the same coverage with an artefact at each checkpoint, and the artefacts compound — the VPC from group 2 hosts the fleet from group 3, which runs the app from group 5, which gets containerised in group 6 and codified in group 7.

Starting at the service you have been asked to use

Wrong

text

# "The team uses Lambda, so I will start at step 21."
# Week one: an AccessDenied nobody can explain, a function with
# no VPC access, and a cold start blamed on the language.

Better

text

# Start at 03 IAM and 06 VPC even if the destination is Lambda.
# Three days of foundations turns those three problems into
# three answers, and they are answers you keep.

What you see: Fast early progress that stalls hard, because every problem is a first-time problem and none of them can be reasoned about from what came before.

Why: The service you were asked to use sits on top of the foundations, and its failures are usually foundation failures wearing a service name — an AccessDenied is IAM, no VPC access is networking, and a timeout is often a route. Starting at the top means learning each foundation anyway, one incident at a time, in the worst possible order.

Thirty-five steps, in eight groups

The gaps between groups are the real checkpoints. Skipping forward within a group costs a little; skipping a whole group is what produces the errors nobody can explain.

The eight groups, what each unlocks, and what happens if you skip it

The eight groups, what each unlocks, and what happens if you skip it
Group	Steps	What it unlocks	Skipping it looks like
1 · Foundations	01 cloud fundamentals, 02 accounts and Organizations, 03 IAM, 04 CLI and SDK, 05 Regions and AZs	Reading any AWS error, and knowing which boundary a resource lives in	Every AccessDenied is a mystery, and a resource "disappears" because you are in another Region
2 · The network	06 VPC, 07 subnets and routing, 08 security groups and NACLs, 09 DNS	Knowing why something is unreachable, and where a packet stops	An instance you cannot connect to, fixed by opening 0.0.0.0/0 and moving on
3 · Compute and traffic	10 load balancing, 11 EC2, 12 EBS and AMIs, 13 Auto Scaling	The replaceable-fleet model, which every later service assumes	A hand-configured instance nobody dares replace, and no idea how to scale it
4 · Storage and delivery	14 S3, 15 CloudFront	Serving static content and handling large objects properly	Files on an instance disk, lost with the instance
5 · Data	16 RDS and PostgreSQL, 17 ElastiCache	State, connections, failover behaviour and caching	A connection pool sized by guesswork, and a cache used as a database
6 · Decoupling and containers	18 SQS and SNS, 19 ECS, 20 Docker, 21 Lambda, 22 API Gateway, 23 DynamoDB, 24 EventBridge	Asynchronous work, containers, and the serverless option	Slow work done inside the request, and a timeout treated as a tuning problem
7 · Operating and delivering	25 KMS and Secrets, 26 CloudWatch and CloudTrail, 27 IaC, 28 CI/CD, 29 security, 30 cost	Running the system: secrets, signals, reproducibility and the bill	A working system nobody can rebuild, watch, or explain the cost of
8 · Synthesis	31 reliability, 32 disaster recovery, 33 architecture, 34 system design, 35 production debugging	Designing and defending a system, and recovering one under pressure	Confident designs with no failure story, and incidents worked by guessing

Together

text

# Why the two most commonly skipped boundaries are the two that
# hurt, with the actual failure each produces.

SKIPPING GROUP 2 (the network) TO REACH EC2 FASTER

  Symptom : the instance launches and SSH times out.
  What happens next: the tutorial answer is "open port 22 to
  0.0.0.0/0", it works, and the real cause is never found.
  What was actually wrong: any of five things — no public IP,
  no internet gateway route, a NACL with no ephemeral return
  rule, the wrong subnet, the wrong key pair.
  Cost: every future connectivity problem is a guess, because
  the five candidates were never distinguished.

SKIPPING GROUP 7 (operating) TO REACH ARCHITECTURE

  Symptom : nothing. The designs look fine on a whiteboard.
  What happens next: the design has no observability, no secret
  handling, no cost story and no way to reproduce it.
  What was actually missing: the four dimensions §64 names as
  the most commonly silent ones are precisely the ones taught
  in group 7.
  Cost: designs that pass a review and fail in the first month.

# The pattern: skipping a group does not block you. It removes
# the ability to tell one cause from another later, which is
# exactly the skill the group existed to build.

Remember: Eight groups, not thirty-five items: foundations, network, compute and traffic, storage and delivery, data, decoupling and containers, operating and delivering, synthesis. Groups 1 and 2 are hard prerequisites; the rest are looser. End each group with something you built, not something you read.