Pular para o conteúdo
fernando.moretes.com
BlogEstudosCursosE-booksOpen SourcePodcasts
Loading…
Fernando Azevedo

Arquiteto de TI Especialista

Arquitetura, AWS, IA em produção, sistemas financeiros e FinOps, escritos a partir do que foi operado, com os números.

  • LinkedIn
  • GitHub
  • E-mail

Conteúdo

  • Blog
  • Estudos de arquitetura
  • Cursos
  • E-books
  • Open Source
  • Podcasts
  • Assuntos
  • Trilhas

Ferramentas

  • Well-Architected self-check
  • Arquitetura deste site
  • Números públicos
  • Histórico de estudo

Sobre

  • Comunidade
  • IA Builder
  • Perfil
  • Currículo (CV)
  • Trabalhe comigo
  • Media kit
  • RSS do blog
  • RSS dos estudos
  • Artigos narrados (podcast)
  • llms.txt
  • Termos, privacidade e uso de IA

(c) 2026 Fernando Francisco Azevedo

Assuntos/Multi-tenant

Outros

Multi-tenant

9 conteúdos publicados sobre este assunto: artigos, estudos de arquitetura e guias de repositório.

Artigos· 3

IA & AgentesCluster de GPU compartilhado no HyperPod: três desenhos e quando cada um valeA AWS publicou uma arquitetura de referência para vários times dividirem um único cluster SageMaker HyperPod EKS, com IAM Identity Center, um domínio SageMaker por time, namespaces e Task Governance. Comparo esse desenho com um cluster por time e com namespaces sem governança, olhando para o que quebra em produção e para quem paga a GPU ociosa.Abrir AWS & CloudBeanstalk Cluster Mode: o postmortem que escrevi antes do incidenteO Elastic Beanstalk ganhou um modo em que ambientes com o mesmo conjunto de subnets compartilham um cluster EKS operado pelo serviço. Isso muda o raio de explosão: um ajuste manual no cluster deixa todos os ambientes dele sem deploy até alguém reverter. Escrevi o postmortem desse incidente antes de ele acontecer, só com comportamento documentado, e listo o que configurar no dia zero.Abrir AWS & CloudAWS Lambda MicroVMs: análise técnica de um novo primitivo serverlessO AWS Lambda MicroVMs preenche uma lacuna real entre funções efêmeras e VMs pesadas, entregando isolamento em nível de hypervisor com latência de retomada quase instantânea e estado preservado por até 8 horas. Como arquiteto que opera ambientes financeiros multi-tenant, vejo potencial genuíno, e armadilhas igualmente reais que precisam ser endereçadas antes de qualquer adoção em produção.Abrir

Estudos de arquitetura· 6

Decisão (ADR)ADR: Executar Código Gerado por IA: Lambda MicroVMs vs. Containers IsoladosDecisão de arquitetura sobre como executar com segurança código gerado por agentes de IA ou submetido por usuários em ambiente multi-tenant, comparando Lambda MicroVMs (lançamento AWS jun/2026), containers efêmeros com gVisor/Firecracker em ECS/EKS e Lambda padrão. A decisão recomendada é Lambda MicroVMs por sessão, orquestrado pelo Bedrock AgentCore, com isolamento em nível de VM sem overhead operacional de virtualização própria.Abrir Decisão (ADR)RAG Multi-Tenant Seguro: ADR para Autorização em Duas CamadasAutorização em RAG multi-tenant não é um detalhe de implementação, é uma decisão arquitetural com consequências diretas em compliance, vazamento de dados entre tenants e superfície de ataque de modelos de linguagem. Neste ADR, documento as forças que me levaram a adotar um padrão de defesa em profundidade com Amazon Verified Permissions e Bedrock Knowledge Bases, as alternativas que descartei e as consequências operacionais que precisam ser gerenciadas.Abrir Decisão (ADR)ADR: OpenSearch Serverless vs Banco Vetorial Dedicado para RAG AgênticoEste ADR avalia as opções de infraestrutura de busca vetorial para uma plataforma RAG agêntica multi-tenant na AWS, comparando OpenSearch Serverless, bancos vetoriais dedicados (Pinecone, pgvector) e busca híbrida própria. A decisão considera custo, latência p99, filtros por permissão, ingestão incremental e integração nativa com Bedrock Knowledge Bases.Abrir Design Doc / RFCDesign Doc: EKS Multi-Tenant em Escala: Karpenter, Isolamento e CustoEste documento descreve a arquitetura de uma plataforma EKS multi-tenant para dezenas de equipes, cobrindo isolamento de workloads via namespaces, network policies e RBAC, autoscaling e consolidação com Karpenter usando Spot, e alocação de custo por tenant via Kubecost. O objetivo é operar com segurança, previsibilidade de custo e eficiência de infraestrutura sem sacrificar a autonomia das equipes.Abrir TeardownNotion: O Modelo de Blocos e o Sharding do PostgresO Notion cresceu de um banco Postgres monolítico para uma arquitetura shardada horizontalmente, particionando dados por tenant para sustentar crescimento explosivo durante a pandemia. Este teardown reconstrói as decisões de modelagem, o processo de migração e os trade-offs reais de operar Postgres em escala.Abrir TeardownShopify: Arquitetura de Pods para Escalar na Black FridayA Shopify redesenhou sua infraestrutura monolítica em torno de pods isolados e sharding de banco de dados para sobreviver aos picos extremos da BFCM sem degradação global. Este teardown reconstrói a arquitetura, examina as decisões de trade-off e avalia o que eu faria diferente com base em 16 anos operando sistemas de missão crítica.Abrir