プレイブック

多くのVPCに対するフルメッシュ接続。一部にCIDRが重複しているVPCがある。

→Transit Gatewayをデプロイします。影響を受けるVPCに一意のセカンダリCIDRブロックを追加して、重複するCIDRを修正します。

理由: Transit Gatewayはスケーラブルな推移的ルーティングを提供しますが、重複するIP範囲間ではルーティングできません。IPの修正が必要です。

高スループット、低レイテンシー、高可用性ハイブリッド接続。

→2つの異なるDirect Connectロケーションで、2つの専用Direct Connect接続をプロビジョニングします。

理由: 2つの異なるロケーションを使用することで、ロケーションレベルの障害（光ファイバー断線、停電など）から保護し、最大の回復性を提供します。複数の接続があっても単一ロケーションでは単一障害点となります。

オンプレミスとAWSプライベートホストゾーン間の双方向DNS解決。

→Route 53 Resolverを使用します。オンプレミスがAWSにクエリするためにインバウンドエンドポイントを作成します。AWSがオンプレミスにクエリするために転送ルールを持つアウトバウンドエンドポイントを作成します。

理由: インバウンドエンドポイントは、オンプレミスのDNSフォワーダーが到達可能なIPを提供します。アウトバウンドエンドポイントは、VPC内からの条件付き転送を可能にします。VPCのデフォルトリゾルバー（VPC+2）はオンプレミスから到達できません。

ネットワーク層のルートを作成せずに、2つのVPC間でサービスレベルのアクセスを提供します。

→AWS PrivateLinkを使用します。プロバイダーVPCにVPCエンドポイントサービス（NLBにサポートされる）を、コンシューマーVPCにインターフェースVPCエンドポイントを作成します。

理由: PrivateLinkは、コンシューマーのVPC内のENIを使用して単方向のサービス固有の接続を提供し、ネットワークレベルのルーティングやCIDRの重複問題を完全に回避します。

プライベートサブネット内のIPv6対応インスタンスに、アウトバウンド専用のインターネットアクセスを提供します。

→Egress-Only Internet Gateway (EIGW) を作成し、プライベートサブネットのルートテーブルに `::/0` のルートをEIGWに向けて追加します。

理由: EIGWはアウトバウンドIPv6接続に対してステートフルであり、戻りトラフィックを許可しますが、望まないインバウンド接続を防ぎます。これはIPv6版のNAT Gatewayに類似しています。

Transit Gatewayを使用した集中型モデルで、AWS Network Firewallを使用してすべてのVPC間トラフィックを検査します。

→Network Firewallを持つ専用の検査VPCを作成します。TGWルートテーブルを設定して、すべてのVPC間トラフィックを検査VPCに送信します。検査VPC内では、対称ルーティングのためにNFWエンドポイントを介してトラフィックを誘導するようにルートテーブルを設定する必要があります。

理由: このアーキテクチャでは慎重なルーティングが必要です。TGWは検査VPCにトラフィックを送信し、VPCルートテーブルはそれをファイアウォールエンドポイントに送信し、ファイアウォールはそれをTGWアタッチメントENIに戻し、TGWが最終宛先にルーティングします。

Transit Gatewayを使用してVPCをセグメント化し（例：本番環境と開発環境）、両方から共有サービスVPCにアクセスできるようにします。

→複数のTransit Gatewayルートテーブルを使用します。各セグメント（本番環境、開発環境、共有）にルートテーブルを作成します。VPCをそれぞれのテーブルに関連付けます。スポークがハブのみを表示できるハブアンドスポークトポロジーを作成するためにルートを伝播させます。

理由: TGWルートテーブルの関連付けと伝播は、ネットワーク層でのネットワークセグメンテーションとトラフィック分離の主要なメカニズムです。

単一リージョンでホストされている動的でキャッシュ不可能なグローバルアプリケーション（API、ゲームなど）のレイテンシーを削減します。

→AWS Global Acceleratorを使用します。これはエニーキャストIPを提供し、ユーザーを最も近いAWSエッジロケーションにルーティングし、その後、トラフィックは最適化されたAWSバックボーンを経由してオリジンに到達します。

