Migrar cargas de trabalho AWS Lambda para Funções do Azure

Migrar uma carga de trabalho serverless que utiliza o AWS Lambda para o Funções do Azure requere um planeamento e uma implementação cuidadosos. Este artigo fornece orientações essenciais para ajudá-lo a:

• Execute um processo de descoberta em sua carga de trabalho existente.
• Saiba como executar as principais atividades de migração, como planejamento pré-migração e avaliação da carga de trabalho.
• Avalie e otimize uma carga de trabalho migrada.

Âmbito de aplicação

Este artigo descreve a migração de uma instância AWS Lambda para o Funções do Azure.

Este artigo não aborda:

• Migre para a sua própria solução de alojamento de contentores, como através do Azure Container Apps.
• Hospedar contentores AWS Lambda no Azure.
• Abordagens fundamentais de adoção do Azure pela sua organização, como zonas de aterragem do Azure ou outros tópicos abordados na metodologia de migração do Cloud Adoption Framework .

Migrar com GitHub Copilot e Azure Skills

O GitHub Copilot com Azure Skills tem suporte integrado para orientar a migração do AWS Lambda para o Funções do Azure.

Pode usar o Copilot para automatizar a maioria dos passos de migração de forma interativa, utilizando este artigo como referência para decisões de arquitetura, validação e prontidão para produção.

Para usar o Azure Skills no GitHub Copilot (no VS Code ou Copilot CLI), siga estes passos:

Pré-requisitos

• Node.js 18+ - necessário para servidores MCP (Download Node.js)
• Acesso a uma subscrição Azure para criar e testar a sua aplicação de funções migrada.
• CLI do Azure (az) instalado e autenticado (Instalar CLI do Azure) (az login)
• Azure CLI de Desenvolvedor (azd) instalado e autenticado (Instalar Azure CLI de Desenvolvedor) (azd auth login)

Para a CLI do GitHub Copilot

1. Instalar Copilot CLI
2. Adicione a fonte do marketplace (apenas pela primeira vez):

   /plugin marketplace add microsoft/azure-skills
   

3. Instale o plugin:

   /plugin install azure@azure-skills
   

4. Após a instalação, recarregue os servidores MCP:

   /mcp reload
   

5. Verificar instalação:

   /mcp status
   

   Deves ver o servidor MCP Azure listado e a funcionar.

Para Visual Studio Code

1. Instale a extensão Azure MCP a partir do VS Code Marketplace (ID da extensão: ms-azuretools.vscode-azure-mcp-server).
2. A extensão instala automaticamente uma extensão complementar, GitHub Copilot para Azure, que contém as competências do Azure.
3. Abrir o Copilot Chat (Ctrl+Shift+I / Cmd+Shift+I).
4. Certifica-te de que estás no modo Agente (não no modo Perguntar ou Editar).
5. Abra a Paleta de Comandos (Ctrl+Shift+P) -> procure "MCP" -> verifique se os servidores estão listados e a funcionar.

Use este prompt para iniciar e continuar o fluxo de migração no Copilot:

Help me migrate my Lambda app to Azure Functions

Este prompt orienta a migração em fases: primeiro gerando um relatório de avaliação detalhado, depois migrando código e configuração, e finalmente construindo os ativos de infraestrutura como código (IaC) necessários para implementação no Azure.

Comparar funcionalidade

Este artigo mapeia as funcionalidades do AWS Lambda para equivalentes ao Funções do Azure para ajudar a garantir a compatibilidade.

Perspetiva da carga de trabalho

Este artigo foca-se em como migrar uma carga de trabalho AWS Lambda para Funções do Azure e nas dependências comuns para cargas de trabalho serverless. Esse processo pode envolver vários serviços porque as cargas de trabalho compreendem muitos recursos e processos para gerenciar esses recursos. Para ter uma estratégia abrangente, você deve combinar as recomendações apresentadas neste artigo com um plano maior que inclua os outros componentes e processos em sua carga de trabalho.

Executar um processo de descoberta em sua carga de trabalho existente

A primeira etapa é conduzir um processo de descoberta detalhado para avaliar sua carga de trabalho existente do AWS Lambda. O objetivo é entender em quais recursos e serviços da AWS sua carga de trabalho depende. Compile um inventário abrangente de suas funções do AWS Lambda usando ferramentas da AWS, como SDKs específicos de serviço, APIs, CloudTrail e AWS CLI para avaliar a carga de trabalho na AWS. Você deve entender os seguintes aspectos-chave do seu inventário do AWS Lambda:

