Provisionamento multi-conta e multi-região

Uma conta AWS deixa de ser suficiente cedo. Segurança quer isolamento, finanças quer contas separadas por centro de custo, e cada time novo quer o próprio espaço. A partir daí toda tarefa de provisionamento ganha uma segunda pergunta: em quantas contas isso precisa existir, e quem tem permissão de fazer acontecer. As três lições deste tópico cobrem os três mecanismos que a AWS oferece para responder isso, e a distinção entre eles é o que a prova mais testa aqui.

O que este tópico cobre

• CloudFormation StackSets: a diferença entre stack set, stack instance e stack, permissões self-managed contra service-managed, as roles que cada modelo exige, targets de implantação com OUs e filtros de conta, concorrência e tolerância a falhas, códigos de status como OUTDATED e INOPERABLE, detecção de drift agregada e as falhas que se escondem atrás de um status SUCCEEDED
• AWS RAM: o que um resource share contém, a regra regional e a Região home dos recursos globais, como habilitar o compartilhamento na organização sem cair na armadilha do trusted access, o modelo de permissão em duas camadas, quais tipos de recurso podem sair da organização, a divisão de propriedade entre owner e participant em uma subnet compartilhada e por que AZ IDs importam entre contas
• Service Catalog: products, portfolios e provisioned products, o launch constraint que permite provisionar sem permissões nos serviços, os cinco tipos de constraint e a escolha entre compartilhar um portfolio como referência viva ou copiar ele com um StackSet
• AWS Control Tower: a estrutura da landing zone, as contas Log Archive e Audit, controls preventivos, detectivos e proativos com o mecanismo de cada um, o Account Factory e os eventos que colocam a landing zone em drift

Por que isso importa

O guia oficial do SOA-C03 nomeia StackSets e AWS RAM na habilidade de provisionar e compartilhar recursos entre Regiões e contas, dentro de um domínio que vale 22% da prova. As questões chegam como cenários curtos: quatro de cinco contas receberam o baseline, uma pessoa toma AccessDenied em um recurso que aparece como compartilhado, um time precisa criar VPCs sem ter permissão de criar VPCs. Cada uma dessas respostas depende de reconhecer qual mecanismo o cenário descreve.

No trabalho a diferença é ainda mais concreta. Escolher StackSets onde o RAM cabia produz doze transit gateways para manter e pagar. Escolher o RAM onde o baseline era o problema deixa contas sem recorder do Config. E sem um caminho de autosserviço governado, o time de plataforma vira uma fila de tickets que só cresce.