AWS SAP 無料サンプル

AWS Control Towerは、Organizations・SCP・CloudTrail組織証跡・Config・IAM Identity Centerなどの基盤サービスを ベストプラクティスに基づいて自動構成し、事前定義された「ガードレール（プリベンティブ＝SCPベース／ディテクティブ＝Configルールベース／プロアクティブ＝CloudFormation Hooksベース）」を 一括適用できるマネージドサービスである。

• Account Factoryにより、標準化されたネットワーク・IAM Identity Center・ガードレール適用済みの新規アカウントを セルフサービス（またはAccount Factory for Terraform経由）で払い出せる。
• ガードレールはプリベンティブ（SCPで拒否）・ディテクティブ（Config管理ルールで違反検知・ダッシュボード表示）・プロアクティブ（CloudFormation Hooksでプロビジョニング前にブロック）の3種を あらかじめ用意されたカタログから選んで有効化でき、自前でSCP文言やConfigルールを1から設計・保守する必要が大幅に減る。
• 組織全体のCloudTrail証跡・Config記録・集約ログ用S3バケットも自動構成されるため、運用負荷の小さいチームでも 一貫したガバナンス基盤を短期間で立ち上げられる。

「自前でOrganizations・SCP・CloudTrail組織証跡・Config Aggregatorを1から設計・実装する」アプローチも技術的には可能だが、 要件にある「運用負荷を抑えたい」「素早く標準化してセルフサービス化したい」に対してはControl Towerが本来の適用対象であり、 再発明を避けられる。

SCPはAWS Organizationsのプリベンティブ（予防的）ガードレールであり、対象アカウントの実効権限の上限（フィルタ）を定める。

• SCPは管理アカウント（旧マスターアカウント）自体には適用されない。管理アカウントに対してガードレールを効かせたい場合は、 管理アカウントの利用を最小限にする・別途Config/CloudTrailで監視する等の設計が必要になる。
• SCPはそれ単体で権限を付与することは一切なく、IAMポリシー（アイデンティティ/リソースベース）側のAllowとの 共通部分（AND）が実効権限になる。SCPだけをアタッチしても何も使えるようにはならない。
• SCPはルートユーザーを含む対象アカウントの全プリンシパルに適用される（管理者権限であってもSCPのDenyからは逃れられない）。

AWS Organizationsの一元請求（Consolidated Billing）を有効化すると、デフォルトで Savings PlansおよびRIの割引共有（sharing）が組織内の全メンバーアカウントに対して有効になる。

• これにより、本番アカウントで購入したSavings Planの割引は、対象インスタンスファミリー/リージョンが一致すれば 開発アカウントや分析アカウントの利用分にも自動的に適用される（購入アカウントに閉じない）。
• RIについても同様で、アベイラビリティゾーン指定なしのRI（リージョナルRI）だけでなく、AZを指定したRI（ゾーンRI）も 組織内の他アカウントへの割引共有の対象となる。ただしゾーンRIの割引が適用されるのは購入時に指定したAZと一致する 使用量に限られる点がリージョナルRI（AZを問わず一致すれば適用）と異なる。いずれにせよ「他アカウントに一切共有されない」 わけではなく、購入者以外のアカウントでの未使用リスクを減らせる。
• この共有はデフォルトで有効だが、特定アカウントを共有対象から外したい場合は管理アカウントの「請求設定」でRI/Savings Plans共有を アカウント単位で無効化することもできる（例：他アカウントには使わせたくない専用購入がある場合）。

したがって、追加のコード実装や個別購入の付け替えを行わずとも、一元請求が有効な組織であれば標準機能として自動的に割引が共有される。

AWS Organizationsの組織用CloudTrail証跡（organization trail）を、管理アカウントから作成することで要件を満たせる。

