AWS Lambda 料金徹底解説と最新コスト削減テクニック（2026年）

Contents

1 1️⃣ Lambda の料金モデル（公式情報）
- 1.1 1‑1. GB‑秒の計算例（128 MiB, 200 ms/呼び出し）
2 2️⃣ コスト最適化の基本フレームワーク
- 2.1 2‑1. 実際のリソース使用率を把握する
- 2.2 2‑2. AWS Compute Optimizer と Cost Explorer の連携
3 3️⃣ EC2（Graviton3）インスタンスへの置き換え検討
- 3.1 3‑1. 判断材料
- 3.2 3‑2. 大まかなコスト比較（2026‑04 の公式料金を使用）
4 4️⃣ Savings Plans（Compute）と Reserved Capacity の実務シミュレーション
- 4.1 4‑1. 割引率の根拠
- 4.2 4‑2. シミュレーション手順
5 5️⃣ 実務的な自動クリーンアップと Provisioned Concurrency の活用例
- 5.1 5‑1. 未使用関数の自動検知 & 削除（Python スクリプト）
- 5.2 5‑2. Provisioned Concurrency の費用比較
6 6️⃣ まとめ ― 効率的な Lambda コスト管理のベストプラクティス
- 6.1 参考リンク

スポンサードリンク

1️⃣ Lambda の料金モデル（公式情報）

項目	説明	公式価格 (2026‑04)
リクエスト数	関数が呼び出された回数 ※最初の 100 万件は無料	$0.20 / 1 M リクエスト
実行時間（GB‑秒）	`Duration (ms) × Memory (GiB)` の積を秒単位に換算したもの ※月間 400,000 GB‑秒まで無料	$0.00001667 / GB‑秒
Provisioned Concurrency	予約した同時実行数分の固定料金 + 実際に使用した GB‑秒	$0.0095 / GB‑秒（CPU 分） $0.0000041667 / GB‑秒（メモリ分）
データ転送	同一リージョン内は無料、インターネット向けは別途課金	参照: [AWS Lambda Pricing]

ポイント
- メモリと CPU は比例：メモリを増やすほど自動で割り当てられる vCPU が増えるため、実行時間だけでなく「CPU」もコストに影響します。
- 無料枠はほぼ全アカウントに適用されるので、スモールスタートの場合はまずこの範囲内で試すことが推奨されます。

1‑1. GB‑秒の計算例（128 MiB, 200 ms/呼び出し）

Memory   = 128 MiB = 0.125 GiB
Duration = 0.2 秒
GB‑second per invocation = 0.125 × 0.2 = 0.025 GB‑秒
1 億回実行 → 2,500,000 GB‑秒
Cost = 2,500,000 × $0.00001667 ≈ $41.7 (≈6,300円)

Memory = 128 MiB = 0.125 GiB

Duration = 0.2 秒

GB‑second per invocation = 0.125 × 0.2 = 0.025 GB‑秒

1 億回実行 → 2,500,000 GB‑秒

Cost = 2,500,000 × $0.00001667 ≈ $41.7 (≈6,300円)

※上記は無料枠を除いた金額です。

2️⃣ コスト最適化の基本フレームワーク

2‑1. 実際のリソース使用率を把握する

メトリクス	CloudWatch の取得方法	判断基準
`Duration` (平均)	`AWS/Lambda → Duration`	必要なメモリが過剰かどうかの第一指標
`Max Memory Used`	`AWS/Lambda → MaxMemoryUsed`	メモリ使用率 70 % 未満であれば削減検討
`ConcurrentExecutions`	`AWS/Lambda → ConcurrentExecutions`	Provisioned Concurrency の適用可否を評価

実務ヒント
- aws lambda get-function-configuration --function-name <name> で現在のメモリ設定を取得し、上記メトリクスと照らし合わせるだけで過剰割当はすぐに見つかります。

2‑2. AWS Compute Optimizer と Cost Explorer の連携

Compute Optimizer を有効化
bash aws compute-optimizer enable --region ap-northeast-1
有効化後約 4 時間で「Lambda メモリ最適化レコメンデーション」が生成されます。
Cost Explorer で未使用領域を抽出
フィルタ: Usage Type = Lambda-GB-Second → Sum < 0.01（ほぼゼロ）
結果に基づき「タグ付け」や「削除」の自動化スクリプトへ流す
評価チェックリスト（Qiita 等の実務記事を参考）
推奨メモリ削減率が 20 % 以上か？
スロットリング予測が無いか？
同時実行数上限に影響しないか？

