Amazon CloudFront: Como o CDN da AWS Acelera Aplicações Web na Borda

A AWS opera hoje mais de 750 pontos de presença do Amazon CloudFront espalhados por mais de 100 cidades em pelo menos 50 países, além de mais de 1.140 pontos de presença embarcados adicionais na América do Norte, Europa e Ásia. Esse número não é curiosidade de marketing: é a diferença entre um usuário em São Paulo esperar o pacote de dados atravessar o Atlântico até um servidor na Virgínia ou receber a resposta de um cache a poucos quilômetros de distância. Para empresas que vendem para todo o Brasil ou operam com clientes internacionais, essa distância — medida em latência, não em quilômetros — é o que separa uma aplicação que "parece rápida" de uma que testa a paciência do usuário. Este guia explica como o Amazon CloudFront funciona, quando ele resolve um problema real de performance, como se compara a outras CDNs do mercado, e quanto custa de fato colocar uma aplicação atrás dele.

O Que É o Amazon CloudFront e Como Funciona a Rede de Edge Locations

O Amazon CloudFront é uma rede de distribuição de conteúdo (CDN) que copia arquivos estáticos e dinâmicos — HTML, CSS, JavaScript, imagens, vídeo, respostas de API — para um conjunto global de data centers chamados edge locations, e entrega essas cópias a partir do ponto mais próximo do usuário. Quando alguém acessa um site servido por CloudFront, a requisição é roteada pela rede de backbone da própria AWS até a edge location de menor latência para aquele usuário, não até o servidor de origem.

O mecanismo de cache é direto: se o objeto solicitado já está naquela edge location, o CloudFront responde imediatamente, sem tocar na origem. Se não está, o CloudFront busca o arquivo na origem configurada — um bucket do Amazon S3, um Application Load Balancer, um servidor HTTP próprio (o que a AWS chama de custom origin) — entrega ao usuário e guarda uma cópia local para as próximas requisições. Por padrão, um objeto permanece em cache por 24 horas se a origem não especificar outro tempo via cabeçalho HTTP; não há limite máximo de tempo, e o mínimo é zero segundos.

Entre as edge locations e a origem existe uma camada intermediária: os Regional Edge Caches. A AWS mantém 15 desses caches regionais, posicionados fisicamente mais perto das regiões da AWS. Eles funcionam como um segundo nível de cache — maior e com objetos que ficam armazenados por mais tempo — que absorve parte do tráfego que, de outra forma, cairia direto sobre a origem quando uma edge location não tem o objeto localmente. Isso reduz a carga na origem sem sacrificar a proximidade com o usuário final.

Um detalhe que costuma pesar pouco na decisão, mas pesa muito na conta: a transferência de dados da origem até o CloudFront é gratuita quando a origem é um serviço AWS — S3, Elastic Load Balancing, API Gateway. A cobrança recai sobre a saída de dados do CloudFront até o usuário final, não sobre o trajeto interno. Isso muda a lógica de arquitetura: colocar CloudFront na frente de uma origem AWS não duplica custo de transferência interna, só adiciona a camada de distribuição.

Os Benefícios Reais: Latência, Disponibilidade e Proteção Contra Picos

O ganho mais citado — e o mais fácil de medir — é a redução de latência. Ao encurtar o caminho de rede entre usuário e conteúdo, o CloudFront reduz o time to first byte e aumenta a taxa de transferência percebida pelo cliente, sobretudo para usuários geograficamente distantes da região AWS onde a aplicação roda. Uma aplicação hospedada em us-east-1 sem CDN entrega cada byte para o Brasil atravessando o mesmo caminho de rede público que qualquer outro tráfego internacional; com CloudFront, boa parte desse conteúdo passa a sair de uma edge location próxima ao usuário.

O segundo ganho é disponibilidade. Como o conteúdo fica replicado em centenas de pontos de presença, a falha ou sobrecarga de um único ponto não tira o serviço do ar para todos os usuários — o tráfego é redirecionado para a próxima edge location disponível. Isso também cria uma camada natural de absorção de picos: campanhas de marketing, lançamentos de produto ou eventos de mídia que geram um surto de acessos batem primeiro no cache de borda, não diretamente na origem. Uma origem dimensionada para tráfego normal não precisa ser redimensionada de emergência para aguentar um pico que o cache já resolve.

Há também o componente de segurança, frequentemente subestimado no cálculo de ROI: o CloudFront tem proteção contra DDoS sempre ativa (integrada ao AWS Shield Standard) e se integra nativamente ao AWS WAF para bloquear requisições maliciosas antes que cheguem à origem. Isso não substitui uma estratégia de segurança de aplicação, mas reduz a superfície de ataque exposta diretamente ao servidor de origem — o mesmo raciocínio de defesa em camadas que vale para qualquer arquitetura de rede bem desenhada, como discutimos no guia de VPC e Transit Gateway.