• 組織用証跡は管理アカウントで一度作成すると、組織内の全メンバーアカウント（既存・将来追加分含む）に自動的に適用され、 各アカウントのAPIアクティビティ・全リージョンのイベントを記録できる（「すべてのリージョンに適用」を選択した場合）。
• メンバーアカウント側からはこの組織用証跡を無効化・削除・変更することができない（管理アカウントのみが変更権限を持つ）ため、 「各アカウント担当者が個別に無効化できない」という監査要件を満たす。
• ログの集約先S3バケットは通常、ログ専用アカウント（Log Archive）に作成し、バケットポリシーで 書き込みは許可するが削除・変更はできないよう最小権限で構成する。

各アカウントで個別にCloudTrail証跡を作成・管理する方式では、担当者が証跡を停止・改ざんできてしまい統制が効かない。

AWSのマルチアカウント戦略のベストプラクティスでは、環境（開発/ステージング/本番）はアカウントレベルで分離することが推奨される。 同一アカウント内でVPC・タグ・IAMポリシーの条件だけで環境を分けるアプローチは、IAM設定の1つのミスが全環境に波及しうるという 根本的な弱点を抱える。

• アカウントごとの分離により、IAMポリシー・SCP・課金・サービスクォータ・CloudTrail証跡がアカウント境界で完全に独立し、 ある環境での設定ミスが他環境のリソースへ直接影響しなくなる（ブラストラディウスの限定）。
• OrganizationsのOU構成で「Prod OU」「NonProd OU」のように分け、Prod OUには本番専用の厳格なSCP （例：特定のCLIプロファイル/踏み台からのみ許可等）を適用し、NonProd OUにはより緩やかな開発用SCPを適用するなど、 OU単位でガードレールの強度を差別化できる。
• アカウント間の正規のデータ連携（例：ステージングから本番の匿名化データ取得等）が必要な場合は、 クロスアカウントIAMロール引き受けなど明示的な最小権限の経路のみを許可する。

これにより、単一アカウント内でタグ/条件キーだけに依存する脆い分離から、AWSの構造的な境界（アカウント）を使った堅牢な分離へ移行できる。

Control Towerのコントロール（ガードレール）は、プリベンティブ（予防的）・ディテクティブ（発見的）・プロアクティブ（事前予防的）の3種類がある。

• プリベンティブガードレールは内部的にSCPとして実装されており、対象OU配下で許可されていない操作自体を API呼び出し時点でブロックする。
• ディテクティブガードレールは内部的にAWS Config管理ルールとして実装されており、 既に存在するリソースの構成が準拠していない状態（non-compliant）を継続的に検知し、Control Towerダッシュボードに表示する。 ディテクティブガードレールはリソースの作成自体を止めない（発見後の是正は別途必要）。
• プロアクティブガードレールは内部的にCloudFormation Hooks（preCreate／preUpdateハンドラ）として実装されており、 リソースがプロビジョニングされる前に非準拠を判定してブロックする。ただし効くのはCloudFormationスタック操作を経由した作成・更新に限られ、 コンソール・API・SDKからの直接操作には効かない。
• ガードレールはOU単位で有効化する（アカウント個別ではなくOUに対して適用する設計）。

SCPの運用方針には大きく2つの戦略がある。

• deny-list戦略（デフォルト）：ルートに FullAWSAccess を残したまま、禁止したい操作だけを 個別のDenyステートメントで追加していく。「原則すべて許可、例外だけ禁止」の考え方。
• allow-list戦略：FullAWSAccess をデタッチ（または対象OUで無効化）し、代わりに 許可したいサービス/アクションだけを明示的にAllowするSCPを作成してアタッチする。「原則すべて禁止、例外だけ許可」の考え方。 ただし、SCPはそのOU配下の全アカウントの実効権限の上限になるため、必要なサービス（IAM、STS、CloudFormation等の基盤サービス含む）を Allow漏れさせると、正規業務まで止まってしまう点に注意が必要。

要件の「許可された一部のサービスしか使わせない」はallow-list戦略そのものであり、Restricted OUから FullAWSAccess をデタッチし、 許可したいサービスのみをAllowする新しいSCPをアタッチすることで実現する。