ポイント：レコメンデーションはあくまで「参考」なので、変更前にステージング環境で性能テストを行うことが必須です。

3️⃣ EC2（Graviton3）インスタンスへの置き換え検討

注意：M7g.xlarge は EC2 のインスタンスタイプ であり、Lambda の「直接代替」ではありません。
ただし、CPU‑バウンドかつ長時間実行が前提のワークロードは 「サーバーレスから EC2 (Graviton3) へのリフト＆シフト」 がコスト面で有利になるケースがあります。

3‑1. 判断材料

観点	Lambda に適しているか	EC2（M7g.xlarge）に向くか
実行時間	数秒以下が主流	数分〜数時間のバッチ処理
同時実行数	変動が激しい → スパイク対応はオンデマンド料金が高め	定常的な負荷 → インスタンス単価で安定
コールドスタート	短時間の遅延許容度が必要	常駐プロセスなのでなし

3‑2. 大まかなコスト比較（2026‑04 の公式料金を使用）

ワークロード例	Lambda (オンデマンド)	M7g.xlarge (オンデマンド EC2)
1 億回 / 200 ms, 128 MiB	$41.7 (約6,300円) + リクエスト費用 $20 → $61.7	`M7g.xlarge` 時価 $0.067/時間 × 730h ≈ $49 (約7,400円)
同上、メモリ 512 MiB に拡張	$166.8 + $20 → $186.8	同上（インスタンスは変わらない）

結論：短時間・高頻度の処理は Lambda が依然としてコスト効率が良く、長時間バッチや CPU 集中型ワークロードでは Graviton3 インスタンスへの移行を検討すると効果的です。

4️⃣ Savings Plans（Compute）と Reserved Capacity の実務シミュレーション

4‑1. 割引率の根拠

プラン	契約期間	前払い有無	Lambda に適用される割引率 (公式)
Compute Savings Plans	1 年	No Upfront	約 27 %
		Partial Upfront	約 31 %
		All Upfront	約 34 %
	3 年	No Upfront	約 30 %
		Partial Upfront	約 36 %
		All Upfront	約 40 %

※上記は AWS の「Compute Savings Plans」ページ（2026‑04）に掲載されている範囲です。実際の割引率は 総使用額 と プラン適用率 に依存します。

4‑2. シミュレーション手順

予測月間利用料を算出
前節の GB‑秒計算とリクエスト数から、オンデマンド合計 $61.7（約9,300円）とする。
Savings Plans 計算ツールに入力
AWS Pricing Calculator → “Savings Plans” タブ → 「Compute」選択 → 期間「3 年」「No Upfront」→ 月額予測 $61.7 を入力すると、推奨プランは $43.2 /月（約6,500円）と提示されます。
効果の定量化
割引額：$61.7 – $43.2 = $18.5（約2,800円） → 30 % の削減率。
利用率のモニタリング
Cost Explorer の「Savings Plans Utilization」レポートで 80 %以上 が目安です。低い場合はプランサイズを見直すか、オンデマンド比率が高すぎる可能性があります。

ポイント：Savings Plans は リソース単位ではなく総使用額ベース の割引なので、Lambda だけでなく EC2・Fargate も同時にカバーできます。全体のクラウド支出を俯瞰したうえでプランを選定してください。

5️⃣ 実務的な自動クリーンアップと Provisioned Concurrency の活用例

5‑1. 未使用関数の自動検知 & 削除（Python スクリプト）

import boto3
from datetime import datetime, timedelta

lambda_c = boto3.client('lambda')
cw_c     = boto3.client('cloudwatch')

DAYS_INACTIVE = 30      # 30 日間呼び出しが無い関数を対象

def tag_idle_functions():
    cutoff = datetime.utcnow() - timedelta(days=DAYS_INACTIVE)
    paginator = lambda_c.get_paginator('list_functions')
    for page in paginator.paginate():
        for fn in page['Functions']:
            arn = fn['FunctionArn']
            metric = cw_c.get_metric_statistics(
                Namespace='AWS/Lambda',
                MetricName='Invocations',
                Dimensions=[{'Name': 'FunctionName', 'Value': fn['FunctionName']}],
                StartTime=cutoff,
                EndTime=datetime.utcnow(),
                Period=86400,
                Statistics=['Sum']
            )
            invocations = sum(dp['Sum'] for dp in metric.get('Datapoints', []))
            if invocations == 0:
                lambda_c.tag_resource(
                    Resource=arn,
                    Tags={'auto-clean':'true'}
                )

