Uncategorized

#45

 

以下の形式で整理しました。

■問題文

ある会社は多くの AWS アカウントを持っており、AWS Organizations を使用してすべてのアカウントを管理しています。ソリューションアーキテクトは、同社が複数のアカウントで共通のネットワークを共有するために使用できるソリューションを実装する必要があります。

同社のインフラストラクチャチームは、VPC を持つ専用のインフラストラクチャアカウントがあります。インフラストラクチャチームは、このアカウントを使用してネットワークを管理する必要があります。個々のアカウントは、独自のネットワークを管理する能力を持つことはできません。ただし、個々のアカウントはサブネット内に AWS リソースを作成できる必要があります。

これらの要件を満たす最適な方法の組み合わせを選択してください。 (2 つ選択)

■選択肢

A. インフラストラクチャのアカウントで Transit Gateway を作成します。
B. AWS Organizations の管理アカウントからリソース共有を有効にします。
C. AWS Organizations の組織内の各 AWS アカウントに VPC を作成します。インフラストラクチャのアカウントの VPC と同じ CIDR 範囲とサブネットを共有するように VPC を構成します。個々のアカウントの VPC をインフラストラクチャのアカウントの VPC とピアリングします。
D. インフラストラクチャのアカウントの AWS Resource Access Manager (RAM) でリソース共有を作成します。共有ネットワークを使用する特定の AWS Organizations OU を選択します。リソース共有に関連付ける各サブネットを選択します。
E. インフラストラクチャのアカウントの AWS Resource Access Manager (RAM) でリソース共有を作成します。共有ネットワークを使用する特定の AWS Organizations OU を選択します。リソース共有に関連付けるために、各プレフィックスリストを選択します。

■問題文の要件の概要

  • 複数 AWS アカウント間で共通ネットワークを共有する必要がある。
  • 中央集約型ネットワーク管理（インフラ専用アカウントで管理）。
  • 各アカウントはネットワーク管理不可だが、共有サブネット内にリソースを作成できる必要あり。

■正解の選択肢と解説

  • B. AWS Organizations の管理アカウントからリソース共有を有効にする
    • Organizations で「組織レベルの共有」を有効化すると、組織内のメンバーアカウントが AWS Resource Access Manager (RAM) の共有リソースを利用可能になる。これにより、サブネット等の共有リソースを OU やアカウント単位で配布でき、各アカウントは独自ネットワークを持たずに利用可能となる。
  • D. インフラストラクチャアカウントの AWS Resource Access Manager (RAM) でサブネット共有を設定する
    • RAM でインフラアカウントのサブネットを対象 OU に共有設定することで、各アカウントは共有 VPC 内にリソースを配置できる。ネットワーク設定はインフラチームが集中管理でき、ガバナンスとスケーラビリティを両立できる。

■不正解の選択肢の理由

  • A. Transit Gateway
    • Transit Gateway はルーティングを集約するだけで、サブネットそのものを共有できない。各アカウントが自分で VPC 管理する必要があり、中央管理要件を満たさない。
  • C. 各アカウントに同じ CIDR の VPC を作成しピアリング
    • CIDR 重複で作成不可、または異なる CIDR でもピアリングは 1:1 接続でスケールしにくく、ルートテーブル管理も分散してしまい要件に反する。
  • E. プレフィックスリスト共有
    • プレフィックスリストはルーティング設定用で、サブネット共有ではない。リソース配置権限は得られず、中央集約型ネットワークの要件を満たさない。

■SAP試験で押さえておくべきポイント

  • VPC共有は AWS RAM と Organizations の組み合わせで実現する。
  • Organizations での「組織レベルの共有有効化」が前提条件。
  • Transit Gateway はルーティング集約用であり、VPC/Subnet共有機能はない。
  • VPC ピアリングはスケーラビリティと管理集中に不向き。
  • プレフィックスリスト共有はネットワークアクセス制御用であり、リソース共有とは別物。

この形式であれば、他の問題も同じフォーマットで整理できます。
次のHTML問題も同じように変換しますか？

以下の形式で整理しました。

■問題文

