AWS Organizations permite gerenciar múltiplas contas AWS centralmente; Service Control Policies (SCPs) impõem restrições de permissões a OUs e contas.

🎯 Para a certificação

Questões cobrem criação de OUs, herança/cascata de SCPs, a exceção da conta de management, diferenças entre SCPs e IAM policies, estratégias allow-list vs deny-list, e outros tipos de policy do Organizations.

---

Resumo

Imagine uma empresa com dezenas de equipes, cada uma precisando de sua própria conta AWS isolada (para não misturar orçamento, permissões e blast radius de um erro). Gerenciar isso manualmente — cobrança separada, políticas repetidas em cada conta — seria inviável em escala. AWS Organizations existe para centralizar essa gestão: cobrança consolidada, hierarquia de contas em grupos (OUs), e políticas aplicadas de uma vez a um grupo inteiro de contas.

• Organization: o container que agrupa todas as contas, com uma conta de management (antiga "master account") no topo.
• OU (Organizational Unit): uma "pasta" para agrupar contas com propósito semelhante (ex: Produção, Desenvolvimento, Segurança).
• SCP (Service Control Policy): define o teto máximo de permissões que contas dentro de uma OU podem ter — nunca concede nada por si só, só limita.
• Consolidated Billing: cobrança unificada, com benefícios de volume compartilhados entre contas (ex: descontos de Reserved Instances/Savings Plans podem se aplicar entre contas da mesma organização).

---

1. Como SCPs funcionam, de fato

Se o IAM é quem "dá permissão" para um usuário fazer algo, o SCP é o "teto" acima de toda a conta — nenhuma permissão IAM, por mais ampla que seja, ultrapassa o que o SCP permite. Mesmo que um administrador dê a um usuário uma IAM policy com "Action": "*", "Resource": "*", se o SCP da conta tiver um deny explícito para ec2:TerminateInstances, essa ação continua bloqueada.

SCP nunca concede nada sozinho — ele só recorta o universo do que pode ser permitido. A permissão efetiva final é sempre a interseção entre o que o SCP permite e o que a IAM policy permite.

Permissão efetiva = (o que o SCP permite) ∩ (o que a IAM policy permite)

---

2. A policy padrão: FullAWSAccess

Toda OU e toda conta nasce, por padrão, com uma SCP chamada FullAWSAccess anexada — que permite tudo ("Action": "*"). É por isso que, ao criar uma Organization, nada quebra de imediato: o teto começa totalmente aberto, e você vai fechando conforme necessário, anexando SCPs adicionais (ou substituindo a padrão).

---

3. Herança em cascata — o ponto mais mal explicado do assunto

SCPs se aplicam de forma cumulativa e hierárquica: uma conta é afetada por todas as SCPs anexadas a ela diretamente, e por todas as SCPs anexadas a cada OU acima dela na árvore, até a raiz da Organization.

Raiz da Organization
  └── OU "Empresa"
        └── OU "Produção"
              └── Conta "app-prod-01"

Se houver um Deny para ec2:TerminateInstances na OU "Produção", esse deny se aplica à conta app-prod-01 mesmo que nenhuma policy diretamente anexada a essa conta mencione essa ação — e mesmo que uma OU mais abaixo (ou a própria conta) tenha uma policy tentando "permitir" essa ação: um Deny em qualquer nível da hierarquia sempre vence, exatamente como a lógica de Deny explícito no IAM (visto no material de IAM).

💡 Regra para a prova: um Deny aplicado numa OU superior é herdado por todas as contas abaixo dela na árvore, sem exceção — não existe "sobrescrever" um Deny herdado com um Allow mais específico embaixo.

---

4. A exceção mais importante: a conta de management

Este é o ponto que o conteúdo original nunca mencionou, e é cobrado com frequência: SCPs não se aplicam à conta de management (a conta raiz da Organization). Isso significa que, mesmo que você anexe um SCP extremamente restritivo na raiz da árvore, um usuário/role atuando dentro da conta de management continua sujeito só às regras normais de IAM daquela conta — o SCP não o restringe.

