週4RDS / S3

2026-08-24(月)RDS (Aurora), S3 (Glacier)

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲(第4章4-3、p.95-100)は、Linuxインスタンス向けの共有ファイルストレージサービスである 「 Amazon EFS(Elastic File System) 」 のコアアーキテクチャを扱います [p.95]。

単一のEC2からしかマウントできないEBSとは異なり [p.88]、複数の異なるアベイラビリティゾーン(AZ)にある何百台ものEC2から同時にファイルを共有マウントして読み書きできる「1対多アクセス」の仕組みを理解することが最重要です [p.95, p.96]。

試験では、システムの特性(アクセス頻度・負荷スパイク・遅延許容度)に応じて、適切なストレージクラス、パフォーマンスモード、スループットモードをコスト最適にマッピング・設計する判断力が鋭く問われます [p.97-99]。


2. 【重要キーワード・サービス一覧】

キーワード 説明
Amazon EFS (Elastic File System) [p.95] 複数のEC2インスタンスから同時にマウント可能な、容量無制限のフルマネージドな共有ファイルストレージサービス(NFSv4プロトコル準拠) [p.95]。
マウントターゲット (Mount Target) [p.96] 各AZのサブネット内に配置される、EC2からEFSへ接続するための物理的なプライベートIPアドレスを持つ接続エンドポイント [p.96]。
EFS セキュリティグループ [p.96] マウントターゲットに割り当てる仮想ファイアウォール [p.96]。アクセス元のEC2セキュリティグループから、ファイル共有に必要な 「 ポート2049(NFS) 」 のインバウンド通信のみを安全に許可・制限する [p.36, p.96]。
EFSスタンダード / EFSスタンダード-IA [p.97] 3箇所以上の複数のAZにデータを自動同期分散させて最高水準の可用性を提供する標準ストレージクラス、およびアクセス頻度の低いデータを格安で保管するインフレクエントアクセス(IA)クラス [p.96, p.97]。
EFS 1ゾーン / EFS 1ゾーン-IA [p.97] データを複数のAZではなく、1つの「単一AZ」内のみに保存・配置することで、保管コストをさらに劇的に節約できる低価格なストレージクラス [p.97]。
汎用パフォーマンスモード (General Purpose) [p.97] ほとんどのシステムで推奨されるデフォルト設定 [p.97]。低い操作遅延(低レイテンシー)に最適化されており、一般的なWebサーバーやコンテンツ共有に適合します [p.97]。
最大 I/O パフォーマンスモード (Max I/O) [p.97] 何百〜何千ものサーバーから超並列で同時アクセスするバッチ処理やビッグデータ解析に特化し、秒間の総入出力処理能力(スループット)を物理的に最大化するモード(ただしファイル操作の開始遅延は若干高くなるトレードオフがある) [p.97]。
バーストスループットモード [p.98] ファイルシステム内に保存されている実データ容量(GiB)の大きさに比例してベースライン帯域(通信速度)が自動決定される、デフォルトのスループットモード [p.98]。
プロビジョニングスループットモード [p.99] 保存されているデータ容量が小さくても、必要とする転送速度(例:100MB/秒)を固定で指定して、常時安定的かつ明示的にスループット帯域を確保できるモード [p.99]。
エラスティックスループットモード [p.99] 予測不能な突発的なアクセススパイク(急増)を伴うアプリケーションにおいて、システム側で自動的に転送帯域を自動スケールアウトさせ、実際の読み書きデータ転送量のみに応じて課金されるモード [p.99]。

3. 【試験で問われる比較ポイント】

① インフラストレージ3大サービスの決定的な違い [p.87, p.88, p.95, p.101]

「同時マウントの可否」と「最適なアクセスプロトコル」で完全に切り分けます [p.87]。

比較項目 Amazon EBS [p.88] Amazon EFS [p.95] Amazon S3 [p.101]
ストレージタイプ ブロックストレージ [p.87]。 ファイルストレージ [p.87]。 オブジェクトストレージ [p.87]。
接続可能なEC2台数 原則1対1(単一のAZ内にある特定の1台のEC2に直接アタッチ。※一部のio1/io2限定でMulti-Attachもあるが同一AZ内に閉じる) [p.88]。 1対多(共有アクセス)。複数の異なるAZに配置された、数百〜数千台のEC2から同時に並列マウント可能 [p.95, p.96]。 ネットワークを介したAPIアクセス(マウント不要。HTTPSプロトコル等で全世界のあらゆるサーバーや端末から何万台でも同時読み書き可能) [p.101, p.102]。
ファイルシステム変更 OSレベルからディスク(フォーマット)を完全に制御可能 [p.88]。 標準的なネットワークファイルシステム(NFSv4)規格 [p.95]。 ディレクトリ(フォルダ)階層を持たない、フラットなデータ保管空間 [p.102]。
試験での選択シグナル ・DBのデータディレクトリ
・標準的な単一サーバーのOS起動(ブート)領域 [p.89]
・ 「 Webサーバー(WordPress等)群で、画像ファイルなどを一元共有管理する共通フォルダ 」
・複数の開発者で共有するホームディレクトリ [p.95]
・静的コンテンツの高速配信(CloudFront連携)
・大量データの長期の安価なバックアップ・保管 [p.101, p.108]

