SAA ストレージ選択ガイド｜S3・EBS・EFS・FSx・Storage Gateway の要件別選択基準
AWS SAA-C03 で問われるストレージ選択の判断軸を完全整理。S3（オブジェクト）・EBS（ブロック）・EFS（ファイル）・FSx・Storage Gateway の5サービスを「アクセスパターン」「共有要件」「オンプレ連携」の3軸で即断できる粒度で解説。試験頻出ひっかけと正しい打ち手も完全網羅。
「どのストレージを選ぶか」という問いに、SAA-C03 は3軸しか使わない。 S3・EBS・EFS・FSx・Storage Gateway はいずれも「データを保存する」サービスだが、「単一EC2に高速ブロックデバイスが欲しい」「複数インスタンスで同一ファイルを共有したい」「大量オブジェクトを安価に保存したい」「オンプレミスとクラウドをシームレスに繋ぎたい」の局面で答えが明確に分岐する。攻略の核心は**「アクセスパターン（ブロック vs ファイル vs オブジェクト）」「共有要件（単一 vs 複数インスタンス）」「オンプレ連携の有無」の3軸**で要件を分類することだ。本記事では、SAA-C03 のストレージ問題を即断できる4設計パターンを、要件キーワードから逆引きできる粒度で解説する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：ストレージ選択の4設計パターン
- 3軸の判断フレームワーク
- パターン1：EBS — EC2 専属の高速ブロックデバイス
- パターン2：EFS / FSx — 複数 EC2 間のファイル共有
- パターン3：S3 + ライフサイクル — 大容量オブジェクト保存とコスト最適化
- パターン4：Storage Gateway — オンプレミスとクラウドの統合
- サービス比較：5サービスの特性一覧
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：ストレージ選択の4設計パターン
SAA-C03 のストレージ問題を最短で解く骨格は、「何を保存するか（データの性質）」と「誰がアクセスするか（アクセス主体）」を先に決めることだ。
| パターン | 主な技術 | 典型的なシナリオ | 試験での見分け方 |
|---|---|---|---|
| 1. EBS | gp3, io2 Block Express | EC2 の OS・DB・アプリデータの永続化 | 「単一 EC2」「高 IOPS」「低レイテンシ」「ブロックストレージ」 |
| 2. EFS / FSx | EFS, FSx for Windows, FSx for Lustre | 複数 EC2 が同じファイルを同時読み書き | 「複数インスタンス共有」「NFS」「SMB」「Linux/Windows ファイルサーバー」 |
| 3. S3 + ライフサイクル | S3 Standard, S3-IA, S3 Glacier | 静的ファイル配信・バックアップ・アーカイブ | 「オブジェクトストレージ」「ペタバイト」「低コスト」「静的ウェブサイト」 |
| 4. Storage Gateway | S3 File GW, Volume GW, Tape GW | オンプレのファイルサーバー/バックアップを AWS に移行・統合 | 「オンプレミス連携」「既存アプリをそのまま」「S3 のバックエンド透過」 |
3軸の判断フレームワークを先に固めれば、4パターンのうちどれが正解かを即断できる。「1 EC2 のデータ永続化」なら EBS、「複数 EC2 のファイル共有」なら EFS/FSx、「巨大オブジェクトの保存」なら S3、「オンプレとの統合」なら Storage Gateway という流れだ。
2. 3軸の判断フレームワーク
ストレージ選択の3軸
AWS ストレージは「アクセスパターン」「共有要件」「ロケーション」の3軸で分類すると、選択肢が絞り込める。
ストレージ選択フローチャート：
Step1: アクセスパターンは？
├── ブロック（OS・DB レベルのディスク）→ EBS / Instance Store
├── ファイル（ディレクトリ構造・NFS/SMB）→ EFS / FSx
└── オブジェクト（HTTP/API 経由のファイル）→ S3
Step2: 共有要件は？
├── 単一 EC2 専属 → EBS（マルチアタッチは例外）
└── 複数 EC2 で同時アクセス → EFS（Linux）/ FSx（Windows/HPC）
Step3: オンプレミス連携は？
├── なし（クラウドのみ） → 上記を選択
└── あり（オンプレと連携） → Storage Gateway| 軸 | 問い | 答えの分岐 |
|---|---|---|
| アクセスパターン | ブロック / ファイル / オブジェクト | ブロック → EBS、ファイル → EFS/FSx、オブジェクト → S3 |
| 共有要件 | 単一 EC2 か複数 EC2 か | 単一 → EBS、複数 → EFS/FSx |
| オンプレ連携 | クラウドのみか既存オンプレとの統合か | クラウドのみ → 上記、統合 → Storage Gateway |
3. パターン1：EBS — EC2 専属の高速ブロックデバイス
概要
1つの EC2 インスタンスに高速なブロックデバイスを提供するパターン。OS のルートボリューム・データベース・アプリケーションデータの永続化に使用する。EC2 と同じ AZ 内に配置され、低レイテンシ・高 IOPS を実現する。
EC2 インスタンス（単一 AZ）
├── EBS ルートボリューム（gp3 — OS）
├── EBS データボリューム（io2 — データベース）
└── EBS Snapshot → S3（バックアップ）EBS ボリュームタイプ
| タイプ | 種別 | 最大 IOPS | 最大スループット | 用途 |
|---|---|---|---|---|
| gp3 | SSD | 16,000 IOPS | 1,000 MB/s | 汎用（デフォルト推奨） |
| io2 Block Express | SSD | 256,000 IOPS | 4,000 MB/s | 高 IOPS DB（Oracle/SQL Server） |
| st1 | HDD | 500 IOPS | 500 MB/s | 大容量スループット（ビッグデータ） |
| sc1 | HDD | 250 IOPS | 250 MB/s | アーカイブ（低頻度アクセス） |
| Instance Store | NVMe | 数百万 IOPS | — | 一時データ（再起動で消える） |
試験での要件キーワード
- 「データベースのストレージを高 IOPS で」→ io2 Block Express
- 「EC2 を停止してもデータを保持したい」→ EBS（Instance Store は不可）
- 「EBS をバックアップしたい」→ EBS Snapshot（S3 に保存、増分方式）
- 「gp2 から gp3 に移行してコストを下げたい」→ EBS Elastic Volume（無停止で変更可）
4. パターン2：EFS / FSx — 複数 EC2 間のファイル共有
概要
複数の EC2 インスタンスが同一のファイルシステムに同時アクセスするパターン。CMS・コンテンツ配信・CI/CD 共有ワークスペース・機械学習の学習データ共有に頻出。Linux なら EFS（NFS v4.1）、Windows なら FSx for Windows File Server（SMB）、HPC なら FSx for Lustre を選ぶ。
複数 EC2 インスタンス（異なる AZ も可）
├── EC2-A ──┐
├── EC2-B ──┼── EFS マウントターゲット（NFS v4.1）
└── EC2-C ──┘ └── EFS ファイルシステム（リージョン全体で共有）EFS vs FSx の選択基準
| 評価項目 | EFS | FSx for Windows | FSx for Lustre | FSx for ONTAP |
|---|---|---|---|---|
| プロトコル | NFS v4.1 | SMB / NFS | Lustre（独自） | NFS / SMB / iSCSI |
| 対応 OS | Linux | Windows / Linux | Linux（HPC） | Linux / Windows |
| スケール | ペタバイト（自動拡張） | 最大 64 TB | 最大数十 PB | ペタバイト |
| 典型用途 | Web コンテンツ共有・CMS | Windows ファイルサーバー移行 | HPC・機械学習・動画編集 | NetApp 移行・マルチプロトコル |
| ストレージクラス | Standard / IA（自動階層化） | HDD / SSD | SSD / HDD | SSD / HDD |
| Active Directory 連携 | なし | あり（AD 統合） | なし | あり（AD 統合） |
試験での要件キーワード
- 「複数 AZ の Linux EC2 で同じファイルを共有したい」→ EFS
- 「Windows ファイルサーバーを AWS に移行したい（SMB）」→ FSx for Windows File Server
- 「HPC / 機械学習の学習データを高速共有したい」→ FSx for Lustre
- 「既存の NetApp ONTAP をクラウドに移行したい」→ FSx for ONTAP
5. パターン3：S3 + ライフサイクル — 大容量オブジェクト保存とコスト最適化
概要
インターネット経由で HTTP/HTTPS でアクセスするオブジェクトストレージパターン。画像・動画・ログ・バックアップ・静的 Web コンテンツなど、構造化されていない大量データの保存に最適。ライフサイクルポリシーで自動的にストレージクラスを遷移させてコストを最適化する。
データの時系列ライフサイクル：
Day 0 Day 30 Day 90 Day 365
S3 Standard → S3-IA → Glacier IR → Glacier Deep Archive
（頻繁アクセス）（低頻度アクセス）（分単位取り出し）（数時間取り出し）
$0.025/GB → $0.0125/GB → $0.004/GB → $0.00099/GBS3 ストレージクラス一覧
| ストレージクラス | 可用性 | 取り出し料金 | 用途 |
|---|---|---|---|
| S3 Standard | 99.99% | なし | 頻繁アクセス（Web コンテンツ・アプリデータ） |
| S3 Intelligent-Tiering | 99.9% | なし（監視料 $0.0025/1,000オブジェクト） | アクセスパターン不明・自動階層化 |
| S3 Standard-IA | 99.9% | あり（$0.01/GB） | 月1回以下アクセス（DR バックアップ） |
| S3 One Zone-IA | 99.5% | あり | 再作成可能なデータの低コスト保存 |
| S3 Glacier Instant Retrieval | 99.9% | あり（$0.03/GB） | 四半期に1回アクセス（ミリ秒取り出し） |
| S3 Glacier Flexible Retrieval | 99.99% | あり（$0.01/GB） | 1〜12時間取り出しOKのアーカイブ |
| S3 Glacier Deep Archive | 99.99% | あり（$0.02/GB） | 7〜10年保存規制要件（最安値） |
試験での要件キーワード
- 「静的ウェブサイトのホスティングをしたい」→ S3 静的ウェブサイトホスティング
- 「アクセス頻度に関わらずコスト最適化したい（予測不能）」→ S3 Intelligent-Tiering
- 「コンプライアンスで10年保管が必要、コスト最優先」→ S3 Glacier Deep Archive
- 「データを誤削除から守りたい」→ S3 バージョニング + Object Lock（WORM）
- 「複数リージョンへの冗長化」→ S3 クロスリージョンレプリケーション（CRR）
6. パターン4：Storage Gateway — オンプレミスとクラウドの統合
概要
既存のオンプレミスアプリケーションを変更せずに AWS ストレージと統合するパターン。オンプレミスのファイルサーバー・テープバックアップ・SAN/NAS をクラウドに透過的に接続。バックエンドを S3 / S3 Glacier / EBS にしながら、既存アプリには変更なし。
オンプレミス
├── ファイルサーバー（NFS/SMB アプリ）
│ └── S3 File Gateway ── バックエンド：S3
├── アプリ（iSCSI ブロックデバイス接続）
│ └── Volume Gateway ── バックエンド：S3 + EBS Snapshot
└── バックアップソフト（テープライブラリ）
└── Tape Gateway ── バックエンド：S3 GlacierStorage Gateway の3ゲートウェイタイプ
| 評価項目 | S3 File Gateway | Volume Gateway | Tape Gateway |
|---|---|---|---|
| プロトコル | NFS v3/v4.1, SMB | iSCSI（ブロック） | iSCSI VTL（仮想テープ） |
| バックエンド | S3（全ストレージクラス） | S3 + EBS Snapshot | S3 Glacier / Glacier Deep Archive |
| 典型用途 | オンプレのファイル共有を S3 に移行 | オンプレ DB のバックアップを AWS に | 物理テープを仮想テープで置換 |
| ローカルキャッシュ | あり（頻繁アクセスデータを高速化） | あり（Stored / Cached の2モード） | あり |
| ユースケース | データレイク取り込み・バックアップ | DR バックアップ・クラウドバースト | テープ置換・長期アーカイブ |
試験での要件キーワード
- 「既存のファイルサーバーアプリを変更せず S3 に移行したい」→ S3 File Gateway
- 「オンプレミスの DB バックアップを AWS に送り続けたい」→ Volume Gateway（Cached モード）
- 「物理テープライブラリを廃止して AWS でテープ管理したい」→ Tape Gateway
- 「オンプレのデータをリアルタイムに S3 に転送したい」→ DataSync（量が多い場合は Snowball）
7. サービス比較：5サービスの特性一覧
| 評価項目 | EBS | EFS | FSx | S3 | Storage GW |
|---|---|---|---|---|---|
| ストレージ種別 | ブロック | ファイル（NFS） | ファイル（NFS/SMB） | オブジェクト | 仮想ゲートウェイ |
| マウント方式 | EC2 に直接アタッチ | NFS マウント | NFS/SMB マウント | HTTP API | NFS/SMB/iSCSI |
| 共有アクセス | 原則単一（マルチアタッチは例外） | 複数 EC2 同時 | 複数 EC2 同時 | 無制限 | オンプレ → AWS |
| スケール | 最大 64 TiB/vol | ペタバイト（自動） | 最大数十 PB | ペタバイト（自動） | バックエンド依存 |
| 耐久性 | 99.999%（AZ 内 3 コピー） | 99.999999999% | 99.999999999% | 99.999999999% | バックエンド依存 |
| 料金モデル | プロビジョン容量課金 | 使用量課金 | プロビジョン容量課金 | 使用量課金 | データ転送 + 稼働時間 |
8. 要件キーワード早見表
SAA-C03 のストレージ問題は、問題文のキーワードから最短1秒で答えを特定できるようになるまで練習すること。
| キーワード | 正解サービス | 理由 |
|---|---|---|
| 「EC2 のデータベース用ディスク」 | EBS io2 | 高 IOPS ブロックデバイス |
| 「EC2 停止後もデータを保持」 | EBS（Instance Store は不可） | 永続ブロックストレージ |
| 「複数 EC2 で同じファイル（Linux）」 | EFS | NFS v4.1、マルチ AZ 対応 |
| 「Windows ファイルサーバー移行」 | FSx for Windows File Server | SMB / AD 統合 |
| 「HPC・機械学習の高速ファイル共有」 | FSx for Lustre | サブミリ秒レイテンシ、S3 統合 |
| 「10年保管のアーカイブ（最安値）」 | S3 Glacier Deep Archive | $0.00099/GB |
| 「アクセス頻度不明のオブジェクト」 | S3 Intelligent-Tiering | 自動階層化 |
| 「静的ウェブサイトホスティング」 | S3 静的ウェブサイト | 低コスト・高スケール |
| 「オンプレのファイルサーバーを変えず S3 へ」 | S3 File Gateway | 透過的 NFS → S3 |
| 「物理テープを廃止してクラウド保管」 | Tape Gateway | 仮想テープライブラリ |
| 「大量データを一括・定期で AWS に転送」 | DataSync | スケジュール転送 |
| 「オフラインで大量データを AWS へ（100TB+）」 | Snowball Edge | 物理デバイス転送 |
9. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：「共有ストレージ」で EBS を選ぶ
誤： 「複数 EC2 でストレージを共有したい → EBS を使う」
正： EBS は原則として1つの EC2 に専属（io1/io2 のマルチアタッチは最大 16 台、かつ同一 AZ のみ）。複数 AZ をまたぐ共有には EFS が正解。
ひっかけ2：Instance Store でデータを永続化しようとする
誤： 「高 IOPS が必要 → Instance Store を選ぶ」
正： Instance Store はEC2 終了・停止でデータが消える一時ストレージ。永続化が必要なら EBS（io2 Block Express で最大 256,000 IOPS）。Instance Store は「キャッシュ」「一時バッファ」のみ。
ひっかけ3：S3-IA をすべての低頻度データに使う
誤： 「アクセスが少ない → 全部 S3-IA にする」
正： S3-IA は最低保存期間 30 日があり、30 日以内に削除しても 30 日分の料金が発生。アクセスパターンが不明なら Intelligent-Tiering が安全。
ひっかけ4：DataSync と Storage Gateway を混同する
誤： 「オンプレアプリが継続的に使うストレージを S3 にしたい → DataSync」
正： DataSync は一括・定期転送ツール。アプリが継続的に NFS/SMB マウントして使うなら Storage Gateway（S3 File Gateway） が正解。
ひっかけ5：S3 One Zone-IA を Primary データに使う
誤： 「コストを下げたい → One Zone-IA に移行する」
正： One Zone-IA はAZ 障害でデータが失われるリスクがある。再作成不可能なデータには Standard-IA（3 AZ 冗長）を使うこと。
10. 次のアクションチェックリスト
- EBS の4ボリュームタイプ（gp3 / io2 / st1 / sc1）と用途を暗記
- EFS（Linux/NFS）と FSx for Windows（Windows/SMB）の差別化ポイントを確認
- S3 のストレージクラスを「取り出し速度」と「最低保存期間」で整理
- S3 Intelligent-Tiering が「監視料あり・取り出し料なし」であることを確認
- Storage Gateway の3タイプ（S3 File / Volume / Tape）とそれぞれのユースケースを確認
- DataSync と Storage Gateway の違い（一括転送 vs 継続統合）を説明できるか確認
- 「複数EC2で共有」「単一EC2専属」「オンプレ連携」の3シナリオで即答できるか模擬問題で確認
11. 関連記事
- SAA DR設計パターン4選（RTO/RPO・Backup & Restore・Pilot Light・Warm Standby・Multi-Site）
- SAA S3設計パターン10選
- SAA コスト最適化設計パターン4選（EC2購入オプション・S3ライフサイクル）
- SAA データレイク設計パターン
- SAA データベース選択ガイド（近日公開）