Cerramos el módulo con la pieza que falta. Hasta ahora, todo lo que ha montado MercadoFresco parte de la misma idea: hay un servidor encendido esperando trabajo. La instancia EC2 de la tienda está encendida aunque sea martes a las 4 de la madrugada. La instancia RDS también. Y se pagan las 730 horas del mes.

Pero hay tareas que no encajan en ese modelo. Generar la miniatura de una foto cuando Luis la sube ocurre veinte veces al día y dura dos segundos. Consultar el estado de un pedido es una llamada puntual. Procesar un fichero de rutas de reparto pasa una vez cada mañana. Tener un servidor encendido 730 horas para 40 minutos de trabajo mensual es absurdo.

AWS Lambda ejecuta código solo cuando ocurre algo y solo cobra mientras se ejecuta, con precisión de milisegundos. En esta lección conectamos por fin el evento de S3 que dejamos configurado en 02-03 y escribimos la función que genera las miniaturas del catálogo de MercadoFresco.

1. Qué es la computación sin servidor y en qué se diferencia de EC2
2. Modelo de ejecución: manejador, evento, contexto y respuesta
3. Arranque en frío y arranque en caliente
4. Concurrencia: reservada, provisionada y el límite de la cuenta
5. Configuración: memoria, CPU, tiempo de espera, variables y arquitectura
6. La función de las miniaturas: el código
7. Empaquetado con dependencias y capas
8. Desplegar por consola y por CLI
9. Permisos: el rol de ejecución y el mínimo privilegio
10. Registros en CloudWatch Logs y depuración
11. Orígenes de eventos habituales
12. Segunda función: consultar el estado de un pedido por HTTP
13. Límites reales que hay que conocer
14. Precios, con el cálculo concreto de MercadoFresco
15. Errores, reintentos y colas de mensajes fallidos
16. Recapitulación del módulo: qué está ya en AWS y qué falta

"Sin servidor" (serverless) no significa que no haya servidores: significa que no son tuyos, no los ves y no los pagas cuando no trabajan. AWS aprovisiona la capacidad, la escala y la retira, todo invisible.

Los criterios de elección, en orden de utilidad práctica:

1. ¿La tarea dura menos de 15 minutos? Si no, Lambda queda descartada.
2. ¿El tráfico es irregular o por eventos? Lambda gana con diferencia. Si es sostenido y constante 24×7, un contenedor o una EC2 salen más baratos.
3. ¿Necesitas control del sistema operativo o estado en disco? Entonces EC2 o contenedores.
4. ¿Cuánto tiempo de tu equipo quieres dedicar a infraestructura? Lambda es el mínimo posible.

Para MercadoFresco, la generación de miniaturas cumple los cuatro criterios de forma perfecta: segundos de duración, disparada por eventos esporádicos, sin estado, y sin nada que administrar.

Una función Lambda es una función normal de tu lenguaje con una firma concreta:

El ciclo de vida completo, que hay que entender bien porque de él dependen el rendimiento y el coste:

De aquí sale la optimización más rentable de Lambda, y es una línea de código:

Y de aquí sale también la trampa correspondiente: el entorno se reutiliza, así que las variables globales persisten entre invocaciones. Es útil para cachés, pero desastroso si acumulas estado por descuido:

El arranque en frío es el tiempo que tarda AWS en preparar un entorno nuevo: crear la microVM, descargar el código y las capas, inicializar el intérprete y ejecutar el código global.

Cuándo importa de verdad: si la Lambda responde a una petición síncrona de un usuario (una API), 1,5 segundos extra son inaceptables. Si procesa un evento asíncrono (la miniatura de una foto), a nadie le importa.

Estrategias de mitigación, de menor a mayor coste:

1. Mover trabajo al código global y mantener el paquete pequeño. Gratis.
2. Elegir un lenguaje ligero. Python o Node para funciones de latencia crítica.
3. Subir la memoria. Más CPU acelera la inicialización, y a menudo el coste total no sube porque la ejecución dura menos.
4. Concurrencia provisionada. AWS mantiene N entornos siempre listos. Elimina el arranque en frío por completo, pero se paga aunque no se use.