② EFSスループットモード3つの使い分け [p.98-99]

「保存しているデータ容量(GiB)」と「要求される転送速度の安定性・スパイク特性」で切り分けます [p.99]。

スループットモード [p.98] 帯域(転送性能)の決定ルール 主なコスト構造 試験での決定的な選定シグナル(なぜ選ぶのか)
バーストスループット 保存データ容量の増加に伴い、ベースライン帯域が自動的に引き上がる [p.98]。 EFSのデータ保存容量課金のみ。 「 十分な保存容量(数TB以上)があり、データ量に応じた比例帯域のみで定常的な転送パフォーマンスを担保できるシステム 」。
プロビジョニング 保存データ容量の大小に関わらず、ユーザーが明示的に帯域幅(MB/秒)を直接指定・固定確保する [p.99]。 容量課金 + 指定した追加スループット固定料金 [p.99]。 「 保存するデータ自体の容量は数GB程度と極めて小さいが、常時100MB/秒といった非常に高いネットワーク転送速度を安定的に要求されるシステム 」 [p.99]。
エラスティック アプリケーションの処理要求に応じて、帯域が完全に自動スケーリングされる [p.99]。 容量課金 + 実際に読み書き(転送)されたデータ量(GB)に対する完全従量課金 [p.99]。 「 いつ大量のファイルアクセスが発生するか全く予測できない、突発的なスパイク負荷を持つシステム 」、またはトラフィックが断続的で使わない時間を無駄に払いたくない場合 [p.99]。

4. 【ひっかけ注意ポイント】

  • ひっかけ①:複数の異なるアベイラビリティゾーン(ap-northeast-1a、ap-northeast-1c)に配置された複数のWebサーバー(EC2)で共通のメディア素材ファイルを共有するため、インフラの維持コスト(固定費)を極限まで最適化する目的で「EFS 1ゾーン(One Zone)」クラスのファイルシステムを選択し、双方のサブネットから直接ネットワークマウントして利用する。

    • 真実: この設計は高可用性(マルチAZ)コンプライアンス要件に深刻に反する不適合アンチパターンです [p.97]。
    • 解決理由: EFS 1ゾーンクラスは、データを「単一の1つのアベイラビリティゾーン」の中にしか物理保持・複製しません [p.97]。そのため、1ゾーンに指定した特定のAZ(例:ap-northeast-1a)が落雷や災害で物理障害に遭ってダウンした場合、別AZ(ap-northeast-1c)で稼働している正常なEC2インスタンスからも、共有ファイルシステムに対するアクセスが同時に100%完全遮断・停止されてしまいます [p.97]。
    • 対策: 可用性と耐障害性を第一に要求される試験シナリオでは、必ず3箇所以上の異なるアベイラビリティゾーンにデータを自動同期分散させる 「 EFSスタンダード 」 または 「 EFSスタンダード-IA 」 をマッピングするのが鉄則です [p.96, p.97]。
  • ひっかけ②:オンプレミスのWindows Active Directoryドメインに参加している複数のWindows EC2インスタンス間で業務ドキュメントファイルをリアルタイムで安全に共有し合うため、「Amazon EFS」のデフォルト共有ファイルシステムを構築し、Windowsエクスプローラーから直接ネットワークドライブとしてマウントマッピングを確立する。

    • 真実: 物理仕様としてマウントおよび稼働させることができません [p.95, p.114]。
    • 理由: Amazon EFSはLinuxオペレーティングシステム(POSIX準拠規格)向けに専用設計されたストレージサービスであり、NFSv4によるWindowsクライアントからのマウントはデフォルトでは非サポートとなっています [p.95]。
    • 対策: Windowsサーバー群から、Windows固有の「SMB(Server Message Block)プロトコル」や「Windows NTFS」の強力なアクセス制御機能、および「Active Directory (AD)」連携を用いて一元共有ストレージを構成させたい場合は、EFSではなく、Windows専用のフルマネージドファイルシステムである 「 Amazon FSx for Windows File Server 」 を選定するのが絶対的な正解アーキテクチャとなります [p.114, p.115]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。