「アカウント管理者権限を奪取されても既存ログを改ざん・削除できない」という要件は、S3のバケットポリシーやIAM権限だけでは満たせない （管理者権限があればIAMポリシー自体やバケットポリシー自体を変更できてしまうため）。この場合に有効なのがS3 Object Lock （コンプライアンスモード）である。

• S3 Object Lockをコンプライアンスモードで有効化すると、指定した保持期間中は、そのバケットのルート/管理者を含め いかなるユーザーもオブジェクトの削除・上書きができなくなる（保持期間の短縮や設定解除もできない）。
• これはIAMポリシーの上位に位置するストレージレイヤーでの技術的強制（technical enforcement）であり、 「IAM権限を奪われても」という前提のシナリオに対して唯一有効な防御である。
• Object Lockを有効にするにはバケットのバージョニングが必須である。バケット作成時に有効化できるほか、 2023年11月以降は既存バケットに対しても有効化できる（いずれもバージョニングの有効化が前提）。

AWSが推奨するOU設計のベストプラクティスは、まず「基盤（Foundational）OU」と「ワークロード（Workloads）OU」を分ける ことから始める。

• Foundational OU：Security（ログ集約・セキュリティツール用アカウント）、Infrastructure （共有ネットワーク等）のような、組織全体を横断して必要になる基盤アカウントを格納する。ほぼ全組織で共通の構成になる。
• Workloads OU：実際のビジネスアプリケーションが稼働するアカウント群。この配下をさらに Prod/NonProd（あるいは事業部・システム単位）に分割し、環境ごとに異なる強度のSCP・ガードレールを適用する。
• OUの分割粒度は「組織構造そのものを模倣する」のではなく、ポリシー（SCP・ガードレール）の適用単位として意味のある分割 （同じポリシーを当てたいアカウント群をまとめる）を優先すべきとされる。

SCPはプリンシパル側（呼び出し元）の実効権限の上限を定めるものであり、リソース側（S3バケット等）のリソースベースポリシーが 組織外プリンシパルへ許可を出すこと自体を制限する機能ではない。この種の「リソース側からの意図しない外部共有」を組織レベルで抑止するために AWSが提供するのがRCP（Resource Control Policy／リソースコントロールポリシー）である。

• RCPはSCPと対になる仕組みで、組織内のリソース（S3、STS等の対応サービス）に対するリソースベースポリシーの実効的な許可範囲に上限を課す。
• 例えば「組織のアカウントID以外のプリンシパルへの許可は、リソースベースポリシーにいくら書かれていても無効にする」というRCPを 組織のルートやOUにアタッチすることで、S3バケットポリシーやIAMロールの信頼ポリシーが誤って組織外に開いていても、 実際のアクセスは組織内プリンシパルに限定される。
• SCPだけでは「呼び出し元がそのアクションを呼べるか」しか制御できず、「リソース側が誰を許可しているか」というリソースベースポリシー由来の アクセス経路を組織レベルで塞ぐことはできない。

Control TowerのAccount Factoryで新規アカウントを払い出すと、ランディングゾーンの標準ベースラインが自動適用される。

• 新規アカウントは自動的に組織用CloudTrail証跡（organization trail）の記録対象となり、ログ専用（Log Archive）アカウントの S3バケットへAPIアクティビティが集約される（アカウント側で個別に証跡を作成する必要はない）。
• アカウントが属するOUに紐づくガードレール（プリベンティブ＝SCP、ディテクティブ＝Configルール）が自動的に適用され、 追加のOU割り当て変更なしにベースラインの統制が効いた状態で払い出される。
• 一方で、アカウント固有のVPCサブネット設計・アプリケーション用IAMロールの作成などワークロード固有の構成は Account Factoryの標準機能の範囲外であり、払い出し後に個別に構築する必要がある。

AWS Organizationsのタグポリシー（Tag Policies）は、組織内のリソースに付与するタグの キーの大文字小文字・許容される値・準拠すべき形式を定義し、非準拠のタグ付けを検知するための機能である。