Por isso, a prática recomendada é não usar a conta de management para rodar workloads — ela deve servir só para administração da Organization em si, com contas-membro separadas (produção, desenvolvimento, segurança, log archive etc.) sendo onde as SCPs realmente entram em ação.

⚠️ Outra exceção relevante: SCPs também não afetam service-linked roles — roles que a própria AWS cria e gerencia para permitir que um serviço (ex: Auto Scaling, Elastic Load Balancing) execute ações em nome da conta. Isso evita que uma SCP muito restritiva quebre acidentalmente a operação interna de serviços gerenciados pela AWS.

---

5. Estratégias de SCP: Deny List vs Allow List

5.1 Deny List (estratégia mais comum)

Você mantém a FullAWSAccess anexada (tudo permitido por padrão) e adiciona SCPs adicionais com Deny explícito para ações específicas que você quer bloquear (ex: negar ec2:* fora de certas regiões, negar a exclusão de trilhas do CloudTrail).

Vantagem: simples de raciocinar — "tudo é permitido, exceto o que listamos".

5.2 Allow List

Você remove a FullAWSAccess da OU e anexa uma SCP que explicitamente lista, via Allow, só as ações permitidas — tudo que não estiver na lista fica bloqueado por padrão (implicit deny, mesma lógica do IAM).

Vantagem: mais restritivo e seguro por padrão, mas exige manutenção cuidadosa — esquecer de listar uma ação necessária quebra funcionalidades legítimas.

💡 Para a prova: "bloquear ações específicas, mantendo o resto permitido" → deny list. "permitir só um conjunto restrito e bem definido de ações, bloqueando tudo o mais" → allow list (remover FullAWSAccess).

---

6. Outros tipos de policy do AWS Organizations

Além de SCPs, a Organizations suporta outros tipos de política, menos citados mas que também caem na prova:

• Tag Policies: padronizam como tags devem ser usadas nos recursos das contas-membro (ex: exigir que toda instância EC2 tenha uma tag cost-center com um dos valores permitidos), ajudando na consistência de alocação de custo e governança.
• Backup Policies: centralizam e padronizam planos de backup (via AWS Backup) aplicados a recursos em múltiplas contas, a partir de uma única definição.
• AI Services Opt-out Policies: controlam se serviços de IA da AWS podem usar dados da conta para melhorar seus modelos, aplicável de forma centralizada pela Organization.

💡 SCP é sobre o que pode ser feito (permissões). Tag Policy é sobre como as coisas devem ser marcadas (padronização), não sobre bloquear ações.

---

7. Compartilhamento de recursos entre contas: AWS RAM

Quando contas de uma mesma Organization precisam compartilhar recursos diretamente (não só permissões de acesso via role, mas o recurso em si — ex: uma subnet de uma VPC, uma regra do Transit Gateway, um repositório de licenças), o serviço usado é o AWS Resource Access Manager (RAM). Ele permite compartilhar recursos específicos entre contas da Organization sem precisar duplicá-los ou recriar infraestrutura em cada conta.

---

8. AWS Control Tower

Um serviço que se apoia em AWS Organizations para automatizar a criação de uma landing zone: uma estrutura multi-conta pronta com boas práticas de governança já configuradas — OUs padrão (ex: separando produção de sandbox), SCPs de linha de base (guardrails), conta de log centralizado, conta de segurança/auditoria, e um processo padronizado (Account Factory) para provisionar novas contas já em conformidade, sem configuração manual repetida.

💡 Para a prova: se o cenário descreve "provisionar rapidamente novas contas já com governança e guardrails padronizados, sem configurar cada uma manualmente", pense em Control Tower, que usa Organizations por trás dos panos.

---

9. Boas práticas

• Não rode workloads na conta de management — use-a só para administração da Organization.
• Teste SCPs em uma OU de sandbox antes de aplicar em produção.
• Use o princípio do menor privilégio: aplicar restrições amplas por OU, refinando com IAM policies dentro de cada conta.
• Separe contas por propósito (produção, desenvolvimento, segurança, log archive) em vez de misturar workloads numa mesma conta.
• Considere Control Tower quando o número de contas crescer e a governança manual se tornar inviável.
• Use AWS RAM para compartilhar recursos de rede (ex: subnets) entre contas, evitando duplicação de infraestrutura.

