aws-pattern-library
22+ AWS architectures with diagram, ADR, Well-Architected pillars and cost — ready to paste into a PR
git clone https://github.com/fernando-moretes/ref-aws-pattern-library.gitListen to guide
generated on playGenerated only on first play
Powered by Amazon Polly + OmniVoice
A versioned catalog of 22+ AWS reference architectures — each with a Mermaid diagram, an ADR, Well-Architected pillars and a cost note — served as a Next.js site at patterns.moretes.com and maintained as a single TypeScript file under review.
Why a catalog, not a folder of diagrams
In 16 years designing platforms on AWS, I have redrawn the same serverless REST — API Gateway, Lambda, DynamoDB — more times than I can count. Each time in a different tool, with a different box name, without the reasoning from the previous round. The question this repository answers is not "how do you draw a data lake on S3?" — it's "where is the version the team already discussed, with the trade-off written down, so I can paste it into today's PR?".
The real problem: loose diagrams rot. A .drawio in a shared folder doesn't say why Kinesis beat MSK on that project, nor what the 10,000-events-per-second assumption cost. Six months later someone re-derives the decision from scratch and lands somewhere else, for reasons nobody recorded.
What the catalog does: it ties every diagram to an ADR (context, decision, consequences), to the services involved, to the six Well-Architected pillars and to a cost estimate with its assumptions spelled out. That's 22+ patterns across ten categories — Web, API, Data, Events, ML/AI, IoT, Security, DevOps, Hybrid/Networking and Batch — and every one of them goes through code review, because the catalog is code.
Who it's for: the architect who wants to stop redrawing, and the junior who needs a starting point where the trade-off is already encoded instead of discovered in production.
What every pattern ships with
flowchart diagram rendered client-side — plain text, with a readable diff in the PR/compare page to put two patterns side by side before decidingHow the catalog becomes a site
One TypeScript file feeds every route; there is no database, CMS or backend.
- frontend/lib/patterns.ts · 22+ entradas tipadas
- git push · PR revisado
- ci.yml · typecheck + build
- security.yml · scan de dependências
- / · categorias + recentes
- /patterns · busca e filtro
- /patterns/[slug] · diagrama · ADR · pilares · custo
- /compare · dois padrões lado a lado
- Mermaid 11 · render no cliente
- DNS · patterns.moretes.com
Install, run and contribute
- 1
Clone the repository
git clone https://github.com/fernando-moretes/ref-aws-pattern-library.git— the app lives infrontend/; the root holdsOPERATIONS.md,SETUP.mdandCONTRIBUTING.md. - 2
Install dependencies
cd frontend && npm install. Next.js 16, React 19, TypeScript 5, Tailwind 4 and Mermaid 11 — nothing outsidepackage.json, no AWS credentials. - 3
Start the dev server
npm run devand openhttp://localhost:3000. Browse/patternsto search and filter, and/comparefor two patterns side by side. - 4
Add a pattern
One new entry in
frontend/lib/patterns.ts— Mermaid diagram, ADR, services, pillars and cost with assumptions. Home, list, detail and compare read the same array, so no other page needs editing. - 5
Open the PR and let CI judge
Three workflows run: CI (typecheck and build), Frontend and Security. A missing field breaks
tscbefore anything reaches production — the only reviewer that never gets tired.
git clone https://github.com/fernando-moretes/ref-aws-pattern-library.git
cd ref-aws-pattern-library/frontend
npm install
npm run dev
# http://localhost:3000/patterns → busca e filtro / search and filter
# http://localhost:3000/compare → dois padrões lado a lado / two patterns side by sideHow it works under the hood
One source of truth: frontend/lib/patterns.ts is a typed array. Each element carries the slug, the category, the Mermaid diagram as a string, the ADR in three fields, the list of services, the per-pillar pointers and the cost note. The TypeScript type is the schema — if a pattern is born without its consequences field, the build fails, not the reader.
Routes are derived, not maintained: the home page builds the category cards and "recently added" from the array; /patterns filters and searches over it; /patterns/[slug] renders one item; /compare puts two side by side. Adding a pattern is one entry; there is no second list to forget to update.
Diagram rendering: Mermaid 11 runs in the browser. The upside is that the diagram is text — the PR diff shows an arrow moved from Kinesis to MSK, something a PNG never shows. The cost is that a diagram with broken syntax fails in the browser of whoever opens the page, not in the build. Open the pattern page before you merge.
Operations: Vercel serves the site, Cloudflare answers DNS, GitHub Actions handles CI, frontend and security. No database, no queue, no Lambda — the cost of keeping this alive for years is the cost of reviewing one TypeScript file, and that is exactly why it was built this way.
The cost note is only as good as its stated assumption
Every estimate ships with its assumptions — volume, region, retention. Swap us-east-1 for sa-east-1 or multiply the traffic by ten and the number changes bracket. Use the note to compare patterns against each other, not as a budget; the budget comes from the AWS Pricing Calculator with your numbers.
Take the ADR, not just the diagram
The format is MADR-friendly: copy context, decision and consequences into docs/adr/NNNN-title.md in your repository and rewrite the context for your case. A diagram without its recorded decision is what you had before the catalog.
FAQ
Can I use the patterns in a company repository?
Yes. The license is MIT — copy the diagram and ADR into your repo, keep the copyright notice and adapt. The analysis is mine, in the first person; no pattern represents any employer's position.
Why Mermaid instead of draw.io or PNG?
Because a diagram as text goes through code review like any other line. The diff shows what changed; a PNG only shows that something changed. The price is depending on client-side rendering — see the warning above.
Does the catalog include Terraform or CDK to deploy the pattern?
No. It's a catalog of decisions, not of ready-to-deploy infrastructure. What it delivers is the diagram, the why and the estimated cost — the implementation is yours, in whatever tool your team already operates.
References
When to use it
Use the catalog when: your team redraws the same patterns every project, needs a ready ADR to justify a choice in a PR, or has juniors who need a starting point with the trade-off already written. Use /compare before a decision meeting — two patterns side by side shorten the conversation more than any slide. Don't use it as a budget or as IaC: the cost note is for comparison, and the implementation stays yours. If your question is "which service do I pick?", the catalog helps; if it's "how do I ship this to production today?", it points the way and stops there.
Architecture, AWS, AI and market deep dives — straight to your inbox. Free.
No spam · unsubscribe anytime