Por que Landing Zones existem

Platform Engineering com AWS Landing Zones — Artigo 1

Toda empresa que cresce na AWS passa pelo mesmo lugar.

Não é um lugar bonito.

A cena

É segunda-feira. Uma auditoria pede uma coisa simples:

“Liste todas as contas AWS da empresa, com o dono de cada uma, o ambiente, e confirme que todas têm CloudTrail habilitado.”

Parece trivial. Você abre o AWS Organizations. Conta as contas.

Quarenta e sete.

Você conhece umas doze. As outras trinta e cinco existem. Foram criadas. Alguém pagou por elas.

Você exporta a lista. Começa a preencher a planilha.

Você para na linha 6.

Existem duas contas chamadas prod-payments-new e prod-payments-new-2. Ambas têm recursos rodando. Ambas custam dinheiro. Ninguém sabe qual é a de verdade.

Você roda um script para verificar o CloudTrail.

Quarenta e uma de quarenta e sete.

Seis contas de produção não têm trilha de auditoria. Você não sabe quem fez o quê nelas nos últimos dois anos. Ninguém sabe.

E a pergunta do auditor não era difícil.

O que aconteceu aqui

Nenhuma dessas contas foi criada por um vilão.

Cada uma foi criada por alguém competente, com pressa, resolvendo um problema real:

• teste-joao — o João precisava testar uma migração e não queria poluir a conta principal. Ele estava certo.
• poc-ml — o time de dados precisava de GPU e a conta principal tinha limite de quota. Eles estavam certos.
• prod-payments-new — o time de pagamentos precisava de isolamento de blast radius. Eles estavam absolutamente certos.
• prod-payments-new-2 — o primeiro -new foi criado com o e-mail errado e não dava pra renomear. Eles fizeram o que dava.

Todo mundo estava certo.

O resultado está errado.

Isso não é um problema de disciplina. É um problema de arquitetura.

Quando o caminho errado é mais fácil que o caminho certo, as pessoas vão pelo caminho errado. Não porque são preguiçosas — porque são racionais.

O caminho errado é fácil demais

Criar uma conta AWS leva três minutos: Console → Organizations → Add an AWS account → Create → pronto.

Três minutos, e você tem:

• Uma conta AWS funcional
• Sem CloudTrail
• Sem GuardDuty
• Sem AWS Config
• Sem SCP nenhuma
• Sem tags
• Sem budget
• Sem dono registrado em lugar nenhum
• Sem conexão com a rede corporativa
• Sem SSO — o criador vira root e cria access keys

Três minutos para criar. Dois anos para descobrir.

Agora compare: fazer isso direito — com baseline de segurança, rede conectada, identidade federada, tags, budget e conformidade — leva de quatro a oito horas e exige conhecimento de sete serviços diferentes.

Caminho errado:  3 minutos,  0 pré-requisitos
Caminho certo:   6 horas,    7 serviços, 1 especialista

Isso não é uma escolha. É uma armadilha de design.

E ela escala mal de um jeito específico: o custo do caminho errado não aparece na conta de quem escolheu. Aparece na auditoria, dois anos depois, na mesa de outra pessoa.

A curva do caos

O problema não é linear. É pior.

Por que a curva sobe assim?

Porque cada conta nova não adiciona um problema. Ela adiciona uma combinação.

Com 10 contas e 5 configurações que podem variar (CloudTrail, Config, GuardDuty, tags, SSO), você tem até 10 realidades diferentes para auditar.

Com 50 contas, você tem 50 realidades. E ninguém tem o mapa.

Não existe “documentar melhor” que resolva isso. O Confluence não sabe se o CloudTrail está ligado.

O que realmente custa

Vamos parar de falar de forma abstrata. O caos multi-conta cobra em cinco moedas.

1. Incidente

Uma conta sem SCP de restrição de região. Alguém sobe um cluster em ap-southeast-2 por engano. Ninguém percebe porque ninguém olha aquela região.

Descoberto na fatura, 40 dias depois. $18.000.

2. Auditoria

Cada auditoria vira um projeto. Alguém passa três semanas rodando scripts, preenchendo planilhas, perseguindo donos que já saíram da empresa.

Duas auditorias por ano × 120h = 240 horas/ano só provando que você sabe o que tem.

Você não sabe. Você descobre a cada auditoria.

3. Incidente de segurança

Access key de um ex-funcionário, criada numa conta sem SSO, sem rotação, commitada num repositório privado que virou público numa migração.

Você tem quantas access keys ativas na organização? Você sabe?

4. Onboarding

Um time novo precisa de uma conta. Abre um ticket. O ticket entra numa fila. Alguém pega em três dias. Configura em seis horas. Esquece o budget.

Nove dias. Enquanto isso, o time desenvolve na conta de outro time. E aí vira permanente.

5. Custo invisível

Contas sem tags não aparecem no chargeback. Elas caem no bucket “não alocado”.

Quanto do seu gasto AWS está em “não alocado”? Se for mais de 5%, você tem uma frota de contas órfãs.

