将 AWS Lambda 工作负载迁移到 Azure Functions

将使用 Amazon Web Services （AWS） Lambda 的无服务器工作负荷迁移到 Azure Functions需要仔细规划和实施。 本文提供帮助你的基本指南：

• 对现有工作负荷进行探索性评估过程。
• 了解如何执行关键迁移活动，例如预迁移规划和工作负荷评估。
• 评估和优化已迁移的工作负荷。

Scope

本文介绍如何将 AWS Lambda 实例迁移到Azure Functions。

本文未解决以下问题：

• 迁移到自己的容器托管解决方案，例如通过Azure 容器应用。
• 在 Azure 中托管 AWS Lambda 容器。
• 组织的基本 Azure 采用方法，例如 Azure 着陆区 或 云采用框架 迁移方法中的其他主题。

使用GitHub Copilot和Azure技能进行迁移

GitHub Copilot具有 Azure Skills 的内置支持，可指导从 AWS Lambda 迁移到 Azure Functions。

可以使用Copilot以交互方式自动执行大多数迁移步骤，同时使用本文作为体系结构决策、验证和生产就绪情况的参考。

若要在 GitHub Copilot 中使用 Azure 技能（在 VS Code 或 Copilot CLI 中），请执行以下步骤：

先决条件

• Node.js 18+ - 必需用于 MCP 服务器（下载 Node.js）
• 访问 Azure 订阅以创建和测试已迁移的函数应用。
• Azure CLI（az）安装和身份验证 （Install Azure CLI） （az login）
• Azure Developer CLI （azd）已安装并经过身份验证 （Install Azure Developer CLI） （azd auth login）

对于 GitHub Copilot CLI

1. Install Copilot CLI
2. 添加市场源（仅第一次）：

   /plugin marketplace add microsoft/azure-skills
   

3. 安装插件：

   /plugin install azure@azure-skills
   

4. 安装后，重新加载 MCP 服务器：

   /mcp reload
   

5. 验证安装：

   /mcp status
   

   应会看到列出并正在运行的 Azure MCP 服务器。

适用于Visual Studio Code

1. 从 VS Code 市场安装 Azure MCP 扩展（扩展 ID：ms-azuretools.vscode-azure-mcp-server）。
2. 该扩展会自动安装一个名为“GitHub Copilot for Azure”的配套扩展，其中包含了Azure相关技能。
3. 打开Copilot 对话助手（Ctrl+Shift+I/ Cmd+Shift+I）。
4. 请确保处于代理模式（而不是“询问”或“编辑”模式）。
5. 打开命令面板（Ctrl+Shift+P） -> 搜索“MCP”-> 验证服务器是否已列出并运行。

使用此提示启动并继续Copilot中的迁移工作流：

Help me migrate my Lambda app to Azure Functions

此提示分阶段指导迁移：首先生成详细的评估报告，然后迁移代码和配置，最后生成所需的基础结构即代码（IaC）资产，以便部署到Azure。

比较功能

本文将 AWS Lambda 功能映射到Azure Functions等效项，以帮助确保兼容性。

工作负荷视角

本文重点介绍如何将 AWS Lambda 工作负载迁移到 Azure Functions，以及无服务器工作负荷的常见依赖项。 此过程可能涉及多个服务，因为工作负荷包含许多资源和用于管理这些资源的流程。 若要制定全面的策略，必须将本文中提供的建议与包含工作负荷中的其他组件和流程的大型计划相结合。

对现有工作负载执行发现过程

第一步是执行详细的发现过程来评估现有的 AWS Lambda 工作负载。 目标是了解工作负荷所依赖的 AWS 功能和服务。 使用服务专用的 SDK、API、CloudTrail 和 AWS CLI 等 AWS 工具来编译 AWS Lambda 函数的综合列表，以便评估 AWS 上的工作负载。 你应该了解 AWS Lambda 清单的以下关键方面：

• 用例
• 配置
• 安全性和网络设置
• 工具、监视、日志记录和可观测性机制
• 依赖关系
• 可靠性目标和当前可靠性状态
• 拥有成本
• 性能目标和当前性能

执行预迁移计划

在开始迁移工作负荷之前，必须将 AWS Lambda 功能映射到Azure Functions，以确保兼容性并制定迁移计划。 然后，可以为概念证明选择关键工作负载。

还需要将 Lambda 依赖的 AWS 服务 映射到 Azure 中对应的依赖项。

将 AWS Lambda 功能映射到Azure Functions

下表将 AWS Lambda 概念、资源和属性与其在 Azure Functions 上的相应等效项（特别是 Flex Consumption 托管计划）进行比较。

