Well-Architected e infraestrutura global
O exame valida projetos contra o AWS Well-Architected Framework, então este tema sustenta os quatro domínios. Infraestrutura global e responsabilidade compartilhada aparecem na Tarefa 1.1 (Domínio 1, 30%) e na Tarefa 2.2 (Domínio 2, 26%).
O framework
AWS Well-Architected Framework
Um conjunto de princípios de design, boas práticas e perguntas para construir cargas seguras, confiáveis, eficientes, econômicas e sustentáveis. A revisão é uma conversa sobre trade-offs, não uma auditoria.
Pontos-chave
- 6 pilares: excelência operacional, segurança, confiabilidade, eficiência de performance, otimização de custos e sustentabilidade.
- Cada pilar tem princípios de design, boas práticas, perguntas e um whitepaper próprio.
- Trade-offs: melhorar um pilar costuma custar outro, por exemplo um desenho multi-Região ativo/ativo aumenta confiabilidade e custo juntos.
- Lentes estendem o framework para cargas específicas, como serverless ou SaaS.
Na prova
Os quatro domínios do exame são quatro pilares. Excelência operacional e sustentabilidade não têm domínio próprio, mas aparecem como qualificadores, por exemplo "least operational overhead".
Pilares e domínios do exame
| Pilar | Onde aparece |
|---|---|
| Segurança | Domínio 1, Criação de arquiteturas seguras (30%) |
| Confiabilidade | Domínio 2, Criação de arquiteturas resilientes (26%) |
| Eficiência de performance | Domínio 3, Criação de arquiteturas de alto desempenho (24%) |
| Otimização de custos | Domínio 4, Criação de arquiteturas com custo otimizado (20%) |
| Excelência operacional | Sem domínio próprio. Aparece como "least operational overhead", automação e serviços gerenciados. |
| Sustentabilidade | Sem domínio próprio. Se sobrepõe a rightsizing, alta utilização e serviços gerenciados. |
Os princípios de design por trás dos Domínios 1 e 2. A maioria das respostas certas nesses domínios aplica um deles.
Pontos-chave
- Base de identidade forte: menor privilégio, separação de funções, identidade centralizada e nada de credenciais estáticas de longo prazo.
- Segurança em todas as camadas e rastreabilidade: defesa em profundidade da borda até o código, com toda ação registrada e com alarme.
- Proteger dados em trânsito e em repouso e manter pessoas longe dos dados: criptografia, tokenização e automação no lugar de acesso manual.
- Confiabilidade (princípios): recuperar automaticamente de falhas, testar a recuperação, escalar horizontalmente, parar de adivinhar capacidade, gerenciar mudanças com automação.
- Escalar horizontalmente: trocar um recurso grande por vários pequenos para que uma falha isolada tenha menos impacto.
Na prova
Chaves de acesso de longo prazo numa instância perdem para uma IAM role. Uma instância grande sozinha perde para um Auto Scaling group em várias AZs. As duas são esses princípios em forma de resposta.
Os princípios de design por trás dos Domínios 3 e 4: consumir tecnologia como serviço, casar com o padrão de acesso e pagar só pelo que gera valor.
Pontos-chave
- Democratizar tecnologias avançadas: consumir NoSQL, transcodificação ou ML como serviços gerenciados em vez de operá-los.
- Ficar global em minutos, usar arquiteturas serverless, experimentar com mais frequência.
- Simpatia mecânica: escolher o banco ou o armazenamento pelo padrão de acesso aos dados, não por costume.
- Custo (princípios): Cloud Financial Management, modelo de consumo, medir a eficiência geral, parar de gastar com trabalho pesado indiferenciado, analisar e atribuir gastos.
- Modelo de consumo: desligar ambientes de dev e teste fora de uma semana de 40 horas economiza cerca de 75% (40 contra 168 horas).
Na prova
"Consultas chave-valor em qualquer escala" é simpatia mecânica apontando para DynamoDB, não uma instância relacional maior. "Ambientes ociosos à noite" é o modelo de consumo: agende o desligamento.
Os dois pilares sem domínio próprio. Mesmo assim decidem muitas respostas por meio de automação, serviços gerenciados e utilização.
Pontos-chave
- Excelência operacional: organizar times em torno de resultados de negócio, ter observabilidade, automatizar com segurança, fazer mudanças pequenas, frequentes e reversíveis.
- Também: refinar procedimentos com frequência, antecipar falhas, aprender com todos os eventos operacionais e usar serviços gerenciados.
- Sustentabilidade (princípios): entender o impacto, definir metas, maximizar a utilização, adotar hardware e software mais eficientes, usar serviços gerenciados, reduzir o impacto downstream das cargas.
- Maximizar a utilização: 2 hosts a 30% são menos eficientes que 1 host a 60%, porque cada host tem um consumo de energia de base.
Na prova
Infraestrutura como código com deploys pequenos e reversíveis é a resposta de excelência operacional. Rightsizing e S3 Lifecycle para classes mais frias servem tanto a sustentabilidade quanto o custo.
Uma Região é uma área geográfica separada e isolada das outras. Cada Região tem pelo menos 3 Availability Zones, cada uma com um ou mais data centers distintos.
Pontos-chave
- Escolha da Região: compliance e residência de dados, latência para os usuários, disponibilidade do serviço e preço.
- Sem cópia automática: alguns recursos podem ser replicados entre Regiões, mas a AWS nunca faz isso por você.
- AZs têm energia, rede e conectividade redundantes, ficam a muitos quilômetros umas das outras mas dentro de 100 km (60 milhas), ligadas por rede de baixa latência que suporta replicação síncrona.
- Regiões opt-in: Regiões lançadas depois de 20 de março de 2019 precisam ser habilitadas antes do uso.
- AZ ID (ex.:
use1-az1) é a mesma zona física em qualquer conta. Nas Regiões mais antigas, o nome da AZ (ex.:us-east-1a) pode apontar para zonas diferentes em contas criadas antes de novembro de 2025.
Na prova
"Sobreviver à perda de um data center" é multi-AZ. "Sobreviver à perda de uma Região" ou "o regulador exige outra geografia" é multi-Região, que custa mais. Para alinhar zonas entre contas, use o AZ ID.
Infraestrutura fora do núcleo da Região: locais de borda para conteúdo e tráfego, e zonas ou racks que levam a AWS para perto dos usuários ou para dentro do seu data center.
Pontos-chave
- Edge locations: os pontos de presença do CloudFront guardam conteúdo perto de quem acessa. Os regional edge caches ficam entre eles e a origem e mantêm por mais tempo objetos menos populares (como funciona).
- AWS Global Accelerator: 2 endereços IPv4 anycast estáticos para TCP ou UDP que colocam o tráfego na rede global da AWS pela borda mais próxima, com failover entre Regiões conforme a saúde dos endpoints.
- Local Zones: extensão de uma Região numa área metropolitana. Habilite, crie uma sub-rede nela e rode cargas sensíveis a latência ou atenda residência de dados local (guia).
- Wavelength Zones: computação e armazenamento da AWS dentro das redes 5G de operadoras de telecom, acessadas por um carrier gateway (guia).
- AWS Outposts: racks (42U) ou servidores (1U ou 2U) gerenciados pela AWS nas suas instalações, extensão de uma AZ e da sua Região para baixa latência, processamento local e residência de dados (guia).
Na prova
"Latência de milissegundos de um dígito até um sistema on-premises" ou "os dados precisam ficar no nosso prédio" é Outposts. "Usuários numa cidade sem Região" é Local Zones. "Dispositivos móveis 5G" é Wavelength. "IP estático e aceleração TCP/UDP" é Global Accelerator, não CloudFront.
Well-Architected Tool
AWS Well-Architected Tool
Serviço no console, sem custo adicional, para revisar uma carga de trabalho contra o framework, registrar decisões e acompanhar melhorias.
Pontos-chave
- Revisão da carga: responda às perguntas dos pilares e receba os riscos identificados, altos e médios (HRIs e MRIs), mais um plano de melhoria.
- Lentes (guia): a lente do Well-Architected Framework é aplicada automaticamente. Some lentes do Lens Catalog da AWS ou suas lentes personalizadas.
- Marcos (milestones): registram o estado da carga num ponto no tempo para medir o progresso.
- Integrações: AWS Trusted Advisor e AWS Service Catalog AppRegistry ajudam a responder as perguntas da revisão.
Na prova
"Revisar uma carga contra as boas práticas da AWS e acompanhar a correção ao longo do tempo" é o Well-Architected Tool. O Trusted Advisor verifica problemas específicos na conta, ele não conduz a revisão de arquitetura.