AWSは最近、Lambda向けのセルフマネージドコードストレージを発表しました。これにより、関数やレイヤーがLambda管理ストレージではなく、顧客所有のS3バケット内のデプロイメントパッケージを直接参照できるようになります。この変更により、多数の関数を運用するチームがこれまでサポートチケットを通じて引き上げてきたリージョンごとのコードストレージクォータが撤廃され、Lambda管理ストレージのデフォルトが75 GBから300 GBに引き上げられます。AWSの発表やそれに続くコミュニティの反応における表現は、誤解を招きやすいものとなっています。

AWSのサーバーレス担当プリンシパルデベロッパーアドボケートであるJulian Wood氏は、LinkedInでこの変更を「ストレージ制限なし：バケットが許す限り、関数およびレイヤーのコードを保存可能」と要約し、顧客自身のアカウント内での単一の信頼できる情報源と、既存のS3メトリクスおよびライフサイクルルールを通じた完全な可視性を提供すると述べています。

この表現は、サーバーレスチームが実際に気にする質問を促しました。あるコメント投稿者が、この変更によりより大きなモデルを関数パッケージ内に同梱できるようになるのかと質問したところ、別の開発者からの回答は率直なものでした。

いいえ、同じ制限が適用されます。AWSはストレージと取得のコストも請求できるようになっただけです。

セルフマネージドストレージは、デプロイメントパッケージの保存場所を変更し、アカウント全体の上限を撤廃するものです。しかし、関数ごとのパッケージ制限は変更されず、zipベースの関数の場合は50 MB（圧縮）および250 MB（非圧縮）、コンテナイメージの場合は10 GBのままであり続けます。個別の関数でサイズの壁に直面しているチームは、以前とまったく同じ状況にあります。

運用上変わる点は、コピーのステップです。AWS Serverless HeroのDarryl Ruggles氏はX（旧Twitter）で、Lambdaが中間コピーを作成しなくなったと指摘しています。

この変更により、独自のバケットからソースコードを直接参照でき、Lambdaが中間コピーを作成しなくなります。これにより、作成および更新後の関数起動を高速化できます。

Ruggles氏は、標準的なS3ストレージ料金およびリージョン間転送料金以外にLambdaの追加料金は発生しないと付け加えています。これにより、ストレージコストはLambda側の不可視のクォータから、顧客自身のS3請求書上の可視的な項目へ移行します。

デプロイメントワークフロー自体は変更されません。Redditでは、S3内のオブジェクトを置き換えた後にUpdateFunctionCodeを呼び出す必要がある場合にどのようなメリットがあるのかという質問が投稿されました。参照は更新時に解決されるもので、継続的に行われるものではないため、バケットをLambdaに指定してもそのバケットがライブのコードフィードになるわけではありません。別のコメント投稿者は価値を率直に表現しています。

マネージドストレージの上限を克服するネイティブオプションであり、ほとんどのチームはそれに達することはないでしょう。

Infrastructure-as-Codeのサポートはまだ追いついていません。Terraformプロバイダーの機能強化リクエストが7月15日に提出され、aws_lambda_functionにs3_object_storage_mode属性を追加するよう求めていますが、実装は行われておらずオープンなままです。Terraformに標準化しているチームは待つか、現在CLIおよびSDKで利用可能なパラメータを使用する必要があります。

セルフマネージドコードストレージは、Lambdaの追加料金なしですべての商用AWSリージョンで利用可能です。

著者について

Steef-Jan Wiggers