会社のウェブアプリケーションは、Amazon S3 バケットに写真や動画を安全にアップロードします。コンテンツのアップロードは、認証されたユーザーのみに許可する必要があります。アプリケーションは、ブラウザーを介してオブジェクトをアップロードするために署名付きURL を生成します。多数のユーザーは、100 MB を超えるオブジェクトのアップロードにかかる時間が遅いと報告しています。

アップロードのパフォーマンスを改善し、認証されたユーザーのみにコンテンツのアップロードを許可するための最適な方法を選択してください。

■選択肢

A. エッジ最適化 API エンドポイントを S3 プロキシのリソースに接続し、Amazon API Gateway のエンドポイントタイプをエッジ最適化 API エンドポイントに設定します。Folder/Item リソースに対するメソッドとして、Amazon S3 バケットにオブジェクトをアップロードする PutObject を公開します。COGNITO_USER_POOLS タイプのオーソライザーを使用して API Gateway を保護します。ブラウザを介して、署名付きURL ではなく API Gateway を使用してオブジェクトをアップロードします。

B. リージョン API エンドポイントを S3 プロキシのリソースに接続し、Amazon API Gateway のエンドポイントタイプをリージョン API エンドポイントに設定します。Folder/Item リソースに対するメソッドとして、Amazon S3 バケットにオブジェクトをアップロードする PutObject を公開します。AWS Lambda オーソライザーを使用して API Gateway を保護します。ブラウザを介して、署名付きURL ではなく API Gateway を使用してオブジェクトをアップロードします。

C. S3 バケットで S3 Transfer Acceleration エンドポイントを有効にします。エンドポイントを使用して、署名付きURL を生成します。S3 マルチパートアップロード API を使用して、ブラウザを介してこの URL にオブジェクトをアップロードします。

D. Amazon CloudFront ディストリビューションを作成して、オリジンサーバーに Amazon S3 バケットを設定します。PUT および POST メソッドを処理するように、CloudFront を構成します。CloudFront オリジンを更新して、オリジンアクセスコントロール (OAC) を使用します。OAC ユーザーにバケットポリシーの S3 PutObject 権限を付与します。ブラウザを介して CloudFront ディストリビューションを使用してオブジェクトをアップロードします。

■問題文の要件の概要

  • 認証されたユーザーのみ S3 にアップロード可能であること
  • ブラウザ経由のアップロード
  • 大容量（100MB超）のファイルアップロード速度改善
  • アプリケーションは署名付きURLを利用

■正解の選択肢と解説

  • C. S3 Transfer Acceleration + マルチパートアップロード
    • S3 Transfer Acceleration は CloudFront エッジロケーション経由で最寄りから AWS バックボーンへデータを流すため、長距離転送のレイテンシーとパケットロスを軽減できる。
    • マルチパートアップロード によりファイルを分割・並列送信し、失敗時は一部のみ再送可能で大容量ファイルのアップロード効率が向上する。
    • 署名付きURL を使うことで有効期限付きアクセス制御が可能になり、認証済みユーザーのみアップロードを許可できる。

■不正解の選択肢の理由

  • A / B. API Gateway経由のアップロード
    • REST API は 10MB のペイロード制限があるため、100MB超のファイルは通過できない。
    • API Gateway を経由するとレイテンシー増加・コスト増加の要因にもなる。
  • D. CloudFront 経由で PUT/POST
    • CloudFront は配信最適化が目的であり、大容量ファイルのアップロード最適化には向かない。
    • マルチパートアップロード非対応で経路が冗長になるため、速度改善は期待できない。

■SAP試験で押さえておくべきポイント

  • 大容量S3アップロードの高速化は S3 Transfer Acceleration と マルチパートアップロード の組み合わせがベストプラクティス。
  • Transfer Accelerationはアップロード・ダウンロード両方に有効だが、距離のあるクライアントに特に効果的。
  • マルチパートアップロードは100MB以上のファイルで推奨、5GB超は必須。
  • API Gateway 経由の直接アップロードはペイロード制限（10MB）を理解して回避する必要がある。
  • CloudFrontは配信向けであり、アップロードの最適化用途では使わない。

