この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

Lambdaのメモリ最適化について調べてたら、「メモリ使用率は60〜80%が理想」という説明をよく見かける。数字が具体的だし一見もっともらしいんだけど、AWSの公式ドキュメントを当たってみたらこの数字はどこにも出てこなかった。

結論

「60〜80%」はAWS公式が定めた基準値ではない。ブログや解説記事でよく見る経験則であって、Lambda開発者ガイドにもCompute Optimizerのドキュメントにも該当の記載は見つからなかった。公式が示しているのは数値の目安ではなく、「Compute Optimizerの推奨値を使う」「Lambda Power Tuningで実測する」という判断の仕組み。

何を確認したか

まずLambda開発者ガイドのメモリ設定ページ。ここには128MBから10,240MBまでのメモリ範囲と、メモリに比例してCPUが割り当てられる仕組みの説明はあるけど、使用率のパーセンテージ基準についての記載はない。

次にCompute OptimizerのLambda関数レコメンデーションのドキュメント。こちらも過去14日間の実行メトリクスから機械学習でメモリサイズを推奨する仕組みが書いてあるだけで、「〜%を目指す」という数値目標は出てこない。判定結果は Optimized / NotOptimized / Unavailable の3分類で、パーセンテージでの提示ではない。

Compute Optimizerには制約がある

Compute Optimizerを使う場合、知っておいた方がいい制約が2つある。

• 設定メモリが1,792MBを超える関数は Inconclusive（判定不能）になる
• 過去14日間で呼び出し回数が50回未満の関数はデータ不足扱いになる

低頻度で動く関数や、すでに大きめのメモリを割り当てている関数だと、Compute Optimizerの推奨自体が出てこないケースがある。この場合は次の手段が必要になる。

実測するならLambda Power Tuning

AWSが公開しているオープンソースツール、Lambda Power Tuningを使うと、複数のメモリ設定で実際に関数を実行してコストと実行時間のトレードオフを可視化できる。Step Functionsのステートマシンとして動く。

graph LR
    A[複数のメモリ設定を指定] --> B[各メモリ設定で関数を実行]
    B --> C[実行時間とコストを計測]
    C --> D[コスト/パフォーマンスの可視化レポート]

strategy パラメータで最適化の方向性を選べる。

• cost: コスト最優先
• speed: 速度最優先
• balanced: 両方のバランス（balancedWeight で重み調整、0がコスト寄り、1が速度寄り）

実機未確認の部分

Power Tuningの balancedWeight の挙動やレポートの読み方は今回ドキュメントレベルでしか確認していない。実際に自分の関数で回してみたらまた別記事にする。

まとめると

「使用率60〜80%」を目標値として設定するより、Compute Optimizerの推奨（出ない場合はPower Tuningでの実測）に基づいて判断する方が公式の考え方に近い。数値の暗記より、判断の仕組みを使う方を優先した方がよさそう。