aws-pattern-library
22+ AWS architectures with diagrams, ADRs and cost notes — ready to copy.
git clone https://github.com/fernandofatech/aws-pattern-library.gitAWS Pattern Library is a versioned, searchable catalog of 22+ AWS reference architectures — each one ships with a Mermaid diagram, an ADR, Well-Architected pointers, and a cost estimate, all browsable through a Next.js frontend deployed at patterns.moretes.com.
Why I built this
Every solution architect I know — including myself — has rebuilt the same EventBridge fan-out diagram or the same S3 data-lake ADR at least a dozen times across different clients and teams. The knowledge exists, but it lives in slide decks, Confluence pages, and people's heads. None of those places are version-controlled, searchable, or easy to copy into a pull-request description.
This library is my answer to that problem. I wanted a single place where a recurring AWS pattern is captured once, with enough context to be immediately useful: what problem it solves, which services are involved, what trade-offs the architecture encodes, which Well-Architected pillars it touches, and a rough cost envelope with stated assumptions. The ADR format (context → decision → consequences) is deliberate — it forces me to document why, not just what.
The secondary goal is pedagogical. Junior architects and engineers joining a team often lack the vocabulary to evaluate trade-offs. A catalog that already encodes those trade-offs gives them a starting point that is honest about the downsides, not just the happy path.
What each pattern includes
/compare route — pick any two patterns and diff their pillars and services.Coverage across ten domains
The 22+ patterns span the scenarios I encounter most often in production engagements:
- Web — three-tier app, static SPA, managed WordPress.
- API — serverless REST with API Gateway + Lambda, managed GraphQL with AppSync.
- Data — data lake on S3, lakehouse with Apache Iceberg.
- Events — event-driven microservices, Step Functions sagas, MSK streaming pipelines.
- ML / AI — real-time inference, batch inference, GenAI RAG with Amazon Bedrock.
- IoT — telemetry ingest at scale via IoT Core.
- Security — secrets rotation with Secrets Manager, GuardDuty + Security Hub posture management.
- DevOps — blue/green deploys, EKS platform baseline, CodePipeline CI/CD.
- Hybrid / Networking — multi-account VPC mesh with Transit Gateway, cross-region DR.
- Batch — AWS Batch with EC2 Spot for cost-optimised compute.
The catalog is intentionally broad rather than deep. Each entry is a starting point — a documented decision that a team can adopt, adapt, or explicitly reject. The point is not to be prescriptive; it is to make the conversation faster by giving everyone a shared vocabulary and a concrete artefact to mark up.
How the catalog works end-to-end
A single TypeScript file (patterns.ts) is the source of truth. The Next.js App Router generates every page from it — no CMS, no database.
- patterns.ts · All 22+ entries
- GitHub Actions · CI / Security / Frontend
- Next.js 16 · App Router + SSG
- Mermaid 11 · Client-side render
- Vercel · Hosting + CDN
- Cloudflare · DNS
- Browser · patterns.moretes.com
Running it locally
- 1
Clone the repository
Use
git clone https://github.com/fernandofatech/aws-pattern-library.gitand enter the directory. - 2
Install dependencies
Navigate into
frontend/and runnpm install. Node 18+ is expected given the Next.js 16 + React 19 stack. - 3
Start the dev server
Run
npm run devinsidefrontend/. The app is available athttp://localhost:3000. Hot reload is active — any change topatterns.tsreflects immediately. - 4
Browse the catalog
Open
/patternsto search and filter. Open/patterns/[slug]for a full pattern view. Use/compareto diff two patterns side by side. - 5
Add a new pattern
All patterns live in
frontend/lib/patterns.ts. Add one entry following the existing shape — every route picks it up automatically on the next render. See CONTRIBUTING.md for the full field spec. - 6
Run CI checks locally
The repo ships three GitHub Actions workflows: CI (lint + type-check), Frontend (build), and Security (dependency audit). You can mirror these locally with
npm run lint,npm run build, andnpm audit.
git clone https://github.com/fernandofatech/aws-pattern-library.git
cd aws-pattern-library/frontend
npm install
npm run dev
# → http://localhost:3000Copying patterns into your own repos
The ADR text and Well-Architected pointers in each pattern are written to be copy-pasted directly into a pull-request description or a docs/adr/ folder. The Mermaid source is plain text — paste it into any tool that renders Mermaid (GitHub Markdown, Notion, Confluence, etc.) and it renders without modification.
Frequently asked questions
Is there a database or CMS behind the catalog?
No. Everything is a TypeScript object in frontend/lib/patterns.ts. Next.js generates static pages from it at build time. There is no runtime data fetching.
How do I contribute a new pattern?
Add one entry to frontend/lib/patterns.ts following the existing structure, then open a pull request. The full field spec is in CONTRIBUTING.md. Every page — listing, detail, compare — picks up the new entry automatically.
Are the cost estimates reliable?
They are rough envelopes with stated assumptions, not AWS Calculator exports. They are useful for early-stage conversations and order-of-magnitude checks, not for budget commitments.
Why Next.js and not a static site generator?
The App Router gives me dynamic routes (/patterns/[slug], /compare) and client-side interactivity (Mermaid rendering, search filtering) without a separate API. It deploys as a static export on Vercel with zero backend.
Who this is for
This repository is useful in three situations. First, if you are a solution architect or senior engineer who regularly writes ADRs and architecture diagrams, the catalog is a starting-point library you can fork and extend with your own team's patterns. Second, if you are onboarding to AWS and want concrete, trade-off-aware examples across a broad range of domains — not just the happy-path tutorials — the patterns give you a more honest picture of how production architectures actually look. Third, if you are evaluating my work as a portfolio piece, the codebase itself demonstrates how I structure a TypeScript/Next.js project, how I approach documentation, and how I think about AWS architecture across ten domains. What it is not: a Terraform module library, a deployable CDK construct, or a replacement for the AWS Well-Architected Tool. It is a documentation artifact — a catalog of decisions, not a catalog of infrastructure code.