• タグポリシーはOUやアカウント単位でアタッチでき、CostCenter というキーの正しい表記や、 許容する値のリストを定義できる。
• タグポリシーにはレポートモードと強制（enforcement）モードがあり、 enforced_for（コンソールでは「このタグの非準拠オペレーションを防止する」）を指定すれば、 タグポリシー単体で、非準拠のタグ値によるリソース作成・タグ付け操作をブロックできる。 ただし強制できるのはタグポリシーがサポートするリソースタイプに限られる。指定しなければ検知・レポートにとどまり、 非準拠のタグをAWS Resource Groups の Tag Editor やコンプライアンスレポートで可視化して是正を促す運用になる。
• ⚠️強制モードでも「タグが1つも付いていない状態での作成」は止められない（必須タグキーの欠落は対象外）。 「タグ未付与での作成」を禁止したいときこそSCP（aws:RequestTag 条件でのDeny）の出番になる。
• SCP単体では「タグの値が正しい表記かどうか」を判定するような柔軟な文字列検証はできず、タグポリシーの方が 表記ゆれの標準化という目的に適している。

VPCピアリングは1対1の接続であり、n個のVPCを相互接続しようとするとフルメッシュでは n(n-1)/2 本の接続が必要になる（30 VPCなら435本）。この本数はアカウント/VPCの追加のたびに指数的に増大し、 経路制御・セキュリティグループ・ルートテーブルの管理が破綻しやすい。加えてVPCピアリングは推移的ルーティング （transitive routing）を許さないため、A-B、B-Cがピアリングされていても、AからCへは直接到達できない （追加でA-Cのピアリングが必要）という制約もある。

• この課題に対する標準的な解決策がAWS Transit Gatewayである。Transit Gatewayを ネットワーク専用アカウント（Infrastructure/Network account）に構築し、各VPCをTransit Gatewayに アタッチする「ハブアンドスポーク型」構成にすることで、接続本数はVPCの数に比例（n本）で済み、 新規アカウント追加時も新しいVPCをTransit Gatewayにアタッチするだけで済む。
• Transit Gatewayはルートテーブルを使ってVPC間・オンプレミス（Direct Connect/VPN経由）との経路を柔軟に制御でき、 本番/非本番の分離のようなセグメンテーションもTransit Gatewayのルートテーブル単位で実現できる。

この種の「メンバーアカウント側の担当者が組織のガバナンス基盤自体を無効化できないようにする」要件は、 SCPで明示的にDenyすることで実現するのが定石である。

• 対象OU（または組織ルート）に、次のようなアクションをDenyするSCPをアタッチする。 organizations:LeaveOrganization（組織離脱）、cloudtrail:StopLogging/cloudtrail:DeleteTrail （組織証跡の停止・削除）、config:StopConfigurationRecorder/config:DeleteConfigurationRecorder （Config記録の停止・削除）などである。
• これらのSCP DenyはOU配下の全プリンシパル（ルートユーザー・管理者含む）に及ぶため、 メンバーアカウントの誰であっても（メンバーアカウント側の操作だけでは）これらの操作を実行できなくなる。
• なお、組織用CloudTrail証跡自体はもともとメンバーアカウント側から無効化できない設計だが、 アカウント固有に別途作成されたローカルの証跡やConfig記録機能までは、SCPで明示的に守らないと メンバーアカウント管理者が停止できてしまう点に注意する。

AWS Organizationsの一元請求は、実際の請求（コンソリデーテッドビル）に加えてAWS Billing Conductorという機能を使うと、 組織内アカウント群に対してカスタムの価格ルール（プライシングルール）を定義し、独自のプロフォーマ請求書（実際の課金ではなく 内部/顧客向けの参考請求書）を生成できる。