A Landing Zone

Landing Zone é a resposta a esse problema.

E aqui vem o primeiro ponto que a maioria das pessoas erra:

Landing Zone não é um produto da AWS.

Não é o Control Tower. Não é o AFT. Não é um botão.

Landing Zone é uma decisão arquitetural: em vez de criar contas, você cria uma fundação reutilizável, e toda conta nasce dela.

A inversão

Antes:

Conta criada vazia
│
▼
Alguém lembra de configurar segurança  ← talvez
│
▼
Alguém lembra de conectar a rede       ← talvez
│
▼
Alguém lembra de aplicar tags          ← quase nunca

Depois:

Fundação (definida uma vez, em código)
│
▼
Conta nasce JÁ COM:
✅ Baseline de segurança (CloudTrail, GuardDuty, Config)
✅ Rede conectada (Transit Gateway, egress inspecionado)
✅ Identidade federada (SSO, zero access keys)
✅ Tags obrigatórias (dono, cost center, criticidade)
✅ Budget e alerta
✅ Logs indo para o Log Archive
✅ SCPs da OU aplicadas

A diferença não é a lista. É de quem é a responsabilidade.

No primeiro modelo, a segurança depende de alguém lembrar. No segundo, ela é uma propriedade da fundação. Não dá pra esquecer, porque não dá pra escolher.

O que uma Landing Zone entrega

Uma Landing Zone madura entrega oito coisas:

O item 8 é o mais esquecido — e o mais revelador.

Se você consegue criar uma conta em código mas não consegue destruí-la em código, você não tem uma Landing Zone. Você tem um gerador de contas órfãs.

O que uma Landing Zone NÃO entrega

Isso importa tanto quanto o que ela entrega:

• ❌ Não entrega workload. Ela cria a conta. O que roda dentro é problema do time.
• ❌ Não entrega arquitetura de aplicação. Landing Zone não escolhe entre ECS e EKS.
• ❌ Não substitui o time de plataforma. Ela é o produto desse time, não o substituto dele.
• ❌ Não é um projeto que termina. E esse é o assunto do próximo artigo.

Landing Zone é fundação, não prédio. Se você tentar modelar a aplicação inteira dentro dela, você construiu um monólito com outro nome.

As três estratégias — e o preço de cada uma

Você tem três caminhos. Nenhum é grátis.

A) AWS Control Tower

Você aceita a opinião da AWS sobre como uma Landing Zone deve ser.

• ✅ Log Archive e Audit accounts prontas em horas
• ✅ Guardrails pré-definidos e testados
• ✅ Account Factory funcional
• ✅ Você não precisa saber o que não sabe
• ❌ Estrutura de OU inicial é imposta
• ❌ Nomenclatura é imposta
• ❌ Drift do Control Tower é doloroso de resolver
• ❌ Terraform não é a fonte da verdade — o CT é

Escolha se: você está começando, tem menos de 20 contas, e não tem um time de plataforma dedicado.

B) Terraform puro

Você constrói tudo. Organizations, OUs, SCPs, baseline, rede.

# Você controla cada linha. Você mantém cada linha.
module "organization" {
  source = "./modules/organization"

  organizational_units = {
    security          = { parent = "root" }
    infrastructure    = { parent = "root" }
    workloads         = { parent = "root" }
    workloads_prod    = { parent = "workloads" }
    workloads_nonprod = { parent = "workloads" }
    sandbox           = { parent = "root" }
    suspended         = { parent = "root" }
  }

  service_control_policies = {
    deny_leave_org     = { targets = ["root"] }
    protect_baseline   = { targets = ["workloads"] }
    region_restriction = { targets = ["root"] }
    sandbox_limits     = { targets = ["sandbox"] }
  }
}

• ✅ Flexibilidade total
• ✅ Terraform é a única fonte da verdade
• ✅ Zero lock-in
• ✅ Você entende tudo, porque você escreveu tudo
• ❌ Meses de trabalho antes da primeira conta
• ❌ Você reimplementa coisas que a AWS já resolveu
• ❌ Você é o único suporte

Escolha se: você já tem 50+ contas com estrutura própria, ou seu compliance exige controles que o Control Tower não expõe.

C) Híbrido — Control Tower + AFT

Control Tower dá a fundação. Account Factory for Terraform dá o pipeline.

• ✅ Fundação pronta + GitOps para criação de contas
• ✅ Padrão suportado pela AWS
• ✅ Caminho mais comum em empresas médias
• ❌ Você herda as limitações do Control Tower
• ❌ AFT te amarra ao modelo de 4 repositórios dele
• ❌ Duas fontes de verdade (CT + Terraform) exigem cuidado

Escolha se: você está entre os dois extremos. Que é onde a maioria está.

A tabela de decisão

A decisão que você não pode adiar: se você vai usar Control Tower, decida antes de ter 30 contas. Adotar CT numa organização já madura é o cenário mais doloroso dos três.

O erro de framing