Lambda no encola peticiones: crea entornos nuevos. Si llegan 100 eventos simultáneos, se ejecutan 100 instancias de la función a la vez. Esa es su gran ventaja y también su riesgo.

La concurrencia reservada tiene un doble efecto que conviene entender:

• Garantiza que esa función siempre podrá usar esa cantidad, aunque otras estén saturando la cuenta.
• Limita esa función a ese máximo. Es un freno.

Ese freno es exactamente lo que MercadoFresco necesita para proteger la base de datos:

Sin ese límite, un pico de tráfico podría abrir cientos de conexiones a mercadofresco-pedidos y tumbar la base de datos. Es un caso real y frecuente: Lambda escala, RDS no.

Este es el parámetro que más gente configura mal. En Lambda solo se asigna memoria, de 128 MB a 10.240 MB, y la CPU se asigna proporcionalmente:

La consecuencia es contraintuitiva y merece un cálculo. Una función que procesa una imagen:

Más memoria puede salir igual de barato o más barato, y ocho veces más rápido. Poner 128 MB "para ahorrar" suele ser un error: la función tarda tanto que el coste no baja y la latencia se dispara. La herramienta AWS Lambda Power Tuning automatiza este análisis.

De 1 segundo a 15 minutos (900 s), con 3 segundos por defecto. Regla: ponlo un poco por encima de lo que la función tarda realmente, nunca al máximo. Un tiempo de espera de 900 s en una función que debería tardar 2 s significa que un cuelgue se pagará durante 15 minutos.

Se cifran en reposo automáticamente, pero son visibles en la consola para cualquiera con permiso de lectura. Nunca metas contraseñas ahí: usa Secrets Manager o Parameter Store (lección 04-03), como hicimos con RDS en 02-04.

Elige arm64 salvo que una dependencia te lo impida. Es un 20 % de ahorro por cambiar un parámetro. La única precaución es que las bibliotecas con código nativo —como Pillow, que usaremos ahora— deben empaquetarse para la arquitectura correcta.

Llegamos al objetivo. En la lección 02-03 configuramos la notificación del bucket mercadofresco-catalogo-fotos para que cada .jpg subido bajo productos/ disparara la función mercadofresco-generar-miniaturas. Vamos a escribirla.

Los detalles del código que marcan la diferencia entre un ejemplo de tutorial y algo que aguanta en producción:

• unquote_plus sobre la clave. S3 codifica los nombres en el evento. Sin esta línea, cualquier foto con espacios, tildes o eñes daría NoSuchKey. Es el fallo número uno de las Lambdas de S3.
• event["Records"] es una lista. Un solo evento puede traer varios registros. Procesarlo con event["Records"][0] funciona en las pruebas y falla en producción.
• Prefijo de salida distinto del de entrada, más la comprobación explícita. Doble protección contra el bucle recursivo.
• raise en los errores recuperables. Lambda reintenta automáticamente las invocaciones asíncronas; tragarse la excepción con un return haría que el fallo pasara desapercibido.
• NoSuchKey se trata aparte. Es un error no recuperable: reintentarlo tres veces es tiempo y dinero perdidos.
• Etiquetado del objeto con el esquema del proyecto, coherente con lo que venimos haciendo.

Pillow no viene incluido en el entorno de Lambda: hay que aportarlo. Hay tres formas y conviene saber cuándo usar cada una.

Para MercadoFresco, una capa con Pillow es la elección correcta: la compartirán la función de miniaturas y las que vengan después, y mantiene el paquete de código pequeño (arranques en frío más rápidos y edición posible en la consola).

La estructura de directorios de la capa no es negociable: Python busca las bibliotecas en /opt/python, y AWS descomprime la capa en /opt. Por eso todo debe colgar de un directorio llamado exactamente python/. Cada lenguaje tiene su ruta (nodejs/node_modules para Node.js).

