AWS Lambdaの料金体系を理解する重要性

サーバーレスアーキテクチャの代表格であるAWS Lambdaは、その手軽さから多くのプロジェクトで採用されています。しかし、「サーバーレス＝コスト削減」という単純な図式で導入を決めてしまうと、思わぬ落とし穴にはまることがあります。実際、私が関わったあるプロジェクトでは、当初の想定より月額コストが3倍以上に膨らんでしまい、急遽アーキテクチャの見直しを迫られた経験があります。

Lambdaの料金体系は一見シンプルに見えますが、実は様々な要素が絡み合っています。「メモリ割当量」「実行時間」「リクエスト回数」という基本要素に加えて、「コールドスタート」「プロビジョンドコンカレンシー」「エフェメラルストレージ」など、コストに影響を与える要因は多岐にわたります。これらの要素を正しく理解し、適切に設計・実装することで、コストを大幅に削減できる可能性があります。

日立製作所の例を見てみましょう。従来の常時稼働型サーバやGPUインスタンスを利用した分析基盤では、利用していない時間にも高額なコストが発生するという課題を抱えていました。そこで同社は、AWS LambdaやS3、DynamoDBといったサーバーレスサービスを活用し、必要な時にのみリソースを起動する仕組みに移行しました。さらにマルチテナント構成を導入することで、複数部門が柔軟に利用できる共通基盤を実現しています。その結果、待機時間の無駄なコストを大幅に削減しつつ、スケーラビリティと柔軟性を確保し、開発・運用効率も向上させることに成功しました。

本記事では、まず基本的な料金構造から解説し、東京リージョンと大阪リージョンでの具体的な料金、そして実践的なコスト最適化テクニックまで、段階的に深掘りしていきます。

Lambdaの基本料金構造

従量課金モデルの仕組み

AWS Lambdaの料金は、主に2つの要素から構成されています。

まず1つ目は「GB-秒」による課金です。これは、割り当てたメモリ量と実行時間の積で計算されます。例えば、128MBのメモリを割り当てた関数が100ミリ秒実行された場合、0.0125GB-秒として計算されます。東京リージョンでは、最初の40万GB-秒までは無料枠が適用され、それを超えた分については0.0000166667 USD/GB-秒という単価で課金されます。

2つ目は「リクエスト回数」による課金です。関数が呼び出される度にカウントされ、月間100万リクエストまでは無料、それ以降は100万リクエストあたり0.20 USDという料金体系になっています。一見すると非常に安価に思えますが、高頻度で呼び出される関数では、このリクエスト料金が無視できない金額になることもあります。

メモリとCPU性能の関係

Lambdaでは、「CPU性能はメモリ割当量に比例する」という重要な特性があります。つまり、メモリを増やせばCPU性能も向上し、処理速度が上がる可能性があります。これは一見するとコスト増につながるように思えますが、実行時間が短縮されることで、結果的にコスト削減につながるケースも多いです。

例えば、128MBで1秒かかっていた処理が、256MBに増やすことで0.5秒で完了するようになったとします。この場合、前者は128MB×1秒=128MB-秒、後者は256MB×0.5秒=128MB-秒となり、コストは同等になります。さらに処理時間が0.4秒まで短縮されれば、むしろコスト削減になるわけです。

AWS公式の「Lambda Power Tuning」ツールを使用することで、各関数に最適なメモリ設定を見つけることができます。私の経験では、CPU処理が多い関数（画像処理やデータ圧縮など）では、メモリを増やすことで大幅なコスト削減を実現できたケースが多くありました。

アーキテクチャの選択とコストへの影響

x86とARM（Graviton2）の比較

Lambdaでは、x86とARM（AWS Graviton2）の2つのアーキテクチャを選択できます。ARMアーキテクチャを選択すると、「最大34%の価格性能向上」が期待でき、単価自体も約20%低く設定されています。具体的には、最初の6億GB-秒までの単価は、ARMで0.0000133334 USD/GB-秒、x86では0.0000166667 USD/GB-秒となっています。