この形式であとも続けられます。
もしよければ次の問題も同じフォーマットで変換できますが、このまま第3問も処理しますか？

■問題文

ある企業が、アプリケーションをオンプレミスから AWS に移行しました。アプリケーションのフロントエンドは静的ウェブサイトで、Application Load Balancer (ALB) の背後にある 2 つの Amazon EC2 インスタンスで実行されます。アプリケーションのバックエンドは Python アプリケーションで、別の ALB の背後にある 3 つの EC2 インスタンスで実行されます。EC2 インスタンスは、アプリケーションのピーク時の使用に対するオンプレミスの仕様を満たすようにサイズ設定された、大規模な汎用オンデマンドインスタンスです。

このアプリケーションは、毎月平均して数十万件のリクエストを処理します。しかし、このアプリケーションは主にランチタイムに使用され、それ以外の時間帯は最小限のトラフィックしか受信しません。ソリューションアーキテクトは、アプリケーションの可用性に悪影響を与えることなく、アプリケーションのインフラストラクチャ コストを最適化する必要があります。

これらの要件を満たす最適な手順の組み合わせを選択してください。(2 つ選択)

■選択肢

A. すべての EC2 インスタンスを、既存の EC2 インスタンスと同じ数のコアを持つコンピュート最適化インスタンスに変更します。
B. アプリケーションのフロントエンドを、Amazon S3 上でホストされている静的ウェブサイトに移動します。
C. AWS Elastic Beanstalk を使用して、アプリケーションのフロントエンドをデプロイします。ノードには同じインスタンスタイプを使用します。
D. すべてのバックエンド EC2 インスタンスをスポットインスタンスに変更します。
E. バックエンド Python アプリケーションを、既存の EC2 インスタンスと同じ数のコアを持つバースト可能な汎用 EC2 インスタンスにデプロイします。

■問題文の要件の概要

  • 主な利用時間帯はランチタイム、それ以外は低負荷
  • 静的コンテンツ（フロントエンド）と動的処理（バックエンド）が分離
  • 現在は大規模なオンデマンドインスタンスを常時稼働しておりコストが高い
  • 可用性を維持したままインフラコストを削減する必要がある

■正解の選択肢と解説

  • B. フロントエンドを Amazon S3 静的ウェブサイトホスティングに移行
    • 静的コンテンツを EC2 や ALB から S3 に移行することで、常時稼働コストを削減しつつ高可用性を確保できる。
    • 必要に応じて CloudFront を併用し、グローバルキャッシュとレイテンシー低減を実現可能。
  • E. バックエンドをバースト可能汎用インスタンスに変更
    • T3/T4g などのバースト可能インスタンスは、低負荷時のコストを削減し、ピーク時には CPU クレジットを利用して性能を発揮できる。
    • Auto Scaling と組み合わせることで負荷変動に応じた柔軟なスケーリングが可能。

■不正解の選択肢の理由

  • A. コンピュート最適化インスタンス
    • CPU 集約型向けで、今回のように負荷変動が大きいケースではコスト削減効果が薄い。
  • C. Elastic Beanstalk でフロントエンドをデプロイ
    • 静的サイトにも EC2/ALB が必要になり、S3 静的ホスティングよりもコストが高くなる。
  • D. 全バックエンドをスポットインスタンス化
    • スポットは中断リスクがあり、ピーク時の可用性を保証できないため不適切。

■SAP試験で押さえておくべきポイント

  • 静的コンテンツは S3 + CloudFront がコスト・可用性・スケーラビリティの面で最適解。
  • 負荷変動のあるワークロードは バースト可能インスタンス や Auto Scaling を活用してコスト最適化。
  • スポットインスタンスは可用性要件の低いワークロードでのみ使用する。
  • インスタンスタイプ選定は、ワークロード特性（負荷パターン、CPU使用率）と課金モデルを考慮する。

この形式であれば、第4問以降も同じ形でまとめられます。
次の問題もこのフォーマットで整理しますか？

以下の形式で整理しました。

■問題文
ある企業は、サードパーティの SaaS アプリケーションを使用したいと考えています。サードパーティの SaaS アプリケーションは、いくつかの API 呼び出しによって消費されます。サードパーティの SaaS アプリケーションは、VPC 内の AWS で実行されます。

