Lambdaの選択肢：S3とEFS、ファイル保存先の正しい使い分け

はじめに：ただの「データの置き場所」じゃなかった２つの選択肢

AWS Lambdaを使い始めた頃、僕は「データを保存するならS3でしょ」と、少し単純に考えていました。しかし、調べてみると、もう一つAmazon EFSというサービスも候補にあることに気づかされました。

Amazon S3は、APIでファイルをやり取りする「ウェブサービスとしてのストレージ」。一方のAmazon EFSは、サーバーでお馴染みの「共有フォルダ」そのものです。この違いを理解することが、AWS Lambdaの性能やコストを最適化する第一歩でした。この記事では、僕が学んだS3とEFSの使い分けについて、深掘りしてみたいと思います。

最初の関門：VPCとの付き合い方

両者の最も大きな違いは、VPC（仮想プライベートネットワーク）との関係性です。

Amazon S3：VPC不要で、とにかく手軽！

Amazon S3はVPCの外にあるサービスなので、AWS LambdaをVPCに入れる必要がありません。これは大きなメリットです。

• コールドスタートが速い: VPC特有のネットワーク準備が不要なため、Lambdaの起動が軽快です。
• IPアドレスを気にしなくていい: 大量のAWS Lambdaを同時に動かしても、VPCのIPアドレスが枯渇する心配がありません。

Amazon EFS：VPCの中で動かすのがお約束

対照的に、Amazon EFSを使うにはAWS Lambdaも必ず同じVPCに入れる必要があります。これにより、いくつかの「お作法」が求められます。

• 起動に少し時間がかかる: 起動時にネットワーク接続の準備（ENIアタッチ）が入るため、S3を使う時より少し「準備運動」の時間が必要です。
• IPアドレスの管理: 同時実行数が増えると、その分サブネットのIPアドレスを消費します。
• インターネット接続には追加設定が必要: Amazon EFSを使いつつ外部APIを呼び出したい場合、「NATゲートウェイ」という仕組みが別途必要になり、コストもかかります。

パフォーマンス比較：「速さ」の質が違う

「どっちが速い？」という質問への答えは、「時と場合による」です。

レイテンシ（応答速度）

• Amazon S3: 数十〜数百ミリ秒。
• Amazon EFS: 数ミリ秒以下。

スループット（一度に運べる量）

• Amazon S3: アクセスがどれだけ集中しても、ほとんど性能が落ちません。
• Amazon EFS: 一つの処理は高速ですが、アクセスが集中すると順番待ちが発生することがあります。

同時実行制御（ファイルの同時編集）

• Amazon S3: ロック機能はありません。複数のAWS Lambdaが同時に同じファイルに書き込んだ場合、最後に完了した処理が全てを上書きします（後勝ち）。
• Amazon EFS: ファイルロックが使えます。これはAmazon EFSの強力な武器で、「Aさんが編集中は、Bさんは読み取りだけ」といった制御が可能です。データの整合性を守りたい場合に非常に頼りになります。

コストモデル：どこにお金がかかる？

ストレージ料金以外にも、それぞれの課金ポイントを把握しておくことが重要です。

Amazon S3はファイルを操作する回数にも料金がかかること、EFSはVPCの構成によって追加コストが発生する場合があることを覚えておきましょう。

結論：僕なりの使い分けガイド

結局のところ、どちらが良いかは作りたいもの次第。僕なら、こう使い分けます。

Amazon S3を選ぶとき：ステートレスな「データ加工パイプライン」として

Amazon S3イベントをきっかけに、データを一つずつ、流れ作業のように処理していくイメージです。

• 最適なユースケース:
  • 画像や動画の変換
  • 大規模なバッチ処理やデータ変換（ETL）
  • 静的サイトのビルド

Amazon EFSを選ぶとき：ステートフルな「共有ワークスペース」として

複数のAWS Lambdaが、同じ場所に置かれたファイルを共有・編集しながら協調して動作するイメージです。

• 最適なユースケース:
  • ファイル操作が前提の既存システムの移行
  • WordPressのようなCMSのバックエンド
  • 複数のAWS Lambdaで共有したい、巨大なAIモデルや設定ファイルの配置場所

Amazon S3とAmazon EFS、それぞれの「得意なこと」を理解して使い分けることが、スマートなサーバーレスアプリケーションへの近道だと僕は考えています。