Lambda@Edge y patrones dirigidos por eventos

Lambda@Edge le permite ejecutar funciones de Lambda en ubicaciones periféricas de CloudFront de todo el mundo, más cerca de los usuarios finales, en lugar de hacerlo en una Región centralizada. Esto permite personalizar solicitudes y respuestas HTTP con una latencia adicional inferior a un milisegundo en la capa de CDN. Las funciones de Lambda@Edge se implementan globalmente y se invocan en cada evento de acierto o error de la caché de CloudFront, por lo que son ideales para tareas ligeras de manipulación de solicitudes.

Lambda@Edge puede interceptar el tráfico en cuatro puntos del ciclo de vida de una solicitud de CloudFront:

• Solicitud del visor: se activa cuando CloudFront recibe una solicitud del visor (usuario), antes de comprobar la caché
• Solicitud al origen: se activa cuando CloudFront reenvía un error de caché al origen
• Respuesta del origen: se activa cuando el origen devuelve una respuesta, antes de almacenarla en caché
• Respuesta al visor: se activa antes de que CloudFront devuelva la respuesta al visor

Lambda@Edge tiene límites más estrictos que Lambda normal: un máximo de 128 MB de memoria (eventos del visor), 1 GB (eventos del origen), un tiempo de espera máximo de 5 segundos (visor) y de 30 segundos (origen). Las funciones deben crearse en us-east-1 e implementarse en las ubicaciones periféricas mediante CloudFront. No admite VPC, variables de entorno ni capas de Lambda. Estas restricciones indican que Lambda@Edge está diseñado para transformaciones ligeras, no para procesamiento intensivo.

Lambda@Edge resulta especialmente útil para: pruebas A/B (reescribir URL a distintas rutas del origen según las cookies), autenticación (validar JWT en el perímetro antes de reenviar la solicitud al origen), manipulación de encabezados HTTP (añadir encabezados de seguridad como HSTS, CSP y X-Frame-Options), normalización de URL (redirigir de www a no-www o imponer barras finales) y personalización (servir contenido diferente según el país del visor a partir del encabezado CloudFront-Viewer-Country).

Las CloudFront Functions son funciones JavaScript ultraligeras que se ejecutan únicamente en las etapas de solicitud y respuesta del visor, con un límite de ejecución de 2 ms y un coste mucho menor. Para casos de uso sencillos (reescritura de URL, manipulación de encabezados y normalización de claves de caché), se prefieren las CloudFront Functions a Lambda@Edge porque son más rápidas y económicas. Utilice Lambda@Edge cuando necesite acceso a llamadas de red, cargas útiles más grandes o los puntos de activación de solicitud y respuesta del origen.

La arquitectura basada en eventos conecta servicios mediante eventos: mensajes que representan algo que ha sucedido. En AWS, Lambda es el principal consumidor de eventos: recibe eventos de SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge y otros servicios. Cada evento activa una ejecución de Lambda, lo que permite que los sistemas reaccionen de forma asíncrona e independiente sin un acoplamiento estrecho. Este patrón permite un acoplamiento flexible, un escalado independiente y el aislamiento de fallos.

Lambda puede configurarse como un mapeo de origen de eventos para SQS. Lambda sondea la cola, recupera hasta un tamaño de lote de mensajes (hasta 10 000 para colas estándar y 10 para FIFO) e invoca la función una vez por lote. Si la función falla, el lote completo vuelve a la cola. Configure una ventana de lote para esperar más mensajes antes de invocar la función y mejorar el rendimiento. Utilice una DLQ en la cola de SQS de origen para los mensajes que fallen repetidamente.

DynamoDB Streams captura cada cambio a nivel de elemento (INSERT, MODIFY, REMOVE) como una secuencia ordenada de eventos. Lambda lee del stream mediante un mapeo de origen de eventos con TRIM_HORIZON (comenzar por el más antiguo) o LATEST (comenzar por el más reciente). Lambda procesa los registros en orden dentro de una partición. Los lotes fallidos bloquean el procesamiento posterior de la misma partición hasta que se resuelven. Utilice bisect on error para dividir los lotes fallidos y aislar los registros problemáticos.

Lambda procesa los registros de Kinesis de forma similar a DynamoDB Streams: una ejecución simultánea por fragmento. Entre las opciones de configuración principales se incluyen el factor de paralelización (hasta 10 invocaciones simultáneas de Lambda por fragmento, que procesan sublotes en paralelo) y enhanced fan-out (un rendimiento dedicado de 2 MB/s por fragmento para el consumidor de Lambda). Estas opciones aumentan considerablemente el rendimiento de los streams de gran volumen sin incrementar el número de fragmentos.

Amazon EventBridge es el bus de eventos recomendado para conectar servicios de AWS y aplicaciones personalizadas. Los eventos fluyen hacia un bus, y las reglas filtran los eventos según un patrón y los dirigen a destinos como Lambda, SQS, Step Functions y otros. EventBridge desacopla por completo a los productores de eventos de los consumidores: ninguno conoce al otro. El bus de eventos predeterminado recibe eventos de los servicios de AWS; cree un bus de eventos personalizado para los eventos de su aplicación.

Un patrón habitual basado en eventos es fan-out: un evento activa varias canalizaciones de procesamiento en paralelo. Publique el evento en un tema de SNS y varias suscripciones a funciones de Lambda reaccionarán de forma independiente. Por ejemplo, un evento de pedido realizado se distribuye mediante fan-out a: una función de Lambda que envía un correo electrónico de confirmación, otra que actualiza el inventario y otra que notifica al almacén. Cada consumidor es independiente y se escala por separado; ningún consumidor puede bloquear a los demás.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que Lambda@Edge ejecuta funciones en ubicaciones periféricas de CloudFront con cuatro puntos de activación (solicitud/respuesta del visor y solicitud/respuesta del origen) para tareas como autenticación, reescritura de URL y manipulación de encabezados; las CloudFront Functions son la alternativa de menor coste y latencia para transformaciones sencillas en la etapa del visor; y los patrones basados en eventos que utilizan SQS, DynamoDB Streams, Kinesis, EventBridge y fan-out de SNS permiten arquitecturas con un acoplamiento flexible en las que Lambda reacciona a eventos en tiempo real. A continuación exploraremos las colas estándar y FIFO de SQS.