同社は、VPC 内からサードパーティの SaaS アプリケーションを利用する予定です。同社には、インターネットを経由しないプライベート接続の使用を義務付ける社内セキュリティポリシーがあります。会社の VPC 内で実行されるリソースは、同社の VPC 外からのアクセスを許可されません。すべてのアクセス許可は、最小特権の原則に準拠する必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢
A. AWS PrivateLink インターフェース VPC エンドポイントを作成します。このエンドポイントを、サードパーティの SaaS アプリケーションが提供するエンドポイントサービスに接続します。エンドポイントへのアクセスを制限するセキュリティグループを作成します。セキュリティグループをエンドポイントに関連付けます。

B. サードパーティの SaaS アプリケーションと会社の VPC の間に AWS Site-to-Site VPN 接続を作成します。VPN トンネル間のアクセスを制限するためにネットワーク ACL を構成します。

C. サードパーティの SaaS アプリケーションと会社の VPC の間に VPC ピアリング接続を作成します。ピアリング接続に必要なルートを追加して、ルートテーブルを更新します。

D. AWS PrivateLink エンドポイントサービスを作成します。サードパーティの SaaS プロバイダーに、このエンドポイントサービス用のインターフェイス VPC エンドポイントを作成するように依頼します。サード パーティの SaaS プロバイダーの特定のアカウントに、エンドポイントサービスのアクセス許可を付与します。

■問題文の要件の概要

  • インターネット非経由でサードパーティ SaaS へ接続する必要がある
  • 接続は企業 VPC 内からのみ発生し、外部からのアクセスは不可
  • 最小特権の原則に基づくアクセス制御が必要
  • SaaS は AWS 上の別 VPC に存在

■正解の選択肢と解説
正解：A
AWS PrivateLink のインターフェース VPC エンドポイントを作成し、SaaS 側が提供するエンドポイントサービスに接続する構成。

  • AWS のプライベートネットワーク内で完結するため、インターネットを経由しない
  • セキュリティグループでアクセスを最小限に絞ることで最小特権を実現
  • インターフェース VPC エンドポイントは一方向（利用者→提供者）のみの通信経路となり、外部から企業 VPC 内リソースへ直接アクセスされない

■不正解の選択肢の理由

  • B（Site-to-Site VPN）
    　VPN はインターネット経由で IPsec トンネルを張るため、「インターネット非経由」の要件を満たさない。ネットワーク ACL 制限を加えても経路自体はパブリック網を通る。
  • C（VPC ピアリング）
    　双方向のルーティングが可能になり、SaaS 側から企業 VPC への到達性が生じる。サービス単位でのアクセス制御が難しく、最小特権の原則を完全に満たせない。
  • D（自社でエンドポイントサービス作成）
    　本来は SaaS 側が提供者、企業側が利用者となるべき。構成が逆転しており、要件を満たさない。

■SAP試験で押さえておくべきポイント

  1. AWS PrivateLink はインターネット非経由で安全に別 VPC のサービスへアクセス可能
  2. インターフェース VPC エンドポイントは一方向通信で、外部からのアクセスを許可しない構造
  3. Site-to-Site VPN は暗号化されるがインターネットを経由するため「プライベート接続」要件を満たさない
  4. VPC ピアリングは双方向接続で、CIDR 全体に対するルートが有効になる点に注意
  5. PrivateLink では「提供者（エンドポイントサービス作成側）」と「利用者（VPC エンドポイント作成側）」の役割を間違えないこと

この形式で次の問題も整理できますが、このまま同じフォーマットで続けますか？

以下の形式で整理しました。

■問題文
企業は、AWS アカウントからの Amazon CloudWatch Logs を 1 つの中央ログアカウントに集約する必要があります。収集されたログは、作成した AWS リージョンに残す必要があります。その後、中央ログアカウントはログを処理し、ログを標準出力フォーマットに正規化し、さらに処理するために出力ログをセキュリティツールにストリーミングします。