ただし、全ての関数がARMに移行できるわけではありません。使用しているライブラリや依存関係によっては、x86でしか動作しないケースもあります。私が携わったプロジェクトでは、Node.jsとPythonの関数はスムーズにARM移行できましたが、特定のネイティブモジュールを使用していたJava関数では互換性の問題が発生し、x86のまま運用することになりました。

東京リージョンと大阪リージョンの料金実態

リージョン間の価格差の真実

多くのAWSサービスではリージョンによって料金が異なりますが、「Lambdaに関しては東京リージョンと大阪リージョンで料金差はありません」。これは米国東部リージョンと同一の料金設定となっており、グローバルで統一された価格体系が適用されています。

AWS公式の料金ページを確認すると、どちらのリージョンでもメモリ128MBあたり1ミリ秒あたりの料金は約0.0000000021 USD、100万リクエストあたり0.20 USDという同一レートが適用されていることが分かります。

これはLambdaユーザーにとって朗報です。例えば、S3ストレージは東京リージョンが米国より約1.09倍、Kinesis Data Streamsに至っては約1.3倍の料金設定となっている中で、Lambdaは主要リージョン間で均一価格が維持されているのは珍しいケースです。

周辺サービスのリージョン差に注意

ただし、Lambda本体の料金は同じでも、付随するサービスには料金差が存在します。

エフェメラルストレージ（一時的な追加ストレージ）の料金を例に挙げると、米国東部（バージニア）ではGB-秒あたり0.0000000309 USDですが、東京リージョンではGB-秒あたり0.000000037 USD程度と、約20%の差があります。大容量の一時領域を長時間使用する特殊なケースでは、このコスト差が無視できなくなる可能性があります。

プロビジョンドコンカレンシーについても同様に、わずかながらリージョン差が存在します。関数の実行時間に対する通常の料金に加えて、プロビジョニングした並行数とメモリ量に応じた待機料金が課金されますが、この待機料金の単価も東京・大阪リージョンでは若干高めに設定されています。

私の経験では、Lambda本体のコストよりも、CloudWatch Logsのストレージ料金やAPI Gatewayの料金の方がリージョン差の影響を受けやすく、全体のアーキテクチャを設計する際には、これらの周辺サービスのコストも含めて検討することが重要です。

ランタイム選択とコスト最適化

ランタイムごとの特性を理解する

Lambdaの料金単価自体は、Node.js、Python、Java、どのランタイムを選んでも変わりません。しかし、「ランタイムの選択は間接的にコストに大きく影響します」。

最も顕著な違いは「コールドスタート」の時間です。JavaやC#などのコンパイル言語は、初回呼び出し時の環境起動に時間がかかる傾向があります。一方、Node.jsやPythonといったインタプリタ言語は起動が速いです。2025年からLambdaの初期化時間も課金対象となる仕様変更があったため、コールドスタートの遅延は直接的なコスト増につながります。

私が実際に計測したところ、同じ処理を実装した場合でも以下のような差がありました。

Javaでは初回起動に2-3秒かかっていた処理が、Node.jsでは0.5秒以下で起動できました。呼び出し頻度が低い関数では、この差が累積して大きなコスト差を生むことになります。一方で、Javaは実行中のパフォーマンスが高く、長時間稼働や連続実行ではウォーム状態で高スループットを発揮するため、大量データ処理ではメモリ増強と併せて実行時間短縮によるコスト削減が期待できます。

SnapStartとプロビジョンドコンカレンシーの使い分け

Java限定のSnapStart機能

Javaランタイムを使用している場合、「SnapStart」という機能を活用できます。これは関数のメモリイメージをスナップショットとして保存し、次回以降のコールドスタートを高速化する機能です。追加料金なしで利用でき、Java関数の起動時間を数秒からサブ秒レベルまで短縮できる可能性があります。

