Qual é a melhor estrutura organizacional para sua conta AWS?

Organização desde o primeiro dia#

Quando você começa na AWS, o normal é criar uma conta, entrar como usuário root e fazer deploy de tudo ali: testes, staging e produção misturados. Funciona até que um script de testes apague um recurso que não devia, a fatura não diga qual ambiente gastou o quê, ou uma credencial vazada dê acesso a tudo de uma vez.

A alternativa é definir, já no design, uma estrutura organizacional segura e funcional. Na AWS, isso é feito com o AWS Organizations: um serviço gratuito que agrupa várias contas sob uma mesma administração, com faturamento consolidado e políticas centralizadas.

Neste guia, vemos como desenhar essa estrutura de forma geral: o que é cada peça do AWS Organizations, como distribuir contas por ambiente e por workload, como criar uma OU e uma conta de produção passo a passo no console nativo da AWS, como automatizar isso com a AWS CLI e o Terraform, e quais guardrails, acessos e controles de faturamento vale ativar desde o início.

Documentação: AWS · O que é o AWS Organizations ↗ · AWS · Organizing your AWS environment (whitepaper) ↗

Os quatro conceitos que você precisa distinguir#

O erro de vocabulário mais comum (e que a versão original deste artigo cometia) é chamar cada pasta de organização. No AWS Organizations, existem peças diferentes:

• Organização: a entidade completa. Existe uma só por conta de gerenciamento, e ela agrupa todas as contas.
• Conta de gerenciamento (management account): a conta que cria a organização. Ela paga a fatura consolidada, cria e convida contas e administra políticas. É a conta mais sensível de todas.
• Root: o contêiner raiz da hierarquia. Todas as OUs e contas ficam abaixo dele, direta ou indiretamente.
• Unidade organizacional (OU): uma pasta dentro do Root (ou dentro de outra OU) para agrupar contas que compartilham políticas, por exemplo production ou sandbox.
• Conta-membro: uma conta AWS normal que pertence à organização. É o verdadeiro limite de isolamento para recursos, permissões e cotas.

A ideia-chave: a conta é a fronteira de segurança e de faturamento; a OU é a forma de aplicar regras a um grupo de contas de uma vez.

Documentação: AWS · O que é o AWS Organizations ↗

A estrutura recomendada: separar por ambiente#

A AWS recomenda um ambiente multi-conta porque cada conta isola permissões, cotas de serviço e custos. Se staging e produção ficam em contas diferentes, um erro em staging não consegue afetar a produção, mesmo que alguém tenha permissões de administrador em staging.

Para times que estão começando, uma base razoável é:

• A conta de gerenciamento, sem workloads: apenas organização, faturamento e políticas.
• Uma OU para produção com sua conta (ou contas) de produção.
• Uma OU para ambientes não produtivos (staging, QA, desenvolvimento).
• Uma OU sandbox para experimentação, com restrições de gasto e de serviços.

À medida que a organização cresce, o whitepaper da AWS Organizing Your AWS Environment propõe OUs adicionais, como Security (contas de auditoria e log archive), Infrastructure (redes e serviços compartilhados), Workloads (com produção e não produção), Sandbox, Policy Staging e Suspended. Você não precisa de todas no primeiro dia, mas vale que seus nomes sejam compatíveis com esse modelo.

Dentro de cada ambiente, a unidade natural é o workload: uma conta por aplicação ou domínio de negócio e por ambiente (por exemplo loja-prod e loja-staging). Assim, cada time tem seu próprio limite de permissões e de cotas, e a fatura por conta já mostra quanto custa cada aplicação em cada ambiente. Se você tem poucas aplicações, começar com uma conta de produção e outra de não produção é perfeitamente válido; o importante é que o design permita dividir depois sem refazer tudo.

Root
├── conta de gerenciamento     (só organização, faturamento e políticas)
├── OU Security
│   ├── log-archive            (logs centralizados, acesso restrito)
│   └── audit                  (ferramentas de segurança, acesso somente leitura)
├── OU Workloads
│   ├── OU Prod
│   │   ├── loja-prod
│   │   └── pagamentos-prod
│   └── OU NonProd
│       ├── loja-staging
│       └── pagamentos-staging
└── OU Sandbox
    └── sandbox-time-dados

