Cerramos el Capítulo 28 con una idea muy potente: ejecutar lógica muy cerca de los usuarios, en el «borde» de la red. Hasta ahora, nuestras Lambdas (Capítulo 14) se ejecutaban en una región concreta. Pero ¿y si pudieras ejecutar código en los cientos de ubicaciones que CloudFront (subcapítulo 16.2) tiene repartidas por el mundo, justo al lado de cada usuario? Eso es lo que permiten Lambda@Edge y CloudFront Functions: llevar el cómputo al edge (el borde de la red) para responder más rápido y personalizar el contenido.

Recuerda del subcapítulo 16.2 que CloudFront es la CDN de AWS: tiene ubicaciones repartidas por todo el mundo (puntos de presencia o «edge locations») que sirven contenido a los usuarios desde el punto más cercano a ellos, reduciendo la latencia. Ese conjunto de ubicaciones cercanas a los usuarios es lo que llamamos el edge (el borde de la red).

La idea de este subcapítulo: ejecutar código en esas ubicaciones del edge, no solo servir archivos. Así, la lógica corre al lado del usuario, no en una región lejana.

Si toda tu lógica se ejecuta en una región (por ejemplo, en Europa), un usuario en Japón tiene que «ir y volver» hasta Europa para cada operación, lo que añade latencia (retardo). Para ciertas tareas sencillas que se podrían resolver cerca del usuario, ese viaje es un desperdicio. Sería mejor ejecutar esa pequeña lógica en la ubicación del edge más cercana al usuario.

Ejecutar lógica en el edge significa correr código en las ubicaciones cercanas a los usuarios (las de CloudFront), en lugar de en una región central. Esto sirve para tareas que conviene resolver justo cuando una petición llega o sale del edge, sin viajar hasta la región:

• Personalizar respuestas según el usuario (su país, su idioma, su dispositivo).
• Redirigir peticiones según ciertas reglas.
• Comprobar cosas (autenticación básica, cabeceras) antes de seguir.
• Modificar la petición o la respuesta al vuelo.

Analogía: ejecutar lógica en el edge es como tener un recepcionista en la puerta de cada sucursal de un banco, en vez de tener que llamar a la central para todo. Si entras y solo necesitas que te indiquen una ventanilla o te den un folleto en tu idioma, el recepcionista local lo resuelve al instante, sin llamar a la central (que está lejos). Solo las gestiones complejas van a la central. Llevar tareas sencillas «a la puerta» hace todo más rápido.

AWS ofrece dos formas de ejecutar código en el edge, una más potente y otra más ligera:

CloudFront Functions son funciones muy ligeras y rapidísimas, pensadas para tareas simples que se ejecutan en cada petición con mínima latencia. Son ideales para manipulaciones sencillas y de gran volumen:

Lambda@Edge son Lambdas (Capítulo 14) que se ejecutan en el edge, más potentes que las CloudFront Functions: permiten lógica más compleja (más tiempo de ejecución, acceso a más recursos, etc.), a cambio de algo más de latencia y coste.

💡 Regla práctica: para tareas simples y de gran volumen (manipular cabeceras o URLs), usa CloudFront Functions (más rápidas y baratas). Para lógica más compleja, usa Lambda@Edge. Elige la herramienta más ligera que resuelva tu necesidad.

La ventaja de ejecutar lógica en el edge es doble:

• Menor latencia: la lógica se ejecuta cerca del usuario, así que responde más rápido (sin el viaje hasta la región).
• Personalización global: puedes adaptar el contenido a cada usuario (idioma, país, dispositivo) en el punto más cercano a él, dando una experiencia rápida y a medida en todo el mundo.

Esto encaja con el pilar de eficiencia del rendimiento del Well-Architected Framework (subcapítulo 27.1): usar la ubicación adecuada para que el sistema rinda lo mejor posible para cada usuario.

Ejemplo del mundo real: una web global quiere que cada usuario vea el contenido en su idioma y sea redirigido a la versión de su país, lo más rápido posible. Usan una CloudFront Function que, en cada petición, mira el país del usuario (a partir de una cabecera que CloudFront añade) y reescribe la URL para servir la versión correcta, todo en la ubicación del edge más cercana, en milisegundos. Para otra tarea más compleja —comprobar un token de autenticación y personalizar la respuesta según el perfil del usuario— usan Lambda@Edge, que tiene la potencia necesaria. El resultado: usuarios de todo el mundo obtienen contenido personalizado y veloz, porque la lógica corre a su lado, no al otro lado del planeta.

• CloudFront (subcap. 16.2) tiene ubicaciones por todo el mundo (el edge) cercanas a los usuarios. Se puede ejecutar código en ellas, no solo servir archivos.
• Ejecutar lógica en el edge significa correr código cerca del usuario (no en una región lejana), ideal para personalizar respuestas, redirigir, comprobar o modificar peticiones al vuelo. Como un recepcionista en la puerta de cada sucursal en vez de llamar siempre a la central.
• AWS ofrece dos opciones: CloudFront Functions (muy ligeras y ultrarrápidas, para tareas simples como reescribir URLs o cabeceras) y Lambda@Edge (más potente, para lógica compleja).
• 💡 Usa la más ligera que resuelva tu necesidad: CloudFront Functions para lo simple y de gran volumen; Lambda@Edge para lo complejo.
• Aporta menor latencia (lógica cerca del usuario) y personalización global, en línea con el pilar de eficiencia del rendimiento del Well-Architected Framework.

¡Has completado el Capítulo 28 y dominas las arquitecturas serverless a escala: event-driven, el patrón Saga, Step Functions y el cómputo en el edge! En el Capítulo 29 cambiaremos de terreno hacia otro gran dominio: las plataformas de datos en AWS (data lakes, streaming y analítica a gran escala).