CloudFront vs Cloudflare, Akamai e Fastly: Como Escolher

Nenhuma CDN é objetivamente "a melhor" — a escolha certa depende de onde o resto da infraestrutura já está e do que a equipe já sabe operar. Para uma empresa que já roda a maior parte da stack na AWS, ficar dentro do mesmo ecossistema reduz a complexidade operacional e evita cobrança de saída de dados entre provedores diferentes. Para quem tem infraestrutura multi-cloud ou prioriza um plano de entrada gratuito e generoso, Cloudflare costuma ser a comparação mais citada.

A diferença que mais importa na prática, para uma empresa de porte médio, não é qual CDN tem mais edge locations no papel — é qual delas se integra sem atrito ao que já existe. Trocar de CDN tem custo de migração real (DNS, certificados, regras de cache, testes de regressão), e isso normalmente pesa mais que uma diferença marginal de performance entre provedores de primeira linha.

Modelos de Implementação: S3, ALB, Origem Customizada e Multi-Origem

A configuração mais simples é CloudFront na frente de um bucket do Amazon S3, típica para sites estáticos, assets de front-end e arquivos de download — um padrão que já discutimos no guia de EC2, S3 e RDS para PMEs. Nesse modelo, o bucket pode ficar privado, com acesso liberado apenas via CloudFront usando Origin Access Control, o que evita expor o S3 diretamente à internet.

Para aplicações dinâmicas, a origem costuma ser um Application Load Balancer na frente de instâncias EC2, containers ou serviços em Auto Scaling Group. Nesse caso, o CloudFront não serve só como cache — ele também atua como camada de terminação TLS, roteamento por caminho e proteção contra picos antes que o tráfego chegue ao ALB. É o desenho recomendado para aplicações que combinam conteúdo estático (que se beneficia de cache agressivo) com chamadas de API dinâmicas (que precisam passar direto para a origem).

Um terceiro modelo usa uma origem customizada — qualquer servidor HTTP que responda com os cabeçalhos corretos, dentro ou fora da AWS. Isso permite usar o CloudFront como camada de distribuição na frente de uma infraestrutura legada, de um provedor on-premises, ou até de outro provedor de nuvem, sem migrar a aplicação em si.

