Por que separar workloads em contas

Uma conta AWS é um contêiner de recursos. Por padrão, nada de uma conta enxerga ou acessa outra: identidades, recursos e dados ficam separados até que você crie explicitamente um acesso entre contas. Por isso a AWS trata a conta como um limite de isolamento forte para três coisas ao mesmo tempo:

• Segurança e acesso: quem tem permissão em uma conta não ganha nada nas outras automaticamente.
• Cobrança: a conta é a forma padrão de alocar custos; cada conta aparece separada na fatura.
• Cotas: Service Quotas e limites de taxa de API valem por conta, então um workload barulhento não consome a cota do vizinho.

A boa prática SEC01-BP01 pede exatamente isso: usar uma estratégia multi-conta para isolar ambientes (produção, desenvolvimento, teste) e workloads, com guardrails comuns aplicados a todas as contas.

Blast radius é o alcance do dano quando algo dá errado: uma credencial vazada, um script que apaga o recurso errado, uma configuração pública por engano. Em uma conta única com tudo dentro, o raio é o ambiente inteiro. Com contas separadas, o problema tende a ficar contido na conta onde aconteceu.

Cenário	Tudo em uma conta	Contas separadas
Chave de acesso de dev vaza	Atacante pode alcançar produção se as permissões permitirem	Alcance limitado à conta de dev
Script de limpeza com filtro errado	Pode apagar recursos de produção	Só apaga o que existe na conta onde rodou
Teste de carga estoura uma cota	Produção fica sem capacidade	Cota da produção intacta
Auditoria de dados sensíveis	Precisa provar isolamento recurso a recurso	O escopo é a conta que guarda os dados

O whitepaper de multi-conta da AWS sugere alguns critérios para decidir as fronteiras:

• Produção separada de não produção: controles diferentes (aprovação de mudança, acesso, monitoramento) ficam mais simples quando cada ambiente tem a própria conta.
• Um workload ou um pequeno grupo de workloads relacionados por conta de produção: donos diferentes, contas diferentes. Isso simplifica acesso e aprovação de mudanças.
• Dados sensíveis em contas dedicadas: menos gente e menos processos chegam perto deles, o que reforça o menor privilégio.
• Sandbox à parte: contas de experimentação com mais liberdade, sem dados internos nem conexão com a rede corporativa, e com orçamento de custo.
• Funções da plataforma isoladas: logs, ferramentas de segurança e rede compartilhada ficam em contas próprias, longe dos workloads.

Um ponto de partida típico para um workload:

Conta	Uso	Acesso típico
pagamentos-dev	Desenvolvimento e testes iniciais	Amplo para o time, sem dados reais
pagamentos-test	Homologação parecida com produção	Mais restrito, mudanças via pipeline
pagamentos-prod	Produção	Mínimo; mudanças só via pipeline, acesso humano raro e auditado

Mais contas não é sempre melhor. Cada conta precisa de baseline, logs, acesso, monitoramento e alguém responsável. Sinais de que você está separando além do necessário:

• Contas criadas por organograma em vez de necessidade de segurança ou operação. O whitepaper recomenda organizar por função, conformidade ou conjunto comum de controles, não pela estrutura de reporte.
• Componentes fortemente acoplados de um mesmo workload espalhados em várias contas, gerando um emaranhado de acessos entre contas.
• Contas criadas à mão, sem automação. Sem automação, cada conta nova é uma chance de configuração divergente.

• Workloads não relacionados, com sensibilidades diferentes, na mesma conta. É o primeiro antipadrão citado na SEC01-BP01.
• Estrutura de OUs mal definida. O segundo antipadrão: sem OUs claras, os guardrails viram exceções conta a conta. Veja a lição 6.
• Workloads na conta de gerenciamento da organização. Essa conta tem poderes especiais e não é restringida por SCPs; ela deve ficar mínima.
• Separar e esquecer o resto. Contas isolam, mas ainda precisam de identidade centralizada, logs centralizados e guardrails comuns.

A conta é o limite de isolamento mais forte da AWS para segurança, acesso, cobrança e cotas. Separar produção de não produção, e workloads com donos ou sensibilidades diferentes, reduz o blast radius e simplifica controles. Mas cada conta tem custo de gestão: separe por necessidade de segurança e operação, automatize a criação e comece pequeno.

SEC01-BP01 Separate workloads using accounts — nível de risco se não for adotada: alto.

• Benefits of using multiple AWS accounts (whitepaper)
• Design principles for your multi-account strategy
• Terminology and concepts for AWS Organizations