1. Consola → Lambda → región Irlanda → Crear función.
2. Crear desde cero. Nombre: mercadofresco-generar-miniaturas. Tiempo de ejecución: Python 3.12. Arquitectura: arm64.
3. Cambiar el rol de ejecución → crear uno nuevo (lo ajustaremos en el apartado siguiente).
4. Pega el código en el editor o sube el ZIP.
5. Configuración → Configuración general: memoria 1.024 MB, tiempo de espera 30 s.
6. Configuración → Variables de entorno: las cuatro que definimos antes.
7. Capas → Añadir una capa → mercadofresco-imagen.
8. Desencadenadores → Añadir desencadenador → S3 → bucket mercadofresco-catalogo-fotos, evento Todos los eventos de creación de objetos, prefijo productos/, sufijo .jpg.
9. Etiquetas: el esquema obligatorio del proyecto.

Actualizar el código después de un cambio:

--publish crea una versión inmutable numerada. Combinada con alias (produccion, pruebas), permite despliegues graduales dirigiendo, por ejemplo, el 10 % del tráfico a la versión nueva. Es otra pieza contra el problema 4 de MercadoFresco, los despliegues arriesgados, que se aborda de lleno en el módulo 8.

Probar sin subir nada a S3:

--log-type Tail devuelve los últimos 4 KB del log codificados en base64: la forma más rápida de depurar sin salir de la terminal.

Aviso de coste. El nivel gratuito de Lambda es permanente, no de 12 meses: 1 millón de peticiones y 400.000 GB-segundo al mes, para siempre. Esta práctica no te costará nada. Aun así, borra la función al terminar si no vas a seguir: aws lambda delete-function --function-name mercadofresco-generar-miniaturas. Y recuerda eliminar también la notificación del bucket y la capa si no las usas.

Una función Lambda no tiene credenciales propias: asume un rol de ejecución de IAM, y los permisos de ese rol son exactamente lo que la función puede hacer. Ni más, ni menos.

La política de confianza, que define quién puede asumir el rol:

Y la política de permisos, que define qué puede hacer. Aquí está el principio de mínimo privilegio aplicado con rigor:

Cuatro decisiones deliberadas, y cada una evita un problema real:

1. s3:GetObject solo bajo productos/. Si la función se ve comprometida, no puede leer los informes de ventas ni las copias de la base de datos.
2. s3:PutObject solo bajo miniaturas/. Aunque hubiera un fallo lógico, la función no puede sobrescribir las fotos originales. Es la última defensa contra el bucle recursivo: incluso si el filtro del bucket fallara, el escritor no tiene permiso sobre el prefijo de entrada.
3. Sin s3:DeleteObject. La función no necesita borrar nada, así que no puede.
4. Los registros acotados a su propio grupo de logs, no a *.

Comparado con la práctica habitual de adjuntar AmazonS3FullAccess "para que funcione", la diferencia entre un incidente menor y una filtración completa está en estas tres instrucciones. La lógica completa de IAM, los roles, las políticas y su evaluación es la lección 04-01.

Cada función escribe automáticamente en un grupo de logs llamado /aws/lambda/<nombre-de-la-función>. Todo lo que imprimas con print() o logger.info() acaba ahí.

Al final de cada invocación, Lambda escribe una línea REPORT que es oro puro para ajustar la configuración:

Cómo se lee:

En este caso la tentación es bajar la memoria a 256 MB. Cuidado: recuerda que la CPU es proporcional. Con 256 MB la función tardaría unos 7 segundos en lugar de 1,8, y el coste sería prácticamente el mismo con cuatro veces más latencia. La decisión correcta es probar 512 MB y medir.

Otras dos capacidades básicas de depuración:

• Métricas automáticas en CloudWatch: Invocations, Errors, Duration, Throttles, ConcurrentExecutions. Una alarma sobre Errors > 0 es lo mínimo exigible en producción.
• Registros estructurados en JSON: configurando el formato de log en JSON, los campos se pueden consultar con CloudWatch Logs Insights sin analizar texto.

La monitorización a fondo —paneles, alarmas, retención, Logs Insights— es la lección 05-01, y el trazado distribuido de una petición que atraviesa varias funciones y servicios es 05-02.

