Lambda vs Fargate — サーバーレスコンピューティングの選択基準

インフラ AWS コスト
読了 6分

コンテナオーケストレーターまで選んでも、最後の質問が残ります。「このワークロードに、そもそも常時稼働のプロセスは必要か?」です。イベントが来たときだけコードを動かせば済む仕事なら Lambda が候補になり、その瞬間の比較対象は Fargate です。結論を先に書くと、短くて間欠的なイベント処理は Lambda、常時トラフィックを受けるサービスと長時間の作業は Fargate です。 境界は勘ではなく使用率の計算で決めます。Fargate 側の基準は ECS Fargate vs EC2 で扱いました。料金は us-east-1 基準です。

課金構造 — 呼び出し単位 vs タスク単位 #

Lambda は呼び出しごとの課金です。リクエスト 100 万件あたり $0.20 に、実行時間を GB・秒単位で計算して GB・秒あたり約 $0.0000167 を払います。コードが動いていない時間は 0 円で、月 100 万リクエストと 40 万 GB・秒の無料枠があります。vCPU は個別に選ばず、メモリに比例して割り当てられます(約 1,769MB で 1vCPU 相当)。

Fargate は 前の記事 で見たとおり、タスクが起動している時間単位の課金です(vCPU あたり 1 時間約 $0.04048、GB あたり約 $0.004445)。トラフィックがなくてもタスクが起動していれば料金が発生し、その代わり呼び出し数と料金は無関係です。

同じ単位に換算すると構造が見えます。Lambda の GB・秒単価を時間に直すと GB・時間あたり $0.06 です。1vCPU 相当(約 1.77GB)を 1 時間ずっと動かすと約 $0.106 で、同じスペックの Fargate(1vCPU・2GB、約 $0.049)の 2 倍を超えます。 Lambda の単価は「動いていない時間が無料」という条件とセットになったプレミアム単価です。

基準線 — 使用率 20〜30% が境界です #

したがって判断の変数は一つに絞られます。コンピューティングが実際に動いている時間の割合です。1 日のうち実行時間の合計が 20〜30% を超えると常時タスク(Fargate)が安くなり、それを下回ると Lambda が安くなります。夜間は空でピークが短い Webhook 処理は使用率が数 % なので Lambda の圧勝で、毎秒数十件が絶えず入ってくる API は実質的に常時実行なので Fargate の領域です。

注意すべきは、トラフィックが増えると境界を越えるということです。呼び出し量が月数百万件台に上がると Lambda の請求がタスク 1〜2 個分を超え始めるので、新規サービスを Lambda で始めるのは正しいのですが、月次請求書で Lambda の項目が Fargate タスク換算額を超える時点にアラームを設定しておくのが安全です。

Lambda のハードリミット — 料金の前にふるい落とされる条件 #

  • 実行 15 分の制限: 超えると強制終了されます。長時間のバッチ、大容量の変換は Fargate(時間制限なし)に行きます。
  • メモリ最大 10GB: それ以上必要な作業には選択肢がありません。
  • コールドスタート: アイドル後の最初の呼び出しに数百 ms〜数秒が付きます。遅延に敏感な API ならプロビジョンド同時実行で消せますが、これはアイドル時間にも課金されるオプションなので、「動いていない時間が無料」という Lambda の存在理由を削っていきます。コールドスタートをお金で消しているなら、Fargate の常時タスクと再比較するタイミングです。
  • 実行モデル: WebSocket のような長時間接続、状態をメモリに持つサーバー、GPU の作業は構造的に Lambda に合いません。

逆に Lambda ならではの強みも構造から生まれます。同時呼び出し数万件まで特別な設定なしで吸収する即時スケーリング、S3・SQS・EventBridge とのイベント連携(トリガー設定だけでパイプラインになります)、サーバーとイメージの管理ゼロです。API Gateway との組み合わせは AWS 上級 #4 で扱いました。

隠れコスト — 本体より周辺が高くつきます #

Lambda の料金計算でよくある誤りは、本体の単価だけを見ることです。実際の請求書には周辺サービスが一緒に来ます。

  • API Gateway: HTTP API 基準で 100 万件あたり約 $1.00 で、呼び出し量が大きいと Lambda 本体の料金と同じ桁になります。トラフィックの大きい API は、ALB(時間あたり固定 + LCU)の後ろに Fargate を置くほうが安くなる分岐点が来ます。
  • CloudWatch Logs の収集: GB あたり約 $0.50。呼び出しのたびにログを多めに書く関数は、ログ収集費が実行費を超えることもあります。ログレベルと保持期間を関数単位で管理します。
  • VPC 接続時の NAT: VPC 内のリソースにアクセスする Lambda が外部 API も呼ぶと、NAT ゲートウェイの処理料金が付きます。料金急増の事例 で扱った類型です。

Fargate 側の隠れコストは逆方向です。最小スペック(0.25vCPU)でもタスクが起動している限り月 $9 ほどは出ていくので、ほとんど呼ばれないサービスをタスクとして置いておくこと自体が無駄です(常時点検リスト 参照)。

選択の手順 #

  1. ハードリミットからふるいにかけます: 15 分超過、10GB 超過、長時間接続、GPU のどれかに該当すれば Fargate です。
  2. 使用率を見積もります: 1 日の実行時間の合計が 20〜30% を下回り続けるイベント性のワークロードなら Lambda、常時トラフィックなら Fargate です。
  3. 遅延の要求を確認します: コールドスタートが許容できない低遅延 API は Fargate が基本で、Lambda を維持するならプロビジョンド同時実行の費用まで入れて再計算します。
  4. 周辺コストを合算します: API Gateway、ログ収集、NAT まで入れた総額で比較します。本体の単価比較は計算の半分です。
  5. 境界の移動を監視します: トラフィックの成長で使用率が境界を越えたら Fargate へ、逆に使用率が底ばいなら Lambda へ移します。コンテナイメージをそのまま使える Lambda のコンテナ対応のおかげで、移行コストは以前より小さくなっています。

まとめ #

  • Lambda は呼び出しごと、Fargate はタスクの時間ごとの課金です。Lambda の単価は GB・時間換算 $0.06 と Fargate の 2 倍を超えるプレミアムで、その対価がアイドル時間 0 円です。
  • 境界は使用率 20〜30% です。それを下回る間欠的なワークロードは Lambda、常時トラフィックは Fargate が安くなります。
  • 15 分・10GB・コールドスタート・長時間接続は、料金の前に決まるハードリミットです。
  • 実際の比較は API Gateway、ログ収集、NAT まで入れた総額で行います。本体の単価だけ見ると、Lambda の請求は予測を外れます。
  • 使用率は変わります。Lambda で始めてトラフィックが付いたら Fargate へ移す道筋を、最初から計画に入れておきます。
X