Amazon SAP-C02: Complexidade Organizacional e Estratégia de Múltiplas Contas — Guia de estudos

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Faz parte do AWS Solutions Architect Professional SAP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Estratégia de múltiplas contas e provisionamento de contas

Uma estratégia de múltiplas contas (multi-account) começa com uma separação clara de responsabilidades: segurança e auditoria, rede compartilhada, workloads de produção e contas de sandbox ou de desenvolvedor. O uso do AWS Organizations com o AWS Control Tower ou uma landing zone personalizada impõe essa separação desde o primeiro dia. O Account Factory do Control Tower fornece um padrão de provisionamento de contas (account vending) que automatiza a criação de contas, papéis IAM de base, templates de VPC e guardrails, enquanto uma landing zone personalizada construída com CloudFormation/CDK e Service Catalog oferece mais flexibilidade para redes e governança sob medida. O principal trade-off é a sobrecarga operacional versus a redução do raio de impacto (blast-radius): mais contas aumentam a superfície de gerenciamento (automação, papéis entre contas, visibilidade de faturamento), mas limitam a exposição a comprometimentos de domínio e simplificam a conformidade por conta. As escolhas de rede — compartilhamento de VPC com o AWS Resource Access Manager, topologia hub-and-spoke com o Transit Gateway ou VPCs isoladas com VPC peering — direcionam os trade-offs de custo e latência. Serviços compartilhados (DNS, NAT, Active Directory) geralmente residem em uma conta de rede ou de serviços compartilhados; o provisionamento de contas deve anexar automaticamente novas contas a esses recursos compartilhados ou provisionar VPCs delegadas. Planeje cotas e automação: centralize os pipelines para artefatos de base para que a escala de contas não multiplique o trabalho manual.

Governança: SCPs, guardrails do Control Tower e políticas organizacionais

A governança em um ambiente AWS de múltiplas contas depende da aplicação de políticas no nível da organização e de controles de tempo de execução (runtime) delegados. As Service Control Policies (SCPs) estabelecem o teto para as ações permitidas entre as contas; elas são poderosas, mas implacáveis — regras de negação (deny) na OU raiz impedem que até mesmo administradores criem service-linked roles ou usem serviços, a menos que seja explicitamente permitido. O Control Tower oferece guardrails pré-construídos (obrigatórios, fortemente recomendados, eletivos) que implementam SCPs e regras do Config comuns, mas pode ser restritivo para padrões de serviço avançados. A decisão de design se concentra em governança centralizada versus delegada: uma lista de negação (deny-list) estrita no nível raiz maximiza a conformidade, mas aumenta o atrito para as equipes de produto e automação, enquanto baselines permissivos com permission boundaries e controles de papéis IAM permitem uma maior velocidade para os desenvolvedores. Políticas de log e auditoria (CloudTrail da organização, agregador do AWS Config, administradores delegados do Security Hub e GuardDuty) devem ser aplicadas a partir da conta de gerenciamento (management account) para garantir trilhas de auditoria imutáveis. Uma abordagem pragmática é a governança em camadas: SCPs da organização para restrições de alto impacto, permission boundaries para o escopo do desenvolvedor e guardrails automatizados aplicados pelo CI/CD da landing zone para manter a consistência sem bloqueios manuais.

Limites de segurança: papéis entre contas, KMS e políticas de recursos

O acesso entre contas (cross-account) é um padrão central e deve ser implementado com o mínimo de privilégios e controles de confiança fortes. O padrão comum delega o acesso por meio de papéis IAM em cada conta que entidades principais (principals) confiáveis assumem com o STS: papéis para implantação de CI/CD, monitoramento (CloudWatch/SSM) e integrações de terceiros devem exigir MFA quando apropriado e usar IDs externos para acesso de parceiros. Políticas baseadas em recursos (resource-based policies) em chaves do S3, SQS e KMS permitem acesso direto entre contas, mas o KMS adiciona complexidade: a política de uma chave KMS deve permitir explicitamente os principals e serviços da conta confiável, e grants ou grants com restrições podem ser necessários para acesso temporário. Usar uma chave KMS centralizada na conta de log ou segurança simplifica a criptografia centralizada, mas cria acoplamento operacional e potenciais considerações de disponibilidade; chaves por conta reduzem o raio de impacto (blast radius), mas multiplicam o gerenciamento de rotação de chaves e de grants. Armadilhas comuns incluem SCPs que negam inadvertidamente a criação de KMS ou de service-linked-roles, políticas de bucket que conflitam com SCPs e esquecer de adicionar o papel de delegação ao Config/CloudTrail na conta coletora. As decisões de design devem ponderar a simplicidade administrativa, o princípio do menor privilégio e a latência entre contas.