• Billing Conductorでは「Billing Group」を作り、対象アカウント群に対してマークアップ率や独自の割引率を設定した カスタム価格計画を適用できる。これにより、実際にAWSへ支払う金額（自社のRI/Savings Plans割引を反映した実コスト）と、 顧客に見せる請求額（独自の価格体系）を分離して管理できる。
• これは通常のConsolidated BillingやCost Explorerだけでは実現できない、再販（リセラー）・マネージドサービスプロバイダー向けの カスタム請求ユースケースに特化した機能である。

多くのAWSセキュリティ/管理系サービス（GuardDuty、Security Hub、IAM Access Analyzer、Config、Firewall Manager等）は 委任管理者（delegated administrator）の仕組みをサポートしている。

• 管理アカウントから、特定のメンバーアカウント（通常はセキュリティ専用アカウント）を委任管理者として登録すると、 以後はそのセキュリティアカウントから組織全体の該当サービスの設定・組織全体のビュー（例：全アカウントの検出結果集約）を 管理できるようになる。管理アカウントに日常的にログインする必要がなくなる。
• 委任管理者の登録・解除自体は管理アカウントからのみ実行可能であり、委任先のセキュリティアカウント側から 勝手に他アカウントを委任管理者に指定することはできない。
• これにより「管理アカウントは初期セットアップ・組織構造の変更など最小限の操作にとどめ、日常運用は専用アカウントに委譲する」 というベストプラクティス（管理アカウントの利用最小化）を実現できる。

インシデント対応における標準的な初動パターンの1つが「隔離SCP（quarantine SCP）」の適用である。

• 該当アカウントを一時的に隔離用のOU（例：Quarantine OU）へ移動し、ごく限られた許可アクション （フォレンジックに必要な読み取り系API、IAM/Organizationsの一部管理操作等）以外を全てDenyする厳格なSCPを適用する。
• これにより既存のリソース（EC2インスタンス等）は起動したまま保持され証拠保全が可能な一方、 攻撃者（漏えいした認証情報を使う何者か）による新たなAPI呼び出しは、たとえIAMポリシー側で許可されていても SCPレベルでブロックされる。
• アカウント自体をOrganizationsから削除（Close account）したり、EC2を停止・終了させたりする対応は、 証拠保全の妨げになる（メモリ状態の消失、S3ログの削除等）ためフォレンジック観点では避けるべき初動である。

複数人で共有するIAMロールを使う場合、CloudTrailのデフォルトのログには引き受けたロール名（assumedRoleUser）は残るが、 「元々誰がそのロールを引き受けたか」という個人識別情報は残らないのが課題になる。この課題を解決するのが STSのSourceIdentity機能である。

• sts:AssumeRole 呼び出し時に SourceIdentity パラメータ（例：社員のログインIDやメールアドレス）を渡すと、 ロールを引き受けた後のすべてのAPI呼び出しのCloudTrailログに、このSourceIdentityの値が記録され続ける （ロールの多段引き受け＝ロールチェイニングをしても伝播する）。
• これにより、複数人が同じ共有ロールを使っていても、個々のAPI呼び出しがどの個人に紐づくかをログから特定できる。
• ロールの信頼ポリシーで sts:SetSourceIdentity アクションを許可しておく必要があり、 かつSCP等で「SourceIdentityが設定されていないAssumeRoleを拒否する」ようなガードレールを組み合わせることで、 設定漏れによる追跡不能な引き受けを防止できる。

AWSのService Quotasには、Organizations統合の一環としてクォータリクエストテンプレート（Quota Request Template） という機能がある。

• 管理アカウント（または委任管理者アカウント）から、特定のリージョン・サービスのクォータ引き上げ内容をテンプレートとして登録しておくと、 そのテンプレートに登録されたクォータ引き上げが、組織内の新規作成アカウントに対して自動的に適用される。 ただしこの自動適用の対象はあくまで新規作成アカウントであり、既存アカウントへ後から横断的に一括適用する ネイティブ機能ではない。
• 既にある20の既存アカウントについては、テンプレートの対象外のため、Service QuotasのAPI（RequestServiceQuotaIncrease等） を使ってスクリプト化し、20アカウント分をまとめて自動申請する運用にすることで、コンソールから1件ずつ手作業で申請する 手間を削減できる。
• SCPやRCPはクォータの引き上げそのものには関与しない（クォータは各アカウントのサービス側の制限値であり、ポリシーで 引き上げられるものではない）点に注意。