Se você prefere não montar tudo à mão, o AWS Control Tower cria uma landing zone sobre o Organizations com OU Security, contas de log archive e audit e controles pré-configurados. É uma opção válida quando você quer um ponto de partida governado; os conceitos deste guia continuam valendo.

Para se aprofundar: Como separar ambientes (dev, staging e produção) na AWS

Documentação: AWS · Benefícios de usar várias contas ↗ · AWS · OUs e contas recomendadas ↗ · AWS · O que é o AWS Control Tower ↗

Passo 1: abra o AWS Organizations#

Entre no console com um usuário da conta que será a de gerenciamento. Digite Organizations na barra de busca superior e selecione AWS Organizations.

Você verá um de dois cenários:

• Se você nunca criou uma organização, o console mostra o botão Create an organization. Ao clicar nele, sua conta atual passa a ser a conta de gerenciamento e o Root é criado.
• Se já existe uma organização, você verá diretamente a visão de estrutura (AWS accounts), de onde se criam contas e OUs.

Lembre-se de que a conta que cria a organização fica como conta de gerenciamento de forma permanente para essa organização. Se hoje você tem workloads de produção nessa mesma conta, o recomendado é planejar movê-los para uma conta-membro com o tempo, e não continuar crescendo ali.

Documentação: AWS · O que é o AWS Organizations ↗ · AWS · Boas práticas para a conta de gerenciamento ↗

Passo 2: crie a unidade organizacional production#

Na visão de estrutura, selecione Root, que será o pai da nova OU, e depois escolha Organizational unit > Create new.

O formulário de criação é aberto. No campo Organizational unit name, digite production e clique em Create organizational unit.

Ao voltar para a árvore, você vai confirmar duas coisas:

• A OU production aparece como filha do Root, exatamente como você a definiu.
• A OU está vazia: ainda não contém nenhuma conta nem outra OU.

Uma OU vazia não custa nada nem tem efeito por si só. O valor dela aparece quando você atribui contas e políticas.

Documentação: AWS · Criar uma unidade organizacional ↗

Passo 3: crie a conta AWS de produção#

Agora crie a conta que vai ficar nessa OU. Clique em Add an AWS account e deixe selecionada a opção padrão, Create an AWS account. Preencha o formulário:

• AWS account name: o prático é usar o mesmo nome da OU ou o padrão workload-ambiente (por exemplo production ou loja-prod). É só um rótulo, e você pode mudá-lo depois.
• Email address of the account's owner: o e-mail do usuário root da nova conta. Precisa ser válido e não estar em uso por outra conta AWS. Pode ser um alias; por exemplo, o Gmail e muitos provedores aceitam endereços com +, como [email protected]. Melhor ainda se for uma lista de distribuição do time, e não a caixa de entrada de uma única pessoa.
• IAM role name: mantenha o valor padrão, OrganizationAccountAccessRole. O Organizations cria essa role na nova conta com permissões de administrador e relação de confiança com a conta de gerenciamento, para que você possa entrar sem usar credenciais root.

Clique em Create AWS account. A criação é assíncrona e pode levar alguns minutos; o console mostra uma notificação e você pode acompanhar o progresso em View all pending creation requests.

Quando termina, a conta aparece na árvore no primeiro nível, diretamente abaixo do Root. Isso é esperado: as contas criadas pelo console nascem no Root.

Documentação: AWS · Criar uma conta-membro ↗ · AWS · Acessar contas-membro com OrganizationAccountAccessRole ↗

Passo 4: mova a conta para a OU correta#

Para que a conta herde as políticas de production, mova-a do Root para a OU:

• Marque a caixa de seleção da conta production na árvore.
• Escolha Actions e, em AWS account, a opção Move.
• Indique a OU de destino, production, e clique em Move AWS account.

