# aws-event-driven-finops-platform Arquitetura de referência event-driven para banking na AWS, com FinOps, segurança e frontend ao vivo. - URL: https://fernando.moretes.com/open-source/aws-event-driven-finops-platform - Markdown: https://fernando.moretes.com/open-source/aws-event-driven-finops-platform/guide.md?lang=pt - GitHub: https://github.com/fernandofatech/aws-event-driven-finops-platform - Homepage: https://finops.moretes.com - Language: HTML - Topics: ai, aws, banking, devsecops, event-driven-architecture, eventbridge, finops, kinesis, moretes, msk, portfolio, solution-architecture, sqs, vercel - Stars: 1 - Forks: 0 - Updated: 2026-05-16T02:23:21Z --- aws-event-driven-finops-platform é uma arquitetura de referência bilíngue que modela um event mesh bancário realista na AWS, tratando deliberadamente custo, segurança e observabilidade como restrições arquiteturais de primeira classe, ao lado dos requisitos funcionais tradicionais. ## O que é este repositório e por que o construí A maioria dos demos event-driven para por aí: "publica uma mensagem, consome uma mensagem." Este vai além. O cenário fictício é uma plataforma bancária brasileira que processa eventos de domínio — `AccountOpened`, `PixPaymentRequested`, `TransactionAuthorized`, `FraudRiskScored`, `StatementGenerated` — e a arquitetura precisa justificar *qual* primitiva de mensageria da AWS trata cada um e *por quê*. Essa justificativa é o ponto central. EventBridge, SQS, Kinesis Data Streams e MSK não são intercambiáveis. Cada um carrega um modelo de custo diferente, garantia de ordenação, capacidade de replay e superfície operacional. Documento essas trocas explicitamente em Architecture Decision Records (ADRs) dentro de `docs/architecture.md`, para que o leitor possa acompanhar o raciocínio em vez de apenas copiar a topologia. O repositório também serve como artefato de portfólio. É bilíngue (inglês e português), tem um frontend estático implantado no Vercel em [finops.moretes.com](https://finops.moretes.com) e executa um pipeline de segurança completo — CodeQL, Trivy, Gitleaks, revisão de dependências e npm audit — a cada push. O objetivo é demonstrar disciplina de nível produtivo em um projeto que não tem tráfego real para se esconder atrás. ## Visão geral da arquitetura Eventos de domínio originam-se de operações bancárias e são roteados por primitivas de mensageria AWS escolhidas por seus trade-offs específicos. O frontend estático visualiza a arquitetura e é implantado de forma independente no Vercel. ### 🏦 Banking Domain - Event Producer (banking ops) (edge) ### ☁️ AWS Event Mesh - EventBridge domain routing (messaging) - SQS buffering & decoupling (messaging) - Kinesis Data Streams ordered streaming (messaging) - MSK (Kafka) high-volume workloads (messaging) - Lambda / Step Functions (compute) - DynamoDB idempotency & state (storage) - CloudWatch + X-Ray (security) ### 🔒 Security Pipeline - GitHub Actions CodeQL · Trivy · Gitleaks (ci) ### 🌐 Frontend - Vercel finops.moretes.com (frontend) ### Fluxos - producer -> eventbridge: evento de domínio - eventbridge -> sqs: baixo volume / desacoplado - eventbridge -> kinesis: stream ordenado - eventbridge -> msk: Kafka alto volume - sqs -> lambda: trigger - kinesis -> lambda: consumidor de stream - msk -> lambda: consumidor Kafka - lambda -> dynamodb: verificação de idempotência - lambda -> observability: traces e métricas - ci -> vercel: deploy no merge ## O que torna esta arquitetura digna de estudo - Justificativa explícita de seleção de serviços: cada primitiva de mensageria (EventBridge, SQS, Kinesis, MSK) é escolhida com trade-offs documentados, não selecionada arbitrariamente. - FinOps como restrição: o custo é tratado como requisito arquitetural desde o início, influenciando qual serviço trata qual volume de eventos. - Documentação orientada por ADR: Architecture Decision Records capturam o 'porquê' de cada escolha significativa, tornando o repositório útil para aprendizado, não apenas para cópia. - Pipeline de segurança automatizado: CodeQL, Trivy, Gitleaks, revisão de dependências e npm audit executam a cada push via GitHub Actions. - Frontend ao vivo no Vercel: o site estático em finops.moretes.com demonstra a arquitetura visualmente e mantém o portfólio acessível sem precisar provisionar recursos AWS. - Lógica de decisão testada: a camada Python inclui testes para a lógica de roteamento e idempotência, então a arquitetura não é apenas um diagrama. ## Como a camada FinOps realmente funciona FinOps neste contexto não é um dashboard adicionado depois do fato. O modelo de custo está embutido na própria lógica de seleção de serviços. A questão central que a arquitetura responde é: dado um evento de domínio bancário, qual primitiva de mensageria minimiza o custo enquanto ainda atende aos requisitos de ordenação, durabilidade e throughput do evento? - **EventBridge** trata o roteamento de eventos de domínio de baixa frequência, onde o preço por evento é aceitável e o schema registry e as capacidades de filtragem agregam valor. - **SQS** absorve cargas de trabalho que precisam de buffering e entrega at-least-once, mas não requerem ordenação estrita — mais barato que Kinesis em baixo throughput. - **Kinesis Data Streams** assume quando a ordenação dentro de um shard importa (ex.: sequências de `TransactionAuthorized` por conta) e o throughput justifica o custo de shard-hour. - **MSK** é reservado para cargas de trabalho de alto volume, compatíveis com Kafka, onde o overhead operacional de um cluster Kafka gerenciado é justificado pelo volume e compatibilidade de ecossistema. Essa abordagem em camadas significa que a arquitetura escala o custo linearmente com a carga real, em vez de pagar por infraestrutura de nível Kafka em cada tipo de evento. Os ADRs em `docs/architecture.md` quantificam os pontos de equilíbrio. ## Instalando e executando localmente 1. **Clone o repositório** — Clone do GitHub e entre no diretório raiz do projeto. Você precisará de Python 3.9+ e Node.js 18+ instalados. 2. **Instale as dependências Python e execute os testes** — A flag `-e .` instala o pacote em modo editável para que o conjunto de testes possa importar a lógica de decisão. `pytest -q` fornece um resumo compacto de aprovação/falha. 3. **Instale as dependências do frontend e faça o build** — O frontend está em `frontend/`. `npm ci` garante uma instalação reproduzível a partir do lockfile. `npm run lint` detecta problemas antes de `npm run build` produzir a saída estática. 4. **Revise a documentação de arquitetura** — Abra `docs/architecture.md` para os ADRs e a justificativa de seleção de serviços. Abra `OPERATIONS.md` para convenções GitFlow, segredos de deployment no Vercel e a configuração do pipeline de segurança. 5. **Faça o deploy do frontend no Vercel (opcional)** — Conecte o repositório a um projeto Vercel, defina o diretório raiz como `frontend/` e configure os segredos documentados em `OPERATIONS.md`. Merges para `main` disparam deploys automáticos. _Setup local completo — testes Python e build do frontend_ ```bash # Clone git clone https://github.com/fernandofatech/aws-event-driven-finops-platform.git cd aws-event-driven-finops-platform # Python layer — install in editable mode and run tests python -m pip install -e . pytest pytest -q # Frontend layer cd frontend npm ci npm run lint npm run build # Review architecture decisions open docs/architecture.md # or: cat docs/architecture.md open OPERATIONS.md ``` > **Por que o frontend é intencionalmente estático:** O diretório `frontend/` é um site estático com dependências mínimas, não um SPA React com uma árvore de 200 pacotes de dependências. Esta é uma decisão deliberada de FinOps e segurança: zero latência de cold-start na CDN do Vercel, superfície de ataque mínima para o pipeline de segurança escanear e sem custo de runtime. A visualização da arquitetura não precisa de um backend — precisa ser rápida e sempre disponível. ## Perguntas frequentes ### Isso implanta infraestrutura AWS real? Não. Este é um projeto de arquitetura de referência e portfólio. A camada Python contém a lógica de decisão e roteamento com testes, mas não há templates de IaC (CDK, Terraform, CloudFormation) que provisionem recursos AWS reais. O valor está nos trade-offs documentados e na lógica testada, não em um deploy com um clique. ### Por que modelar especificamente um domínio bancário? Eventos bancários têm requisitos naturalmente variados: alguns precisam de ordenação estrita (sequências de transações), alguns precisam de alto throughput (scoring de fraude em escala), alguns precisam de entrega confiável at-least-once (geração de extratos). Essa variedade o torna uma função forçadora útil para demonstrar por que você não usaria uma única primitiva de mensageria para tudo. ### Qual é o propósito da tabela DynamoDB? Idempotência e estado de evento. Em um modelo de entrega at-least-once, os consumidores devem ser capazes de detectar e descartar com segurança eventos duplicados. As escritas condicionais do DynamoDB o tornam um armazenamento de idempotência prático — a arquitetura documenta o esquema de chave e a estratégia de TTL utilizada. ### Posso contribuir ou adaptar isso para meu próprio portfólio? O repositório é público. A orientação de contribuição e as convenções GitFlow estão em `OPERATIONS.md`. Se você adaptá-lo, peço que documente seu próprio raciocínio de trade-off em vez de copiar os ADRs literalmente — o raciocínio é o artefato de portfólio, não a topologia. ## Para quem é e quando usar Este repositório é útil em três situações. Primeiro, se você é um engenheiro avaliando primitivas de mensageria AWS para um projeto real e quer um exemplo trabalhado com trade-offs documentados em vez de uma tabela de comparação de fornecedores. Segundo, se você é um gerente de contratação ou entrevistador técnico avaliando como um arquiteto de soluções pensa sobre custo, segurança e observabilidade como restrições arquiteturais — os ADRs e o conjunto de testes são a evidência. Terceiro, se você está construindo seu próprio portfólio de arquitetura e quer um template estrutural que vai além de diagramas: documentação bilíngue, um pipeline de segurança, um frontend ao vivo e lógica testada no mesmo repositório. Não é um kit de deployment pronto para produção. Não há templates de IaC, gerenciamento de configuração específico por ambiente, nem runbooks operacionais além do que está em `OPERATIONS.md`. Trate-o como uma referência detalhada e uma ferramenta de raciocínio, não como infraestrutura que você pode fazer fork e implantar sem alterações. ## Links - [GitHub — fernandofatech/aws-event-driven-finops-platform](https://github.com/fernandofatech/aws-event-driven-finops-platform) - [Live site — finops.moretes.com](https://finops.moretes.com) - [AWS EventBridge documentation](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) - [AWS SQS documentation](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) - [Amazon Kinesis Data Streams documentation](https://docs.aws.amazon.com/streams/latest/dev/introduction.html) - [Amazon MSK documentation](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) - [FinOps Foundation — FinOps Framework](https://www.finops.org/framework/) - [Author — Fernando Francisco Azevedo](https://fernando.moretes.com) ## Links - [GitHub repository](https://github.com/fernandofatech/aws-event-driven-finops-platform) - [Homepage](https://finops.moretes.com)