Come spostare una funzione Lambda in un'altra regione senza perdere le sue pianificazioni

In AWS una funzione Lambda non si sposta: se ne crea un'altra uguale nella nuova regione e, quando verifichi che funziona, spegni o cancelli la vecchia. Quello che spaventa non è il codice (è uno zip che si scarica e si ricarica), ma tutto quello che c'è intorno: la pianificazione che la lancia ogni notte, l'URL pubblico che usa il tuo sito, la coda che la alimenta. Parte di questo è regionale e non viaggia. Questa guida ti dice cosa si porta dietro, cosa no, e l'ordine sicuro: prima la copia, poi la prova, e solo alla fine la vecchia.

Passo dopo passo

1. Fai l'inventario di quello che circonda la funzione

   Apri la funzione nella console di Lambda e guarda in tre posti. In Configuration → Triggers: cosa la esegue (EventBridge, S3, SNS, API Gateway, una coda SQS). In Configuration → Function URL: se ha un URL pubblico. In Code → Layers: se usa layer. Annota anche memoria, timeout, variabili d'ambiente e il ruolo di esecuzione (Configuration → Permissions). Con quell'elenco saprai cosa viaggerà da solo e cosa dovrai rifare.

2. Decidi cosa si porta dietro e cosa no

   Si porta dietro così com'è: il codice, il linguaggio (runtime), l'handler, la memoria, il tempo massimo, l'architettura, le variabili d'ambiente, la descrizione e lo stesso ruolo di esecuzione. I layer pubblici di AWS di solito esistono in tutte le regioni con lo stesso nome; i tuoi no.

   Le pianificazioni si ricreano a destinazione con la stessa espressione. Gli eventi di EventBridge con pattern (per esempio "quando si ferma una macchina") sono regole regionali su quello che succede in quella regione: non ha senso portarle, se ne creano di nuove se serve. Le code e i flussi (SQS, DynamoDB, Kinesis) restano nella loro regione e continueranno a chiamare la vecchia funzione. Le notifiche di S3 arrivano solo a funzioni della regione del bucket. SNS ammette sottoscrizioni tra regioni, ma bisogna sottoscrivere la nuova funzione a mano. API Gateway va puntato alla nuova funzione. E i log e le metriche restano dov'erano: la nuova funzione parte con lo storico vuoto.

3. Scarica il codice e crea la funzione nella nuova regione

   Nella vecchia funzione, Code → Actions → Export function → Download deployment package: ti dà lo zip. Cambia regione in alto a destra, Create function, stesso nome, stesso runtime e architettura, e in Permissions → Change default execution role → Use an existing role, scegli il ruolo della vecchia. Poi Upload from → .zip file con quello che hai scaricato. In General configuration metti la stessa memoria e lo stesso timeout; in Environment variables, le stesse. Aspetta che lo stato smetta di essere "Pending".

   Se usi la CLI, è un solo comando a partire dallo 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. Ricrea le pianificazioni e l'URL

   Nella nuova regione, apri EventBridge → Rules → Create rule con lo stesso nome e la stessa espressione che aveva la vecchia (copiala dalla regola originale: rate(15 minutes), cron(0 3 * * ? *)). Destinazione: la nuova funzione. EventBridge aggiunge da solo il permesso per invocarla. Se la regola originale era disabilitata, lascia disabilitata anche la nuova: la attiverai quando spegnerai la vecchia.

   Se aveva un URL pubblico, Configuration → Function URL → Create function URL, stesso tipo di autenticazione. Annota il nuovo indirizzo: dovrai cambiarlo nel sito o nel programma che lo chiamava.

5. Prova la nuova con entrambe accese

   Mentre verifichi, le due funzioni esistono e le due pianificazioni girano. Se all'attività non dà fastidio ripetersi (un report, una pulizia), lascia così per un giorno e confronta i log di CloudWatch delle due. Se ripetersi è un problema (invia email, addebita, scrive in un database), crea la nuova pianificazione disabilitata, prova la nuova funzione a mano con il pulsante Test e un evento reale, e nel passo seguente fai il cambio in un colpo solo.

6. Spegni la vecchia, non cancellarla ancora

   Prima lascia la vecchia senza possibilità di essere eseguita: Configuration → Concurrency → Reserve concurrency → 0. Con questo AWS rifiuta tutte le sue esecuzioni, ma il codice e le regole restano lì nel caso tu debba tornare indietro in un minuto. Disabilita anche la sua regola di EventBridge perché non accumuli errori. Abilita la regola della nuova. Cambia l'URL in quello che lo usava e sottoscrivi di nuovo SNS o API Gateway se li aveva.

7. Cancella la vecchia quando è passata una settimana tranquilla

   Passata una settimana senza spaventi, cancella la vecchia regola di EventBridge e poi la funzione (Actions → Delete). I vecchi log restano in CloudWatch Logs: non si cancellano né ti servono per la nuova funzione, ma conviene impostare una conservazione (per esempio 90 giorni) perché non costino per sempre.

Cosa può andare storto