Diagrama de landing zone da AWS: ambiente multiconta com Organizations e Control Tower

Uma única conta da AWS para tudo funciona até deixar de funcionar. Um script de teste apaga um bucket de produção. O financeiro não consegue dividir a fatura por time. Um auditor pergunta quem pode alterar os logs de auditoria, e a resposta honesta é “qualquer pessoa com permissão de admin”. Uma landing zone é a base multiconta que você monta antes de as workloads chegarem: a estrutura de contas, a identidade, os guardrails, os logs e a rede que toda conta nova herda.

Este post percorre o projeto de uma landing zone com um diagrama: por que várias contas, as unidades organizacionais recomendadas, as contas centrais, os guardrails com políticas de controle de serviço (SCPs), políticas de controle de recursos (RCPs) e políticas declarativas, a identidade, os logs centralizados e as ferramentas de segurança, a rede, e como montar tudo com o Control Tower, incluindo o que mudou na landing zone 4.0, ou com Terraform.

Por que várias contas

Uma conta da AWS é a fronteira de isolamento mais forte que a AWS oferece. Permissões do IAM, cotas de serviço, custos e a maioria das falhas param na borda dela. Contas separadas dão a você:

• Raio de impacto limitado. Um erro ou uma credencial comprometida em uma sandbox não consegue tocar a produção.
• Responsabilidade e cobrança claras por time, aplicação ou ambiente.
• Permissões mais simples. Em vez de uma conta cheia de condições sobre tags, cada conta recebe o acesso de que o seu time precisa.
• Cotas independentes, para que o teste de carga de um time não esgote os limites de outro.

O custo é a coordenação: identidade, logs, guardrails e rede precisam funcionar em dezenas de contas. Essa coordenação é o que uma landing zone oferece.

A estrutura: unidades organizacionais

O AWS Organizations agrupa as contas em unidades organizacionais (OUs), e as políticas anexadas a uma OU valem para todas as contas abaixo dela. O whitepaper da AWS sobre como organizar o seu ambiente recomenda um conjunto de OUs para começar:

Divida Workloads cedo em sub-OUs Prod e Non-prod. Os guardrails são diferentes entre elas, e mover contas depois é trabalhoso. Adicione uma OU Suspended com uma política que nega tudo para as contas que aguardam encerramento.

A conta de gerenciamento

A conta de gerenciamento é dona da organização, do faturamento consolidado e do Control Tower. Mantenha as workloads fora dela, por um motivo decisivo: SCPs não afetam usuários nem funções da conta de gerenciamento, como diz a documentação do Organizations. Nada do que você implanta ali é limitado pelos seus guardrails, então dê a ela o mínimo possível de usuários e recursos.

Contas centrais

• Log Archive. Recebe o trail do CloudTrail da organização e o histórico do AWS Config no S3. Quase ninguém tem acesso de escrita ou exclusão; considere o S3 Object Lock para que nem administradores consigam alterar os logs.
• Security Tooling, também chamada de Audit. É a administradora delegada do GuardDuty, do Security Hub, do IAM Access Analyzer e do agregador do AWS Config, para que o time de segurança veja todas as contas de um só lugar, sem acesso à conta de gerenciamento.
• Network. É dona do Transit Gateway, da conectividade privada com data centers, dos resolvedores de DNS e do gerenciamento de endereços IP, compartilhados com as contas de workloads pelo AWS Resource Access Manager.
• Shared Services. CI/CD, repositórios de artefatos e outras ferramentas que muitos times usam.

Guardrails: SCPs, RCPs e políticas declarativas

O Organizations oferece vários tipos de política, e eles respondem a perguntas diferentes:

Políticas só restringem; nunca concedem permissões. Comece com uma lista curta de guardrails de alto valor:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

Restrições de região são populares e fáceis de errar, porque serviços globais como o IAM precisam continuar permitidos. Teste cada política nova em uma OU de staging com uma conta representativa antes de anexá-la a Workloads.

O Control Tower empacota os guardrails como controles de três tipos: controles preventivos, implementados com SCPs e RCPs; controles de detecção, implementados com regras do AWS Config; e controles proativos, que verificam os recursos antes de o CloudFormation criá-los.

Identidade

Pessoas nunca deveriam ter usuários do IAM com chaves de longa duração nas contas de workloads. Conecte o IAM Identity Center ao provedor de identidade corporativo, provisione usuários e grupos com SCIM e conceda acesso por conjuntos de permissões atribuídos a grupos em cada conta: por exemplo, desenvolvedores recebem acesso de power user em Non-prod e somente leitura em Prod.

Mantenha duas identidades de emergência (break-glass) com MFA de hardware, guardadas offline e monitoradas. Para usuários raiz, o IAM agora consegue gerenciar o acesso raiz das contas-membro de forma centralizada, recurso lançado em novembro de 2024; assim, você pode remover totalmente as credenciais raiz das contas-membro e fazer as poucas tarefas exclusivas da raiz a partir de um ponto central.

Logs e detecção

1. Um trail de organização no CloudTrail registra a atividade de API de todas as contas e regiões na conta Log Archive.
2. O AWS Config registra a configuração dos recursos em todo lugar, com um agregador na Security Tooling.
3. GuardDuty e Security Hub ficam ativos em toda a organização, com a Security Tooling como administradora delegada, para que contas novas sejam cobertas automaticamente.
4. As descobertas vão para o seu SIEM ou para as ferramentas de plantão.

Rede

As contas de workloads são donas das suas VPCs, mas não da sua conectividade. A conta Network fornece um Transit Gateway compartilhado pelo Resource Access Manager, saída e inspeção centralizadas, resolução de DNS entre nuvem e data center e um plano de endereços IP, de preferência gerenciado com o Amazon VPC IP Address Manager para que duas VPCs nunca se sobreponham. O diagrama de VPC da AWS cobre o que fica dentro de cada VPC de workload, e o diagrama de arquitetura multirregião da AWS cobre como estender o projeto para várias regiões.

