AWS Lambdaとは？Cloud Run functions、Azure Functionsとの違いと選び方

AWS Lambdaは、イベントを受け取ったときにコードを実行し、実行基盤の準備や拡張をAWSに任せられるサービスです。

ただし、サーバーレスは『設計や運用が不要』という意味ではありません。開発チームは、処理の分け方、失敗時の再実行、権限、監視、費用を設計する必要があります。

この記事では、AWS Lambdaを中心に、Google CloudのCloud Run functionsとMicrosoft AzureのAzure Functionsを比較し、要件から候補を絞る手順まで整理します。

三つのサービスを選ぶときの結論

三つのサービスに一律の優劣はありません。すでに使っているクラウド、処理を起動するイベント、許容できる遅延、ネットワーク要件、チームの運用経験によって適切な選択が変わります。

Google Cloudでは、旧Cloud Functions第2世代に当たる機能が現在のCloud Run functionsとして整理されています。Azureでは、新しいサーバーレス関数の候補としてFlex Consumptionが案内されており、Premiumも常時稼働に近い処理や複数アプリをまとめる用途で引き続き選択肢になります。

サーバーレスを理解するための用語

設計を比較する前に、似た言葉の役割を分けておくと判断しやすくなります。

• FaaS：Function as a Serviceの略で、関数単位のコードをイベントに応じて実行するサービス形態です。
• イベント駆動：ファイルの到着、HTTPリクエスト、キューへのメッセージ投入などをきっかけに処理を始める設計です。
• コールドスタート：処理を実行できる環境がまだ用意されていないとき、環境やランタイムの初期化によって開始が遅れる現象です。
• 同時実行：ある時点で並行して処理しているリクエストやイベントの数です。
• 冪等性：同じイベントを複数回処理しても、意図しない重複更新を起こさず、結果を一貫させる性質です。
• DLQ：Dead Letter Queueの略で、再試行しても処理できなかったメッセージを隔離し、調査や再処理につなげるキューです。

サーバーレスでは、プラットフォームがサーバーを管理しても、イベントの重複や下流サービスの停止までは消えません。冪等性、再試行、DLQを一つの組として設計する必要があります。

AWS Lambdaの実行モデル

AWS Lambdaの公式ドキュメントでは、関数をトリガーに接続し、Lambdaが実行環境の作成と破棄をトラフィックに応じて管理する仕組みが説明されています。

標準のLambda関数では、一つの実行環境が同時に一件の呼び出しを処理します。同時に届く処理が増えると実行環境も増えるため、関数だけでなく、データベース接続数や外部APIの上限も考慮しなければなりません。

予約済み同時実行は関数が使用できる同時実行数を確保または制限する設定で、プロビジョンド同時実行は初期化済みの実行環境を用意する設定です。後者はコールドスタートの影響を抑えますが、待機容量にも費用がかかります。

依存ライブラリや接続の初期化は、毎回のハンドラー処理ではなく、再利用できる範囲に置くと実行時間を短縮しやすくなります。一方、以前の処理結果が残ることを前提にしてはいけません。

代表的な用途と失敗時の設計

APIとWebhook

HTTPの応答を待つ利用者がいる処理では、応答に必要な最小限の仕事だけを同期で実行し、メール送信や集計などの後続処理はキューへ渡します。

AWSではAmazon API GatewayでAPIの入口を設計する方法と、Amazon SQSを使ったキューイング設計を分けて考えると、タイムアウトと再試行の責任を整理できます。

ファイル処理

S3へのファイル到着を契機に変換し、別の保存先へ出力する構成はLambdaの代表例です。同じバケットへ出力する場合は、入力用の接頭辞と出力用の接頭辞を分けないと、出力が再び関数を呼び出す循環が起こり得ます。

AWSのS3イベント連携ガイドは、バケットを分ける方法か、入力だけに一致する接頭辞を設定する方法を案内しています。

定期処理と連続処理

短い定期処理はスケジューラーから関数を呼び出せますが、長い処理を一つの関数へ詰め込むと、失敗時のやり直し範囲が広がります。処理を再開できる単位に分け、長い手順はワークフローやバッチ基盤も候補にします。

コールドスタートへの対処

最初に計測すべきなのは平均値だけではありません。利用者が待つAPIでは、遅い側の応答を示すp95やp99、初期化時間、下流サービスへの接続時間を分けて確認します。

1. 依存関係を減らし、初期化処理を軽くする。
2. 接続やSDKクライアントを安全に再利用する。
3. 許容遅延を超える場合だけ、待機容量を設定する。
4. 突発的な負荷はキューで受け、下流サービスへの流入を制御する。

Lambdaのプロビジョンド同時実行、Cloud Runの最小インスタンス、Azure Functionsのホスティングプランと常時準備するインスタンスは、いずれも開始遅延を抑える手段です。ただし、待機容量を増やすほど固定的な費用も増えるため、計測結果から必要量を決めます。

Cloud Run functionsとの違い

Cloud Run functionsの公式説明によると、関数のソースはCloud Buildでコンテナイメージに変換され、Cloud Runサービスとして配置されます。HTTP、Eventarc、Pub/Subなどを起点にできます。

Cloud Run functionsでは、一つのインスタンスへ送る最大同時リクエスト数を設定できます。同時処理数を増やすと少ないインスタンスで多くのリクエストを扱える可能性がありますが、グローバルな可変状態を持つコードやCPUを使い切る処理では競合や待ち時間が増えることがあります。

Cloud Runの同時実行ガイドが勧めるように、低めの値から始め、CPU、メモリ、応答時間、インスタンス数を見ながら調整する方法が安全です。

