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

A decisão entre uma única AWS Organization e múltiplas organizações parece estratégica no papel, mas se torna operacional no pior momento possível — durante um incidente. Este artigo reconstrói o padrão de falha mais comum que observo em ambientes financeiros e propõe remediações concretas baseadas nos pilares do AWS Well-Architected.

- URL: https://fernando.moretes.com/blog/aws-organizations-single-ou-multi-org-com-governanca

- Markdown: https://fernando.moretes.com/blog/aws-organizations-single-ou-multi-org-com-governanca/article.md?lang=pt

- Published: 2026-05-25T00:00:00.000Z

- Category: AWS & Cloud

- Tags: aws-organizations, landing-zone, governance, iam, finops, security, multi-account, scp

- Reading time: 9 min

- Source: [Single versus multiple AWS Organizations](https://aws.amazon.com/blogs/architecture/)

---

Em algum momento de 2023, uma instituição financeira de médio porte com a qual trabalhei consolidou todas as suas unidades de negócio sob uma única AWS Organization para simplificar a governança de custos. Dezoito meses depois, um erro de Service Control Policy aplicado no nó raiz silenciou o pipeline de pagamentos em produção por 47 minutos. O postmortem revelou algo que a maioria dos arquitetos sabe intuitivamente mas raramente documenta com rigor: a topologia de Organizations não é uma decisão de FinOps — é uma decisão de blast radius.

## O Que Aconteceu: Contexto e Pressão Organizacional

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.

## Linha do Tempo do Incidente

1. **T+00:00 — SCP aplicada no nó raiz** — Engenheiro de segurança executa `aws organizations attach-policy` apontando para Root ID em vez do OU ID de sandbox. Nenhuma validação de escopo no pipeline de IaC (Terraform) bloqueou a operação — a policy já existia, apenas o target mudou.

2. **T+00:08 — Primeiros erros silenciosos no SDK** — O boto3 com `max_attempts=5` e backoff exponencial começa a absorver `AccessDeniedException` das chamadas DynamoDB em `us-east-2`. O Lambda timeout de 15s ainda não foi atingido. Nenhum alarme ativo.

3. **T+00:11 — Circuit breaker dispara no serviço de autorização** — O serviço de autorização de pagamentos, implementado em EKS com Resilience4j, abre o circuit após 10 falhas consecutivas em 30s. Transações começam a retornar HTTP 503 para o API Gateway.

4. **T+00:14 — Alarme CloudWatch dispara** — Alarm `PaymentAPI-5xxRate > 1%` envia notificação para SNS → PagerDuty. On-call engineer recebe o alerta. Runbook inicial aponta para o serviço de autorização EKS.

5. **T+00:22 — Diagnóstico incorreto inicial** — Engineer verifica pods EKS, logs do Resilience4j, métricas de CPU/memória. Tudo normal. Escalona para o tech lead. Nenhuma correlação com CloudTrail ainda.

6. **T+00:31 — Correlação com CloudTrail e Organizations** — Tech lead consulta CloudTrail Lake com query Athena filtrando `errorCode = AccessDeniedException` nos últimos 60 minutos. Identifica padrão em chamadas DynamoDB de `us-east-2`. Cruza com Organizations API e encontra o attach-policy no Root.

7. **T+00:38 — SCP removida do nó raiz** — Engenheiro de segurança sênior executa `aws organizations detach-policy`. Propagação da mudança leva aproximadamente 4 minutos para todas as contas afetadas.

8. **T+00:47 — Serviço restaurado** — Circuit breaker fecha após health checks bem-sucedidos. Taxa de erro retorna a < 0.1%. Incidente encerrado. Duração total: 47 minutos de degradação parcial, 36 minutos de indisponibilidade completa para novos pagamentos.

> **Causa Raiz: Blast Radius Irrestrito por Design:** A causa raiz não foi o erro humano de apontar para o nó raiz — erros humanos são inevitáveis. A causa raiz foi arquitetural: uma única AWS Organization sem boundary de isolamento entre cargas de trabalho reguladas (pagamentos, PCI-DSS) e cargas de trabalho operacionais (segurança, tooling). Qualquer SCP aplicada no Root afeta **todas** as contas simultaneamente, sem staging, sem canary, sem rollback automático. O design transformou uma mudança de política de segurança rotineira em um change com raio de explosão de nível organizacional. Em ambientes financeiros, isso é inaceitável.

## Topologia: Single-Org com Blast Radius vs. Multi-Org com Isolamento

O diagrama compara o padrão que causou o incidente (esquerda) com a arquitetura remediada (direita). As bordas vermelhas indicam propagação irrestrita de SCP; as bordas verdes indicam boundary de isolamento com promoção controlada.

### 🔴 Padrão Problemático — Single Org / Problematic Pattern — Single Org

- Root Management Account (security)
- SCP: DenyRegion applied at Root (security)
- OU: Security Tooling Accounts (security)
- OU: Payments PCI-DSS Accounts (compute)
- DynamoDB us-east-2 replica (data)

### 🟢 Padrão Remediado — Multi-Org com Isolamento / Remediated Pattern — Multi-Org

- Org: Operations Security & Tooling (security)
- Org: Payments PCI-DSS Boundary (compute)
- SCP: DenyRegion scoped to Ops Org (security)
- SCP: PCI Controls independent lifecycle (security)
- RAM / PrivateLink cross-org sharing (network)
- CloudTrail Lake centralized (delegated) (data)

### Fluxos

- scp-bad -> root: anexada no Root
- root -> ou-sec: herança irrestrita
- root -> ou-pay: blast radius total
- ou-pay -> ddb-replica: bloqueado pela SCP
- scp-ops -> org-ops: escopo isolado
- scp-pay -> org-pay: ciclo independente
- org-ops -> ram-share: compartilhamento controlado
- org-pay -> ram-share: acesso via PrivateLink
- org-ops -> ct-lake: logs delegados
- org-pay -> ct-lake: logs delegados

## Por Que a Decisão Single-Org vs. Multi-Org É Fundamentalmente uma Decisão de Isolamento

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.

## Remediação Técnica: O Que Mudamos Depois do Incidente

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.

## Single-Org vs. Multi-Org: Trade-offs Reais
| Critério | Dimensão | Single Organization | Multiple Organizations |
| --- | --- | --- | --- |
| Blast radius de SCP | Root afeta 100% das contas instantaneamente | Isolado por Organization boundary; mudanças são independentes | — |
| Complexidade operacional | Menor: um único pipeline de landing zone, um Control Tower | Maior: múltiplos pipelines, múltiplos Control Tower enrollments | — |
| Visibilidade de custos | Nativa via Consolidated Billing | Requer CUR cross-account + Athena ou AWS Cost Explorer linked accounts | — |
| Isolamento regulatório (PCI, SOC2) | Possível via OUs, mas policy boundary é lógico, não físico | Boundary físico entre orgs; auditores aceitam mais facilmente | — |
| Comprometimento de Management Account | Uma conta comprometida = acesso potencial a toda a organização | Raio limitado à org específica; outras orgs não afetadas | — |
| Latência de propagação de SCP | Segundos a poucos minutos para todas as contas | Mesmo comportamento dentro de cada org; orgs são independentes | — |

## O Problema Real com SCPs: Sem Staging, Sem Rollback Automático

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.

## FinOps em Multi-Org: O Argumento que Derruba a Resistência

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.

## AWS Well-Architected: Pilares Afetados

- **security**: SCPs devem ter lifecycle de change management equivalente a mudanças de banco de dados em produção. Use `aws:PrincipalType: Root` como escape hatch explícito em SCPs críticas. Implemente EventBridge + SNS para detecção imediata de attach/detach de policies no Management Account. Considere Organization boundary como isolamento físico para regimes PCI-DSS e BACEN 4.893.
- **reliability**: O design de Organizations deve minimizar o blast radius de mudanças operacionais. Circuit breakers em serviços downstream (EKS/Resilience4j, Lambda com Dead Letter Queue) são necessários mas insuficientes — eles mascaram o erro sem resolver a causa. Adicione health checks específicos para `AccessDeniedException` com alarmes de baixa latência (< 5 minutos de MTTD). Implemente rollback automatizado de SCPs com estado imutável em S3 Object Lock.

## Anti-Padrões que Levam ao Incidente

- Tratar SCPs como infraestrutura comum no pipeline de CI/CD sem aprovação diferenciada por nível de target (Root, OU de produção, OU de sandbox)
- Usar uma única Organization para consolidar governança de custo sem avaliar o blast radius de políticas de segurança em cargas de trabalho reguladas
- Configurar alarmes de 5xx no API Gateway como único sinal de detecção sem alarmes específicos para `AccessDeniedException` em CloudTrail
- Assumir que circuit breakers em serviços downstream substituem isolamento arquitetural — eles são complementares, não equivalentes
- Não mapear dependências cross-region de contas antes de aplicar SCPs com condição `aws:RequestedRegion`
- Confiar em OUs como boundary de isolamento regulatório para auditores PCI-DSS sem documentar explicitamente que o boundary é lógico, não físico

> **Nota do Arquiteto:** Depois desse incidente, passei a recomendar uma regra simples: se você tem cargas de trabalho com regimes regulatórios distintos (PCI-DSS, SOC 2, BACEN) ou com SLOs de disponibilidade acima de 99.9%, elas pertencem a Organizations separadas — não a OUs separadas. O custo operacional adicional de múltiplas Organizations é real, mas é um custo de engenharia previsível e gerenciável; o custo de um incidente de 47 minutos em um pipeline de pagamentos não é. A lição mais dura foi perceber que tratamos SCPs como código quando deveríamos tê-las tratado como mudanças de schema de banco de dados em produção: com staging, aprovação dupla, rollback testado e janela de manutenção. Isso não é burocracia — é engenharia de confiabilidade aplicada à camada de controle.

## Veredicto: Quando Usar Uma ou Múltiplas Organizations

Use uma única AWS Organization quando: todas as suas cargas de trabalho compartilham o mesmo regime regulatório, o mesmo SLO de disponibilidade, e a equipe de plataforma tem capacidade para implementar guardrails rigorosos no pipeline de mudança de SCPs. Use múltiplas Organizations quando: você tem regimes regulatórios distintos (especialmente PCI-DSS ou BACEN 4.893), SLOs acima de 99.9% em cargas de trabalho críticas, ou quando auditores exigem evidência de isolamento físico de políticas. O custo de Savings Plans não compartilhados é quantificável e geralmente menor que o custo de um único incidente causado por blast radius irrestrito. A decisão não é sobre simplicidade operacional — é sobre onde você aceita que o erro humano inevitável tenha consequências.

## Referências

- [AWS Organizations — Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
- [AWS CloudTrail Lake — Cross-Organization Event Data Stores](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)
- [AWS Control Tower — Customizations for Landing Zone](https://docs.aws.amazon.com/controltower/latest/userguide/customize-landing-zone.html)
- [AWS Cost and Usage Report 2.0](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)
- [AWS Well-Architected Framework — Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
- [AWS Architecture Blog — Single versus multiple AWS Organizations](https://aws.amazon.com/blogs/architecture/)
- [BACEN Resolução 4.893/2021 — Política de Segurança Cibernética](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=85)
- [PCI DSS v4.0 — Requirement 1: Network Security Controls](https://www.pcisecuritystandards.org/document_library/)