Priority for a 5-Year AWS Engineer

Level: advanced
Read: 14 min
Concepts: 1

AWS publishes hundreds of services and a senior engineer is expected to be genuinely deep in about seventeen. Those seventeen are foundations rather than products — identity, networking, compute, load balancing and scaling, storage, relational data, observability, auditability, queues, containers, delivery, troubleshooting, cost and architecture — and the test for each is that you can design it, debug it at three in the morning and state its trade-off with nobody available to ask. A second tier of roughly seventeen more is the set you can build correctly with the documentation open, where knowing the limit that shapes each one matters more than knowing its full feature surface. A third tier is recognition only: you can say that a problem calls for Kinesis or Step Functions or Direct Connect, and name what you would have to learn before committing to it. The tiers are defined by that verb rather than by how interesting a service is, which is why the common failure is spending a month on tier-3 novelty while every ordinary IAM error still costs an afternoon. Applied honestly, item by item, the list stops being a ranking and becomes a diagnostic: mark each tier-1 item with the verb you can actually claim, group the gaps by root cause, and close the one that blocks you most often — against a real system rather than a reading list.

AWS overview

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

What is true here

Tier 1 is seventeen foundations, and every incident is debugged through them.
The tier test is a verb: design and debug unaided, build with the docs open, or recognise.
Tier 2 depth is knowing the limit that shapes a service, not its full feature list.
Studying tier 3 for novelty while tier 1 gaps persist is the common and expensive mistake.
Mark yourself item by item; the useful output is a specific gap, not a score.

What you will be able to do

Rank AWS services by the depth your role actually requires
Apply the verb test to your own knowledge and produce a specific gap list
Group gaps by root cause rather than by service name
Choose what to learn next by what blocks the day, not by what sounds current

Priority for a 5-Year AWS Engineer

The three tiers, the test that defines each one, and how to turn the list into a study plan with specific items rather than a ranking to admire.

Three Tiers — What to Master, What to Know, What to Recognise

coreadvanced

AWS has hundreds of services and a five-year engineer is expected to be deep in about seventeen of them. The rest divide into a second tier you use confidently when a project needs them, and a third tier you recognise well enough to say when it applies and who to ask. Trying to hold all three at the same depth is what produces broad, shallow knowledge that fails the first hard question.

Think of it as

Depth is defined by what you can do without help. Tier 1: you can design it, debug it at 3 a.m. and explain the trade-off. Tier 2: you can build it correctly with the documentation open. Tier 3: you can recognise that this is the right tool and say what you would need to learn. The tiers are about that verb, not about how interesting the service is.

What we're doing: Use the tiers to turn a vague plan into a specific one.

plan.txttext

The unhelpful version: "I want to get better at AWS."

The tier version: go through tier 1 and mark each item with the
verb you can honestly claim.

  can design + debug + defend    → done
  can build with the docs open   → one tier short
  can recognise it               → two tiers short

WORKED, FOR A REAL ENGINEER

  IAM                 build-with-docs   ← tier 1 gap
  VPC / networking    design + debug
  EC2                 design + debug
  Load balancing      design + debug
  Auto Scaling        build-with-docs   ← tier 1 gap
  S3                  design + debug
  RDS / Aurora        build-with-docs   ← tier 1 gap
  CloudWatch          design + debug
  CloudTrail          recognise         ← two tiers short
  SQS                 design + debug
  ECS                 design + debug
  Docker              design + debug
  CI/CD               design + debug
  IAM security        recognise         ← two tiers short
  Troubleshooting     design + debug
  Cost basics         build-with-docs   ← tier 1 gap
  AWS architecture    design + debug

Five gaps, and they are not equal. IAM and IAM security are the
same root: the evaluation order and the policy types have never
been learned properly, and every AccessDenied is therefore an
afternoon. That one root causes two of the five marks.

So the plan is not "study AWS". It is: IAM evaluation order and
policy types this week, then RDS failover behaviour, then the
Auto Scaling lifecycle. Three specific things, in an order set
by how often each one blocks the day.

