DEV Community

Cover image for [pt-BR] AWS Landing Zones na prática - Parte 1
Plínio Balduino
Plínio Balduino

Posted on

[pt-BR] AWS Landing Zones na prática - Parte 1

#ptbr #aws #architecture

Quando uma organização começa a utilizar AWS, é relativamente comum que tudo nasça dentro de uma única conta.

No começo, isso parece razoável. Uma conta contém algumas VPCs, aplicações, bancos de dados, buckets e usuários. Com o crescimento do ambiente, porém, começam a surgir perguntas mais difíceis:

Produção e desenvolvimento deveriam estar na mesma conta?, Onde devem ficar os logs de auditoria?, Como impedir que uma equipe desative controles de segurança?, Como conceder acesso a dezenas ou centenas de contas?, Como garantir que novas contas sejam criadas seguindo os mesmos padrões?, Como aplicar políticas corporativas sem configurar cada conta individualmente? e Como separar workloads, segurança, infraestrutura compartilhada e billing?.

É nesse contexto que surge o conceito de Landing Zone.

O que é uma Landing Zone?

A AWS define uma Landing Zone como um framework de orquestração para o ambiente AWS fundamental da organização.

Ela estabelece uma baseline para aspectos como:

arquitetura multi-account, Identity and Access Management, governança, segurança de dados, arquitetura de rede, logging, estrutura de contas, billing e mecanismos de customização..

Portanto, uma Landing Zone não é simplesmente uma VPC preparada para receber aplicações.

Também não é apenas uma estrutura de AWS Organizations.

E não é sinônimo de AWS Control Tower.

Uma maneira útil de pensar no conceito é:

A Landing Zone é a fundação sobre a qual os workloads da organização serão construídos.

Antes de migrarmos ou criarmos aplicações, estabelecemos as regras do terreno.

Uma arquitetura multi-account

Um dos princípios centrais de uma Landing Zone é utilizar AWS Accounts como fronteiras de isolamento.

Em vez de construir algo como:

AWS Account
├── VPC Development
├── VPC Staging
├── VPC Production
├── Security
├── Logs
└── Shared Services
Enter fullscreen mode Exit fullscreen mode

podemos estabelecer uma estrutura semelhante a:

AWS Organization
│
├── Security OU
│   ├── Log Archive Account
│   └── Audit Account
│
├── Infrastructure OU
│   ├── Network Account
│   └── Shared Services Account
│
├── Workloads OU
│   ├── Development Account
│   ├── Staging Account
│   └── Production Account
│
└── Sandbox OU
    ├── Developer A
    └── Developer B
Enter fullscreen mode Exit fullscreen mode

Essa separação cria fronteiras mais fortes entre workloads e responsabilidades.

Uma falha de configuração em uma conta de desenvolvimento, por exemplo, não precisa conceder acesso aos recursos da conta de produção.

A AWS recomenda que workloads de produção não sejam executados na management account de uma organização gerenciada pelo Control Tower.

O que uma Landing Zone deve resolver?

Segundo a AWS Prescriptive Guidance, a configuração inicial deve tratar pelo menos de estrutura de contas, identidade, governança, segurança, rede, logging, billing e mecanismos de customização.

Estrutura de contas

É necessário definir como as AWS Accounts serão organizadas e quais Organizational Units (OUs) serão utilizadas.

Por exemplo:

Root
├── Security
├── Infrastructure
├── Workloads
└── Sandbox
Enter fullscreen mode Exit fullscreen mode

Estrutura de rede

A Landing Zone deve estabelecer padrões de conectividade e governança para componentes como:

VPCs, subnets, DNS, Transit Gateway, conectividade híbrida, Direct Connect, VPN, firewalls e IP Address Management..

Ela não precisa necessariamente criar toda a infraestrutura de rede de cada workload, mas deve definir como essa infraestrutura será organizada e governada.

Identity

Também é necessário definir como pessoas e sistemas acessam as contas.

Isso normalmente envolve:

IAM, IAM Identity Center, roles, permission sets e federação com provedores de identidade corporativos..

Logging e auditoria

Logs de auditoria não deveriam existir apenas dentro da própria conta que está sendo auditada.

Uma arquitetura comum centraliza esses registros em uma conta dedicada:

Application Accounts
        │
        ├── CloudTrail
        ├── AWS Config
        └── Security Logs
                │
                ▼
        Log Archive Account
Enter fullscreen mode Exit fullscreen mode

Isso reduz a possibilidade de um comprometimento da conta de workload resultar também na destruição das evidências necessárias para auditoria ou investigação.

Governance

A organização precisa determinar quais ações são permitidas ou proibidas.

AWS Organizations permite, por exemplo, utilizar Service Control Policies (SCPs) para estabelecer limites máximos de permissões.

Em vez de depender de cada equipe para configurar individualmente todos os controles, podemos estabelecer políticas organizacionais como:

Workloads não podem desabilitar determinados mecanismos de segurança.
Enter fullscreen mode Exit fullscreen mode

Landing Zone não é Control Tower