Control Towerは「新規に組織を作る」だけでなく、既存のOrganizations環境に後から導入（landing zoneのセットアップ）し、 既存アカウントを個別に登録（enroll）することもサポートしている。

• 既存アカウントをControl Towerに登録する前には、通常「Account Factory for Terraform (AFT)」やコンソールの 事前チェック機能で、既存のCloudTrail証跡・Config設定・IAMロールが Control Tower の想定と衝突しないか確認する必要がある （例：既存の独自CloudTrail証跡がある場合、Control Tower標準のものと重複・競合しうる）。
• 既存アカウントの登録（enrollment）はアカウント単位、またはOU単位（該当OUを登録・再登録することで配下の既存アカウントをまとめて登録）で 段階的に進み、登録が進むにつれて該当アカウントにControl Towerのベースライン（ガードレール・ロール等）がデプロイされていく。 登録中は既存ワークロードの停止までは通常発生しないが、事前の設定衝突確認は必須である。
• 一方で、「既存アカウントは登録前に一度削除して作り直す必要がある」というのは誤りで、 既存アカウントをそのまま登録できるのがControl Towerの既存環境移行機能の要点である。

複数アカウントにまたがってTGWのようなリージョナルリソースを使わせたい場合の標準的な仕組みはAWS Resource Access Manager（RAM）である。

• 中央のネットワークアカウントがTGWを所有したまま、RAMでそのTGWをOrganizations配下の対象アカウント（または特定OU）に共有する。
• Organizationsとの統合を有効にしておけば、共有された各アカウントは招待の個別承認なしに自動的に共有リソースを受け取れる。
• 各アプリケーションチームは自分のアカウントから、自分が所有するVPCを共有されたTGWへVPCアタッチメントとして作成できる（ここは各アカウントの権限で実行可）。
• 一方、TGWのルートテーブルの作成・関連付け・伝播設定はTGWの所有アカウント（中央のネットワークアカウント）側でのみ操作可能であり、中央管理のガバナンスを維持できる。

これによりTGW自体は1つのまま、アタッチメントの作成権限だけを各チームに委譲でき、TGWを人数分複製する必要がない。

TGWは複数のルートテーブルを作成し、各アタッチメントを任意のルートテーブルに関連付ける（association）ことができ、 さらに伝播（propagation）先のルートテーブルもアタッチメントごとに個別に選べる。これによりVRF（仮想ルーティングフォワーディング）に似た論理的な分離＝セグメンテーションを構成できる。

• 本番ルートテーブル：本番VPCアタッチメントを関連付け、本番VPC同士のルートと共有サービスVPCのルートだけを伝播/追加する（開発VPCのルートは伝播させない）。
• 開発ルートテーブル：開発VPCアタッチメントを関連付け、開発VPC同士のルートと共有サービスVPCのルートだけを伝播/追加する（本番VPCのルートは伝播させない）。
• 共有サービス側：共有サービスVPCのアタッチメントは本番・開発の双方のルートテーブルへルートを伝播させ、また共有サービスVPC自身のルートテーブルには本番・開発両方への経路を持たせる。

この構成により、本番と開発の間には（どちらのルートテーブルにも相手のルートが存在しないため）そもそも到達可能な経路自体が存在せず、 SGやNACLに頼らずルーティングレイヤーで確実に分離できる。大量のVPCがあってもルートテーブルの関連付け・伝播ルールで一括管理できるためスケーラブルである。

