ある企業が AWS 上で複数の Lambda 関数を運用しており、月次のコスト分析で Lambda のコストが予想を大幅に上回っていることが判明しました。CloudWatch のメトリクスを確認すると、多くの関数でメモリ使用率が設定の 10〜20% 程度しか使われていないにもかかわらず、1,500MB や 3,008MB の高いメモリサイズが設定されていることが分かりました。また、実行時間が非常に長い関数もいくつかあります。最もコスト効率よく Lambda を最適化するにはどの方法が適切ですか？
- A. Lambda の予約済み同時実行数を削減して関数の並列実行を制限し、トータルコストを削減する
- B. すべての Lambda 関数のメモリを一律 128MB に設定し、タイムアウトを最大の 15 分に設定する
- C. Lambda 関数をすべて AWS Fargate に移行し、コンテナで必要なメモリを正確に指定する
- D. AWS Lambda Power Tuning ツール（Step Functions ベースのオープンソースツール）を使って各関数の最適メモリサイズを測定し、コスト-パフォーマンストレードオフの最適点を特定する。AWS Compute Optimizer の Lambda レコメンデーションも活用して、過剰プロビジョニングの関数を特定してメモリを削減する
解答と解説を見る
正解: D
Lambda Power Tuning は異なるメモリサイズで関数をテスト実行し、実行時間とコストのトレードオフグラフを生成します。多くの場合、メモリを増やすことで実行時間が短縮されコスト的に最適な点が見つかります。Compute Optimizer は本番の実際の使用状況からメモリの過剰プロビジョニングを検出し、具体的な削減量を推薦します。この2つの組み合わせがデータ駆動型の最適化として最も効果的です。 B: 一律 128MB への設定は多くの関数でパフォーマンス低下や実行時間増加によるコスト増を招く可能性があります。最適メモリは関数によって異なります。 C: Fargate への移行は大きなアーキテクチャ変更と開発コストが発生し、Lambda のコスト問題への解決策としては過剰です。 A: 同時実行数の削減はスロットリングを引き起こし、リクエストの失敗やレイテンシー増加につながります。コスト削減の適切な方法ではありません。
📚 関連サービスの解説: AWS Lambda ・ AWS Step Functions