LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS Lambdaのコスト構造：GB秒課金とメモリ・CPUの関係

サーバーレス（Lambda）のコスト最適化を外注するとは、AWS Lambda固有の課金構造を深く理解した外部パートナーに、メモリ設定・実行時間チューニング・呼び出し設計の見直しを委ねる取り組みです。自社エンジニアがLambdaの運用に慣れていても、コスト観点の体系的な最適化まで手が回らないケースは珍しくありません。

AWS Lambdaの課金は大きく2つの要素で構成されています。1つ目はリクエスト数（ファンクションの呼び出し回数）、2つ目は実行時間をメモリ量で重み付けしたGB秒（Gigabyte-seconds）です。GB秒は「割り当てメモリ量（GB単位）×実際の実行時間（秒）」で計算されます。

重要なのは、Lambdaではメモリ量とCPU処理能力が比例配分される点です。メモリを増やすとCPUも同時に強化されます。その結果、処理速度が上がり実行時間が短縮されます。「メモリを増やすと単価は上がるが、実行時間が縮まるため総コストが下がる」というスイートスポットが存在するのはこの仕組みによるものです。

具体的な単価はAWS公式料金ページで確認する必要があります（リージョン・アーキテクチャによって異なります）。誤ったメモリ設定のまま大量のファンクションを動かし続けると、適正値と比べて不必要なコストが積み上がります。これがLambdaコスト最適化の中心的な課題です。

コスト増大を招く主なパターン

LambdaのAWSコストが膨らむ原因として、実務上よく見られるパターンを整理します。

• メモリ設定がデフォルト（128MB）のまま放置：デフォルトメモリのままだとCPUが少なく、実行時間が長くなりコストが余計にかかるケースがあります。
• 過剰なProvisioned Concurrency設定：コールドスタート対策として設定するProvisioned Concurrency（プロビジョンド・コンカレンシー）は待機中も課金が発生します。必要以上の設定はコスト増に直結します。
• 不要な呼び出しの蓄積：エラー時のリトライ設計や、細かすぎる関数分割による呼び出し回数の増大が、リクエスト課金を押し上げます。
• タイムアウト値の過剰設定：Lambdaの実行時間の上限は15分ですが、タイムアウト値を過剰に長く設定すると、処理が滞ったファンクションがタイムアウトするまで課金が続きます。
• CloudWatch Logsの費用見落とし：デフォルトでLambdaのログはAmazon CloudWatch Logsに送られます。ログの保存量と保存期間（デフォルト無期限）次第では、ログ費用がLambda実行費用に近い水準になるケースがあります。

メモリ最適化のスイートスポットとLambda Power Tuning

メモリ設定の最適化は、Lambdaコスト削減で取り組む価値が高い手段のひとつです。ただし「何MBが適切か」は処理内容によって異なり、勘や経験則だけで決めることには限界があります。そこでAWSが公式に提供しているツールがAWS Lambda Power Tuningです。

AWS Lambda Power Tuningの仕組みと使い方

AWS Lambda Power Tuningは、対象ファンクションに対して複数のメモリ設定で実際のテスト実行を行い、メモリ量ごとのコストと実行時間を測定してグラフ化するオープンソースツールです。AWS Step Functionsを使って動作し、AWS Serverless Application Repository経由でデプロイできます。

利用の流れは次のとおりです。デプロイしたPower Tuning用のStep Functions実行をトリガーし、テストしたいメモリ設定の組み合わせ（例：128MB・256MB・512MB・1024MB・2048MB）と、各メモリ設定での試行回数を指定します。実行後、コスト重視・速度重視の両面での推奨メモリ量を可視化したグラフが得られます。このグラフで「コストが最も低くなるメモリ量」を実測値として確認できます。

CPU集約型の処理（データ変換・画像処理・計算ロジックなど）では、メモリ増加による実行時間短縮の恩恵が出やすい傾向があります。一方、外部APIやデータベースの応答待ちが処理時間の大半を占めるI/O待ちのファンクションでは、メモリを増やしてもCPU性能向上の恩恵が限られるため、スイートスポットの効果が出にくいこともあります。実測して確認することが大切です。

