Gerenciamento de redirecionamentos HTTP
Visão geral
O Gerenciamento de redirecionamentos é um requisito comum em sites, geralmente usado para redirecionar URLs não existentes (por exemplo, campanhas expiradas ou após uma alteração na estrutura do site) ou para localizar conteúdo com base no país. Os redirecionamentos podem ser gerenciados na origem ou na CDN. O gerenciamento de redirecionamentos no nível da CDN pode reduzir a carga na origem e reduzir os tempos de resposta. Em alguns casos, como na hospedagem estática (por exemplo, S3), os redirecionamentos não podem ser gerenciados na origem. Os redirecionamentos no CloudFront são gerenciados usando seus recursos de funções de borda.
Decisões arquitetônicas
Os redirecionamentos podem ser implementados de maneiras diferentes usando funções de borda, dependendo dos seus requisitos. Para projetar a melhor implementação para os seus negócios, considere as seguintes perguntas
- Com que frequência você atualiza sua lógica de redirecionamento? O uso intenso de redirecionamentos em paralelo por diferentes equipes exige uma implementação mais sofisticada em comparação com testes A/B mais simples e ocasionais.
- Quantas regras de redirecionamento você tem na sua lógica? O tamanho do banco de dados de redirecionamentos é um fator a ser considerado ao avaliar diferentes opções de armazenamento.
- Os redirecionamentos são estáticos ou dinâmicos (por exemplo, variam com base no país do usuário ou nas capacidades do dispositivo)? Quando são dinâmicos, a lógica de redirecionamento deve ser executada em um contexto em que todos os parâmetros necessários estejam disponíveis para variar a resposta.
- Você reescreve o URL de forma transparente para o usuário ou envia um redirecionamento 3xx?
Para saber mais sobre algumas das implementações de redirecionamentos usando funções de borda do CloudFront, considere este workshop prático. Na seção a seguir, compartilharemos duas implementações comuns do Gerenciamento de redirecionamentos usando o CloudFront.
Casos de uso comuns
Redirecionamentos HTTP estáticos
Se você pretende implementar redirecionamentos HTTP com poucas regras que raramente são alteradas, configure uma função do CloudFront no evento de solicitação do visualizador com a lógica de redirecionamento incorporada no código da função. Quando a lógica de redirecionamento evoluir, você poderá atualizar o código da função e a nova lógica será aplicada aos usuários em poucos segundos.
Por exemplo, a função do CloudFront a seguir, configurada no evento de solicitação do espectador, envia uma resposta HTTP 3xx para usuários de países selecionados (Espanha e Emirados Árabes Unidos) para redirecioná-los para a versão local de uma aplicação de página única (por exemplo, https://example.com/ -> https://example.com/es/). Para que isso funcione, você precisa incluir o cabeçalho cloudfront-viewer-country na Política de solicitação de origem. Ele instrui o CloudFront a disponibilizar esse cabeçalho no objeto de evento do CloudFront Functions, usado pela lógica da sua função. Observe que, neste código de exemplo, o usuário é redirecionado com base em seu país, a menos que solicite especificamente uma versão diferente do SPA.
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = request.headers.host.value;
var supported_countries = ['ie','ae', 'es']; // countries in which you'd like to serve a localized version of your Single Page Application
var defaultCountryIndex = 0; // default country index in the support_countries array. here it is 'ie'
if ((supported_countries.includes(request.uri.substring(1,3))) && ((request.uri.substring(3,4) === '/') || (request.uri.length === 3))) {
// If one of the supported country codes is included in the path (e.g. /es/about) then add index.html when needed to the reauest
return requestWithIndexHTML(request);
} else if ((headers['cloudfront-viewer-country']) && (headers['cloudfront-viewer-country'].value.toLowerCase() !== supported_countries[defaultCountryIndex])){
// Otherwise if the user reauest is coming from one of the supported countries except the default one, then redirect to country specific version (e.g. /about -> /es/about)
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: { location: { value: `https://${host}/${headers['cloudfront-viewer-country'].value.toLowerCase()}${request.uri}` } },
};
return response;
} else {
// Otherwise send rewrite the request to the default country path, add index.html if needed and return
request.uri = '/'+supported_countries[defaultCountryIndex] + request.uri;
return requestWithIndexHTML(request);
}
}
// Add index.html to SPA path when needed
function requestWithIndexHTML(request) {
if (request.uri.endsWith('/')) {
request.uri += 'index.html';
} else if (!request.uri.includes('.')) {
request.uri += '/index.html';
}
return request;
}Redirecionamentos HTTP em massa
A função CloudFront também é capaz de suportar mapeamentos de redirecionamento maiores com o uso do CloudFront KeyValueStore, além do que você pode ajustar dentro do tamanho máximo da função de 10 KB. Por exemplo, você pode armazenar os URIs com os quais deseja comparar com as chaves e os URLs de redirecionamento no valor. O URI disponível no objeto de evento da solicitação do visualizador pode ser avaliado para um URI correspondente e, caso exista nas chaves, sua função poderá retornar um redirecionamento 3xx com o valor associado.
O uso do KeyValueStore também tem a vantagem de desacoplar dados que mudam regularmente a partir do seu código. O KeyValueStore é ideal como um datastore global (para cada PoP), de leitura de baixa latência e de valor-chave em grande escala (milhões de solicitações por segundo).
Requisitos avançados para redirecionamentos HTTP
Uma solução baseada em Lambda@Edge é mais adequada para requisitos avançados de redirecionamento que não podem ser atendidos pelo tamanho máximo do KeyValueStore (5 MB) nem pelo limite de velocidade de alteração de algumas chamadas de API por segundo. Um exemplo de cenário é quando há várias equipes de marketing diferentes atualizando centenas de milhares de redirecionamentos de campanhas diariamente.
Nessa arquitetura, uma função do Lambda@Edge, configurada no evento em solicitação de origem, é executada em cada perda de cache para verificar com um armazenamento de regras externo, como o S3 ou o DynamoDB, qual regra de redirecionamento aplicar. As regras são gerenciadas diretamente no armazenamento selecionado, com a possibilidade de criar uma interface de usuário simples sobre ele para facilitar o gerenciamento. Um exemplo dessa arquitetura, com um armazenamento baseado em S3 e uma interface de usuário de gerenciamento autenticada, é descrito neste blog.
