Distribuições e origens do CloudFront

O Amazon CloudFront é a Rede de Distribuição de Conteúdo (CDN) global da AWS, que armazena em cache e entrega conteúdo a partir de locais de borda distribuídos por mais de 400 cidades em mais de 90 países. Quando um usuário solicita conteúdo, o CloudFront o entrega a partir do local de borda mais próximo, reduzindo significativamente a latência em comparação com buscá-lo no servidor de origem.

O CloudFront não serve apenas para arquivos estáticos: ele também acelera conteúdo dinâmico, APIs e transmissão de vídeo. Ele se integra a outros serviços da AWS, como S3, ALB, Lambda@Edge, WAF e Shield, tornando-se a camada de distribuição padrão para arquiteturas modernas da AWS.

Uma distribuição do CloudFront é a principal unidade de configuração. Ela define: uma ou mais origens (onde o conteúdo está armazenado), comportamentos de cache (como diferentes caminhos de URL são armazenados em cache), configurações de segurança e níveis de preço. Você acessa o conteúdo pelo nome de domínio da distribuição (por exemplo, d1234abcdef.cloudfront.net) ou por um domínio personalizado (por exemplo, cdn.example.com), usando um registro CNAME ou ALIAS.

Após a criação, as distribuições levam de 10 a 15 minutos para serem implantadas globalmente em todos os locais de borda. As alterações em uma distribuição existente também levam vários minutos para se propagar. Historicamente, havia dois tipos de distribuição, mas atualmente todas usam a interface de configuração unificada.

Usar um bucket do S3 como origem do CloudFront é um dos padrões mais comuns. O CloudFront busca objetos no S3, armazena-os em cache nos locais de borda e atende às solicitações subsequentes a partir do cache, sem acessar o S3 novamente. Isso reduz os custos das solicitações do S3, melhora a latência para usuários globais e diminui a carga de largura de banda do S3.

Para disponibilizar um site apoiado pelo S3, você não precisa tornar o bucket público. Em vez disso, use o Origin Access Control (OAC), o substituto moderno do Origin Access Identity (OAI). O OAC concede apenas à distribuição do CloudFront permissão para ler o bucket, mantendo o S3 privado enquanto o CloudFront disponibiliza o conteúdo publicamente.

O CloudFront também oferece suporte a origens personalizadas: qualquer servidor HTTP ou HTTPS acessível pela Internet, incluindo instâncias do EC2, Application Load Balancers, endpoints do API Gateway e servidores locais. As origens personalizadas permitem que o CloudFront armazene em cache e acelere aplicações dinâmicas e APIs, não apenas arquivos estáticos.

Ao usar um ALB como origem personalizada, configure-o para aceitar conexões apenas dos intervalos de IP do CloudFront em seu grupo de segurança. Isso força todo o tráfego externo a passar pelo CloudFront, permitindo regras do WAF e encerramento de TLS na borda, enquanto mantém o ALB interno à AWS.

O Origin Access Identity (OAI) era a forma original de restringir o acesso de um bucket do S3 ao CloudFront. Trata-se de uma identidade de usuário especial do CloudFront, concedida na política do bucket do S3. Embora o OAI ainda funcione, ele é considerado legado.

O Origin Access Control (OAC) é o substituto moderno. O OAC oferece suporte a todos os tipos de bucket do S3 (incluindo o S3 nas Regiões da AWS na China e buckets criptografados com SSE-KMS), usa entidades principais de serviço do IAM para um controle mais granular e assina automaticamente as solicitações ao S3 usando SigV4. Para novas distribuições, use sempre OAC em vez de OAI.

A Viewer Protocol Policy controla como o CloudFront trata as conexões entre os usuários (visualizadores) e o local de borda:

• HTTP e HTTPS: permite ambos; não é recomendado para conteúdo confidencial
• Redirecionar HTTP para HTTPS: redireciona de forma transparente as solicitações HTTP para HTTPS; é a configuração mais comum
• Somente HTTPS: rejeita completamente as conexões HTTP; use para impor TLS rigorosamente