ソリューションアーキテクトは、取り込む必要がある大量のログデータを処理できるソリューションを設計する必要があります。通常の営業時間外では、通常の営業時間中よりもログ記録が少なくなります。ロギングソリューションは、予想される負荷に合わせて拡張する必要があります。ソリューションアーキテクトは、AWS Control Tower 設計を使用してマルチアカウントのログプロセスを処理することにしました。

要件を満たす最適な手順の組み合わせを選択してください。(3 つ選択)

■選択肢
A. 中央ログアカウントに宛先の Amazon Kinesis Data Streams を作成します。

B. 中央ログアカウントに宛先の Amazon Simple Queue Service (Amazon SQS) キューを作成します。

C. Amazon CloudWatch Logs に Amazon Kinesis Data Streams にデータを追加するアクセス許可を与える IAM ロールを作成します。信頼ポリシーを作成します。IAM ロールで信頼ポリシーを指定します。各メンバーアカウントで、データを Kinesis Data Streams に送信するために、各ロググループのサブスクリプションフィルターを作成します。

D. Amazon Simple Queue Service (Amazon SQS) キューにデータを追加するアクセス許可を Amazon CloudWatch Logs に与える IAM ロールを作成します。信頼ポリシーを作成します。IAM ロールで信頼ポリシーを指定します。各メンバーアカウントで、SQS キューにデータを送信するために、すべてのロググループに対して単一のサブスクリプションフィルターを作成します。

E. AWS Lambda 関数を作成します。中央ログアカウントのログを正規化し、セキュリティツールにログを書き込むように Lambda 関数をプログラムします。

F. AWS Lambda 関数を作成します。メンバーアカウントのログを正規化し、セキュリティツールにログを書き込むように Lambda 関数をプログラムします。

■問題文の要件の概要

  • 複数 AWS アカウントからの CloudWatch Logs を中央アカウントに集約
  • ログはリージョン内に保持する必要あり
  • 大量データを処理でき、負荷変動に応じてスケール可能な構成
  • ログを標準フォーマットに正規化し、セキュリティツールへストリーミング
  • AWS Control Tower を利用したマルチアカウント管理

■正解の選択肢と解説
正解：A, C, E

  • A
    　Kinesis Data Streams を中央ログアカウントに作成することで、大量ログを高スループットかつリアルタイムに取り込み可能。シャードのスケーリングで負荷変動にも対応でき、リージョン外転送を避けられる。
  • C
    　CloudWatch Logs から Kinesis Data Streams にデータを送信するためのクロスアカウント IAM ロールを作成し、信頼ポリシーを設定。メンバーアカウントごとにロググループのサブスクリプションフィルターを作成することで、ログが即時に中央ストリームへ集約される。
  • E
    　中央ログアカウントに Lambda 関数を作成し、Kinesis Data Streams をイベントソースとして取り込み。標準フォーマットへの正規化処理後、セキュリティツールにストリーミング送信。Lambda の自動スケーリングにより負荷変動へ対応可能。

■不正解の選択肢の理由

  • B（SQSキュー作成）
    　SQS はポーリング式で高スループットに向かず、リアルタイム性や大量ログ処理性能が不足。
  • D（SQS＋サブスクリプションフィルター）
    　CloudWatch Logs はロググループごとに1つのサブスクリプションフィルターしか設定できず、統合が困難。SQS のスループット制限も要件に不適合。
  • F（各メンバーアカウントに Lambda 配置）
    　各アカウントごとに Lambda を配置すると運用負荷が増大し、中央集約モデルの利点を失う。

■SAP試験で押さえておくべきポイント

  1. 大量ログのリアルタイム集約には Kinesis Data Streams が適しており、スループットやスケーラビリティで SQS より優れる。
  2. CloudWatch Logs サブスクリプションフィルター はロググループ単位で1つまでという制限がある。
  3. クロスアカウント権限設定（IAMロール＋信頼ポリシー）でメンバーアカウントから中央ストリームへ安全にデータ転送可能。
  4. ログ正規化は中央アカウントで一括実行し、Lambda のスケーリング特性を活用する。
  5. Control Tower 環境では「中央集約＋一括処理」構成が運用負荷低減と可視性向上の両方に寄与する。

