AWS SAA 無料サンプル

クロスアカウントで一時的かつ監査可能なアクセスを実現する標準パターンは、アカウントBにIAMロールを作成し、 そのロールの信頼ポリシー（trust policy）でアカウントA（またはアカウントA内の特定プリンシパル）を sts:AssumeRole できるプリンシパルとして許可することである。

• ロールのアクセス許可ポリシーには、対象バケットへの s3:GetObject/s3:ListBucket のみを許可する最小権限のポリシーを付与する。
• アカウントAのユーザー/アプリケーションは sts:AssumeRole を呼び出し、有効期限付きの一時的セキュリティ認証情報（アクセスキーID・シークレットキー・セッショントークン）を取得して利用する。
• AssumeRole の呼び出し自体・および発行された一時認証情報でのAPI呼び出しはCloudTrailに記録され、誰がいつどのロールを引き受けてアクセスしたかを追跡できる。

これにより長期キーの管理・ローテーション負担を避けつつ、最小権限と監査性を同時に満たせる。

AWSのポリシー評価では、あらゆる形の明示的Deny（explicit deny）が最優先で効く。 評価対象になり得るポリシー（IAMアイデンティティベースポリシー、リソースベースポリシー、権限境界、SCP、セッションポリシー）のうち 1つでもDenyがあれば、他にAllowがいくつあっても最終結果はDenyになる。

SCPはAWS Organizationsの機能で、アカウント（メンバーアカウント）に対する権限の“上限（guardrail）”を定める。 SCPで s3:DeleteObject を明示的にDenyしているので、たとえ alice のIAMポリシーが s3:* を許可していても、 SCPの範囲内に収まらない操作は実行できない。結果、alice の DeleteObject 呼び出しは拒否される。

SSE-KMS はエンベロープ暗号化（envelope encryption）の仕組みで動く。KMSはデータそのものを暗号化しない （KMSの暗号化APIには扱えるデータサイズに上限があり、GB単位のオブジェクトを直接暗号化する用途には使わない）。

• S3は、指定されたCMKに対して kms:GenerateDataKey を呼び出し、一意なデータキー（プレーンテキスト版＋暗号化版のペア）を取得する。
• プレーンテキストのデータキーでオブジェクト本体をS3側がAES-256で暗号化し、暗号化が終わったらプレーンテキストのデータキーはメモリから破棄する。
• 暗号化されたデータキーはオブジェクトのメタデータとして一緒に保存される。
• 復号時はメタデータ中の暗号化データキーをKMSの kms:Decrypt でCMKを使って復号し、得られたプレーンテキストのデータキーでオブジェクトを復号する。

この方式により、大きなオブジェクトでもKMSの呼び出し回数を抑えつつ（1オブジェクトにつきキー生成1回）、CMK自体はデータキーの保護のためだけに使われる。

SSE-S3 と SSE-KMS はどちらもAWS側でオブジェクトを暗号化する点は同じだが、鍵の可視性・制御性・監査性が大きく異なる。

• 監査性：SSE-KMS はCMKに対する GenerateDataKey/Decrypt の呼び出しがCloudTrailに記録されるため、 誰がいつそのキーを使ってデータへアクセスしたかを個別に追跡できる。SSE-S3 のAWS管理キーではここまでの粒度の監査はできない。
• 鍵のライフサイクル制御：SSE-KMS のCMKはキーポリシー・IAMポリシーで誰が使えるかを細かく制御でき、 ローテーション・無効化（disable）・削除スケジュールなど鍵自体のライフサイクルを管理者が制御できる。SSE-S3 のキーはAWSが完全管理し利用者側では制御できない。

一方でコスト面は逆で、SSE-KMS はKMSのAPIコール（GenerateDataKey 等）に応じた課金が発生し、SSE-S3 より高くなる。

AWS Secrets Managerは、RDS（MySQL/PostgreSQL/Oracle等）・Redshift・DocumentDBなど主要データベース向けに 組み込みのローテーションLambdaテンプレートを提供しており、コンソールで有効化するだけで 指定した日数（例：30日）ごとに自動でDBパスワードをローテーションできる。