Distribuições mais sofisticadas combinam múltiplas origens numa única distribuição, roteando por padrão de URL: /api/* vai para o ALB, /static/* vai para o S3, /imagens/* vai para um bucket dedicado a mídia. Essa granularidade é o que separa uma configuração de CDN genérica de uma arquitetura de entrega desenhada para a aplicação específica — e é também onde entra a decisão entre Lambda@Edge e CloudFront Functions para customizar o comportamento de cada rota.

Lambda@Edge e CloudFront Functions: Onde Rodar Código na Borda

Os dois recursos permitem executar código customizado em resposta a eventos do CloudFront — mas resolvem problemas de naturezas diferentes, e a documentação da AWS é explícita sobre quando usar cada um.

CloudFront Functions é feito para lógica leve e ultrarrápida: normalização de cache key, manipulação de cabeçalhos, redirecionamentos e reescrita de URL, e validação de tokens de autorização. Roda apenas em JavaScript (compatível com ECMAScript 5.1), com execução em tempo submilissegundo e escala para milhões de requisições por segundo.

Lambda@Edge é para lógica que exige mais poder computacional: chamadas a serviços de terceiros, acesso ao corpo da requisição, manipulação de imagem sob demanda, integração com outros serviços AWS via SDK. Roda em Node.js ou Python, com até 30 segundos de execução e até 10.240 MB de memória nos eventos de origem — mas escala para até 10.000 requisições por segundo por região, uma ordem de grandeza abaixo do CloudFront Functions.

A regra prática, direto da documentação oficial: se a lógica cabe em poucas linhas e não precisa sair da borda para buscar nada, CloudFront Functions é mais barato e mais rápido. Se a lógica depende de rede, sistema de arquivos, bibliotecas de terceiros ou processamento pesado, é caso para Lambda@Edge — aceitando o custo e a latência maiores como parte do trade-off.

Quanto Custa Usar o Amazon CloudFront

O CloudFront cobra por dois itens principais: transferência de dados de saída (do CloudFront para o usuário) e número de requisições HTTP/HTTPS. A cobrança varia por região geográfica e tipo de uso, conforme a página oficial de preços pay-as-you-go — para tráfego servido a partir dos EUA, México e Canadá, o primeiro 1 TB de transferência por mês é gratuito, e a partir daí o preço cai por faixas de volume. Requisições custam por lote de 10.000: no free tier, os primeiros 10 milhões de requisições HTTP ou HTTPS por mês não são cobrados; depois disso, a cobrança gira em torno de US$ 0,0075 (HTTP) e US$ 0,0100 (HTTPS) por 10.000 requisições nessas regiões. Invalidação de cache também tem cobrança própria: os primeiros 1.000 paths ou tags invalidados por mês são gratuitos, e cada path adicional custa US$ 0,005.

Além do modelo pay-as-you-go, a AWS passou a oferecer também planos com taxa fixa mensal, que agrupam CDN, WAF, proteção DDoS, DNS, certificado TLS e computação serverless em um único preço previsível:

A escolha entre os dois modelos é, na prática, uma escolha entre previsibilidade e granularidade. Planos flat-rate facilitam orçamento e comparação com concorrentes que já cobram por assinatura, como Cloudflare — mas empresas com padrão de tráfego muito variável ou com necessidade de configuração fina por distribuição tendem a continuar no pay-as-you-go. Vale lembrar também que o CloudFront permite escolher uma Price Class por distribuição — restringir a entrega a um subconjunto de regiões geográficas reduz o custo, ao preço de latência maior para usuários fora dessas regiões. É uma decisão de arquitetura, não só de custo: uma aplicação que só atende ao Brasil não precisa pagar pela cobertura de edge locations que nunca vai usar. Esse tipo de ajuste fino é exatamente o que a prática de FinOps na AWS existe para capturar antes que vire desperdício recorrente na fatura.

Casos de Uso por Porte de Empresa

Para uma empresa pequena ou em fase de crescimento, o caso de uso mais comum e mais barato é CloudFront na frente de um site estático ou de uma SPA (single-page application) hospedada em S3 — o plano Free ou Pro cobre a maioria desses cenários sem exigir nenhuma configuração avançada, e o ganho de latência já é perceptível para qualquer usuário fora da região onde o bucket está hospedado.

Empresas de porte médio (30 a 700 funcionários, o perfil mais comum entre os clientes da DOMINIT) tipicamente chegam ao CloudFront por um de dois caminhos: proteção contra picos de tráfego em campanhas e lançamentos, ou necessidade de servir uma aplicação híbrida — parte estática, parte API dinâmica — com performance consistente para uma base de usuários já distribuída geograficamente. É também nesse porte que CloudFront Functions começa a valer a pena: normalizar cache key ou fazer redirecionamento de URL sem precisar subir e manter uma Lambda inteira para isso.

Para empresas maiores, com múltiplas aplicações, múltiplas equipes e exigência de auditoria, o CloudFront entra como peça de uma arquitetura de rede mais ampla — combinado a WAF, Shield Advanced, múltiplas origens roteadas por padrão de URL, e frequentemente como parte de uma estratégia de resiliência multi-região, como a que descrevemos no guia de Disaster Recovery na AWS. Nesse porte, a decisão deixa de ser "usar CDN ou não" e passa a ser "que fração do tráfego cada padrão de cache deve receber" — uma discussão de engenharia, não de ferramenta.

Tendências: IA na Borda, Segurança Integrada e Simplificação de Preços

Três movimentos vêm mudando o papel do CloudFront nos últimos ciclos de produto da AWS. O primeiro é a aproximação entre CDN e segurança: WAF, proteção DDoS e certificado TLS deixaram de ser complementos configurados à parte e passaram a integrar os planos com taxa fixa, sinal de que a AWS está tratando a borda como camada de segurança por padrão, não como opção avançada.

O segundo é o avanço de processamento cada vez mais próximo do usuário — não só cache de conteúdo, mas execução de lógica de negócio na borda, via CloudFront Functions e Lambda@Edge, reduzindo a necessidade de round-trip até a origem para decisões simples (personalização, autenticação leve, roteamento por geolocalização). É a mesma lógica arquitetural que sustenta o avanço de arquiteturas serverless na AWS como um todo: menos infraestrutura para gerenciar, mais código rodando sob demanda, o mais perto possível de onde a requisição se origina.

O terceiro é a simplificação de preços — os planos flat-rate são um reconhecimento de que o modelo pay-as-you-go tradicional, apesar de flexível, é difícil de prever para quem não acompanha consumo de perto. Isso tende a baixar a barreira de entrada para empresas menores que hoje evitam CDN por medo de fatura surpresa, e aproxima o modelo de cobrança do CloudFront do padrão que concorrentes como Cloudflare já praticavam.

Perguntas Frequentes sobre Amazon CloudFront

O Amazon CloudFront serve só para sites estáticos?

Não. Embora o caso mais simples seja servir arquivos estáticos a partir de um bucket S3, o CloudFront também acelera aplicações dinâmicas quando configurado na frente de um Application Load Balancer ou de uma origem customizada. Nesses casos, ele atua como camada de terminação TLS, roteamento e proteção contra picos, mesmo para conteúdo que não pode ser cacheado.

Preciso reescrever minha aplicação para usar CloudFront?

Não, na maioria dos casos. O CloudFront funciona como uma camada na frente da infraestrutura existente — a aplicação continua respondendo normalmente na origem. O trabalho de configuração está em definir origens, comportamentos de cache e, se necessário, funções de borda; não em alterar o código da aplicação em si.

Qual a diferença prática entre CloudFront Functions e Lambda@Edge?

CloudFront Functions é mais barato, mais rápido e mais escalável, mas limitado a lógica leve em JavaScript, sem acesso a rede ou sistema de arquivos. Lambda@Edge suporta Node.js e Python, acessa rede e bibliotecas externas, mas custa mais e escala menos (até 10.000 requisições por segundo por região, contra milhões por segundo do CloudFront Functions). A escolha depende da complexidade da lógica que vai rodar na borda.

O CloudFront substitui a necessidade de um WAF?

Não. O CloudFront tem proteção contra DDoS sempre ativa e se integra nativamente ao AWS WAF, mas o WAF continua sendo a camada responsável por regras específicas contra SQL injection, bots e outros padrões de ataque à aplicação. Um sem o outro deixa lacunas: CDN sem WAF protege performance, mas não filtra payloads maliciosos.

Como escolher entre o modelo pay-as-you-go e os planos com taxa fixa?

Planos com taxa fixa (Free, Pro, Business, Premium) fazem sentido para quem quer previsibilidade orçamentária e já sabe aproximadamente o volume mensal de requisições e transferência. O pay-as-you-go continua sendo mais adequado para tráfego muito variável, sazonal, ou para quem precisa de controle fino por distribuição — inclusive a escolha de Price Class para restringir a cobertura geográfica e reduzir custo.

O CloudFront funciona com origens fora da AWS?

Sim. Qualquer servidor HTTP que responda corretamente pode ser configurado como custom origin, dentro ou fora da AWS. É um caminho comum para empresas que querem os benefícios de distribuição do CloudFront sem migrar a aplicação de onde ela já está hospedada.

Existe cobrança para transferir dados da origem até o CloudFront?

Não, quando a origem é um serviço AWS como S3, Elastic Load Balancing ou API Gateway — essa transferência é gratuita. A cobrança recai sobre a saída de dados do CloudFront até o usuário final (viewer), não sobre o trajeto entre a origem AWS e a borda.

O CDN Deixou de Ser Luxo de Grande Player Para Virar Decisão de Arquitetura Básica

A distância entre "meu site funciona" e "meu site funciona rápido para qualquer usuário, em qualquer lugar" costuma ser exatamente a distância que uma CDN bem configurada resolve. O Amazon CloudFront não é a única opção do mercado, mas para quem já opera dentro do ecossistema AWS, é a que exige menos fricção para implementar — e, com os planos de taxa fixa, também a que ficou mais fácil de orçar.

O que separa uma implementação que entrega valor real de uma que só adiciona uma camada de complexidade é a mesma pergunta de sempre: qual origem, qual padrão de cache, e qual nível de lógica precisa rodar na borda. Empresas que respondem essas três perguntas antes de configurar a primeira distribuição chegam a um resultado previsível; as que pulam direto para "ativar CloudFront" descobrem depois, na fatura ou na régua de performance, o que deveriam ter decidido antes.

Artigos Relacionados

• VPC e Transit Gateway: a Arquitetura de Rede Avançada para Ambientes AWS Multi-Região — o CloudFront resolve a distância até o usuário final; a arquitetura de rede interna descrita aqui resolve a distância entre as próprias cargas de trabalho na AWS.
• Arquitetura Serverless na AWS: Lambda, Step Functions e API Gateway — Lambda@Edge é uma extensão do mesmo modelo serverless discutido neste guia, só que executando o mais perto possível do usuário.
• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — escolher Price Class e o modelo de cobrança certo do CloudFront é exatamente o tipo de decisão que uma prática de FinOps madura revisa antes que vire desperdício recorrente.
• Disaster Recovery na AWS: Estratégias Multi-Região — em arquiteturas multi-região, o CloudFront costuma ser a camada que decide para onde o tráfego vai durante um failover, tornando as duas discussões diretamente relacionadas.