Multi-account: por que, não se
Uma conta AWS por workload crítico é padrão em enterprise. Isolamento de blast radius (explosão de custo em dev não afeta prod), isolamento de IAM (roles de dev não têm chance em prod), billing claro (cada conta = linha no cost report), compliance (SOC2/PCI exige separação). Organizations é o eixo estrutural que gerencia essas contas.
Estrutura OU típica (landing zone):
Root
├── Security OU
│ ├── Log Archive (CloudTrail central + S3 WORM)
│ └── Audit (Security Hub, GuardDuty master)
├── Infrastructure OU
│ ├── Network (Transit Gateway, Route 53 hub)
│ └── Shared Services (SSM, ECR, artifact repos)
├── Sandbox OU (contas pessoais descartáveis)
├── Workloads OU
│ ├── Production OU
│ │ ├── app-a-prod
│ │ └── app-b-prod
│ └── Non-production OU
│ ├── app-a-dev
│ └── app-a-staging
└── Suspended OU (contas em decomissionamento)SCPs: guardrails, não permissões
SCPs são policies aplicadas em OU ou conta que limitam o que IAM pode fazer. Herança é restritiva: se Root OU nega ec2:* na us-east-1, nada abaixo consegue liberar. SCPs não afetam o management account — nunca confie que SCP protegerá a conta payer.
Exemplos clássicos de SCP em produção:
DenyRegionsOutsideCompliance:
Effect: Deny
NotAction: [ "iam:*", "support:*", "route53:*" ]
Resource: "*"
Condition:
StringNotEquals:
aws:RequestedRegion: [ "us-east-1", "sa-east-1" ]
DenyRootUserActions:
Effect: Deny
Action: "*"
Resource: "*"
Condition:
StringLike:
aws:PrincipalArn: "arn:aws:iam::*:root"
DenyDisableSecurityServices:
Effect: Deny
Action:
- cloudtrail:StopLogging
- cloudtrail:DeleteTrail
- config:DeleteConfigurationRecorder
- guardduty:DeleteDetector
Resource: "*"Nunca anexe SCP "Deny *" no Root OU durante teste — você pode se bloquear do management. Teste SCPs primeiro numa sandbox OU isolada.
Control Tower + AFT: landing zone gerenciada
Control Tower faz deploy de landing zone com: Organizations estruturado, contas Log Archive + Audit, CloudTrail org-wide, Config rules mandatórias, IAM Identity Center, 20+ guardrails prontos (preventive via SCP, detective via Config). Account Factory cria contas novas pelo console. AFT (Account Factory for Terraform) adiciona camada IaC: cada conta nova é um PR em repo Git → CodePipeline aplica customizations.
Padrão 2026 em enterprise AWS: Control Tower como base + AFT pra customization + Identity Center conectado a Okta/Azure AD + Organizations com OUs por ambiente. Dá governance sem reinventar roda.