Aqui está o que quase toda empresa faz errado:

Trata a Landing Zone como um projeto.

Q1: kickoff
Q2: implementação
Q3: entrega
Q4: handoff para o time de operações
│
▼
...e aí?

Seis meses depois do “handoff”, as contas voltaram a divergir. Alguém criou uma conta fora da fábrica. Alguém desabilitou o Config “temporariamente”. O drift voltou.

Porque projeto termina. Caos não.

A Landing Zone precisa ser tratada como um produto — com roadmap, com usuários, com SLO, com versionamento, com on-call.

Essa é a mudança de mentalidade que muda tudo. E é o tema do Artigo 2.

O que fazer amanhã

Se você leu até aqui e reconheceu a sua empresa, comece por três coisas. Nenhuma delas exige aprovação de ninguém.

1. Faça o inventário honesto

O script abaixo assume que você já tem um profile AWS configurado para cada conta (~/.aws/config). Se você está começando agora, o primeiro passo é conseguir acesso via AWS Organizations antes de tentar automatizar isso.

# Quantas contas você tem?
aws organizations list-accounts \
  --query 'Accounts[*].[Id,Name,Email,Status]' \
  --output table

# Quantas têm CloudTrail?
for acc in $(aws organizations list-accounts --query 'Accounts[].Id' --output text); do
  echo "=== $acc ==="
  aws cloudtrail describe-trails \
    --profile "$acc" \
    --query 'trailList[*].[Name,IsMultiRegionTrail,IsOrganizationTrail]' \
    --output text 2>/dev/null || echo "SEM ACESSO / SEM TRAIL"
done

O número vai te assustar. É pra assustar. É o começo.

2. Aplique a SCP mais importante que existe

Antes de qualquer Landing Zone, antes de qualquer Terraform, aplique isto na raiz da sua organização:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityBaseline",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder",
        "securityhub:DisableSecurityHub"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/PlatformAdminRole"
        }
      }
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization"],
      "Resource": "*"
    }
  ]
}

Isso não te dá uma Landing Zone. Mas garante que ninguém pode apagar as evidências.

É o mínimo civilizatório.

3. Escolha o caminho — e escreva

Control Tower, Terraform puro, ou híbrido. Escreva a decisão num ADR (Architecture Decision Record). Um documento. Uma página.

Porque daqui a dois anos, alguém vai perguntar por que vocês escolheram assim. E a resposta “não sei, já era assim” é como você chegou aqui.

O ponto

Landing Zones não existem porque a AWS quer vender Control Tower.

Existem porque a AWS tornou trivial criar contas, e não tornou trivial governá-las.

O caminho errado é fácil. O caminho certo é caro.

A Landing Zone existe para inverter isso — para que o caminho certo seja o de menor resistência.

E quando você consegue isso, você para de ter um problema de infraestrutura e começa a ter um produto interno.

Que é o assunto dos próximos vinte e nove artigos.

Referências

AWS — Oficial

• Organizing Your AWS Environment Using Multiple Accounts — AWS Whitepaper. O documento fundador. Leia antes de qualquer coisa.
• AWS Security Reference Architecture (SRA) — o modelo canônico de contas, OUs e serviços de segurança.
• AWS Control Tower User Guide — o que ele faz e, criticamente, o que ele impõe.
• AWS Organizations — Service Control Policies — o controle preventivo mais forte da AWS.
• AWS Prescriptive Guidance — Multi-account strategy — estratégia, não tutorial.
• Account Factory for Terraform (AFT) — a implementação de referência da AWS para GitOps de contas.
• Amazon Builders’ Library — como a AWS opera sistemas em escala. Referência de rigor técnico.

HashiCorp / OpenTofu

• Terraform AWS Provider — Organizations — a base de qualquer Landing Zone em código.
• HashiCorp Well-Architected Framework — princípios de IaC em escala.
• OpenTofu — fork do Terraform sob a Linux Foundation. Relevante para quem avalia lock-in de licença.

Platform Engineering

• CNCF Platforms White Paper — define plataforma como produto interno. Base conceitual da série.
• Thoughtworks Technology Radar — Platform Engineering — estado da arte e armadilhas comuns.

Livros

• Skelton, M. & Pais, M. — Team Topologies (IT Revolution, 2019). O conceito de “thinnest viable platform” — o argumento contra construir demais.
• Forsgren, N., Humble, J. & Kim, G. — Accelerate (IT Revolution, 2018). Por que fricção de provisionamento é um problema de negócio, não de TI.

Próximo artigo

Artigo 2 — Landing Zone como Projeto vs. Landing Zone como Produto

O maior mindset shift não é técnico. É de propriedade. Projeto tem fim, tem entrega, tem handoff. Produto tem roadmap, tem usuários, tem SLO, tem on-call.

A pergunta que separa os dois: quem faz plantão da Landing Zone?

Este artigo faz parte da série “Platform Engineering com AWS Landing Zones” — sobre transformar infraestrutura em um produto interno consumível por desenvolvedores.