Contents
1. AWS Lambda の料金モデルと無料利用枠
Lambda の課金は リクエスト数 と 実行時間（メモリ単位） の 2 要素で構成されます。公式の料金ページでは、1 M リクエストあたり $0.20、GB‑秒あたり $0.00001667 が課金対象と明記されています【AWS Lambda Pricing】。
無料利用枠は毎月 100 万件のリクエスト と 400 000 GB‑秒（約 3.2M 秒 × 128 MiB） が提供され、スタートアップや低トラフィック環境では実質的にコストゼロで運用可能です。
1.1 課金対象の詳細
| 項目 | 無料枠 | 超過時の課金単価 |
|---|---|---|
| リクエスト数 | 月間 100 万件 | $0.20 / 1 M 件 |
| 実行時間（GB‑秒） | 月間 400 000 GB‑秒 | $0.00001667 / GB‑秒 |
重要ポイント
- リクエスト単価は固定、実行時間はメモリ設定と実行秒数の積で算出されるため、メモリと処理時間のバランスがコストに直結します。
- 無料枠を超える前に Cost Explorer で使用量を可視化し、必要なら Savings Plans の適用検討を行いましょう。
2. リソース設定の最適化：メモリ・タイムアウトと過剰サイジング検出
メモリ増加は CPU とネットワーク帯域も比例して向上しますが、GB‑秒課金は「メモリ × 実行秒数」 で計算されるため、不要に大きなメモリを割り当てるとコストが膨らむリスクがあります。本セクションでは CloudWatch の指標を用いた過剰サイジングの検出手順と実装フローを解説します。
2.1 パフォーマンス指標で判断する方法
メモリ設定を最適化する際は、Duration（実行時間） と MaxMemoryUsed（使用メモリ上限） の両方を確認し、以下の基準で評価します。
MaxMemoryUsedが割り当てメモリの 70 % 以下 → メモリ過剰可能性Duration増加が 10 % 未満 かつスループット要件を満たす → ダウングレード可
2.2 CloudWatch メトリクス活用手順
| 指標 | 用途・評価ポイント |
|---|---|
Duration |
実行時間（ミリ秒）。最小/最大値とタイムアウト設定を比較し、余裕度を把握。 |
MaxMemoryUsed |
関数が実際に使用したメモリ上限。割り当てメモリとの差が大きい場合は過剰サイジングの兆候。 |
Invocations |
リクエスト件数。無料枠超過判定やトラフィックパターン分析に活用。 |
重要ポイント
- 両指標を同時に監視することで、単なる「高速化」だけでなく コスト効率の高いメモリサイズ を見極められます。
2.3 実装フロー（データ収集 → 判定 → テスト → 本番適用）
- データ収集：過去 14 日間分の
DurationとMaxMemoryUsedを CloudWatch Insights で抽出。 - 閾値判定：
MaxMemoryUsedが割り当てメモリの 70 % 以下かつDuration増加が 10 % 未満の場合、ダウングレード候補とフラグ付け。 - ステージテスト：候補メモリでステージ環境へデプロイし、負荷ジェネレータ（Artillery / k6）で性能回帰を検証。
- 本番ロールアウト：問題がなければ Blue/Green デプロイまたは Traffic Shifting で段階的に本番適用。
3. AWS Compute Optimizer の活用と評価フロー
Compute Optimizer は Lambda 関数の メモリ と プロビジョンドコンカレンシー に対して自動レコメンデーションを生成します。一次情報は公式ドキュメントに記載されており、最新情報は AWS の開発者ガイドをご参照ください【AWS Compute Optimizer – Lambda Recommendations】。
3.1 推奨レコメンデーション取得手順
| 手順 | 操作内容 |
|---|---|
| 1️⃣ 有効化 | コンソールの Compute Optimizer → Enable。対象リージョンで有効にするだけで自動収集が開始されます。 |
| 2️⃣ 対象選択 | 過去 14 日以上実行履歴がある Lambda 関数を選択（データ量が少ないと推奨精度が低下）。 |
| 3️⃣ レポート取得 | MemoryRecommendation と ProvisionedConcurrencyRecommendation が JSON 形式で出力され、コンソールまたは CLI (aws compute-optimizer get-lambda-recommendation) から確認可能。 |
重要ポイント
Compute Optimizer のレコメンデーションは 「最適化のヒント」 に過ぎません。必ずテストとシミュレーションを実施して、SLA への影響を評価した上で本番導入してください。
3.2 評価フロー（データ収集 → 仮想テスト → コストシミュレーション → 判断）
| フェーズ | 主な作業 | 成果物 |
|---|---|---|
| データ収集 | CloudWatch と X‑Ray から実行トレース取得。リクエストパターン、スロットル率を把握。 | 現状分析レポート |
| 仮想テスト | 推奨メモリでステージ環境にデプロイし、1.5 倍トラフィックをシミュレーション。 | パフォーマンス比較結果 |
| コストシミュレーション | AWS Pricing Calculator に実測データ入力 → 現行費用 vs 推奨後概算費用を算出。 | 削減見込額（%） |
| 判断 | シミュ結果と SLA 要件を総合評価し、採用 / 保留 / 再調整 を決定。 | 実装方針書 |
4. Graviton (Arm64) への移行とベストプラクティス
2026 年にリリースされた Graviton3（arm64） は、同等メモリ構成で最大約 20 % のパフォーマンス向上、価格は約 15 % 割安と AWS の公式ブログで発表されています【AWS Graviton3 Announcement (2026)】。ただし数値は環境やワークロードに依存するため、移行前のベンチマークが必須です。
4.1 移行前チェックリスト
| チェック項目 | 確認方法 |
|---|---|
| バイナリ互換性 | ldd で ARM64 対応か確認、Docker の amazonlinux:2023 (arm64) イメージでビルドテスト。 |
| 外部コマンド | シェルスクリプト内の実行ファイルが x86_64 でないか file コマンドで検証。 |
| ロケール・文字コード | UTF‑8 前提の処理が ARM 環境でも同様に動作するかユニットテスト実施。 |
| パフォーマンスベンチマーク | 同一入力データで x86_64 と arm64 の Duration を比較し、5 %〜10 %以上の改善が見込めるか評価。 |
4.2 移行手順概要
- CI/CD 環境を ARM64 に切替
- CodeBuild の標準イメージ
aws/codebuild/standard:7.0-arm64等を使用し、ビルドプロセス全体を ARM 用に再構築。 - 関数設定変更
- SAM テンプレートまたはコンソールで
Architecture: arm64を指定。例：Architectures: ["arm64"]。 - ステージングデプロイとテスト
- Artillery や k6 で負荷テストを実施し、スループット・レイテンシ・エラーレートを比較。
- 本番ロールアウト
- Blue/Green デプロイ または Traffic Shifting（AWS Lambda のバージョン別トラフィック配分） を活用し、段階的にトラフィックを移行。
重要ポイント
- ARM への完全移行は 互換性テストが鍵 です。特に C/C++ ライブラリや外部バイナリに依存する関数は必ずローカルでビルドし直す必要があります。
- 移行後は CloudWatch のDurationとMaxMemoryUsedを再測定し、実際のパフォーマンス向上が期待通りか確認しましょう。
5. コンカレンシー管理：プロビジョンド vs オンデマンド
Lambda の同時実行数は オンデマンド と プロビジョンドコンカレンシー の二つのモデルで制御できます。トラフィックパターンに応じた適切な選択が、スロットル回避とコスト最適化の両立に直結します。
5.1 適用パターンと推奨設定
| パターン | 推奨モデル | 設定ポイント |
|---|---|---|
| 予測可能な定常トラフィック（バッチ処理、API の基礎呼び出し） | プロビジョンドコンカレンシー | ProvisionedConcurrency を事前に設定し、スパイク時は ReservedConcurrentExecutions で上限を緩衝。 |
| 不規則なスパイクが中心（キャンペーン・イベント） | オンデマンド | 自動スケーリングに任せつつ、Savings Plans（Compute Savings Plans） でベースラインの割引を確保。 |
| 大容量・定常ワークロード（ストリーム処理等） | Lambda Managed Instance（2026 年追加機能） | EC2 と同等の長時間実行が可能。コストはオンデマンドと比較して 10 %〜20 % 削減できるケースあり（AWS の公式ドキュメント参照）。 |
重要ポイント
- プロビジョンドコンカレンシーは スループット保証 が得られる代わりに、未使用分でも課金が発生します。利用率 < 70 % の場合はオンデマンドへ戻すことを検討してください。
5.2 監視指標と自動調整のベストプラクティス
| 指標 | アラート例 |
|---|---|
ProvisionedConcurrencySpilloverInvocations |
プロビジョンドが足りない場合にスパイクが発生。閾値 5 % 超えでアラート。 |
ConcurrentExecutions |
同時実行数のピークを検知し、プロビジョンド設定の見直し材料に。 |
Throttles |
スロットルが頻発したらオンデマンドへ自動シフト（Lambda のトラフィックシフティング機能）を活用。 |
6. コスト管理と Savings Plans の活用、継続的改善サイクル
Savings Plans は Compute Savings Plans と Lambda‑Specific Savings Plans に大別されます。公式ドキュメントでは Lambda‑Specific が最大約 45 % の割引を提供すると記載されています【AWS Savings Plans Overview】。
6.1 Savings Plans シミュレーション手順
| 手順 | 作業内容 |
|---|---|
| ① 使用実績取得 | Cost Explorer から過去 3 ヶ月分の Lambda 別 UsageQuantity（GB‑秒）を CSV エクスポート。 |
| ② プラン選定 | - Compute Savings Plans：全コンピューティングリソースに適用、割引率 15 %〜30 %。 - Lambda‑Specific Savings Plans：Lambda 専用、最大約 45 % 割引。 |
| ③ シミュレーション | AWS Pricing Calculator に実績データ入力し、Commitment (USD) と Estimated Savings を比較。 |
| ④ 判断基準 | コミットメント率が 70 %以上 で使用量が安定している場合はプラン適用を推奨。変動が大きいケースはオンデマンド＋ Compute Savings Plans の組み合わせでリスク分散。 |
重要ポイント
- コミットメント率＝実績使用量 ÷ コミット額 が高いほど割引効果が最大化します。定期的に再評価し、利用パターンの変化に応じてプランを見直しましょう。
6.2 可視化ツールで実運用コストを把握
| ツール | 主な活用例 |
|---|---|
| CloudWatch Billing | 月次請求額とサービス別内訳のリアルタイム取得。予算超過アラート設定が可能。 |
| LambdaDuration / Invocations メトリクス | GB‑秒単位の使用量を正確に把握し、Savings Plans シミュレーションの入力データとして活用。 |
| AWS X‑Ray | 関数間呼び出しや外部 API 待ち時間を可視化。余分な実行時間がコストに与える影響を特定できる。 |
6.3 PDCA サイクルで継続的改善
- Plan（計画）
- Compute Optimizer と Savings Plans シミュレーションで削減目標（例：年間コスト 15 % 削減）を設定。 |
- Do（実施）
- メモリ・タイムアウト最適化、Graviton3 移行、プロビジョンドコンカレンシー導入など具体策を実装。 |
- Check（評価）
- CloudWatch Billing と X‑Ray で実際のコスト変動とパフォーマンス指標を測定。 |
- Act（改善）
- 新たに検出された過剰リソースやスロットルを Compute Optimizer に再投入し、次サイクルへフィードバック。 |
重要ポイント
可視化と自動化を組み合わせることで、「費用ドライバー」 を定量的に把握でき、Savings Plans のコミットメントと実績ギャップを最小限に抑えることが可能です。
まとめ
| 項目 | キーアクション |
|---|---|
| 料金モデル | リクエスト数＋メモリ×実行時間。無料枠活用と Cost Explorer で使用量を常時把握。 |
| メモリ最適化 | MaxMemoryUsed と Duration の両指標で過剰サイジングを検出し、10 % 未満の遅延増加でダウングレード。 |
| Compute Optimizer | 公式ドキュメントに基づく取得手順とテスト・シミュレーションフローを必ず実施。 |
| Graviton3 移行 | バイナリ互換性チェック → ARM64 ビルド → ステージングベンチマーク → Blue/Green ロールアウト。 |
| コンカレンシー管理 | 定常トラフィックはプロビジョンド、スパイクはオンデマンド＋ Savings Plans で最適化。 |
| Savings Plans & PDCA | 実績ベースのシミュレーション → コミットメント率 70 % 以上を目指す → 可視化ツールで継続的に評価・改善。 |
これらの 3 層アプローチ（リソース設定、インフラ選択、コストプラン） を順次導入することで、過剰リソースや無駄なリクエストによる余計な支出を抑えつつ、安定したサーバーレス運用が実現できます。ぜひ本ガイドの手順をプロジェクトに組み込み、2026 年以降も最適化された Lambda 環境を維持してください。