• Casos de uso
• Configurações
• Configurações de segurança e rede
• Ferramentas, monitorização, registo e mecanismos de observabilidade
• Dependências
• Objetivos de fiabilidade e estado de fiabilidade atual
• Custo de propriedade
• Metas de desempenho e desempenho atual

Executar o planeamento de pré-migração

Antes de começar a migrar a sua carga de trabalho, deve mapear as funcionalidades AWS Lambda para o Funções do Azure para garantir a compatibilidade e desenvolver um plano de migração. Em seguida, você pode selecionar as principais cargas de trabalho para uma prova de conceito.

Também precisas de mapear os serviços AWS de que o Lambda depende para as dependências equivalentes em Azure.

Mapear funcionalidades do AWS Lambda para o Funções do Azure

As tabelas seguintes comparam conceitos, recursos e propriedades AWS Lambda com os seus equivalentes correspondentes no Funções do Azure, especificamente, o plano de alojamento Flex Consumption.

• Idiomas suportados
• Modelo de programação
• Gatilhos e associações de eventos
• Permissões
• URL da função
• Ligação em rede
• Observabilidade e monitorização
• Dimensionamento e concorrência
• Proteção contra arranque a frio
• Preços
• Armazenamento de código-fonte
• Desenvolvimento local
• Implementação
• Tempo limite e limites de memória
• Gestão de segredos
• Gestão de estados
• Orquestração com estado
• Outras diferenças e considerações

Idiomas suportados

Modelo de programação

Gatilhos e vinculações de eventos

Permissões

URL da função

Rede

Observabilidade e monitorização

Dimensionamento e simultaneidade

Proteção contra arranque a frio

Preços

Armazenamento de código-fonte

Desenvolvimento local

Implantação

Tempo limite e limites de memória

Gestão de segredos

Gestão do Estado

Orquestração com estado

Outras diferenças e considerações

Criar um plano de migração

1. Selecione as principais cargas de trabalho para uma prova de conceito.

   Comece selecionando uma a duas cargas de trabalho não críticas de médio porte do seu inventário total. Essas cargas de trabalho servem como base para a sua migração de prova de conceito. Você pode testar o processo e identificar possíveis desafios sem correr o risco de grandes interrupções em suas operações.

2. Teste iterativamente e recolha feedback.

   Use a prova de conceito para coletar feedback, identificar lacunas e ajustar o processo antes de dimensionar para cargas de trabalho maiores. Essa abordagem iterativa garante que, no momento em que você passar para a migração em grande escala, você abordará os desafios potenciais e refinará o processo.

Criar os recursos de migração

Esta etapa é uma fase transitória de desenvolvimento. Durante esta fase, constróis o código-fonte, templates de infraestrutura como código (IaC) e pipelines de implementação para representar a carga de trabalho no Azure. Você deve adaptar o código de função para compatibilidade e práticas recomendadas antes de executar a migração.

• Adapte o código de função, os arquivos de configuração e a infraestrutura como arquivos de código
• Ajustar definições de configuração
• Gerar arquivos IaC
• Usar ferramentas para refatoração

Adapte o código de função, os arquivos de configuração e a infraestrutura como arquivos de código

Para atualizar código para os requisitos de runtime do Funções do Azure:

• Modifica o teu código para aderir ao modelo de programação do Funções do Azure. Por exemplo, adapta as assinaturas das tuas funções para corresponder ao formato que o Funções do Azure exige. Para mais informações sobre definição de funções e contexto de execução, consulte Funções do Azure developers guides.

• Use o pacote de extensões Funções do Azure para gerir vários bindings e triggers semelhantes aos serviços da AWS. Para aplicações .NET, deve usar os pacotes NuGet apropriados em vez do pacote de extensões.

• Use o pacote de extensões para integrar com outros serviços do Azure, como Armazenamento do Azure, Azure Service Bus e Azure Cosmos DB, sem necessidade de configurar manualmente cada binding através de SDKs. Para mais informações, consulte Ligar funções a serviços do Azure usando ligações e padrões de expressão de ligação das funções do Azure.

Esses trechos são exemplos de código SDK comum. O código AWS Lambda mapeia para os gatilhos, associações ou excertos de código SDK correspondentes no serviço do Funções do Azure.

