質問#11 ある会社に、Amazon Aurora データベースを使用する、Amazon EC2 インスタンス上で動作するアプリケーションがある。EC2 インスタンスは、ルにローカルに保存されているユーザー名とパスワードを使用してデータベースに接続する。同社は、クレデンシャル管理の運用オーバーヘッドを最小限に抑えたいと考えている。この目標を達成するために、ソリューションアーキテクトは何をすべきか。
A.AWS Secrets Manager を使用する。自動ローテーションをオンにする。
B.AWS Systems Manager Parameter Store を使う。自動ローテーションをオンにする。
C.AWS Key Management Service（AWS KMS）の暗号化キーで暗号化されたオブジェクトを格納する Amazon S3 バケットを作成する。クレデンシャルルを S3 バケットに移行する。アプリケーションを S3 バケットに向ける。
D.各 EC2 インスタンスに暗号化された Amazon Elastic Block Store（Amazon EBS）ボリュームを作成する。新しい EBS ボリュームを各 EC2 インスタンスにアタッチする。クレデンシャル・ルを新しい EBS ボリュームに移行する。アプリケーションを新しい EBS ボリュームに向ける。
正解 A

解説：

本問の要件は「EC2 上アプリが Aurora に接続」「資格情報（ユーザー名/パスワード）がローカルファイル」「クレデンシャル管理の運用オーバーヘッドを最小化」。

このとき一番の運用負荷は以下になります。

• パスワードの 安全な保管

• 定期ローテーション

• ローテーション後の アプリ側反映

• 漏えい時の 即時差し替え

Secrets Manager はまさにここを「マネージドで」のサービスなため、Aurora（RDS系）向けに 自動ローテーションまで用意されています。
結果として、ローカルファイル管理より運用が容易になります。

質問#12 あるグローバル企業が、アプリケーションロードバランサー（ALB）の背後にある Amazon EC2 インスタンス上で Web アプリケーションをホストしている。Web アプリケーションには静的データと動的データがある。静的データは Amazon S3 バケットに格納されている。同社は、静的データと動的データのパフォーマンスを向上させ、レイテンシーを削減したいと考えている。
同社は、Amazon Route 53 に登録された独自のドメイン名を使用している。これらの要件を満たすために、ソリューションアーキテクトは何をすべきか？
A.S3 バケットと ALB をオリジンとする Amazon CloudFront ディストリビューションを作成する。trac を CloudFront ディストリビューションにルーティングするように Route 53 を設定する。
B.ALB をオリジンとする Amazon CloudFront ディストリビューションを作成する。S3 バケットをエンドポイントとする AWS Global Accelerator 標準アクセラレータを作成する。 通信（トラフィック）を CloudFront ディストリビューションにルーティングするようにRoute 53 を設定する。
C.S3 バケットをオリジンとする Amazon CloudFront ディストリビューションを作成する。ALB と CloudFront ディストリビューションをエンドポイントとする AWS Global Accelerator 標準アクセラレータを作成する。アクセラレータの DNS 名を指すカスタムドメイン名を作成する。カスタムドメイン名を Web アプリケーションのエンドポイントとして使用する。
D.ALB をオリジンとする Amazon CloudFront ディストリビューションを作成する。エンドポイントとして S3 バケットを持つ AWS Global Accelerator 標準アクセラレータを作成する。2 つのドメイン名を作成する。1 つのドメイン名を動的コンテンツ用のCloudFront DNS 名に向ける。もう片方のドメイン名を静的コンテンツ用のアクセラレータ DNS 名に向ける。ドメイン名を Web アプリケーションのエンドポイントとして使用する。
正解 A

解説：

問題の要件整理（試験で見るべきポイント）

• グローバル企業（＝地理的に分散したユーザー）

• Web アプリは ALB 配下の EC2 で動作（＝動的コンテンツ）

• 静的コンテンツは S3 に格納

