AWS Lambda コスト最適化入門｜メモリ設定・Provisioned ConcurrencyからARM64移行まで月額料金を大幅削減する実践ガイド

Lambdaの請求が思ったより高い、と気づいたのはコスト明細を初めてじっくり見たときでした。オンプレのサーバー運用では固定費が主体でしたが、クラウドに移行してサーバーレスを採用した途端、実行回数と実行時間に比例して請求が増え続ける。しかも何が高コストの原因なのかが、最初はまったく見えなかった。

この記事では、AWS Lambdaの料金の仕組みを正確に理解したうえで、メモリ設定の最適化・Provisioned Concurrencyの賢い使い方・ARM64（Graviton2）への移行という三つの軸でコスト削減の実践手順を解説します。Lambdaをすでに本番運用していて「コストを下げたい」と考えているインフラエンジニアに向けた内容です。

Lambdaの料金の仕組みを正確に把握する

まず料金体系を整理します。LambdaはオンプレのVM課金とは異なり、使った分だけ課金されます（2026年3月時点の東京リージョン・x86の料金）。

「GB-秒」とは、割り当てたメモリ（GB単位）×実行時間（秒）で計算されます。たとえばメモリ512MBで2秒動く関数は1回あたり0.5GB × 2秒 = 1 GB-秒の課金が発生します。

【重要】コストを左右する変数は「メモリ設定」と「実行時間」

ここが見落とされがちな点です。メモリを増やすとGB-秒単価の基数が上がる一方、CPUパワーも上がるため実行時間が短縮される。「メモリ = コスト増」ではなく、最適なメモリサイズを見つけることがコスト削減の第一歩です。

メモリ設定の最適化でコストを削減する

1. Lambda Power Tuningで最適メモリを見つける

手動でメモリを変えながらベンチマークを取るのは現実的ではありません。AWSが提供するAWS Lambda Power Tuningというオープンソースのステートマシン（AWS Step Functions）を使うと、指定した複数のメモリ設定でLambda関数を並列実行し、コストと実行時間の最適点を自動で算出してくれます。

デプロイはAWS Serverless Application Repository（SAR）から数分で完了します。

# AWS CLI でSARからデプロイする例
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides Name=powerValues,Value="128,256,512,1024,2048,3008"

実行後、Step FunctionsのコンソールからJSON形式でインプット（対象関数のARN・テストペイロード・繰り返し回数）を指定するとレポートが出力されます。

2. 実測で見るメモリ最適値の考え方

一般的な傾向として、以下のパターンが多く観察されています。

・CPU依存の処理（画像変換・圧縮など）: 1,024MB以上でCPUが倍になり、実行時間が半分以下になりコスト減
・I/O待ち中心の処理（DB問い合わせ・APIコール）: 256MB前後が多くの場合コスト最適。メモリを増やしても待ち時間は変わらない
・初回起動（コールドスタート）重視: メモリを増やすとコールドスタート時間も短縮される傾向がある

Lambda Power Tuningが出力する「コスト最小」ポイントを採用することで、コストを削減できるケースは珍しくありません。

Provisioned Concurrencyのコスト設計

1. Provisioned Concurrencyはいつ有効にすべきか

Provisioned Concurrencyは「常時ウォームなLambdaインスタンスを確保する機能」です。コールドスタートによるレイテンシが許容できないユーザー向けAPIなどで有効ですが、確保している分だけ課金が発生するため、使い方を誤るとコスト増の原因になります。

判断基準は以下の3点です。

・使う場面: レイテンシ要件が厳しい（P99で500ms以内など）ユーザー向けAPIエンドポイント
・使わない場面: バッチ処理・非同期ジョブ・バックエンドワーカー（コールドスタートが問題にならない）
・中間の場面: 業務時間のみトラフィックが集中するAPIは、Application Auto Scalingでスケジュール制御

2. Application Auto Scalingとの組み合わせ

24時間フルで確保し続けるのはもったいない。Application Auto Scalingを使うと、時刻ベースのスケジュールやCloudWatchメトリクスに基づいてProvisioned Concurrencyの数を自動で増減できます。

# AWS CLI: ターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --resource-id function:my-api-function:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --min-capacity 0 \
  --max-capacity 10

# 平日9:00にスケールアウト（スケジュールはUTC表記）
aws application-autoscaling put-scheduled-action \
  --service-namespace lambda \
  --resource-id function:my-api-function:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --scheduled-action-name scale-out-morning \
  --schedule "cron(0 0 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=5,MaxCapacity=5

# 平日18:00にスケールイン
aws application-autoscaling put-scheduled-action \
  --service-namespace lambda \
  --resource-id function:my-api-function:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --scheduled-action-name scale-in-evening \
  --schedule "cron(0 9 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=0,MaxCapacity=0

業務時間帯のみに絞ることで、Provisioned Concurrencyのコストを大きく削減できるケースもあります。

