ストレージの全体像

AWS のストレージは3種類の方式に分かれる。オンプレとの対応関係を整理すると選択しやすい。

AWS サービス方式オンプレの対応特徴
EBSブロックストレージSAN / 物理ディスクEC2 に1対1でアタッチ。高速な随時アクセス向け
EFS共有ファイルストレージNAS / NFS / ファイルサーバー複数の EC2/コンテナから同時マウント可能
S3オブジェクトストレージファイルサーバー / バックアップストレージ容量無制限・高耐久性。HTTP/S でアクセス

判断フロー

Q1. サーバー（EC2）に直接アタッチするディスクが必要か？
　├─ Yes（OS・DB データファイル・アプリのローカルストレージ）→ EBS
　└─ No → Q2 へ

Q2. 複数のサーバー / コンテナから同時にマウントして読み書きする必要があるか？
　├─ Yes（共有ファイルシステムが必要）→ EFS
　└─ No → Q3 へ

Q3. ファイルの置き場・配信・バックアップ・アーカイブか？
　├─ 頻繁にアクセスする（静的コンテンツ・ログ収集など）→ S3 Standard
　├─ 月1回程度のアクセス → S3 Standard-IA
　└─ 年数回・長期アーカイブ → S3 Glacier Instant / Flexible

EBS — ブロックストレージ

EBS（Elastic Block Store）は EC2 インスタンスにアタッチして使うブロックストレージだ。 物理サーバーの HDD/SSD に相当し、OS ブートボリュームや DB のデータファイル格納に使う。

主なボリュームタイプ：

タイプ用途最大 IOPSコスト
gp3（汎用 SSD）ほとんどのワークロード16,000低〜中
io2 Block Express（プロビジョンド IOPS）高 IOPS が必要な DB256,000高
st1（スループット最適化 HDD）大容量シーケンシャルアクセス（ログ等）500低
sc1（コールド HDD）アクセス頻度が低いデータ250最低

💡 gp3 を基本に選ぶ

gp3 は gp2 の後継で、同じ価格帯でより高い IOPS・スループットを提供する。新規で EBS を作る場合は基本的に gp3 を選べばよい。DB などで高 IOPS が必要な場合のみ io2 を検討する。

EBS の注意点：

  • EBS は 1つの EC2 に1つが基本（通常は複数の EC2 から同時アクセス不可）
  • 同一 AZ 内にのみ存在。EC2 とは同じ AZ に配置する必要がある
  • EC2 を停止してもデータは残る（インスタンスを終了するとデフォルトで削除されるため注意）
  • スナップショットで S3 にバックアップ可能（クロスリージョンコピーも可）

EFS — 共有ファイルストレージ

EFS（Elastic File System）は 複数の EC2 インスタンスや ECS/Fargate コンテナから同時にマウントできる共有ファイルシステムだ。 オンプレの NAS（NFS）に相当し、複数サーバーで同一ファイルを参照するワークロードに適する。

EFS を選ぶケース：

  • Web サーバーが複数台あり、アップロードファイルを共有したい
  • コンテナ（Fargate）間で設定ファイルや一時ファイルを共有したい
  • CMS（WordPress 等）の /wp-content を複数 AP サーバーで共有したい

EFS のパフォーマンスモード：

  • General Purpose：レイテンシ優先。ほとんどのケースで十分
  • Max I/O：高スループット優先だがレイテンシが増加。大規模なビッグデータ処理向け

⚠️ EFS のコストに注意

EFS は EBS に比べて単価が高い（gp3 の約3倍程度）。また容量に応じた従量課金のため、大量データを格納するとコストが膨らみやすい。頻繁にアクセスしないファイルは EFS Infrequent Access（IA）クラスに自動移行するライフサイクルポリシーを設定しよう。

S3 — オブジェクトストレージ

Amazon S3 は 容量無制限のオブジェクトストレージで、AWS の基盤インフラとして幅広く活用されている。 ファイルはキー（パス）で管理され、HTTP/HTTPS でアクセスする。 ファイルシステムのようなディレクトリ構造はないが、パスの「/」区切りで階層的に見せることができる。

S3 の主な用途：

  • 静的コンテンツのホスティング：HTML/CSS/JS/画像を S3 で配信（CloudFront と組み合わせると CDN として機能）
  • バックアップ・アーカイブ：EBS スナップショット・DB ダンプ・ログの長期保管
  • データレイク：Athena / Redshift Spectrum で S3 上のデータを SQL クエリ
  • Lambda のトリガー：ファイルアップロードをトリガーに処理を自動実行
  • アプリのファイルアップロード先：ユーザーがアップロードした画像・動画・帳票の保管

S3 のストレージクラス選び

S3 はアクセス頻度に応じてストレージクラスを選ぶことでコストを最適化できる。

ストレージクラス用途取得レイテンシコスト感
Standard頻繁にアクセスするデータミリ秒基準
Intelligent-Tieringアクセスパターンが不明ミリ秒中（自動最適化）
Standard-IA月1回程度のアクセスミリ秒低（取得コストあり）
Glacier Instant Retrieval四半期1回程度ミリ秒非常に低
Glacier Flexible Retrieval年1〜2回・長期アーカイブ分〜時間最低
Glacier Deep Archive7〜10年保管・規制対応12時間最低水準

✅ S3 ライフサイクルポリシーを活用する

「作成から30日後に Standard-IA へ移行、90日後に Glacier へ移行、5年後に削除」のようなルールを S3 ライフサイクルポリシーで自動化できる。ログやバックアップは必ずライフサイクルポリシーを設定し、ストレージコストを管理しよう。

比較表

観点EBSEFSS3
アクセス方法EC2 にマウント（ブロック）複数の EC2/ECS にマウント（NFS）HTTP/API（オブジェクト）
同時アクセス原則1台複数台 OK複数アクセス OK
容量最大 64TiB / ボリューム自動拡張（実質無制限）実質無制限
コスト感低（gp3: 約 $0.08/GB/月）中〜高（約 $0.30/GB/月）最低（Standard: 約 $0.023/GB/月）
オンプレ対応SAN / ローカルディスクNAS / NFSファイルサーバー / オブジェクトストレージ

実務での判断ポイント

  • オンプレの NFS 共有フォルダ → EFS：ほぼ直接移行できる。ただし EFS は Linux 専用（Windows の SMB には Amazon FSx for Windows File Server を使う）
  • オンプレの Object Storage（S3互換）→ S3：MinIO 等をオンプレで使っていた場合は S3 API 互換のため移行が容易
  • EBS の IOPS 設計：オンプレ DB の IOPS 実績を確認し、gp3 の最大 16,000 IOPS で足りるか確認する。DB 移行前に AWS の IOPS 上限を事前テストしておくとよい
  • S3 の暗号化：デフォルトで SSE-S3（サーバーサイド暗号化）が有効。機密データは SSE-KMS（独自 KMS キー）を使うことでアクセス制御を強化できる

✅ 次の章では…

PART 05 ではネットワーク設計の選び方を解説する。ALB/NLB の使い分け、VPC 設計、オンプレとのハイブリッド接続（Direct Connect vs VPN）の判断フローを整理する。

→ PART 05 — ネットワークの選び方へ