Administración de redirecciones HTTP
Información general
La administración de redirecciones es un requisito común en los sitios web, a menudo utilizado para redirigir URL no existentes (por ejemplo, campañas caducadas o tras un cambio en la estructura del sitio web), o para localizar contenido en función del país. Las redirecciones se pueden gestionar en el origen o en la CDN. Administrar las redirecciones en la CDN podría reducir la carga en el origen y los tiempos de respuesta. En algunos casos, como con el alojamiento estático (por ejemplo, S3), las redirecciones no se pueden gestionar en el origen. Las redirecciones en CloudFront se gestionan mediante sus capacidades de funciones de periferia.
Decisiones de arquitectura
Las redirecciones se pueden implementar de diferentes maneras mediante funciones de periferia, en función de sus requisitos. Para diseñar la mejor implementación para la empresa, tenga en cuenta las siguientes preguntas
- ¿Con qué frecuencia actualiza la lógica de redirección? El uso intensivo de redirecciones en paralelo por parte de diferentes equipos requiere una implementación más sofisticada en comparación con las pruebas A/B más sencillas y ocasionales.
- ¿Cuántas reglas de redirección tiene en su lógica? El tamaño de la base de datos de redirecciones es un factor a tener en cuenta a la hora de evaluar las distintas opciones de almacenamiento.
- ¿Las redirecciones son estáticas o dinámicas (por ejemplo, varían en función del país del usuario o de las capacidades del dispositivo)? Cuando es dinámica, la lógica de redirección debe ejecutarse en un contexto en el que estén disponibles todos los parámetros necesarios para variar la respuesta.
- ¿Se reescribe la URL de forma transparente para el usuario o se envía una redirección 3xx?
Para conocer algunas de las implementaciones de redirecciones que utilizan las funciones de periferia de CloudFront, considere este taller práctico. En la siguiente sección, compartiremos dos implementaciones comunes de Administración de redirecciones mediante CloudFront.
Casos de uso comunes
Redireccionamientos HTTP estáticos
Si desea implementar redireccionamientos HTTP con pocas reglas que rara vez cambian, configure CloudFront Function en el evento de solicitud del espectador con la lógica de redireccionamiento integrada en el código de la función. Cuando la lógica de redireccionamiento evolucione, podrá actualizar el código de la función y se aplicará la nueva lógica para los usuarios en cuestión de segundos.
Por ejemplo, la siguiente función de CloudFront, configurada en el evento de solicitud de espectador, envía una respuesta HTTP 3xx a los usuarios de los países seleccionados (España y EAU) para redirigirlos a la versión local de una aplicación de página única (por ejemplo, https://example.com/ -> https://example.com/es/). Para que esto funcione, debe incluir el encabezado cloudfront-viewer-country en la Política de solicitud de origen. Indica a CloudFront que haga que este encabezado esté disponible en el objeto de evento de CloudFront Function, que utiliza la lógica de su función. Tenga en cuenta que, en este código de ejemplo, se redirige al usuario en función de su país, a menos que solicite específicamente una versión de país diferente de la 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;
}Redireccionamientos HTTP masivos
CloudFront Function también es capaz de admitir asignaciones de redireccionamiento más grandes mediante el uso de CloudFront KeyValueStore, más allá de lo que puede caber en el tamaño máximo de la función de 10 KB. Por ejemplo, puede almacenar los URI que desea hacer coincidir en las claves y las URL de redireccionamiento en el valor. El URI disponible en el objeto del evento de la solicitud del espectador se puede evaluar para encontrar un URI coincidente y, si existe uno en las claves, la función puede devolver un redireccionamiento 3xx con el valor asociado.
El uso de KeyValueStore también tiene la ventaja de desvincular los datos que cambian con regularidad de su código. KeyValueStore es ideal como almacén de datos global (para cada PoP), con lectura de baja latencia y valores clave a escala (millones de solicitudes por segundo).
Requisitos avanzados para los redireccionamientos HTTP
Una solución basada en Lambda@Edge es más adecuada para los requisitos de redireccionamiento avanzados, que no se pueden cumplir por el tamaño máximo de KeyValueStore (5 MB) o el cambio del límite de velocidad de unas pocas llamadas a la API por segundo. Un ejemplo es cuando hay muchos equipos de marketing diferentes que actualizan cientos de miles de redireccionamientos de campañas a diario.
En esta arquitectura, una función de Lambda@Edge, configurada en el evento de solicitud de origen, se ejecuta en cada fallo de caché para comprobar con un almacenamiento de reglas externo, como S3 o DynamoDB, qué regla de redireccionamiento aplicar. Las reglas se administran directamente en el almacenamiento seleccionado, con la posibilidad de crear una interfaz de usuario sencilla sobre él para facilitar la gestión. En este blog, se describe un ejemplo de esta arquitectura, con un almacenamiento basado en S3 y una interfaz de usuario de gestión autenticada.