Separadamente, a Origin Protocol Policy controla como o CloudFront se comunica com sua origem: somente HTTP, somente HTTPS ou correspondência com o visualizador. Para origens do S3 com OAC, o CloudFront sempre usa HTTPS.

Para disponibilizar conteúdo de cdn.example.com em vez do domínio do CloudFront, configure um Nome de domínio alternativo (CNAME) na distribuição e associe um certificado SSL/TLS do AWS Certificate Manager (ACM). O certificado ACM deve estar na Região us-east-1 (independentemente de onde a sua distribuição atende ao tráfego), porque o CloudFront é um serviço global gerenciado a partir de us-east-1.

Crie o registro do Route 53 como um registro ALIAS apontando para o nome de domínio da distribuição do CloudFront. O CloudFront disponibiliza automaticamente o seu certificado para solicitações SNI correspondentes.

A Classe de preço do CloudFront controla quais locais de borda são usados para disponibilizar a sua distribuição. Classes de preço mais altas incluem locais de borda mais caros (normalmente em regiões com custos de largura de banda mais altos):

• Classe de preço 100: somente América do Norte e Europa (menor custo)
• Classe de preço 200: América do Norte, Europa, Ásia, Oriente Médio e África
• Classe de preço All: todos os locais de borda no mundo (melhor desempenho, maior custo)

Use a Classe de preço 100 para ferramentas internas ou públicos limitados à América do Norte e à Europa. Use a Classe de preço All para aplicações voltadas ao consumidor e realmente globais.

Os grupos de origem permitem o failover da origem do CloudFront. Você define uma origem primária e uma origem secundária em um grupo. Se a origem primária retornar um código de erro HTTP específico (por exemplo, 500, 502, 503 ou 504), o CloudFront tentará automaticamente realizar a solicitação novamente usando a origem secundária.

O failover da origem é útil para recuperação de desastres: mantenha um bucket S3 primário em us-east-1 e um backup replicado em us-west-2 como origem secundária. O CloudFront executa o failover de forma transparente durante uma interrupção do S3, sem exigir alterações no DNS. Esse padrão complementa a replicação entre regiões do S3.

O CloudFront pode entregar registros de acesso a um bucket S3, registrando detalhes sobre cada solicitação do visualizador: carimbo de data e hora, local de borda, código de status, bytes transferidos, acerto ou erro do cache, agente do usuário e muito mais. Os registros são entregues em lotes a cada poucos minutos.

Use os registros de acesso para analisar padrões de tráfego, identificar conteúdo muito acessado, auditar campos relevantes para a segurança (IP, referenciador e agente do usuário) e medir taxas de acerto do cache. O campo x-edge-result-type informa se a solicitação resultou em Hit, Miss ou RefreshHit na borda.

O CloudFront tem dois níveis de infraestrutura de cache:

• Locais de borda: centenas de PoPs globais próximos aos usuários finais; disponibilizam conteúdo armazenado em cache com latência mínima
• Caches de borda regionais (RECs): 13 caches maiores e de vida útil mais longa entre os locais de borda e as origens; disponibilizam conteúdo que não é popular o suficiente para permanecer nos caches pequenos dos locais de borda

Quando uma solicitação não encontra o conteúdo no cache do local de borda, o CloudFront verifica o REC antes de chegar à origem. Os RECs são transparentes — você não os configura diretamente —, mas melhoram significativamente as taxas de acerto do cache para conteúdo de cauda longa e reduzem a carga na origem.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: as distribuições do CloudFront armazenam conteúdo em cache nos locais de borda globalmente, OAC mantém os buckets S3 privados e permite o acesso do CloudFront e as origens personalizadas são compatíveis com ALBs, API Gateway e qualquer servidor HTTP. Os certificados ACM do CloudFront devem ser provisionados em us-east-1. A seguir, exploraremos os comportamentos de cache e as configurações de TTL.