内製でのメモリ最適化が難しい理由

Lambda Power Tuningの活用に必要なのは、ツールのデプロイだけではありません。テスト用のペイロード設計、本番相当の負荷での実測、複数ファンクション横断での優先度付け、そして測定と調整のサイクルを継続する体制が求められます。

ファンクション数が数十〜数百本規模になると、個別の最適化作業は工数が積み上がります。Lambda固有の知識を持ち、測定から実装まで一貫して担える人材が社内にいない場合、外注によって体系的に進める判断が合理的になります。

Graviton2・コールドスタート・ログ費用・呼び出し設計の最適化

Lambdaのコスト最適化はメモリ調整だけにとどまりません。ランタイムアーキテクチャの選択、コールドスタートへの対処、ログ費用の管理、呼び出し設計の改善と、複数の切り口から取り組む必要があります。

Graviton2（arm64）アーキテクチャの活用

AWS LambdaはGraviton2プロセッサを使ったarm64アーキテクチャに対応しています。x86（x86_64）と比べて、同じメモリ設定での単位時間あたりの料金が低く設定されており、価格性能比が優れるケースがあります。AWSの公式料金ページでx86とarm64の料金差を確認できます。

ただし効果はランタイムや処理内容によって異なります。Javaなど一部のランタイムでは、起動時間や実行特性の違いが出る場合があります。アーキテクチャの切り替えにあたっては、使用しているライブラリやネイティブバイナリのarm64互換性確認が必要です。移行前の動作テストと実測比較を経て採否を判断することが大切です。

コールドスタートとProvisioned Concurrencyのコスト

Lambdaは一定時間アイドル状態が続くと実行環境がシャットダウンされます。次の呼び出し時に環境の初期化が発生する状態をコールドスタートと呼びます。コールドスタートによるレイテンシが問題になる場合、Provisioned Concurrency（プロビジョンド・コンカレンシー）を使ってファンクションを事前にウォームアップしておく方法があります。

ただしProvisioned Concurrencyは、ファンクションが呼び出されていない待機中も課金が発生します。コールドスタートによるユーザー体験の悪化を防ぐためのコストと位置付けることが重要です。コスト削減の観点では、Application Auto Scalingと組み合わせてトラフィックが集中する時間帯にのみProvisioned Concurrencyを確保し、閑散時間帯はゼロに戻す構成が有効です。

なお、Java・Python・.NETの一部ランタイムではSnapStartという機能も利用できます（対応ランタイム・バージョンはAWS公式で確認してください）。SnapStartはファンクションの初期化済みスナップショットを保存しておき、コールドスタート時に再利用することで起動を高速化します。Provisioned Concurrencyとは異なる仕組みで、SnapStartはProvisioned Concurrencyと異なり待機分の常時課金は発生しませんが、スナップショットのキャッシュ・復元に関する費用が生じる場合があります（最新の料金はAWS公式でご確認ください）、コールドスタート対策のコストを抑えながら起動時間を改善できる選択肢です。

CloudWatch Logsのコスト管理

Lambdaはデフォルトで実行ログをAmazon CloudWatch Logsに送出します。ロググループの保持期間はデフォルトで無期限のため、ログの蓄積とともに費用が膨らみます。

対策としては次の方法が有効です。まず、ロググループの保持期間を用途に応じた日数（例：30日・90日）に設定し、不要なログの長期保存を防ぎます。ログ出力レベルも見直し、本番環境でデバッグレベルのログを大量出力している場合はINFOやWARNに絞ります。必要な長期保存はS3に転送し、CloudWatch Logsのストレージコストを抑える設計も選択肢です。

呼び出し設計の最適化：バッチ化とタイムアウト設定

Lambdaのリクエスト課金は呼び出し回数に比例します。細かな処理を1件ずつ個別に呼び出す設計より、複数レコードをまとめて処理するバッチ化によって呼び出し回数を抑えられます。Amazon SQSやAmazon Kinesisをトリガーにする場合は、バッチサイズ（1回の呼び出しで処理するレコード数）の設定が呼び出し回数とコストに影響します。

