全ストレージをS3に集約する設計 — データレイク・ストレージクラス・パーティション

AWSの設計思想は「困ったらまずS3に置く」です。ログも、バックアップも、分析用データも、中間ファイルも、いったんS3へ集約する。この「全部S3」は、オンプレの「用途ごとに別のストレージ装置」という発想とは根本的に違います。その違いと、集約を活かす設計を整理します。

01「用途別の装置」から「1つのレイクと階層」へ

オンプレでは、高速DB用のSAN、ファイル共有のNAS、バックアップのテープ、と用途ごとに別の装置を買い、それぞれを別々に運用してきました。S3中心の設計はこれを反転させ、データはまずS3という単一のレイクに集約し、性質に応じてストレージクラスで階層化する。装置を増やすのではなく、同じS3の中でクラスを使い分けます。

02ストレージクラス — オンプレ階層との対応

• S3 Standard — 頻繁にアクセスする現役データ。オンプレの一次ストレージ相当
• S3 Intelligent-Tiering — アクセス頻度が読めないデータを、S3が自動で最適な階層に動かす。「とりあえず入れておく」の最適解
• Standard-IA / One Zone-IA — たまに使う。低頻度アクセス相当
• Glacier Instant / Flexible / Deep Archive — アーカイブ。テープの現代版（テープ移行の記事で詳述）

肝は、これらが同じバケットの中でオブジェクト単位に混在できること。オンプレのように「アーカイブ用の別装置に手で移す」必要がなく、ライフサイクルルールで自動的に階層を落とせます。

03ライフサイクルとIntelligent-Tiering — 運用を自動化する

S3集約の真価は運用の自動化です。「作成から30日でIA、90日でGlacier、7年で削除」といったライフサイクルルールを宣言すれば、あとはS3が勝手に動かします。テープ交換も、アーカイブ装置への手動移動も要りません。

04分析を効かせる — パーティションと列指向

S3に集約したデータを、Athena（S3上のデータにSQLを投げる）やRedshift Spectrum、EMRで分析するのが、データレイクの本領です。ここで効くのが2つの設計です。

• パーティション設計 — s3://bucket/table/dt=2026-07-07/ のように日付等でプレフィックスを切る。クエリが対象パーティションだけをスキャンするので、速く安くなる（Athenaはスキャン量で課金）
• 列指向フォーマット — CSVやJSONではなくParquet/ORCで持つ。必要な列だけ読めるので、スキャン量が激減する
• この2つで、同じデータでもクエリのコストと速度が桁で変わります

逆に、生ログをCSVのまま無数の小ファイルでS3に撒くと、分析は遅く高くなります。「S3に置けば分析できる」は半分正しく、パーティションと列指向の設計があって初めて実用になります。

05オンプレ運用との根本的な違い

• 容量計画が消える — S3は事実上無限。「ディスクが満杯」も「増設のための調達」もなくなる
• コストが「使った分」になる — 買い切りの資産ではなく、保管量＋リクエスト＋転送の従量。リクエスト課金を意識した設計が要る
• 耐久性が桁違い — S3の設計上の耐久性は非常に高く、RAIDやレプリケーションを自分で組む発想（RAIDの記事）から解放される
• データが「動かせる資産」になる — 装置に固定されず、分析・連携・AI活用（Security Lakeやデータレイク）へ流用できる

—まとめ

「全ストレージをS3へ」は、単なる置き場所の変更ではなく、用途別の装置運用から単一レイク＋自動階層化への発想転換です。ストレージクラスとライフサイクルで運用を自動化し、パーティションと列指向で分析を効かせる。オンプレの容量計画・調達・RAID設計から解放される代わりに、従量課金とオブジェクトストレージの癖（前々回・前回）を設計に織り込む。この転換ができると、S3は単なる倉庫ではなく、データ活用の土台になります。