Referência
Estrutura de OUs recomendada
OUs fundamentais e adicionais, para que serve cada uma.
Material complementar · Módulo 2 — Contas como fronteira
A árvore de referência
Esta estrutura segue as OUs recomendadas no whitepaper Organizing Your AWS Environment Using Multiple Accounts. Os nomes das contas são exemplos. Comece com as fundamentais, Workloads e Sandbox, e acrescente as outras quando houver necessidade.
Estrutura
123456789101112131415161718192021222324
Root├── Conta de gerenciamento (sem workloads)├── Security ← fundamental│ ├── log-archive│ └── security-tooling├── Infrastructure ← fundamental│ ├── network│ ├── operations-tooling│ └── backup├── Workloads│ ├── Prod│ │ └── pagamentos-prod│ └── Test│ └── pagamentos-test├── Sandbox│ └── sandbox-maria├── Deployments│ └── cicd-prod├── Policy Staging├── Exceptions├── Transitional├── Suspended├── Individual Business Users└── Business ContinuityOUs fundamentais e de aplicação
| OU | Propósito | Exemplos de contas | Políticas típicas |
|---|---|---|---|
| Security | Contas que aplicam controles de segurança, governança e conformidade para toda a organização. Dono: time de segurança. | Log Archive, Security Tooling (Audit) | Proteger trilhas, buckets de log e as ferramentas de segurança contra alteração |
| Infrastructure | Infraestrutura compartilhada e operação central. Sem workloads de aplicação. | Network, Operations Tooling, Backup | Restringir quem altera rede compartilhada e recursos centrais |
| Workloads | Workloads de negócio, de produção e de não produção, em geral em OUs filhas (Prod, Test). | pagamentos-prod, pagamentos-test | Regiões aprovadas, proteção de logs, regras mais rígidas em Prod |
OUs experimentais, procedimentais e avançadas
| OU | Propósito | Exemplos de contas | Políticas típicas |
|---|---|---|---|
| Sandbox | Experimentação livre, desconectada da rede e dos dados internos. Não vira conta de workload. | Uma por builder ou time pequeno | Orçamento de custo, limpeza periódica, bloqueio de conexão com a rede corporativa |
| Policy Staging | Testar mudanças amplas de políticas antes de aplicá-las às OUs de destino. | Contas que espelham a estrutura real | A versão candidata da política em teste |
| Exceptions | Contas que precisam de exceção às políticas da Workloads OU. Devem ser poucas. | Um workload com requisito incomum | SCPs anexadas por conta; mais escrutínio do monitoramento |
| Transitional | Área temporária para contas que chegam (aquisição, contas antigas) antes de integrá-las. | Contas de uma empresa adquirida | Revisar o impacto das SCPs do root antes de mover |
| Suspended | Contas com uso suspenso. Mover para cá não fecha a conta. | Sandbox de quem saiu da empresa | SCP negando uso de APIs a todos, exceto times de segurança e plataforma; tags com o motivo |
| Individual Business Users | Contas para usuários e times de negócio que gerenciam poucos recursos fora de um workload. | Bucket para troca de arquivos com parceiro | SCPs e IAM liberando só os serviços necessários |
| Deployments | Capacidades de CI/CD separadas dos workloads. | Contas de pipeline de produção | Proteger roles e artefatos de deploy |
| Business Continuity | Caso avançado: cópias de recuperação o mais isoladas possível, sem workloads, para desastres graves como ransomware. | Conta de cofre de recuperação | Acesso mínimo, só em recuperação |
Regras de desenho
- Organize por função, conformidade ou controles comuns, não pelo organograma.
- Aplique controles em OUs, não conta a conta.
- Evite hierarquias profundas: o limite é de cinco níveis, mas cada nível precisa se justificar.
- Não coloque workloads na conta de gerenciamento; SCPs não a restringem.
- Comece pequeno e expanda.