• ローテーションされた新しい認証情報はSecretsManagerのシークレットとして保存され、アプリケーションは実行のたびに GetSecretValue で最新値を取得する設計にしておけば、ローテーション後も再デプロイ不要で追従できる。
• 一方 Systems Manager Parameter Store（SecureString）はKMSで暗号化した値を保管する機能は持つが、 DB認証情報向けの組み込み自動ローテーション機構は持たない。ローテーションを実現するには自前でLambda・EventBridgeスケジュールを組む必要がある。

「DB認証情報を自動ローテーションしたい」という要件は、Secrets Managerがまさに設計目的とする領域である。

Amazon Cognitoの2つのコンポーネントは役割がはっきり分かれている。

• Cognitoユーザープール（User Pool）：ユーザーディレクトリ機能。サインアップ・サインイン、パスワードポリシー、MFA、 外部IdP（Google/SAML等）連携を提供し、認証成功時にJWT（IDトークン・アクセストークン）を発行する。ユーザープール単体ではAWSリソースへの直接アクセス用の認証情報は発行しない。
• CognitoIDプール（Identity Pool / Federated Identities）：ユーザープールなど各種IdPが発行したトークンを受け取り、 STSを介して一時的なAWS認証情報（IAMロールに基づく）に交換する。この一時認証情報を使ってモバイルSDKがS3等へ直接アクセスできる。

したがって「ユーザープールで認証 → 発行されたトークンをIDプールに連携し、認証済みユーザー用IAMロールの一時認証情報を取得してS3へ直接アクセス」という組み合わせが正解となる。

「管理者権限を持つユーザーであっても」「一律に」「予防的に」という要件は、IAMポリシーではなく AWS OrganizationsのSCP（サービスコントロールポリシー）で実現すべきシグナルである。SCPは対象OU/アカウントの 全プリンシパル（ルートユーザー・管理者含む）の実効権限の上限を定めるガードレールだからである。

具体的には、対象OUに次のようなSCPをアタッチする。

{
  "Effect": "Deny",
  "NotAction": [ "iam:*", "organizations:*", "route53:*", "cloudfront:*", ... ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1"]
    }
  }
}

aws:RequestedRegion 条件キーで許可リージョンを絞ることで、そのOU配下のどのアカウントの誰が実行しても、 対象外リージョンでのリソース作成操作はDenyで拒否される（各アカウントのIAM側の設定に関わらず有効）。

オンプレミスの既存IdP（AD FS等）を使ってAWSコンソールへフェデレーションする標準パターンは、 IAMで SAML 2.0 のIDプロバイダー（IdP）をアイデンティティプロバイダーとして登録し、 そのIdPを信頼するIAMロールを作成することである。

• 従業員はまず社内のAD FSで認証し、AD FSがSAMLアサーションを生成する。
• そのSAMLアサーションをAWSのサインインエンドポイント（https://signin.aws.amazon.com/saml）へPOSTすると、 STSのAssumeRoleWithSAML相当の処理でロールが引き受けられ、一時的なAWS認証情報が発行されてコンソールにサインインできる。
• ロールにアタッチする権限ポリシーで、部門やAD上のグループに応じた権限をマッピングできる。

これにより500名分のIAMユーザーを作成せず、既存のADによる認証基盤をそのままAWSコンソールアクセスの認証に使い回せる。

多くのAWSサービス（EC2、RDS等）はリソースベースポリシーを持たないため、クロスアカウントアクセスには ターゲット側にロールを作り、呼び出し元が sts:AssumeRole で引き受ける方式が基本になる。 しかしS3はバケットポリシーというリソースベースポリシーを持つ数少ないサービスの一つであり、これを使うと ロールを新たに引き受ける手順を挟まずに、呼び出し元が“自分自身の既存のIAMロールの認証情報のまま”クロスアカウントでアクセスできる。