Padrões de logging centralizado, faturamento e automação

O logging e o faturamento centralizados são a espinha dorsal da visibilidade corporativa. Um CloudTrail organizacional com trilhas entregues a um bucket S3 em uma conta centralizada de segurança ou auditoria garante a captura de eventos à prova de adulteração; complemente com filtros de assinatura do CloudWatch Logs para o Kinesis Data Firehose para análise e agregue os dados do Config com um agregador na mesma conta. A visibilidade de custos requer faturamento consolidado no Organizations, Cost Explorer, Budgets e Cost and Usage Reports entregues de forma centralizada; a governança de tags e a aplicação automatizada de tags por meio de regras do Config melhoram a precisão do estorno (chargeback). Padrões de automação que escalam entre contas geralmente usam um pipeline de CI/CD compartilhado ou uma conta de implantação que assume perfis (roles) de implantação entre contas, ou CloudFormation StackSets com um administrador delegado para provisionamento em massa. Use o Systems Manager Automation e o State Manager para patching e configuração entre contas, mas lembre-se de que cada conta deve conceder os perfis (roles) e as permissões do SSM necessários. Os trade-offs equilibram centralização e latência: a agregação central reduz o armazenamento duplicado e simplifica a análise, mas cria dependências de rede e disponibilidade; o logging distribuído duplica dados, mas isola falhas. Planeje a retenção, as regras de ciclo de vida, a replicação entre regiões para DR e o gerenciamento de chaves de criptografia de forma consistente com os requisitos de conformidade.

Problema Prático: Cenário de Caso de Uso

Cenário: A Contoso Media opera um ambiente AWS corporativo com o Organizations e o Control Tower implementados. Eles têm uma conta de gerenciamento, uma conta de rede de serviços compartilhados e 20 contas-membro executando cargas de trabalho de produção, homologação e desenvolvimento em duas Regiões.

Desafio: A Contoso precisa integrar (onboard) 15 novas contas de projeto rapidamente, garantindo logging centralizado, guarda-corpos (guardrails) de SCP apropriados, conectividade de rede automatizada com a conta de serviços compartilhados via Transit Gateway e pipelines de implantação que não exijam configuração manual do IAM por conta.

Abordagem Recomendada:

1. Use o Control Tower Account Factory ou um fluxo de trabalho automatizado da API do AWS Organizations para fornecer (vend) contas com um template de linha de base (baseline) do CloudFormation/CDK que registra a conta no AWS Config, habilita um CloudTrail organizacional apontando para o bucket S3 da conta de auditoria e aplica as tags necessárias.
2. Anexe SCPs no nível da OU que apliquem negações de alto impacto (por exemplo, negar a exclusão de chaves entre regiões e regiões não permitidas), mantendo as OUs de permissão de desenvolvimento menos restritivas; valide as SCPs em um ambiente de sandbox antes da aplicação em larga escala.
3. Configure o Transit Gateway na conta de rede de serviços compartilhados e crie anexos (attachments) para o anexo da VPC do Transit Gateway de cada nova conta usando Infraestrutura como Código e um administrador delegado ou um perfil (role) entre contas que o processo de fornecimento assume para automatizar a criação de anexos e a propagação de rotas.
4. Provisione um pipeline de implantação de CI/CD centralizado em uma conta de ferramentas (tooling) que use perfis (roles) IAM entre contas (assume-role) criados pelo processo de fornecimento de contas; use CloudFormation StackSets (administrador delegado) ou ações do CodePipeline entre contas para o provisionamento da linha de base inicial e atualizações contínuas.

Justificativa: Automatizar o fornecimento de contas com artefatos de linha de base impõe a governança enquanto minimiza os passos manuais; delegar tarefas de rede e implantação por meio de perfis (roles) entre contas e do Transit Gateway centraliza os serviços compartilhados, reduz o raio de impacto (blast radius) e escala a integração (onboarding) sem sacrificar a segurança ou a capacidade de auditoria.

Todos os domínios · Redes e Conectividade Híbrida →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →