Borda e DNS
Levar conteúdo e endpoints para perto de usuários no mundo todo e direcionar o tráfego por latência, localização e saúde. Faz parte do Domínio 3: Projetar arquiteturas de alto desempenho, 24% do conteúdo pontuado.
Registros do Route 53
Amazon Route 53
O Route 53 hospeda zonas DNS públicas e privadas. O registro alias é a extensão da AWS que a prova mais cobra.
Pontos-chave
- Tipos comuns: A (IPv4), AAAA (IPv6), CNAME, MX, NS, SOA, TXT, CAA, SRV, PTR. A AWS recomenda TXT no lugar de registros SPF.
- CNAME: aponta um nome para outro nome, nunca no apex da zona (
example.com). - Alias: aponta para recursos da AWS (CloudFront, ELB, site do S3, API Gateway, Global Accelerator, interface endpoint de VPC ou outro registro da zona), funciona no apex e consultas a recursos da AWS são gratuitas.
- Zona hospedada privada: nomes DNS resolvidos só dentro das VPCs associadas.
Na prova
"Apontar o domínio raiz para um load balancer ou CloudFront" -> registro alias, nunca CNAME. O alias também evita cobrança por consulta.
A política de roteamento decide qual registro responde a cada consulta DNS. Junto com health checks, dá failover e direcionamento de tráfego no nível do DNS.
Pontos-chave
- Geolocation responde pela localização do usuário (continente, país, estado). Crie um registro padrão ou usuários sem correspondência ficam sem resposta.
- Geoproximity roteia pela distância até os recursos e desloca carga com um bias de -99 a +99.
- Multivalue answer devolve até 8 registros saudáveis ao acaso. Não substitui um load balancer.
- IP-based roteia pelo CIDR do cliente (CIDR collections), útil para rotas por provedor. Não existe em zonas privadas.
Na prova
"Menor latência para usuários globais" -> latency, não geolocation. "Direitos de conteúdo ou idioma por país" -> geolocation. "Mandar 10% para a nova versão" -> weighted.
Políticas de roteamento do Route 53
| Política | Use para |
|---|---|
| Simple | Um único recurso, sem health check na resposta. |
| Weighted | Dividir tráfego por percentual: canário, blue/green, testes A/B. |
| Latency | Mandar o usuário para a Região com menor latência para ele. |
| Failover | Ativo-passivo: primário enquanto saudável, secundário caso contrário. |
| Geolocation | Responder pela localização do usuário: conformidade, localização. |
| Geoproximity | Rotear pela distância, com bias para aumentar ou reduzir uma área. |
| IP-based | Rotear pela faixa de IP do cliente que você conhece (CIDR collections). |
| Multivalue answer | Até 8 registros saudáveis devolvidos ao acaso. |
Os health checks do Route 53 tiram endpoints não saudáveis das respostas DNS, o que viabiliza failover entre Regiões.
Pontos-chave
- Checagem de endpoint: verificadores espalhados pelo mundo testam um IP ou domínio. O endpoint é saudável quando mais de 18% deles o consideram saudável.
- Checagem calculada: combina o resultado de outros health checks.
- Checagem por alarme do CloudWatch: segue um alarme. Obrigatória para recursos só com IP privado, porque os verificadores ficam fora da VPC.
- Roteamento failover usa a checagem do registro primário para trocar para o secundário (por exemplo, um site estático no S3).
Na prova
"Trocar para uma Região de backup automaticamente quando a primária falhar" -> roteamento failover + health check. "Saúde de um recurso privado" -> checagem baseada em alarme do CloudWatch.
Rede de entrega de conteúdo com mais de 750 pontos de presença e 15 caches regionais de borda. Guarda conteúdo estático e dinâmico perto do usuário e protege a origem.
Pontos-chave
- Origens: bucket S3, site do S3, ALB, NLB, EC2, API Gateway, URL de função Lambda, MediaPackage ou qualquer servidor HTTP. VPC origins alcançam ALB, NLB e EC2 em sub-redes privadas.
- Cache behaviors: padrões de caminho (
/images/*,/api/*) apontam para origens e políticas de cache. Padrões: TTL mínimo 0, padrão 86.400 s (24 horas), máximo 31.536.000 s (1 ano). - Origin Shield: uma camada extra de cache que reduz a carga na origem.
- Failover de origem: um origin group com origem primária e secundária, para requisições GET, HEAD e OPTIONS.
- HTTPS: o certificado do ACM para domínio próprio precisa estar em
us-east-1.
Na prova
"Usuários globais, conteúdo estático no S3, menos latência e menos carga na origem" -> CloudFront. Problema de taxa de acerto de cache aponta para política de cache e TTLs, não para uma origem maior.
O CloudFront mantém a origem privada, exige acesso assinado, bloqueia países e criptografa campos sensíveis na borda.
Pontos-chave
- Origin access control (OAC): o bucket S3 só aceita requisições assinadas pelo CloudFront. Suporta SSE-KMS e PUT/DELETE. O legado origin access identity (OAI) não é recomendado.
- URLs assinadas: uma URL por arquivo, ou clientes que não aceitam cookies. Cookies assinados: muitos arquivos restritos sem mudar as URLs. Assine com trusted key groups.
- Restrição geográfica: lista de países permitidos ou bloqueados para a distribuição inteira.
- Field-level encryption: criptografa até 10 campos de POST na borda com chave pública, e só o backend com a chave privada consegue lê-los.
- AWS WAF e Shield Standard protegem a distribuição na borda.
Na prova
"Usuários não podem acessar o bucket S3 diretamente" -> OAC. "Biblioteca de vídeos paga, muitos arquivos por assinante" -> cookies assinados. "Um link de download" -> URL assinada, não URL pré-assinada do S3 quando há CloudFront na frente.
Código que roda no CloudFront para alterar requisições e respostas. CloudFront Functions são leves e baratas, Lambda@Edge é mais capaz.
Pontos-chave
- CloudFront Functions: JavaScript, só viewer request e viewer response, abaixo de 1 ms, tamanho máximo de 10 KB, sem acesso à rede, milhões de requisições por segundo.
- Lambda@Edge: Node.js ou Python, eventos de viewer e de origem, acesso à rede, até 30 s, criado em
us-east-1. - Usos típicos de CloudFront Functions: manipular cabeçalhos, reescrever URLs e redirecionar, normalizar a chave de cache, validar tokens simples.
- Usos típicos de Lambda@Edge: chamar serviços externos, corpos maiores, escolher a origem, lógica que precisa de mais memória ou tempo.
Na prova
"Reescrever URLs ou adicionar cabeçalhos em escala massiva, menor custo" -> CloudFront Functions. "Chamar uma API de terceiros ou alterar a requisição à origem" -> Lambda@Edge.
CloudFront Functions ou Lambda@Edge
| Aspecto | CloudFront Functions e Lambda@Edge |
|---|---|
| Eventos |
|
| Runtime |
|
| Duração |
|
| Acesso à rede |
|
| Memória |
|
Global Accelerator
AWS Global Accelerator
IPs anycast fixos que colocam o usuário na rede global da AWS pela borda mais próxima e o levam a endpoints regionais saudáveis. Sem cache.
Pontos-chave
- IPs fixos: 2 endereços IPv4 anycast (4 com dual stack) que não mudam enquanto os endpoints mudam por trás.
- Protocolos: TCP e UDP, então atende jogos, IoT (MQTT) e VoIP, que o CloudFront não atende.
- Endpoints: ALB, NLB, instâncias EC2 e Elastic IPs em uma ou mais Regiões.
- Failover: detecta um endpoint não saudável e o tira de serviço em menos de 1 minuto, sem esperar cache de DNS.
- Traffic dials por Região e pesos por endpoint, além de afinidade de cliente.
Na prova
"IPs fixos para allowlist, UDP, failover regional rápido" -> Global Accelerator. "Cache de conteúdo na borda, HTTP" -> CloudFront. Os dois usam a borda, só o CloudFront faz cache.
S3 Transfer Acceleration
Amazon S3 Transfer Acceleration
Uploads e downloads mais rápidos para um bucket a longas distâncias, entrando na rede da AWS por um ponto de presença do CloudFront.
Pontos-chave
- Endpoint:
bucketname.s3-accelerate.amazonaws.com(ou o endpoint dual-stack). - Nome do bucket: precisa ser compatível com DNS e sem pontos.
- Preço: só paga pelas transferências aceleradas. Se não ficar mais rápido, não há cobrança.
- Speed Comparison tool mostra o ganho para a sua localização antes de ativar.
Na prova
"Usuários em outros continentes enviam arquivos grandes para um bucket" -> S3 Transfer Acceleration, junto com multipart upload para objetos grandes. Não CloudFront, que é voltado à entrega.