ARM64（Graviton2）への移行でさらに削減する

1. x86との料金比較

2021年末にLambdaがARM64（AWS Graviton2プロセッサ）をサポートしました。料金はx86比で約20%安く、さらに多くのワークロードでパフォーマンスも向上しています（2026年3月時点）。

さらに実行時間の短縮効果（アーキテクチャ効率の改善）が加わると、実効的なコスト削減率は20%を超えるケースもあります。

2. ARM64への移行手順と注意点

移行は設定変更だけで完了しますが、事前確認が必要です。

・ランタイム: Python・Node.js・Java・Ruby・.NET 6以降・Go 1.x はARM64対応済み
・コンテナイメージ利用時: arm64用のイメージを別途ビルドする必要があります（x86イメージはそのまま動きません）
・ネイティブライブラリの依存: C拡張モジュールやバイナリファイルがある場合はARM64向けに再コンパイルが必要

問題がなければ設定変更だけで完了します。

# AWS CLI: アーキテクチャをARM64に変更する
aws lambda update-function-configuration \
  --function-name my-function \
  --architectures arm64

コンソールの場合は、関数の「コード」タブ → 「ランタイム設定」 → 「編集」からアーキテクチャを選択できます。

3. 移行後の動作確認は段階的に

本番への即時適用は避け、Lambdaエイリアスとトラフィックシフト（weighted alias）を使って段階的にロールアウトすることを推奨します。

・ステップ1: 新しいバージョン（ARM64）をデプロイし、エイリアスに10%を向ける
・ステップ2: CloudWatchでエラーレートとP99レイテンシを24時間監視
・ステップ3: 問題なければ50%→100%と段階的に切り替え

その他のコスト削減テクニック

1. タイムアウト値の適正化

デフォルト15分のタイムアウト設定のまま放置しているケースを見かけます。処理が途中で止まった場合に最大15分間課金され続けるリスクがあります。実際の最大実行時間の1.5〜2倍程度に調整することで、無駄なコストを防げます。

2. 再帰的呼び出しのループ検知

LambdaがSQSやS3イベントをトリガーにして自分自身を呼び出すループが発生すると、リクエスト数が爆発的に増えます。2023年にAWSが「再帰ループ検知」機能を追加し、デフォルトで16回の再帰的呼び出しを自動検知してブロックするようになりました。SQSトリガーの場合は必ず確認してください。

3. 不要な関数のクリーンアップ

開発・テスト用に作ったLambda関数が本番アカウントに残り続けているケースは多いです。AWS Lambdaコンソールの「最終更新日」とCloudWatchの`Invocations`メトリクスが0のものを定期的に棚卸しし、不要なものは削除します。Provisioned Concurrencyが設定されていれば、存在するだけでコストが発生します。

4. X-Rayトレースのサンプリングレート調整

AWS X-Rayを全量トレース（100%）で設定すると、それ自体のコストが積み上がります。本番環境では5〜10%のサンプリングレートで十分なケースがほとんどです。

LambdaとEC2の使い分けやLinuxサーバーの基礎については、姉妹サイトLinuxMaster.JPでオンプレとクラウドの比較を中心に解説しています。

よくあるトラブルと対処法

問題1: メモリを増やしたのにコストが増えた

原因: 処理がI/O待ち中心で、メモリを増やしてもCPUが使われず実行時間が変わらなかった。
対処: Lambda Power Tuningでコスト最小ポイントを実測する。I/O待ちが主因ならメモリを下げて最低限のスペックに抑える。

問題2: ARM64移行後に一部の依存ライブラリでエラーが出た

原因: x86専用コンパイル済みバイナリが含まれていた（例: numpy・mysqlclient等のC拡張）。
対処: LambdaレイヤーをARM64用に再ビルドするか、コンテナイメージベースでarm64イメージをビルドし直す。

問題3: Provisioned Concurrencyを0に戻したのに課金が続く

原因: Application Auto Scalingのスケジュールが残っており、翌日の朝に自動で戻されていた。
対処: スケジュールアクション一覧を確認し、不要なものを削除する。

# AWS CLI: スケジュールアクションの一覧確認
aws application-autoscaling describe-scheduled-actions \
  --service-namespace lambda \
  --resource-id function:my-api-function:prod

問題4: Cost Explorerでどの関数がコストを使っているかわからない

原因: 関数へのコスト配分タグが設定されていない。
対処: Lambda関数にタグ（例: Project: payment、Env: prod）を設定し、Cost ExplorerとCost Allocation Tagsを連携させる。タグ設定から最大24時間後にコストの内訳が見え始めます。

本記事のまとめ

AWS Lambdaのコスト最適化施策を優先度ごとに整理します。

サーバーレスのコスト最適化はVMのリサイジングとは考え方が異なります。「使った分だけ課金」の構造を正確に理解し、メモリとアーキテクチャの最適化から着手することが最初の一歩です。