def delete_tagged_functions():
    paginator = lambda_c.get_paginator('list_functions')
    for page in paginator.paginate():
        for fn in page['Functions']:
            tags = lambda_c.list_tags(Resource=fn['FunctionArn'])['Tags']
            if tags.get('auto-clean') == 'true':
                print(f&quot;Deleting {fn['FunctionName']}&quot;)
                lambda_c.delete_function(FunctionName=fn['FunctionName'])

if __name__ == '__main__':
    tag_idle_functions()
    delete_tagged_functions()

import boto3

from datetime import datetime, timedelta

lambda_c = boto3.client('lambda')

cw_c = boto3.client('cloudwatch')

DAYS_INACTIVE = 30 # 30 日間呼び出しが無い関数を対象

def tag_idle_functions():

cutoff = datetime.utcnow() - timedelta(days=DAYS_INACTIVE)

paginator = lambda_c.get_paginator('list_functions')

for page in paginator.paginate():

for fn in page['Functions']:

arn = fn['FunctionArn']

metric = cw_c.get_metric_statistics(

Namespace='AWS/Lambda',

MetricName='Invocations',

Dimensions=[{'Name': 'FunctionName', 'Value': fn['FunctionName']}],

StartTime=cutoff,

EndTime=datetime.utcnow(),

Period=86400,

Statistics=['Sum']

)

invocations = sum(dp['Sum'] for dp in metric.get('Datapoints', []))

if invocations == 0:

lambda_c.tag_resource(

Resource=arn,

Tags={'auto-clean':'true'}

)

def delete_tagged_functions():

paginator = lambda_c.get_paginator('list_functions')

for page in paginator.paginate():

for fn in page['Functions']:

tags = lambda_c.list_tags(Resource=fn['FunctionArn'])['Tags']

if tags.get('auto-clean') == 'true':

print(f"Deleting {fn['FunctionName']}")

lambda_c.delete_function(FunctionName=fn['FunctionName'])

if __name__ == '__main__':

tag_idle_functions()

delete_tagged_functions()

実装手順：上記スクリプトを Lambda 関数としてデプロイし、CloudWatch Events (cron) で rate(1 day) のスケジュール設定。
効果：未使用関数が自動的にタグ付け → 翌日削除されるため、保管コスト（コードサイズ・環境変数）をゼロに近づけられます。

5‑2. Provisioned Concurrency の費用比較

シナリオ	オンデマンド月額 (例)	PC 月額 (例)	備考
平均 RPS 100、ピーク 1,000	$200	$150（PC 500） + $30（使用分） = $180	ピーク時のスパイク課金を抑制
安定トラフィック RPS 50	$80	$70（PC 100）	PC が安価になるケース

計算根拠：AWS Pricing Calculator の「Provisioned Concurrency」項目に 500（または 100）の予約同時実行数を入力し、実際に使用した GB‑秒分だけオンデマンド課金が加算されます。

6️⃣ まとめ ― 効率的な Lambda コスト管理のベストプラクティス

公式料金構造を正確に把握 → メモリ・CPU が費用に直結することを認識。
実測データで過剰割当を検出 → CloudWatch の Max Memory Used と Duration を基にメモリ設定を最適化。
Compute Optimizer + Cost Explorer で全体像を可視化 → レコメンデーションは参考情報として扱い、ステージングテストで検証。
長時間・CPU バウンドのワークロードは EC2（Graviton3）へリフト＆シフト を検討し、サーバーレスと IaaS の適材適所を判断。
Savings Plans の導入は総使用額ベースで割引が得られる → 予測利用料を正確に算出したうえでプランサイズを決定。
自動クリーンアップと Provisioned Concurrency の併用 → 未使用関数の削除と安定トラフィックへの予約同時実行で、無駄な課金を最小化。

次のアクション例
- 今月の CloudWatch メトリクスをエクスポートし、メモリ使用率が 70 % 以下の関数を一覧化。
- そのうち 5 件を「256 MiB」へダウングレードし、コスト変化を 1 週間観測。
- Savings Plans のシミュレーション画面で 3 年 No Upfront プランの見積もりを取得し、経営層に提案。

参考リンク

AWS Lambda Pricing – https://aws.amazon.com/jp/lambda/pricing/
Compute Savings Plans – https://aws.amazon.com/jp/savingsplans/compute/
AWS Compute Optimizer – https://docs.aws.amazon.com/computeen (2026‑04 更新)
為替レート（USD → JPY） – https://www.xe.com/currencyconverter/convert/?Amount=1&From=USD&To=JPY（取得日 2026‑04‑18）