52 AWS Study Guides in 18 Weeks: A Practitioner's Field Notes

I decided to fix that the way I learn best: by writing.

The result is 52 study guides, organized across 18 weeks, covering the services and patterns I use most as a cloud engineer. Each guide runs ~60 minutes. None of them are introductory the plan assumes you already know what a VPC is, what an IAM role is, and how a container works.

Because summarizing forces you to identify what you don't actually understand. When I tried to write about RDS Proxy, I realized I had never properly understood what causes pinning when a client connection gets stuck to a specific database connection instead of being reused by the pool. The documentation mentions it. But I had read past it without the concept really sticking. Writing the guide forced me to understand it well enough to explain it.

That pattern repeated throughout the plan. The DynamoDB guide forced me to define exactly when a GSI causes a hot partition and when it doesn't. The Karpenter guide forced me to understand the real difference between the NodePool API and the old Provisioner, and what actually changed in behavior with the v1 API. Writing is an audit of your own knowledge.

Technical documentation goes stale. Opinions become facts. Community consensus gets treated as specification. That bothered me enough that I adopted a simple convention: every substantive claim in any guide carries an explicit confidence marker.

It sounds bureaucratic written out like that. In practice, it changes how you consume the material: you know, before implementing something, whether you're following a verified fact or a recommendation someone consolidated from practical experience. It also forced me to be honest about what I didn't know for certain.

Two concrete examples from the plan where this mattered: as of June 2026, RDS Performance Insights was discontinued and replaced by CloudWatch Database Insights — the RDS guide carries this as [FACT] with the EOL date. Aurora Serverless v2 was renamed to simply "Aurora serverless" in April 2026 also marked, so the information isn't confused with a functional change that didn't happen.

All 52 guides follow the same template.

Concepts with the epistemic markers described above, and ASCII diagrams to represent flows and architectures without depending on external tools or images that break.

CDK Python with the full infrastructure for the service being studied. Not snippets working stacks you can use as a starting point. For example, the RDS Proxy guide includes a stack with Multi-AZ, a read replica, a proxy with three authentication modes (credentials, standard IAM, and end-to-end IAM), and CloudWatch alarms for replica lag and connection count.

Application-layer code in Python with the SDK not infrastructure, but the code that runs on the server. In the RDS Proxy guide, for example, there's an IAMTokenManager class that caches the authentication token for 14 minutes (the token expires in 15) and renews it automatically before expiry, transparently to the application.

Annotated CLI walkthroughs from scratch, with context explaining why each flag exists, not just what it does.

Documented pitfalls the mistakes I've made or seen repeated in architecture reviews. In the Karpenter guide: Karpenter cannot manage the node it's running on; if you don't configure the correct NodeSelector during install, Karpenter may try to consolidate the node where it's running and create a loop. In the EKS IRSA vs Pod Identity guide: the two mechanisms have different behaviors when the role assumes another role — and most comparisons you find don't mention this.

Reflection exercises with open-ended questions to consolidate learning before moving to the next session.

References always to primary documentation AWS docs pages, official repositories, RFCs. Never blog posts or paid courses as technical references.

The 12 modules cover IaC (advanced AWS CLI, CloudFormation with changesets and drift detection, CDK v2 from bootstrap through self-mutating pipelines and custom resources), ECS Fargate in depth (capacity providers, blue/green with CodeDeploy, FireLens), Lambda (execution model and cold starts, event source mappings with filtering, extensions, Lambda@Edge vs CloudFront Functions), Step Functions, load balancers (ALB with native OIDC and mTLS, NLB, GLB for inline inspection), DynamoDB with single-table design and adjacency list, DAX, transactions and Global Tables, observability with CloudWatch (EMF, Logs Insights, composite alarms, anomaly detection) and X-Ray, FinOps with Savings Plans, Spot Fleet and Cost Explorer, Secrets Manager and SSM Parameter Store, EKS from cluster setup to Karpenter (IRSA, Pod Identity, VPC CNI with Prefix Delegation, EBS CSI Driver, NodePool and EC2NodeClass), RDS Multi-AZ, RDS Proxy and Performance Insights, and Aurora serverless with Global Database including switchover vs managed failover.

Because someone already wrote what I needed to know, somewhere, and published it. And I learned because of that. It's the only reason.

The repository is open on GitHub. If you find something wrong, outdated, or simply confusing, open an issue. If any guide is useful to you, even better.

🔗 https://github.com/crypto-br/52-weeks-of-aws-engineer/blob/main/EN-README.MD [EN]

🔗 https://github.com/crypto-br/52-weeks-of-aws-engineer/blob/main/README.md [PT-BR]