理由: Global AcceleratorはAWSネットワーク上での「ファーストマイル」と「ミドルマイル」を最適化し、TCP/UDPトラフィックのレイテンシーとジッターを削減します。CloudFrontはキャッシュ可能なコンテンツに適しています。

インターネットを経由せずに、VPCからS3およびDynamoDBへのプライベートアクセスを提供します。

→S3およびDynamoDB用のGateway VPCエンドポイントを作成します。これにより、指定されたサブネットルートテーブルにプレフィックスリストエントリが追加されます。

理由: Gatewayエンドポイントは、S3およびDynamoDBのプライベートアクセスに特化した、高性能かつ無料のメカニズムです。他のサービスはインターフェースエンドポイント（PrivateLink）を使用します。

単一のオンプレミスDirect Connect接続から複数のAWSリージョンにあるVPCにアクセスします。

→Transit Virtual Interface (T-VIF) を持つDirect Connect Gatewayを使用します。DX Gatewayを、必要な各リージョンのTransit Gatewayに関連付けます。

理由: DX GatewayとTransit VIFの組み合わせは、複数のリージョンにわたるTransit Gatewayに接続するためのスケーラブルなソリューションです。DX GatewayとPrivate VIFの組み合わせは、より低い制限があります。

透過的なトラフィック検査のために、サードパーティの仮想ファイアウォールアプライアンスを統合します。

→Gateway Load Balancer (GWLB) を使用します。これはレイヤー3で動作し、GENEVEプロトコルを使用してトラフィックをカプセル化し、元の送信元/宛先IPを保持します。

理由: GWLBのGENEVEカプセル化により、「ワイヤー内介入」となり、セキュリティアプライアンスにとって重要な、ソースNATを必要とせずにアプライアンスをネットワークパスに透過的に挿入できます。

重複を防ぎ、使用状況を追跡するために、マルチアカウント組織内の数百のVPCのIPアドレス割り当てを管理します。

→Amazon VPC IP Address Manager (IPAM) を使用します。トップレベルプールを作成し、リージョンプールを委任してVPC CIDRの割り当てを自動化します。

理由: VPC IPAMは、エラーが発生しやすい手動の方法に代わり、集中型IPアドレス管理のための専用の拡張可能なAWSサービスです。

GREトンネルと動的BGPルーティングを使用して、サードパーティのSD-WANアプライアンスをTransit Gatewayと統合します。

→Transit Gateway Connectアタッチメントを使用します。

理由: TGW ConnectはSD-WAN統合のために特別に設計されています。より高い帯域幅（ピアあたり最大5 Gbps）のためのGREと、動的ルーティングのためのBGPをサポートします。

IPv6のみのVPCが、インターネット上のIPv4のみのリソースと通信する必要があります。

→VPCのRoute 53 Resolver設定でDNS64を有効にし、パブリックサブネットにNAT Gatewayを設定します。`64:ff9b::/96` をNAT Gatewayにルーティングします。

理由: DNS64はIPv4宛先用のAAAAレコードを合成します。NAT Gatewayは、合成されたIPv6アドレスから実際のIPv4アドレスへのNAT64プロトコル変換を実行します。

厳格なセグメンテーション要件（本番環境、開発環境、共有サービス）を持つ、多数のリージョンにわたる数百のVPCを接続します。

→AWS Cloud WANを使用します。単一のコアネットワークポリシーでセグメントとセグメントアクションを定義し、セグメント間のルーティングをグローバルに制御します。

理由: Cloud WANは集中管理型の宣言的グローバルネットワークポリシーを提供し、各リージョンでTransit Gatewayピアリングとルートテーブルのフルメッシュを管理するよりもスケーラブルで複雑さが低減されます。

帯域幅の増加とリンク冗長性のために、単一ロケーションで複数のDirect Connect接続を集約します。

→リンクアグリゲーショングループ (LAG) を設定します。すべての接続は同じ帯域幅を持ち、同じAWSデバイスで終端する必要があります。

