AWS Lambda ワークロードをAzure Functionsに移行する

Amazon Web Services (AWS) Lambda を使用するサーバーレス ワークロードをAzure Functionsに移行するには、慎重な計画と実装が必要です。 この記事では、次の場合に役立つ重要なガイダンスを提供します。

• 既存のワークロードに対して検出プロセスを実行します。
• 移行前計画やワークロード評価などの主要な移行アクティビティを実行する方法について説明します。
• 移行されたワークロードを評価して最適化します。

Scope

この記事では、AWS Lambda インスタンスをAzure Functionsに移行する方法について説明します。

この記事では、次の内容は扱いません。

• Azure Container Appsなど、独自のコンテナー ホスティング ソリューションへの移行。
• Azureでの AWS Lambda コンテナーのホスト。
• Azureランディング ゾーン、、クラウド導入フレームワーク migrate 手法で取り上げられたその他のトピックなど、組織による基本的なAzure導入アプローチ。

GitHub CopilotとAzureスキルを使用して移行する

Azure Skills を使用したGitHub Copilotには、AWS Lambda から Azure Functions への移行をガイドするサポートが組み込まれています。

Copilotを使用すると、ほとんどの移行手順を対話形式で自動化できます。この記事は、アーキテクチャの決定、検証、運用準備のリファレンスとして使用します。

GitHub Copilot (VS Code または Copilot CLI) でAzureスキルを使用するには、次の手順に従います。

前提条件

• Node.js 18 以上 - MCP サーバーに必要 (ダウンロード Node.js)
• 移行された関数アプリを作成してテストするためのAzure サブスクリプションへのアクセス。
• Azure CLI (az)インストールおよび認証 (Install Azure CLI) (az login)
• Azure Developer CLI (azd) インストールおよび認証 ( Azure開発者 CLI のインストール) (azd auth login)

GitHub Copilot CLI の場合

1. Copilot CLI インストール
2. Marketplace ソースを追加します (初回のみ):

   /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 Marketplace から Azure MCP 拡張機能をインストールします (拡張機能 ID: ms-azuretools.vscode-azure-mcp-server)。
2. 拡張機能は、Azureスキルを含む、AzureのGitHub Copilotコンパニオン拡張機能を自動インストールします。
3. Copilot Chat (Ctrl + Shift + I / Cmd + Shift + I) を開きます。
4. エージェント モードであることを確認します ([確認] モードまたは [編集] モードではありません)。
5. コマンド パレットを開きます (Ctrl + Shift + P) -> 検索 "MCP" -> サーバーが一覧表示され、実行されていることを確認します。

このプロンプトを使用して、Copilotで移行ワークフローを開始して続行します。

Help me migrate my Lambda app to Azure Functions

このプロンプトでは、移行を段階的にガイドします。最初に詳細な評価レポートを生成してから、コードと構成を移行し、最後に、Azureにデプロイするために必要なコードとしてのインフラストラクチャ (IaC) 資産を構築します。

機能の比較

この記事では、AWS Lambda の機能を Azure Functions の同等の機能にマッピングし、互換性を確保する方法を示します。

ワークロードの観点

この記事では、AWS Lambda ワークロードをAzure Functionsに移行する方法と、サーバーレス ワークロードの一般的な依存関係について説明します。 ワークロードは多くのリソースとそれらのリソースを管理するプロセスで構成されるため、このプロセスには複数のサービスが含まれる場合があります。 包括的な戦略を立てるには、この記事に記載されている推奨事項と、ワークロード内の他のコンポーネントとプロセスを含む大規模な計画を組み合わせる必要があります。

既存のワークロードで検出プロセスを実行する

最初の手順では、既存の AWS Lambda ワークロードを評価するための詳細な検出プロセスを実行します。 目標は、ワークロードが依存している AWS の機能とサービスを理解することです。 サービス固有の SDK、API、CloudTrail、AWS CLI などの AWS ツールを使用して AWS Lambda 関数の包括的なインベントリをコンパイルし、AWS のワークロードを評価します。 AWS Lambda インベントリの次の重要な側面を理解する必要があります。

• 活用事例
• Configurations
• セキュリティとネットワークのセットアップ
• ツール、監視、ログ記録、および監視メカニズム
• 依存関係
• 信頼性の目標と現在の信頼性の状態
• 保有コスト
• パフォーマンス目標と現在のパフォーマンス