Expanda a OU production para confirmar que a conta agora está dentro dela. Este passo também mostra algo útil: a hierarquia não é rígida. Você pode mover contas entre OUs mais adiante se reorganizar sua estrutura, mas lembre que, ao mover, a conta deixa de herdar as políticas da OU anterior e passa a herdar as da nova, então revise as SCPs antes de fazer isso em produção.

Documentação: AWS · Mover contas entre OUs ↗

Automatize: AWS CLI e Terraform#

O console é perfeito para entender o processo. Para repeti-lo sem erros (outra conta para staging, outra para sandbox), vale tê-lo como código. Estes são os mesmos passos com a AWS CLI:

# Executar com credenciais da conta de gerenciamento
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)

# 1. Criar a OU "production" abaixo do Root
OU_ID=$(aws organizations create-organizational-unit \
  --parent-id "$ROOT_ID" --name production \
  --query 'OrganizationalUnit.Id' --output text)

# 2. Criar a conta-membro (assíncrono: retorna um request id)
REQ_ID=$(aws organizations create-account \
  --account-name production \
  --email [email protected] \
  --role-name OrganizationAccountAccessRole \
  --query 'CreateAccountStatus.Id' --output text)

# 3. Consultar o status até que seja SUCCEEDED
aws organizations describe-create-account-status \
  --create-account-request-id "$REQ_ID"

# 4. Mover a conta do Root para a OU production
aws organizations move-account --account-id <ID_DA_CONTA> \
  --source-parent-id "$ROOT_ID" --destination-parent-id "$OU_ID"

Com o Terraform, você pode declarar a OU e a conta, e criar a conta diretamente dentro da OU com parent_id, o que evita o passo de movê-la:

data "aws_organizations_organization" "this" {}

resource "aws_organizations_organizational_unit" "production" {
  name      = "production"
  parent_id = data.aws_organizations_organization.this.roots[0].id
}

resource "aws_organizations_account" "production" {
  name      = "production"
  email     = "[email protected]"
  role_name = "OrganizationAccountAccessRole"
  # É criada diretamente dentro da OU: não é preciso movê-la depois
  parent_id = aws_organizations_organizational_unit.production.id

  lifecycle {
    ignore_changes = [role_name]
  }
}

Documentação: Terraform AWS provider · aws_organizations_organizational_unit ↗ · Terraform AWS provider · aws_organizations_account ↗ · AWS · Criar uma conta-membro ↗

Guardrails: SCPs, acessos e a conta de gerenciamento#

Ter contas separadas é a base; os guardrails são o que transforma isso em uma estrutura segura.

Service Control Policies (SCPs). Elas são anexadas ao Root, a uma OU ou a uma conta e definem o máximo de permissões disponíveis nas contas afetadas. Não concedem permissões por si só: limitam o que o IAM pode conceder. Um detalhe importante: as SCPs não afetam os usuários nem as roles da conta de gerenciamento, mais um motivo para não fazer deploy de workloads ali.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingTheOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Acessos. Em vez de compartilhar credenciais root ou criar usuários IAM em cada conta, use o IAM Identity Center para dar a cada pessoa acesso às contas de que ela precisa, com permissões restritas. Proteja o usuário root de cada conta com MFA e não o use no dia a dia.

Acessos. Em vez de compartilhar credenciais root ou criar usuários IAM em cada conta, use o IAM Identity Center (que veremos na próxima seção). Proteja o usuário root de cada conta com MFA e não o use no dia a dia.

Documentação: AWS · Service Control Policies (SCPs) ↗ · AWS · O que é o IAM Identity Center ↗ · AWS · Boas práticas para a conta de gerenciamento ↗ · AWS Well-Architected · Pilar de segurança ↗ · AWS · Exemplos de SCPs ↗

Acessos com o IAM Identity Center#

Com várias contas, criar usuários IAM em cada uma se torna inviável. O IAM Identity Center centraliza o acesso: você conecta uma fonte de identidade (o diretório próprio dele, o Active Directory ou um provedor externo como Okta ou Microsoft Entra ID), define permission sets e atribui grupos a contas específicas. Cada pessoa entra por um portal único e recebe credenciais temporárias para a conta e a role que lhe cabem.