理由: LAGは物理リンクを1つの論理リンクにバンドルします。これによりリンクレベルのフェイルオーバーは提供されますが、デバイスまたはロケーションの障害からは保護されません。フェイルオーバーしきい値を定義するには`minimum links`を使用します。

マルチリージョンアプリケーションに対して60秒未満のDNSフェイルオーバーを実現します。

→ヘルスチェック付きのRoute 53フェイルオーバールーティングを使用します。高速間隔（10秒）のヘルスチェックを低い障害しきい値（1）で設定します。エイリアスレコードまたは非常に低いTTL（例：10～60秒）を使用します。

理由: 高速フェイルオーバーには、迅速な検出（高速ヘルスチェック）と迅速なクライアント側更新（低いTTLまたは動的TTLを持つエイリアスレコード）が必要です。

Site-to-Site VPN接続の両方のトンネルを同時に使用して、合計VPNスループットを向上させます。

→VPNをTransit Gatewayにアタッチします。Transit Gateway VPNアタッチメントでECMPサポートを有効にします。

理由: デフォルトでは、TGWへのVPNは1つのトンネルのみを使用する場合があります。BGPルートが等コストである場合、TGWアタッチメントでECMPを有効にすると、両方のトンネルにトラフィックが分散されます。

Network Load Balancerの背後にあるバックエンドTCPサービスが、元のクライアントIPアドレスを認識するようにします。

→インスタンスIDでターゲットを登録します。ターゲットがIPで登録されている場合は、ターゲットグループでProxy Protocol v2を有効にします。

理由: ターゲットがインスタンスIDで登録されている場合、NLBはデフォルトでクライアントIPを保持します。IPで登録されている場合、NLBのIPがソースとなり、元のIPを渡すにはProxy Protocol v2が必要です。

複数のDirect Connectパスが存在する場合に、AWSがオンプレミスネットワークにトラフィックを戻す方法に影響を与えます。

→オンプレミスルーターからの優先度の低いパスでBGP ASパスプリペンドを使用します。

理由: AWSからのアウトバウンドトラフィックの場合、顧客が制御できる主要なメカニズムはASパスの長さです。AWSは最短ASパスを持つパスを優先します。AWS側でローカルプリファレンスを設定することはできません。

AWS Organizationsのスポークアカウントが、中央のネットワーキングアカウントが所有するTransit GatewayにVPCをアタッチできるようにします。

→AWS Resource Access Manager (RAM) を使用します。ネットワーキングアカウントは、Transit GatewayをOrganizationまたは特定のOUと共有します。

理由: RAMは、Transit Gatewayなどのリソースをアカウント間で共有するために設計された特定のAWSサービスです。これにより、一元管理が可能になり、スポークアカウントのセルフサービスアタッチメントが有効になります。

単一のVPNトンネルの1.25 Gbpsの制限を超えるスループットを集約します。

→ECMPが有効なTransit Gatewayに対して、複数のSite-to-Site VPN接続を作成します。

理由: 各VPNトンネルは約1.25 Gbpsに制限されています。スケーリングするには、複数のトンネル/接続を使用し、Transit GatewayでECMPを活用してそれらの間でトラフィックをロードバランスする必要があります。

内部の、インターネットに面していないリソース（内部ALBなど）に対してRoute 53ヘルスチェックを設定します。

→内部リソースのメトリクス（例：ALBの`HealthyHostCount`）を監視するCloudWatchアラームを作成します。Route 53ヘルスチェックを、CloudWatchアラームの状態を監視するように設定します。

理由: Route 53のヘルスチェッカーは外部にあります。内部リソースを監視するには、内部メトリクスによってトリガーされるCloudWatchアラームの状態のようなプロキシシグナルを監視する必要があります。

プライマリオリジン（ALBなど）が5xxエラーを返した場合に、CloudFrontトラフィックを自動的にセカンダリオリジン（静的S3サイトなど）にフェイルオーバーします。

→ALBをプライマリ、S3をセカンダリとするCloudFrontオリジングループを作成します。指定されたステータスコード（例：500、502、503、504）でフェイルオーバーするように設定します。