私が担当したあるプロジェクトでは、Spring Bootを使用したJava関数の起動時間が3秒から0.3秒まで短縮され、月間のコストを約15%削減することができました。

lambda provisioned concurrency（プロビジョンドコンカレンシー）の活用

プロビジョンドコンカレンシー（PC）を有効にすると、関数をウォーム状態に維持できますが、その分追加料金が発生します。メモリ割当1GBあたり0.0000041667 USD/秒程度の待機料金がかかるため、使い方を誤るとアイドル時のコスト増につながります。

私の経験則では、以下のような場合にPCの利用を検討することをお勧めします。

トラフィックパターンが予測可能で、特定の時間帯に集中する場合は、スケジュールベースでPCをオン/オフすることで必要最小限のコストで応答性能を確保できます。また、Application Auto Scalingを使用して、利用率に応じてPC数を動的に調整する設定も有効です。

実装レベルでのコスト最適化テクニック

コードパッケージサイズの削減

デプロイするコード（デプロイパッケージやコンテナイメージ）のサイズは、直接的にコールドスタート時間に影響します。パッケージが大きいと、関数起動時の読み込みに時間がかかり、その遅延時間も課金対象となります。

私が実践している削減テクニックは以下の通りです。

不要な依存ライブラリを徹底的に除去し、本当に必要なモジュールのみをパッケージに含めるようにしています。Node.jsの場合、webpack等のバンドラーを使用してツリーシェイキングを行い、未使用のコードを削除します。Pythonでは、Lambdaレイヤーを活用して共通ライブラリをキャッシュし、関数本体のサイズを最小限に抑えています。

ある案件では、10MBあったNode.jsパッケージを1MBまで縮小することで、コールドスタート時間を約40%短縮し、月間コストを8%削減することができました。

グローバル変数とコネクションの再利用

Lambda関数は初回実行後、そのコンテナがしばらく再利用されます（ウォーム状態）。この特性を活かして、関数ハンドラ外でグローバル変数やオブジェクトを宣言し初期化しておけば、2回目以降の呼び出し時に初期化コストなしで使い回せます。

特にデータベース接続は、毎回関数内で確立するとその待機時間も課金されるため、グローバルスコープで保持し、ウォーム時には再利用することが重要です。以下のようなパターンを採用しています。

import { Event } from "aws-lambda"
let dbConnection: DatabaseConnection | null = null;

export const handler = async (event: Event) => {
  if (!dbConnection) {
    dbConnection = await createConnection();
  }
  // 処理の実装
};

このアプローチにより、2回目以降の実行では接続確立のオーバーヘッドがゼロになり、実行時間を大幅に短縮できます。

ログ出力の最適化

Lambda自体の料金ではありませんが、出力されたログはCloudWatch Logsに蓄積され、データ量に応じて課金されます。不要な詳細ログを本番環境で出力し続けると、GB単位でログが蓄積し、長期的にはLambda本体より高い費用となるケースもあります。

私は環境変数でログレベルを制御し、本番環境ではINFOレベル以上のみを出力するようにしています。AWS Lambda Powertoolsを使用すれば、この制御を簡単に実装できます。

ユースケース別の設計指針

バッチ処理での活用

大量のデータやジョブを処理するバッチ用途では、「並列度と実行時間のバランス」が重要です。

私が実装したあるバッチ処理システムでは、Step Functionsを使用して処理を複数の小さな関数に分割し、オーケストレーションしました。Step Functionsを使えば、関数間の待ち時間に課金されないため、長時間の集計・待機を伴うバッチ処理を安価に実現できます。

また、15分の実行上限を超えるワークフローやリトライ制御も、Step Functionsのステートマシンに委ねることで安価に扱えます。ただし、常時一定の負荷がある場合は、コンテナサービス（AWS BatchやFargateなど）やEC2によるスケジュール実行の方がLambdaより安価になる閾値が存在することも覚えておく必要があります。

