# aws-pattern-library 22+ arquiteturas AWS com diagramas, ADRs e notas de custo — prontas para copiar. - URL: https://fernando.moretes.com/open-source/aws-pattern-library - Markdown: https://fernando.moretes.com/open-source/aws-pattern-library/guide.md?lang=pt - GitHub: https://github.com/fernandofatech/aws-pattern-library - Language: TypeScript - Topics: - Stars: 0 - Forks: 0 - Updated: 2026-05-16T02:08:25Z --- AWS Pattern Library é um catálogo versionado e pesquisável com 22+ arquiteturas de referência AWS — cada uma acompanhada de diagrama Mermaid, ADR, pontos do Well-Architected Framework e estimativa de custo, navegável por um frontend Next.js publicado em patterns.moretes.com. ## Por que construí isso Todo arquiteto de soluções que conheço — inclusive eu — já reconstruiu o mesmo diagrama de fan-out com EventBridge ou o mesmo ADR de data lake em S3 pelo menos uma dúzia de vezes em diferentes clientes e equipes. O conhecimento existe, mas vive em slides, páginas de Confluence e na cabeça das pessoas. Nenhum desses lugares é versionado, pesquisável ou fácil de copiar na descrição de um pull request. Esta biblioteca é minha resposta a esse problema. Queria um único lugar onde um padrão AWS recorrente fosse capturado *uma vez*, com contexto suficiente para ser imediatamente útil: qual problema resolve, quais serviços estão envolvidos, quais trade-offs a arquitetura codifica, quais pilares do Well-Architected são tocados e um envelope de custo aproximado com premissas declaradas. O formato ADR (contexto → decisão → consequências) é intencional — ele me obriga a documentar o *porquê*, não apenas o *quê*. O objetivo secundário é pedagógico. Arquitetos e engenheiros juniores que entram em uma equipe frequentemente carecem do vocabulário para avaliar trade-offs. Um catálogo que já codifica esses trade-offs dá a eles um ponto de partida honesto sobre as desvantagens, não apenas o caminho feliz. ## O que cada padrão inclui - **Diagrama Mermaid** renderizado no cliente — sem hospedagem externa de imagens, sem PNGs desatualizados. - **ADR (Architecture Decision Record)** em formato compatível com MADR: contexto, decisão, consequências. - **Lista de serviços** com links diretos para que os leitores possam acessar a documentação AWS relevante. - **Pontos do Well-Architected** nos seis pilares: Excelência Operacional, Segurança, Confiabilidade, Performance, Custo, Sustentabilidade. - **Estimativa de custo com premissas declaradas** — não uma promessa vaga, mas um envelope aproximado que você pode verificar. - **Comparação lado a lado** pela rota `/compare` — escolha dois padrões e compare pilares e serviços. ## Cobertura em dez domínios Os 22+ padrões cobrem os cenários que encontro com mais frequência em projetos de produção: - **Web** — app três camadas, SPA estático, WordPress gerenciado. - **API** — REST serverless com API Gateway + Lambda, GraphQL gerenciado com AppSync. - **Data** — data lake em S3, lakehouse com Apache Iceberg. - **Events** — microsserviços orientados a eventos, sagas com Step Functions, pipelines de streaming com MSK. - **ML / AI** — inferência em tempo real, inferência em batch, GenAI RAG com Amazon Bedrock. - **IoT** — ingestão de telemetria em escala via IoT Core. - **Security** — rotação de segredos com Secrets Manager, postura com GuardDuty + Security Hub. - **DevOps** — deploys blue/green, baseline de plataforma EKS, CI/CD com CodePipeline. - **Hybrid / Networking** — malha VPC multi-conta com Transit Gateway, DR cross-region. - **Batch** — AWS Batch com EC2 Spot para compute otimizado em custo. O catálogo é intencionalmente amplo em vez de profundo. Cada entrada é um ponto de partida — uma decisão documentada que uma equipe pode adotar, adaptar ou explicitamente rejeitar. O objetivo não é ser prescritivo; é tornar a conversa mais rápida, dando a todos um vocabulário comum e um artefato concreto para anotar. ## Como o catálogo funciona de ponta a ponta Um único arquivo TypeScript (patterns.ts) é a fonte da verdade. O App Router do Next.js gera todas as páginas a partir dele — sem CMS, sem banco de dados. ### 📝 Source of Truth - patterns.ts All 22+ entries (data) ### ⚙️ Build & CI - GitHub Actions CI / Security / Frontend (ci) - Next.js 16 App Router + SSG (frontend) - Mermaid 11 Client-side render (frontend) ### 🌐 Delivery - Vercel Hosting + CDN (edge) - Cloudflare DNS (network) ### 👤 User - Browser patterns.moretes.com (user) ### Fluxos - patterns_ts -> nextjs: importado no build - gh_actions -> nextjs: executa build e lint - nextjs -> mermaid: string do diagrama passada - nextjs -> vercel: deploy no push - vercel -> cloudflare: resolução DNS - cloudflare -> browser: serve páginas - browser -> mermaid: renderiza diagrama no cliente ## Executando localmente 1. **Clone o repositório** — Use `git clone https://github.com/fernandofatech/aws-pattern-library.git` e entre no diretório. 2. **Instale as dependências** — Navegue até `frontend/` e execute `npm install`. Node 18+ é esperado dado o stack Next.js 16 + React 19. 3. **Inicie o servidor de desenvolvimento** — Execute `npm run dev` dentro de `frontend/`. O app fica disponível em `http://localhost:3000`. Hot reload está ativo — qualquer alteração em `patterns.ts` reflete imediatamente. 4. **Navegue pelo catálogo** — Abra `/patterns` para pesquisar e filtrar. Abra `/patterns/[slug]` para ver um padrão completo. Use `/compare` para comparar dois padrões lado a lado. 5. **Adicione um novo padrão** — Todos os padrões vivem em `frontend/lib/patterns.ts`. Adicione uma entrada seguindo a estrutura existente — todas as rotas a capturam automaticamente no próximo render. Veja CONTRIBUTING.md para a especificação completa dos campos. 6. **Execute as verificações de CI localmente** — O repositório inclui três workflows do GitHub Actions: CI (lint + type-check), Frontend (build) e Security (auditoria de dependências). Você pode espelhar isso localmente com `npm run lint`, `npm run build` e `npm audit`. _Quickstart — do clone ao servidor de desenvolvimento_ ```bash git clone https://github.com/fernandofatech/aws-pattern-library.git cd aws-pattern-library/frontend npm install npm run dev # → http://localhost:3000 ``` > **Copiando padrões para seus próprios repositórios:** O texto do ADR e os pontos do Well-Architected em cada padrão foram escritos para serem copiados diretamente em uma descrição de pull request ou em uma pasta `docs/adr/`. O código-fonte Mermaid é texto simples — cole em qualquer ferramenta que renderize Mermaid (GitHub Markdown, Notion, Confluence, etc.) e ele renderiza sem modificação. ## Perguntas frequentes ### Existe um banco de dados ou CMS por trás do catálogo? Não. Tudo é um objeto TypeScript em `frontend/lib/patterns.ts`. O Next.js gera páginas estáticas a partir dele no momento do build. Não há busca de dados em tempo de execução. ### Como contribuo com um novo padrão? Adicione uma entrada em `frontend/lib/patterns.ts` seguindo a estrutura existente e abra um pull request. A especificação completa dos campos está em CONTRIBUTING.md. Todas as páginas — listagem, detalhe, comparação — capturam a nova entrada automaticamente. ### As estimativas de custo são confiáveis? São envelopes aproximados com premissas declaradas, não exportações do AWS Calculator. São úteis para conversas em estágios iniciais e verificações de ordem de grandeza, não para compromissos orçamentários. ### Por que Next.js e não um gerador de site estático? O App Router me dá rotas dinâmicas (`/patterns/[slug]`, `/compare`) e interatividade no cliente (renderização Mermaid, filtragem de busca) sem uma API separada. É implantado como exportação estática no Vercel sem backend. ## Para quem é isso Este repositório é útil em três situações. Primeiro, se você é um arquiteto de soluções ou engenheiro sênior que regularmente escreve ADRs e diagramas de arquitetura, o catálogo é uma biblioteca de ponto de partida que você pode fazer fork e estender com os padrões da sua própria equipe. Segundo, se você está ingressando no AWS e quer exemplos concretos e conscientes de trade-offs em uma ampla gama de domínios — não apenas os tutoriais do caminho feliz — os padrões oferecem uma visão mais honesta de como as arquiteturas de produção realmente parecem. Terceiro, se você está avaliando meu trabalho como parte de portfólio, o próprio codebase demonstra como estruturo um projeto TypeScript/Next.js, como abordo documentação e como penso sobre arquitetura AWS em dez domínios. O que não é: uma biblioteca de módulos Terraform, um construct CDK implantável ou um substituto para o AWS Well-Architected Tool. É um artefato de documentação — um catálogo de decisões, não um catálogo de código de infraestrutura. ## Links - [GitHub — fernandofatech/aws-pattern-library](https://github.com/fernandofatech/aws-pattern-library) - [Live site — patterns.moretes.com](https://patterns.moretes.com) - [Project architecture docs](https://github.com/fernandofatech/aws-pattern-library/blob/main/docs/architecture.md) - [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) - [MADR — Markdown Architectural Decision Records](https://adr.github.io/madr/) - [Mermaid — Diagramming and charting tool](https://mermaid.js.org/) - [Next.js App Router docs](https://nextjs.org/docs/app) ## Links - [GitHub repository](https://github.com/fernandofatech/aws-pattern-library)