Una aplicación web suele empezar con un servidor que escucha en un puerto, recibe peticiones y devuelve respuestas. Llevar ese código a un entorno serverless podía exigir adaptar el framework al formato de eventos de la plataforma. AWS Lambda Web Functions introduce otro camino: ejecutar el servidor HTTP directamente dentro de Lambda.
AWS presentó esta capacidad el 12 de octubre de 2026 y publicó una guía técnica el día 13. En este artículo repasamos su funcionamiento y construimos un ejemplo mínimo para entender el despliegue. Las características descritas corresponden a esas publicaciones; el ejemplo de código es propio y no representa una prueba de rendimiento realizada en AWS.
Qué son AWS Lambda Web Functions
Una Web Function ejecuta un servidor HTTP estándar. En lugar de exportar únicamente un handler que recibe eventos, la aplicación abre un puerto y atiende las solicitudes mediante su propio servidor o framework.
La guía de lanzamiento describe compatibilidad con servidores Node.js y frameworks como Express, Fastify y Hono sin una capa adaptadora. Next.js en modo standalone necesita un pequeño punto de entrada para configurar la dirección y el puerto. La configuración inicial documentada utiliza Node.js 24, arquitectura Arm64, dos vCPU y 2 GB de memoria por entorno.
Esto permite plantear APIs REST, servicios GraphQL, aplicaciones con renderizado en servidor y respuestas en streaming. Para una web cuyo contenido ya son archivos HTML, CSS e imágenes, una arquitectura con S3 y CloudFront sigue siendo una opción adecuada: no hace falta añadir ejecución de código a cada visita.
Funciones, revisiones y endpoints
El modelo separa tres recursos. La Web Function identifica la aplicación y su configuración. Una revisión conserva una instantánea inmutable del código y la configuración. El endpoint proporciona la entrada HTTPS, el mecanismo de autenticación y las reglas que dirigen el tráfico a las revisiones.
Esta separación resulta útil al publicar cambios. Una revisión nueva no debe confundirse con una URL nueva para los usuarios. El enrutamiento permite decidir qué revisión recibe las peticiones y volver a una anterior cuando sea necesario. En una aplicación real conviene acompañar esa posibilidad con comprobaciones de salud y compatibilidad de los cambios de base de datos.
En qué se diferencia de Lambda orientado a eventos
El artículo de AWS denomina Event Functions al modelo orientado a eventos. Continúa siendo apropiado para procesar mensajes de colas, reaccionar a objetos de S3 o ejecutar tareas disparadas por otros servicios. Web Functions añade un modelo pensado para HTTP.
| Aspecto | Modelo orientado a eventos | Web Functions |
|---|---|---|
| Entrada del código | Handler que recibe un evento. | Servidor HTTP que escucha en un puerto. |
| Uso natural | Procesamiento de eventos e integraciones. | Aplicaciones web, APIs y streaming HTTP. |
| Concurrencia | El modelo tradicional descrito en la guía atiende una invocación por entorno. | Un entorno puede atender varias peticiones simultáneas. |
| Acceso HTTP | Puede usar API Gateway u otras opciones de entrada. | Dispone de endpoints HTTPS propios. |
Disponer de un endpoint propio no convierte Web Functions en un sustituto automático de todas las capacidades de API Gateway. Antes de migrar una API, revisa sus requisitos de autorización, validación, cuotas, observabilidad e integración. Compara la solución completa.
Un ejemplo mínimo con Node.js
El siguiente servidor tiene dos rutas: /, que devuelve un mensaje JSON, y /health, que permite comprobar que el proceso responde. No utiliza dependencias externas ni almacena información de usuarios.
Crea una carpeta de pruebas independiente de los archivos de tu web y entra en ella:
mkdir cloudcompute-web-demo
cd cloudcompute-web-demoGuarda este código como index.js. Lee la dirección proporcionada por Lambda y utiliza el puerto 3000 cuando se ejecuta localmente:
const http = require('node:http');
const address = process.env.AWS_LAMBDA_HTTP_ENDPOINT || '0.0.0.0:3000';
const separator = address.lastIndexOf(':');
const host = address.slice(0, separator);
const port = Number(address.slice(separator + 1));
if (!host || !Number.isInteger(port) || port < 1 || port > 65535) {
throw new Error('Dirección HTTP no válida');
}
const server = http.createServer((req, res) => {
const path = (req.url || '/').split('?')[0];
const allowed = req.method === 'GET' || req.method === 'HEAD';
let status;
let data;
if (!allowed) {
status = 405;
res.setHeader('Allow', 'GET, HEAD');
data = { error: 'Método no permitido' };
} else if (path === '/health') {
status = 200;
data = { ok: true };
} else if (path === '/') {
status = 200;
data = { message: 'Hola desde CloudCompute.es' };
} else {
status = 404;
data = { error: 'Ruta no encontrada' };
}
res.writeHead(status, {
'Content-Type': 'application/json; charset=utf-8',
'Cache-Control': 'no-store'
});
res.end(req.method === 'HEAD' ? undefined : JSON.stringify(data));
});
server.listen(port, host, () => {
console.log(`Servidor escuchando en ${host}:${port}`);
});Desde esa carpeta, arranca el servidor:
node index.jsEn otra terminal, comprueba la ruta de salud:
curl -i http://127.0.0.1:3000/healthEl resultado esperado es un estado 200 y un cuerpo {"ok":true}. Una petición a una ruta desconocida devuelve 404; los métodos distintos de GET y HEAD reciben 405. Detén el servidor local con Ctrl+C cuando termines.
Cómo desplegar el ejemplo
Necesitas una cuenta AWS, credenciales configuradas, permisos para crear los recursos y una versión de AWS CLI que incluya lambda-web. Comprueba primero la identidad y la disponibilidad del comando:
aws sts get-caller-identity --no-cli-pager
aws lambda-web deploy helpSi la CLI no reconoce lambda-web, revisa su instalación y la documentación actual antes de continuar. Desde la carpeta que contiene únicamente el ejemplo, el comando de despliegue sigue este formato:
aws lambda-web deploy --name cloudcompute-web-demo --code . --region us-east-1Usamos us-east-1 porque aparece en la demostración oficial; no supone que debas trasladar tus otras aplicaciones a esa región. La herramienta empaqueta el código y prepara la función y un endpoint. Según la guía, también crea el rol de ejecución y un bucket S3 con versionado si no existen los recursos compartidos correspondientes.
Revisa los recursos antes de confirmar. El ejemplo de inicio genera una URL pública; no incluyas secretos, archivos de tu web ni información privada en el directorio que empaquetas. Comprueba /health en la URL HTTPS que devuelve el despliegue.
Esta prueba crea infraestructura que puede generar cargos. Al terminar, revisa las instrucciones de limpieza del patrón oficial y elimina los recursos exclusivos de la prueba. Un bucket compartido con otras funciones requiere una comprobación previa.
Concurrencia: varias peticiones dentro del mismo entorno
La concurrencia permite que un proceso atienda otras solicitudes mientras espera una respuesta de red. Es especialmente relevante para conexiones abiertas o llamadas a bases de datos y APIs externas. No significa que todas las operaciones utilicen CPU en paralelo sin límite.
La guía establece una concurrencia por entorno predeterminada de 64 solicitudes y un máximo configurable de 128 mediante maxConcurrencyPerEnvironment. También documenta maxEnvironments y rateLimit en los endpoints. Los límites se aplican por región; el límite de entornos se aplica a cada revisión. Las peticiones que exceden el límite reciben HTTP 429 y no quedan en una cola.
Para el desarrollador, esto exige revisar el estado compartido. Una variable global puede ser utilizada por varias solicitudes del mismo proceso: nunca debe contener datos específicos de un usuario que otra petición pueda reutilizar. Conviene limitar también los pools de conexiones y evitar tareas de CPU intensivas que bloqueen el event loop de Node.js.
CPU activa: qué cambia en los costes
El modelo descrito factura solicitudes, memoria y CPU consumida. Cuando el proceso está esperando una operación de entrada o salida, puede consumir poca CPU, aunque la conexión permanezca abierta.
Eso no convierte el tiempo de espera en gratuito: la memoria y las solicitudes siguen formando parte del cálculo. Tampoco permite afirmar que cualquier aplicación será más barata que con otra arquitectura. Hay que medir la carga real y añadir transferencia de datos, registros, base de datos y otros servicios utilizados.
Para una comparación útil, ejecuta el mismo escenario con un volumen conocido de peticiones. Registra latencia, errores, concurrencia, memoria y consumo de CPU. Después calcula el coste total con las tarifas vigentes de la región elegida, en lugar de comparar solo el precio de una invocación.
Despliegues en varias regiones
El ejemplo oficial también muestra un endpoint multirregión. Lambda replica el código y la configuración de la revisión, incluidas las variables de entorno, y utiliza enrutamiento por latencia de Route 53 para dirigir las solicitudes.
La aplicación puede acercarse a los usuarios, pero los datos necesitan su propio diseño. Una base de datos que permanece en otra región puede seguir añadiendo latencia. Antes de distribuir la aplicación, revisa dónde se almacenan los datos, cómo se replica el estado y qué dependencias pueden utilizarse desde cada región.
El artículo de AWS presenta mediciones individuales desde una ubicación concreta. Son una ilustración del funcionamiento, no una garantía de latencia aplicable a todos los usuarios.
Autenticación, CloudFront y observabilidad
Con ApplicationManaged, la aplicación controla la autenticación: por ejemplo, mediante sesiones o tokens. Con IamAuth, Lambda valida solicitudes firmadas; la guía distingue SigV4 para endpoints de una región y SigV4a para multirregión. La autorización IAM no convierte el endpoint en una dirección de red privada.
Para dominio personalizado, caché en el borde y AWS WAF, el artículo plantea colocar CloudFront delante del endpoint y usar IAM con Origin Access Control. El objetivo es controlar también el acceso directo al origen, además del tráfico que pasa por la distribución.
La observabilidad debe acompañar al despliegue: registra errores, observa la duración de las solicitudes y configura alertas sobre fallos y saturación. Un endpoint que responde no demuestra que todas sus dependencias estén funcionando. Para problemas con un origen S3, puedes consultar nuestra guía de diagnóstico de errores 403 en S3 y CloudFront; las políticas de acceso dependen del tipo de origen.
Cuándo merece la pena evaluarlo
Web Functions resulta interesante si ya tienes una aplicación Node.js basada en HTTP, necesitas streaming o quieres experimentar con concurrencia por entorno sin administrar servidores. Su valor debe comprobarse con una prueba pequeña que represente el tráfico y las dependencias de tu aplicación.
Para un blog estático como CloudCompute.es, esta novedad no obliga a cambiar el alojamiento de los artículos. Podría estudiarse para una funcionalidad dinámica separada. Para consumidores de colas y automatizaciones orientadas a eventos, el modelo de eventos conserva su utilidad.
La recomendación es empezar por una ruta sencilla, observar su comportamiento y revisar seguridad, costes y recuperación antes de ampliar el alcance. Una nueva capacidad de AWS aporta otra opción de diseño; la elección depende del problema que necesitas resolver.
Fuentes y documentación
- AWS Compute Blog: Exploring AWS Lambda Web Functions for building web applications, Julian Wood, Kim Wendt y Samrat Karak, 13 de octubre de 2026. Fuente técnica de este artículo y acceso a los patrones de ejemplo.
- AWS Lambda: precios oficiales. Consulta las tarifas y condiciones aplicables antes de estimar una carga real.