理由: オリジングループはCloudFrontネイティブの高可用性メカニズムであり、DNSの変更を必要とせずにエッジでのシームレスなフェイルオーバーを提供します。

バックアップVPNまたはセカンダリDXパスへのDirect Connect接続でサブ秒のフェイルオーバーを実現します。

→Direct Connect仮想インターフェースでBidirectional Forwarding Detection (BFD) を有効にします。オンプレミスルーターでBFDを設定します。

理由: BFDはBGPキープアライブタイマー（デフォルト90秒）と比較して、はるかに高速なリンク障害検出（最短300ms）を提供し、迅速なトラフィック再収束を可能にします。

2つの異なるリージョンにあるTransit Gateway間の接続を有効にします。

→Transit Gatewayピアリング接続を確立します。各TGWルートテーブルに、ピアリングアタッチメント経由でリモートリージョンのCIDRを指す静的ルートを手動で追加します。

理由: 重要な点として、Transit Gatewayのリージョン間ピアリングは動的ルート伝播をサポートしていません。すべてのクロスリージョンルートは静的に設定する必要があります。

AWS内での接続問題を、特定のブロックコンポーネント（ルート、NACL、SGなど）を特定することでトラブルシューティングします。

→VPC Reachability Analyzerを使用します。送信元と宛先を指定すると、ネットワークパス構成の静的分析が実行されます。

理由: Reachability Analyzerは、AWSネットワークコンストラクトの確定的かつホップバイホップの分析を提供します。これは、traceroute（機能しない場合がある）や各コンポーネントを手動で確認するよりも効果的です。

コンプライアンスのための詳細なVPC Flow Logsの長期保存とアドホッククエリ。

→フローログをカスタムフィールドレイアウトのParquet形式でS3に直接発行します。SQLベースのアドホッククエリにはAmazon Athenaを使用します。

理由: S3は最もコスト効率の高いストレージです。Parquet形式はAthenaクエリに非常に効率的で、スキャンコストを削減し、パフォーマンスを向上させます。これはフローログ分析のためのサーバーレスでスケーラブルなパターンです。

AWS OrganizationsのすべてのVPCで必須のセキュリティグループルールを一元的に適用し、非準拠を自動修復します。

→セキュリティグループ監査ポリシーを持つAWS Firewall Managerを使用します。必要なルールを定義し、非準拠のグループを自動的に修復するようにポリシーを設定します。

理由: Firewall Managerは、Organization全体でのセキュリティポリシー（WAF、SG、NFW）のための一元的なガバナンスツールです。自動修復機能を備えたその監査ポリシーは、強制的な適用を提供します。

Transit Gateway、VPN、Direct Connectを含むグローバルネットワークトポロジーを、リージョンとアカウントをまたいで視覚化および監視します。

→AWS Network Managerを使用します。Transit Gatewayを単一のグローバルネットワークに登録して、集中型ダッシュボード、トポロジーマップ、およびヘルスモニタリングを取得します。

理由: Network Managerは、複雑なグローバルAWSネットワークに対し、監視と管理を統合する単一の管理画面を提供するために専用に構築されています。

Direct Connect接続での断続的なパケットロスやエラーを診断します。

→Direct ConnectのCloudWatchメトリクス（`ConnectionErrorCount`）を確認します。顧客ルーターで、光信号レベル（Tx/Rx光レベル）とインターフェースエラーカウンター（CRCエラー、入力エラー）を確認します。

理由: パケットロスは物理層の問題である可能性があります。光ファイバーケーブルやトランシーバーの劣化などの問題を特定するには、AWS側のメトリクスと顧客側のルーター診断の両方が必要です。

公開SSHアクセスを許可するセキュリティグループなど、非準拠のネットワーク設定を自動的に検出し、修復します。

→マネージドルール（例：`restricted-ssh`）を備えたAWS Configを使用し、SSM Automationドキュメントを使用して自動修復アクションを設定します。

理由: これにより、クローズドループのコンプライアンスシステムが提供されます。AWS Configが違反を検出し、その修復アクションがSSMドキュメントをトリガーして設定を自動的に修正します。