Lambda se integra con más de 200 servicios. Estos son los que importan al empezar:

Las tres formas de invocación tienen consecuencias muy distintas en el comportamiento ante errores:

La primera función reaccionaba a un evento interno. Ahora expondremos una función a internet para que la aplicación móvil de MercadoFresco consulte el estado de un pedido.

Hay dos formas de poner HTTP delante de una Lambda:

Empezamos con Function URL por simplicidad, sabiendo que producción pedirá API Gateway.

Cuatro decisiones de diseño que merecen atención:

• La conexión a la base de datos vive en el ámbito global y se reutiliza. Abrir una conexión a PostgreSQL cuesta decenas de milisegundos; hacerlo en cada invocación multiplicaría la latencia y saturaría RDS.
• Concurrencia reservada de 20 como techo de conexiones. Sin esto, un pico podría abrir cientos de conexiones y tumbar mercadofresco-pedidos. Es la lección de 02-04 aplicada: Lambda escala, RDS no. (Para casos exigentes existe RDS Proxy, que agrupa conexiones; queda fuera del alcance de esta lección.)
• Consulta parametrizada con %s, nunca concatenación de cadenas. Inyección SQL evitada.
• Los errores internos no se detallan al cliente: se registran en CloudWatch y se devuelve un mensaje genérico.

El límite de los 15 minutos es el que más decisiones de arquitectura condiciona. Si el proceso nocturno que recomprime las 40.000 fotos del catálogo tarda 3 horas, no es un trabajo para una sola Lambda: o se reparte en 40.000 invocaciones de dos segundos (que sí encajan perfectamente), o se ejecuta en una tarea de contenedor. Repartir es casi siempre la respuesta correcta con Lambda.

Lambda cobra dos conceptos:

1. Peticiones: 0,20 USD por millón.
2. Duración: 0,0000166667 USD por GB-segundo (x86_64; arm64 es un 20 % menos).

Y el nivel gratuito es permanente, no de 12 meses: 1 millón de peticiones y 400.000 GB-segundo al mes, siempre.

Caso 1: la función de miniaturas. Luis sube unas 20 fotos al día (600 al mes), la función usa 1.024 MB y tarda 1,8 segundos:

Coste cero. El equivalente en una EC2 t3.micro encendida para hacer lo mismo serían unos 7,50 USD al mes. Este es exactamente el caso de uso para el que Lambda existe.

Caso 2: el endpoint de estado de pedidos, en el escenario realista. MercadoFresco recibe unas 900.000 consultas al mes, la función usa 512 MB y tarda 120 ms, en arm64:

Caso 3: crecimiento a tres ciudades más (problema 3). Diez veces el tráfico: 9 millones de consultas al mes:

Menos de 4 dólares al mes para servir 9 millones de peticiones, sin un servidor que administrar, parchear o vigilar. Cuando la carga es irregular y por eventos, el modelo sin servidor es difícilmente batible.

El punto de equilibrio, para tenerlo presente: a partir de una utilización sostenida superior al 50-60 % de un servidor, un contenedor o una EC2 reservada salen más baratos. Lambda es cara si la usas como si fuera un servidor siempre encendido.

Qué ocurre cuando la función falla depende del modo de invocación:

"El evento se descarta" es la frase peligrosa. Si la función de miniaturas falla tres veces con una foto concreta, esa foto se queda sin miniatura y nadie se entera. La protección es un destino de error o una cola de mensajes fallidos (dead-letter queue, DLQ): un sitio donde acaban los eventos que no se pudieron procesar, para revisarlos y reprocesarlos.

Tres principios que hay que respetar desde el primer día:

1. Idempotencia. La entrega es "al menos una vez": la misma foto puede procesarse dos veces. Nuestra función lo cumple porque regenerar una miniatura sobre sí misma da el mismo resultado. Si la función incrementara un contador o cobrara un pago, habría que protegerla explícitamente.
2. Distinguir errores recuperables de los que no lo son. Un tiempo de espera de red merece reintento; un NoSuchKey no. Reintentar lo irrecuperable es tiempo y dinero tirados.
3. Vigilar la DLQ. Una cola de fallidos que nadie mira es lo mismo que no tenerla. Una alarma sobre ApproximateNumberOfMessagesVisible > 0 es obligatoria.

