Organizations, Control Tower e Landing Zone
- ⬜🎯 SAP-C03 intro: domínios, pesos e estratégia(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
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.
- → cria e configura
- → limita
- → limita
- → RAM: subnet compartilhada
- → trilha imutável
- → permission set
- Segurança e identidade
- Armazenamento
- Rede e entrega
- Compute
Esta é a estrutura de referência que quase toda questão de SAP-C03 sobre governança assume. Os dois pontos que mais valem ponto: conta de gerenciamento sem carga, e OU organizada por função porque é ali que a SCP incide.
- A conta de gerenciamento não roda carga. Ela é o payer e o dono da organização. Colocar aplicação nela é o antipadrão nº 1 de multi-account: SCP não se aplica à conta de gerenciamento, então ela fica sem guardrail nenhum.
- OU por FUNÇÃO, não por time. Security, Infrastructure, Workloads, Sandbox. A OU é onde a SCP se aplica, então ela precisa agrupar contas com o MESMO conjunto de restrições. Organizar por departamento gera OU com necessidades conflitantes.
- Log em conta que ninguém de produção altera. CloudTrail e Config agregados numa conta cujo bucket tem política impedindo exclusão — inclusive pelo administrador da conta auditada. É o que garante que a trilha sobrevive ao comprometimento.
- Rede centralizada com RAM. A conta Network cria a VPC, o Transit Gateway e o Direct Connect, e compartilha subnets com as contas de carga via Resource Access Manager. Uma equipe cuida do endereçamento e do trânsito; as demais só consomem.
- Acesso humano por permission set. Identity Center federa com o IdP e atribui conjuntos de permissão por conta. Zero usuário IAM por pessoa. Desligar alguém no IdP remove o acesso em todas as contas de uma vez.
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)Onde isso entra no exame
Organizations é o centro do Domain 1. Espere SCP que nega mesmo com o IAM da conta permitindo (a interseção é o que vale), quando Control Tower vale mais que Organizations puro, e como delegar administração de serviço — GuardDuty, Config, Security Hub — para uma conta de segurança em vez de operar da conta de gestão.
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.
Onde a carga de produção NÃO deve rodar numa organização AWS, e por quê?
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.
Perguntas frequentes
❓ Por que separar cargas em várias contas?
❓ O que a política de controle de serviço faz na prática?
❓ Control Tower ou montar a base à mão?
Fixando
Qual é a diferença prática entre AWS Organizations e Control Tower?
Uma SCP anexada à OU de produção permite apenas as ações de EC2 e S3. Uma conta dessa OU tem política IAM concedendo acesso ao DynamoDB. O que acontece?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…