---

10. Como cai na certificação

• Cenário "nenhuma conta pode criar recursos fora de uma lista de regiões aprovadas" → SCP aplicada na OU apropriada.
• Cenário "usuário com IAM policy * ainda consegue executar a ação bloqueada" → SCP não está negando aquela ação em nenhum nível da hierarquia — ou o SCP nem existe para aquela conta/OU.
• Cenário "SCP super restritiva aplicada na raiz, mas um administrador na conta de management ainda consegue fazer tudo" → comportamento esperado: SCPs não afetam a conta de management.
• Cenário "provisionar novas contas rapidamente já com governança padronizada" → Control Tower.
• Cenário "padronizar como tags são aplicadas entre contas" → Tag Policy, não SCP.
• Cenário "compartilhar uma subnet de VPC entre contas da mesma organização" → AWS RAM.
• Cenário "permitir só um conjunto restrito de ações, bloqueando todo o resto por padrão" → allow list (remover FullAWSAccess).
• Cenário "SCP negando uma ação, mas um serviço AWS interno (ex: Auto Scaling) continua funcionando normalmente" → comportamento esperado: SCPs não afetam service-linked roles.

---

11. Exercícios práticos conceituais

1. Desenhe uma hierarquia de OUs para uma organização com ambientes prod/dev/test, incluindo uma conta de log centralizado e uma de segurança.
2. Proponha um SCP que proíba a criação de instâncias em regiões fora do conjunto permitido.
3. Explique a diferença entre negar via SCP e negar via IAM policy — em qual delas você conseguiria bloquear até o próprio usuário root de uma conta-membro?
4. Discuta por que a conta de management não deveria hospedar workloads de produção, considerando a exceção de SCP.
5. Compare a estratégia deny list e allow list para uma OU de "sandbox" onde só um punhado de serviços deveria ser permitido.
6. Explique quando usar Tag Policy em vez de SCP para um requisito de governança de custos.

---

12. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: criar uma estrutura simples de OUs, aplicar um SCP em cascata, e observar a exceção da conta de management.

Pré-requisitos: uma conta AWS que ainda não faça parte de uma Organization (ela se tornará a conta de management), e permissão para criar contas-membro adicionais (ou usar contas de teste já existentes).

Tempo estimado: 30 minutos

Possíveis custos: nenhum custo direto do AWS Organizations em si; atenção a recursos criados nas contas-membro durante o teste.

Passos:

1. Habilite o AWS Organizations na conta atual (ela se torna a conta de management).
2. Crie duas OUs: Producao e Sandbox.
3. Convide ou crie uma conta-membro de teste e mova-a para a OU Sandbox.
4. Crie uma SCP com Deny explícito para ec2:RunInstances, e anexe-a à OU Sandbox.
5. Usando um usuário/role dentro da conta-membro (não na conta de management), tente lançar uma instância EC2 — deve falhar, mesmo que a IAM policy do usuário permita ec2:RunInstances.
6. Repita a tentativa de lançar uma instância na conta de management — deve funcionar normalmente, demonstrando a exceção de SCP para essa conta.
7. Mova a conta-membro de teste para fora da OU Sandbox (ou remova a SCP) e confirme que o lançamento de instância volta a funcionar na conta-membro.

Resultado esperado: você confirma na prática a cascata de SCP bloqueando a ação na conta-membro, e a exceção da conta de management permanecendo irrestrita pela mesma SCP.

Limpeza dos recursos: remova a SCP de teste, mova a conta-membro de volta para a raiz se necessário, e desfaça a estrutura de OUs se for um ambiente só de teste.

---

Referências:

• AWS Organizations User Guide: https://docs.aws.amazon.com/organizations/
• Service Control Policies: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
• Tipos de política do Organizations: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html
• AWS Control Tower: https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
• AWS Resource Access Manager (RAM): https://docs.aws.amazon.com/ram/latest/userguide/what-is.html