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

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.

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 e reduzir custo sem refatorar a aplicação. 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.

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.