Essa distinção é importante.

A documentação da AWS diferencia duas abordagens principais:

  1. uma service-based landing zone, utilizando AWS Control Tower;
  2. uma customized landing zone, construída pela própria organização.

O AWS Control Tower é, portanto, uma implementação gerenciada do conceito de Landing Zone — não o conceito em si.

Landing Zone com AWS Control Tower

O AWS Control Tower automatiza boa parte da criação e governança de um ambiente multi-account.

Ele orquestra diferentes serviços AWS envolvidos nessa fundação, incluindo AWS Organizations, IAM Identity Center, AWS Service Catalog, AWS CloudTrail e AWS Config.

Uma estrutura inicial típica inclui:

Management Account
│
└── AWS Organization
    │
    ├── Security OU
    │   ├── Log Archive
    │   └── Audit
    │
    └── Workload OUs
Enter fullscreen mode Exit fullscreen mode

O Log Archive Account funciona como repositório central para logs, enquanto o Audit Account fornece capacidades destinadas às equipes de segurança e compliance.

Controls

Outro componente importante são os Controls, anteriormente conhecidos principalmente como guardrails.

Eles representam mecanismos de governança aplicados ao ambiente. O Control Tower trabalha com controles de diferentes comportamentos, incluindo:

preventive, detective e proactive..

Um control pode impedir determinadas operações, enquanto outro pode detectar recursos que deixaram de atender a uma regra.

Isso muda a natureza da governança:

Provisionar → Configurar → Torcer para ninguém alterar
Enter fullscreen mode Exit fullscreen mode

passa a ser:

Provisionar
     ↓
Aplicar baseline
     ↓
Monitorar continuamente
     ↓
Detectar ou impedir desvios
Enter fullscreen mode Exit fullscreen mode

Account Factory

Outro recurso importante é o Account Factory, usado para padronizar o provisionamento de novas contas.

Em vez de:

Ticket → Cloud Team → configuração manual → nova conta
Enter fullscreen mode Exit fullscreen mode

podemos caminhar para:

Solicitação
     ↓
Account Factory
     ↓
AWS Account
     ↓
Baseline
     ↓
OU
     ↓
Controls
Enter fullscreen mode Exit fullscreen mode

Isso se torna especialmente relevante em organizações que administram dezenas ou centenas de AWS Accounts.

Landing Zone customizada

Também é possível construir uma Landing Zone sem utilizar Control Tower.

Nesse cenário, podemos combinar diretamente serviços como:

AWS Organizations
+
Organizational Units
+
SCPs
+
IAM Identity Center
+
CloudTrail
+
AWS Config
+
Security Hub
+
GuardDuty
+
VPC / Transit Gateway
+
Infrastructure as Code
Enter fullscreen mode Exit fullscreen mode

Terraform, CloudFormation ou outras ferramentas podem então automatizar essa arquitetura.

Por exemplo:

Terraform
   │
   ├── AWS Organizations
   ├── Organizational Units
   ├── Accounts
   ├── SCPs
   ├── IAM
   ├── Logging
   └── Networking
   │
   ▼
Custom Landing Zone
Enter fullscreen mode Exit fullscreen mode

Nesse modelo, a organização possui maior liberdade sobre a implementação.

O preço dessa liberdade é assumir também a responsabilidade pela evolução, manutenção, testes, upgrades e tratamento de drift da plataforma.

Control Tower versus Landing Zone customizada

Aspecto Control Tower Customizada
Provisionamento inicial Mais simples Mais complexo
AWS best practices Incorporadas ao modelo Precisam ser implementadas
Flexibilidade Alta, dentro do modelo do serviço Muito alta
Governança Controls integrados Implementação própria
Account provisioning Account Factory Pipeline próprio
Manutenção Parcialmente gerenciada pela AWS Responsabilidade da equipe
Curva de aprendizado Menor Maior
Customização extrema Pode exigir adaptações Natural
Drift management Integrado ao modelo do Control Tower Precisa ser projetado
Integração com legado Pode exigir adaptação Maior liberdade

Essa comparação não significa que Control Tower seja uma solução para iniciantes e uma Landing Zone customizada seja uma solução para arquitetos experientes.

A decisão é arquitetural.

Uma organização grande pode preferir Control Tower justamente para reduzir a quantidade de plataforma que precisa manter internamente.

Outra organização pode possuir requisitos de rede, compliance, identidade ou provisionamento tão específicos que uma implementação customizada faça mais sentido.

Vantagens

Isolamento

AWS Accounts tornam-se fronteiras de segurança.

Um comprometimento em uma conta de desenvolvimento não implica automaticamente comprometimento da conta de produção.

Governança centralizada

Políticas podem ser aplicadas no nível da organização ou de uma OU:

Organization
     │
     ├── SCPs
     ├── Controls
     ├── Identity
     └── Logging
Enter fullscreen mode Exit fullscreen mode

Isso reduz configurações divergentes entre contas.

Escalabilidade organizacional

Criar a décima conta manualmente talvez seja aceitável.

Criar a conta número 500 dessa maneira provavelmente não será.

