2026-08-25（火）RDS (Aurora), S3 (Glacier)
1. 【この範囲の全体像】
本範囲（第4章4-5・4-6、p.114-124）は、オンプレミスとAWSクラウドの間で、ファイルやブロックレベルのデータを安全かつシームレスに共有・同期させる「ハイブリッド接続ストレージソリューション」を扱います [p.114, p.117]。
Windows独自のセキュリティ仕様を満たす「FSx for Windows」や、HPC/機械学習向けの超高速並列ファイルシステム「FSx for Lustre」の選定基準 [p.114, p.115]、そして、オンプレミス側の既存プロトコル（NFS/SMB/iSCSI）を一切変更せずにAWSストレージ（S3/Glacier）へとデータ退避や災害復旧（DR）連携を自動化する「AWS Storage Gateway」の各種モード（ファイル/ボリューム/テープ）の使い分けが試験の重要論点です [p.117, p.118]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| Amazon FSx [p.114] | WindowsやLinux向けの業界標準ファイルシステム（SMB、NFS、Lustre等）の互換性を保ちながら、フルマネージドでAWS上にデプロイ・運用できる高性能ファイルストレージサービス。 |
| FSx for Windows ファイルサーバー [p.114] | Windows Serverベースで構築された、Active Directory（AD）認証やWindows特有のセキュリティ（NTFSアクセス許可、ファイルロック等）と完全統合されたSMBプロトコル対応ファイル共有ストレージ。 |
| FSx for Lustre [p.115] | Amazon S3と双方向でシームレスに直接同期でき、ミリ秒未満の極めて低いレイテンシーで数百万IOPSを発揮する、高性能計算（HPC）や機械学習、ビッグデータ処理用の並列ファイルシステム。 |
| AWS Storage Gateway [p.117] | オンプレミスのデータセンターに仮想マシン（VMware/Hyper-V）を配備し、標準のストレージプロトコルを介してAWS上の高耐久・格安なストレージ（S3やGlacier）に閉域網やインターネット経由でデータ同期を行うハイブリッド統合ゲートウェイ。 |
| ファイルゲートウェイ (File Gateway) [p.118] | オンプレミス側から使い慣れた「NFS（Linux）」や「SMB（Windows）」でフォルダとして共有マウントし、書き込まれたファイルを1対1で透過的にAmazon S3のオブジェクトへ非同期で自動アップロード・同期するゲートウェイ。 |
| ボリュームゲートウェイ (Volume Gateway) [p.119] | オンプレミスの物理・仮想サーバーに「iSCSI（ブロックプロトコル）」で接続し、S3を仮想ディスク領域として提供するゲートウェイ。バックアップはEBSスナップショット形式で取得されます。 |
| キャッシュ型ボリューム (Cached Volumes) [p.119] | 頻繁に読み書きされるホットデータのみをオンプレミス側のキャッシュディスク（EBSボリューム）に保持し、残りの全プライマリデータを安価なAmazon S3に格納することで、オンプレ側の物理的なディスク投資を最小限に抑えるブロックモード。 |
| 保管型ボリューム (Stored Volumes) [p.120] | 「すべての一次データ」をオンプレ側のプライベートストレージへ完全に100%保持（超低遅延で即時アクセス可能）したまま、その定期的なバックアップデータ（増分スナップショット）のみを非同期でS3へ自動レプリケーションする、DR（ディザスタリカバリ）特化のブロックモード。 |
| テープゲートウェイ (Tape Gateway) [p.121] | 既存のバックアップソフトウェアから「物理テープライブラリ（LTO等）」と誤認するiSCSI仮想テープライブラリ（VTL）としてマウントし、高価な物理テープ運用を廃して、データをS3 Glacierへ安全かつ自動的に長期アーカイブ保管するサービス。 |
3. 【試験で問われる比較ポイント】
① 高可用・共有ファイルシステム：EFS vs FSx（Windows / Lustre） [p.95, p.114-115]
「接続元のオペレーティングシステム」と「要求される処理性能（プロトコル仕様）」でマッピングを判断します [p.115]。
| 比較項目 | Amazon EFS [p.95] | FSx for Windows [p.114] | FSx for Lustre [p.115] |
|---|---|---|---|
| 対象オペレーティングシステム | Linux専用（NFSv4対応） [p.95]。 | Windows専用（SMB対応） [p.114]。 | Linux専用（Lustreクライアント） [p.115]。 |
| セキュリティ・認証統合 | IAMポリシー、Linux標準POSIXアクセス権 [p.95]。 | Microsoft Active Directory (AD) 統合、Windows NTFSアクセス制御リスト（ACL） [p.114]。 | IAMポリシー、Amazon S3バケット連携権限 [p.115]。 |
| スケーラビリティと遅延 | 格納データ量に応じて容量が自動伸縮する [p.95]。 | 明示的にプロビジョニングした容量・スループットに準拠 [p.114]。 | ペタバイト規模の超並列アクセス。ミリ秒未満の圧倒的スループット [p.115]。 |
| 主な用途と決定シグナル | Linux Webサーバー群によるコンテンツの共有マウント [p.95]。 | 「 ADドメインに参加したWindows環境で、社内の共有フォルダやドキュメントストレージを一元化したい 」 [p.114] | 「 Amazon S3にある大量の画像や生ログを、SageMakerによる機械学習モデルの訓練用として極小遅延で直接読み込みたい 」 [p.115] |
② AWS Storage Gateway 3大タイプの仕様比較 [p.118-121]
「オンプレミス側からどのようなインターフェースでマウントさせるか」によって100%切り分けます [p.118, p.119, p.121]。
| 比較項目 | ファイルゲートウェイ [p.118] | ボリュームゲートウェイ [p.119] | テープゲートウェイ [p.121] |
|---|---|---|---|
| マウント用プロトコル | NFSv3/v4（Linux向け）、SMB（Windows向け） [p.118]。 | iSCSI（ブロック接続。OSからは物理ハードディスクとしてマウントされる） [p.119]。 | iSCSI-VTL（バックアップソフトからはテープメディアに見える） [p.121]。 |
| AWS側の格納先 | Amazon S3 内の「個別ファイル（オブジェクト）」として、通常のS3ツールで検索可能 [p.118]。 | AWS S3 内の「ボリュームイメージ」。通常のS3からはファイルごとに見えない（EBSスナップショット互換） [p.119]。 | AWS S3 および Amazon S3 Glacier （アーカイブデータとして低コストに保管） [p.121]。 |
| キャッシュ型 vs 保管型の使い分け | なし（常に直近アクセスファイルをローカルキャッシュ） [p.118]。 | ・キャッシュ型: ローカル容量を節約（全データはS3） [p.119]。 ・保管型: ローカルに100%元データを保持（低遅延最優先、DR用） [p.120]。 |
なし（物理テープライブラリ運用の完全な代替） [p.121]。 |
| 主な試験要件シグナル | 「オンプレミスにあるレガシーサーバーが生成するログファイルを、コード変更なしにS3へ直接ファイルとしてアップロードしたい」 [p.118] | 「オンプレの空き容量が逼迫しており、既存のブロックストレージ（iSCSI）を段階的にクラウドの拡張容量にオフロードしたい」 [p.119] | 「既存のバックアップソフトウェア（Veritas等）のコマンドを変更せず、物理テープメディアの配送・保管コストを削減したい」 [p.121] |
4. 【ひっかけ注意ポイント】
ひっかけ①：「社内コンプライアンスを満たすため、AD環境で構築されているWindowsファイルサーバーをAWSへ移行させたい。設定工数を削減するため、Linux向けに最適化された『Amazon EFS』をWindows EC2インスタンスへ直接マウントし、各ドメインユーザーの個別アクセス制限（NTFS ACL）を設定して共有を確立する。」
- 真実: Amazon EFSはNFSv4プロトコルを用いたLinux専用設計であり、Windowsクライアントからのマウントはデフォルトで非サポートとなっています [p.95]。また、Windows特有のActive Directory認証やNTFSアクセス権（ACL）による細かなフォルダ制御も適用できません。
- 対策: Windows環境における一貫性のあるAD認証およびファイル権限管理を要求された場合は、100% 「 FSx for Windows File Server 」 のデプロイがアーキテクチャ上の唯一の正解となります [p.114, p.115]。
ひっかけ②：「オンプレミスのデータセンター内にあるファイルサーバーの物理空き容量が深刻に不足（95%消費）しているため、直ちに容量制限を解消しつつ、全ての共有データに対して極小ミリ秒の超低遅延で即時アクセス性能を維持したい。この要件を完璧に満たすため、AWSの『ボリュームゲートウェイ（保管型ボリューム：Stored Volumes）』を導入してデータをS3へ同期させる。」
- 真実: 「 保管型ボリューム（Stored Volumes） 」 は、データの一次コピー（実体）をオンプレミス側のローカルディスクに「100%丸ごと保持」し、バックグラウンドでS3へバックアップをとる仕様です [p.120]。そのため、導入したからといってオンプレミス側のディスク容量が1KBも解放されることはありません [p.120]。
- 対策: ローカルの空きディスク容量を節約しながらクラウドの無限のストレージパワーを拡張マッピングさせたい場合は、よく使うデータのみを物理キャッシュとしてローカルに置き、プライマリデータの実体はすべて安価なS3へ格納させる 「 キャッシュ型ボリューム（Cached Volumes） 」 を選定するのが正しい判断手順です [p.119]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。