以下に、問題1の内容を指定の形式で整理しました。
■問題文（編集せずそのまま出力）
企業は、オンプレミスの Oracle データベースの一部を AWS に移行する必要があります。同社は、ビジネスコンプライアンス上の理由から、一部のデータベースをオンプレミスに保持することを選択しました。
オンプレミスのデータベースには空間データが含まれており、メンテナンスのために cron ジョブを実行しています。AWS からオンプレミスシステムに直接接続し、外部テーブルとしてデータをクエリする必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢（編集せずそのまま出力）
A.
Auto Scaling を有効にして、Amazon DynamoDB グローバルテーブルを作成します。AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、オンプレミスから DynamoDB にデータを移動します。AWS Lambda 関数を作成して、空間データを Amazon S3 に移動します。Amazon Athena を使用してデータをクエリします。Amazon EventBridge を使用して、メンテナンス用に DynamoDB でジョブをスケジュールします。Amazon API Gateway を使用して外部テーブルをサポートします。
B.
Amazon RDS for PostgreSQL DB インスタンスを作成します。AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、オンプレミスから DB インスタンスにデータを移動します。PostgreSQL ネイティブの空間データサポートを使用します。メンテナンスのために DB インスタンスで cron ジョブを実行します。外部テーブルのサポートのために、AWS Direct Connect を使用して DB インスタンスをオンプレミス環境に接続します。
C.
Amazon RDS for Microsoft SQL Server DB インスタンスを作成します。ネイティブレプリケーションを使用して、オンプレミスから DB インスタンスにデータを移動します。AWS Schema Conversion Tool (AWS SCT) を使用して、レプリケーション後に必要に応じて SQL Server スキーマを変更します。空間データを Amazon Redshift に移動します。システムメンテナンスにはストアドプロシージャを使用します。外部テーブルサポートのために、オンプレミスの Oracle データベースに接続する AWS Glue クローラーを作成します。
D.
Oracle データベースをホストするために Amazon EC2 インスタンスを起動します。EC2 インスタンスを Auto Scaling グループに配置します。AWS Application Migration Service を使用して、オンプレミスから EC2 インスタンスにデータを移動し、リアルタイムの双方向変更データキャプチャ (CDC) 同期を行います。Oracle ネイティブの空間データサポートを使用します。AWS Step Functions ワークフローの一部としてメンテナンスジョブを実行する AWS Lambda 関数を作成します。外部テーブルのサポート用にインターネットゲートウェイを作成します。
■問題文の要件の概要
- オンプレミスの Oracle DB の一部を AWS に移行
- コンプライアンス上、一部はオンプレミスに残す必要あり
- 空間データが含まれる
- cron ジョブでメンテナンスを実行
- AWS からオンプレミスの DB に 直接接続し外部テーブルとしてクエリしたい
■正解の選択肢と解説
- 正解：B
解説：
Amazon RDS for PostgreSQL は、PostGIS 拡張機能により空間データをネイティブにサポートします。また、pg_cron 拡張機能によりcron ジョブのスケジューリングも可能です。
- DMS + SCT を用いた Oracle からの移行にも適しており、データ移行が容易
- AWS Direct Connect を用いれば、オンプレミス環境との低レイテンシな専用線接続が可能で、外部テーブルクエリ要件にも対応
この構成は、空間データの扱い・cron 対応・オンプレとの接続という要件を最も的確に満たします。
■不正解の選択肢の理由
- A：
DynamoDB はスケーラブルな NoSQL データベースですが、空間データをネイティブにサポートしません。また、EventBridge によるスケジューリングでは、cron ベースの詳細制御には不十分です。 - C：
SQL Server は PostgreSQL に比べて空間データの機能が限定的で、PostGIS のような充実したツールがありません。また、Glue クローラーはクエリではなくインベントリの構築用であり、外部テーブルとしてのリアルタイムクエリには適しません。 - D：
EC2 上に Oracle を構築することで自由度は得られますが、管理負荷が非常に高く、スケーラビリティや信頼性の点で RDS より劣ります。さらに、インターネットゲートウェイ経由での接続は Direct Connect よりも遅延・セキュリティ面で劣るため、企業向け構成には不適。
■SAP試験で押さえておくべきポイント
- PostgreSQL + PostGIS = 空間データ処理の最適解
- pg_cron 拡張でスケジュールジョブ（cron）も実現可能
- DMS + SCTの併用は移行ベストプラクティス
- AWS Direct Connect はオンプレとの高信頼・低レイテンシな接続手段
- EC2 ベースの DB 構築は管理コスト高。RDS の利用が基本方針
次の問題も準備できましたら、どうぞお送りください。
以下に、問題2の内容を指定の形式で整理しました。
■問題文（編集せずそのまま出力）
科学会社は、Amazon S3 バケットからのテキストと画像データを処理する必要があります。このデータは、深宇宙ミッションのタイムクリティカルなフェーズで、複数のレーダーステーションから収集されたものです。レーダーステーションは、データをソース S3 バケットにアップロードします。データの前には、レーダーステーションの識別番号が付けられています。この会社は、2 つ目のアカウントに保存先の S3 バケットを作成しました。コンプライアンスの目標を達成するには、データをソース S3 バケットから宛先 S3 バケットにコピーする必要があります。レプリケーションは、ソース S3 バケット内のすべてのオブジェクトをカバーする S3 レプリケーションルールを使用して行われます。ある特定のレーダーステーションが、最も正確なデータを持っていると認識されます。このレーダーステーションでのデータレプリケーションは、レーダーステーションがオブジェクトをソース S3 バケットにアップロードした後、30 分以内に完了することを監視する必要があります。
これらの要件を満たす最適な方法を選択してください。
■選択肢（編集せずそのまま出力）
A.
AWS DataSync エージェントを設定して、プレフィックス付きデータをソース S3 バケットから宛先 S3 バケットにレプリケートします。タスクで使用可能なすべての帯域幅を使用するように選択し、タスクが TRANSFERRING ステータスになっていることを確認するためにタスクを監視します。Amazon EventBridge (Amazon CloudWatch Events) ルールを作成して、このステータスが変更された場合にアラートをトリガーします。
B.
ソース S3 バケットで Amazon S3 Transfer Acceleration を有効にして、最も正確なデータを持つレーダーステーションが新しいエンドポイントを使用するように構成します。S3 宛先バケットの TotalRequestLatency メトリクスを監視します。Amazon EventBridge (Amazon CloudWatch Events) ルールを作成して、このステータスが変化した場合にアラートをトリガーします。
C.
2 つ目のアカウントで、最も正確なデータを持つレーダーステーションからデータを受け取るために、別の S3 バケットを作成します。この新しい S3 バケットに新しいレプリケーションルールを設定して、レプリケーションを他のレーダーステーションから分離します。宛先への最大レプリケーション時間を監視します。Amazon EventBridge (Amazon CloudWatch Events) ルールを作成して、時間が目的のしきい値を超えたときにアラートをトリガーします。
D.
最も正確なデータを持つレーダーステーションのプレフィックスを使用するキーをフィルタリングする新しい S3 レプリケーションルールをソース S3 バケットに作成します。S3 Replication Time Control (S3 RTC) を有効にします。宛先への最大レプリケーション時間を監視します。Amazon EventBridge (Amazon CloudWatch Events) ルールを作成して、時間が目的のしきい値を超えたときにアラートをトリガーします。
■問題文の要件の概要
- データはレーダーステーションごとに S3 にアップロードされる（プレフィックスあり）
- ソースバケットから別アカウントの宛先バケットにレプリケーションする必要がある
- 特に「最も正確なレーダーステーション」のデータは30分以内のレプリケーション完了を保証＋監視が必要
- コンプライアンス対応として明確なレプリケーション時間管理が必要
■正解の選択肢と解説
- 正解：D
解説：
Amazon S3 Replication Time Control（S3 RTC）は、S3 バケット間のオブジェクトレプリケーションを99.99% の確率で 15 分以内に完了することを保証する機能です。
- 特定のレーダーステーションを識別するプレフィックスにフィルターをかけたレプリケーションルールを作成
- S3 RTC をそのルールに適用することで、30分以内に必ずレプリケートされるという要件を満たす
- S3 RTC は レプリケーション遅延のメトリクスとイベント通知（OperationMissedThreshold など）を提供し、EventBridge 連携で監視とアラートが可能
この構成が唯一、時間制約付きのレプリケーションを保証できる方法です。
■不正解の選択肢の理由
- A：
AWS DataSync はファイルベースのデータ転送サービスであり、S3 レプリケーションとは別物。
プレフィックス指定やステータス監視は可能でも、レプリケーション完了時間の SLA 保証はなし。S3 RTC の代替にはならない。 - B：
S3 Transfer Acceleration は、データのアップロードを高速化する仕組みであり、レプリケーションやその監視には無関係。
TotalRequestLatency は API 呼び出しの遅延であり、オブジェクトのレプリケーション完了時間は測定できない。 - C：
別の S3 バケットに新しいレプリケーションルールを設定しても、S3 RTC を有効化しなければ、時間保証は得られない。
設計として冗長な上、要件である「30分以内の完了保証」に対応できない。
■SAP試験で押さえておくべきポイント
- S3 Replication Time Control (S3 RTC)：
- 15分以内にレプリケーションを完了する SLA
- コンポーネント：レプリケーションルール＋フィルター＋RTC有効化＋監視（メトリクス/イベント）
- EventBridge 連携でアラートが可能（MissedThreshold など）
- プレフィックス指定ルールの活用：
- 特定ソースのデータを分離してレプリケーション制御可能
- 他の選択肢との違い：
- DataSyncやTransfer Accelerationは「データ転送支援」ではあるが、S3 レプリケーションの保証や監視機能を持たない
次の問題もあれば、どうぞお送りください。分析を続けてお手伝いします。
以下に、問題3の内容を指定の形式で整理しました。
■問題文（編集せずそのまま出力）
ソリューションアーキテクトは、ある企業の Amazon EC2 インスタンスと Amazon Elastic Block Store (Amazon EBS) ボリュームを評価し、企業がリソースをどれだけ効率的に使用しているかを判断する必要があります。この企業は、アクティブ / パッシブセットアップでデータベースクラスターをホストするために、多数の大容量で高メモリの Amazon EC2 インスタンスを使用しています。組織は、データベースにアクセスするアプリケーションが、これらの EC2 インスタンスをどのように使用するかについてのパターンを検出できていません。
ソリューションアーキテクトは、環境の分析を行い、その結果に応じて適切なアクションを実行する必要があります。
費用対効果の観点から、これらの基準に最も適した方法を選択してください。
■選択肢（編集せずそのまま出力）
A.
EC2 インスタンスとその EBS ボリュームの Amazon CloudWatch 詳細モニタリングを有効にします。メトリクスに基づくダッシュボードを作成し、確認します。使用パターンを特定します。メトリクスのピークに基づいて EC2 インスタンスを適切なサイズに変更します。
B.
AWS エンタープライズサポートプランにサインアップします。AWS Trusted Advisor を有効にします。12 時間待ちます。Trusted Advisor の推奨事項を確認し、指示されたとおりに EC2 インスタンスのサイズを適切に設定します。
C.
AWS Systems Manager OpsCenter を使用してダッシュボードを作成します。EC2 インスタンスとその EBS ボリュームに関連する Amazon CloudWatch メトリクスのための視覚化を構成します。定期的にダッシュボードを確認し、使用パターンを特定します。メトリクスのピークに基づいて EC2 インスタンスを適切なサイズに変更します。
D.
各 EC2 インスタンスに Amazon CloudWatch エージェントをインストールします。AWS Compute Optimizer を有効にして、少なくとも 12 時間実行させます。Compute Optimizer の推奨事項を確認し、指示されたとおりに EC2 インスタンスのサイズを適切に設定します。
■問題文の要件の概要
- 多数の大容量・高メモリ EC2 インスタンスを使用中（アクティブ/パッシブ構成）
- 実際の利用パターンが不明
- 使用状況を把握し、費用対効果を高めるためにリソースを最適化したい
- 自動的・定量的な評価と推奨が求められている
■正解の選択肢と解説
- 正解：D
解説：
AWS Compute Optimizer は、EC2 インスタンス、EBS ボリューム、Lambda、Auto Scaling Group に対して、過去のメトリクス（最大 14 日分）を用いて機械学習による最適なリソースサイズを推奨します。
特徴：
- CloudWatch メトリクスと連携し、パフォーマンスに基づいた自動分析
- 過剰または不足なプロビジョニングを検出
- 推奨には、リソースのコスト削減額やパフォーマンス影響も含まれる
- 少なくとも 12 時間のモニタリングが必要（最長14日まで分析）
企業が「使用パターンを把握できていない」という前提に対し、Compute Optimizer による自動推奨が最も費用対効果に優れた対応です。
■不正解の選択肢の理由
- A：
CloudWatch の詳細モニタリングでメトリクスは取得可能ですが、ユーザー自身が手動で分析・判断しなければならず、コスト最適化までに工数がかかる。また、Compute Optimizer のようなサイズ推奨は提供されない。 - B：
Trusted Advisor はエンタープライズサポート限定機能であり、コスト最適化の提案はあるが抽象的。
Compute Optimizer のような実際のリソース使用に基づく明確なインスタンスサイズ提案は得られない。 - C：
OpsCenter は運用上のインシデント管理用であり、モニタリング・可視化は可能でもサイズ推奨はしない。
また、CloudWatch の視覚化と重複しており、目的に対して冗長な構成。
■SAP試験で押さえておくべきポイント
- AWS Compute Optimizer
- EC2、EBS、Lambda の使用パターンを分析し、サイズやタイプの最適化を提案
- 少なくとも 12時間以上稼働データが必要
- CloudWatch メトリクスを自動取得し、推奨事項はコンソール or API で確認可能
- 手動 vs 自動最適化の違い
- CloudWatch＋ダッシュボード＝手動分析 → 時間と誤判断のリスクあり
- Compute Optimizer＝機械学習ベースで自動提案
- Trusted Advisor
- サポートプランに依存
- セキュリティ・コスト最適化・制限超過などの汎用アドバイスが中心
次の問題もあれば、どうぞお送りください。引き続き分析いたします。
以下に、AWS Certified Solutions Architect – Professional（SAP）試験の「問題4」に対する整理を所定のフォーマットで記載します。
■問題文（編集せずそのまま出力）
企業は、ユーザーがドキュメントをアップロードできる電子ドキュメント管理システムを開発しています。アプリケーションスタックは完全にサーバーレスであり、eu-central-1 リージョンの Amazon Web Services でホストされています。このシステムは、Amazon S3 オリジンを持つ Amazon CloudFront ディストリビューションを介して配信されるウェブアプリケーションで構成されています。
ウェブアプリケーションは、Amazon API Gateway のリージョン API エンドポイントとのインターフェースになっています。API Gateway API は、AWS Lambda サービスを呼び出します。AWS Lambda サービスは、メタデータを Amazon Aurora Serverless v1 のデータベースに保存し、コンテンツを S3 バケットに保存します。
事業は好調で、主要なクライアントとの概念実証を完了したばかりです。企業は、ヨーロッパ以外のレイテンシーを改善する必要があります。
これらの基準を満たす方法の組み合わせを選択してください。(2 つ選択)
■選択肢（編集せずそのまま出力）
A. Lambda 関数と Aurora Serverless のデータベースの間に Amazon RDS Proxy を追加します。
B. S3 バケットで S3 Transfer Acceleration を有効にします。ウェブアプリケーションが Transfer Acceleration の署名付き URL を使用していることを確認します。
C. API Gateway の リージョン API エンドポイントをエッジ最適化 API エンドポイントに変更します。
D. AWS Global Accelerator でアクセラレータを作成します。アクセラレーターを CloudFront ディストリビューションにアタッチします。
E. 世界中に散らばる他の 2 つの拠点にスタック全体をプロビジョニングします。Aurora Serverless クラスターで Aurora Global Database を使用します。
■問題文の要件の概要
- 完全サーバーレス構成（CloudFront + API Gateway + Lambda + Aurora Serverless + S3）
- リージョンは
eu-central-1 - ドキュメントアップロードアプリケーション
- ヨーロッパ以外からのユーザーのレイテンシー改善が必要
- 対象は S3 へのアップロードや API 呼び出しと推定される
■正解の選択肢と解説
- 正解: B, C
B. S3 Transfer Acceleration を有効にし、署名付きURLを使用
- S3 Transfer Acceleration により、世界中のユーザーがS3バケットに高速でアップロードできる。
- CloudFrontのエッジロケーションを経由して Amazon S3 にデータを送信することで、アップロードのパフォーマンスが向上。
- 特に地理的に遠いクライアントからのアップロードに有効。
C. API Gateway をエッジ最適化 API に変更
- 「エッジ最適化 API エンドポイント」を使うと、リクエストは最寄りの CloudFront エッジロケーションで受信される。
- これにより API のレスポンスレイテンシーが大幅に短縮される。
- グローバルユーザー向けのベストプラクティス構成。
■不正解の選択肢の理由
A. RDS Proxy の追加
- RDS Proxy は Lambda と RDS 間の接続効率向上には役立つが、地理的なレイテンシー改善には関係がない。
- 今回の主眼は「ヨーロッパ外のレイテンシー改善」であり対象外。
D. Global Accelerator を CloudFront にアタッチ
- Global Accelerator はTCP/UDPベースのアプリケーション向けのレイテンシー最適化サービス。
- CloudFront 自体がエッジロケーションを使って HTTP 配信を最適化しているため、重複かつ非推奨な構成。
E. 他拠点にスタック全体をプロビジョニング + Aurora Global Database
- スタック全体の複製はコストと運用の複雑性が増す。
- Aurora Serverless は Aurora Global Database をサポートしていない（試験ではこの知識が重要）。
- 要件に対して過剰な対応。
■SAP試験で押さえておくべきポイント
- S3 Transfer Acceleration はグローバルクライアントからのアップロードレイテンシーを改善できる。
- エッジ最適化 API Gateway はグローバルユーザー向けの REST API 最適構成。
- Aurora Serverless v1 は Aurora Global Database をサポートしていない。
- Global Accelerator は CloudFront 用ではない（主に ALB/NLB などに適用）。
- 地理的なレイテンシー問題にはエッジサービスと転送最適化機能が第一選択。
続けて他の問題も整理できますので、お送りください。
以下に、問題5の整理を所定のフォーマットで記載します。
■問題文（編集せずそのまま出力）
ある企業は、e コマースのウェブサイトに単一の AWS リージョンを使用しています。このウェブサイトには、Application Load Balancer (ALB) の背後にある複数の Amazon EC2 インスタンスで実行されるウェブアプリケーションが含まれています。ウェブサイトには、Amazon DynamoDB のテーブルも含まれています。Amazon Route 53 のカスタムドメイン名は ALB にリンクされています。同社は、AWS Certificate Manager (ACM) で SSL/TLS 証明書を作成し、ALB に証明書をアタッチしました。同社は、設計の一部としてコンテンツ配信ネットワークを使用していません。
同社は、災害対策、将来の成長計画、ユーザーへのアクセス時間の改善を提供するために、アプリケーションスタック全体を 2 番目のリージョンに複製したいと考えています。ソリューションアーキテクトは、これらの目標を達成し、管理オーバーヘッドを最小限に抑えるソリューションを実装する必要があります。
これらの要件を満たすために、ソリューションアーキテクトが実行する必要がある手順の組み合わせを選択してください。(3 つ選択)
■選択肢（編集せずそのまま出力）
A. 現在のインフラストラクチャ設計用の AWS CloudFormation テンプレートを作成します。リージョンを含む重要なシステム値のパラメータを使用します。CloudFormation テンプレートを使用して、2 番目のリージョンに新しいインフラストラクチャを作成します。
B. DynamoDB Streams を有効にして、既存の DynamoDB テーブルの設定を更新します。2 番目のリージョンを追加して、グローバルテーブルを作成します。
C. アプリケーションの Route 53 ホストゾーンレコードを、レイテンシーに基づくルーティングを使用するように更新します。各リージョンの ALB にトラフィックを送信します。
D. AWS マネジメントコンソールを使用して、最初のリージョンで既存のインフラストラクチャ設計を文書化し、2 番目のリージョンで新しいインフラストラクチャを作成します。
E. アプリケーションの Route 53 ホストゾーンレコードを更新して、加重ルーティングを使用します。各リージョンの ALB にトラフィックの 50% を送信します。
F. 新しい DynamoDB テーブルを作成します。新しいテーブルに対して DynamoDB Streams を有効にします。2 番目のリージョンを追加して、グローバルテーブルを作成します。既存の DynamoDB テーブルから新しいテーブルに、1 回限りの操作としてデータをコピーします。
■問題文の要件の概要
- 単一リージョン構成から2リージョンへスケール
- 災害対策・成長・低レイテンシーを目的とした全スタックの複製
- 管理オーバーヘッド最小化が必要
- CloudFrontなどCDNは現時点で使っていない
■正解の選択肢と解説
- 正解: A, B, C
A. CloudFormation テンプレートによるインフラ複製
- インフラの再現性と自動化を実現。
- リージョン可変のパラメータを使えば、マルチリージョン展開が簡単。
- IaC（Infrastructure as Code） による運用の効率化。
B. DynamoDB グローバルテーブルの構成
- DynamoDB Streams を有効にすることで、複数リージョンに自動レプリケーション。
- レプリカ同士がマルチアクティブで読み書き可能になる。
- 災害対策と高速なローカル読み書きを両立。
C. Route 53 のレイテンシールーティング
- 各リージョンの ALB に最も近いユーザーからトラフィックをルーティング。
- レスポンス時間を短縮し、ユーザー体験向上。
- フェイルオーバーにも対応可能な柔軟なルーティング構成。
■不正解の選択肢の理由
D. コンソール手動操作による複製
- ヒューマンエラーが発生しやすい
- 再現性がなく、スケールにも不向き → 管理オーバーヘッドが増大
E. 加重ルーティング（50%）
- トラフィックを均等に送るだけでレイテンシーは考慮されない
- 災害対策やユーザー体験の改善には不十分
F. 新規DynamoDB +手動データコピー
- 手作業でのデータ移行が必要 → 整合性・リアルタイム性に欠ける
- グローバルテーブルとしては不完全
■SAP試験で押さえておくべきポイント
- CloudFormation によるスタック複製は、再現性・一貫性・管理性の観点から非常に重要。
- DynamoDB グローバルテーブルはマルチリージョン環境での可用性確保に有効。
- Route 53のレイテンシールーティングは、ユーザー体験を改善する標準構成。
- 加重ルーティングはA/Bテストや段階的移行向けであり、本設問の要件には不適。
- マネジメントコンソールでの手動作業は非推奨。自動化が基本。
次の問題も対応可能ですので、引き続きお送りください。
以下、ご要望の形式に沿って問題6を整理・解説いたします。
■問題文（編集せずそのまま出力）
ある企業は、AWS Control Tower を使用して、AWS 上のマルチアカウント構造を調整しています。同社は AWS Organizations、AWS Config、および AWS Trusted Advisor を使用しています。同社には、開発者が AWS でテストするために使用する開発アカウント用の特定の OU があります。同社には数百人の開発者がおり、各開発者は個別の開発アカウントを持っています。
同社は、これらの開発アカウントのコストを最適化したいと考えています。これらのアカウントの Amazon EC2 インスタンスと Amazon RDS インスタンスは、バースト可能である必要があります。同社は、関連性のない他のサービスの使用を禁止したいと考えています。
これらの要件を満たす推奨する方法を選択してください。
■選択肢（編集せずそのまま出力）
A. AWS Control Tower でカスタムな検出コントロール (ガードレール) を作成します。バースト可能なインスタンスのみのデプロイを許可し、関連性のないサービスを許可しないように、コントロール (ガードレール) を構成します。コントロール (ガードレール) を開発 OU に適用します。
B. AWS Control Tower でカスタムな予防コントロール (ガードレール) を作成します。バースト可能なインスタンスのみのデプロイを許可し、関連性のないサービスを許可しないように、コントロール (ガードレール) を構成します。コントロール (ガードレール) を開発 OU に適用します。
C. AWS Organizations でカスタム SCP を作成して、バースト可能なインスタンスのみのデプロイを許可し、関連性のないサービスを許可しないようにします。SCP を開発 OU に適用します。
D. AWS Control Tower アカウントに AWS Config ルールを作成します。バースト可能なインスタンスのみのデプロイを許可し、関連性のないサービスを許可しないように AWS Config ルールを構成します。AWS CloudFormation StackSets を使用して、AWS Config ルールを開発 OU にデプロイします。
■問題文の要件の概要
- AWS Control Tower 管理下にあるマルチアカウント構成
- 各開発者に開発用アカウントが存在（数百アカウント）
- コスト最適化：EC2とRDSはバースト可能インスタンスタイプのみを許可したい
- 不要なサービスの利用を防止したい（例：コストに寄与しない他のAWSサービス）
- 一元的かつスケーラブルに制御したい
■正解の選択肢と解説
- 正解：B
AWS Control Tower の「カスタム予防コントロール（ガードレール）」を使うことで、開発OUにおけるリソースのデプロイ前にルール違反を阻止できます。
バースト可能インスタンス（例：T3/T4）以外の使用や、不要なサービスへのアクセスを事前にブロックすることで、ガバナンスとコスト最適化を両立できます。
Control Tower ガードレールは、OU単位に一元的に適用でき、数百のアカウントへの統制も容易です。
■不正解の選択肢の理由
- A：検出コントロールは事後検知のみであり、違反を防げない
- 検出コントロールは違反を「通知」するのみで、リソース作成は阻止できません。
- 目的は予防（使わせないこと）であり、事後報告では不十分です。
- C：SCP（Service Control Policy）は粒度が粗く、柔軟性に欠ける
- SCPでは「サービス単位」の制御は可能ですが、インスタンスタイプ（例：t3/t4など）までは制御不可。
- また、Control Towerの運用モデルから逸脱し、可視性や整合性が低下します。
- D：AWS Configは監査目的であり、事後検出に限られる
- AWS Configは準拠状況を評価・通知するが、リソース作成を事前にブロックできません。
- 目的の「コスト最適化と禁止」は未然防止が必要です。
■SAP試験で押さえておくべきポイント
- AWS Control Tower での **カスタムガードレール（予防／検出）**の違いを理解：
- 予防ガードレール：事前に違反リソースの作成を防止
- 検出ガードレール：事後に違反を検知・通知
- Control TowerはOU単位でガバナンス管理が可能であり、マルチアカウント構成に最適
- SCPはサービス単位の制御に限定されるため、リソース細粒度制御には向かない
- AWS Configは評価ツールであり、強制力はない
次の問題があれば、引き続きどうぞ。
以下、問題7を指定の形式で整理・解説いたします。
■問題文（編集せずそのまま出力）
ある企業が最近、Amazon WorkSpaces の概念実証を無事完了しました。ソリューションアーキテクトは、2 つの AWS リージョン間でソリューションを高可用性にする必要があります。Amazon WorkSpaces はフェイルオーバーリージョンにデプロイされ、ホストゾーンは Amazon Route 53 にデプロイされています。
ソリューションの可用性を高める最適な方法を選択してください。
■選択肢（編集せずそのまま出力）
A. プライマリリージョンに接続エイリアスを作成します。接続エイリアスをフェイルオーバーリージョンのディレクトリに関連付けます。Route 53 フェイルオーバールーティングポリシーを作成します。[ターゲットのヘルスを評価] を [はい] に設定します。
B. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53 複数値回答ルーティングポリシーを作成します。
C. プライマリリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53 加重ルーティングポリシーを作成します。
D. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスを各リージョンのディレクトリに関連付けます。Route 53 フェイルオーバールーティングポリシーを作成します。[ターゲットのヘルスを評価] を [はい] に設定します。
■問題文の要件の概要
- Amazon WorkSpaces を使った VDI 環境を2つのリージョンで構築
- 高可用性（HA）構成が必要
- Route 53 を使った DNS ベースのルーティング
- 障害時に自動でフェイルオーバーさせたい
■正解の選択肢と解説
- 正解：D
プライマリとフェイルオーバーの両リージョンに接続エイリアスを作成し、それぞれのディレクトリに関連付けることで、ユーザーがどちらのリージョンにも接続できる環境を構築します。
さらに、Route 53 のフェイルオーバールーティングポリシー + ターゲットのヘルスチェックを使うことで、プライマリリージョンがダウンした場合に自動的にフェイルオーバーリージョンへトラフィックが切り替わり、高可用性を実現します。
■不正解の選択肢の理由
- A：
- 接続エイリアスがプライマリリージョンにしか存在しない状態で、フェイルオーバーリージョンのディレクトリに関連付けようとする構成は矛盾しており、意図通り機能しません。
- B：
- 複数値回答ルーティングではヘルスチェックを用いたフェイルオーバー切替が行えません。
- プライマリリージョンのディレクトリにしか関連付けていないため、フェイルオーバー構成として不完全です。
- C：
- 加重ルーティングはトラフィックの分散用途であり、フェイルオーバーには向きません。
- プライマリしか使えない構成で、高可用性を実現できません。
■SAP試験で押さえておくべきポイント
- Amazon WorkSpacesのクロスリージョンリダイレクトでは、接続エイリアスを各リージョンに作成・関連付けが必要。
- Route 53 において フェイルオーバールーティングポリシー と ターゲットのヘルスチェックを組み合わせることで、自動フェイルオーバーを実現できる。
- 複数値回答や加重ルーティングはフェイルオーバーには不向きである点を明確に区別すること。
- SAP試験では、高可用性アーキテクチャの設計において、DNSベースのルーティング戦略とサービス特有の制約（今回で言えばWorkSpacesのエイリアス）を正しく理解しておく必要があります。
次の問題も対応可能です。引き続きどうぞ。
