Na AWS uma função Lambda não se move: cria-se outra igual na região nova e, quando confirma que funciona, desliga ou apaga a antiga. O que assusta não é o código (é um zip que se descarrega e se volta a carregar), mas tudo o que há à volta: o agendamento que a lança todas as noites, o URL público que o seu site usa, a fila que a alimenta. Parte disso é regional e não viaja. Este guia diz-lhe o que se leva, o que não, e a ordem segura: primeiro a cópia, depois o teste, e só no fim a antiga.
Antes de começar: o que significa cada coisa
- Região
- O grupo de centros de dados onde vive a função (eu-west-1 é a Irlanda, eu-west-3 é Paris, eu-south-2 é Espanha). Quase tudo no Lambda é regional: a função, os seus registos, as suas regras.
- Pacote zip
- O ficheiro com o código da função. É o que se copia. As funções feitas como imagem de contentor movem-se de outra maneira (há que copiar a imagem para um registo ECR da região nova).
- Função (role) de execução
- A permissão com que corre a função (o que pode tocar). O IAM é global, por isso a mesma role serve em qualquer região: não é preciso criar outra.
- Agendamento (EventBridge)
- A regra "executa-a a cada 15 minutos" ou "todos os dias às 3:00". É regional: há que criá-la de novo na região de destino, com a mesma frequência.
- URL público
- O endereço web da função. Leva a região lá dentro: na região nova o endereço muda e há que atualizar o que o usava.
- Camada (layer)
- Bibliotecas partilhadas que a função carrega ao arrancar. As camadas são regionais: uma camada sua tem de ser publicada também na região nova.
Passo a passo
Faça o inventário do que rodeia a função
Abra a função na consola do Lambda e veja três sítios. Em Configuração → Gatilhos: o que a executa (EventBridge, S3, SNS, API Gateway, uma fila SQS). Em Configuração → URL da função: se tem URL público. Em Código → Camadas: se usa camadas. Anote também a memória, o tempo limite, as variáveis de ambiente e a role de execução (Configuração → Permissões). Com essa lista saberá o que vai viajar sozinho e o que terá de refazer.
Decida o que se leva e o que não
Leva-se tal e qual: o código, a linguagem (runtime), o handler, a memória, o tempo máximo, a arquitetura, as variáveis de ambiente, a descrição e a mesma role de execução. As camadas públicas da AWS costumam existir em todas as regiões com o mesmo nome; as suas não.
Os agendamentos recriam-se no destino com a mesma expressão. Os eventos do EventBridge com padrão (por exemplo "quando uma máquina para") são regras regionais sobre o que acontece nessa região: não faz sentido levá-las, criam-se novas se for preciso. As filas e fluxos (SQS, DynamoDB, Kinesis) continuam na sua região e continuarão a chamar a função antiga. Os avisos do S3 só chegam a funções da região do bucket. O SNS admite subscrições entre regiões, mas há que subscrever a função nova à mão. O API Gateway tem de ser apontado para a função nova. E os registos e métricas ficam onde estavam: a função nova começa com o histórico vazio.
Descarregue o código e crie a função na região nova
Na função antiga, Código → Ações → Exportar função → Baixar pacote de implantação: dá-lhe o zip. Mude de região em cima à direita, Criar função, mesmo nome, mesmo runtime e arquitetura, e em Permissões → Alterar a função de execução padrão → Usar uma função existente, escolha a role da antiga. Depois Carregar de → arquivo .zip com o que descarregou. Em Configuração geral ponha a mesma memória e tempo limite; em Variáveis de ambiente, as mesmas. Espere que o estado deixe de ser "Pendente".
Se usar a CLI, é um só comando a partir do 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}Recrie os agendamentos e o URL
Na região nova, abra EventBridge → Regras → Criar regra com o mesmo nome e a mesma expressão que a antiga tinha (copie-a da regra original:
rate(15 minutes),cron(0 3 * * ? *)). Destino: a função nova. O EventBridge acrescenta sozinho a permissão para a invocar. Se a regra original estava desabilitada, deixe a nova também desabilitada: vai ativá-la quando desligar a antiga.Se tinha URL público, Configuração → URL da função → Criar URL da função, mesmo tipo de autenticação. Anote o endereço novo: terá de o mudar no site ou programa que o chamava.
Teste a nova com as duas ligadas
Enquanto verifica, as duas funções existem e os dois agendamentos correm. Se à tarefa não faz mal repetir-se (um relatório, uma limpeza), deixe assim um dia e compare os registos do CloudWatch das duas. Se repetir-se for um problema (envia e-mails, cobra, escreve numa base de dados), crie o agendamento novo desabilitado, teste a função nova à mão com o botão Testar e um evento real, e no passo seguinte faça a mudança de uma vez.
Desligue a antiga, não a apague ainda
Primeiro deixe a antiga sem poder executar-se: Configuração → Simultaneidade → Reservar simultaneidade → 0. Com isso a AWS rejeita todas as suas execuções, mas o código e as regras continuam lá para o caso de ter de voltar atrás num minuto. Desabilite também a sua regra do EventBridge para que não acumule falhas. Habilite a regra da nova. Mude o URL no que o usava e volte a subscrever o SNS ou o API Gateway se os tinha.
Apague a antiga quando levar uma semana tranquilo
Passada uma semana sem sustos, apague a regra do EventBridge antiga e depois a função (Ações → Excluir). Os registos antigos ficam no CloudWatch Logs: nem se apagam nem lhe fazem falta para a função nova, mas convém pôr-lhes uma retenção (por exemplo 90 dias) para que não custem para sempre.
O que pode correr mal
A função nova cria-se mas falha com "não autorizado" ao executar-se
A role de execução é a mesma, mas o que a função toca (um bucket, uma tabela, um segredo) está na região antiga ou a sua política limita-o por região. Reveja na role as condições aws:RequestedRegion e os ARN com região, e que o que a função usa exista ou seja acessível a partir da região nova.
Ao criá-la diz que a camada não existe
As camadas são regionais. Se for sua, publique-a na região nova (Lambda → Camadas → Criar camada com o mesmo zip) e acrescente a versão nova à função. Se for uma camada pública da AWS, procure o seu ARN para essa região na documentação da camada: muda a região e às vezes o número de versão.
Executa-se duas vezes todas as noites
Tem os dois agendamentos habilitados. É o esperado enquanto testa; se já não o quiser, desabilite a regra da antiga (ou ponha a sua simultaneidade a 0).
O site que usava o URL público deixou de funcionar
O URL novo é diferente (leva a região). Mude o endereço no site. Se não puder mexer-lhe já, deixe a antiga ligada um pouco mais e faça a mudança com calma.
A fila SQS continua a chamar a antiga
As filas não mudam de região. Opções: deixar a função antiga como "ponte" que reencaminha para a nova, criar uma fila nova na região de destino e que quem escreve na fila mude de endereço, ou aceitar que essa parte fique onde está.
E para outra conta da AWS?
É o mesmo processo com uma diferença importante: a role de execução vive na conta, por isso na conta nova a função não pode usar a da antiga. Crie lá uma role para o Lambda (ou use a que já tiver) e, se a função toca no S3, em bases de dados ou em filas, dê-lhe essas permissões: a cópia cria-se bem mas vai falhar ao executar-se até a role poder fazer o que o código faz. As variáveis de ambiente copiam-se tal e qual: se guardam endereços ou chaves da conta antiga, mude-as. E as filas, buckets e APIs não mudam de conta: há que recriá-los ou ligá-los de novo.
No Simplio, "Mover para outra conta" pede uma chave de acesso da outra conta registada em Chaves de acesso, verifica antes que tem permissões para criar funções, e cria a cópia com a role simplio-lambda-ejecucion dessa conta (a do script da Ajuda), avisando-o de que só escreve registos e de que amplie essa role se a função precisar de mais.
No Simplio
No Simplio, no cartão da função há um botão Mover de região…. Escolhe a região, vê antes o que se leva (código, definições, role, agendamentos) e o que não (filas, avisos do S3, registos), confirma com o duplo fator e a cópia aparece com os seus agendamentos recriados, em pausa se o estavam. A original não é tocada: no seu cartão fica o aviso "Copiada para … a …; a original continua ativa" com os botões Pausar a original e Apagar a original, que só apaga se a cópia existir e estiver ativa. Se algo falhar pelo caminho, o Simplio desfaz o que foi criado no destino e conta-lho em linguagem simples.
O mesmo, na AWS e no Simplio
| Na consola da AWS | No Simplio | |
|---|---|---|
| Saber o que viaja e o que não | Rever à mão gatilhos, URL, camadas e role em vários ecrãs | Uma pré-visualização no mesmo cartão: o que se leva, o que se recria e o que há que refazer, antes de tocar em nada |
| Criar a cópia | Descarregar o zip, criar a função, repetir memória, tempo, variáveis e role; criar as regras uma a uma | Um botão "Mover de região…": copia, espera que esteja ativa, recria os agendamentos com a mesma frequência e o URL se o tinha |
| Se algo falha a meio | Fica uma função meio criada e regras soltas que há que limpar | Desfaz-se tudo o que foi criado no destino e a original não é tocada |
| Desligar e apagar a antiga | Simultaneidade a 0, desabilitar regras, apagar depois | Dois botões no cartão da original: "Pausar a original" (reversível) e "Apagar a original", que só atua se a cópia estiver ativa |