Eine Lambda-Funktion in eine andere Region verschieben, ohne ihre Zeitpläne zu verlieren

In AWS wird eine Lambda-Funktion nicht verschoben: Man legt eine gleiche in der neuen Region an und schaltet die alte ab oder löscht sie, sobald man geprüft hat, dass die neue funktioniert. Was Angst macht, ist nicht der Code (das ist ein Zip, das man herunterlädt und wieder hochlädt), sondern alles drumherum: der Zeitplan, der sie jede Nacht startet, die öffentliche URL, die Ihre Website benutzt, die Warteschlange, die sie füttert. Ein Teil davon ist regional und kommt nicht mit. Diese Anleitung sagt Ihnen, was mitkommt, was nicht, und die sichere Reihenfolge: zuerst die Kopie, dann der Test, und erst ganz zum Schluss die alte.

Schritt für Schritt

1. Machen Sie eine Bestandsaufnahme dessen, was die Funktion umgibt

   Öffnen Sie die Funktion in der Lambda-Konsole und sehen Sie an drei Stellen nach. Unter Konfiguration → Auslöser: was sie ausführt (EventBridge, S3, SNS, API Gateway, eine SQS-Warteschlange). Unter Konfiguration → Funktions-URL: ob sie eine öffentliche URL hat. Unter Code → Layer: ob sie Layer verwendet. Notieren Sie auch Arbeitsspeicher, Timeout, Umgebungsvariablen und die Ausführungsrolle (Konfiguration → Berechtigungen). Mit dieser Liste wissen Sie, was von selbst mitkommt und was Sie neu machen müssen.

2. Entscheiden Sie, was mitkommt und was nicht

   Unverändert mit kommen: der Code, die Sprache (Runtime), der Handler, der Arbeitsspeicher, die maximale Laufzeit, die Architektur, die Umgebungsvariablen, die Beschreibung und dieselbe Ausführungsrolle. Die öffentlichen Layer von AWS gibt es meist in allen Regionen unter demselben Namen; Ihre eigenen nicht.

   Die Zeitpläne werden im Ziel mit demselben Ausdruck neu angelegt. EventBridge-Ereignisse mit Muster (zum Beispiel „wenn eine Maschine gestoppt wird“) sind regionale Regeln über das, was in dieser Region passiert: Es ergibt keinen Sinn, sie mitzunehmen; bei Bedarf werden neue angelegt. Warteschlangen und Streams (SQS, DynamoDB, Kinesis) bleiben in ihrer Region und rufen weiter die alte Funktion auf. S3-Benachrichtigungen erreichen nur Funktionen in der Region des Buckets. SNS erlaubt Abonnements zwischen Regionen, aber die neue Funktion muss von Hand abonniert werden. API Gateway muss auf die neue Funktion gezeigt werden. Und die Protokolle und Metriken bleiben, wo sie waren: Die neue Funktion startet mit leerer Historie.

3. Laden Sie den Code herunter und legen Sie die Funktion in der neuen Region an

   In der alten Funktion, Code → Aktionen → Funktion exportieren → Bereitstellungspaket herunterladen: Das gibt Ihnen das Zip. Wechseln Sie oben rechts die Region, Funktion erstellen, derselbe Name, dieselbe Runtime und Architektur, und unter Berechtigungen → Standard-Ausführungsrolle ändern → Vorhandene Rolle verwenden wählen Sie die Rolle der alten. Danach Hochladen von → .zip-Datei mit dem, das Sie heruntergeladen haben. Setzen Sie unter Allgemeine Konfiguration denselben Arbeitsspeicher und dasselbe Timeout; unter Umgebungsvariablen dieselben. Warten Sie, bis der Status nicht mehr „Ausstehend“ ist.

   Wenn Sie die CLI verwenden, ist es ein einziger Befehl ausgehend vom 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. Legen Sie die Zeitpläne und die URL neu an

   Öffnen Sie in der neuen Region EventBridge → Regeln → Regel erstellen mit demselben Namen und demselben Ausdruck wie die alte (kopieren Sie ihn aus der Originalregel: rate(15 minutes), cron(0 3 * * ? *)). Ziel: die neue Funktion. EventBridge fügt die Berechtigung, sie aufzurufen, selbst hinzu. Wenn die Originalregel deaktiviert war, lassen Sie die neue ebenfalls deaktiviert: Sie aktivieren sie, wenn Sie die alte abschalten.

   Wenn sie eine öffentliche URL hatte, Konfiguration → Funktions-URL → Funktions-URL erstellen, derselbe Authentifizierungstyp. Notieren Sie die neue Adresse: Sie müssen sie in der Website oder dem Programm ändern, das sie aufgerufen hat.

5. Testen Sie die neue, während beide eingeschaltet sind

   Während Sie prüfen, existieren beide Funktionen und beide Zeitpläne laufen. Wenn es der Aufgabe nichts ausmacht, wiederholt zu werden (ein Bericht, eine Bereinigung), lassen Sie es einen Tag so und vergleichen Sie die CloudWatch-Protokolle der beiden. Wenn Wiederholen ein Problem ist (sie verschickt E-Mails, bucht ab, schreibt in eine Datenbank), legen Sie den neuen Zeitplan deaktiviert an, testen Sie die neue Funktion von Hand mit der Schaltfläche Testen und einem echten Ereignis, und machen Sie im nächsten Schritt den Wechsel auf einmal.

6. Schalten Sie die alte ab, löschen Sie sie noch nicht

   Sorgen Sie zuerst dafür, dass die alte nicht mehr laufen kann: Konfiguration → Parallelität → Parallelität reservieren → 0. Damit weist AWS alle ihre Ausführungen ab, aber Code und Regeln bleiben da, falls Sie in einer Minute zurück müssen. Deaktivieren Sie auch ihre EventBridge-Regel, damit sie keine Fehler ansammelt. Aktivieren Sie die Regel der neuen. Ändern Sie die URL dort, wo sie benutzt wurde, und abonnieren Sie SNS oder API Gateway neu, falls vorhanden.

7. Löschen Sie die alte, wenn eine Woche lang Ruhe war

   Nach einer Woche ohne Zwischenfälle löschen Sie die alte EventBridge-Regel und danach die Funktion (Aktionen → Löschen). Die alten Protokolle bleiben in CloudWatch Logs: Sie werden weder gelöscht noch brauchen Sie sie für die neue Funktion, aber es lohnt sich, ihnen eine Aufbewahrung zu geben (zum Beispiel 90 Tage), damit sie nicht für immer Kosten verursachen.

Was schiefgehen kann