Leitura da Amazon S3 versus Armazenamento de Blobs do Azure

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

exports.handler = async (event) => {
const params = {
Bucket: 'my-bucket',
Key: 'my-object.txt',
};
const data = await
s3.getObject(params).promise();
console.log('File content:',
data.Body.toString());
};       

import { app } from '@azure/functions';

app.storageblob('blobTrigger', { 
path: 'my-container/{blobName}',
connection: 'AzureWebJobsStorage',
}, async (context, myBlob) => { 
context.log(`Blob content:
${myBlob.toString()}`);
});

Escrita para o Amazon Simple Queue Service (SQS) versus Armazenamento de Filas do Azure

const AWS = require('aws-sdk');
const sqs = new AWS.SQS(); 

exports.handler = async (event) => {
const params = {
QueueUrl:
'https://sqs.amazonaws.com/123456789012/MyQueue',
MessageBody: 'Hello, world!',
};
await
sqs.sendMessage(params).promise();
};

import { app } from '@azure/functions';

app.queue('queueTrigger', { 
queueName: 'myqueue-items',
connection: 'AzureWebJobsStorage',
}, async (context, queueMessage) => {
context.log(`Queue message: 
${queueMessage}`);
}); 

Escrever em DynamoDB versus Azure Cosmos DB

const AWS = require('aws-sdk'); 
const dynamoDb = new AWS.DynamoDB.DocumentClient();   

exports.handler = async (event) => { 
const params = { 
TableName: 'my-table', 
Key: { id: '123' }, 
}; 
const data = await dynamoDb.get(params).promise(); 
console.log('DynamoDB record:', data.Item); 
}; 

import { app } from '@azure/functions';  

app.cosmosDB('cosmosTrigger', { 
connectionStringSetting: 'CosmosDBConnection', 
databaseName: 'my-database', 
containerName: 'my-container', 
leaseContainerName: 'leases', 
}, async (context, documents) => { 
documents.forEach(doc => { 
context.log(`Cosmos DB document: ${JSON.stringify(doc)}`); 
}); 
}); 

Amazon CloudWatch Events versus um disparador de temporizador da Azure

exports.handler = async (event) => {
console.log('Scheduled event:', event); 
}; 

import { app } from '@azure/functions'; 