タイムアウト値の適切な設定も重要です。実際の処理時間に対して余裕を持たせながらも、処理が滞ったときにいつまでも課金が続かないよう、合理的な上限を設けることが大切です。不適切に長いタイムアウトは、エラーによる無駄な課金を発生させます。

外注で進める流れ：実績分析→チューニング→測定サイクル

Lambdaのコスト最適化を外注する場合、「現状把握のない最適化作業」は効果測定ができず費用対効果が見えにくくなります。スコープと成果の定義を最初に合意したうえで、以下の流れで進めることが一般的です。

ステップ1：現状の可視化と診断

まず、対象アカウント・リージョンのLambda関連コストを可視化します。AWS Cost ExplorerではLambdaのリクエスト費用と実行時間費用を分けて確認でき、ファンクション単位のコスト内訳も把握できます。AWS Compute Optimizer（コンピュート・オプティマイザー）はLambdaのメモリ設定に関する推奨を提示する機能も持っています。

診断フェーズでは、どのファンクションが費用の大部分を占めているか（上位ファンクションの特定）、メモリ設定が実使用量と乖離していないか、CloudWatch Logsの費用規模、コールドスタートの発生頻度とその影響を整理します。この診断結果が次のチューニング工程の優先順位付けの根拠になります。

ステップ2：メモリ・ランタイム最適化の実装

診断結果をもとに、費用インパクトの大きいファンクションからLambda Power Tuningを実施します。テスト用ペイロードの設計、本番相当の負荷でのテスト実行、測定結果の分析と推奨メモリ量への変更という流れで進みます。

Graviton2（arm64）への移行が効果的と判断されたファンクションについては、ライブラリ互換性の確認と動作テストを経て切り替えを実施します。SnapStart対応のランタイムでコールドスタートが問題になっているケースでは、SnapStartの導入も検討します。

ステップ3：呼び出し設計とProvisioned Concurrencyの見直し

Provisioned Concurrencyの設定内容を棚卸しし、実際のトラフィックパターンに合わせたAuto Scalingスケジュールを設計します。不要なProvisioned Concurrencyを削除し、必要な時間帯にのみ有効化する設定に変更することで待機課金を抑えます。

呼び出し回数が多いファンクションについては、バッチサイズの見直し、エラーリトライ設計の確認、不要な呼び出しの排除を検討します。タイムアウト値も実態に即した値に調整します。

ステップ4：継続的な測定とサイクルの定着

最適化を実施した後は、Cost Explorerと CloudWatch メトリクスを使って費用の変化を継続的にモニタリングします。ファンクションのコード変更やトラフィック増加によって適切なメモリ設定は変わることがあるため、定期的な再測定のサイクルを設けることが重要です。

委託契約の形態として、初期診断と最適化実装をまとめたスポットプロジェクト型と、継続的なモニタリングと定期チューニングを含む月次運用型があります。自社にLambdaのコスト管理を担える人材がいない場合、月次運用型で外注を継続することが費用対効果に見合う判断になります。

外注の費用構造とレンジ感

Lambdaコスト最適化を外注する際の費用は、スコープ・ファンクション数・契約形態によって異なります。以下は市場参考値であり、一次資料に基づく数値ではありません。実際の費用は複数社への見積もり取得で確認してください。

費用対効果を評価するには、最適化前後のAWSコストをCost Explorerで比較します。外注費用と削減額のバランスを確認し、継続契約の判断材料にすることが大切です。なお、Compute Savings Plans（コンピュート・セービングスプラン）はEC2だけでなくLambdaの実行時間費用にも適用できます。メモリ最適化と並行して、利用量の多い環境ではSavings Plansの活用も検討に値します（Savings Plans自体の詳細はAWS公式サイトで確認してください）。

委託先の選び方：Lambda実績・測定体制・継続改善力で判断する

Lambdaコスト最適化の外注先を選ぶ際、汎用的なAWS運用会社と、サーバーレス・Lambda専門の知見を持つパートナーでは対応品質に差が出る場合があります。選定時に確認すべきポイントを整理します。