この整理だと、試験本番でもKinesis / SQS の使い分けやログ転送の構成パターンが即答できる状態になるはずです。

以下の形式で整理しました。

■問題文
健康保険会社が、個人を特定できる情報 (PII) を Amazon S3 バケットに保存しています。同社は、S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用して、オブジェクトを暗号化します。

新しい要件によると、S3 バケット内の現在および将来のすべてのオブジェクトは、会社のセキュリティチームが管理するキーによって暗号化する必要があります。S3 バケットではバージョニングが有効になっていません。

これらの要件を満たすソリューションを選択してください。

■選択肢
A. S3 バケットのプロパティで、デフォルトの暗号化をカスタマーマネージドキーを使用する SSE-S3 に変更します。AWS CLI を使用して、S3 バケット内のすべてのオブジェクトを再アップロードします。暗号化されていない PutObject リクエストを拒否するように S3 バケットポリシーを設定します。

B. S3 バケットのプロパティで、デフォルトの暗号化を AWS Key Management Service (SSE-KMS) によるサーバー側の暗号化に変更します。暗号化されていない PutObject リクエストを拒否するように S3 バケットポリシーを設定します。AWS CLI を使用して、S3 バケット内のすべてのオブジェクトを再アップロードします。

C. S3 バケットのプロパティで、デフォルトの暗号化を AWS Key Management Service (SSE-KMS) によるサーバー側の暗号化に変更します。GetObject および PutObject リクエストでオブジェクトを自動的に暗号化するように S3 バケットポリシーを設定します。

D. S3 バケットのプロパティで、デフォルトの暗号化をカスタマーマネージドキーを使用する AES-256 に変更します。S3 バケットにアクセスするすべてのエンティティに暗号化されていない PutObject リクエストを拒否するポリシーをアタッチします。AWS CLI を使用して、S3 バケット内のすべてのオブジェクトを再アップロードします。

■問題文の要件の概要

  • 現在の暗号化：SSE-S3（S3管理キー）
  • 要件：会社セキュリティチームが管理するカスタマーマネージドキーを使用
  • 対象：既存・将来の全オブジェクト
  • バージョニング：無効
  • 実施内容：暗号化方式の変更＋既存オブジェクトの再暗号化＋今後の非暗号化アップロード拒否

■正解の選択肢と解説
正解：B

  • デフォルト暗号化を SSE-KMS（カスタマーマネージドCMK）に設定し、将来の全オブジェクトを自動暗号化。
  • バケットポリシーで SSE-KMS かつ指定CMKでない PutObject を拒否し、誤設定を防止。
  • 既存オブジェクトは再アップロード（上書き）で CMK による暗号化に更新。

この方法で、現在と将来のデータ両方を要件通りに暗号化できる。

■不正解の選択肢の理由

  • A（SSE-S3にカスタマーマネージドキー指定）
    　SSE-S3はS3管理キー方式であり、カスタマーマネージドキーを利用できない。
  • C（ポリシーで自動暗号化）
    　バケットポリシーはアクセス制御のみで既存オブジェクトの暗号化方式を変更できない。
  • D（AES-256＋カスタマーマネージドキー）
    　AES-256はSSE-S3の一部であり、カスタマーマネージドキーとの組み合わせは存在しない。

■SAP試験で押さえておくべきポイント

  1. SSE-S3：S3管理キー、カスタマーマネージドキー不可。
  2. SSE-KMS：AWS KMSキー（カスタマーマネージドCMK可）で暗号化、キーのローテーションやアクセス管理可能。
  3. 既存オブジェクトの暗号化方式を変更するには再アップロード（上書き）が必要。
  4. バケットポリシーは暗号化必須条件を強制できるが、既存データには適用されない。
  5. 要件に「セキュリティチーム管理キー」とあれば SSE-KMS＋CMK を選択するのが基本。

この問題は 「SSE-S3とSSE-KMSの違い」 と 「既存オブジェクト再暗号化の必要性」 を正確に理解しているかを問う典型パターンです。

以下の形式で整理しました。

