Landing Zone e AWS Organizations: Como Estruturar uma Arquitetura Multi-Conta Segura e Escalável

Eduardo Souza | CEO Dominit

Toda empresa que começa na AWS com uma única conta eventualmente chega a um ponto de inflexão: times diferentes, ambientes diferentes e níveis de risco diferentes, todos misturados na mesma conta, sem isolamento real entre eles. Uma Landing Zone bem desenhada, construída sobre o AWS Organizations, resolve esse problema antes que ele vire incidente de segurança ou gargalo de governança. Neste guia avançado, você vai entender o que é uma Landing Zone na prática, como estruturar uma hierarquia de contas que escala, e como o AWS Control Tower automatiza boa parte dessa fundação.

O Que É uma Landing Zone e Por Que uma Única Conta Para de Funcionar

Uma Landing Zone é a fundação multi-conta de uma organização na AWS: uma estrutura pré-configurada de contas, políticas de governança, identidade centralizada e controles de segurança que servem de base para toda a operação futura — não é um produto único, é uma arquitetura de referência.

O modelo de conta única para de funcionar por motivos que vão além de “ficar bagunçado”: ambientes de produção e desenvolvimento compartilhando limites de billing e permissão tornam impossível isolar o impacto de um erro de configuração; equipes diferentes competindo pelos mesmos limites de serviço (service quotas) da conta; e, mais criticamente, um único ponto de comprometimento de segurança expondo toda a operação da empresa de uma vez, em vez de apenas uma fração isolada dela.

AWS Organizations: a Fundação de Qualquer Estratégia Multi-Conta

O AWS Organizations é o serviço que permite gerenciar múltiplas contas AWS como uma hierarquia única, com faturamento consolidado e políticas aplicadas centralmente. A estrutura típica organiza contas em unidades organizacionais (OUs) por função ou nível de risco, não apenas por time:

OU de Segurança — contas dedicadas a funções de segurança centralizadas: logging centralizado, auditoria e ferramentas de detecção de ameaças, isoladas do resto da operação.

OU de Infraestrutura Compartilhada — hospeda recursos usados por toda a organização, como a conta de rede central num modelo de Transit Gateway hub-and-spoke.

OUs de Carga de Trabalho — segregadas tipicamente por ambiente (produção, homologação, desenvolvimento) e, em empresas maiores, também por unidade de negócio ou aplicação.

OU Sandbox — contas isoladas para experimentação, com guardrails mais permissivos, mas sem acesso a dados reais de produção.

Service Control Policies: o Guardrail Que Nenhuma Conta Individual Pode Contornar

Service Control Policies (SCPs) definem o teto máximo de permissão possível para todas as contas dentro de uma unidade organizacional — mesmo que uma política IAM local dentro da conta permita uma ação, a SCP aplicada na hierarquia acima pode bloqueá-la de forma absoluta.

Isso transforma governança de algo que precisa ser reforçado individualmente em cada conta (e, portanto, sujeito a erro humano e inconsistência) em uma camada centralizada e auditável: por exemplo, impedir que qualquer conta de desenvolvimento crie recursos fora de uma região específica, ou impedir que contas de sandbox desabilitem logging de auditoria — regras que se aplicam de cima para baixo, sem depender da configuração local de cada conta.

AWS Control Tower: Automatizando a Fundação da Landing Zone

Construir uma Landing Zone do zero, manualmente, é um projeto de arquitetura significativo — o AWS Control Tower existe para automatizar boa parte dessa fundação: provisiona a estrutura inicial de OUs, aplica guardrails pré-configurados alinhados a boas práticas, e integra AWS Organizations, IAM Identity Center e logging centralizado numa configuração coerente desde o início.

Isso não elimina a necessidade de decisões de arquitetura específicas da empresa — mas reduz drasticamente o tempo até ter uma fundação multi-conta funcional e alinhada a boas práticas, em vez de reconstruir cada peça manualmente e correndo o risco de deixar lacunas de segurança na configuração inicial.

Provisionamento de Contas: Account Factory e Padronização

Uma vez que a Landing Zone está no lugar, o desafio se torna provisionar novas contas de forma consistente conforme a empresa cresce — sem que cada conta nova exija configuração manual repetida do zero. O Account Factory do Control Tower automatiza esse provisionamento, aplicando automaticamente a estrutura de rede, guardrails e identidade padrão a cada conta nova criada.

Isso garante que uma conta criada hoje tenha exatamente o mesmo nível de governança de segurança que uma conta criada há um ano — um problema comum em empresas que cresceram organicamente sem uma Landing Zone formal é ter contas antigas com configuração de segurança significativamente mais fraca que contas criadas mais recentemente, simplesmente porque o padrão de configuração evoluiu no meio do caminho sem retroagir às contas existentes.

