Segurança e confiabilidade são pré-requisito de arquitetura AWS, não extra pós-deploy

Uma lista de boas práticas, não um anúncio de produto

Em 31 de outubro de 2026, o AWS Builder Center publicou um texto de comunidade assinado por Robin Kumar, intitulado "Building Production-Ready AWS Infrastructure: Why Security and Reliability Must Come First". É conteúdo de builder, não documentação oficial da AWS, e o próprio Builder Center avisa isso no rodapé. Ainda assim, a lista de cinco pontos que o autor propõe (fundação segura, alta disponibilidade, automação, observabilidade e custo) é um bom mapa do que separa um ambiente que "funciona" de um ambiente pronto pra produção.

O problema é que, descrita assim, em bullet points genéricos, a lista parece checklist de curso introdutório. Para quem desenha arquitetura de verdade, cada item esconde decisões de design que valem muito mais do que a frase de efeito sugere, principalmente quando a região é sa-east-1 e a LGPD entra na conta.

Segurança desde a VPC: least privilege não é feature, é desenho

O autor recomenda IAM roles em vez de access keys de longa duração e segmentação por VPC e subnet. Isso é consenso há anos, mas o ponto que costuma faltar nesse tipo de lista é onde essa decisão se materializa: não é uma tarefa de hardening depois do deploy, é um artefato de infraestrutura como código desde o primeiro commit.

Em um stack CDK ou CloudFormation, isso aparece como:

• Roles com AssumeRolePolicyDocument restrito ao serviço que de fato precisa assumi-la, nunca um * em Principal.
• Permission Boundaries aplicadas a roles criadas por pipelines de CI/CD, para limitar o blast radius de uma automação comprometida.
• Security Groups referenciando outros Security Groups (não CIDR solto), para que a regra sobreviva a mudanças de IP interno.
• Service Control Policies no nível da AWS Organizations, bloqueando ações fora da conta de workload antes mesmo de o IAM da conta entrar em cena.

Nenhum desses pontos está no texto original, e é exatamente aqui que a lista do Builder Center fica rasa: ela descreve o "o quê" (least privilege, VPC segmentada) sem tocar no "onde" isso é imposto como guard rail estrutural, via Organizations, em vez de depender da disciplina de cada time.

Alta disponibilidade em sa-east-1: redundância multi-AZ tem limites regionais

O segundo pilar da fonte é clássico: Application Load Balancer, Auto Scaling Group multi-AZ, RDS Multi-AZ e CloudWatch para alarme. A arquitetura, diz o autor, deve tolerar falha de infraestrutura sem intervenção manual. Verdade, mas vale lembrar que, como qualquer região AWS, São Paulo tem um número finito de zonas de disponibilidade, e isso limita até onde a redundância multi-AZ sozinha resolve o problema.

Na prática, isso significa duas coisas. Primeiro, um Auto Scaling Group bem distribuído entre as zonas disponíveis na região já cobre o cenário de falha de uma AZ inteira, sem exigir o dimensionamento que só faria sentido em regiões com mais zonas disponíveis. Segundo, para workloads que exigem disaster recovery regional (não só zonal), a estratégia de replicação cross-region entra em jogo, e vale desenhar isso desde o início do projeto, não depois de um incidente regional.

Em resumo: HA dentro da região resolve falha de AZ; LGPD e requisitos de negócio que exigem continuidade além da região de origem entram num desenho de DR cross-region que a lista do Builder Center simplesmente não menciona.

Terraform, CDK ou CloudFormation: a automação é só metade da escolha

O autor defende Terraform com state remoto, locking e módulos, o que é correto e é prática de mercado consolidada. Mas para quem trabalha majoritariamente com stack AWS, vale lembrar que a escolha entre Terraform e as ferramentas nativas (CDK, CloudFormation) envolve trade-offs que a fonte não discute, e que pesam na decisão de arquitetura: gestão de state, suporte a serviços novos, linguagem de definição e estratégia multi-conta variam bastante entre as duas abordagens, e cada time acaba pesando isso de acordo com o quanto depende só da AWS ou de múltiplos provedores de nuvem.

Nenhuma das duas é "a certa": times multi-cloud tendem a Terraform pela portabilidade; times AWS-only costumam valorizar a integração nativa das ferramentas da própria AWS. O que não dá é escolher sem discutir esse trade-off, e a lista original trata automação como se fosse uma decisão única e óbvia.

Observabilidade: medir além de "a instância está de pé"

O quarto ponto da fonte está correto na premissa (infraestrutura que não pode ser monitorada não pode ser operada de forma confiável) mas fica vago na prática. CloudWatch metrics, logs e alarmes resolvem o sintoma, não a causa: o ganho real vem de alarmes que correlacionam latência, taxa de erro e utilização antes de acordar alguém às três da manhã, em vez de um alarme por métrica isolada que gera ruído.

Custo como responsabilidade de engenharia, e onde isso cruza com LGPD

O quinto ponto, tratar custo como responsabilidade de engenharia e não só da fatura, é o mais consensual da lista e o menos detalhado. Cost Explorer e Budgets servem para visibilidade, mas a decisão de dimensionamento (right-sizing de instância RDS, lifecycle policy em S3, Reserved Instances versus Savings Plans) é arquitetural, feita no desenho, não corrigida depois com um relatório de gasto.

O que a lista do Builder Center não cobre, e que pesa especificamente para quem opera em sa-east-1, é a camada de conformidade: a LGPD exige rastreabilidade de acesso a dado pessoal, o que normalmente significa CloudTrail habilitado em todas as contas da Organization e AWS Config com conformance packs avaliando criptografia obrigatória em repouso e em trânsito. Nenhum desses itens aparece como "segurança" na lista original, mas são exatamente o tipo de requisito que transforma um ambiente tecnicamente seguro em um ambiente auditável.

O que falta discutir antes de replicar a lista

Os cinco pontos do Builder Center funcionam como índice, não como arquitetura de referência. Faltam, pelo menos, três camadas que normalmente aparecem num Well-Architected Review formal: estratégia de múltiplas contas via AWS Organizations (a lista trata tudo como se fosse uma conta só), disaster recovery cross-region para quem depende de uma única região sem alternativa próxima, e o enquadramento regulatório que a LGPD impõe sobre qualquer decisão de IAM, criptografia e log de acesso.

Nenhuma dessas lacunas invalida os cinco pilares; elas só confirmam o argumento central do próprio texto, mesmo sem explorá-lo: segurança e confiabilidade não são itens de checklist pós-deploy. São decisões de desenho que, em produção, custam caro para revisitar depois.

Fonte

Building Production-Ready AWS Infrastructure: Why Security and Reliability Must Come First, AWS Builder Center, publicado por Robin Kumar em 31 de outubro de 2026.

Fonte: AWS Builder Center