■問題文
企業は、ハイブリッド DNS ソリューションを設計する必要があります。このソリューションは、VPC 内に保存されたリソースのために、ドメイン cloud.example.com の Amazon Route 53 プライベートホスティングゾーンを使用する予定です。

同社には、以下の DNS 解決の要件があります。

  • オンプレミスシステムは、cloud.example.com を解決して接続できる必要があります。
  • すべての VPC が cloud.example.com を解決できる必要があります。

オンプレミスの企業ネットワークと AWS Transit Gateway の間には、すでに AWS Direct Connect 接続が存在します。

最高のパフォーマンスでこれらの要件を満たす最適な方法を選択してください。

■選択肢
A. プライベートホストゾーンをすべての VPC に関連付けます。共有サービス VPC に Route 53 インバウンドリゾルバを作成します。すべての VPC を Transit Gateway にアタッチし、cloud.example.com のオンプレミスの DNS サーバーに、インバウンドリゾルバーを指す転送ルールを作成します。

B. プライベートホストゾーンをすべての VPC に関連付けます。共有サービス VPC に Amazon EC2 条件付きフォワーダーをデプロイします。すべての VPC を Transit Gateway にアタッチし、cloud.example.com のオンプレミスの DNS サーバーに、条件付きフォワーダーを指す転送ルールを作成します。

C. プライベートホストゾーンを共有サービス VPC に関連付けます。共有サービス VPC で Route 53 アウトバウンドリゾルバーを作成します。すべての VPC を Transit Gateway にアタッチし、cloud.example.com のオンプレミスの DNS サーバーに、アウトバウンドリゾルバーを指す転送ルールを作成します。

D. プライベートホストゾーンを共有サービス VPC に関連付けます。共有サービス VPC に Route 53 インバウンドリゾルバーを作成します。共有サービス VPC を Transit Gateway にアタッチし、cloud.example.com のオンプレミス DNS サーバーに、インバウンドリゾルバーを指す転送ルールを作成します。

■問題文の要件の概要

  • オンプレミスから cloud.example.com を名前解決できること
  • 全 VPC から cloud.example.com を解決できること
  • Direct Connect ＋ Transit Gateway 環境あり
  • 高パフォーマンスかつマネージドな方法で実現すること

■正解の選択肢と解説
正解：A

  • プライベートホストゾーンをすべての VPC に関連付けることで、各 VPC 内で cloud.example.com をローカルに解決可能。
  • 共有サービス VPC に Route 53 インバウンドリゾルバ を作成し、オンプレミスからのクエリを受け入れる。
  • すべての VPC を Transit Gateway にアタッチしてネットワーク接続を確立。
  • オンプレミス DNS サーバーに転送ルールを設定し、インバウンドリゾルバ経由で cloud.example.com を解決。
  • EC2ベースの条件付きフォワーダーよりも運用負荷が低く、Direct Connect 経由で低レイテンシーが実現できる。

■不正解の選択肢の理由

  • B（EC2 条件付きフォワーダー）
    　マネージドではなく可用性確保やパッチ管理が必要で、レイテンシーや運用負荷が増大。
  • C（アウトバウンドリゾルバ）
    　アウトバウンドリゾルバは AWS からオンプレミスへの名前解決専用で、オンプレミスからの問い合わせを受けられない。
  • D（共有サービス VPC のみ関連付け）
    　他の VPC がプライベートホストゾーンを参照できず、全 VPC 解決要件を満たさない。

■SAP試験で押さえておくべきポイント

  1. Route 53 Resolver インバウンドエンドポイント はオンプレミス→AWS 方向のクエリ受信に使用。
  2. アウトバウンドエンドポイント は AWS→オンプレミス方向専用。通信方向を混同しない。
  3. プライベートホストゾーンを複数VPCで利用するには、関連付け（または AWS RAM 共有）が必要。
  4. EC2ベースのDNS転送は可用性・運用コスト・スケーラビリティで劣る。
  5. Transit Gateway はネットワーク接続のみで、DNS名前空間共有は自動で行われない。

この問題は 「Route 53 Resolverの通信方向」 と 「プライベートホストゾーン共有方法」 を正確に理解しているかを確認する典型パターンです。

RELATED POST