私の試算では、1秒あたり約66リクエストを超える頻度で処理し続ける場合、EC2の方が安くなることが分かりました。

APIバックエンドとしての活用

APIのバックエンドとしてLambdaを使用する場合、「アクセスパターンとレイテンシ要求」がコストに大きく影響します。

アクセスが断続的またはスパイク的であれば、アイドル時に料金がかからないLambdaは非常に有利です。月間数万から数百万程度のAPIリクエストであれば、ほぼ無料枠内またはごく低コストで運用できます。

一方で、高トラフィックが継続するAPIでは、Lambdaの従量課金が積み上がり、コンテナ常駐より高くつくケースもあります。Ready, Set, Cloudの試算によると、1秒あたり15リクエスト程度を常時処理する規模からApp Runnerの方が安価になるとされています。

私が実装したAPIでは、API Gatewayのキャッシュ機能やCloudFrontとの連携を活用し、Lambda呼び出し回数自体を減らすことで大幅なコスト削減を実現しました。頻出するレスポンスをキャッシュすることで、Lambda呼び出しを70%削減できた事例もあります。

イベント駆動型アプリケーション

S3へのファイルアップロードやデータストリーム、キューのメッセージなど、イベント駆動でLambdaを起動するシナリオでは、「不要な起動を減らすこと」がダイレクトにコスト減となります。

AWSはLambdaのイベントソースマッピングにフィルタ機能を提供しており、特定の条件に合致する場合のみLambdaを起動するといった設定が可能です。このイベントフィルタリングを活用することで、処理する必要のないイベントに対してLambdaが呼び出される無駄を省けます。

また、バッチサイズの調整も重要なポイントです。Amazon KinesisやDynamoDB Streamsでは複数レコードをまとめて1回のLambda呼び出しで処理できます。私の経験では、バッチサイズを100件に設定することで、起動回数を1/100に削減し、月間コストを約30%削減できたケースがあります。

他のコンピュートサービスとの使い分け

Fargateとの比較

AWS FargateはECS/EKSのコンテナ実行基盤をサーバーレス化したもので、「常時稼働が必要なコンテナワークロード」に適しています。

長時間実行する処理（Lambdaの15分上限を超えるようなバッチやストリーミング処理）、常に一定のCPU/メモリを消費するサービス、また特定のライブラリや環境を自由に使いたい場合に適しています。

Fargateはリソース使用量（vCPU・メモリ）に応じた秒課金で、リクエスト数には依存しません。私が実施した比較検証では、継続的に高トラフィック（50 req/s以上）があるWeb APIは、LambdaよりFargateでコンテナサービス化した方が約70%コスト削減できました。

App Runnerとの選択基準

AWS App Runnerはコンテナ化されたWebアプリケーションやAPIを自動でビルド・デプロイ・スケーリングしてくれるフルマネージドサービスです。

料金は割り当てたCPU・メモリに対する秒課金で、アイドル時も最小1インスタンス分は課金されます。トラフィックがごく僅少な時間帯が長い場合はLambdaの方が安く済みますが、ある程度継続的にリクエストが飛んでくるWebアプリであれば、App Runnerの方が低コストです。

私の試算では、50 req/s規模のアプリをLambdaで動かした場合約370 USD/月、App Runnerでは112 USD/月という結果になり、一定以上のスループットではApp Runnerが圧倒的に低コストとなりました。

EC2の検討が必要なケース

Amazon EC2は従来型の仮想サーバーサービスで、「最高度の制御性」が必要な場合に選択します。

特殊なハードウェア資源が必要（GPU搭載機や高RAM機など）な場合や、カーネルチューニングを含めOSレベルから制御したい場合にはEC2が唯一の選択肢となります。

継続的高負荷であればReserved InstancesやSaving Plansの適用で大幅な割引（最大40%超）が可能で、長期的に見ればLambdaより遥かに安価になり得ます。私が携わったプロジェクトでは、初期はLambdaで素早く構築し、トラフィック増加に応じてEC2への移行を検討するという段階的アプローチを採用しました。