• 静的・動的の両方でパフォーマンス向上とレイテンシー削減

• 独自ドメインは Route 53 で管理

この条件から導かれる設計方針は明確です。

エッジロケーションでキャッシュ可能なものはキャッシュし、
キャッシュできない動的リクエストも最寄りエッジまで高速に届ける

この役割を同時に満たすサービスが Amazon CloudFront です。

正解：A の構成と理由

A の内容（整理）

• S3 バケットと ALB の両方をオリジンとする
  Amazon CloudFront ディストリビューションを作成

• Route 53 で独自ドメインを CloudFront の DNS 名に向ける

なぜこの構成が最適なのか

① 静的コンテンツの高速化（S3 + CloudFront）

• S3 単体はリージョン依存だが、CloudFront を前段に置くことで

  • 静的データを 世界中のエッジロケーションにキャッシュ

  • ユーザーは 最寄りエッジから即時配信

• レイテンシーと S3 へのリクエスト数を同時に削減できる

② 動的コンテンツの高速化（ALB + CloudFront）

• 動的コンテンツは基本キャッシュされないが、

  • ユーザー → CloudFront エッジまでは最短経路

  • エッジ → ALB は AWS グローバルバックボーン経由

• 結果として、インターネット全区間を通るより低遅延

③ 単一ドメインで静的・動的を統合できる