• 支持的语言
• 编程模型
• 事件触发器和绑定
• 权限
• 函数 URL
• 联网
• 可观测性和监视性
• 缩放和并发
• 冷启动保护
• 定价
• 源代码存储
• 本地开发
• 部署
• 超时和内存限制
• 机密管理
• 状态管理
• 有状态业务流程
• 其他差异和注意事项

支持的语言

编程模型

事件触发器和绑定

权限

函数 URL

网络

可观测性和监视性

缩放和并发

冷启动保护

定价

源代码存储

本地开发

部署

超时和内存限制

机密管理

状态管理

处于监控状态的业务流程

其他差异和注意事项

创建迁移计划

1. 为概念证明选择关键工作负载。

   首先，从总清单中选择一到两个中等大小的非关键工作负荷。 这些工作负载是概念证明迁移的基础。 可以测试该过程并确定潜在的挑战，而不会带来对操作造成重大中断的风险。

2. 以迭代方式测试并收集反馈。

   在扩展到更大的工作负荷之前，使用概念证明来收集反馈、识别差距并微调流程。 这种迭代方法可确保在迁移到全面迁移时解决潜在挑战并优化流程。

生成迁移资产

此步骤是过渡性开发阶段。 在此阶段，你将生成源代码、基础结构即代码（IaC）模板和部署管道来表示Azure中的工作负荷。 必须先根据兼容性和最佳做法调整函数代码，然后才能执行迁移。

• 将函数代码、配置文件和基础结构调整为代码文件
• 调整配置设置
• 生成 IaC 文件
• 使用用于重构的工具

将函数代码、配置文件和基础结构调整为代码文件

更新Azure Functions运行时要求的代码：

• 修改代码以遵守Azure Functions编程模型。 例如，调整函数签名以匹配Azure Functions所需的格式。 有关函数定义和执行上下文的详细信息，请参阅Azure Functions开发人员指南。

• 使用 Azure Functions 扩展捆绑包来处理类似于 AWS 服务的各种绑定和触发器。 对于.NET应用程序，应使用相应的 NuGet 包而不是扩展捆绑包。

• 使用扩展捆绑包与其他Azure服务（例如Azure 存储、Azure 服务总线和Azure Cosmos DB）集成，而无需通过 SDK 手动配置每个绑定。 有关详细信息，请参阅 通过使用绑定将函数连接到 Azure 服务 和 Azure Functions 绑定表达式模式。

这些代码片段是常见 SDK 代码的示例。 AWS Lambda 代码映射到Azure Functions中的相应触发器、绑定或 SDK 代码片段。

从 Amazon S3 读取与 Azure Blob 存储

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()}`);
});

Amazon Simple Queue Service（SQS）与 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}`);
}); 