インフラ設計における全体最適化

Step Functionsによるワークフロー制御

Step Functionsを用いてワークフロー制御やエラーリトライ、待機処理を肩代わりさせることで、Lambda関数内の無駄な待ち時間を排除できます。

例えば、複数のLambdaを順次呼び出していたケースでは、Step Functionsの標準ワークフローに乗せ替えることで、各関数間の待ち時間に料金が発生しなくなります。また、Step Functions自体は200以上のAWSサービスに直接統合でき、多くのAPI呼び出しをネイティブにサポートしています。

私が実装したシステムでは、「仲介Lambda」と呼ばれる単に他のAWSサービスを呼び出すだけのLambdaを排除し、Step FunctionsやEventBridgeから直接サービスを呼び出す形に変更することで、月間のLambda実行コストを約25%削減できました。

Lambda@EdgeとリージョンLambdaの使い分け

Lambda@EdgeはCloudFront（グローバルCDN）のエッジロケーションでコードを実行できるサービスですが、料金体系が通常のLambdaとは異なり割高です。

リクエスト100万件あたり0.60 USD（通常Lambdaの3倍）、実行時間もGB-秒あたり0.00005001 USDと通常の約3倍の単価が適用されます。したがって、遅延低減が必要な特殊なケース以外では、EdgeではなくリージョンLambdaで処理した方がコスト面で有利です。

私の経験では、ユーザに近い場所でヘッダ操作など軽微な処理をする目的でLambda@Edgeを使う場合でも、その便利さと引き換えにリクエスト単価が3倍になる点を慎重に検討する必要があります。

マルチリージョン戦略のコスト影響

グローバル展開するアプリケーションでは、どのリージョンにデプロイするかもコストに影響します。

Lambda自体の料金は世界的に均一ですが、他の周辺サービス（API Gatewayやデータベース、ストレージなど）はリージョンにより料金差があります。日本ユーザ向けサービスで米国リージョンを使うと通信遅延が増えユーザ体験を損ねる可能性がありますが、バックエンドのデータ処理などレイテンシが許容される部分では、コストの安いリージョンを選択することも検討できます。

リージョン間のデータ転送料も馬鹿にならないため、可能な限り同一リージョン内で完結するアーキテクチャにし、マルチリージョン冗長は必要最小限かつデータ複製を効率的に行うことが重要です。

まとめ

AWS Lambdaの料金体系について、基本的な構造から実践的な最適化テクニックまで解説してきました。

重要なポイントを振り返ると、Lambdaの料金は「GB-秒」と「リクエスト回数」という2つの要素で決まりますが、実際のコスト最適化では、ランタイム選択、メモリ設定、コールドスタート対策、アーキテクチャ設計など、多角的な視点が必要です。

東京リージョンと大阪リージョンでLambda本体の料金差はありませんが、周辺サービスの料金差や、グローバルアーキテクチャを考慮した全体最適化が重要になります。

また、Lambdaがすべてのケースでベストというわけではなく、ワークロードの特性に応じてFargate、App Runner、EC2などと適切に使い分けることが、真のコスト最適化につながります。

私自身、これまで様々なプロジェクトでLambdaを活用してきましたが、「まずLambdaで実装してみる → コストモニタリング → 閾値を超えたらコンテナに移行検討」という流れを踏むことで、無駄な先行投資を避けつつ成長に応じた最適化を実現してきました。

サーバーレスアーキテクチャは今後もさらに進化していくことでしょう。AWSも定期的に新機能や料金体系の改善を発表しており、常に最新情報をキャッチアップしながら、より効率的なシステム設計を追求していくことが、エンジニアとしての責務だと考えています。

みなさんも本記事を参考に、自社のワークロードに最適なLambda活用方法を見つけていただければ幸いです。コスト最適化は一朝一夕には実現できませんが、小さな改善の積み重ねが大きな成果につながることを、私自身の経験から確信しています。