確認すべき実績と技術力

Lambda固有のコスト最適化経験があるかどうかは、提案内容で確認できます。Power Tuningの活用実績、Graviton2移行の経験、Provisioned Concurrencyとトラフィックパターンの関係設計など、具体的な話が出てくるかどうかが見極めのポイントです。

AWS認定資格（AWS Certified Solutions Architect・AWS Certified Developer等）の保有者がチームにいるかどうかも確認します。資格はベースラインの技術知識を示す指標のひとつです。ただし資格の有無より、実際のLambda最適化の実績と手法の具体性を重視することが大切です。

測定・可視化の体制

最適化の成果を定量的に示せる体制があるかどうかを確認します。Cost Explorerを使ったファンクション別コスト集計、CloudWatchメトリクスを使った実行時間・エラー率・コールドスタート発生率の可視化、最適化前後の比較レポートを提示できるか確認します。

「最適化を実施した」という報告だけで数値を示せない委託先は、費用対効果の評価ができません。KPIの定義と測定方法を契約前に合意しておくことが重要です。

継続改善力とナレッジ移転

Lambdaの最適化は一度やれば終わりではありません。ファンクションのコード変更、トラフィックの変化、AWSの新機能リリース（新しいランタイム・SnapStartの対応拡大など）に応じて継続的な見直しが必要です。定期的なレビューと再チューニングを仕組みとして提供できるかどうかを確認します。

また、外注依存が長期化するリスクを避けるため、最適化の考え方や手順を自社チームに移転してくれるかどうかも確認ポイントです。ドキュメント整備・勉強会・コードレビューの提供など、内製化への道筋を示せるパートナーが長期的に信頼しやすい委託先です。

内製対応との比較：必要なスキルと工数の目安

内製でLambdaコスト最適化を進める場合、求められる知識の範囲は広くなります。Lambda課金構造の深い理解、Power Tuningのセットアップと読み取り、Graviton2移行時のランタイム互換性確認、Provisioned Concurrencyのスケジューリング設計、CloudWatch LogsとCost Explorerの操作、継続モニタリングの仕組み構築が必要です。

ファンクション数が数十本以上ある環境で体系的に取り組む場合、担当者1〜2名が数週間から1か月程度を集中させる工数が目安になります（実際の工数はファンクションの複雑さや環境によって大きく異なります）。この工数を他の開発・運用業務から確保するコストと、外注費用を比較して判断することが合理的です。

まとめ：Lambdaコスト最適化外注の3つの判断軸

本稿では、AWS LambdaのGB秒課金の仕組みとメモリ・CPU比例配分の関係から始まり、Power Tuning・Graviton2・コールドスタート対策・ログ費用管理・呼び出し設計という複数の最適化手段を整理しました。外注で進める流れと費用構造・委託先の選び方についても解説しています。要点を3つに集約します。

第一に、Lambdaのコスト最適化はメモリ設定の見直しが起点になります。Lambda Power Tuningを使って実測データに基づくスイートスポットを特定することが、費用対効果の高いアプローチです。

第二に、メモリ以外にもGraviton2・コールドスタート設計・CloudWatch Logsの管理・呼び出し設計と、複数の手段を組み合わせることで削減の余地が広がります。これらを体系的に進めるには、Lambda固有の知識と継続的な測定サイクルが必要です。

第三に、外注の判断基準は「社内に担える人材がいるか」「継続的な測定サイクルを回せる体制があるか」の2点です。外注先は、Lambda実績・測定の可視化能力・継続改善力・ナレッジ移転の意向を軸に評価することが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Lambda 料金」 — https://aws.amazon.com/jp/lambda/pricing/（2024年）
2. *2　出典：Amazon Web Services「AWS Lambda Power Tuning（AWS Serverless Application Repository）」 — AWS Serverless Application Repository（2024年）
3. *3　出典：Amazon Web Services「Lambda SnapStart」 — https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/snapstart.html（2024年）
4. *4　出典：Amazon Web Services「AWS Compute Optimizer — AWS Lambda 関数の推奨事項」 — https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/lambda-recommendations.html（2024年）

Tweet