1: The vague version cannot be finished, so it stays on the list indefinitely — which is the actual problem with it.
9: Marking with a verb rather than a score forces honesty: "can debug at 3 a.m." is either true or it is not.
19: Grouping gaps by root cause is what turns five items into three, and the root is usually a foundation rather than a service.

Why this works: The tier list is only useful when it is applied to yourself item by item, because the interesting output is not the ranking — it is the specific gap. Most people who feel behind on AWS are tier 1 on twelve items and tier 3 on two foundational ones, and those two are producing nearly all the friction.

Studying tier 3 because it is more interesting

Wrong

text

# A month on EKS internals and Kinesis shard maths, while every
# IAM error still takes an afternoon to resolve.

Better

text

# The tier 1 gap first: policy evaluation order, the five policy
# types, and reading a real AccessDenied. Two days of work that
# pays back every week for the rest of your career.

What you see: A broad, current-sounding knowledge of AWS that stalls on ordinary incidents — impressive in a conversation, slow on a Tuesday.

Why: Tier 3 services are more interesting precisely because they are unfamiliar, and novelty is a poor guide to value. Tier 1 items are boring because they appear every day, and appearing every day is exactly what makes the depth compound. The specialised knowledge also decays faster, because nothing exercises it.

Three tiers, defined by what you can do unaided

The width of each band is roughly its share of a working week. Tier 1 is the base because everything above it is debugged through those seventeen things.

The three tiers, the test for each, and what it looks like when the depth is missing

The three tiers, the test for each, and what it looks like when the depth is missing
Tier	What is in it	The test	Missing depth looks like
Tier 1 — master	IAM, VPC and networking, EC2, load balancing, Auto Scaling, S3, RDS/Aurora, CloudWatch, CloudTrail, SQS, ECS, Docker, CI/CD, IAM security, troubleshooting, cost basics, AWS architecture	Design it, debug it at 3 a.m., and state the trade-off — unaided	An AccessDenied that takes an afternoon; a 5xx spike investigated by guessing
Tier 2 — strong working knowledge	Lambda, API Gateway, DynamoDB, EventBridge, SNS, ElastiCache, CloudFront, Route 53, KMS, Secrets Manager, Organizations, Config, WAF, CDK/CloudFormation/Terraform, disaster recovery, observability, distributed systems	Build it correctly with the documentation open, and name the limit that shapes it	Shipping a design that meets the requirement and breaks on a documented quota
Tier 3 — conceptual and specialised	EKS internals, Kinesis, Step Functions, advanced multi-Region patterns, Direct Connect, advanced governance, advanced security services, specialised analytics and AI services	Recognise that this problem calls for it, and say what you would need to learn first	Reaching for the specialised tool when a tier 1 or 2 answer was sufficient

Together

text

# The tier test, applied to one service, honestly.

DynamoDB — where am I?

Tier 3 answer: "It is a NoSQL key-value store, good for
               high-scale simple lookups."
Tier 2 answer: "Partition key and sort key. Query needs the
               partition key; Scan reads everything and you
               avoid it. A GSI adds an access pattern and has
               its own capacity. I would design the access
               patterns before the table."
Tier 1 answer: adds — "Hot partitions and how adaptive capacity
               does and does not save you. Single-table design
               and when it is not worth it. TransactWriteItems
               versus a conditional write. What a 400 KB item
               limit does to a design. Which of those I have
               actually hit in production, and what it cost."

The useful part of this exercise is that the gap is specific.
"I am tier 2 on DynamoDB and the missing piece is hot
partitions" is a study plan. "I should learn DynamoDB better"
is not.

Remember: Master seventeen things, know a second tier well enough to build with the documentation open, and recognise a third well enough to name it and its cost. Mark each tier 1 item with the verb you can honestly claim, group the gaps by root cause, and close the one that blocks you most often — against a real system, not a reading list.