サーバーレスの代表的なサービスとして知られる「AWS Lambda」。
「サーバーレスなら料金も安く抑えられる」という話を聞いて興味を持ったものの、実際の料金体系がよく分からない…。
「無料利用枠があるらしいけど、どのくらい使えるの？」
「高額請求を防ぐにはどうすればいい？」
このような疑問をお持ちの方も多いのではないでしょうか。
本記事では、AWS Lambdaの料金について以下のポイントを解説していきます：
- 分かりやすい料金体系の説明
- 具体的な料金計算例の紹介
- コスト最適化のベストプラクティス
- 高額請求を防ぐための設定方法
特に「料金計算例」では、小規模から大規模まで、実際のユースケースに基づいた具体的な試算を紹介します。
これから本番環境でAWS Lambdaの利用を検討している方はもちろん、すでに使用していて最適化を考えている方にも役立つ内容となっています。
それでは、具体的な内容を見ていきましょう。
AWS Lambdaとは？
AWSが提供するサーバーレスコンピューティングサービス「Lambda」は、サーバーの構築や管理なしにコードを実行できるサービスです。
料金面で特に注目すべき特徴は、実行時間に応じた従量課金制という点です。
従来のサーバー環境では、24時間365日稼働させる必要があり、使用していない時間帯でもコストが発生していました。
一方、Lambdaは実際にコードを実行した時間分のみ課金されるため、大きなコスト削減が期待できます。
従来型のサーバーとLambdaのコストの違い
| 観点 | 従来型のサーバー | Lambda |
|---|---|---|
| 課金単位 | インスタンスの稼働時間 | 関数の実行時間 |
| 最小課金単位 | 1時間または秒単位 | 1ミリ秒 |
| アイドル時のコスト | 発生する | 発生しない |
| スケーリングコスト | 事前に容量を確保 | 使用量に応じて自動調整 |
詳しいLambdaの基本概念や仕組みについては、以下の記事をご覧ください。
AWS Lambdaの料金体系を分かりやすく解説
料金の基本構造
AWS Lambdaの料金は、主に以下の3つの要素で構成されています。
- リクエスト数（呼び出し回数）
- 実行時間（Duration）
- メモリ使用量（Allocated memory）
それぞれの要素について、具体的な課金方法を見ていきましょう。
リクエスト数による課金
Lambda関数が呼び出される度に課金されます。
| 項目 | 内容 |
|---|---|
| 課金単位 | 1リクエスト |
| 基本料金 | 0.20 USD / 100万リクエスト |
| 無料枠 | 100万リクエスト / 月 |
実行時間による課金
関数の実行時間に応じて課金されます。
| 項目 | 内容 |
|---|---|
| 課金単位 | 1ミリ秒 |
| 基本料金 | 0.0000166667 USD / GB-秒 |
| 無料枠 | 400,000 GB-秒 / 月 |
メモリサイズ別の料金（1秒あたり）
| メモリサイズ | GB換算 | 1秒あたりの料金（USD） | 1秒あたりの料金（円）※ |
|---|---|---|---|
| 128 MB | 0.128 GB | 0.00000213334 | 約0.00032円 |
| 256 MB | 0.256 GB | 0.00000426668 | 約0.00064円 |
| 512 MB | 0.512 GB | 0.00000853336 | 約0.00128円 |
| 1024 MB | 1.024 GB | 0.00001706672 | 約0.00256円 |
| 2048 MB | 2.048 GB | 0.00003413344 | 約0.00512円 |
メモリ使用量の設定範囲
メモリは以下の範囲で設定可能です。
- 最小：128MB
- 最大：10,240MB
- 設定単位：1MB単位
計算例（メモリ256MB、100万回実行の場合）
| 1回あたりの実行時間 | 合計実行時間 | 料金（USD） | 料金（円）※ |
|---|---|---|---|
| 100ミリ秒 | 27.8時間 | 0.427 | 約64円 |
| 500ミリ秒 | 139時間 | 2.135 | 約320円 |
| 1秒 | 278時間 | 4.27 | 約640円 |
無料利用枠の詳細
AWSは毎月、すべてのアカウントに対して以下の無料枠を提供しています：
| 項目 | 無料枠 |
|---|---|
| リクエスト数 | 100万回 |
| 実行時間 | 400,000GB-秒 |
無料枠で実行できる量を具体的に見てみましょう
例えば、メモリを128MBに設定した場合：
- 利用可能な実行時間の計算
- 無料枠の400,000GB-秒を128MB（=0.128GB）で割ります
- 400,000GB-秒 ÷ 0.128GB = 約3,125,000秒
- わかりやすく換算すると
- 約3,125,000秒 = 約52万分 = 約8,680時間
つまり、1つの関数を約8,680時間分実行できます
具体的なユースケースで考えると：
- 1回の実行が100ミリ秒の関数なら → 3,125万回の実行が可能
- 1回の実行が1秒の関数なら → 312.5万回の実行が可能
ただし、リクエスト数の無料枠は100万回までなので、実際には100万回までしか実行できません。
追加料金が発生するケース
以下の場合に基本料金（リクエスト数と実行時間）以外の料金が発生します。
Provisioned Concurrency使用時
関数の同時実行数を事前に確保する機能です。
| 項目 | 内容 | 料金（東京リージョン） |
|---|---|---|
| プロビジョニング料金 | 確保した同時実行数分 | 1 GB-秒あたり $0.0000053835 |
| 実行時の料金 | 関数実行時 | 1 GB-秒あたり $0.0000125615 |
| リクエスト料金 | 通常の実行と同様 | 100万リクエストあたり $0.20 |
エフェメラルストレージ使用時
Lambda 関数内で使用できる一時的なストレージスペースです。
| ストレージ容量 | 料金 | 備考 |
|---|---|---|
| 512MB以下 | 無料 | 標準で提供 |
| 512MB超 | GB-秒あたり $0.000000037 | 最大10,240MBまで |
データ転送時
Lambda 関数から外部へのデータ送信時に発生する転送です。
| 転送タイプ | 課金対象 | 備考 |
|---|---|---|
| VPC外への転送 | 転送量に応じて課金 | EC2料金に準拠 |
| リージョン間転送 | 転送量に応じて課金 | EC2料金に準拠 |
| インターネットへの転送 | 転送量に応じて課金 | EC2料金に準拠 |
- 同一リージョン内の以下のサービスとの連携：
- Amazon S3
- DynamoDB
- SQS
- SNS
- その他AWS主要サービス
HTTP応答ストリーム使用時
大容量のレスポンスデータを効率的に返すための機能です。
| 項目 | 料金 | 備考 |
|---|---|---|
| 最初の6MB | 無料 | リクエストごと |
| 6MB超 | 1GBあたり $0.008 | – |
SnapStart使用時（Javaランタイムのみ）
Java関数の起動時間を高速化するための機能です。
| 項目 | 料金 | 備考 |
|---|---|---|
| スナップショットのキャッシュ | GB-秒あたり $0.0000015046 | 最低3時間分課金 |
| スナップショットの復元 | 復元されたGBあたり $0.0001397998 | – |
※ すべての料金は東京リージョンの場合
2024年の料金改定ポイント
AWS Lambdaの料金体系は定期的に見直されます。
2024年の主な変更点：
- アーム系プロセッサ（Graviton2）対応による料金最適化オプションの追加
- コンテナイメージサポートの料金体系の調整
- 新リージョンでのサービス提供開始に伴う地域別料金の更新
このような料金体系を理解した上で、次のセクションでは具体的な料金計算例を見ていきましょう。
AWS Lambdaの料金計算例
規模別の具体的な料金試算をご紹介します。
アプリケーション規模別の利用条件と料金
以下の3つのケースで具体的な料金を計算していきます。
| 規模 | 用途 | メモリ | 実行時間/回 | 月間リクエスト数 |
|---|---|---|---|---|
| 小規模 | バッチ処理・小規模API | 128MB | 100ms | 10万回 |
| 中規模 | Webサービスバックエンド | 512MB | 200ms | 100万回 |
| 大規模 | 高トラフィックWeb | 1,024MB | 300ms | 1,000万回 |
詳細な料金計算例
小規模アプリケーションの場合
リクエスト料金：$0.02
- 10万リクエスト × $0.20/100万リクエスト
実行時間料金：$0.021
- メモリ：128MB = 0.128GB
- 総実行時間：10,000秒（0.1秒 × 10万回）
- GB-秒：1,280（0.128GB × 10,000秒）
- 料金：1,280GB-秒 × $0.0000166667
月額合計：$0.041（約6.15円）
※無料利用枠内のため実質無料中規模アプリケーションの場合
リクエスト料金：$0.20
- 100万リクエスト × $0.20/100万リクエスト
実行時間料金：$1.71
- メモリ：512MB = 0.512GB
- 総実行時間：200,000秒（0.2秒 × 100万回）
- GB-秒：102,400（0.512GB × 200,000秒）
- 料金：102,400GB-秒 × $0.0000166667
月額合計：$1.91（約286.5円）大規模アプリケーションの場合
リクエスト料金：$2.00
- 1,000万リクエスト × $0.20/100万リクエスト
実行時間料金：$51.20
- メモリ：1,024MB = 1.024GB
- 総実行時間：3,000,000秒（0.3秒 × 1,000万回）
- GB-秒：3,072,000（1.024GB × 3,000,000秒）
- 料金：3,072,000GB-秒 × $0.0000166667
月額合計：$53.20（約7,980円）料金最適化のポイント
- メモリサイズの適切な選択
- 実行時間とのバランスを考慮
- コストとパフォーマンスの最適化
- 実行時間の最適化
- コードの効率化
- 不要な処理の削除
- リクエスト数の予測と管理
- 季節変動の考慮
- 急激な増加への対策
AWS Lambdaを効率的に利用するためのコスト最適化方法
メモリ設定の最適化手法
メモリサイズの選択は、実行時間とコストに直接影響を与えます。
メモリとCPUの関係
| メモリサイズ | 相対的なCPUパワー |
|---|---|
| 128MB | 0.125 vCPU相当 |
| 1,024MB | 1 vCPU相当 |
| 3,008MB | 2 vCPU相当 |
最適化のステップ
- 適切なメモリサイズの見極め
- AWS CloudWatch メトリクスでメモリ使用率を確認
- 実際の使用メモリ量＋余裕分を設定
- 定期的な使用状況の見直し
- パフォーマンステストの実施
- 異なるメモリサイズでの実行時間を比較
- コストと実行時間のバランスを検証
実行時間を短縮するためのコード最適化
Before/After例
# Before：最適化前のコード
def handler(event, context):
# 毎回接続を作成
db = create_database_connection()
# 全データを取得して処理
results = db.query("SELECT * FROM large_table")
processed = []
for item in results:
processed.append(process_item(item))
return processed
# After：最適化後のコード
db_connection = None # グローバル変数で接続を保持
def handler(event, context):
global db_connection
# コネクションの再利用
if not db_connection:
db_connection = create_database_connection()
# 必要なデータのみを取得
results = db_connection.query(
"SELECT * FROM large_table LIMIT 100"
)
# リスト内包表記で処理を効率化
return [process_item(item) for item in results]実行時間短縮のポイント
- 初期化コードの最適化
- 不要なAPI呼び出しの削減
- データベース接続の再利用
- 効率的なデータ構造の使用
コールドスタート対策とコストバランス
コールドスタートによるコストへの影響を整理した表です。
| 項目 | ウォームスタート | コールドスタート | コストへの影響 |
|---|---|---|---|
| 実行時間 | 関数実行のみ | 環境構築＋初期化＋関数実行 | 実行時間の増加で料金増 |
| レスポンス | ミリ秒単位 | 数秒の遅延 | ユーザー体験の低下 |
コスト影響の具体例
# 通常実行の場合
実行時間：100ms
コスト：基本料金のみ
# コールドスタート時
環境構築：~300ms
初期化：~200ms
実行時間：100ms
コスト：基本料金の約6倍対策とコストバランス
Provisioned Concurrencyの使用
| メリット | デメリット |
|---|---|
| • コールドスタート完全回避 • 安定したレスポンス | • 常時料金が発生 • 使用量に関係なく課金 |
コスト最適化のポイント：
- 重要なAPIのみに適用
- アクセスピーク時のみ設定
- 定期的な使用量の見直し
コードの最適化
| 施策 | コスト削減効果 |
|---|---|
| 依存ライブラリの最小化 | 初期化時間の短縮 |
| 初期化コードの効率化 | メモリ使用量の削減 |
| モジュールの遅延ロード | 必要時のみリソース使用 |
コスト最適化の判断基準
- アプリケーションの要件
- レスポンス時間の要件
- 許容できる遅延
- ユーザー体験への影響
- アクセスパターン
- 定常的なアクセス
- 間欠的なアクセス
- ピーク時の同時接続数
- コストと性能のバランス
- Provisioned Concurrencyのコスト
- コールドスタートの影響
- 最適な設定値の検討
これらの要素を総合的に判断し、アプリケーションに最適なコスト最適化戦略を選択することが重要です。
アーキテクチャパターン別のコスト比較
同期処理パターン
APIリクエスト → Lambda → 即時レスポンス- メリット：シンプルな構成
- デメリット：実行時間が長いとコスト増加
非同期処理パターン
APIリクエスト → SQS → Lambda → S3- メリット：負荷分散によるコスト最適化
- デメリット：システム複雑化
バッチ処理パターン
EventBridge → Lambda → 一括処理- メリット：処理の効率化でコスト削減
- デメリット：リアルタイム性の低下
コスト最適化のための設計原則
- 処理の分割
- 重い処理は分割して実行
- タイムアウトリスクの軽減
- 適切なトリガーの選択
- イベント駆動型の設計
- 不要な実行の防止
- エラーハンドリングの実装
- リトライ回数の適切な設定
- デッドレターキューの活用
他のAWSサービスとの連携とコスト
Lambdaと他のAWSサービスを組み合わせる際は、それぞれのサービスの料金も考慮する必要があります。
API Gatewayとの連携時のコスト
API GatewayはRESTful APIを構築する際によく使用されます。
API Gatewayの料金体系
- APIコール：100万リクエストあたり$3.50
- データ転送：1GBあたり$0.09
- キャッシュメモリ（オプション）：0.5GBあたり$0.02/時間
コスト最適化のポイント
- キャッシュの適切な設定
- スロットリングの活用
- リクエスト/レスポンスの最適化
DynamoDBとの連携時のコスト考慮点
DynamoDBはサーバーレスアプリケーションでよく使用されるデータベースです。
料金への影響要因
- 読み取り/書き込みキャパシティユニット
- ストレージ使用量
- バックアップとリストア
- グローバルテーブルの使用
コスト削減のための施策
- オンデマンドモードvs.プロビジョニングモードの適切な選択
- TTL（Time To Live）の活用
- インデックスの最適化
- 項目サイズの最小化
CloudWatchのログ保存と監視コスト
CloudWatchはLambdaの監視に不可欠ですが、コストにも注意が必要です。
主な課金対象
- ログデータの保存：1GBあたり$0.03/月
- ログの取り込み：1GBあたり$0.50
- メトリクスの保存：メトリクス1個あたり$0.30/月
コスト管理のベストプラクティス
- ログ保持期間の適切な設定
- 不要なログの削除
- メトリクスフィルターの最適化
- カスタムメトリクスの精査
EventBridgeを使用したスケジューリングのコスト
定期実行やイベント連携に使用するEventBridgeのコストを考慮します。
料金体系
- カスタムイベント：100万イベントあたり$1.00
- スケジュール実行：100万回の呼び出しあたり$1.00
- クロスアカウントイベント：100万イベントあたり$1.00
最適化のポイント
- イベントルールの適切な設定
- バッチ処理の活用
- 不要なルールの削除
S3との連携時のコスト考慮点
S3はデータの保存や受け渡しに頻繁に使用されます。
コストに影響する要素
- ストレージ使用量：標準クラスで1GBあたり$0.023/月
- データ転送：リージョン外への転送1GBあたり$0.09
- リクエスト料金：PUT/COPY/POST/LISTリクエスト1,000件あたり$0.005
コスト最適化戦略
- 適切なストレージクラスの選択
- ライフサイクルルールの活用
- バッチ処理による リクエスト数の削減
- オブジェクトの圧縮
コンテナイメージ使用時の追加コスト
Lambdaでコンテナイメージを使用する場合の考慮点です。
発生する追加コスト
- Amazon ECRのストレージ料金
- イメージのプッシュ/プル料金
- データ転送料金
コスト削減のヒント
- イメージサイズの最適化
- レイヤーの効率的な利用
- 不要なイメージの削除
- マルチステージビルドの活用
次のセクションでは、コスト監視と予算管理について詳しく解説していきます。
コスト監視
AWS Lambdaのコストを効果的に管理するには、適切な監視が不可欠です。
CloudWatchダッシュボードの設定方法
効果的なモニタリングのために、以下のメトリクスを監視することをお勧めします。
重要な監視項目
- 関数ごとの呼び出し回数
- 実行時間の推移
- エラー率
- 同時実行数
- メモリ使用率
ダッシュボード作成のポイント
- 関数グループごとの集計
- 時間帯別の使用傾向
- コスト関連メトリクスの可視化
- アラート閾値の設定
よくある質問と注意点
無料利用枠超過時の対応方法
Q：無料利用枠を超えたらどうなりますか？
AWS Lambdaの無料利用枠を超過した場合、超過分に対して自動的に課金が発生します。
対応方法：
- 使用状況の確認
- コスト超過アラートの設定
- 予算の見直し
- 最適化施策の実施
Q：突然の高額請求を防ぐにはどうすればよいですか？
以下の対策を実施することで、予期せぬ高額請求を防ぐことができます。
- 使用量制限の設定
- 同時実行数の制限
- タイムアウト値の適切な設定
- スロットリングの活用
- モニタリングの徹底
- CloudWatchアラームの設定
- 予算アラートの設定
- 定期的な使用状況の確認
高額請求を防ぐために意識しておきたいこと
実行時間の制御
- タイムアウト設定の最適化
- 無限ループの防止
- エラーハンドリングの実装
リクエスト数の管理
- スロットリングの設定
- キャッシュの活用
- 不要な呼び出しの削減
リソースの最適化
- メモリサイズの適正化
- コードの効率化
- 処理の分散化
まとめ
AWS Lambdaの料金体系について、以下のポイントを解説してきました：
- リクエスト数と実行時間による従量課金制
- メモリサイズの選択がコストに与える影響
- 無料利用枠の範囲と活用方法
- 具体的な料金計算例とコスト最適化の方法
- 他のAWSサービスとの連携時のコスト考慮点
- コスト監視と予算管理の重要性
AWS Lambdaのコスト管理は、一見複雑に感じるかもしれません。
でも、本記事で紹介した内容を参考に、少しずつ最適化を進めていけば、きっとコストを抑えながらLambdaを効果的に活用できるはずです。
「こんな使い方をしてみたい」「別のコスト最適化方法を知りたい」など、新しい疑問や課題が出てきたときは、ぜひAWSの公式ドキュメントもチェックしてみてください。
最後まで読んでいただき、ありがとうございました！
※ AWS Lambdaの料金体系は定期的に更新されます。最新の情報は必ずAWS公式ドキュメントでご確認ください。
コメント