Cómo mover una función Lambda a otra región sin perder sus programaciones

En AWS una función Lambda no se mueve: se crea otra igual en la región nueva y, cuando compruebas que funciona, apagas o borras la antigua. Lo que asusta no es el código (es un zip que se descarga y se vuelve a subir), sino todo lo que hay alrededor: la programación que la lanza cada noche, la URL pública que usa tu web, la cola que la alimenta. Parte de eso es regional y no viaja. Esta guía te dice qué se lleva, qué no, y el orden seguro: primero la copia, después la prueba, y solo al final la antigua.

Paso a paso

1. Haz inventario de lo que rodea a la función

   Abre la función en la consola de Lambda y mira tres sitios. En Configuración → Desencadenadores: qué la ejecuta (EventBridge, S3, SNS, API Gateway, una cola SQS). En Configuración → URL de función: si tiene URL pública. En Código → Capas: si usa capas. Apunta también memoria, tiempo de espera, variables de entorno y el rol de ejecución (Configuración → Permisos). Con esa lista sabrás qué va a viajar solo y qué tendrás que rehacer.

2. Decide qué se lleva y qué no

   Se lleva tal cual: el código, el lenguaje (runtime), el handler, la memoria, el tiempo máximo, la arquitectura, las variables de entorno, la descripción y el mismo rol de ejecución. Las capas públicas de AWS suelen existir en todas las regiones con el mismo nombre; las tuyas no.

   Las programaciones se recrean en destino con la misma expresión. Los eventos de EventBridge con patrón (por ejemplo "cuando se para una máquina") son reglas regionales sobre lo que pasa en esa región: no tiene sentido llevarlas, se crean nuevas si hace falta. Las colas y flujos (SQS, DynamoDB, Kinesis) siguen en su región y seguirán llamando a la función antigua. Los avisos de S3 solo llegan a funciones de la región del bucket. SNS admite suscripciones entre regiones, pero hay que suscribir la función nueva a mano. API Gateway hay que apuntarla a la función nueva. Y los registros y métricas se quedan donde estaban: la función nueva empieza con el historial vacío.

3. Descarga el código y crea la función en la región nueva

   En la función antigua, Código → Acciones → Exportar función → Descargar paquete de implementación: te da el zip. Cambia de región arriba a la derecha, Crear función, mismo nombre, mismo runtime y arquitectura, y en Permisos → Cambiar el rol de ejecución predeterminado → Usar un rol existente, elige el rol de la antigua. Después Cargar desde → archivo .zip con el que descargaste. En Configuración general pon la misma memoria y tiempo de espera; en Variables de entorno, las mismas. Espera a que el estado deje de ser "Pendiente".

   Si usas la CLI, es un solo comando a partir del zip:

   aws lambda create-function --region eu-west-3 --function-name mi-funcion \
     --runtime python3.12 --handler lambda_function.lambda_handler \
     --role arn:aws:iam::123456789012:role/mi-rol --zip-file fileb://mi-funcion.zip \
     --memory-size 256 --timeout 60 --environment Variables={CLAVE=valor}

4. Recrea las programaciones y la URL

   En la región nueva, abre EventBridge → Reglas → Crear regla con el mismo nombre y la misma expresión que tenía la antigua (cópiala de la regla original: rate(15 minutes), cron(0 3 * * ? *)). Destino: la función nueva. EventBridge añade solo el permiso para invocarla. Si la regla original estaba deshabilitada, deja la nueva también deshabilitada: la activarás cuando apagues la antigua.

   Si tenía URL pública, Configuración → URL de función → Crear URL de función, mismo tipo de autenticación. Apunta la dirección nueva: tendrás que cambiarla en la web o programa que la llamaba.

5. Prueba la nueva con las dos encendidas

   Mientras compruebas, las dos funciones existen y las dos programaciones corren. Si la tarea no pasa nada por repetirse (un informe, una limpieza), déjalo así un día y compara los registros de CloudWatch de las dos. Si repetirse es un problema (envía correos, cobra, escribe en una base), crea la programación nueva deshabilitada, prueba la función nueva a mano con el botón Probar y un evento real, y en el paso siguiente haz el cambio de una vez.

6. Apaga la antigua, no la borres todavía

   Primero deja la antigua sin poder ejecutarse: Configuración → Simultaneidad → Reservar simultaneidad → 0. Con eso AWS rechaza todas sus ejecuciones, pero el código y las reglas siguen ahí por si tienes que volver atrás en un minuto. Deshabilita también su regla de EventBridge para que no acumule fallos. Habilita la regla de la nueva. Cambia la URL en lo que la usaba y vuelve a suscribir SNS o API Gateway si los tenía.

7. Borra la antigua cuando lleves una semana tranquilo

   Pasada una semana sin sustos, borra la regla de EventBridge antigua y después la función (Acciones → Eliminar). Los registros antiguos se quedan en CloudWatch Logs: ni se borran ni te hacen falta para la función nueva, pero conviene ponerles una retención (por ejemplo 90 días) para que no cuesten para siempre.

Qué puede salir mal