Comment déplacer une fonction Lambda vers une autre région sans perdre ses planifications

Chez AWS, une fonction Lambda ne se déplace pas : on en crée une autre identique dans la nouvelle région et, quand on a vérifié qu'elle fonctionne, on éteint ou on supprime l'ancienne. Ce qui fait peur, ce n'est pas le code (c'est un zip qu'on télécharge et qu'on renvoie), mais tout ce qu'il y a autour : la planification qui la lance chaque nuit, l'URL publique qu'utilise votre site, la file qui l'alimente. Une partie de cela est régionale et ne voyage pas. Ce guide vous dit ce qui part avec elle, ce qui ne part pas, et l'ordre sûr : d'abord la copie, ensuite le test, et seulement à la fin l'ancienne.

Pas à pas

1. Faites l'inventaire de ce qui entoure la fonction

   Ouvrez la fonction dans la console Lambda et regardez trois endroits. Dans Configuration → Déclencheurs : ce qui l'exécute (EventBridge, S3, SNS, API Gateway, une file SQS). Dans Configuration → URL de fonction : si elle a une URL publique. Dans Code → Couches : si elle utilise des couches. Notez aussi la mémoire, le délai d'expiration, les variables d'environnement et le rôle d'exécution (Configuration → Autorisations). Avec cette liste, vous saurez ce qui va voyager tout seul et ce que vous devrez refaire.

2. Décidez ce qui part et ce qui reste

   Part tel quel : le code, le langage (runtime), le handler, la mémoire, le temps maximal, l'architecture, les variables d'environnement, la description et le même rôle d'exécution. Les couches publiques d'AWS existent généralement dans toutes les régions sous le même nom ; les vôtres, non.

   Les planifications se recréent à destination avec la même expression. Les événements EventBridge à motif (par exemple « quand une machine s'arrête ») sont des règles régionales sur ce qui se passe dans cette région : cela n'a pas de sens de les emporter, on en crée de nouvelles si besoin. Les files et flux (SQS, DynamoDB, Kinesis) restent dans leur région et continueront d'appeler l'ancienne fonction. Les notifications S3 n'arrivent qu'aux fonctions de la région du bucket. SNS accepte les abonnements entre régions, mais il faut abonner la nouvelle fonction à la main. API Gateway doit être pointée vers la nouvelle fonction. Et les journaux et métriques restent où ils étaient : la nouvelle fonction démarre avec un historique vide.

3. Téléchargez le code et créez la fonction dans la nouvelle région

   Dans l'ancienne fonction, Code → Actions → Exporter la fonction → Télécharger le package de déploiement : vous obtenez le zip. Changez de région en haut à droite, Créer une fonction, même nom, même runtime et architecture, et dans Autorisations → Modifier le rôle d'exécution par défaut → Utiliser un rôle existant, choisissez le rôle de l'ancienne. Ensuite Charger à partir de → fichier .zip avec celui que vous avez téléchargé. Dans Configuration générale, mettez la même mémoire et le même délai d'expiration ; dans Variables d'environnement, les mêmes. Attendez que l'état ne soit plus « En attente ».

   Si vous utilisez la CLI, c'est une seule commande à partir du 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. Recréez les planifications et l'URL

   Dans la nouvelle région, ouvrez EventBridge → Règles → Créer une règle avec le même nom et la même expression que l'ancienne (copiez-la depuis la règle d'origine : rate(15 minutes), cron(0 3 * * ? *)). Cible : la nouvelle fonction. EventBridge ajoute tout seul la permission de l'invoquer. Si la règle d'origine était désactivée, laissez la nouvelle désactivée aussi : vous l'activerez quand vous éteindrez l'ancienne.

   Si elle avait une URL publique, Configuration → URL de fonction → Créer une URL de fonction, même type d'authentification. Notez la nouvelle adresse : vous devrez la changer dans le site ou le programme qui l'appelait.

5. Testez la nouvelle avec les deux allumées

   Pendant que vous vérifiez, les deux fonctions existent et les deux planifications tournent. Si la tâche peut se répéter sans conséquence (un rapport, un nettoyage), laissez les choses ainsi une journée et comparez les journaux CloudWatch des deux. Si la répétition pose problème (elle envoie des courriels, facture, écrit dans une base), créez la nouvelle planification désactivée, testez la nouvelle fonction à la main avec le bouton Tester et un événement réel, et à l'étape suivante faites la bascule d'un coup.

6. Éteignez l'ancienne, ne la supprimez pas encore

   D'abord, empêchez l'ancienne de s'exécuter : Configuration → Simultanéité → Réserver la simultanéité → 0. Ainsi AWS refuse toutes ses exécutions, mais le code et les règles restent là au cas où vous devriez revenir en arrière en une minute. Désactivez aussi sa règle EventBridge pour qu'elle n'accumule pas d'échecs. Activez la règle de la nouvelle. Changez l'URL dans ce qui l'utilisait et réabonnez SNS ou API Gateway si elle en avait.

7. Supprimez l'ancienne après une semaine tranquille

   Après une semaine sans frayeur, supprimez l'ancienne règle EventBridge puis la fonction (Actions → Supprimer). Les anciens journaux restent dans CloudWatch Logs : ils ne sont pas supprimés et vous n'en avez pas besoin pour la nouvelle fonction, mais il vaut mieux leur mettre une rétention (par exemple 90 jours) pour qu'ils ne coûtent pas pour toujours.

Ce qui peut mal tourner