Uma Organização ou Várias? O Postmortem que Ninguém Quer Escrever

A pressão veio de cima. O CFO queria visibilidade consolidada de custos, o CISO queria um único ponto de aplicação de políticas, e a equipe de plataforma, já sobrecarregada, queria reduzir o número de pipelines de automação de landing zone. A solução óbvia pareceu ser: uma Organization, múltiplas OUs, SCPs hierárquicas. O raciocínio era defensável em um whiteboard.

O problema começou quando a equipe de segurança precisou bloquear o acesso a determinadas regiões AWS para conformidade com LGPD/GDPR. A SCP foi redigida com uma condição aws:RequestedRegion negando todas as regiões fora de sa-east-1 e us-east-1. O teste foi feito em uma OU de sandbox. A aprovação foi dada. O deploy foi feito no nó raiz, não na OU de produção, no raiz.

O que ninguém havia mapeado explicitamente: a conta de pagamentos usava us-east-2 para um endpoint de DynamoDB Global Tables que servia como réplica de leitura de baixa latência. A SCP bloqueou as chamadas dynamodb:GetItem e dynamodb:Query originadas de Lambda functions nessa conta para aquela região. O SDK do Python (boto3) com retry exponencial mascarou o erro por cerca de 8 minutos antes de o circuit breaker do serviço de autorização de pagamentos disparar. O alerta chegou via CloudWatch Alarm com threshold de erro de 5xx no API Gateway, mas o runbook apontava para o serviço de autorização, não para a camada de dados.

Existe uma narrativa dominante de que múltiplas Organizations aumentam a complexidade operacional, e ela é parcialmente verdadeira. Mas ela obscurece o que realmente está sendo trocado. Em uma única Organization, o nó raiz e as OUs de nível superior são superfícies de ataque para mudanças de política com propagação instantânea e sem mecanismo nativo de rollback progressivo. O AWS Organizations não tem o conceito de "deploy canário de SCP". Quando você aplica uma SCP no Root, ela entra em vigor imediatamente para todas as ~100, ~500 ou ~2000 contas sob aquele root.

Em ambientes financeiros com múltiplos regimes regulatórios: PCI-DSS para pagamentos, SOC 2 para operações de dados, BACEN 4.893 para resiliência cibernética no Brasil, a tentação de usar uma única Organization com OUs especializadas é compreensível. A realidade operacional é que os controles de compliance para PCI-DSS exigem isolamento de rede e de política que é mais limpo quando há um Organization boundary real, não apenas um OU boundary.

O Organization boundary oferece: (1) políticas de SCP com lifecycle completamente independente; (2) contas de Management Account separadas, reduzindo o raio de comprometimento de credenciais de alto privilégio; (3) billing consolidado ainda disponível via AWS Organizations trusted access e Cost and Usage Report cross-account; (4) CloudTrail Lake com delegated administrator que pode agregar logs de múltiplas Organizations em um único data store S3 com Athena, mantendo a visibilidade centralizada sem o acoplamento de políticas.

O custo real de múltiplas Organizations é a duplicação de automação de landing zone, e esse custo é endereçável com Account Vending Machine baseada em Control Tower customizations e pipelines de IaC compartilhados via CodePipeline cross-account.

A remediação não foi simplesmente "mover pagamentos para uma nova Organization". Isso teria levado semanas e exigido re-onboarding de dezenas de contas. A remediação foi em camadas, com impacto imediato primeiro e refatoração estrutural depois.

Imediato (semana 1): Implementamos uma SCP de guardrail no nó raiz que nega explicitamente organizations:AttachPolicy para qualquer target que seja o Root ID (r-xxxx) ou qualquer OU de nível 1 que contenha cargas de trabalho de produção. A condição usa aws:ResourceTag em combinação com uma tag Environment=Production aplicada nas OUs via Organizations tag policy. Isso não resolve o problema estrutural, mas adiciona uma camada de proteção contra o erro específico que ocorreu. O pipeline Terraform foi atualizado com um precondition que valida o target type antes de qualquer attach-policy.