Aquí solo dejamos planteado el concepto. SQS se estudia en la lección 07-01, y los patrones completos de idempotencia, reintentos y colas de mensajes fallidos son la lección 07-05.

Este es el punto del curso donde conviene levantar la vista. MercadoFresco empezó el módulo 2 con un servidor físico en la oficina; termina con esto:

Lo que está resuelto y lo que no:

Y lo que aún no existe, que es mucho:

• Red propia. Todo está en la VPC por defecto, con las instancias expuestas. Falta diseñar subredes públicas y privadas, tablas de rutas, y sacar la base de datos a una subred sin salida a internet. Módulo 3.
• Balanceador de carga. Las cuatro instancias del ASG no reciben tráfico repartido, y no hay HTTPS ni dominio propio. 03-03 y 03-05.
• Distribución de contenido. El 97 % de la factura de S3 era transferencia de salida: CloudFront lo arregla. 03-04.
• Identidad y secretos con rigor. Hemos usado roles y Secrets Manager de pasada; falta la estructura completa de IAM, el cifrado con claves propias y la protección frente a ataques. Módulo 4.
• Observabilidad. Tenemos métricas sueltas y algún log. Falta un sistema de paneles, alarmas, trazas y auditoría de quién hizo qué. Módulo 5.
• Infraestructura como código. Todo lo hemos creado a mano o con comandos sueltos: no es reproducible ni revisable. Módulo 9.

• Crear los clientes de boto3 dentro del manejador. Se pagan 100-300 ms en cada invocación. Siempre en el ámbito global.
• No decodificar la clave de S3 con unquote_plus. Cualquier foto con espacios o eñes fallará con NoSuchKey. Es el fallo número uno de las Lambdas disparadas por S3.
• Procesar solo event["Records"][0]. Un evento puede traer varios registros. Itera siempre.
• Escribir en el mismo prefijo que dispara la función. Bucle infinito. Filtra por prefijo y restringe los permisos de escritura del rol, como defensa doble.
• Asignar 128 MB "para ahorrar". La CPU es proporcional a la memoria: la función tarda tanto que el coste no baja y la latencia se dispara. Mide con Max Memory Used y prueba varios valores.
• Poner el tiempo de espera a 900 s por defecto. Un cuelgue se pagará durante 15 minutos.
• Guardar estado en variables globales sin control. El entorno se reutiliza y una lista global crece hasta agotar la memoria.
• Dar AdministratorAccess al rol de ejecución. Concede solo las acciones y los recursos exactos que la función necesita.
• Olvidar lambda:add-permission para el origen del evento. El disparador no funciona y no aparece ningún error visible en ninguna parte.
• Abrir una conexión a RDS por invocación sin límite de concurrencia. Un pico de tráfico tumba la base de datos. Conexión en el ámbito global y concurrencia reservada.
• No configurar destino de error ni DLQ en invocaciones asíncronas. Los eventos fallidos se descartan en silencio.
• Devolver ficheros grandes en la respuesta. El límite síncrono es de 6 MB. Guarda en S3 y devuelve una URL prefirmada.
• Consejo: empieza en arm64 salvo que una dependencia lo impida. Es un 20 % de ahorro por cambiar un parámetro.

Para cada carga de MercadoFresco, decide entre Lambda, EC2/contenedor o una combinación, y justifica con los criterios de la lección:

• A) La tienda web PHP, que atiende tráfico de forma continua con un pico los viernes.
• B) Generar el PDF de la factura cuando un pedido se marca como entregado (unos 900 al día, 1,5 s cada uno).
• C) Recomprimir las 40.000 fotos del catálogo, un proceso que hoy tarda 3 horas seguidas.
• D) Un trabajo que cada noche a las 3:00 exporta los pedidos del día a S3; tarda 90 segundos.
• E) Un servicio de recomendación que carga un modelo de 4 GB en memoria y responde en menos de 50 ms.

