Quando o AWS Global Accelerator foi anunciado em Novembro de 2018, muitos engenheiros se perguntaram quais seriam os reais benefícios. As principais funcionalidades do Global Accelerator são o uso da rede backbone da AWS e a seleção de região baseada em latência com failover.

Embora isso possa parecer incrível, funcionalidades semelhantes já estavam disponíveis em outros serviços da AWS há algum tempo.

Por exemplo, no CloudFront CDN, o tráfego entre a localização de borda (Edge Location) e a origem (Origin) também usa a rede interna da AWS. E o Route 53 oferece múltiplas possibilidades para DNS baseado em geolocalização, onde a região mais próxima é selecionada automaticamente, com health checks personalizáveis e possibilidades de failover.

Para entender um caso de uso para o AWS Global Accelerator, vamos comparar diferentes arquiteturas de aplicações web hospedadas na nuvem.

Resumo dos conteúdos

1. CloudFront
2. Configuração multirregional com CloudFront
3. AWS Global Accelerator sem cache
4. Aplicação multirregional com AWS Global Accelerator e CloudFront
5. Conclusão

1. CloudFront

Esta é uma arquitetura clássica para aplicações web, com requisitos de disponibilidade global. A ideia por trás dessa arquitetura é passar todo o tráfego web pelo CloudFront. Isso permite usar o cache para os ativos do site, fazer uso total da rede backbone da AWS entre a localização de borda e a aplicação de back-end.

Esquema 1. O tráfego do site passa pelo CloudFront

Vantagens desta arquitetura:

• Possibilidade de armazenar em cache os ativos do site e o tráfego principal na localização de borda, próximo ao usuário final.
• Entre a localização de borda e a origem (seu back-end), a rede interna da AWS é usada, o que permite que o tráfego passe mais rapidamente. Por exemplo, a latência entre São Paulo e Irlanda usando a rede pública pode ser de 600ms, mas através da rede da AWS geralmente é inferior a 200ms.
• Possibilidade de usar conexões SSL persistentes entre a localização de borda e a origem (aplicação de back-end). Isso permite evitar handshakes SSL entre as regiões, o que leva muito tempo devido à latência.
• Qualquer servidor pode ser usado como origem do CloudFront. Podem ser serviços da AWS como Load Balancers, ou buckets S3, ou até mesmo um IP estático, fora da rede da AWS. Isso permite aplicar a abordagem do CloudFront mesmo para aplicações não hospedadas na AWS.

Embora essa arquitetura seja ótima para os usuários finais, ela traz alguma complexidade para as operações de TI:

• O Route 53 deve ser usado como DNS para usar o registro de Alias para o domínio.
• Qualquer pequena alteração na configuração do CloudFront leva ~30 minutos para ser aplicada devido à arquitetura interna do CloudFront. (Nota de atualização: Embora ainda possa haver um atraso na propagação, a AWS tem trabalhado para reduzir esse tempo).

Vamos tentar estender essa arquitetura, adicionando múltiplos recursos de back-end em diferentes regiões.

2. Configuração multirregional com CloudFront

Para adicionar múltiplas regiões à arquitetura anterior, precisamos de alguma forma balancear o tráfego entre elas. Felizmente, o Route 53 oferece registros DNS baseados em latência, que permitem a conexão com a região mais próxima. O Route 53 também oferece health checks, então se uma região ficar offline, todo o tráfego será passado para outra região saudável.

O caminho da requisição neste caso é: O usuário solicita o domínio www.example.com, que é resolvido para a distribuição do CloudFront. Desta forma, a solicitação atinge a localização de borda do CloudFront mais próxima do usuário. A localização de borda tem uma origem configurada para o domínio origin.example.com. Este domínio é resolvido pelo registro baseado em latência do Route 53 para a região mais próxima (serviço de back-end).

Esquema 2. Configuração multirregional com CloudFront

Esta arquitetura tem os mesmos prós e contras da configuração anterior com uma única região.

3. AWS Global Accelerator sem cache

Agora é hora de usar o Global Accelerator. Simplesmente colocando-o entre o usuário e os serviços de back-end, alcançamos quase as mesmas capacidades da configuração anterior (Configuração multirregional com CloudFront).

Esquema 3. Aplicação multirregional usando AWS Global Accelerator

Vantagens da solução AWS Global Accelerator sobre a solução baseada em CloudFront:

• Não há necessidade de Route 53 e registro de Alias para o domínio. O Global Accelerator fornece 2 IPs dedicados, que podem ser usados com qualquer DNS de terceiros.
• Configuração mais rápida. Apesar da configuração do CloudFront, o Global Accelerator se atualiza imediatamente, então, em uma situação crítica, as atualizações podem ser aplicadas mais rapidamente.

Embora seja mais fácil e simples de configurar, o Global Accelerator não possui cache nas bordas. Então, como ficaria nossa arquitetura se ainda precisarmos adicionar cache?

4. Aplicação multirregional com AWS Global Accelerator e CloudFront

Se precisarmos de cache, temos que introduzir o CloudFront na frente de toda a cadeia:

Esquema 4. Aplicação multirregional usando AWS Global Accelerator e CloudFront

Parece complexo, não é? Vamos compará-lo com o Esquema 2: Configuração multirregional com CloudFront:

• Adicionar o Global Accelerator tornou o sistema mais complexo: o proxy extra na linha consome alguns milissegundos em cada solicitação.
• A arquitetura sem o Global Accelerator também era mais flexível: permite ter um IP não AWS como back-end, enquanto o Global Accelerator só pode funcionar com Load Balancers da AWS e IPs Elásticos como back-end.

Conclusão

Para um domínio que possui apenas endpoints de API e nunca precisa de cache, é melhor configurar o AWS Global Accelerator e usar a arquitetura do Esquema 3: Aplicação multirregional usando AWS Global Accelerator.

Para um domínio com um site ou endpoints de API que podem precisar de cache, é melhor optar por uma solução com CloudFront + Route 53, veja o Esquema 2: Configuração multirregional com CloudFront. Essa abordagem oferece os benefícios de cache e segurança do CloudFront, juntamente com a flexibilidade do Route 53 para roteamento baseado em latência e failover.

Em resumo, a escolha da melhor arquitetura depende das necessidades específicas da sua aplicação. Se a performance global e a alta disponibilidade são críticas, especialmente para APIs, o Global Accelerator é uma ferramenta poderosa. Se o cache é um requisito fundamental, o CloudFront (com ou sem o Global Accelerator) é a escolha mais apropriada. Sempre avalie cuidadosamente as opções e faça testes para determinar a solução ideal para o seu caso.