Azure Functionsとの違い

Azure Functionsは、HTTP、キュー、ストレージ、タイマーなどのトリガーと、ホスティングプランを組み合わせて使います。実行時間、スケール、コールドスタート、ネットワーク、課金はプランによって異なるため、Azure Functionsという製品名だけで比較すると判断を誤ります。

• Flex Consumption：変動するイベント駆動処理を従量課金で動かし、必要なら仮想ネットワーク統合や常時準備するインスタンスも使いたい場合の候補です。
• Premium：継続的に動く関数、複数の関数アプリを同じプランで運用する構成、常に温めたワーカーを使う構成の候補です。
• DedicatedまたはContainer Apps：既存のApp Service資源やコンテナ運用との統合を優先する場合に比較します。

仮想ネットワークへ接続する場合も、利用できる方式と必要なサブネットはプランで変わります。構築前にAzure Functionsのネットワーク選択肢をプラン別に確認します。

セキュリティとネットワーク

環境変数にはバケット名や機能フラグなどの運用設定を置けますが、パスワードやAPIキーを平文で置く運用は避けます。秘密情報はSecrets Manager、Secret Manager、Key Vaultなどの保管サービスから実行時の権限で取得します。

AWSでは、関数ごとに実行ロールを割り当て、必要な操作と対象資源だけを許可します。権限の分け方はAWS IAMの権限設計ガイド、秘密情報の更新と監査はAWS Secrets Managerの運用ガイドも参考になります。

VPCやVNetへの接続は、通信先を自動的に安全にする機能ではありません。許可する宛先、名前解決、外向き通信の経路、セキュリティグループやネットワーク規則を明示します。LambdaではHyperplane ENIを介したVPC接続をLambdaが管理するため、ENIの永続性に依存しない設計が必要です。

可観測性と障害対応

可観測性とは、メトリクス、ログ、トレースを組み合わせ、外から見える情報でシステム内部の状態を調べられるようにすることです。

• メトリクス：実行数、エラー率、遅延、同時実行、スロットリング、キューの滞留を監視します。
• ログ：相関ID、処理結果、失敗理由を構造化し、秘密情報や不要な本文を記録しないようにします。
• トレース：関数からデータベースや外部APIまでの待ち時間を分けて確認します。
• 費用：ログの量と保持期間を監視対象に含めます。

AWSの監視項目を具体化するときは、Amazon CloudWatchのログとメトリクス設計も参照できます。

障害時は、直近のデプロイ、トリガー、下流サービス、ネットワークの順に時系列で確認します。一時的な同時実行数の増加だけで直そうとすると、停止中のデータベースへ負荷を集中させることがあるため、原因と下流の余力を確認してから変更します。

料金を比較する手順

関数の料金は、実行回数と処理時間だけでは決まりません。待機容量、ネットワーク転送、ログ保存、ビルドと成果物保管、接続先サービスまで含めて、一つの処理が完了する費用を比較します。

1. 通常時とピーク時のリクエスト数を分ける。
2. メモリ、CPU、平均実行時間ではなく、実測した分布を使う。
3. プロビジョンド同時実行、最小インスタンス、常時準備するインスタンスの待機費用を加える。
4. キュー、API管理、ログ、データ転送、秘密情報管理の費用を加える。
5. 再試行や重複実行が増えた場合の上振れを試算する。

短い処理だから必ず関数が安いとは限りません。呼び出しが途切れず待機容量も多い処理や、長時間にわたってCPUを使う処理では、コンテナやバッチ基盤も同じ条件で比較します。

要件から候補を絞るチェックリスト

1. 起点を決める：HTTP、ファイル、キュー、データ変更、スケジュールのどれで処理を始めるかを書き出します。
2. 失敗の扱いを決める：再試行回数、待機方法、重複処理、DLQ、手動再開の担当を決めます。
3. 性能目標を決める：許容遅延、ピーク時の件数、下流サービスの上限を数値で置きます。
4. 境界を決める：プライベートネットワーク、外向き通信、秘密情報、個人情報、監査ログの条件を整理します。
5. 運用を決める：デプロイ、ロールバック、監視、障害対応、利用終了時の削除まで担当を決めます。
6. 同じ処理で試す：候補ごとに小さな検証環境を作り、遅延、失敗時の復旧、運用手順、月額見込みを比べます。

すでに特定クラウドのデータ基盤、権限管理、監視へ投資している場合、その運用資産は大きな判断材料です。複数クラウドへ分散するなら、関数コードの移植性だけでなく、イベント、権限、監視、ネットワークの作り直しまで見積もります。

まとめ

AWS Lambdaは、AWSのイベントを起点に小さな処理を組み合わせる用途で検討しやすいサービスです。Cloud Run functionsはCloud Runのコンテナ実行と同時処理の調整を活用でき、Azure Functionsはホスティングプランを選ぶことで従量実行から常時稼働に近い構成まで対応します。

サービス名から選ぶのではなく、イベント、冪等性、下流の処理能力、許容遅延、ネットワーク、監視、総費用を先に定義します。その条件を同じ検証シナリオへ当てはめれば、採用理由と運用上の注意点を説明できる選択になります。

参考にした公式資料

• AWS Lambda公式ドキュメント
• AWS Lambda関数のベストプラクティス
• AWS Lambdaのプロビジョンド同時実行
• Cloud Run functionsの概要
• Cloud Run functionsの世代比較
• Azure Functionsのスケールとホスティング
• Azure Functionsのネットワーク選択肢