Identidade Centralizada: Conectando a Landing Zone ao Resto da Governança

Uma Landing Zone bem estruturada depende de identidade centralizada para realmente funcionar como governança única, não como um conjunto de contas isoladas com identidades próprias. O AWS IAM Identity Center, integrado nativamente ao Control Tower, permite que o acesso a qualquer conta da organização seja controlado a partir de uma única fonte de identidade — a mesma base que sustenta uma estratégia mais ampla de Zero Trust e IAM avançado.

Sem essa centralização, cada conta nova tende a acumular seus próprios usuários IAM locais, replicando exatamente o problema de gestão de identidade fragmentada que a Landing Zone deveria resolver.

Erros Comuns ao Estruturar uma Landing Zone

Os mesmos erros de estruturação aparecem repetidamente em empresas que constroem uma arquitetura multi-conta sem planejamento prévio:

Estrutura de OUs baseada em organograma da empresa, não em nível de risco — replicar a estrutura de departamentos da empresa na hierarquia de contas costuma gerar OUs que não correspondem a diferenças reais de política de segurança necessária.

Ausência de conta de logging centralizado desde o início — adicionar isso depois que dezenas de contas já existem é significativamente mais trabalhoso do que estabelecê-lo como parte da fundação inicial.

Guardrails aplicados de forma tão restritiva que forçam exceções constantes — SCPs mal calibradas que impedem operações legítimas do dia a dia acabam sendo contornadas ou relaxadas de forma ad-hoc, corroendo o valor da governança centralizada.

Falta de processo formal para criação de conta nova — permitir que contas sejam criadas fora do Account Factory, sem herdar automaticamente os guardrails padrão, recria o problema de inconsistência que a Landing Zone deveria eliminar.

Como Migrar uma Operação Existente para uma Landing Zone Formal

Empresas que já operam com múltiplas contas AWS desorganizadas, sem uma Landing Zone formal, normalmente seguem uma migração gradual:

Estabeleça a estrutura de Organizations e OUs primeiro, mesmo antes de mover qualquer conta existente — a fundação organizacional pode ser criada independentemente da migração das contas de carga de trabalho.

Migre contas de menor risco primeiro, validando que os guardrails aplicados não quebram operações legítimas antes de migrar contas de produção crítica.

Trate identidade centralizada como pré-requisito, não como etapa posterior — migrar contas para dentro da Landing Zone sem resolver identidade centralizada primeiro recria fragmentação que precisará ser corrigida depois de qualquer forma.

Esse tipo de migração costuma se beneficiar de um parceiro certificado AWS com experiência prévia em Landing Zone — decisões de estrutura de OU tomadas incorretamente no início são caras de reverter depois que dezenas de contas já dependem delas.

Perguntas Frequentes Sobre Landing Zone e AWS Organizations

Minha empresa precisa de uma Landing Zone com apenas 2 ou 3 contas AWS?

O benefício cresce com o número de contas, mas mesmo estruturas pequenas se beneficiam de separar, no mínimo, produção de não-produção, e centralizar identidade desde o início — é mais fácil manter essa disciplina desde o começo do que retrofita-la depois.

AWS Control Tower é obrigatório para ter uma Landing Zone?

Não, mas automatiza significativamente o trabalho de configurar a fundação — é possível construir uma Landing Zone manualmente com AWS Organizations puro, mas isso exige mais esforço de arquitetura e manutenção contínua.

O que são Service Control Policies e como elas diferem de políticas IAM?

SCPs definem o teto máximo de permissão possível para contas inteiras dentro de uma unidade organizacional; políticas IAM concedem permissão dentro desse teto. Uma SCP pode bloquear uma ação mesmo que a política IAM local a permita, mas nunca o contrário.

Como decido a estrutura certa de unidades organizacionais (OUs)?

Baseando a estrutura em nível de risco e função (segurança, infraestrutura compartilhada, produção, desenvolvimento, sandbox), não no organograma da empresa — a estrutura de OUs deveria refletir diferenças reais de política de segurança necessária.

É possível migrar contas AWS existentes para dentro de uma Landing Zone?

Sim, é um processo comum e bem documentado pela AWS, mas exige planejamento cuidadoso — geralmente começando pela fundação organizacional e migrando contas de menor risco antes das críticas.

Landing Zone Como Investimento em Governança Que Escala com a Empresa

Uma Landing Zone bem estruturada não é sobre ter mais contas AWS por si só — é sobre ter uma fundação de governança, segurança e identidade que escala de forma consistente conforme a empresa cresce, em vez de se tornar mais frágil e mais difícil de auditar a cada conta nova adicionada de forma improvisada.

As empresas que investem nessa fundação antes de precisar dela por urgência são as que conseguem crescer em número de contas, times e projetos sem que governança vire um ponto cego cada vez mais caro de corrigir.