Amazon S3 はオブジェクトストレージの事実上の標準であり、その地位は機能の多さよりも「S3 互換 API」という生態系を生み出したことに表れている。後発のストレージの多くが S3 API に互換性を持たせており、SDK もツールも S3 を前提に整備されている。新規プロジェクトで「とりあえずファイルを置く場所」を決めるとき、S3 を選んで困ることはまずない。

単なる保管庫ではない

静的ファイルの保管、バックアップ、CloudFront のオリジン、データレイクの土台と、S3 は AWS のさまざまなワークロードの基盤になる。署名付き URL で一時的なアップロード・ダウンロード権限を渡せる仕組みや、ライフサイクルポリシーで古いオブジェクトを安価なストレージクラスへ自動移行できる点は、運用を続けるほど効いてくる。

ストレージクラスの選択が運用を左右する

S3 には標準のほかに、アクセス頻度の低いデータ向けや、アクセスパターンを自動判定する Intelligent-Tiering、アーカイブ向けの Glacier 系など複数のクラスがある。すべてを標準クラスに置くと、ほとんど読まれないバックアップにも高い保管料がかかる。一方、Glacier 系は取り出しに時間と追加料金がかかるため、復元の即時性が要るデータを入れると運用で困る。データの読まれ方に合わせてクラスを設計するのが、コストと使い勝手の両立点になる。

コスト構造の落とし穴

料金はストレージ量・リクエスト数・データ転送量の三本立てで、見落とされがちなのが転送量（egress）だ。画像や動画を外部に大量配信するサービスでは、保管費よりも転送費が支配的になることがある。配信が重いワークロードなら、egress 無料の Cloudflare R2 のような選択肢と比較する価値がある。AWS スタック内で処理が完結するなら S3 が素直で、外向き配信が主役なら一度コストを試算してから決めたい。小さなオブジェクトを大量に読み書きするとリクエスト課金が積み上がる点も、設計段階で見ておきたい落とし穴だ。

公開設定の事故が最も多い

S3 に関する情報漏えいの多くは、バケットやオブジェクトを意図せず公開状態にしたことが原因になる。現在はデフォルトで公開がブロックされる設定になっているが、「画像が表示されない」という理由で公開ブロックを外す判断が、そのまま全データの公開につながる事例は後を絶たない。公開したいのが一部のファイルであれば、署名付き URL や CloudFront 経由の配信を使い、バケット自体は非公開のまま保つべきだ。

🔴
「とりあえず公開」で解決しないでください

アクセスできない問題の原因は、多くの場合バケットポリシーか IAM 権限か CORS 設定のいずれかです。公開ブロックを外すのは最も安易で最も危険な回避策です。原因を切り分けてから、必要最小限の範囲で権限を与えてください。

削除の取り返しをどう確保するか

誤って削除したオブジェクトは、バージョニングを有効にしていなければ戻せない。バージョニングは保存容量が増える代わりに、上書きと削除からの復旧手段になる。あわせて、削除操作に多要素認証を要求する設定や、ライフサイクルで古いバージョンを自動的に整理する設定を組み合わせると、安全性とコストの両立ができる。重要なデータほど、消えたときにどうするかを先に決めておきたい。