Médio prazo (meses 2-3): Criamos uma segunda AWS Organization para cargas de trabalho PCI-DSS. A conta de Management Account da nova org usa MFA com hardware token e acesso restrito a dois engenheiros sênior. As SCPs da nova org são gerenciadas por um pipeline separado com aprovação obrigatória de dois revisores via pull request. O CloudTrail Lake foi configurado com um Event Data Store cross-organization usando a funcionalidade de organizationEnabled + delegated administrator, agregando eventos de ambas as orgs em um único repositório Athena.

Observabilidade: Adicionamos um EventBridge rule na conta de Management Account de cada org que captura organizations.amazonaws.com events do tipo AttachPolicy e DetachPolicy e publica em um SNS topic com assinatura para o canal de segurança no Slack e para o PagerDuty. O MTTD para esse tipo de mudança caiu de ~31 minutos (tempo que levou para correlacionar no incidente) para menos de 2 minutos nos testes de validação pós-implementação.

Uma das descobertas mais importantes do postmortem foi que a equipe havia tratado SCPs como código de infraestrutura comum, com o mesmo pipeline de deploy de um security group ou de uma IAM role. Isso é um erro de modelo mental.

SCPs são políticas de controle de acesso com propagação imediata e sem mecanismo nativo de rollback progressivo. Não existe aws organizations deploy-policy --canary 10%. Quando você faz attach-policy em uma OU com 200 contas, todas as 200 contas são afetadas simultaneamente. O AWS Organizations não tem o conceito de deployment rings para políticas.

A implicação prática é que o processo de mudança de SCP deve ser tratado como um change de nível de banco de dados em produção, com janela de manutenção, aprovação dupla, e um plano de rollback testado. O plano de rollback para SCP é simples: detach-policy. Mas se você não sabe qual policy estava antes, ou se a mudança foi composta de múltiplas operações, o rollback pode não ser trivial.

O que implementamos: um registro imutável de estado de SCPs por OU/Root, armazenado em S3 com versionamento habilitado e Object Lock em modo COMPLIANCE por 90 dias. Antes de qualquer attach-policy, o pipeline salva o estado atual. O rollback automatizado é um Lambda que lê o estado anterior do S3 e executa as operações inversas. O tempo de rollback automatizado nos testes foi de 45 segundos, comparado aos 7 minutos que levou no incidente real para identificar e executar manualmente.

Um detalhe frequentemente ignorado: SCPs com Deny explícito têm precedência sobre qualquer Allow em políticas de identidade, incluindo políticas de IAM Role com AdministratorAccess. Isso significa que nem mesmo o root user da conta (se não estiver explicitamente excluído via aws:PrincipalType: Root) consegue executar ações bloqueadas por uma SCP. Em nosso incidente, isso foi o que tornou a situação tão severa, não havia escape hatch na conta de pagamentos.

O argumento mais comum contra múltiplas Organizations é a perda de visibilidade consolidada de custos. Esse argumento era válido em 2018. Em 2024, é um problema resolvido, com algumas ressalvas importantes.

O AWS Cost and Usage Report (CUR 2.0) pode ser configurado com entrega para um S3 bucket centralizado em uma conta de billing dedicada, mesmo para múltiplas Organizations, usando um padrão de cross-account S3 bucket policy com s3:PutObject permitido para o service principal billingreports.amazonaws.com de múltiplos account IDs de Management Account. O Athena + AWS Glue Crawler sobre esses dados produz uma visão unificada de custos que o CFO pode consumir via QuickSight com row-level security por unidade de negócio.

O que não é resolvido nativamente: Reserved Instances e Savings Plans não são compartilhados entre Organizations. Esse é um custo real. Em nossa análise, a conta de pagamentos usava aproximadamente $18k/mês em Compute Savings Plans que, ao mover para uma nova Organization, não podiam mais ser compartilhados com as contas de tooling da org original. A solução foi consolidar os Savings Plans na nova org de pagamentos e usar On-Demand para as cargas de trabalho de tooling que têm uso mais variável, o delta de custo foi de aproximadamente $1.2k/mês, que foi aceito como custo de isolamento regulatório.

Um padrão que recomendo: use AWS Cost Categories com regras baseadas em tags de CostCenter e BusinessUnit aplicadas via tag policies em ambas as Organizations. Isso permite que o relatório financeiro seja agnóstico à topologia de Organizations, o CFO vê por centro de custo, não por org.