AWS Lambda へのデプロイ時に CodeStorageExceededException が発生した場合の対処として適切なものはどれですか。

解説

正解は「使われていない古い関数バージョンを削除してコードストレージの使用量を減らす」です。CodeStorageExceededException は、アカウント単位・リージョン単位のコードストレージ総量の上限（デフォルト 75GB）を超えたときに発生するエラーで、保存されているデプロイパッケージの合計サイズを減らすことが直接の対処になります。なぜ容量が膨らむのかLambda では関数を更新するたびに $LATEST が上書きされますが、発行（publish）したバージョンは不変の複製として残り続けます。バージョンは削除しない限り消えず、それぞれがコードストレージを消費します。CI/CD で毎回バージョンを発行している環境では、数十MBのパッケージでも積み重なって上限に達します。# 関数のバージョン一覧を確認します aws lambda list-versions-by-function --function-name my-func # 不要なバージョンを指定して削除します（$LATEST は削除できません） aws lambda delete-function --function-name my-func --qualifier 3どうしてもバージョンを残す必要がある場合は、Service Quotas から「Function and layer storage」のクォータ引き上げを申請するという手段もあります。S3 経由にしても総量は変わりません「デプロイパッケージを S3 バケット経由で」を選びたくなるかもしれませんが、S3 からのアップロードは50MB を超えるパッケージを登録するための手段であって、登録後のコードは結局 Lambda 側のストレージに保存されます。合計容量の上限には何の影響もありません。同様に、Lambda レイヤーも各バージョンがストレージを消費するため、放置したレイヤーバージョンが原因になっているケースもあります。他の指定が無関係な理由「関数のメモリ割り当てを増やして」は実行時に割り当てられる RAM の設定であり、保存領域とは別物です。「エフェメラルストレージ（/tmp）のサイズを」は実行中に一時ファイルを置く領域の設定で、こちらもコード保存量には関係しません。むしろ増やすと実行コストが上がります。参考Lambda クォータ - AWS LambdaLambda 関数のバージョン - AWS Lambda