アプライアンスモードを有効にしていないTGWは、トラフィックを発信元のAZに留めようとする（AZアフィニティ）。 AZを跨ぐのはAZ障害時か、そのAZにVPCアタッチメントのサブネットが無い場合だけである （VPCアタッチメント同士でECMPは行われない＝CIDRが重複しないためTGWのVPCアタッチメントはECMP非対応）。 問題は、この「発信元AZに留める」挙動が復路にも同じように働くことである。復路は宛先側VPCのAZで発生するため、 TGWはそれをそのAZのインスペクションVPCへ送る＝往路とは別のAZのアプライアンスへ着弾しうる。 そのアプライアンスは往路のセッションを知らないため、フローの非対称性（asymmetric routing）としてパケットがドロップされる。

• この問題への解決策がTGWの「アプライアンスモード（Appliance Mode）」である。インスペクションVPCのアタッチメントでアプライアンスモードを有効にすると、 TGWは特定のフロー（5タプル）を宛先AZに関わらず単一のAZに固定してルーティングするようになり、往路・復路が常に同じAZの同じアプライアンスインスタンスを通過する（フロー対称性の担保）。
• アプライアンスモードはアプライアンス（インスペクション）側のVPCアタッチメントに対して設定するものであり、スポークVPC側のアタッチメントに設定するものではない。

これにより、追加のロードバランサー変更や各AZ専用のルートテーブル分割といった複雑な構成を組まずに、TGWレベルの設定変更だけでステートフルインスペクションの整合性を確保できる。

TGWピアリングアタッチメントは、VPCアタッチメントとはルーティングの扱いが異なる点に注意が必要である。

• ルートの伝播はされない：VPCアタッチメントではTGWのルートテーブルへVPC側のCIDRが自動伝播（propagation）されるが、 ピアリングアタッチメントでは動的な伝播は行われず、双方のTGWルートテーブルに相手側CIDR宛の静的ルートを明示的に追加する必要がある。
• AWSグローバルネットワークバックボーンを利用：ピアリングされたTGW間のトラフィックはパブリックインターネットを経由せず、AWSの専用グローバルバックボーン上を流れる（リージョン間の物理層暗号化も提供される）。
• 推移的（トランジティブ）ルーティングは提供されない：TGW-A↔TGW-B↔TGW-Cのようにピアリングを連結しても、TGWは受信したピアリングアタッチメント経由のトラフィックを別のピアリングアタッチメントへ自動転送しない。中継が必要な場合は各TGW側で個別の設計・静的ルート構成が必要になる。

集約型エグレス（centralized egress）では、TGWのアタッチメントとNATゲートウェイの両方をAZごとに用意し、AZアフィニティ（affinity）を維持することが重要である。

• エグレスVPCには各AZにNATゲートウェイを1つずつ配置し、TGWアタッチメント用のサブネットも各AZに1つずつ作成する。
• 各スポークVPCの該当AZのルートテーブルで 0.0.0.0/0 をTGWへ向け、TGWのルートテーブルでエグレスVPCアタッチメントへ転送する。
• エグレスVPC側では、TGWアタッチメントサブネット（AZ-a）のルートテーブルで 0.0.0.0/0 を同じAZ-aのNATゲートウェイへ向ける（AZ-bも同様に自AZのNATゲートウェイへ）。これによりAZをまたいだNATゲートウェイ利用を避け、クロスAZデータ転送料金の発生を防ぐ。
• 各AZに独立したNATゲートウェイがあるため、1つのAZに障害があっても他AZのスポークVPCの通信には影響しない（単一障害点の排除）。

これはVPCサブネット共有（VPC sharing）が想定するユースケースそのものである。VPCサブネット共有はAWS RAMを利用して実現する。

• VPC所有アカウント（中央のネットワークアカウント）が、特定のサブネットをRAM経由で他のアカウント（参加者アカウント）に共有する。
• 参加者アカウントは、共有されたサブネットへ自分のアカウントのIAM権限でEC2・RDS等のリソースを起動できる。リソースの課金は起動したアカウント側に計上される。
• 各参加者アカウントは、同じ共有サブネット内であっても他の参加者が作成したリソース（ENI等）を参照・変更することはできない（可視性・権限は自分が所有するリソースに限定される）。
• VPCそのもの・ルートテーブル・NACL・サブネットCIDRの管理は引き続き所有アカウント側で一元管理される。これにより新規VPC/CIDRを都度払い出す必要がなく、IPアドレス空間の消費とネットワーク設定の分散を防げる。