La función de miniaturas está configurada con 1.024 MB y tarda 1.800 ms. Pruebas con AWS Lambda Power Tuning dan estos resultados:

MercadoFresco crece y ahora se procesan 200.000 fotos al mes (ya fuera del nivel gratuito de duración). Calcula el coste de duración de cada configuración en arm64 (0,0000133334 USD por GB-segundo) y decide cuál elegirías, teniendo en cuenta también la latencia.

MercadoFresco añade una tercera función, mercadofresco-exportar-pedidos, que cada noche:

1. Lee los pedidos del día de la réplica de lectura de RDS.
2. Obtiene las credenciales de la base de datos de Secrets Manager.
3. Escribe un fichero CSV en s3://mercadofresco-informes-analitica/informes/AAAA/MM/.
4. Envía una notificación a un tema de SNS cuando termina.
5. Escribe sus registros en CloudWatch Logs.

Escribe la política de permisos del rol de ejecución aplicando el mínimo privilegio, y explica dos permisos que deliberadamente no incluyes aunque podrían parecer necesarios.

Solución 1.

Solución 2.

Coste de duración en arm64, para 200.000 invocaciones:

Resultado revelador: las tres primeras configuraciones cuestan exactamente lo mismo, cero, porque todas caben en el nivel gratuito de 400.000 GB-segundo. La decisión, por tanto, no es económica sino de latencia y de margen.

Elección: 1.769 MB. Razones:

• Es la más rápida de las tres gratuitas: 1,15 s frente a 3,4 s, casi tres veces mejor.
• 1.769 MB corresponde a un vCPU completo, el punto donde Pillow deja de estar limitado por CPU.
• Se queda en 397.900 GB-segundo, muy justo respecto al límite. Si el volumen crece, empezará a costar: a 300.000 fotos serían 596.850 GB-segundo, es decir 2,62 USD al mes. Sigue siendo irrelevante.
• 3.008 MB se descarta: solo mejora 100 ms sobre 1.769 MB (la función ya no está limitada por CPU) y multiplica el consumo de GB-segundo, saliéndose del nivel gratuito.

La lección general: por encima de un vCPU, seguir subiendo memoria deja de acelerar y empieza a costar. El punto óptimo suele estar cerca de 1.769 MB para trabajos de un solo hilo.

Solución 3.

Dos permisos que deliberadamente NO se incluyen:

1. s3:GetObject y s3:DeleteObject sobre el bucket de informes. La función solo escribe: no necesita leer ni borrar nada. Excluirlos significa que, si la función se viera comprometida por una dependencia maliciosa, no podría exfiltrar los informes históricos de ventas ni destruirlos. Es el mismo razonamiento que aplicamos en la función de miniaturas.

2. Cualquier permiso de rds:*. Resulta contraintuitivo, porque la función consulta la base de datos, pero conectarse a PostgreSQL con usuario y contraseña no pasa por IAM: es una conexión TCP autenticada por el propio motor. Los permisos rds:* sirven para administrar instancias (crearlas, borrarlas, modificarlas), y la función no debe poder hacer nada de eso. Concederlos sería dar permiso para borrar la base de datos a un proceso que solo necesita leer una tabla. (La excepción sería la autenticación IAM de RDS, que sí requiere rds-db:connect sobre un recurso de usuario concreto.)

Detalles adicionales del diseño: el ARN del secreto lleva un comodín final porque Secrets Manager añade un sufijo aleatorio de seis caracteres al nombre; y los permisos de ec2:*NetworkInterface son obligatorios y con Resource: "*" cuando la función se conecta a recursos dentro de una VPC —es una de las poquísimas excepciones legítimas al mínimo privilegio, impuesta por el propio servicio.

