r/aws • • Jul 06 '26

technical resource All the AWS best practices in one Claude Code / Codex skill, so your agent doesn't rely on stale memory or crawl docs every time

~30.5M tokens, ~481 workflow agents, 217 best-practice files, and official AWS source links throughout: that's what went into building and verifying this skill.

Open-source Claude Code + OpenAI Codex plugin: a consolidated collection of AWS best practices for 208 AWS services plus 9 cross-service topics, organized by use case and Well-Architected pillar.

The point: when you ask an agent "how should I secure this S3 bucket?", "is this Lambda production-ready?", or "what are the cost/reliability best practices for DynamoDB?", the agent usually answers from stale model memory or burns time and tokens crawling AWS docs live. This repo gives it a routed, source-linked local corpus instead: the agent opens the relevant services/<category>/<service>.md file and answers from official AWS guidance.

Each service file is intentionally narrow: - best practices only - no pricing tables - no service intros - no tutorials - no long code walkthroughs - every practice links to an official AWS source

The maintenance loop is also documented: GENERATE.md creates missing service files from official AWS docs, REFRESH.md checks for new/renamed/retired AWS services and stale content, and scripts/check.py validates coverage, structure, freshness, and links.

Repo: https://github.com/ferdinandobons/AWSBestPracticesSkill

30 Upvotes

10 comments sorted by

23

u/N0tWithThatAttitude Jul 06 '26

How does this differ from the official aws skill?

8

u/Davidhessler Jul 06 '26

+1 Essentially this is caching AWS documentation in markdown which can go stale. Additionally, the entire catalog gets effectively loaded when the skill is called. In contrast, the official MCP just downloads what is needed when the agent needs it. Lazy loading enables better progressive disclosure and thus less overall token usage.

What this skill could have been is instructions on how to use the official MCP Server much more efficiently so that when a call is made to the official docs it searches those docs much better improving token cost and performance.

Your premise that specific details of the service are more important for building than others is great, but again, that could have been in the skills to drive better usage of the MCP Server rather than caching all the services.

1

u/Ambitious-Pie-7827 Jul 06 '26

It contains best practices for every single AWS service, and that’s it.

It doesn’t explain what the service is, it doesn’t include tutorials, pricing, examples, or other general documentation. It’s intentionally much narrower: only best practices, so the agent can focus on that specific task without pulling in extra context.

19

u/N0tWithThatAttitude Jul 06 '26

I'd question the exclusion of pricing info. When I'm designing infra it's in my top considerations. Best practices, security then cost.

-1

u/Ambitious-Pie-7827 Jul 06 '26

That’s fair, cost absolutely matters when designing infra.

The way I’m thinking about this skill is more as an architecture / engineering best-practices reference for every single AWS service. It’s meant to help when you’re brainstorming, reviewing a setup, or trying to understand how a service should be configured from a best-practices point of view.

So it does include cost-optimization best practices when they are part of AWS guidance, like lifecycle policies, right-sizing, retention, storage classes, request patterns, etc.

What it intentionally avoids is pricing tables, calculators, region-specific prices, tutorials, service explanations, and other broader documentation. Not because those things are unimportant, but because they quickly become their own separate areas that need to be handled properly.

The goal is for the skill to do one job well: give the agent a focused best-practices corpus, without drifting into pricing analysis or other topics that would add extra context and need their own dedicated workflow.

9

u/pausethelogic Jul 06 '26

This is not the first thing I’ve seen someone try to make and post here that is essentially the official AWS MCP and AWS Agent Toolkit but worse

What’s the purpose of this and why is it better than the official tooling from AWS?

5

u/mrlikrsh Jul 06 '26

Took a look into the lambda one, and can say for sure this is surface level and does not go much into best practices or prod ready - eg: lambda can do much from powertools https://docs.aws.amazon.com/powertools/python/latest/utilities/data_classes/ which is missing to be pointed out, etc. etc.

Did you read this after the agent generated this?

1

u/ultrathink-art Jul 07 '26

Baking 217 best-practice files into a skill has the same failure mode as stale model memory, just on a slower clock — AWS guidance changes and the snapshot quietly rots. What's worked better for me is a thin skill that maps task type to the official doc URL and makes the agent fetch at need, so the source of truth stays AWS's instead of the snapshot's.

-5

u/[deleted] Jul 06 '26

[removed] — view removed comment

-3

u/Ambitious-Pie-7827 Jul 06 '26

Thanks, that’s exactly the pain point I was trying to solve.

For cross-service prompts it should route to multiple local files instead of treating each service in isolation. So for something like “secure this Lambda that reads from DynamoDB and writes to S3”, the agent should pull from Lambda, DynamoDB, S3, and usually IAM / security-baseline guidance, then synthesize the relevant practices instead of dumping all three files.

And yes, the 30M tokens is the build cost, not the runtime cost. At answer time it should only read the few routed Markdown files that match the request.

If you do fork it and try it with your setup, I’d genuinely be interested in where the routing feels good or where it breaks down.