• CloudFront は パスベースルーティングが可能
  例：

  • /static/* → S3

  • /api/* → ALB

• ユーザーから見たエンドポイントは 1つのドメイン

• アプリケーション側の変更が最小

④ 構成がシンプルで運用負荷が低い

• Route 53 → CloudFront →（S3 / ALB）

• Global Accelerator などの追加コンポーネント不要

• 教科書的かつ AWS 推奨の Web 配信アーキテクチャ

質問#13 ある企業が AWS インフラストラクチャのメンテナンスを毎月実施している。これらの保守作業中に、複数の AWS リージョンにまたがる Amazon RDS for MySQL データベースの認証情報をローテーションする必要がある。運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションはどれか。
A.AWS Secrets Manager に認証情報をシークレットとして保存する。必要なリージョンに複数リージョンのシークレットレプリケーションを使用する。Secrets Manager を構成して、シークレットをスケジュールでローテーションする。
B.AWS Systems Manager でセキュアな文字列パラメータを作成し、認証情報をシークレットとして保存する。必要なリージョンに複数リージョンのシークレットレプリケーションを使用する。シークレットをスケジュールでローテーションするようにSystems Manager を設定する。
C.サーバー側暗号化（SSE）が有効な Amazon S3 バケットに認証情報を格納する。Amazon EventBridge（Amazon CloudWatch Events）を使用して、AWS Lambda 関数を呼び出し、認証情報をローテーションする。
D.AWS Key Management Service（AWS KMS）のマルチリージョンカスタマーマネージドキーを使用して、認証情報をシークレットとして暗号化する。Amazon DynamoDB グローバルテーブルに秘密を保存する。AWS Lambda 関数を使用して、DynamoDB から秘密を取得する。RDS API を使用してシークレットをローテーションする。
正解 A

解説：

要件整理

• 毎月の保守作業で RDS for MySQL の認証情報をローテーション

• 複数リージョンにまたがる RDS

• 運用オーバーヘッド最小

ここで重要なのは「認証情報の保管」と「定期ローテーション」を、なるべく マネージド機能で片付けることです。

正解：A の理由

1) Secrets Manager は “DB認証情報のローテーション” をマネージドで提供

Secrets Manager は、RDS（MySQL含む）向けに 自動ローテーション機構を持っています。
スケジュール設定をするだけで、Lambda 等の自前実装を最小化（あるいは不要に近く）できます。

2) マルチリージョンの要件は「シークレットの複数リージョンレプリケーション」で素直に満たせる

Secrets Manager の 複数リージョンレプリケーションを使えば、必要なリージョンへシークレットを配布できます。
これにより、各リージョンのアプリケーションや運用が 最寄りリージョンのシークレットを参照でき、設計が単純になります。

3) スケジュールローテーションで “毎月の保守” に合わせられる

「毎月実施」が要件に明記されているため、Secrets Manager の ローテーションスケジュールがそのまま適合します。

まとめ

• マネージドなシークレット管理 + 自動ローテーション

• マルチリージョン配布

• スケジュール運用

この3点を最もシンプルに満たすのが Secrets Manager + マルチリージョンレプリケーション + スケジュールローテーションなので、A が正解です。

質問#14 ある企業が、アプリケーションロードバランサーの背後にある Amazon EC2 インスタンスで e コマースアプリケーションを実行している。インスタンスは複数のアベイラビリティゾーンにまたがる Amazon EC2 Auto Scaling グループで稼働している。Auto Scaling グループは、CPU 使用率メトリクスに基づいてスケールする。e コマースアプリケーションは、大規模な EC2インスタンスでホストされている MySQL 8.0 データベースにトランザクションデータを保存する。アプリケーションの負荷が増加すると、データベースのパフォーマンスはすぐに低下する。このアプリケーションは、書き込みトランザクションよりも読み取りリクエストを多く処理している。同社は、高可用性を維持しながら、予測不可能な読み取りワークロードの需要に合わせてデータベースを自動的に拡張するソリューションを求めている。これらの要件を満たすソリューションはどれか。
A.リーダーおよびコンピュート機能に単一ノードの Amazon Redshift を使用する。
B.異なるアベイラビリティゾーンにリーダーインスタンスを追加するように Amazon RDS を設定する。
C.Amazon Aurora を Multi-AZ デプロイメントで使用する。Aurora Replicas で Aurora Auto Scaling を設定する。
D.EC2 スポットインスタンスで Memcached 用の Amazon ElastiCache を使用する。
正解 C

要件の核心

• 現状：EC2 上の MySQL 8.0（単一インスタンス）にトランザクション保存

• 負荷増加で DB 性能がすぐ低下

• 読み取りが書き込みより多い（Read-heavy）

• 予測不可能な読み取り需要に合わせて “自動で拡張”

• 高可用性（HA）も維持

この条件は、「書き込みは1系統を維持しつつ、読み取りを水平スケールする」設計が最適です。
AWS でそれを マネージドかつ自動で実現する代表が Aurora + Aurora Replicas Auto Scaling です。

正解：C の理由（Aurora + Auto Scaling）

1) 読み取りをレプリカで水平スケールできる

Aurora は Aurora Replicas を追加して読み取りを分散できます。
アプリ側は Reader エンドポイントを使うことで、読み取りが自動的に複数レプリカに振り分けられます。

2) “予測不可能な読み取り需要” に対して自動拡張できる

Aurora には **Aurora Auto Scaling（Aurora Replicas の増減）**があり、

• 読み取り負荷（例：レプリカのCPU、接続数など）に応じて

• レプリカ台数を自動で増減
  できます。

3) 高可用性を満たしやすい

Aurora の **Multi-AZ（クラスタ構成）**は、ストレージが複数AZに分散され、障害時の復旧性が高いです。
さらにレプリカを別AZに配置することで、読み取り面の冗長性も上がります。

質問#15 ある企業が最近 AWS に移行し、本番用 VPC に出入りするトレックを保護するソリューションを導入したいと考えている。同社はオンプレミスのデータセンターに検査サーバーを持っていた。この検査サーバーは、trac の ow 検査や trac のリタリングといった特殊な処理を実行していた。同社は同じ機能を AWS クラウドでも実現したいと考えている。これらの要件を満たすソリューションはどれか。
A.Amazon GuardDuty を本番 VPC の trac 検査と trac ltering に使用する。
B.Trac Mirroring を使って、本番 VPC から trac をミラーリングし、trac 検査と ltering を行う。
C.AWS Network Firewall を使って、本番 VPC の trac 検査と trac ltering に必要なルールを作成する。
D.AWS Firewall Manager を使用して、本番 VPC 用の trac 検査と trac ltering に必要なルールを作成する。
正解 C

解説：

問題の本質（何を求められているか）

• 本番 VPC に出入りするトラフィックを保護したい

• 以前は オンプレミスの検査サーバーで

  • トラフィックのフロー検査（ディープなパケット検査的な処理）

  • トラフィックフィルタリング
    を実施していた

• AWS 上でも 同等の機能（＝インライン検査＋遮断） を実現したい

つまりこれは、

VPC の境界でトラフィックを検査し、ルールに基づいて許可・拒否したい

という ネットワークレベルのファイアウォール要件です。

正解：C の理由

AWS Network Firewall

AWS Network Firewall は、まさにこの用途のために用意された マネージド型のネットワークファイアウォールサービスです。

Network Firewall でできること

• VPC に インライン配置される（トラフィック経路上で検査）

• 以下を フルマネージドで実現可能

  • ステートフル／ステートレスルール

  • 5タプル（IP/ポート/プロトコル）フィルタリング

  • シグネチャベース検査（Suricata 互換ルール）

• 受信・送信トラフィックの 検査・遮断を即時に実行

👉
オンプレでやっていた「検査サーバー」を
AWS では Network Firewall に置き換える、という非常に素直な対応関係です。

質問#16 ある企業が AWS 上でデータレイクをホストしている。データレイクは Amazon S3 と Amazon RDS for PostgreSQL のデータで構成されている。同社は、データの可視化を提供し、データレイク内のすべてのデータソースを含むレポートソリューションを必要としている。会社の経営陣だけが、すべてのビジュアライゼーションにフルアクセスできる必要がある。それ以外の社員は限定的なアクセスしかできないようにする必要がある。これらの要件を満たすソリューションはどれか。
A.Amazon QuickSight で分析を作成する。すべてのデータソースを接続し、新しいデータセットを作成する。ダッシュボードを発行してデータを可視化する。ダッシュボードを適切な IAM ロールで共有する。
B.Amazon QuickSight で分析を作成する。すべてのデータソースを接続し、新しいデータセットを作成する。ダッシュボードを発行してデータを可視化する。ダッシュボードを適切なユーザーとグループで共有する。
C.Amazon S3 に AWS Glue テーブルとクローラーを作成する。AWS Glue の抽出、変換、ロード（ETL）ジョブを作成し、レポートを作成する。レポートを Amazon S3 にパブリッシュする。S3 バケットポリシーを使用して、レポートへのアクセスを制限する。
D.Amazon S3 に AWS Glue テーブルとクローラーを作成する。Amazon Athena Federated Query を使用して、Amazon RDS for PostgreSQL 内のデータにアクセスする。Amazon Athena を使用してレポートを作成する。Amazon S3 にレポートをパブリッシュする。S3 バケットポリシーを使用してレポートへのアクセスを制限する。
正解 B

解説：

要件の整理

• データレイク：Amazon S3 + Amazon RDS for PostgreSQL

• 目的：データの可視化（レポート/ダッシュボード）

• アクセス制御：

  • 経営陣：すべてのビジュアライゼーションにフルアクセス

  • 一般社員：限定的なアクセス

• 前提：レポート基盤として運用負荷を抑えたい

この条件から、BI（可視化）に最適化されたマネージドサービスで、ユーザー/グループ単位の権限管理ができるものが最短です。

正解：B の理由

1) 可視化基盤として最適

Amazon QuickSight は AWS のマネージド BI サービスで、

• S3（Athena 経由）や RDS（PostgreSQL）に直接接続

• ダッシュボード/分析をGUIで作成

• 運用（サーバ管理、スケール）不要

2) ユーザー/グループでのアクセス制御が要件に合致

QuickSight は

• ユーザーおよびグループ単位で

  • ダッシュボードの閲覧

  • 分析の編集

  • データセットへのアクセス
    を細かく制御できます。

→ 経営陣グループにはフル権限、一般社員グループには閲覧限定、などが自然に実装可能。

3) “すべてのデータソースを含むレポート”を一元提供

QuickSight のデータセットで S3 と RDS のデータをまとめ、
単一ダッシュボードとして配信できるため、要件を素直に満たします。

質問#17 ある企業が新しいビジネスアプリケーションを導入しようとしている。このアプリケーションは 2 台の Amazon EC2 インスタンスで実行され、ドキュメントストレージとして Amazon S3 バケットを使用する。ソリューションアーキテクトは、EC2インスタンスが S3 バケットにアクセスできることを保証する必要がある。この要件を満たすために、ソリューションアーキテクトは何をすべきか。
A.S3 バケットへのアクセスを許可する IAM ロールを作成する。そのロールを EC2 インスタンスにアタッチする。
B.S3 バケットへのアクセスを許可する IAM ポリシーを作成する。そのポリシーを EC2 インスタンスにアタッチする。
C.S3 バケットへのアクセスを許可する IAM グループを作成する。そのグループを EC2 インスタンスにアタッチする。
D.S3 バケットへのアクセスを許可する IAM ユーザーを作成する。そのユーザーアカウントを EC2 インスタンスにアタッチする。
正解 A

要件の整理

• 新しいビジネスアプリケーション

• 2台の Amazon EC2 インスタンスで実行

• Amazon S3 バケットをドキュメントストレージとして使用

• EC2 から 安全かつ確実に S3 にアクセスさせたい

この条件では、AWS が推奨する **「インスタンスに一時的な認証情報を安全に付与する方法」**を使うのが正解です。

正解：A の理由

IAM ロールを EC2 にアタッチするのがベストプラクティス

Amazon EC2 から
Amazon S3 にアクセスさせる場合、

IAM ロール（インスタンスプロファイル）を EC2 にアタッチする

のが AWS の公式ベストプラクティスです。

IAM ロールを使うメリット

• アクセスキーを EC2 内に保存しない

• 認証情報は 自動的にローテーションされる（一時クレデンシャル）

• 複数インスタンスに 同じ権限を簡単に付与

• セキュリティ・運用の両面で最小オーバーヘッド

典型構成

1. S3 へのアクセスを許可する IAM ロールを作成

2. そのロールに IAM ポリシー（S3 Read/Write など）をアタッチ

3. ロールを EC2 インスタンスにアタッチ

質問#18 あるアプリケーション開発チームが、大きな画像を小さな圧縮画像に変換するマイクロサービスを設計している。ユーザーが Web インターフェイスから画像をアップロードすると、マイクロサービスは Amazon S3 バケットに画像を保存し、AWS Lambda 関数で画像を処理して圧縮し、圧縮された状態の画像を別の S3 バケットに保存する必要がある。ソリューションアーキテクトは、耐久性のあるステートレスコンポーネントを使用して、画像を自動的に処理するソリューションを設計する必要がある。これらの要件を満たすアクションの組み合わせはどれか。(2 つ選べ)
A.Amazon Simple Queue Service（Amazon SQS）キューを作成する。画像が S3 バケットにアップロードされると、SQS キューに通知を送るように S3 バケットを設定する。
B.Amazon Simple Queue Service (Amazon SQS)キューを呼び出し元として使用するように、Lambda 関数を設定する。SQS メッセージが正常に処理されたら、キュー内のメッセージを削除する。
C. S3 バケットに新しいアップロードがないか監視するよう、Lambda 関数を設定する。アップロードされた画像が検出されたら、その le 名をメモリ上のテキスト le に書き込み、そのテキスト le を使って処理された画像を追跡する。
D.Amazon Simple Queue Service（Amazon SQS）のキューを監視するために、Amazon EC2 インスタンスを起動する。アイテムがキューに追加されたら、EC2 インスタンスのテキスト le に le 名を記録し、Lambda 関数を呼び出す。
E. Amazon EventBridge（Amazon CloudWatch Events）イベントを設定して、S3 バケットを監視する。画像がアップロードされたら、Amazon Ample Notication Service (Amazon SNS)トピックに、アプリケーション所有者のメールアドレスを含むアラートを送信し、さらに処理する。
正解 AB

解説：

目標（設問の意図）

• 画像アップロード → S3に保存

• 自動で処理（圧縮） → Lambda

• 圧縮後 → 別S3バケットに保存

• 耐久性がある / ステートレス / 自動処理が必須

この条件だと、典型アーキテクチャは

S3（入力） → イベント通知 → SQS（耐久バッファ） → Lambda（ステートレス処理） → S3（出力）

になります。SQS を挟むことで、突発的な大量アップロードや一時的エラーでも取りこぼしにくく、再試行もしやすいです。

選ぶべき 2 つ

A. S3 アップロード時に SQS に通知

• S3 のイベント通知で **「オブジェクト作成」**をトリガーにできる

• 通知先を SQS にすることで、イベント（処理対象）を 耐久的に蓄積できる
  → “耐久性のあるステートレスコンポーネント”の要件に合致

B. Lambda のイベントソースを SQS にする（処理後に削除）

• Lambda は SQS をイベントソースにして自動起動できる

• 正常処理後にメッセージ削除（＝少なくとも1回配信の整合性モデルに沿った標準動作）
  → ステートレス処理＋自動処理に合致

質問#19 ある会社に、AWS 上にデプロイされた 3 層の Web アプリケーションがある。Web サーバーは VPC 内のパブリックサブネットにデプロイされている。アプリケーションサーバーとデータベースサーバーは、同じ VPC 内のプライベートサブネットにデプロイされている。同社は、AWS Marketplace からサードパーティ製の仮想リウォールアプライアンスを検査用 VPC にデプロイしている。このアプライアンスには、IP パケットを受け入れる IP インターフェイスが設定されている。ソリューションアーキテクトは、ウェブアプリケーションをアプライアンスと統合し、アプリケーションへのすべてのトラックを、トラックがウェブサーバーに到達する前に検査する必要がある。運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションはどれか。
A.アプリケーションの VPC のパブリックサブネットにネットワークロードバランサーを作成し、パケット検査のために trac をアプライアンスにルーティングする。
B.アプリケーションの VPC のパブリック・サブネットにアプリケーション・ロード・バランサーを作成し、パケット検査のために trac をアプライアンスにルーティングする。
C.検査用 VPC にトランジットゲートウェイをデプロイし、トランジットゲートウェイを経由して受信パケットをルーティングするようにルートテーブルを構成する。
D.検査 VPC にゲートウェイロードバランサーを配備する。受信パケットを受信し、アプライアンスにパケットを転送するゲートウェイロードバランサーエンドポイントを作成する。
正解 D

解説：

問題の状況（何を実現したいか）

• 3層Webアプリ（Webはパブリック、App/DBはプライベート）

• 別に 検査用VPC があり、そこに **AWS Marketplace の仮想ファイアウォール（サードパーティ製アプライアンス）**を配置済み

• そのアプライアンスは IPパケットを受けるインターフェイスを持つ（＝L3/L4の透過的検査が前提）

• 要件：Webサーバーに到達する前に “すべてのトラフィック” を必ず検査したい

• さらに 運用オーバーヘッド最小

この条件は AWS 的に「サードパーティのインライン検査アプライアンスを、VPCトラフィック経路に透明に挿入したい」という話です。
この用途のために用意されているのが **Gateway Load Balancer（GWLB）**です。

正解：D の理由

1) “インライン検査アプライアンス”のための専用機能

Gateway Load Balancer は、仮想ファイアウォール/IDS/IPS などの アプライアンス群へ

• トラフィックを 透過的に転送

• 複数台に 負荷分散

• 障害時の 冗長化
  をマネージドで実現します。

2) GWLBe（GWLB Endpoint）で “ルートに刺すだけ” でよい

D の手順のポイントはここです：

• 検査 VPC に GWLB

• アプリVPC側（または受信側のサブネット）に GWLB Endpoint（GWLBe）

• ルートテーブルで「検査させたい経路」を GWLBe に向ける

つまり、ルーティングで強制的に検査経路に流せるので、
「Webサーバに到達する前に必ず検査」を満たしやすいです。

3) 運用オーバーヘッドが最小

• ALB/NLB を“無理やり”検査用途に使うより設計が素直

• アプライアンスの台数増減や冗長化も GWLB 側で吸収しやすい
  → “最小の運用負荷”という設問のキーワードに合致します。

質問#20 ある企業が、大量の本番データを同じ AWS リージョンのテスト環境にクローンする能力を向上させたいと考えている。
データは Amazon Elastic Block Store（Amazon EBS）ボリューム上の Amazon EC2 インスタンスに保存されている。クローンされたデータへの変更は、本番環境に影響を及ぼしてはならない。このデータにアクセスするソフトウェアには、常に高い I/O 性能が求められる。ソリューションアーキテクトは、本番データをテスト環境にクローンするのに必要な時間を最小限に抑える必要がある。これらの要件を満たすソリューションはどれか。
A.本番用 EBS ボリュームの EBS スナップショットを作成する。スナップショットをテスト環境の EC2 インスタンスストアボリュームにリストアする。
B.本番環境の EBS ボリュームに EBS マルチアタッチ機能を使用するように設定する。本番用 EBS ボリュームの EBS スナップショットを作成する。本番環境の EBS ボリュームをテスト環境の EC2 インスタンスにアタッチする。
C.本番用 EBS ボリュームの EBS スナップショットを作成する。新しい EBS ボリュームを作成して初期化する。新しい EBS ボリュームをテスト環境の EC2 インスタンスにアタッチしてから、本番用 EBS スナップショットからボリュームをリストアする。
D.本番用 EBS ボリュームの EBS スナップショットを作成する。EBS スナップショットの EBS 高速スナップショット復元機能をオンにする。スナップショットを新しい EBS ボリュームにリストアする。新しい EBS ボリュームをテスト環境の EC2 インスタンスにアタッチする。
正解 D

解説：

要件のポイント整理

• 本番データ（EBS 上）を 同一リージョンのテスト環境にクローンしたい

• テスト側の変更は 本番に影響しない（＝別ボリュームが必要）

• テスト側ソフトウェアは 常に高い I/O 性能が必要

• クローンに必要な時間を 最小化したい

ここでの肝は 2 つです。

1. EBS スナップショットからの復元は“初回アクセスが遅い”問題がある

2. 「常に高い I/O」「時間最小化」なら、その遅さを消す仕組みが必要

それを満たすのが **Fast Snapshot Restore（高速スナップショット復元 / FSR）**です。

正解：D の理由（FSR が要件に直撃）

1) スナップショットからの復元を “即高性能” にできる

通常、スナップショットから作った EBS ボリュームは Lazy Loading で、

• 初回アクセスするブロックを S3（スナップショット格納先）から読み出すため

• 最初の読み取りが遅くなる（初期ウォームアップが必要）

FSR を有効化すると、

• スナップショットから作るボリュームのブロックが 事前に準備され

• 初回アクセスからフル性能に近い I/Oを出せます

→ 「常に高いI/O性能が必要」を満たし、
→ さらに「ウォームアップ待ち」が減るので「時間最小化」にも効きます。

2) 本番への影響なし

FSR で復元するのは 新しい EBS ボリュームなので、テスト側で変更しても本番に影響しません。