Route 53 Resolverには方向の異なる2種類のエンドポイントがあり、それぞれ役割が明確に分かれている。

• インバウンドエンドポイント：VPC側に作成し、オンプレミスからVPC内（プライベートホストゾーン等）へのDNSクエリを受け付ける入り口。オンプレミスのDNSサーバー（フォワーダー）の転送先として、このエンドポイントのIPアドレスを設定する。
• アウトバウンドエンドポイントとResolverルール：VPC側に作成し、VPC内からオンプレミスへのDNSクエリを転送する出口。corp.example.com 宛のクエリをオンプレミスのDNSサーバーIPへ転送するResolverルールを作成し、アウトバウンドエンドポイントに関連付ける。

したがって「インバウンドエンドポイント（オンプレミス→VPC方向）」と「アウトバウンドエンドポイント＋転送ルール（VPC→オンプレミス方向）」の両方を組み合わせて構成することで、双方向のハイブリッドDNS解決が実現する。

Route 53 Resolverルールの中央管理・大量VPCへの適用は、AWS RAMでのルール共有＋各アカウント側でのVPC関連付けという2段階の操作で実現する。

• ルールの作成と共有：中央のネットワークアカウントでアウトバウンドエンドポイントとResolverルール（corp.example.com をオンプレミスDNS IPへ転送）を作成し、AWS RAMで対象のスポークアカウント（またはOU）へ共有する。
• 各アカウントでのVPC関連付け：共有を受けたスポークアカウント側で、そのResolverルールを自分のVPCへ関連付ける（AssociateResolverRule）。RAMでの共有はルールを「利用可能」にするだけで、VPCへの適用（関連付け）は各アカウント側の操作が別途必要になる。
• この構成にしておけば、オンプレミスDNSサーバーIPが変わった場合も中央アカウントのルールを1箇所修正するだけで、関連付け済みの全スポークVPCへ変更が反映される。

Route 53のプライベートホストゾーンはAWS RAMの共有対象リソースタイプではない点が本問の核心である。クロスアカウントでのVPC関連付けには、 Route 53が提供する専用の認可APIペアを使う。

• ホストゾーンの所有アカウント（中央のネットワークアカウント）側で、対象VPC（スポークアカウントが所有）ごとに CreateVPCAssociationAuthorization を実行し、そのVPCの関連付けを許可する。
• VPC所有アカウント（スポークアカウント）側で AssociateVPCWithHostedZone を実行し、認可されたホストゾーンと自分のVPCを実際に関連付ける。
• この2段階の認可・実行フローにより、ホストゾーンの所有権は中央アカウントに残したまま、複数アカウントのVPCから同じプライベートホストゾーンを名前解決に使えるようになる。

DNSクエリの内容（ドメイン名）に基づくフィルタリングはRoute 53 Resolver DNS Firewallが最も軽量かつ目的に合致する機能である。

• ドメインリストを作成し（AWS管理のマルウェア／ボットネットC2ドメインリストを利用可能）、これをブロックするルールグループを構成する。
• ルールグループを各VPCに関連付けることでDNSクエリレベルでのブロックが有効になる。ルールグループ自体は一元的に作成・更新し、関連付けだけを各VPCに対して行えばよいため、100超のVPCへも運用負荷を抑えて展開できる。
• クエリログをCloudWatch LogsやS3へ出力する設定を有効にすることで、どのクエリがブロックされたかを監査できる。

セキュリティグループやネットワークACLはIPアドレス・ポート単位の制御であり、ドメイン名に基づく制御はできない。AWS Network Firewallでもドメインフィルタリング自体は可能だが、 各VPCへファイアウォールエンドポイントを配置する必要がありインフラ・コスト・運用負荷が大きく、本問の「DNS解決の許可/拒否」という狭いスコープに対しては過剰な構成になる。