Como montar: Control Tower ou Terraform

O AWS Control Tower configura a organização, as contas centrais, um trail de organização, o Config e um catálogo de controles, e oferece o Account Factory para criar contas novas. A versão 4.0 da landing zone, lançada em 17 de novembro de 2025, o deixou bem mais flexível, segundo as notas de versão do Control Tower:

• As integrações com AWS Config, CloudTrail, funções de segurança e AWS Backup ficaram opcionais.
• Uma OU Security não é mais obrigatória; você pode definir a sua própria estrutura de OUs.
• Uma configuração mínima pode usar só a integração com o Organizations e os controles.
• Config e CloudTrail ganham recursos dedicados, e um agregador do Config vinculado ao serviço substitui a agregação antiga.

Times de Terraform costumam combinar o Control Tower com o Account Factory for Terraform (AFT), que provisiona e personaliza contas a partir de um repositório Git. Desde setembro de 2026, o AFT pode executar as personalizações em modo somente plano, para pré-visualizar as mudanças antes de aplicá-las. Outros gerenciam o Organizations inteiramente com Terraform ou usam a solução Landing Zone Accelerator on AWS. As três funcionam; o que importa é que a criação de contas seja automatizada e repetível.

Vending de contas

Contas novas devem chegar prontas para uso: uma solicitação, muitas vezes um pull request, cria a conta na OU certa, aplica a linha de base (atribuições do Identity Center, orçamentos e alertas, uma VPC ligada ao Transit Gateway, serviços de segurança padrão) e entrega a conta ao time. O Organizations limita uma organização a 10 contas por padrão, um valor ajustável pelo Service Quotas; então peça o aumento antes de precisar.

Erros comuns

• Workloads na conta de gerenciamento, onde nenhuma SCP se aplica.
• Uma única OU Workloads sem divisões, de modo que produção e desenvolvimento compartilham guardrails.
• Guardrails escritos depois que os times já construíram sobre premissas que eles quebram.
• Uma conta Log Archive que os administradores conseguem alterar.
• Contas criadas à mão, cada uma um pouco diferente.

O diagrama da landing zone

Como ler:

• A conta de gerenciamento no topo guarda a organização e as políticas; as arestas dela para cada OU são anexos de guardrails.
• A OU Security contém a Log Archive, que recebe logs de todas as contas, e a Security Tooling, que administra GuardDuty e Security Hub.
• A OU Infrastructure contém a conta Network, cujo Transit Gateway conecta as VPCs das workloads, e a Shared Services para CI/CD.
• A OU Workloads separa as contas Prod e Non-prod; a OU Sandbox fica isolada.
• O IAM Identity Center, à direita, dá acesso às pessoas por conjuntos de permissões.
• O bloco Markdown lista os guardrails iniciais.

Desenhar estruturas de contas com clareza

• Desenhe as OUs como contêineres e coloque as contas dentro delas; a hierarquia é o modelo de políticas.
• Mostre a conta de gerenciamento à parte. Ela fica fora dos seus guardrails, e a figura deve dizer isso.
• Desenhe só os fluxos que atravessam contas: logs para o arquivo, conexões de rede, administração delegada, identidade.
• Nomeie as contas pela função, não pelo número da conta.

Para o modelo de segurança por trás disso, veja o diagrama de arquitetura zero trust. Se você gerencia infraestrutura como código, o diagrama de arquitetura Terraform mostra como desenhar ambientes gerenciados com Terraform.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione um nó Política do pack Segurança para a conta de gerenciamento e um Provedor de identidade para o IAM Identity Center.
3. Adicione quatro nós Moldura do pack Básico para as OUs: Security, Infrastructure, Workloads e Sandbox.
4. Em Security, adicione um nó Armazenamento de objetos do pack Nuvem para a Log Archive e um nó Alerta do pack DevOps para a Security Tooling. Em Infrastructure, adicione um Roteador do pack Rede para a conta Network e um Pipeline de CI/CD do pack DevOps para a Shared Services.
5. Adicione nós Instância de computação do pack Nuvem para as contas Prod, Non-prod e Sandbox.
6. Ligue a conta de gerenciamento a cada OU, as contas à Log Archive e a conta Network às workloads, e adicione um bloco Markdown do pack Básico com os guardrails.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O que é uma landing zone da AWS? Um ambiente da AWS com várias contas, configurado de acordo com os seus padrões de segurança e operação antes de as workloads chegarem: unidades organizacionais, contas centrais, identidade, guardrails, logs e rede.

Preciso do AWS Control Tower para ter uma landing zone? Não. O Control Tower é a forma gerenciada de montar uma, e a versão 4.0 o deixou mais flexível. Você também pode gerenciar o Organizations com Terraform, Account Factory for Terraform ou o Landing Zone Accelerator.

Qual é a diferença entre uma SCP e uma RCP? Uma SCP limita o que as entidades principais das contas-membro podem fazer. Uma RCP limita o que pode ser feito com os recursos das contas-membro, por exemplo impedindo que buckets sejam compartilhados fora da organização. Nenhuma das duas concede permissões.

Por que a conta de gerenciamento deve ficar vazia? SCPs não se aplicam a usuários e funções da conta de gerenciamento, então tudo o que estiver ali fica fora dos seus guardrails. Ela também controla o faturamento e a própria organização, o que a torna a conta mais sensível que você tem.

Quantas contas uma organização pode ter? Dez por padrão. A cota é ajustável pelo Service Quotas, e só a conta de gerenciamento pode pedir o aumento.

Comece grátis — um assento, sem cartão de crédito.