移行前の計画を実行する

ワークロードの移行を開始する前に、AWS Lambda の機能をAzure Functionsにマップして互換性を確保し、移行計画を策定する必要があります。 その後、概念実証のために主要なワークロードを選択できます。

また、ラムダがAzureの同等の依存関係に依存する AWS サービスをマップする必要があります。

AWS Lambda の機能をAzure Functionsにマップする

次の表では、AWS Lambda の概念、リソース、およびプロパティと、Azure Functions (具体的には Flex Consumption ホスティング プラン) に対応する同等の概念を比較します。

• サポートされている言語
• プログラミング モデル
• イベント トリガーとバインド
• アクセス許可
• 関数 URL
• ネットワーク
• 可観測性と監視
• スケーリングとコンカレンシー
• コールド スタート保護
• 料金
• ソース コード ストレージ
• ローカル開発
• デプロイ
• タイムアウトとメモリの制限
• シークレットの管理
• 状態管理
• ステートフル オーケストレーション
• その他の相違点と考慮事項

サポートされている言語

プログラミング モデル

イベント トリガーとバインド

権限

関数 URL

ネットワーク

可観測性と監視

スケーリングとコンカレンシー

コールドスタート保護

価格設定

ソース コード ストレージ

ローカル開発

デプロイメント

タイムアウトとメモリの制限

機密管理

ステート管理

ステートフル オーケストレーション

その他の相違点と考慮事項

移行計画を作成する

1. 概念実証のために主要なワークロードを選択します。

   まず、インベントリ全体から中サイズの重要でないワークロードを 1 ~ 2 つ選択します。 これらのワークロードは、概念実証移行の基盤として機能します。 プロセスをテストし、運用に大きな中断を伴うことなく潜在的な課題を特定できます。

2. 反復的にテストし、フィードバックを収集します。

   概念実証を使用して、フィードバックを収集し、ギャップを特定し、大規模なワークロードにスケーリングする前にプロセスを微調整します。 この反復的なアプローチにより、本格的な移行に移行する時点までに、潜在的な課題に対処し、プロセスを改善することができます。

移行資産を構築する

この手順は、移行開発フェーズです。 このフェーズでは、ソース コード、コードとしてのインフラストラクチャ (IaC) テンプレート、およびデプロイ パイプラインをビルドして、Azureのワークロードを表します。 移行を実行する前に、互換性とベスト プラクティスのために関数コードを調整する必要があります。

• 関数コード、構成ファイル、およびインフラストラクチャをコード ファイルとして適応させる
• 構成設定を調整する
• IaC ファイルを生成する
• リファクタリングにツールを使用する

関数コード、構成ファイル、およびインフラストラクチャをコード ファイルとして適応させる

Azure Functionsランタイム要件のコードを更新するには:

• Azure Functions プログラミング モデルに準拠するようにコードを変更します。 たとえば、関数シグネチャを、Azure Functions必要な形式に合わせて調整します。 関数定義と実行コンテキストの詳細については、Azure Functions開発者ガイドを参照してください。

• Azure Functions拡張機能バンドルを使用して、AWS サービスに似たさまざまなバインディングとトリガーを処理します。 .NET アプリケーションの場合は、拡張機能バンドルの代わりに適切な NuGet パッケージを使用する必要があります。

• 拡張機能バンドルを使用して、SDK を使用して各バインドを手動で構成することなく、Azure Storage、Azure Service Bus、Azure Cosmos DBなどの他のAzure サービスと統合します。 詳細については、「バインディングを使用して関数をAzureサービスに接続する」および「Azure Functionsのバインディング式パターン」を参照してください。

これらのスニペットは、一般的な SDK コードの例です。 AWS Lambda コードは、Azure Functionsの対応するトリガー、バインディング、または SDK コード スニペットにマップされます。

Amazon S3 からの読み取りと Azure Blob Storage からの読み取りの比較

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 Queue Storage への書き込み

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 Simple Notification Service (SNS) と 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 対 Azure Event Hubs トリガー

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

AWS Lambda コードとAzure Functions コードを比較するには、次のGitHubリポジトリを参照してください。