• Habilite o IAM Identity Center a partir da conta de gerenciamento da organização e escolha a fonte de identidade.
• Considere delegar a administração do Identity Center a uma conta-membro, para que o dia a dia não exija entrar na conta de gerenciamento.
• Crie permission sets por função (por exemplo AdministratorAccess para o time de plataforma, ReadOnly para consultas em produção), e não por pessoa.
• Atribua grupos, e não usuários individuais, a cada conta com o permission set adequado: acesso amplo em sandbox e staging, restrito em produção.

data "aws_ssoadmin_instances" "this" {}

locals {
  sso_instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
}

# Permission set: um conjunto de permissões reutilizável em várias contas
resource "aws_ssoadmin_permission_set" "read_only" {
  name             = "ReadOnly"
  instance_arn     = local.sso_instance_arn
  session_duration = "PT4H"
}

resource "aws_ssoadmin_managed_policy_attachment" "read_only" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

# Atribuição: o grupo "developers" entra em produção somente leitura
resource "aws_ssoadmin_account_assignment" "developers_prod" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn
  principal_type     = "GROUP"
  principal_id       = var.developers_group_id
  target_type        = "AWS_ACCOUNT"
  target_id          = aws_organizations_account.production.id
}

Para se aprofundar: Acesso à sua AWS para plataforma externa com privilégio mínimo

Documentação: AWS · Primeiros passos com o IAM Identity Center ↗ · AWS · Permission sets ↗ · AWS · Administração delegada do IAM Identity Center ↗ · Terraform AWS provider · aws_ssoadmin_permission_set ↗ · Terraform AWS provider · aws_ssoadmin_account_assignment ↗

Faturamento: uma fatura, custos por conta#

O Organizations ativa o faturamento consolidado: a conta de gerenciamento paga uma única fatura que soma o uso de todas as contas-membro. Esse é o motivo prático para separar por conta: o custo de cada ambiente e de cada workload aparece detalhado sem que você precise taguear cada recurso com perfeição.

• Agrupe por conta vinculada (linked account) no Cost Explorer para ver o gasto de cada ambiente e aplicação.
• Ative tags de alocação de custos (por exemplo team ou project) na conta de gerenciamento para detalhar os custos dentro de uma conta compartilhada. As tags só aparecem nos relatórios depois de ativadas.
• Crie orçamentos com o AWS Budgets por conta, principalmente em sandbox, com alertas antes de chegar ao limite.
• Lembre-se de que, por padrão, os descontos de Reserved Instances e Savings Plans são compartilhados entre as contas da organização; você pode desativar esse compartilhamento por conta se precisar atribuir a economia a um time específico.

Para se aprofundar: Por que o custo cloud preocupa mais que a segurança nas PMEs

Documentação: AWS · Faturamento consolidado ↗ · AWS · Tags de alocação de custos ↗ · AWS · Gerenciar custos com o AWS Budgets ↗ · AWS · Desativar o compartilhamento de descontos de RI e Savings Plans ↗

Checklist da estrutura#

• A conta de gerenciamento não executa workloads.
• A produção fica em sua própria conta, dentro de uma OU production.
• Staging, QA e sandbox estão em contas e OUs separadas da produção.
• Cada conta usa um e-mail de time válido e único, e o usuário root tem MFA.
• O acesso às contas é feito com IAM Identity Center ou OrganizationAccountAccessRole, não com credenciais root compartilhadas.
• Há pelo menos uma SCP base aplicada e testada antes em uma OU de testes.
• A estrutura está em código (CLI ou Terraform) para poder ser repetida.
• Cada workload tem sua conta por ambiente, ou o design permite separá-lo sem refazer a estrutura.
• Há orçamentos por conta e as tags de custo que você usa estão ativadas.

Com organização desde o design, adicionar um ambiente novo deixa de ser um projeto e vira uma mudança de poucas linhas. É uma base que escala à medida que os times e os projetos crescem.

Documentação: AWS · OUs e contas recomendadas ↗