Con esta lección MercadoFresco cierra su primer módulo de servicios reales. Sabes qué es la computación sin servidor y, más importante, cuándo no usarla: has comparado Lambda con EC2 y con contenedores en una tabla de criterios y has aplicado la regla de que por encima del 50-60 % de utilización sostenida el modelo deja de compensar. Dominas el modelo de ejecución —manejador, evento, contexto, respuesta— y el ciclo de vida del entorno, del que se deriva la optimización más rentable que existe en Lambda: crear los clientes de boto3 en el ámbito global, fuera del manejador, porque el entorno se reutiliza. Conoces el arranque en frío, qué lo alarga y las cuatro formas de mitigarlo, y sabes que la concurrencia reservada es a la vez una garantía y un freno, el freno que protege a RDS de la capacidad de Lambda para escalar sin límite.

Has entendido la relación memoria-CPU-coste, que es el parámetro que más gente configura mal, y lo has calculado con números: asignar 128 MB "para ahorrar" suele salir igual de caro y ocho veces más lento. Sabes elegir arm64 por un 20 % de ahorro, poner un tiempo de espera ajustado y no guardar contraseñas en variables de entorno.

Y has escrito la función que cierra el círculo abierto en la lección 02-03: mercadofresco-generar-miniaturas se dispara con el evento s3:ObjectCreated del bucket mercadofresco-catalogo-fotos, decodifica correctamente la clave con unquote_plus, itera sobre todos los registros del evento, escribe en un prefijo distinto del de entrada para no crear un bucle infinito, distingue los errores recuperables de los que no lo son y etiqueta lo que produce. La has empaquetado con Pillow en una capa compilada para la plataforma correcta, la has desplegado por consola y por CLI con create-function y update-function-code --publish, y le has dado un rol de ejecución de mínimo privilegio que solo puede leer bajo productos/, solo puede escribir bajo miniaturas/ y no puede borrar nada. Has añadido una segunda función, mercadofresco-estado-pedido, expuesta por Function URL, con la conexión a RDS reutilizada entre invocaciones, consultas parametrizadas, concurrencia limitada a 20 y errores que no filtran información al cliente. Sabes leer la línea REPORT de CloudWatch Logs para ajustar la memoria, has recorrido los orígenes de eventos habituales señalando dónde se estudia cada uno, conoces los límites reales —15 minutos, 250 MB, 512 MB en /tmp, 6 MB de payload síncrono— y has hecho el cálculo de precios que demuestra que servir 9 millones de peticiones cuesta menos de 4 dólares al mes. Por último, sabes qué pasa cuando una función falla en cada modo de invocación y por qué una cola de mensajes fallidos sin vigilancia es lo mismo que no tenerla.

Recapitulando el módulo entero: MercadoFresco tiene ya en eu-west-1 un grupo de Auto Scaling de la tienda repartido en dos zonas de disponibilidad, discos EBS con copias automáticas gestionadas por Data Lifecycle Manager, el catálogo de fotos en S3 con versionado y reglas de ciclo de vida, la base de datos de pedidos en RDS PostgreSQL con Multi-AZ, réplica de lectura y restauración a un punto en el tiempo, y dos funciones Lambda que reaccionan a eventos y responden por HTTP. El problema 2, las copias de seguridad no fiables, está resuelto de principio a fin. Los otros tres están encaminados pero incompletos.

Y lo que falta es, precisamente, lo que sostiene todo lo demás. Todo esto vive en la VPC por defecto: las instancias están expuestas donde no deberían, la base de datos comparte espacio de red con la tienda, no hay nada que reparta el tráfico entre las cuatro instancias del viernes, no hay HTTPS ni dominio propio, y el 97 % de la factura de S3 sigue siendo transferencia de salida sin caché. En el módulo 3, «Redes y entrega de contenido», empezando por la lección 03-01 «Amazon VPC», construiremos la red propia de MercadoFresco: subredes públicas y privadas en dos zonas de disponibilidad, tablas de rutas, puertas de enlace y una base de datos que deja de ser alcanzable desde internet. Sobre esa red montaremos después los grupos de seguridad, el balanceador que completa la solución al pico de los viernes, CloudFront para abaratar y acelerar las fotos, y Route 53 para que mercadofresco.example apunte por fin a la nube.