Uma Landing Zone transforma a criação e configuração de contas em uma capacidade da plataforma.

Segurança

A separação entre workloads, security, audit, logging e infrastructure reduz o blast radius e melhora a segregação de responsabilidades.

Migrações

Landing Zones são particularmente importantes em programas de cloud migration.

Antes de migrar centenas de workloads, cria-se uma fundação comum para recebê-los.

A AWS Prescriptive Guidance trata a Landing Zone como uma base segura para suportar migração e posterior customização do ambiente.

Desvantagens

Landing Zones também possuem custos arquiteturais.

Complexidade

Uma arquitetura multi-account introduz conceitos adicionais:

cross-account IAM, SCPs, Organizations, resource sharing, centralized networking, centralized logging e account lifecycle..

Para uma aplicação pequena, isso pode representar complexidade desnecessária.

Custo operacional

Mais contas normalmente significam mais infraestrutura compartilhada e serviços de governança.

Logs, AWS Config, NAT Gateways, Transit Gateway, serviços de segurança e observabilidade podem gerar custos relevantes.

Troubleshooting

Em uma arquitetura simples:

Application → Database
Enter fullscreen mode Exit fullscreen mode

o troubleshooting tende a permanecer dentro de uma conta.

Em uma arquitetura corporativa:

Application Account
        ↓
Transit Gateway
        ↓
Network Account
        ↓
Firewall
        ↓
Shared Services
Enter fullscreen mode Exit fullscreen mode

o problema pode atravessar várias fronteiras administrativas.

Restrições de governança

Governança forte também pode reduzir autonomia.

Um desenvolvedor pode possuir AdministratorAccess dentro de uma conta e ainda assim não conseguir executar determinada operação porque uma SCP estabelece um limite organizacional.

Isso é proposital, mas pode gerar atrito se a Landing Zone for mal projetada.

Quando usar?

Landing Zones fazem bastante sentido quando existe:

estratégia multi-account, múltiplos ambientes, vários times, workloads críticos, requisitos de compliance, necessidade de auditoria, migração de múltiplos sistemas, necessidade de padronização e crescimento significativo esperado..

Para um cenário como:

uma aplicação
+
uma equipe pequena
+
uma conta AWS
+
baixo requisito regulatório
Enter fullscreen mode Exit fullscreen mode

uma Landing Zone completa pode ser excessiva.

Para um cenário como:

50 aplicações
+
20 equipes
+
produção
+
requisitos regulatórios
+
múltiplas regiões
+
centenas de AWS Accounts
Enter fullscreen mode Exit fullscreen mode

a ausência de uma estratégia de Landing Zone tende a se tornar um problema arquitetural.

Control Tower ou customizada?

Uma pergunta inicial razoável é:

Existe alguma exigência concreta que impeça ou torne inadequado o uso do Control Tower?

Se a resposta for não, Control Tower normalmente merece ser considerado primeiro.

A AWS gerencia parte importante da orquestração e fornece controles, Account Factory e uma baseline baseada nas práticas recomendadas da plataforma.

Uma Landing Zone customizada passa a ser particularmente interessante quando requisitos organizacionais não se encaixam adequadamente nesse modelo.

Existe ainda uma terceira possibilidade bastante importante: Control Tower + customizações.

Não precisamos escolher exclusivamente entre:

Control Tower
Enter fullscreen mode Exit fullscreen mode

e:

Tudo construído manualmente
Enter fullscreen mode Exit fullscreen mode

Podemos ter:

AWS Control Tower
       │
       ├── baseline
       ├── governance
       ├── account lifecycle
       │
       ▼
Customizações
       │
       ├── Terraform
       ├── CloudFormation
       ├── networking
       ├── security tooling
       └── corporate standards
Enter fullscreen mode Exit fullscreen mode

Para muitas organizações, esse é um ponto de equilíbrio interessante entre padronização e flexibilidade.

Nas próximas partes

Agora temos uma distinção fundamental:

Landing Zone ≠ AWS Control Tower
Enter fullscreen mode Exit fullscreen mode

Control Tower é uma das formas de implementar e operar uma Landing Zone.

Na Parte 2, construiremos uma Landing Zone programaticamente utilizando AWS CLI, explorando AWS Organizations, AWS Control Tower, o Landing Zone Manifest e o acompanhamento das operações assíncronas.

Na Parte 3, abordaremos a implementação utilizando Terraform, transformando a fundação da organização em Infrastructure as Code e discutindo uma questão importante: quem deve ser responsável pelo lifecycle da Landing Zone — Terraform ou Control Tower?

Também veremos como o recurso aws_controltower_landing_zone do AWS Provider for Terraform permite administrar uma Landing Zone do Control Tower por Infrastructure as Code.

Referências

AWS Prescriptive Guidance — Set up a secure AWS landing zone

AWS Control Tower User Guide

AWS Control Tower — How AWS Control Tower works

AWS CLI — controltower create-landing-zone

Terraform AWS Provider — aws_controltower_landing_zone.

Top comments (0)