Blog/Artigos · Cloud e Plataforma
Estratégia multi-conta, AWS Organizations e OUs, SCPs e Control Tower, o baseline herdado e a fábrica de contas.
O provérbio diz que o justo é fundação eterna: o que sustenta o resto é o que foi bem posto por baixo, invisível, antes de tudo o que se vê. Em nuvem, a pressa faz o oposto. A empresa cria uma conta, sobe o primeiro serviço, e vai empilhando tudo ali: produção, teste, dado sensível, experimento, tudo na mesma conta, sem fronteira. Funciona por uns meses e vira uma bola de lama impossível de governar, onde um erro em teste derruba produção e ninguém consegue dizer quem paga o quê. Landing Zone é a recusa dessa pressa: lançar a fundação primeiro, a estrutura de contas, os limites e o baseline, para que tudo o que se erguer depois assente sobre chão firme, e não sobre areia.
A conta única é a dívida técnica mais cara da nuvem, porque cresce em silêncio. No começo, tudo numa conta é simples. Com o tempo, produção e teste dividem o mesmo espaço, o limite de recursos de uma atinge a outra, o dado sensível convive com o experimento, e a fatura vira um caldeirão onde ninguém consegue atribuir custo a um time ou projeto. Pior: o raio de dano de qualquer erro é a conta inteira. Uma permissão ampla demais, um script equivocado, e não há fronteira para conter o estrago. A areia cede quando o prédio fica pesado.
Landing Zone é o nome que a AWS deu à fundação bem lançada: um ambiente multi-conta, seguro e governado, pronto para receber cargas antes de a primeira carga chegar. Não é um produto único; é um padrão de arquitetura que combina estrutura de contas, controles centralizados e um baseline comum. Lançar a Landing Zone antes de migrar ou construir é o que separa a nuvem que escala com ordem da que vira bola de lama. É o justo por baixo: invisível para quem só vê os serviços em cima, mas é ele que sustenta o peso quando a empresa cresce.
O coração da Landing Zone é a estratégia multi-conta, organizada pelo AWS Organizations. Em vez de uma conta gigante, há muitas contas pequenas, agrupadas em unidades organizacionais, as OUs, por ambiente e por função: uma OU de produção, uma de não-produção, uma de segurança, uma de infraestrutura compartilhada. Cada carga vive na sua conta, e a conta vira a unidade natural de isolamento: de segurança, porque o comprometimento de uma não alcança a outra; de custo, porque a fatura por conta atribui o gasto sem esforço; e de blast radius, porque o erro fica preso à conta onde aconteceu.
Essa fronteira é a mais forte que a nuvem oferece, mais forte que qualquer permissão dentro de uma conta, porque é uma separação de conta inteira, não de política interna. É por isso que a recomendação madura é generosa com contas: uma conta por carga e ambiente não é exagero, é a fronteira que contém o dano no menor escopo possível. A conta de segurança, isolada, guarda os logs e as chaves de forma que nem um administrador comprometido de produção alcance. A fundação não é só ter contas; é desenhar a árvore de OUs para que a fronteira caia exatamente onde o risco precisa ser contido.
A fundação não seria firme se cada conta pudesse fazer qualquer coisa. Os guardrails da organização são os limites que valem para todas as contas de uma OU, aplicados de cima, que nem o administrador da conta consegue remover. A ferramenta central são os SCPs, as Service Control Policies: elas não concedem permissão, elas definem o teto do que é possível numa conta. Um SCP pode proibir desligar o log de auditoria, impedir criar recurso fora das regiões aprovadas, ou bloquear o uso de serviços não homologados, e essa proibição vale mesmo para quem tem privilégio de administrador na conta.
O AWS Control Tower automatiza a montagem disso, entregando uma Landing Zone com guardrails prontos, preventivos e detectivos, e um painel de conformidade. É a mesma distinção do Policy as Code, agora no nível da organização: o guardrail preventivo barra, o detectivo alerta. O poder está em que o limite é estrutural, não depende de vigilância. Numa conta de produção regulada, o SCP que impede desligar o CloudTrail garante a trilha de auditoria por construção, e não por confiança de que ninguém vai desligá-la. A fundação firme é a que põe o limite onde nem o poder máximo da conta o alcança.
A fundação inclui um baseline comum que toda conta nova herda no instante em que nasce: log de auditoria já ligado e enviando para a conta de segurança central, rede já configurada segundo o padrão, identidade integrada ao provedor central, alarmes básicos e tags de custo. Sem baseline, cada conta nova é uma folha em branco que alguém configura à mão, esquecendo metade e abrindo brechas. Com baseline, a conta nasce já governada, segura e observável, sem trabalho manual repetido e sem a variação que o trabalho manual sempre introduz.
É aqui que entra a fábrica de contas, o account vending: um processo, idealmente por IaC, que provisiona uma conta nova completa a partir de um pedido, com todo o baseline aplicado. Um time pede uma conta, e recebe minutos depois uma conta pronta para uso, dentro da OU certa, com os guardrails, o log e a rede no lugar. Isso transforma a criação de conta de um projeto manual arriscado em autosserviço governado, e é o que permite ser generoso com contas sem que a governança vire gargalo. A fábrica é o golden path da Landing Zone: o jeito fácil de nascer uma conta é também o jeito certo, governado por construção.
Ser generoso com contas deixa de sobrecarregar a governança: o jeito fácil de nascer uma conta é também o governado, por construção.
A Landing Zone amadurece da conta única à fundação viva. No começo é tudo numa conta, a bola de lama. Depois vem a separação em poucas contas, feita à mão. No meio é o Organizations com OUs e SCPs, a estrutura desenhada. No topo é a Landing Zone completa, com fábrica de contas por IaC, baseline verificado continuamente e guardrails coerentes com a governança. Cada degrau põe mais chão firme por baixo, e o esforço é maior no início, quando ninguém vê o benefício, e impagável depois, quando a empresa cresce sem virar caos.
A fundação sustenta tudo o que vem por cima neste eixo. É sobre a Landing Zone que a migração para a nuvem aterrissa, que o IaC provisiona, que a plataforma constrói o golden path, que o disaster recovery organiza suas contas de recuperação. Fundar antes de construir não dá retorno visível no primeiro mês, e é exatamente por isso que tanta empresa pula essa etapa e paga caro depois, reorganizando na marra uma nuvem que virou bola de lama. O justo é fundação eterna: o que se lança bem por baixo é o que permite erguer alto sem medo de o prédio ceder.
Landing Zone é a fundação lançada antes de erguer a nuvem: estrutura multi-conta que isola o dano, guardrails da organização que põem o limite acima do administrador, e um baseline que toda conta herda por uma fábrica de contas. É o justo por baixo, invisível mas indispensável, e a etapa que a pressa pula e paga caro quando a conta única vira bola de lama. A IA planeja a saída do caos, revisa os SCPs e verifica o baseline. Mas desenhar a árvore de contas e decidir onde a fronteira do risco precisa cair continua sendo arquitetura de quem responde pela nuvem inteira.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaעַמּוּדִים
Nuvem não perdoa arquitetura improvisada. O Well-Architected dá seis pilares e um método de perguntas para tornar a decisão explícita, e a maturidade está em admitir que os pilares se contradizem e escolher a compensação de olhos abertos.
Cloud e Plataformaמַעֲקֶה
O que é seu e o que é do provedor, como montar guardrails em camadas, por que identidade é onde o ataque acontece e como a IA prioriza e corrige postura.