具体的には、アカウントBの reports-bucket のバケットポリシーで、 プリンシパルに arn:aws:iam::111111111111:role/AnalyticsRole を指定して s3:GetObject を許可する。 アカウントA側は追加のAssumeRole呼び出しをせず、EC2インスタンスが元々持つ AnalyticsRole の認証情報のままS3 APIを呼べる （リクエスト評価時にIAM側のAllow ∩ バケットポリシー側のAllowの両方が必要）。

これに対し、EC2やRDSのようにリソースベースポリシーを持たないサービスのリソースへアクセスする場合は、 ターゲットアカウント側にロールを作り明示的に AssumeRole するアプローチが必要になる。 なおLambdaはリソースベースポリシーを持つ側であり、関数のリソースベースポリシーで他アカウントのプリンシパルに lambda:InvokeFunction を直接委任できる（S3と同じくAssumeRoleを挟まない委任が可能）。「EC2とLambdaはどちらも委任できない」と一括りにしないこと。

KMSのCMKへのアクセス許可は、他のAWSリソースと異なり「キーポリシー」が常に評価に関与するという特殊なモデルを取る。

• CMK作成時のデフォルトのキーポリシーには、通常 {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::<account>:root"},"Action":"kms:*","Resource":"*"} というアカウントルートへの許可ステートメントが含まれる。これがあることで初めて、IAMポリシー側の許可がそのCMKへのアクセスとして「有効」になる （IAMポリシーに実効力を持たせるための“扉”をキーポリシー側が開けている状態）。
• この設問のようにそのステートメントが削除されている場合、IAMポリシーでどれだけ広く kms:Decrypt を許可していても、 キーポリシー側に bob（または彼が引き受けているロール）を明示的に許可するステートメントが無い限りアクセスは拒否される。
• 解決には、キーポリシーに bob（または関連ロール）を許可するステートメントを追加するか、 削除されたルートへの委任ステートメントを復元してIAMポリシー側の管理に戻す必要がある。

両者はいずれも「権限を付与するものではなく、上限（フィルタ）を定めるもの」という共通点を持ちながら、適用対象が異なる。

• 権限境界（permission boundary）：IAMの機能で、特定のIAMユーザー/ロールにアタッチし、 そのプリンシパルが持てる権限の上限を定める。主に「権限委任された管理者が、自分より広い権限のロールを誤って作らないようにする」目的で使われる。
• SCP：AWS Organizationsの機能で、アカウント／OU単位に適用し、その配下の全プリンシパル（管理者・ルートユーザー含む）の実効権限の上限を定める。
• 実効権限は、いずれの仕組みでも 「アイデンティティベースポリシー（またはリソースベースポリシー）のAllow」と「境界/SCPが許可する範囲」の共通部分（AND） になる。境界やSCPだけでは何も権限を付与できない。

CognitoIDプールは「認証済み（authenticated）」と「未認証（unauthenticated）」の2種類のロールを個別に設定できるのが特長である。

• 未認証ロール：匿名ユーザー向けにアタッチするIAMロールで、ランキング読み取り専用など限定的な権限だけを持たせる。
• 認証済みロール：サインイン済みユーザー向けにアタッチするIAMロールで、 ${cognito-identity.amazonaws.com:sub} のようなポリシー変数を使い、 自分のCognito IDに対応するプレフィックス配下のオブジェクトにだけ読み書きを許可するなど、ユーザーごとにスコープを絞れる。
• いずれもSTSを介して発行される一時的なAWS認証情報であり、モバイルSDKはこれを使って直接S3を呼び出せる（バックエンドの都度プロキシは不要）。

CognitoIDプール（および、Cognitoを使わずに直接OIDC/OAuthのWebIDトークンでAWSアクセスを実現したい場合）が使うSTS APIは sts:AssumeRoleWithWebIdentityである。

• このAPIは、Web IDフェデレーションプロバイダー（Google、Facebook、Amazon、または任意のOIDC互換IdP）が発行した OIDCトークンを受け取り、指定したIAMロールを引き受けて一時的なAWS認証情報を返す。
• sts:AssumeRole はすでにAWSの認証情報（IAMユーザー/ロール）を持つ主体が別のロールへ切り替える場合に使う（クロスアカウントロール引き受け等）。外部Webトークンを直接渡す用途ではない。
• sts:GetFederationToken はIAMユーザーの認証情報を使い、限定的な権限を持つ一時トークンを発行する古い方式で、外部IdPのトークンを受け取る仕組みではない。
• sts:GetSessionToken はMFA保護されたAPI呼び出しのためにIAMユーザー自身が一時セッションを取得する用途であり、フェデレーションとは無関係。

Secrets Managerのローテーションは、ローテーションLambda関数が createSecret → setSecret → testSecret → finishSecret の4ステップを実行して、 新しい認証情報の生成・DB側への設定・接続検証・確定（バージョンラベルの切り替え）を行う。 RDS/Aurora/Redshift/DocumentDB向けにはAWSが提供する組み込みのローテーションテンプレートがあり、これをそのまま使える。

アプリケーション側は、認証情報を起動時にキャッシュして固定するのではなく、 実行のたびに（あるいは適切な間隔でキャッシュしつつ）secretsmanager:GetSecretValue を呼び出す設計にしておけば、 裏側でローテーションが行われてもコードの変更・再デプロイ無しに新しい認証情報へ自然に追従できる。

KMSマルチリージョンキー（multi-Region keys）を使うと、この要件を満たせる。

• ap-northeast-1でプライマリキー（mrk-接頭辞のキーID）を作成し、 CreateReplicaKeyでap-northeast-3にレプリカキーを作成する。
• プライマリとレプリカは同一のキーマテリアル・キーID（リージョン部分を除く）を共有する独立したKMSキーとして振る舞う。
• そのため、プライマリ（ap-northeast-1）で暗号化した暗号文を、レプリカ（ap-northeast-3）のエンドポイントに対して直接 Decrypt を呼ぶだけで復号できる。 リージョンをまたぐAPI呼び出しやap-northeast-1への依存は発生しない。

一方、通常の単一リージョンCMKでIAMポリシー側だけをクロスリージョンで許可しても、暗号文の復号はそのキーが存在するリージョンのKMSエンドポイントを呼び出す必要があるため、 ap-northeast-1への依存自体は解消されない（DRの目的である「原リージョン障害時の独立性」を満たせない）。

SCPはメンバーアカウントの全プリンシパル（そのアカウントの管理者・ルートユーザーも含む）に対する実効権限の上限になるため、 「悪意ある/誤った操作でガードレールを外されたくない」設定に向いている。代表的な2パターン：

• 組織離脱の禁止：ルートOU（またはメンバーアカウントを含むOU）に organizations:LeaveOrganization を明示的にDenyするSCPを適用すると、 メンバーアカウントの管理者であっても組織から離脱する操作ができなくなる。
• 証跡ログの無効化・削除の禁止：cloudtrail:StopLogging/cloudtrail:DeleteTrail などをDenyするSCPを適用すると、 たとえアカウント内で管理者権限を奪取されても、監査証跡（CloudTrail）を止められない多層防御になる。

なおSCPは管理アカウント（Organizationsの管理者アカウント）自体には適用されない点、 またSCPはルートユーザーの認証情報そのものを無効化する機能ではない点（あくまでAPIアクションの許可/拒否を制御する）には注意が必要。

S3はマネージドサービスでセキュリティグループ/NACLをアタッチする対象ではないため、ネットワーク経路を条件にしたアクセス制御はバケットポリシーの条件キーで行う。

• バケットポリシーに、aws:SourceVpce 条件キーが指定のVPCエンドポイントIDと一致しない場合にDenyするステートメントを追加する。
• Condition: { "StringNotEquals": { "aws:SourceVpce": "vpce-0123456789abcdef0" } } のようにすることで、 正しいIAM認証情報を持っていても、このVPCエンドポイントを経由しないリクエスト（インターネット経由・別VPC経由等）は明示的Denyで拒否される。
• IAM側のポリシーでs3:GetObject等を許可していても、バケットポリシー側の明示的Denyが優先されるため、経路の強制が実現できる。

この2つの要件はいずれもIAM Access Analyzerの機能領域である。

• 外部アクセスの分析（external access analyzer）：S3バケットポリシー、IAMロールの信頼ポリシー、KMSキーポリシー、SQSキューポリシーなど リソースベースポリシーを解析し、組織/アカウントの「ゾーン・オブ・トラスト」の外側にアクセスを許可している箇所を検出する。
• 未使用アクセスの分析（unused access analyzer）：過去の実際のCloudTrail利用状況から、 一定期間（追跡期間を設定可能）使われていない権限・ロール・アクセスキーを検出し、最小権限化の推奨を提示する。

Trusted Advisorは一般的なベストプラクティスチェック（例：S3バケットのパブリックアクセス有無の簡易チェック等）は行うが、 本問のようなリソース単位・ポリシー単位の詳細な外部アクセス分析や未使用アクセス分析には対応していない。CloudTrail Insightsは異常なAPI呼び出しパターンの検出であり権限分析ではない。

EC2インスタンスロールは、Well-Architectedフレームワークのセキュリティの柱が推奨する「長期認証情報を避ける」ベストプラクティスの代表例である。

• ロールの認証情報はインスタンスメタデータサービス（IMDS）経由で自動的に発行・定期的に自動ローテーションされる一時的なセキュリティ認証情報であり、 開発者が長期アクセスキーを設定ファイルへ埋め込んで手動管理・手動ローテーションする必要がなくなる。
• この一時認証情報には有効期限があり自動的に更新され続けるため、万一インスタンスが侵害されても、 漏えいした認証情報が悪用できる時間的な窓は、失効しない長期アクセスキーが漏えいした場合に比べて限定的になる。

なお、ロールを使う場合でもアタッチする権限ポリシー自体は別途必要であり（自動的にフルアクセスになるわけではない）、 またロールの認証情報はローテーションされないわけではなく、定期的に自動更新されるという点を混同しないこと。

この種の高スループットなクライアント側エンベロープ暗号化のユースケースには、 AWS Encryption SDKのデータキーキャッシング（data key caching）機能が設計されている。

• データキーキャッシングは、生成したデータキーをローカルの暗号資料キャッシュ（cryptographic materials cache）に保持し、 一定の制限（最大メッセージ数・最大バイト数・最大有効時間などを設定可能）の範囲内であれば、 毎回KMSを呼ばず同じデータキーを複数の暗号化操作で再利用する。
• これによりGenerateDataKeyの呼び出し回数・スロットリング・コストを大幅に削減しつつ、 設定した上限に達したら新しいデータキーへ切り替えるため、1つのデータキーが無制限に使われ続けることも防げる（露出範囲の限定）。

単にKMSのAPIクォータ引き上げをサポートに依頼するだけでは、根本のアーキテクチャ課題（呼び出し回数そのものの多さ・コスト）は解決しない。 またSSE-S3への切り替えはクライアント側暗号化を手放すことになり要件（クライアント側でのコントロール）にそぐわない場合が多く、 無期限にキャッシュし続ける設計はデータキーの露出範囲を限定するという安全上の目的を損なう。

プライベートサブネットのインスタンスに「アウトバウンドのインターネットアクセスは必要だが、インバウンド接続は一切許可しない」という要件には、NAT ゲートウェイが最適解である。

• NAT ゲートウェイはパブリックサブネットに配置し、Elastic IP を割り当てる。パブリックサブネットのルートテーブルには 0.0.0.0/0 → インターネットゲートウェイ（IGW） のルートが必要。
• プライベートサブネットのルートテーブルには 0.0.0.0/0 → NAT ゲートウェイ ID を設定する。これによりプライベートサブネットのインスタンスはアウトバウンド通信（送信元アドレス変換＝SNAT）でインターネットへ出られる。
• NAT ゲートウェイは送信元からの接続に対する戻りの通信のみを通す（ステートフルな変換テーブルを保持）。インターネット側から新規にプライベートサブネットへ接続を開始することはできない＝インバウンド接続を許可しない要件を自然に満たす。

セキュリティグループはステートフルである。これが本問の核心。

• インバウンドルールで許可した通信の戻りのレスポンスは、アウトバウンドルールの内容にかかわらず自動的に許可される（コネクション追跡により、往路が許可されれば復路も自動的に通す）。
• セキュリティグループのデフォルトのアウトバウンドルールは「すべての送信を許可」であるため、仮に明示的なアウトバウンドルールを何も追加していなくても外向き通信自体は妨げられない。だが本問で問われている本質はステートフルな戻り通信の自動許可の性質である。
• 対照的にネットワークACL（NACL）はステートレスであり、インバウンド／アウトバウンド双方を明示的に許可しなければならない（戻り通信にはエフェメラルポートのアウトバウンド許可が別途必要）。

ネットワークACL（NACL）はステートレスであり、往路と復路のルールをそれぞれ独立して明示的に許可しなければならない。

• アウトバウンドでポート 443 を許可しているため、アプリケーションサーバから外部 API へのリクエスト自体は送出できる。
• しかし外部 API からのレスポンスは、クライアント側（アプリケーションサーバ）が接続時に使用した一時的な送信元ポート＝エフェメラルポート（一般的に 1024〜65535）宛てに返ってくる。インバウンドルールが「ALL TRAFFIC DENY」のままでは、この戻りのレスポンスがブロックされる。
• 修正には、インバウンドルールに送信元 0.0.0.0/0・プロトコル TCP・ポート範囲 1024-65535（OS のエフェメラルポート範囲に応じて調整）を許可する ALLOW ルールを、DENY ルールより小さいルール番号で追加する必要がある（NACL はルール番号の小さい順に評価し最初にマッチしたルールが適用される）。

S3 や DynamoDB のような AWS のリージョナルサービスへプライベートサブネットから到達させるにはゲートウェイ型 VPC エンドポイント（Gateway Endpoint）が最適。

• ゲートウェイエンドポイントはルートテーブルにプレフィックスリスト経由のルートを追加するだけで機能し、ENI（インターフェース）を作成しない。追加の時間課金が発生しない（無料）のが大きな特長。
• トラフィックはインターネット・NAT ゲートウェイを経由せず、AWS のネットワーク内で完結する。これにより NAT ゲートウェイのデータ処理料金を削減でき、セキュリティ要件（インターネット非経由）も満たす。
• ゲートウェイエンドポイントはS3 と DynamoDB のみ対応。それ以外の多くの AWS サービスはインターフェース型エンドポイント（PrivateLink・ENI＋課金あり）を使う。

この要件（CIDR 重複あり／VPC 全体ではなく特定サービスだけへの限定的なアクセス）は、AWS PrivateLink（インターフェース型 VPC エンドポイント）の典型的なユースケースである。

• パートナー企業（サービス提供側）は NLB をエンドポイントサービスとして公開し、自社（消費側）はそのサービスに対してインターフェース型 VPC エンドポイント（ENI）を自社 VPC 内に作成して接続する。
• PrivateLink は片方向・一点集中型の接続であり、自社側は公開されたサービスにのみアクセスでき、パートナー側 VPC 全体のルーティングテーブルやサブネットへは一切到達できない。
• ENI は自社 VPC 内のプライベート IP として現れるだけなので、双方の VPC CIDR が重複していても問題なく機能する（VPC ピアリングは CIDR 重複時に接続できないため、この点が VPC ピアリングとの決定的な違い）。

VPC ピアリング接続は推移性を持たない（non-transitive）。これが本問の核心。

• VPC-A ⇄ VPC-B のピアリングと VPC-B ⇄ VPC-C のピアリングが存在していても、VPC-B を経由して VPC-A から VPC-C へ通信することはできない。ピアリングはあくまでピアとなった2つの VPC 間だけの直接接続であり、片方の VPC を中継点（トランジット）として使うことは設計上サポートされない。
• VPC-A から VPC-C へ到達させるには、VPC-A と VPC-C の間に別途直接のピアリング接続を作成するか、あるいはTransit Gateway を導入して VPC-A・VPC-B・VPC-C を一括してアタッチし、ハブ＆スポーク型で推移的なルーティングを実現する必要がある。

多数の VPC（およびオンプレミス拠点）を相互接続する場合、Transit Gateway を使ったハブ＆スポーク型設計が最もスケーラブルである。

• 各 VPC を Transit Gateway にアタッチメントとして接続し、Transit Gateway 1つを中心（ハブ）に据える構成へ変更する。VPC の数が n 個でも、必要な接続（アタッチメント）は n 本で済み、VPC ピアリングのフルメッシュ（最大 n(n-1)/2 本）のような組み合わせ爆発が起きない。
• Transit Gateway は推移的なルーティングをサポートする（VPC ピアリングとの決定的な違い）。VPC-A と VPC-B がそれぞれ Transit Gateway にアタッチされていれば、Transit Gateway 経由で相互に通信できる。
• Transit Gateway ルートテーブルを使えば、VPC ごとにルーティングを個別制御し、必要に応じてセグメント化（例：本番と開発を分離）することも可能。

「短納期（数日〜1週間程度）」「通信量・レイテンシ要件が厳しくない」という条件から、AWS Site-to-Site VPN が最適解となる。

• Site-to-Site VPN は、オンプレミスのカスタマーゲートウェイと AWS 側の仮想プライベートゲートウェイ（または Transit Gateway）の間にIPsec による暗号化トンネルをインターネット経由で確立する。専用線の敷設が不要で、設定さえ整えば短時間（数分〜数時間）で構築できる。
• 一方 AWS Direct Connect は、オンプレミスと AWS の間に専用の物理接続を確立するもので、一貫した帯域・低レイテンシ・高スループットが得られる利点があるが、物理的な敷設や Direct Connect パートナーとの調整に数週間〜数ヶ月の納期を要する。今回のような短納期要件には向かない。
• 本問は「大容量データ移行」「一貫した低レイテンシが必須」といった Direct Connect が優位になる条件を提示していないため、迅速に構築できる VPN が適切という結論になる。

1本の Direct Connect 接続から、複数リージョンにまたがる複数の VPCへ到達させたい場合は、Direct Connect Gateway を使う。

• オンプレミス側のルータと DX ロケーションの間に確立したプライベート仮想インターフェース（Private VIF）を、Direct Connect Gateway に関連付ける。
• Direct Connect Gateway には、各リージョンの VPC に紐づく仮想プライベートゲートウェイ（VGW）またはTransit Gatewayを関連付けることができ、これにより1本の Direct Connect 接続から、リージョンをまたいだ複数の VPC へ到達できるようになる。
• Direct Connect Gateway 自体はグローバル（リージョンに縛られない）なリソースであり、まさに「1つの物理接続を複数リージョンの複数 VPC で共有する」ユースケースのために設計されている。

Direct Connect の耐障害性向上は、単一の物理接続・単一のロケーションに依存しない設計にすることが基本方針である。

• 別の Direct Connect ロケーション（POP）に2本目の Direct Connect 接続を構築する。同一ロケーション内で機器や回線を二重化しても、そのロケーション自体（建物・電源・回線経路）に障害が起きれば両方とも影響を受ける。ロケーションを分けることで、施設単位の障害からも保護される。
• Site-to-Site VPN をバックアップ経路として構成する。Direct Connect 経路に障害が起きた場合、インターネット経由の VPN 接続へフェイルオーバーすることで、帯域・レイテンシは落ちるものの接続断を防げる（BGP の経路優先度で通常時は Direct Connect を優先し、障害時に VPN 経路へ切り替わるよう設計する）。

AWS の Direct Connect Resiliency Toolkit でも、最高レベルの耐障害性（Max Resiliency）は複数ロケーション・複数デバイスにまたがる複数接続を推奨している。