• AWS ラムダ コード
• Azure Functions コード
• Azure サンプル リポジトリには、Azure Functions 用のスターター、IaC、エンドツーエンドのサンプルが含まれています。

構成設定を調整する

関数のタイムアウトと memory 設定がAzure Functionsと互換性があることを確認します。 構成可能な設定の詳細については、Azure Functionshost.jsonリファレンス>を参照してください。

アクセス許可、アクセス、ネットワーク、デプロイの構成に関して推奨されるベスト プラクティスに従います。

アクセス許可を構成する

関数アプリに対するアクセス許可を設定するときは、ベスト プラクティスに従います。 詳細については、「 マネージド ID を使用して関数アプリとストレージ アカウントを構成する」を参照してください。

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 アドレスである場合、NAT ゲートウェイを構成しない限り、ソース IP アドレスはアプリのプロパティに一覧表示されているアドレスの 1 つです。

関数アプリの 仮想ネットワーク統合 を有効にする場合は、 Web アプリと関数アプリの仮想ネットワーク統合に関する TSG のベスト プラクティスに従ってください。

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 を参照してください。

展開設定を構成する

デプロイは 1 つのパスに従います。 プロジェクト コードをビルドしてアプリケーション パッケージに zip 圧縮した後、Blob Storage コンテナーにデプロイします。 起動時に、アプリはパッケージを取得し、そこから関数コードを実行します。 既定では、 AzureWebJobsStorageなどの内部ホスト メタデータを格納するのと同じストレージ アカウントもデプロイ コンテナーとして機能します。 ただし、別のストレージ アカウントを使用することも、アプリのデプロイ設定を構成して、優先する認証方法を選択することもできます。 詳細については、「 展開テクノロジの詳細 」および「 展開設定の構成」を参照してください。

IaC ファイルを生成する

• Bicep、Azure Resource Manager テンプレート、Terraform などのツールを使用して、Azure リソースをデプロイする IaC ファイルを作成します。

• IaC ファイル内のAzure Functions、ストレージ アカウント、ネットワーク コンポーネントなどのリソースを定義します。

• このIaC サンプル リポジトリは、Azure Functionsの推奨事項とベスト プラクティスを使用するサンプルに使用します。

リファクタリングにツールを使用する

VS Code のGitHub Copilotなどのツールを使用して、コードのリファクタリング、特定の変更に対する手動リファクタリング、またはその他の移行支援に役立てます。

次の記事では、移行プロセスを容易にするための具体的な例と詳細な手順を示します。

• AWS プロフェッショナル向けの Azure
• Core Tools

Day-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 を使用して、 コマンドで 関数アプリをデプロイします。

• 継続的インテグレーションと継続的デプロイ (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 を有効にして、監視とトラブルシューティングのための詳細なテレメトリ データを収集します。 Application Insights は、Azure ポータルまたは関数アプリの host.json 構成ファイルで有効にすることができます。 Application Insights を有効にすると、次のことができます。

• テレメトリ データを収集します。 Application Insights は、要求ログ、パフォーマンス メトリック、例外、依存関係など、さまざまなテレメトリ データを提供します。

• ログとメトリックを分析します。 Azure ポータルから Application Insights ダッシュボードにアクセスして、ログ、メトリック、その他のテレメトリ データを視覚化および分析します。 組み込みのツールを使用してカスタム クエリを作成し、データを視覚化して、関数アプリのパフォーマンスと動作に関する分析情報を得ることができます。

• アラートを設定します。 Application Insights でアラートを構成して、重大な問題、パフォーマンスの低下、または特定のイベントを通知します。 これらのアラートは、問題を事前に監視して迅速に対応するのに役立ちます。

コストとパフォーマンスを最適化する

• スケーリングとパフォーマンスの最適化:

  • 自動スケール機能を使用して、さまざまなワークロードを効率的に処理します。

  • ランタイムを短縮し、依存関係を最適化し、効率的なコーディングプラクティスを使用して、パフォーマンスを向上させるために関数コードを最適化します。

  • キャッシュ戦略を実装して、頻繁にアクセスされるデータの繰り返し処理と待機時間を短縮します。

• コスト管理:

  • Azure Functionsコストを監視および分析するには、Microsoft Cost Management ツールを使用します。

  • 予算作成とコストのアラートを設定して、経費を効果的に管理および予測します。