写入 DynamoDB 与 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 事件与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 简单通知服务（SNS）与Azure 事件网格触发器

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 与 Azure 事件中心 触发器的比较

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}`);  
});  
});

请参阅以下GitHub存储库来比较 AWS Lambda 代码和Azure Functions代码：

• AWS Lambda 代码
• Azure Functions代码
• Azure示例存储库，其中包括初学者、IaC 和用于Azure Functions的端到端示例

调整配置设置

确保函数的超时和内存设置与 Azure Functions 兼容。 有关可配置设置的详细信息，请参阅 Azure Functions 的 host.json 参考。

遵循有关权限、访问、网络和部署配置的建议最佳做法。

配置权限

在为函数应用设置权限时，请遵循最佳做法。 有关详细信息，请参阅 使用托管身份验证配置存储帐户和函数应用。

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}'
  }
}

有关详细信息，请参阅 rbac.bicep。

配置网络访问

Azure Functions支持 虚拟网络集成，使函数应用能够访问虚拟网络中的资源。 集成后，应用通过虚拟网络路由出站流量。 然后，应用可以使用仅允许来自特定子网的流量的规则访问专用终结点或资源。 如果目标是虚拟网络外部的 IP 地址，则源 IP 地址是应用属性中列出的地址之一，除非配置 NAT 网关。

为函数应用启用 虚拟网络集成 时，请遵循 TSG 中的最佳做法，实现 Web 应用和函数应用的虚拟网络集成。

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
  }
}

有关详细信息，请参阅 VNet.bicep 和 storage-PrivateEndpoint.bicep。

配置部署设置

部署遵循单个路径。 生成项目代码并将其压缩到应用程序包后，将其部署到Blob 存储容器。 启动后，应用会获取包，并从中运行函数代码。 默认情况下，存储内部主机元数据的同一存储帐户（例如 AzureWebJobsStorage）也用作部署容器。 但是，可以使用备用存储帐户，也可以通过配置应用的部署设置来选择首选的身份验证方法。 有关详细信息，请参阅 部署技术详细信息 和 配置部署设置。

生成 IaC 文件

• 使用Bicep、Azure 资源管理器模板或 Terraform 等工具创建 IaC 文件来部署Azure资源。

• 在 IaC 文件中定义资源，例如Azure Functions、存储帐户和网络组件。

• 将此 IaC 示例存储库用于使用Azure Functions建议和最佳做法的示例。

使用重构工具

使用 VS Code 中的GitHub Copilot等工具来帮助进行代码重构、手动重构特定更改或其他迁移帮助。

以下文章提供了特定的示例和详细的步骤，以方便迁移过程：

• 适用于 AWS 专业人员的 Azure
• 使用 Core Tools 在本地开发Azure Functions

为第 0 天迁移开发分步过程

为你的迁移制定故障转移和故障回复策略，并在预生产环境中对其进行全面测试。 建议在最终从 AWS Lambda 过渡到Azure Functions之前执行端到端测试。

• 验证功能

  • 在本地编写和测试Azure Functions。

  • 彻底测试每个函数，以确保其按预期工作。 这些测试应包括输入/输出、事件触发器和绑定验证。

  • 使用 VS Code 上的 curl 或 REST 客户端 扩展等工具发送 HTTP 触发的函数的 HTTP 请求。

  • 对于其他触发器（如计时器或队列），请确保触发器正确触发，并且函数按预期运行。

• 验证性能

  • 执行性能测试，将新的Azure Functions部署与以前的 AWS Lambda 部署进行比较。

  • 监视响应时间、运行时和资源消耗等指标。

  • 在测试阶段使用 Application Insights 进行 监视、日志分析和故障排除 。

• 使用诊断和解决问题功能进行故障排除

  使用 Azure 门户中的 诊断并解决问题功能对函数应用进行故障排除。 此工具提供了一组诊断功能，可帮助你快速识别和解决常见问题，例如应用程序崩溃、性能下降和配置问题。 按照该工具提供的引导性故障排除步骤和建议来解决所识别的问题。

评估已迁移工作负荷的最终状态

在 AWS 中解除资源授权之前，需要确信平台满足当前的工作负荷预期，并且不会阻止工作负荷维护或进一步开发。

部署和测试函数以验证其性能和正确性。

部署到Azure

使用 VS Code 发布功能部署工作负载。 还可以使用 Azure Functions Core Tools 或 Azure CLI 从命令行部署工作负荷。 Azure DevOps 和 GitHub Actions 也使用 One Deploy。

• Azure Functions Core Tools：使用 Azure Functions Core Tools 和 命令来 func azure functionapp publish <FunctionAppName>。

• 持续集成和持续部署（CI/CD）管道：使用GitHub Actions、Azure DevOps或其他 CI/CD 工具等服务设置 CI/CD 管道。

有关详细信息，请参阅使用 GitHub Actions 的连续传送或使用 Azure Pipelines 的连续传送。

探索示例迁移方案

使用 MigrationGetStarted 存储库 作为模板开始概念验证。 此存储库包括一个现成部署Azure Functions项目，其中包含基础结构和源代码文件，可帮助你入门。

如果希望使用 Terraform，请改用 MigrationGetStarted-Terraform 。

优化和监视应用程序对Azure的性能

迁移工作负荷后，建议浏览有关Azure的更多功能。 这些功能可以帮助你满足未来的工作负载要求，并帮助缩小差距。

使用 Application Insights 进行监视和故障排除

为函数应用启用 Application Insights 以收集详细的遥测数据，以便进行监视和故障排除。 可以通过Azure门户或在函数应用的 host.json 配置文件中启用 Application Insights。 启用 Application Insights 后，可以：

• 收集遥测数据。 Application Insights 提供各种遥测数据，例如请求日志、性能指标、异常和依赖项。

• 分析日志和指标。 从 Azure 门户访问 Application Insights 仪表板，以可视化和分析日志、指标和其他遥测数据。 使用内置工具创建自定义查询并可视化数据，以便深入了解函数应用的性能和行为。

• 设置警报。 在 Application Insights 中配置警报，以通知严重问题、性能下降或特定事件。 这些警报可帮助你主动监视并快速响应问题。

针对成本和性能进行优化

• 缩放和性能优化：

  • 使用自动缩放功能高效处理不同的工作负荷。

  • 通过减少运行时、优化依赖项和使用高效的编码做法来优化函数代码以提高性能。

  • 实现缓存策略，以减少频繁访问数据的重复处理和延迟。

• 成本管理：

  • 使用 Microsoft 成本管理 工具监视和分析Azure Functions成本。

  • 设置预算和成本警报，以有效管理和预测费用。