インターネットやその他の信頼できないネットワークから機密リソースへの意図しないネットワークアクセスパスをプロアクティブに特定します。

→VPC Network Access Analyzerを使用します。アクセススコープを定義し、分析を実行して、一致する可能性のあるすべてのネットワークパスのリストを取得します。

理由: このツールは、すべてのコンポーネント（SG、NACL、TGW、IGW）を分析して潜在的なパスを見つける形式的なネットワーク検証を実行します。これは、手動チェックやリアクティブな監視よりも包括的です。

多数のメンバーアカウントからVPC Flow Logs、DNS Query Logs、およびNetwork Firewallログを中央のログアカウントに収集します。

→メンバーアカウントのサービスを、クロスアカウントバケットポリシーとIAMロールを使用して、ログアカウントの中央S3バケット（Flow Logs/NFW用）またはCloudWatch Log Group（DNSログ用）に直接ログを発行するように設定します。

理由: 直接的なクロスアカウントログ発行は、エージェントや複雑なデータパイプラインを必要とせず、ネイティブのAWS機能を活用するため、最も効率的でスケーラブルなパターンです。

Transit Gatewayのハブアンドスポークアーキテクチャにおける特定のVPCペア間の大容量トラフィックのネットワークコストを最適化します。

→トラフィック量の多いVPCペアについては、Transit Gatewayをバイパスするために直接VPCピアリング接続を作成します。他のすべてのハブアンドスポークトラフィックにはTGWを維持します。

理由: VPCピアリングにはGBあたりのデータ処理料金がかかりませんが（標準データ転送のみ）、Transit Gatewayにはかかります。大量のポイントツーポイントトラフィックをピアリングに移行すると、コストを大幅に削減できます。

ラインレート性能のために、Direct Connectトラフィックをレイヤー2で暗号化します。

→MACsec (IEEE 802.1AE) を有効にします。MACsec対応ロケーションでの専用の10Gbpsまたは100Gbps接続が必要です。

理由: MACsecは顧客ルーターとAWSデバイス間のホップバイホップ暗号化を提供し、最小限のパフォーマンスオーバーヘッドで物理リンクを保護します。

ウェブアプリケーションを一般的な攻撃（SQLi、XSS）から保護し、国によるアクセスを制限します。

→AWS WAFを使用します。ウェブACLをALB/CloudFrontにアタッチします。AWSマネージドルールグループ（例：`AWSManagedRulesSQLiRuleSet`、`AWSManagedRulesCommonRuleSet`）を使用し、ジオマッチルールを作成します。

理由: AWSマネージドルールは一般的な脅威に対するすぐに使える保護を提供し、ジオマッチルールは地理的制御を提供します。これは標準的なWAFの実装パターンです。

VPC内で多層アプリケーション分離（例：Web -> アプリ -> DB）を実装します。

→各階層にセキュリティグループを作成します。ルール内でセキュリティグループID参照を使用します（例：app-sgはweb-sgからのインバウンドを許可する）。

理由: セキュリティグループを参照することは、CIDR範囲を使用するよりも動的で安全です。インスタンスが階層に追加または削除されると自動的に適応します。

DNSトンネリングやC2サーバーとの通信など、DNSベースの脅威を監視および検出します。

→Route 53 Resolverクエリログを有効にします。DNSクエリログをデータソースとして分析するAmazon GuardDutyを有効にします。

理由: GuardDutyには、DNSログを分析して既知の悪意のあるドメイン、DGA、およびデータ流出を示す異常なクエリパターンを検出する組み込みの脅威インテリジェンスがあります。

S3コンテンツがS3 URL経由で直接ではなく、CloudFront経由でのみアクセスできるようにし、他のIAMプリンシパルにはアクセスを許可します。

→Origin Access Control (OAC) を使用します。S3バケットポリシーを更新して、OACサービスプリンシパルおよびその他の必要なIAMロール/ユーザーからのアクセスを許可します。

理由: OACはOAIの現代的な代替です。バケットポリシーで参照できるサービスプリンシパルを作成し、よりきめ細かく柔軟なアクセスコントロールを提供します。

