Amazon S3 はオブジェクトストレージの事実上の標準であり、その地位は機能の多さよりも「S3 互換 API」という生態系を生み出したことに表れている。後発のストレージの多くが S3 API に互換性を持たせており、SDK もツールも S3 を前提に整備されている。新規プロジェクトで「とりあえずファイルを置く場所」を決めるとき、S3 を選んで困ることはまずない。
単なる保管庫ではない
静的ファイルの保管、バックアップ、CloudFront のオリジン、データレイクの土台と、S3 は AWS のさまざまなワークロードの基盤になる。署名付き URL で一時的なアップロード・ダウンロード権限を渡せる仕組みや、ライフサイクルポリシーで古いオブジェクトを安価なストレージクラスへ自動移行できる点は、運用を続けるほど効いてくる。
ストレージクラスの選択が運用を左右する
S3 には標準のほかに、アクセス頻度の低いデータ向けや、アクセスパターンを自動判定する Intelligent-Tiering、アーカイブ向けの Glacier 系など複数のクラスがある。すべてを標準クラスに置くと、ほとんど読まれないバックアップにも高い保管料がかかる。一方、Glacier 系は取り出しに時間と追加料金がかかるため、復元の即時性が要るデータを入れると運用で困る。データの読まれ方に合わせてクラスを設計するのが、コストと使い勝手の両立点になる。
コスト構造の落とし穴
料金はストレージ量・リクエスト数・データ転送量の三本立てで、見落とされがちなのが転送量（egress）だ。画像や動画を外部に大量配信するサービスでは、保管費よりも転送費が支配的になることがある。配信が重いワークロードなら、egress 無料の Cloudflare R2 のような選択肢と比較する価値がある。AWS スタック内で処理が完結するなら S3 が素直で、外向き配信が主役なら一度コストを試算してから決めたい。小さなオブジェクトを大量に読み書きするとリクエスト課金が積み上がる点も、設計段階で見ておきたい落とし穴だ。