Amazon Web Services (AWS) Lambda を使用するサーバーレス ワークロードを Azure Functions に移行するには、慎重な計画と実装が必要です。 この記事では、次の場合に役立つ重要なガイダンスを提供します。
- 既存のワークロードに対して検出プロセスを実行します。
- 移行前計画やワークロード評価などの主要な移行アクティビティを実行する方法について説明します。
- 移行されたワークロードを評価して最適化します。
範囲
この記事では、AWS Lambda インスタンスから Azure Functions への移行について説明します。
この記事では、次の内容は扱いません。
- Azure Container Apps など、独自のコンテナー ホスティング ソリューションへの移行。
- Azure での AWS Lambda コンテナーのホスト。
- Azure ランディング ゾーン やクラウド導入フレームワーク の移行手法で取り上げられたその他のトピックなど、組織による基本的な Azure 導入アプローチ。
機能の比較
この記事では、互換性を確保するために、AWS Lambda の機能を Azure Functions と同等の機能にマップします。
Von Bedeutung
移行計画に最適化を含めることもできますが、Microsoft では 2 段階のプロセスをお勧めします。 "似ている" 機能を最初に移行し、次に Azure で最適化の機会を評価します。
最適化作業は継続的に行い、ワークロード チームの変更管理プロセスを通じて実行する必要があります。 移行中により多くの機能を追加する移行では、リスクが発生し、プロセスが不必要に拡張されます。
ワークロードの観点
この記事では、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
- ネットワーク
- 可観測性と監視
- スケーリングとコンカレンシー
- コールド スタート保護
- 料金
- ソース コード ストレージ
- ローカル開発
- デプロイ
- タイムアウトとメモリの制限
- シークレットの管理
- 状態管理
- ステートフル オーケストレーション
- その他の相違点と考慮事項
サポートされている言語
| プログラミング言語 | AWS Lambda でサポートされているバージョン | Azure Functions でサポートされているバージョン |
|---|---|---|
| Node.js | 20、22 | 20、22 |
| Python（プログラミング言語） | 3.9, 3.10, 3.11, 3.12, 3.13 | 3.9, 3.10, 3.11 |
| ジャワ | 8, 11, 17, 21 | 8, 11, 17, 21 |
| PowerShell | サポートされていません | 7.4 |
| .NET | .NET 8 | .NET 8、.NET 9、.NET Framework 4.8.1 |
| ルビー | 3.2, 3.3 | カスタム ハンドラー |
| Go | OS 専用ランタイム | カスタム ハンドラー |
| 錆 | OS 専用ランタイム | カスタム ハンドラー |
プログラミング モデル
| 特徴 | AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|---|
| トリガー (条件や動作を引き起こすもの) | イベント ソースを介して他の AWS サービスと統合します。 Lambda 関数をイベント ソースとリンクするための自動およびプログラムによる方法を提供します。 | データベース内の更新やキュー内の新しいメッセージなど、特定のイベントに基づいて関数をトリガーします。 たとえば、Azure Cosmos DB トリガーを使用すると、関数は Azure Cosmos DB コンテナー内の挿入と更新に自動的に応答できます。 このアクションにより、データ変更をリアルタイムで処理できます。 Functions は Azure Event Grid と統合されるため、Azure Storage や Azure Media Services などの Azure サービスからのイベントや外部イベント ソースを処理できます。 Event Grid は、Functions トリガーを補完し、高いスケーラビリティと広範なイベント ソース カバレッジを実現する、一元化された拡張可能なイベント ルーティング サービスとして機能します。 |
| バインド | バインディングがありません。 Lambda 関数内の AWS SDK を使用して、他の AWS サービスとの対話を手動で管理します。 | バインディングは入力または出力として構成され、サービスへの宣言型接続を有効にし、明示的な SDK コードの必要性を最小限に抑えます。 たとえば、統合を手動で管理することなく、Blob Storage からの読み取り、Azure Cosmos DB への書き込み、SendGrid 経由で電子メールの送信を行うバインディングを構成できます。 |
イベント トリガーとバインド
| AWS Lambda トリガーまたはサービス | Azure Functions トリガー | 説明 |
|---|---|---|
| API ゲートウェイ: HTTP 要求 | HTTP トリガー | これらのトリガーを使用すると、HTTP 要求を直接処理できます。 |
| Simple Queue Service (SQS) | Azure Queue Storage トリガー または Azure Service Bus トリガー | これらのトリガーは、キュー内のメッセージを処理できます。 |
| 簡易通知サービス (SNS) | Event Grid トリガー または Service Bus トリガー | これらのトリガーにより、通知処理が有効になります。 |
| Kinesis (データ ストリーム) | Event Hubs トリガー | これらのトリガーは、データ ストリームを使用します。 |
| DynamoDB (テーブルの変更) | Azure Cosmos DB 変更フィード トリガー | これらのトリガーは、テーブルの変更を監視します。 |
| CloudWatch イベントまたは EventBridge スケジューラ | タイマー トリガー | これらのトリガーは、スケジュールされた関数または時間ベースの関数を処理します。 |
| S3 (オブジェクト イベント) | Blob Storage トリガー | これらのトリガーは、BLOB ストレージ内のイベントに反応します。 |
| Amazon リレーショナル データベース サービス (RDS) | Azure SQL トリガー | これらのトリガーは、データベースの変更に対応します。 |
| Apache Kafka のマネージド ストリーミング (MSK) | Apache Kafka トリガー | これらのトリガーは、Kafka トピック メッセージに反応します。 |
| Amazon ElastiCache（Amazonによるインメモリキャッシュサービス） | Azure Redis トリガー | これらのトリガーは、Redis のメッセージに反応します。 |
| Amazon MQ | RabbitMQ トリガー | これらのトリガーは RabbitMQ のメッセージに反応します。 |
権限
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| Lambda 実行ロールは、他の AWS サービスと対話するためのアクセス許可を Lambda 関数に付与します。 各 Lambda 関数には、実行中にアクセス許可を決定する ID およびアクセス管理 (IAM) ロールが関連付けられています。 | マネージド ID は、コードに資格情報を格納せずに他の Azure サービスで認証できるようにする関数アプリの ID を提供します。 ロールベースのアクセス制御では、Microsoft Entra ID のマネージド ID に適切なロールを割り当てて、必要なリソースへのアクセスを許可します。 |
| リソース ベースのポリシー ステートメント: - AWSLambda_FullAccessでは、関数の作成、更新、削除など、すべての Lambda 操作にフル アクセスできます。 - AWSLambda_ReadOnlyAccessは、ラムダ関数とその構成を表示するための読み取り専用アクセスを提供します。 - Custom IAM ポリシー。 |
リソース ベースの組み込みロール: - 所有者ロールは、アクセス許可の管理を含むフル アクセス権を付与します。 - 共同作成者ロールは、関数アプリの作成と削除、設定の構成、コードのデプロイを行うことができます。 アクセスを管理することはできません。 - 監視閲覧者ロールは、監視データと設定への読み取り専用アクセス権を付与できます。 また、カスタム ロールを割り当てることもできます。 |
関数 URL
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
https://<url-id>.lambda-url.<region>.on.aws |
- <appname>.azurewebsites.net (元のグローバル既定のホスト名) - <appname>-<randomhash>.<Region>.azurewebsites.net (新しい一意の既定のホスト名) |
ネットワーキング
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| すべての Lambda 関数は、既定のシステムマネージド仮想プライベート クラウド (VPC) 内で安全に実行されます。 カスタム VPC 内のリソースにアクセスするように Lambda 関数を構成することもできます。 | 関数アプリはネットワークで保護でき、ネットワーク内の他のサービスにアクセスできます。 受信ネットワーク アクセスは、サービス エンドポイントまたはプライベート エンドポイントを介して、IP アドレスのファイアウォール リストと特定の仮想ネットワークのみに制限できます。 送信ネットワーク アクセスは、仮想ネットワーク統合機能を使用して有効になります。 関数アプリでは、すべてのトラフィックを仮想ネットワークのサブネットに制限し、その仮想ネットワーク内の他のサービスにアクセスすることもできます。 |
可観測性と監視
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| Amazon CloudWatch は、メトリックの収集と追跡、ログの集計と分析、アラームの設定、カスタム ダッシュボードの作成、リソースのパフォーマンスとメトリックの変化に対する自動応答の実装によって、監視と監視に役立ちます。 | Azure Monitor は、特に Application Insights 機能を通じて、Azure Functions の包括的な監視と監視を提供します。 Application Insights は、要求率、応答時間、失敗率などのテレメトリ データを収集します。 アプリケーション コンポーネントの関係を視覚化し、リアルタイムのパフォーマンスを監視し、詳細な診断をログに記録し、カスタム メトリックの追跡を可能にします。 これらの機能は、カスタム ダッシュボード、アラート、自動応答を有効にしながら、Azure Functions のパフォーマンス、可用性、信頼性を維持するのに役立ちます。 |
| AWS Lambda は関数呼び出しからテレメトリ データを生成し、OpenTelemetry セマンティクスを使用してこのデータをエクスポートできます。 このテレメトリ データを OpenTelemetry 準拠のエンドポイントに送信するように Lambda 関数を構成できます。 このアクションにより、トレースとログの関連付け、標準ベースの一貫性のあるテレメトリ データ、OpenTelemetry をサポートする他の監視ツールとの統合が可能になります。 | OpenTelemetry 形式でログ データとトレース データをエクスポートするように関数アプリを構成します。 OpenTelemetry を使用して、任意の準拠エンドポイントにテレメトリ データをエクスポートできます。 OpenTelemetry には、トレースとログの関連付け、一貫性のある標準ベースのテレメトリ データ、他のプロバイダーとの統合などの利点があります。 OpenTelemetry は、ホスト構成とコード プロジェクトの関数アプリ レベルで有効にして、関数コードからのデータエクスポートを最適化できます。 詳細については、「Azure Functions で OpenTelemetry を使用する」を参照してください。 |
スケーリングとコンカレンシー
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| AWS はオンデマンドスケーリングモデルを使用します。 需要に応じて関数操作を自動的にスケーリングします。 コンカレンシーまたはインスタンスによって処理される要求の数は常に 1 です。 | インスタンスは、受信イベントの数と各インスタンスに対して構成されたコンカレンシーに基づいて、動的に追加および削除されます。 コンカレンシー設定を目的の値に構成できます。 |
| コンカレンシーは常に 1 です。 | コンカレンシーは構成可能です (>1)。 |
| 0 へのスケーリングをサポートします。 | 0 へのスケーリングをサポートします。 |
コールドスタート保護
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| プロビジョニングされたコンカレンシーでは、要求された数の関数インスタンスを事前に初期化することで、待機時間が短縮され、予測可能な関数のパフォーマンスが保証されます。 プロビジョニングされたコンカレンシーは、待機時間の影響を受けやすいアプリケーションに適しており、標準のコンカレンシーとは別に価格が設定されます。 | 関数アプリを使用すると、インスタンスごとにコンカレンシーを構成し、そのスケールを推進できます。 アプリの同じインスタンスで複数のジョブを並列で実行でき、インスタンス内の後続のジョブでは初期コールド スタートは発生しません。 関数アプリには、 常に準備が整 ったインスタンスもあります。 お客様は、コールドスタートの待機時間を排除し、一貫したパフォーマンスを確保するために、事前に予約されたインスタンスの数を指定できます。 また、関数アプリは、常に準備ができているインスタンスを維持しながら、需要に基づいてより多くのインスタンスにスケールアウトします。 |
| 予約済みコンカレンシーは、関数で使用できる同時実行インスタンスの最大数を指定します。 この制限により、アカウントのコンカレンシー クォータの一部がその関数専用に確保されます。 AWS Lambda は、予約されたコンカレンシーが設定されている場合でも、要求が指定された予約コンカレンシー制限を超えない限り、受信要求を処理するように動的にスケールアウトします。 AWS Lambda での予約コンカレンシーの下限は 1 です。 AWS Lambda での予約コンカレンシーの上限は、アカウントのリージョンコンカレンシークォータによって決まります。 既定では、この制限はリージョンごとに 1,000 の同時操作です。 | Azure Functions には、予約されたコンカレンシーと同等の機能はありません。 同様の機能を実現するには、特定の関数を個別の関数アプリに分離し、各アプリの最大スケールアウト制限を設定します。 Azure Functions は、スケールアウト制限セット内で動的にスケールアウトするか、インスタンスを追加し、インスタンスをスケールインまたは削除します。 既定では、Flex 従量課金プランで実行されるアプリは、構成可能なインスタンスの上限である 100 個から始まります。 最小の最大インスタンス数の値は 40 で、サポートされる最大インスタンス数の最大値は 1,000 です。 リージョンサブスクリプションのメモリ クォータ では、関数アプリがスケールアウトできる量を制限することもできますが、サポートを呼び出すことでこのクォータを増やすことができます。 |
価格設定
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| - 呼び出し回数の合計と各インスタンスの GB/秒に対する使用量あたりの支払い (固定コンカレンシーは 1) - 1 ミリ秒の増分 - 400,000 Gbps Free レベル |
- 合計呼び出し数と各インスタンスの GB/秒 (構成可能な同時呼び出しを使用) に対する使用量あたりの支払い - 100 ミリ秒単位 - 100,000 Gbps Free レベル - 従量課金ベースのコスト |
ソース コード ストレージ
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| AWS Lambda は、独自のマネージドストレージシステムで関数コードのストレージを管理します。 より多くのストレージを提供する必要はありません。 | Functions では、アプリのコードを含むデプロイ パッケージを維持するために、顧客が指定した Blob Storage コンテナーが必要です。 デプロイに同じストレージ アカウントまたは別のストレージ アカウントを使用するように設定を構成し、コンテナーにアクセスするための認証方法を管理できます。 |
ローカル開発
| AWS ラムダ機能 | Azure Functions の機能 |
|---|---|
| - SAM CLI - LocalStack |
- Azure Functions Core Tools - Visual Studio Code - Visual Studio - GitHub Codespaces - VSCode.dev - Maven - Azure Functions をローカルでコーディングしてテストする |
デプロイメント
| 特徴 | AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|---|
| 展開パッケージ | - ZIP ファイル - コンテナー イメージ |
ZIP ファイル (コンテナー イメージのデプロイの場合は、専用または Premium SKU を使用します)。 |
| ZIP ファイル サイズ (コンソール) | 最大 50 MB | ZIP 展開の場合は最大 500 MB |
| ZIP ファイル サイズ (CLI/SDK) | ZIP 展開の場合は最大 250 MB、解凍の場合は最大 500 MB | ZIP 展開の場合は最大 500 MB |
| コンテナー イメージのサイズ | 最大 10 GB | Azure 経由の柔軟なストレージを使用したコンテナーのサポート |
| 大きな成果物の処理 | 大規模なデプロイにはコンテナー イメージを使用します。 | Blob Storage または Azure Files 共有をアタッチして、アプリから大きなファイルにアクセスします。 |
| 関数に共通の依存関係をパッケージ化する | レイヤー | .Zip での展開は、ストレージからはオンデマンドで、またはコンテナー (ACA、専用、EP SKU のみ) を使用します |
| ブルーグリーンデプロイまたは関数のバージョン管理 | バージョン番号またはエイリアス名を使用して関数の特定の状態を参照するには、関数修飾子を使用します。 修飾子を使用すると、バージョン管理と段階的なデプロイ戦略が可能になります。 | ブルーグリーンデプロイには、継続的インテグレーションと継続的デリバリーシステムを使用します。 |
タイムアウトとメモリの制限
| 特徴 | AWS Lambda の制限 | Azure Functions の制限 |
|---|---|---|
| 実行タイムアウト | 900 秒 (15 分) | 既定のタイムアウトは 30 分です。 最大タイムアウトは無制限です。 ただし、関数の実行に与えられる猶予期間は、スケールイン中は 60 分、プラットフォームの更新中は 10 分です。 詳細については、「 関数アプリのタイムアウト期間」を参照してください。 |
| 構成可能なメモリ | 128 MB から 10,240 MB (64 MB 単位) | Functions では、 2 GB と 4 GB の インスタンス サイズがサポートされます。 特定のサブスクリプション内の各リージョンのメモリ制限は、アプリのすべてのインスタンスに対して 512,000 MB です。サポートを呼び出すことで増やすことができます。 リージョン内のすべての関数アプリのすべてのインスタンスの合計メモリ使用量は、このクォータ内に収まる必要があります。 インスタンス サイズオプションは 2 GB と 4 GB ですが、各インスタンスのコンカレンシーは 1 より大きくなる可能性があります。 そのため、構成に応じて、1 つのインスタンスで複数の同時実行を処理できます。 コンカレンシーを適切に構成すると、リソースの使用状況を最適化し、パフォーマンスを管理するのに役立ちます。 メモリの割り当てとコンカレンシーの設定を分散することで、関数アプリに割り当てられたリソースを効果的に管理し、効率的なパフォーマンスとコスト管理を確保できます。 詳細については、「 リージョン サブスクリプションのメモリ クォータ」を参照してください。 |
機密管理
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| AWS Secrets Manager を使用すると、データベースの資格情報、API キー、その他の機密情報などのシークレットを格納、管理、取得できます。 ラムダ関数は、AWS SDK を使用してシークレットを取得できます。 | 資格情報をハードコーディングせずに Azure リソースへの安全なアクセスを有効にするには、マネージド ID などの秘密のないアプローチを使用することをお勧めします。 パートナーやレガシ システムなどのシークレットが必要な場合、Azure Key Vault には、シークレット、キー、証明書を格納および管理するためのセキュリティで保護されたソリューションが用意されています。 |
| AWS Systems Manager Parameter Store は、構成データとシークレットを格納するサービスです。 AWS KMS を使用してパラメーターを暗号化し、AWS SDK を使用して Lambda 関数で取得できます。 ラムダ関数は、環境変数に構成設定を格納できます。 機密データは、KMS キーを使用して暗号化して、安全なアクセスを実現できます。 |
Azure Functions では、アプリケーション設定を使用して構成データを格納します。 これらの設定は、関数内で使いやすくするために環境変数に直接マップされます。 これらの設定は暗号化され、Azure App Service 構成に安全に格納できます。 より高度なシナリオでは、Azure App Configuration には、複数の構成を管理するための堅牢な機能が用意されています。 機能のフラグ設定が可能になり、サービス間での動的な更新がサポートされます。 |
ステート管理
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| AWS Lambda は、オブジェクトストレージ用の Amazon S3、高速でスケーラブルな NoSQL 状態ストレージ用の DynamoDB、メッセージキュー処理用の SQS などのサービスを使用して、単純な状態管理を処理します。 これらのサービスにより、Lambda 関数の実行全体でデータの永続化と一貫性が確保されます。 | Azure Functions では、blob Storage、Queue Storage、Table Storage などの Azure Storage サービスでバインドとトリガーを有効にすることで、 AzureWebJobsStorage を使用して状態を管理します。 これにより、関数は状態の読み取りと書き込みを簡単に行えます。 より複雑な状態管理のために、Durable Functions は、Azure Storage を使用して高度なワークフロー オーケストレーションと状態永続化機能を提供します。 |
ステートフル オーケストレーション
| AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|
| ネイティブステートオーケストレーションなし。 ワークフローには AWS ステップ関数を使用します。 | Durable Functions は、永続的なワークフロー オーケストレーションとステートフル エンティティを提供することで、複雑な状態管理に役立ちます。 これにより、実行時間の長い操作、自動チェックポイント処理、および信頼性の高い状態の永続化が可能になります。 これらの機能により、複雑なワークフローを構築して、ステートフル アプリケーションのフォールト トレランスとスケーラビリティを確保できます。 |
その他の相違点と考慮事項
| 特徴 | AWS Lambda | Azure Functions (アジュール ファンクションズ) |
|---|---|---|
| 関数のグループ化 | 各 AWS Lambda 関数は独立したエンティティです。 | 関数アプリは、複数の関数のコンテナーとして機能します。 含まれる関数の共有実行コンテキストと構成が提供されます。 複数の関数を 1 つのエンティティとして扱うと、デプロイと管理が簡単になります。 関数では、関数ごとのスケーリング戦略も使用されます。HTTP、Blob Storage、Durable Functions トリガーを除き、各関数は個別にスケーリングされます。 これらのトリガーされた関数は、独自のグループでスケーリングされます。 |
| カスタム ドメイン | API ゲートウェイ経由で有効 | カスタム ドメインは、関数アプリまたは Azure API Management で直接構成できます。 |
| カスタム コンテナーのサポート | ラムダ コンテナー イメージを使用したカスタム コンテナーのサポート | Azure Functions では、 Container Apps 環境で実行されるカスタム コンテナーがサポートされています。 |
移行計画を作成する
概念実証のために主要なワークロードを選択します。
まず、インベントリ全体から中サイズの重要でないワークロードを 1 ~ 2 つ選択します。 これらのワークロードは、概念実証移行の基盤として機能します。 プロセスをテストし、運用に大きな中断を伴うことなく潜在的な課題を特定できます。
反復的にテストし、フィードバックを収集します。
概念実証を使用して、フィードバックを収集し、ギャップを特定し、大規模なワークロードにスケーリングする前にプロセスを微調整します。 この反復的なアプローチにより、本格的な移行に移行する時点までに、潜在的な課題に対処し、プロセスを改善することができます。
移行資産を構築する
この手順は、移行開発フェーズです。 このフェーズでは、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 Functions バインド式パターンを使用して関数を Azure サービスに接続する」を参照してください。
次のスニペットは、一般的な SDK コードの例です。 AWS Lambda コードは、Azure Functions の対応するトリガー、バインド、または SDK コード スニペットにマップされます。
Amazon S3 と Azure Blob Storage からの読み取り
AWS ラムダ コード (SDK)
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());
};
Azure Functions コード (トリガー)
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 への書き込み
AWS ラムダ コード (SDK)
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();
};
Azure Functions コード (トリガー)
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 への書き込み
AWS ラムダ コード (SDK)
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);
};
Azure Functions コード (トリガー)
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 タイマー トリガー
AWS ラムダ コード (SDK)
exports.handler = async (event) => {
console.log('Scheduled event:', event);
};
Azure Functions コード (トリガー)
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 トリガー
AWS ラムダ コード (SDK)
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();
};
Azure Functions コード (トリガー)
import { app } from '@azure/functions';
app.eventGrid('eventGridTrigger', {},
async (context, eventGridEvent) => {
context.log(`Event Grid event:
${JSON.stringify(eventGridEvent)}`);
});
Amazon Kinesis と Azure Event Hubs トリガー
AWS ラムダ コード (SDK)
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);
};
Azure Functions コード (トリガー)
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 Functions 用のスターター、IaC、エンド ツー エンドのサンプルを含む Azure サンプル リポジトリ
構成設定を調整する
関数のタイムアウトと メモリ の設定が 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、ストレージ アカウント、ネットワーク コンポーネントなどのリソースを定義します。
Azure Functions の推奨事項とベスト プラクティスを使用するサンプルについては、この IaC サンプル リポジトリ を使用してください。
リファクタリングにツールを使用する
VS Code の GitHub Copilot などのツールを使用して、コードのリファクタリング、特定の変更の手動リファクタリング、またはその他の移行支援に役立てます。
注
VS Code の GitHub Copilot で エージェント モード を使用します。
次の記事では、移行プロセスを容易にするための具体的な例と詳細な手順を示します。
Day-0 移行のステップ バイ ステップ プロセスを開発する
移行のフェールオーバーとフェールバックの戦略を開発し、運用前環境で十分にテストします。 AWS Lambda から Azure Functions に最終的に移行する前に、エンドツーエンドのテストを実行することをお勧めします。
機能の検証
各関数を十分にテストして、期待どおりに動作することを確認します。 これらのテストには、入力/出力、イベント トリガー、バインド検証が含まれている必要があります。
VS Code で curl や REST クライアント 拡張機能などのツールを使用して、HTTP によってトリガーされる関数の HTTP 要求を送信します。
タイマーやキューなどの他のトリガーの場合は、トリガーが正しく起動し、関数が期待どおりに実行されていることを確認します。
パフォーマンスの検証
パフォーマンス テストを実施して、新しい Azure Functions デプロイと以前の AWS Lambda デプロイを比較します。
応答時間、実行時間、リソース消費量などのメトリックを監視します。
Application Insights を使用して、テスト フェーズ中の 監視、ログ分析、トラブルシューティングを 行います。
問題の診断と解決機能を使用したトラブルシューティング
Azure portal の 問題の診断と解決 機能を使用して、関数アプリのトラブルシューティングを行います。 このツールには、アプリケーションのクラッシュ、パフォーマンスの低下、構成の問題など、一般的な問題をすばやく特定して解決するのに役立つ一連の診断機能が用意されています。 特定した問題に対処するためにツールが提供するガイド付きトラブルシューティングの手順と推奨事項に従います。
移行されたワークロードの終了状態を評価する
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 を有効にして、監視とトラブルシューティングのための詳細なテレメトリ データを収集します。 Application Insights は、Azure portal または関数アプリの host.json 構成ファイルで有効にすることができます。 Application Insights を有効にすると、次のことができます。
テレメトリ データを収集します。 Application Insights は、要求ログ、パフォーマンス メトリック、例外、依存関係など、さまざまなテレメトリ データを提供します。
ログとメトリックを分析します。 Azure portal から Application Insights ダッシュボードにアクセスして、ログ、メトリック、およびその他のテレメトリ データを視覚化および分析します。 組み込みのツールを使用してカスタム クエリを作成し、データを視覚化して、関数アプリのパフォーマンスと動作に関する分析情報を得ることができます。
アラートを設定します。 Application Insights でアラートを構成して、重大な問題、パフォーマンスの低下、または特定のイベントを通知します。 これらのアラートは、問題を事前に監視して迅速に対応するのに役立ちます。
コストとパフォーマンスを最適化する
スケーリングとパフォーマンスの最適化:
自動スケール機能を使用して、さまざまなワークロードを効率的に処理します。
ランタイムを短縮し、依存関係を最適化し、効率的なコーディングプラクティスを使用して、パフォーマンスを向上させるために関数コードを最適化します。
キャッシュ戦略を実装して、頻繁にアクセスされるデータの繰り返し処理と待機時間を短縮します。
コスト管理:
Microsoft Cost Management ツールを使用して、Azure Functions のコストを監視および分析します。
予算作成とコストのアラートを設定して、経費を効果的に管理および予測します。