ユーザーがCloudFrontをバイパスしてALBオリジンに直接アクセスするのを防ぎます。

→CloudFrontを設定して、オリジンリクエストに秘密の値を持つカスタムHTTPヘッダーを追加します。このヘッダーと値をチェックし、それを持たないリクエストをブロックするALBリスナールールを作成します。

理由: これは、リクエストが特定のディストリビューションから来たことを検証するため、IPベースの制限（マネージドプレフィックスリストの使用）よりも強力な保護を提供します。多層防御のために両方を使用してください。

エージェントをインストールせずに、特定のEC2インスタンスから完全なネットワークパケットデータをキャプチャしてフォレンジック分析を行います。

→VPC Traffic Mirroringを使用します。インスタンスのENIでミラーセッションを設定し、トラフィックをターゲット（例：分析ツールを前面に出すNLB）にコピーします。

理由: Traffic Mirroringはエージェントレスのフルパケットキャプチャを提供し、これは詳細なフォレンジック分析に不可欠です。フローログはメタデータのみを提供します。

公開向けアプリケーションに対する包括的なDDoS保護を提供します。

→AWS Shield Advancedを購読します。重要なリソース（CloudFront、ALB、EIP、Route 53）に保護を関連付けます。レイヤー7軽減にはAWS WAFを使用します。攻撃時にはShield Response Team (SRT) と連携します。

理由: Shield Advancedは、強化された検出、DDoSによるスケーリングに対するコスト保護、および専門家による支援のためのSRTへのアクセスを提供し、ビジネス上重要なアプリケーションにとって不可欠です。

プライベート証明機関から、内部マイクロサービス用のTLS証明書を発行し、自動的にローテーションします。

→AWS Private Certificate Authority (Private CA) を使用してCAを作成します。AWS Certificate Manager (ACM) を使用して、そのCAからプライベート証明書を発行し、ライフサイクル（自動更新を含む）を管理します。

理由: この組み合わせは、完全に管理されたプライベートPKIソリューションを提供し、公開を伴わない内部証明書の複雑なライフサイクルを自動化します。

AWS Organizationsのどのメンバーアカウントのユーザーも、インターネットゲートウェイを作成またはアタッチできないようにします。

→Organizationのルートで、`ec2:CreateInternetGateway` および `ec2:AttachInternetGateway` アクションを拒否するサービスコントロールポリシー (SCP) を適用します。

理由: SCPは、メンバーアカウント内のIAMポリシーによって上書きできない予防的なガードレールを提供し、組織全体のセキュリティポリシーを強制するための決定的なツールとなります。

AWS Network Firewallを使用してHTTPSトラフィックを復号化し、脅威がないか検査してから再暗号化します。

→ACMでCA証明書を作成またはインポートします。このCAを参照するTLS検査設定をファイアウォールポリシーに作成します。CA証明書を信頼されたルートCAとしてクライアントシステムに配布します。

理由: Network Firewallは、提供されたCAを使用して証明書をその場で再署名する中間者攻撃的なアプローチでTLS検査を実行します。クライアントは証明書エラーを避けるためにこのCAを信頼する必要があります。

AWS OrganizationsのすべてのVPCで、既知の悪意のあるドメインへのDNSクエリをブロックします。

→AWSマネージドドメインリストを使用して、中央アカウントでDNS Firewallルールグループを作成します。RAMを介してルールグループを共有し、メンバーアカウントのVPCに関連付けます。

理由: DNS Firewallは、DNS解決層で悪意のあるドメインをブロックするための管理された、一元的に更新可能な脅威インテリジェンスを提供し、これは重要なセキュリティ制御です。

アプリケーションの変更なしに、同じVPC内のEC2インスタンス間のすべてのネットワークトラフィックを暗号化します。

→AWS Nitro Systemベースのインスタンスタイプを使用します。

理由: Nitroインスタンスは、インスタンス間のすべてのトラフィックをハードウェアレベルで自動的に暗号化し、設定不要で透過的でラインレートの暗号化を提供します。