app.timer('timerTrigger', { schedule: '0 */5 * * * *', // Runs every 5 minutes }, async (context, myTimer) => { if (myTimer.isPastDue) { context.log('Timer is running late!'); } context.log(Timer function executed at: ${new Date().toISOString()}); });

Amazon Simple Notification Service (SNS) vs. um gatilho do Azure Event Grid

const AWS = require('aws-sdk'); 
const sns = new AWS.SNS();   

exports.handler = async (event) => { 
const params = { 
Message: 'Hello, Event Grid!', 
TopicArn: 'arn:aws:sns:us-east-1:123456789012:MyTopic', 
}; 
await sns.publish(params).promise(); 
}; 

import { app } from '@azure/functions'; 

app.eventGrid('eventGridTrigger', {}, 
async (context, eventGridEvent) => { 

context.log(`Event Grid event: 
${JSON.stringify(eventGridEvent)}`); 

}); 

Amazon Kinesis vs. Hubs de Eventos do Azure com disparador

const AWS = require('aws-sdk'); 
const kinesis = new AWS.Kinesis();   

exports.handler = async (event) => { 
const records = 
event.Records.map(record => 
Buffer.from(record.kinesis.data, 
'base64').toString()); 
console.log('Kinesis records:', records); 
}; 

import { app } from '@azure/functions'; 
app.eventHub('eventHubTrigger', {  
connection: 'EventHubConnection',  
eventHubName: 'my-event-hub',  
}, async (context, eventHubMessages) => 
{  
eventHubMessages.forEach(message => 
{  
context.log(`Event Hub message: 
${message}`);  
});  
});

Consulte os seguintes repositórios do GitHub para comparar o código AWS Lambda e o código do Funções do Azure:

• Código do AWS Lambda
• código do Funções do Azure
• repositório de amostras do Azure, que inclui amostras iniciais, IaC e completas para Funções do Azure.

Ajustar definições de configuração

Certifique-se de que as definições de time-out e memória da sua função são compatíveis com Funções do Azure. Para mais informações sobre definições configuráveis, consulte host.json referência para Funções do Azure.

Siga as práticas recomendadas para permissões, acesso, rede e configurações de implantação.

Configurar permissões

Siga as práticas recomendadas ao configurar permissões em seus aplicativos de função. Para obter mais informações, consulte Configurar seu aplicativo de função e conta de armazenamento com identidade gerenciada.

main.bicep

// User-assigned managed identity that the function app uses to reach Storage and Service Bus
module processorUserAssignedIdentity './core/identity/userAssignedIdentity.bicep' = {
  name: 'processorUserAssignedIdentity'
  scope: rg
  params: {
    location: location
    tags: tags
    identityName: !empty(processorUserAssignedIdentityName) ? processorUserAssignedIdentityName : '${abbrs.managedIdentityUserAssignedIdentities}processor-${resourceToken}'
  }
}

Para mais informações, consulte rbac.bicep.

Configurar o acesso à rede

Funções do Azure suporta integração de rede virtual, que dá à sua aplicação de funções acesso a recursos na sua rede virtual. Após a integração, seu aplicativo roteia o tráfego de saída através da rede virtual. Em seguida, seu aplicativo pode acessar pontos de extremidade ou recursos privados usando regras que permitem apenas o tráfego de sub-redes específicas. Se o destino for um endereço IP fora da rede virtual, o endereço IP de origem será um dos endereços listados nas propriedades do seu aplicativo, a menos que você configure um gateway NAT.

Ao habilitar a integração de rede virtual para seus aplicativos funcionais, siga as práticas recomendadas no TSG para integração de rede virtual para aplicativos Web e aplicativos de função.

main.bicep

// Virtual network and private endpoint
module serviceVirtualNetwork 'app/vnet.bicep' = {
  name: 'serviceVirtualNetwork'
  scope: rg
  params: {
    location: location
    tags: tags
    vNetName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
  }
}  

module servicePrivateEndpoint 'app/storage-PrivateEndpoint.bicep' = {
  name: 'servicePrivateEndpoint'
  scope: rg
  params: {
    location: location
    tags: tags
    virtualNetworkName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
    subnetName: serviceVirtualNetwork.outputs.peSubnetName
    resourceName: storage.outputs.name
  }
}

Para mais informações, consulte VNet.bicep e storage-PrivateEndpoint.bicep.

Definir configurações de implantação

As implantações seguem um único caminho. Depois de compilar o código do seu projeto e o compactar num pacote de aplicação, implemente-o num contentor Armazenamento de Blobs. Quando ele é iniciado, seu aplicativo recebe o pacote e executa seu código de função a partir dele. Por padrão, a mesma conta de armazenamento que armazena metadados internos do host, como AzureWebJobsStorage, também serve como contêiner de implantação. No entanto, você pode usar uma conta de armazenamento alternativa ou escolher seu método de autenticação preferido definindo as configurações de implantação do seu aplicativo. Para obter mais informações, consulte Detalhes da tecnologia de implantação e Definir configurações de implantação.

Gerar arquivos IaC

• Use ferramentas como Bicep, templates do Azure Resource Manager ou Terraform para criar ficheiros IaC que implementem recursos do Azure.

• Defina recursos como Funções do Azure, contas de armazenamento e componentes de rede nos seus ficheiros IaC.

• Use este repositório de exemplos IaC para amostras que utilizam as recomendações e melhores práticas das Funções do Azure.

Utilizar ferramentas para refatorar código

Use ferramentas como o GitHub Copilot no VS Code para ajudar com refatoração de código, refatoração manual para alterações específicas ou outros auxílios de migração.

Os artigos a seguir fornecem exemplos específicos e etapas detalhadas para facilitar o processo de migração:

• Azure para os profissionais AWS
• Desenvolva Funções do Azure localmente usando Core Tools

Desenvolver um processo passo a passo para a migração do primeiro dia (Dia 0)

Desenvolva estratégias de failover e failback para a sua migração e teste-as exaustivamente num ambiente de pré-produção. Recomendamos que realize testes de ponta a ponta antes de finalmente fazer a transição do AWS Lambda para o Funções do Azure.

• Validar funcionalidade

  • Code e teste Funções do Azure localmente.

  • Teste cada função cuidadosamente para garantir que ela funcione conforme o esperado. Esses testes devem incluir entrada/saída, gatilhos de eventos e verificação de ligações.

  • Use ferramentas como curl ou extensões de cliente REST no VS Code para enviar solicitações HTTP para funções acionadas por HTTP.

  • Para outros gatilhos, como temporizadores ou filas, certifique-se de que os gatilhos sejam acionados corretamente e que as funções sejam executadas conforme o esperado.

• Validar o desempenho

  • Realize testes de desempenho para comparar a nova implementação do Funções do Azure com a implementação anterior do AWS Lambda.

  • Monitore métricas como tempo de resposta, tempo de execução e consumo de recursos.

  • Use o Application Insights para monitoramento, análise de log e solução de problemas durante a fase de teste.

• Solucionar problemas usando o recurso diagnosticar e resolver problemas

  Use a funcionalidade diagnosticar e resolver problemas no portal Azure para diagnosticar a sua aplicação de funções. Essa ferramenta fornece um conjunto de recursos de diagnóstico que podem ajudá-lo a identificar e resolver rapidamente problemas comuns, como falhas de aplicativos, degradação de desempenho e problemas de configuração. Siga as etapas de solução de problemas guiadas e as recomendações que a ferramenta fornece para resolver os problemas identificados.

Avaliar o estado final da carga de trabalho migrada

Antes de desativar recursos na AWS, você precisa ter certeza de que a plataforma atende às expectativas atuais de carga de trabalho e que nada bloqueia a manutenção ou o desenvolvimento adicional da carga de trabalho.

Implante e teste funções para validar seu desempenho e correção.

Implementar no Azure

Implante cargas de trabalho usando o recurso de publicação do VS Code . Também pode implementar cargas de trabalho a partir da linha de comandos usando Funções do Azure Core Tools ou o CLI do Azure. Azure DevOps e GitHub Actions também usam o One Deploy.

• Funções do Azure Core Tools: Implemente a sua aplicação de funções usando Funções do Azure Core Tools com o comando func azure functionapp publish <FunctionAppName>.

• Pipelines de integração contínua e implementação contínua (CI/CD): Configure um pipeline CI/CD utilizando serviços como GitHub Actions, Azure DevOps ou outra ferramenta CI/CD.

Para mais informações, consulte Entrega contínua usando GitHub Actions ou Entrega contínua com Azure Pipelines.

Explore exemplos de cenários de migração

Use o repositório MigrationGetStarted como um modelo para iniciar sua prova de conceito. Este repositório inclui um projeto Funções do Azure pronto a implementar que tem a infraestrutura e os ficheiros de código-fonte para o ajudar a começar.

Se preferir usar o Terraform, use MigrationGetStarted-Terraform.

Otimize e monitorize o desempenho da aplicação no Azure

Depois de migrar a sua carga de trabalho, recomendamos que explore mais funcionalidades no Azure. Esses recursos podem ajudá-lo a atender aos requisitos futuros de carga de trabalho e ajudar a fechar lacunas.

Usar o Application Insights para monitoramento e solução de problemas

Habilite o Application Insights para seu aplicativo de função para coletar dados de telemetria detalhados para monitoramento e solução de problemas. Pode ativar o Application Insights através do portal Azure ou no ficheiro de configuração host.json da aplicação de funções. Depois de habilitar o Application Insights, você pode:

• Coletar dados de telemetria. O Application Insights fornece vários dados de telemetria, como logs de solicitação, métricas de desempenho, exceções e dependências.

• Analise logs e métricas. Aceda ao painel Application Insights a partir do portal Azure para visualizar e analisar logs, métricas e outros dados de telemetria. Use as ferramentas internas para criar consultas personalizadas e visualizar dados para obter informações sobre o desempenho e o comportamento do seu aplicativo funcional.

• Configure alertas. Configure alertas no Application Insights para notificá-lo de problemas críticos, degradação de desempenho ou eventos específicos. Estes alertas ajudam-no a monitorizar proativamente e a responder rapidamente a problemas.

Otimize o custo e o desempenho

• Dimensionamento e otimização de desempenho:

  • Use os recursos de dimensionamento automático para lidar com cargas de trabalho variáveis de forma eficiente.

  • Otimize o código de função para melhorar o desempenho reduzindo o tempo de execução, otimizando dependências e usando práticas de codificação eficientes.

  • Implemente estratégias de cache para reduzir o processamento repetido e a latência para dados acessados com frequência.

• Gestão de custos:

  • Use as ferramentas Microsoft Cost Management para monitorizar e analisar os seus custos com Funções do Azure.

  • Configure alertas de orçamento e custos para gerenciar e prever despesas de forma eficaz.