# CloudFront: 5 motivos para colocar na frente da aplicação

> Performance, custo, segurança, cache e Lambda@Edge: os 5 motivos para pôr o CloudFront na frente da sua aplicação AWS e o que cada um muda.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos, Rede
- URL: https://pages.formacaoaws.com.br/blog/cloudfront-5-motivos-para-usar/
- Aula de origem: "5 motivos para começar no CloudFront imediatamente!" (https://www.youtube.com/watch?v=ZJil_4ej1IQ)

Colocar o Amazon CloudFront na frente da aplicação melhora a velocidade, ajuda na conta, reforça a segurança, tira carga do servidor e ainda permite mexer na requisição antes que ela chegue. São cinco motivos, e este texto mostra o que cada um muda para você decidir se vale começar.

O CloudFront é o serviço de CDN da AWS. Uma CDN é uma rede com milhares de servidores colocados na frente da sua aplicação, preparados para entregar conteúdo sem que a visita precise chegar ao servidor onde a aplicação roda.

## Motivo 1: performance

Imagine a aplicação na Virgínia, nos Estados Unidos, e um usuário em Fortaleza. Sem CDN, a requisição sai da internet dele, passa por vários provedores e rotas até entrar nos Estados Unidos, chega ao servidor e volta pelo mesmo tipo de caminho. Não existe uma linha reta: o dado vai de um lado para outro até chegar.

Esse vai e volta é a latência (o round trip). Quanto mais longo o caminho, mais tempo a pessoa espera.

Com o CloudFront, o usuário é atendido por um *edge location* no Brasil, um ponto de entrega da AWS espalhado pelo mundo. Existem ainda os *regional edge caches*, que ficam em regiões da AWS. O caminho até o ponto mais próximo é bem menor, e dali em diante o dado trafega dentro da rede da AWS. A requisição não fica navegando meio perdida, indo para um canto e para outro: segue um trajeto mais direto até a aplicação.

![O mapa-múndi da aula, com os pontos de edge location (azul e roxo) e os regional edge caches (círculos laranja) espalhados pelo mundo, incluindo o Brasil](https://pages.formacaoaws.com.br/blog/assets/posts/cloudfront-5-motivos-para-usar/mapa-edge-locations.webp)

**Fluxo:** Usuário (pede a página) → Amazon CloudFront (borda, cache e segurança) → Aplicação na EC2 (recebe só o que não está no cache)

## Motivo 2: custo

Um dos custos que mais pesam na AWS, quando a estrutura já é um pouco maior, é a transferência de dados para a internet. Ela depende do volume de acessos e de quanto cada usuário baixa.

Entregar a aplicação pelo CloudFront dá uma redução de custo de cara em relação a entregar direto pela EC2, e o tamanho dela depende de onde estão o dado e o usuário. Há uma segunda redução, quando você habilita o Saving Bundle.

A conta completa, com os números, está em outros dois textos: [custo de tráfego com CloudFront e Saving Bundle](https://pages.formacaoaws.com.br/blog/custo-de-trafego-aws-cloudfront/) e [reduzir custo sem refatorar a aplicação](https://pages.formacaoaws.com.br/blog/reduzir-custo-na-aws-sem-refactor/). Aqui basta guardar a ideia: o CDN entra na conta como motivo de economia, não só de velocidade.

## Motivo 3: segurança

Todo CloudFront já vem com o AWS Shield, na versão básica, habilitado por padrão. Ele ajuda a mitigar ataques contra a aplicação sem que você configure nada.

Isso não protege de tudo. Para ir além, você pode habilitar o AWS WAF, o firewall de aplicação da AWS, que é configurável e ajuda a proteger contra ataques de DoS e outras ameaças.

> **Importante:** o Shield básico vem ligado, mas o WAF não. Se a aplicação precisa de proteção além da básica, o WAF é uma decisão sua, com regras que você escolhe.

## Motivo 4: cache

Este é o motivo que mais pesa para quem já tem uma aplicação escalando sozinha na AWS. Quanto mais páginas só de leitura você tem, mais o cache reduz a carga.

Pense em um blog. O autor escreve o post uma vez, e depois ele só é lido pelos visitantes. Cada visita é uma página de leitura. Se você coloca um cache simples nessa página, com um tempo de 900 segundos, por exemplo, o CloudFront guarda a resposta e passa a entregá-la sozinho. Só quando o tempo vence ele volta ao servidor para buscar a versão nova.

O efeito está no servidor. Sem CDN, a EC2 entrega 100% do tráfego e precisa escalar quando chega muita gente. Com o cache, o tráfego de leitura entra pelo CloudFront e não chega mais à instância. Menos tráfego batendo na instância, menos escala, menos custo.

O cache é, portanto, o ponto que junta performance e custo: a página sai mais rápido e o servidor trabalha menos.

## Motivo 5: Lambda@Edge

O Lambda@Edge permite colocar funções Lambda em pontos diferentes do CDN: depois que a requisição chega e antes de ir ao servidor, ou no caminho de volta, antes de a resposta chegar ao usuário.

Com isso você intercepta a requisição, altera o que chegou e até redireciona o usuário, conforme o que está acontecendo naquele momento. É um tópico bem mais aprofundado, e só faz sentido quando você chegar a esse nível de uso do serviço.

## Checklist

- Identifique onde estão a aplicação e os seus usuários e avalie quanto do caminho o CDN encurta.
- Compare o custo de transferência da EC2 com o do CloudFront, usando os preços atuais da sua região.
- Confirme que o Shield básico está ativo na distribuição e decida se precisa do WAF.
- Liste as páginas só de leitura e defina um tempo de cache para elas.
- Acompanhe se o tráfego de leitura deixou de chegar à EC2.
- Considere o Lambda@Edge se precisar alterar ou redirecionar requisições.

Os cinco motivos se somam, e o cache é o ponto que junta performance e custo. Se quiser ajuda para avaliar o CloudFront na sua aplicação, agende uma conversa.