A collection of notes and resources
問題 13 不正解 会社は、パブリックサブネット内の複数の Amazon EC2 インスタンス上で複数のワークロードを実行しています。最近の事例では、攻撃者が EC2 インスタンスの 1 つでアプリケーションの脆弱性を悪用してインスタンスにアクセスしました。会社はアプリケーションを修正し、更新されたアプリケーションを含む代替 EC2 インスタンスを起動しました。攻撃者は侵害されたアプリケーションを使用してインターネット経由でマルウェアを拡散しました。会社は AWS からの通知を通じて侵害を認識しました。会社は EC2 インスタンスにデプロイされたアプリケーションがマルウェアを拡散している場合に識別する能力が必要です。最も運用負荷の少ない解決策はどれですか？ 送信トラフィックのディープパケット検査を行うために Amazon Inspector を設定する。 説明
不正解 Amazon Inspector は主に EC2 インスタンス内の脆弱性評価とコンプライアンス検証に焦点を当てたサービスです。Amazon Inspector には送信トラフィックのディープパケット検査を行う機能はありません。このサービスはホスト上の脆弱性スキャンに使用されるもので、ネットワークトラフィックの監視や分析には設計されていません。 回答は不正解です 最新のマルウェアシグネチャを備えた AWS 管理のおとりシステムをデプロイするために Amazon GuardDuty を使用する。 説明
不正解 GuardDuty は AWS 管理のおとりシステム（デコイシステム）をデプロイする機能を持っていません。GuardDuty は主に既存の AWS サービスからのログと情報を分析することで脅威を検出します。この選択肢は存在しない機能を説明しているため不正解です。 正解 DNS リクエストと VPC フローログを検査することでトラフィックパターンを分析するために Amazon GuardDuty を使用する。 説明
正解 Amazon GuardDuty は、複数のデータソース（Amazon CloudTrail、DNS クエリ、VPC フローログなど）から情報を収集し、機械学習やその他の手法を使用して異常なネットワークトラフィックパターンを検出します。GuardDuty はこれらの基本データソースを使用して、既知の悪意のあるドメインや IP アドレスとの通信を検出し、潜在的に異常な動作や不正な活動を特定します。これにより、マルウェアの拡散を示す可能性のあるトラフィックパターンを識別できます。セットアップが最小限で済み、フルマネージドサービスであるため運用負荷が最も少ないソリューションです。 Gateway Load Balancer を設定する。トラフィック検査のために AWS Marketplace から EC2 上で侵入検知システム（IDS）アプライアンスを実行する。 説明
不正解 Gateway Load Balancer を設定し、侵入検知システム（IDS）アプライアンスを実行する方法は、マルウェア拡散を検出できますが、追加のインフラストラクチャをデプロイおよび管理する必要があるため、運用負荷が高くなります。設定、メンテナンス、スケーリングの管理が必要で、GuardDuty よりも複雑な設定が必要です。 全体的な説明 問われている要件 この問題では、会社が以下の要件を持っています： EC2 インスタンスにデプロイされたアプリケーションがマルウェアを拡散している場合に識別する能力 運用負荷が最小限であること 前提知識 Amazon GuardDuty Amazon GuardDuty は、AWS 環境内の悪意のあるアクティビティや不正な動作を継続的に監視し、検出するフルマネージドの脅威検出サービスです。GuardDuty は機械学習、異常検出、脅威インテリジェンスを使用して、AWS 環境内で潜在的に悪意のあるアクティビティや疑わしいアクティビティを検出します。 GuardDuty の主要な機能と特徴： データソース： GuardDuty の基本データソースには、AWS CloudTrail 管理イベントログ、VPC フローログ、DNS クエリログが含まれます。これらのデータソースを分析して、既知の悪意のあるドメインや IP アドレスとの通信、異常なネットワークトラフィックパターン、不正なアクティビティなどを検出します。 マルウェア検出： GuardDuty は EC2 インスタンスが DNS クエリを使用して外部データ転送を行うマルウェアを実行している場合に検出し、このタイプのデータ転送はインスタンスが侵害されていることを示し、データ流出につながる可能性があることを通知します。 運用の容易さ： GuardDuty は設定が簡単で、有効にするとすぐに分析を開始します。追加のインフラストラクチャやエージェントのデプロイは必要ありません。AWS Management Console、API、または CLI を通じて管理できます。 自動脅威検出： GuardDuty は、マシンラーニングや異常検出などの組み込みの検出技術を使用し、これらの検出アルゴリズムは AWS セキュリティチームによって継続的に維持・改善されています。 多層的な保護： 基本的な脅威検出に加えて、GuardDuty は S3 保護、EKS 保護、EC2/ECS ランタイムモニタリング、マルウェア保護、RDS 保護などの特化した保護プランも提供しています。 VPC フローログ VPC フローログは、VPC 内のネットワークインターフェースとの間で送受信される IP トラフィックに関する情報をキャプチャする AWS のサービスです。フローログデータを使用して、異常なトラフィックパターン、セキュリティ問題、過剰なトラフィックなどのネットワーク関連の問題を診断できます。 GuardDuty は VPC フローログを使用して、以下のような悪意のあるアクティビティを検出します： 異常に高いボリュームのネットワークトラフィック 既知の悪意のある IP アドレスとの通信 不審なポートへのアクセス 分散型サービス拒否（DDoS）攻撃のパターン DNS クエリログ DNS クエリログは、EC2 インスタンスからの DNS リクエストの記録です。GuardDuty はこれらのログを使用して、以下のような悪意のあるアクティビティを検出します： 既知のコマンド＆コントロール（C&C）サーバーへの通信 ドメイン生成アルゴリズム（DGA）を使用するマルウェア DNS を使用したデータ流出 不審なドメイン名へのリクエスト その他のソリューション Gateway Load Balancer + IDS： Gateway Load Balancer は、サードパーティのネットワークバーチャルアプライアンスをデプロイして管理するためのサービスです。侵入検知システム（IDS）アプライアンスを実行して、ネットワークトラフィックを検査し、マルウェアアクティビティを検出できます。ただし、このソリューションには、アプライアンスのデプロイ、設定、維持、およびトラフィックルーティングの管理が必要です。 Amazon Inspector： Amazon Inspector は、EC2 インスタンスとコンテナの脆弱性管理に特化したサービスです。主にホストレベルの脆弱性評価とコンプライアンス検証に焦点を当てており、ネットワークトラフィックの検査やマルウェアアクティビティの検出には設計されていません。
解くための考え方 この問題を解くには、各選択肢がマルウェア拡散の検出にどのように役立つか、およびそれぞれの運用負荷を評価する必要があります。 「Amazon GuardDuty を使用して DNS リクエストと VPC フローログを検査することでトラフィックパターンを分析する」アプローチには、以下の利点があります： 最小限の設定：GuardDuty は有効にするだけで、すぐに VPC フローログと DNS クエリを分析し始めます。追加のインフラストラクチャをデプロイしたり、複雑な設定を行ったりする必要はありません。 リアルタイム検出：GuardDuty は継続的に監視を行い、マルウェアの拡散を示す可能性のある不審なトラフィックパターンをリアルタイムで検出します。 フルマネージド：GuardDuty は AWS によって管理されており、ユーザーはインフラストラクチャやソフトウェアの更新を気にする必要がありません。 スケーラビリティ：GuardDuty は自動的にスケールし、AWS 環境の成長に合わせて対応します。 他の選択肢と比較して、GuardDuty は設定が最も簡単で、運用負荷が最も少ないソリューションです。 参考資料 Amazon GuardDuty Amazon GuardDuty ユーザーガイド VPC フローログ Amazon GuardDuty の検出結果タイプ GuardDuty のデータソース 問題 16 不正解 ある会社がエンドツーエンドの暗号化通信が必要なサービスを計画しています。このサービスは gRPC プロトコルを TCP ポート 443 で利用し、クライアントとバックエンド間の通信を復号化せず、数千の同時接続をサポートする必要があります。バックエンドは Kubernetes Cluster Autoscaler と Horizontal Pod Autoscaler が設定された Amazon EKS クラスターでホストされ、クライアントとバックエンド間では相互 TLS による双方向認証が必要です。どのソリューションがこれらの要件を満たすでしょうか？ AWS Load Balancer Controller for Kubernetes をインストールし、Application Load Balancer を設定して HTTPS リスナーでポート 443 のトラフィックをバックエンドサービス Pod の IP アドレスに転送する 説明
不正解: この方法では、ALB が HTTPS トラフィックを終端（復号化）してしまうため、クライアントとバックエンド間でトラフィックが復号化されないという要件を満たせません。ALB は L7（アプリケーション層）で動作するため、トラフィックを検査するために復号化が必要です。 正解 AWS Load Balancer Controller for Kubernetes をインストールし、Network Load Balancer を設定して TCP リスナーでポート 443 のトラフィックをバックエンドサービス Pod の IP アドレスに転送する 説明
正解: AWS Load Balancer Controller for Kubernetes をインストールし、Network Load Balancer を設定して TCP リスナーでポート 443 のトラフィックをバックエンドサービス Pod の IP アドレスに転送する方法が最適です。NLB は TCP レベルで動作するため、トラフィックを復号化せずにそのまま転送できます。これにより、エンドツーエンドの暗号化が維持され、相互 TLS 認証が適切に機能します。 回答は不正解です ターゲットグループを作成し、EKS マネージドノードグループの Auto Scaling グループをターゲットとして追加、Network Load Balancer を作成して TLS リスナーでポート 443 のトラフィックをターゲットグループに転送する 説明
不正解: この方法は NLB を使用していますが、TLS リスナーを指定しているため、NLB で TLS が終端されてしまいます。これにより、クライアントとバックエンド間でトラフィックが復号化されるため、要件を満たせません。また、ノードの Auto Scaling グループをターゲットにすることで、Pod への直接ルーティングができず、効率的なスケーリングが難しくなります。 ターゲットグループを作成し、EKS マネージドノードグループの Auto Scaling グループをターゲットとして追加、Application Load Balancer を作成して HTTPS リスナーでポート 443 のトラフィックをターゲットグループに転送する 説明
不正解: この方法には 2 つの問題があります。まず、ALB を使用しているため HTTPS トラフィックが終端され、クライアントとバックエンド間でトラフィックが復号化されてしまいます。さらに、ノードの Auto Scaling グループをターゲットにすると、トラフィックはノードレベルで終端し、Pod に直接ルーティングされないため、効率的なスケーリングが難しくなります。 全体的な説明 問われている要件 この問題では、以下の要件が提示されています： クライアントとバックエンド間のトラフィックは復号化されない（エンドツーエンド暗号化） gRPC プロトコルを TCP ポート 443 で使用 数千の同時接続をサポート 相互 TLS（mTLS）による双方向認証が必要 EKS クラスターで Kubernetes Cluster Autoscaler と Horizontal Pod Autoscaler を使用 前提知識 相互 TLS（mTLS） 相互 TLS（Mutual TLS）は、クライアントとサーバーの両方が証明書を使用して互いを認証する仕組みです。通常の TLS ではクライアントがサーバーを認証しますが、mTLS ではサーバーもクライアントを認証します。 具体的なフロー： クライアントがサーバーに接続を要求する サーバーは自身の証明書をクライアントに送信 クライアントはサーバーの証明書を検証 サーバーはクライアントに証明書の提示を要求 クライアントは自身の証明書をサーバーに送信 サーバーはクライアントの証明書を検証 双方の検証が成功すると暗号化された通信が開始される mTLS はマイクロサービスアーキテクチャ、ゼロトラストセキュリティモデル、API セキュリティなどで広く使用されています。 ロードバランサーの種類と特性 Network Load Balancer (NLB): OSI モデルのレイヤー 4（トランスポート層）で動作 TCP/UDP トラフィックを処理 パケットの内容を検査せず、ヘッダー情報のみに基づいてルーティング 暗号化されたトラフィックをそのまま通過させることが可能 レイテンシーが低く、高スループットを実現 静的 IP アドレスを提供可能 TCP/TLS リスナーをサポート Application Load Balancer (ALB): OSI モデルのレイヤー 7（アプリケーション層）で動作 HTTP/HTTPS トラフィックを処理 パケットの内容を検査してルーティング決定 HTTPS トラフィックを終端（復号化）して処理する必要がある パスベースのルーティング、ホストベースのルーティングなど高度な機能を提供 WebSocket や gRPC などのプロトコルもサポート リスナーの種類と機能 TCP リスナー（NLB）: 暗号化されたトラフィックをそのまま転送（パススルーモード） TLS 終端を行わない（復号化しない） エンドツーエンドの暗号化を維持 TLS リスナー（NLB）: ロードバランサーで TLS 終端を行う トラフィックを復号化してから転送 バックエンドへの再暗号化のオプションあり HTTPS リスナー（ALB）: ロードバランサーで HTTPS 終端を行う トラフィックを復号化して内容を検査 バックエンドへは HTTP または HTTPS で転送 AWS Load Balancer Controller for Kubernetes これは Kubernetes 用のコントローラーで、Kubernetes リソースと AWS ロードバランサーリソースを連携させます。主な機能： Kubernetes Service Type=LoadBalancer に対して NLB を自動プロビジョニング Kubernetes Ingress リソースに対して ALB を自動プロビジョニング ターゲットタイプとしてインスタンスまたは IP を選択可能 Pod への直接ルーティング（IP mode）をサポート Kubernetes 用のロードバランサーカスタムリソース定義（CRD）を提供 gRPC プロトコル gRPC は Google が開発したオープンソースの RPC（Remote Procedure Call）フレームワークです。特徴： HTTP/2 プロトコル上で動作 Protocol Buffers を使用した効率的なシリアライゼーション 双方向ストリーミングをサポート 複数のプログラミング言語に対応 低レイテンシーの通信に適している TLS/SSL で暗号化できる Kubernetes Autoscaling Horizontal Pod Autoscaler (HPA): ワークロードの CPU/メモリ使用率や他のメトリクスに基づいて Pod の数を自動調整 リソース使用率が高い場合に Pod を追加し、低い場合に削除 Deployment、ReplicaSet、StatefulSet などのリソースに適用可能 Cluster Autoscaler: クラスター内のノード数を自動調整 ノードが低使用率の場合にノードを削除 AWS では Auto Scaling Group と連携して動作 解くための考え方 この問題を解決するには、以下の観点から分析する必要があります： 暗号化要件の分析: エンドツーエンド暗号化が必要（途中で復号化しない） 相互 TLS 認証が必要 ロードバランサーの選定: 暗号化トラフィックを復号化せずに転送するには、NLB がより適切 リスナーは TCP タイプが必要（TLS リスナーだと復号化される） ターゲットタイプの検討: Pod へ IP ベースで直接ルーティングすると、よりきめ細かいスケーリングが可能 ノードグループをターゲットにすると、追加の転送が必要になる Kubernetes との統合: AWS Load Balancer Controller を使用すると、Kubernetes リソースと AWS リソースの管理が容易になる Horizontal Pod Autoscaler と Cluster Autoscaler との連携がスムーズになる 正しいソリューションは、NLB と TCP リスナーの組み合わせを使用し、AWS Load Balancer Controller を介して Pod IP に直接トラフィックをルーティングする方法です。これにより、トラフィックの復号化なしにエンドツーエンドの暗号化が維持され、相互 TLS 認証が適切に機能します。
参考資料 AWS Load Balancer Controller - Amazon EKS Network Load Balancer - Elastic Load Balancing 相互 TLS 認証 - AWS App Mesh Amazon EKS の Pod とノードのスケーリング 問題 17 不正解 ある小売企業が AWS でサービスを運用しています。同社のアーキテクチャには、パブリックサブネットに Application Load Balancer（ALB）が含まれています。ALB のターゲットグループは、プライベートサブネット内のバックエンド Amazon EC2 インスタンスにトラフィックを送信するように構成されています。これらのバックエンド EC2 インスタンスは、NAT ゲートウェイを使用してインターネット経由で外部ホストされたサービスを呼び出すことができます。同社は請求書で NAT ゲートウェイの使用量が大幅に増加していることに気付きました。ネットワークエンジニアはこの使用量増加の原因を突き止める必要があります。ネットワークエンジニアは NAT ゲートウェイを通過するトラフィックを調査するために、どの方法を利用できますか？（2 つ選択してください） NAT ゲートウェイの Elastic Network Interface で Traffic Mirroring を構成します。トラフィックを追加の EC2 インスタンスに送信します。tcpdump や Wireshark などのツールを使用して、ミラーリングされたトラフィックのクエリと分析を行います。 説明
不正解 Traffic Mirroring は技術的に可能ですが、NAT ゲートウェイの使用量増加の原因を特定するには過剰な方法です。パケットレベルでの詳細な分析は必要なく、追加の EC2 インスタンスのセットアップと維持が必要になり、コストと複雑さが増します。 NAT ゲートウェイアクセスログを有効にします。ログを Amazon CloudWatch Logs のロググループに発行します。CloudWatch Logs Insights を使用してログのクエリと分析を行います。 説明
不正解 「NAT ゲートウェイアクセスログ」は AWS のネイティブ機能として存在しません。NAT ゲートウェイのトラフィックを監視するには、VPC フローログを使用する必要があります。 正しい選択 NAT ゲートウェイの Elastic Network Interface で VPC フローログを有効にします。ログを Amazon CloudWatch Logs のロググループに発行します。CloudWatch Logs Insights を使用してログのクエリと分析を行います。 説明
正解 NAT ゲートウェイには Elastic Network Interface（ENI）があり、そこで VPC フローログを有効にすることができます。CloudWatch Logs を使用してこれらのログを保存し、CloudWatch Logs Insights を使用して分析することは、NAT ゲートウェイのトラフィックを調査するための有効な方法です。 選択は不正解です NAT ゲートウェイアクセスログを有効にします。ログを Amazon S3 バケットに発行します。ログ構造を記述するために S3 バケットのカスタムテーブルを Amazon Athena で作成します。Athena を使用してログのクエリと分析を行います。 説明
不正解 「NAT ゲートウェイアクセスログ」は AWS のネイティブ機能として存在しないため、この選択肢は無効です。 選択は正解です NAT ゲートウェイの Elastic Network Interface で VPC フローログを有効にします。ログを Amazon S3 バケットに発行します。ログ構造を記述するために S3 バケットのカスタムテーブルを Amazon Athena で作成します。Athena を使用してログのクエリと分析を行います。 説明
正解 VPC フローログを S3 バケットに発行し、Athena を使用して分析することは、NAT ゲートウェイのトラフィックを調査するためのもう一つの有効なアプローチです。特に大量のログデータを長期間保存して分析する必要がある場合に適しています。 全体的な説明 問われている要件 この問題では、NAT ゲートウェイの使用量が大幅に増加している原因を特定するために、ネットワークエンジニアがどのような方法で NAT ゲートウェイを通過するトラフィックを調査できるかを問われています。 前提知識 NAT ゲートウェイとは NAT（Network Address Translation）ゲートウェイは、プライベートサブネット内のリソースがインターネットや他の AWS サービスに接続できるようにする AWS のマネージドサービスです。NAT ゲートウェイの主な機能は： プライベートサブネット内のインスタンスからのアウトバウンドトラフィックを可能にする インターネットからのインバウンド接続を防ぐ 高可用性と冗長性を提供する 帯域幅に応じて自動的にスケールする NAT ゲートウェイは使用データ処理量と使用時間に基づいて課金されるため、トラフィック量の増加は直接的にコスト増加につながります。
VPC フローログ VPC フローログは、VPC 内のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャするための AWS の機能です。フローログの主な特徴は： ネットワークトラフィックのモニタリング、トラブルシューティング、最適化に役立つ VPC、サブネット、またはネットワークインターフェイスレベルで有効化できる 以下のような情報を記録： 送信元と宛先の IP アドレス 送信元と宛先のポート プロトコル パケット数とバイト数 トラフィックの許可/拒否 CloudWatch Logs または S3 バケットに送信可能 デフォルトでは有効になっていない CloudWatch Logs と Athena CloudWatch Logs と Athena はどちらも AWS のログ分析ツールですが、異なる特性と用途があります： CloudWatch Logs Insights： リアルタイムログモニタリングと分析 クエリ言語によるログの検索と分析 ダッシュボードとアラームの作成 比較的短期間のログ分析に適している Amazon Athena： S3 に保存されたデータに対するサーバーレスのインタラクティブなクエリサービス 標準 SQL を使用してデータをクエリできる 非常に大規模なデータセットに対して効率的に動作 カスタムテーブルの作成とスキーマの定義が可能 長期的なログ保持と複雑なクエリに適している 解くための考え方 この問題の解決策を選ぶ際には、以下の点を考慮する必要があります： 有効な AWS 機能であるか： 選択されたソリューションは AWS で実際に利用可能な機能でなければなりません。「NAT ゲートウェイアクセスログ」は AWS のネイティブ機能として存在しないため、除外されます。 効率性とコスト： Traffic Mirroring とパケットキャプチャは技術的には可能ですが、NAT ゲートウェイの使用量増加を調査するには過剰なソリューションです。このアプローチでは追加の EC2 インスタンスが必要となり、コストと管理オーバーヘッドが増加します。 ログの保存と分析： VPC フローログの保存と分析には、CloudWatch Logs と S3+Athena の 2 つの主要なオプションがあります： CloudWatch Logs：リアルタイム分析と短期間のログストレージに適しています。 S3+Athena：大量のデータの長期保存と複雑なクエリに適しています。 参考資料 VPC で NAT ゲートウェイのトラフィックソースを見つける方法 VPC フローログを使用した IP トラフィックのログ記録 Amazon CloudWatch Logs Insights を使用したログデータの分析 Amazon Athena を使用した VPC フローログの分析 問題 22 不正解 ある国際企業が非本番環境を 3 つの AWS リージョン（eu-west-1、us-east-1、us-west-1）で運用しています。この企業は本番ワークロードを 2 つのオンプレミスデータセンターでホストしています。企業には 60 の AWS アカウントがあり、アカウントごとに各リージョンに 2 つの VPC があります。各 VPC には、データセンターへの冗長接続のために 2 つの VPN 接続を終端する仮想プライベートゲートウェイがあります。そのため企業は各データセンターへ 360 個の VPN トンネルを持ち、管理の負担が大きくなっています。各リージョンの VPN スループットの合計は 500 Mbps です。 この企業は本番環境を AWS に移行したいと考えています。ネットワークアーキテクチャを簡素化し、将来的な成長に対応できるソリューションが必要です。本番環境では、リージョンごとに 2 Gbps の追加トラフィックがデータセンターに戻され、このトラフィック量は時間とともに増加します。 これらの要件を満たすソリューションはどれですか。 回答は不正解です 各リージョンの各データセンターから AWS への Direct Connect 接続を設定します。単一の Direct Connect ゲートウェイにプライベート VIF を作成し、接続します。その Direct Connect ゲートウェイをすべての VPC に接続します。仮想プライベートゲートウェイに直接接続されている既存の VPN 接続を削除します。 説明
不正解 Direct Connect Gateway は VPC への接続数に制限があり、1 つの Direct Connect Gateway では最大 20 個の仮想プライベートゲートウェイ（VGW）しか接続できません。この場合、60 アカウント ×2 VPC×3 リージョン=360 個の VPC があるため、単一の Direct Connect Gateway では対応できません。 各データセンターからの VPN 接続を備えた単一のトランジットゲートウェイを作成します。AWS Resource Access Manager（AWS RAM）を使用して、各アカウントでトランジットゲートウェイを共有します。トランジットゲートウェイを各 VPC に接続します。仮想プライベートゲートウェイに直接接続されている既存の VPN 接続を削除します。 説明
不正解 Transit Gateway はリージョンリソースであるため、単一の Transit Gateway で複数のリージョンにまたがる VPC を接続することはできません。この選択肢では、単一の Transit Gateway を使用していますが、3 つの異なるリージョン（eu-west-1、us-east-1、us-west-1）にある VPC を接続する必要があり、リージョンをまたいだ接続には対応できません。 正解 各リージョンにトランジットゲートウェイを作成し、各データセンターから複数の新規 VPN 接続を作成します。AWS Resource Access Manager（AWS RAM）を使用して、各アカウントでトランジットゲートウェイを共有します。各リージョンで、トランジットゲートウェイを各 VPC にアタッチします。仮想プライベートゲートウェイに直接アタッチされている既存の VPN 接続を削除します。 説明
正解 各リージョンに個別の Transit Gateway を作成することで、リージョンごとの VPC を効率的に接続できます。Transit Gateway は AWS RAM を使用して複数アカウントで共有でき、VPC アタッチメントも可能です。また、Transit Gateway は複数の VPN トンネルを集約でき、ECMP ルーティングにより最大 50Gbps までスループットを拡張できるため、将来的な成長（リージョンごとに 2Gbps 以上）にも対応可能です。各データセンターからリージョンごとの Transit Gateway へ接続することで、VPN 接続数を大幅に削減でき、管理オーバーヘッドを軽減できます。 各リージョン内のすべての VPC を、各リージョン内の新しい VPC（集中型トランジット VPC として機能する）にピアリング接続します。各データセンターからトランジット VPC への新しい VPN 接続を作成します。すべての元の VPC に接続されている元の VPN 接続を終了します。各リージョンの新しいトランジット VPC への新しい VPN 接続は保持します。 説明
不正解 VPC ピアリングでは推移的ルーティングがサポートされていないため、トランジット VPC を経由してオンプレミスデータセンターに接続することはできません。つまり、VPC A がトランジット VPC とピアリングされ、トランジット VPC がオンプレミスへの VPN 接続を持っていても、VPC A からオンプレミスへのトラフィックはルーティングできません。そのため、この設計では必要な接続を提供できません。 全体的な説明 問われている要件 この問題では以下の要件が問われています： ネットワークアーキテクチャの簡素化 将来の成長に対応できるスケーラビリティ 現在の 360 個の VPN トンネルによる管理オーバーヘッドの削減 リージョンごとに 2Gbps 以上の追加トラフィックを処理する能力 前提知識 Transit Gateway AWS Transit Gateway は、VPC とオンプレミスネットワークを接続するためのネットワークトランジットハブです。Transit Gateway を使用すると、星型トポロジーでネットワークを接続でき、複雑なピアリング関係を排除できます。ただし、Transit Gateway はリージョンリソースであるため、単一の Transit Gateway で異なるリージョンの VPC を接続することはできません。 Transit Gateway の主な特徴： リージョンごとに作成する必要がある AWS RAM を使用して複数のアカウントで共有可能 複数の VPN 接続を集約して高いスループットを実現可能（ECMP ルーティングにより最大 50Gbps） 数百の VPC を接続可能 Direct Connect Gateway AWS Direct Connect Gateway は、オンプレミスネットワークと複数の VPC を高帯域幅、低レイテンシーで接続するためのグローバルリソースです。しかし、1 つの Direct Connect Gateway に接続できる仮想プライベートゲートウェイ（VGW）の数は最大 20 個という制限があります。 VPC ピアリング VPC ピアリングは 2 つの VPC 間の直接的なネットワーク接続を提供しますが、推移的ルーティングをサポートしていません。つまり、VPC A が VPC B とピアリングされ、VPC B が VPC C とピアリングされていても、VPC A から VPC C への直接通信はできません。 解決策の考え方 この場合、60 アカウント ×2 VPC×3 リージョン=360 個の VPC があり、単一の Direct Connect Gateway では対応できません。また、Transit Gateway はリージョンリソースであるため、各リージョンに個別の Transit Gateway が必要です。 正解の選択肢では、各リージョンに Transit Gateway を作成し、AWS RAM を使用して各アカウントで共有します。これにより： VPN 接続の数が大幅に削減される（360 個から数個へ） 各リージョンの Transit Gateway で複数の VPN 接続を集約し、ECMP ルーティングにより高いスループット（最大 50Gbps）を実現 AWS RAM による効率的なリソース共有 将来的な成長に対応できるスケーラビリティ この方法は、ネットワークアーキテクチャを簡素化し、管理オーバーヘッドを削減しながら、将来の成長に対応できる柔軟性を提供します。
参考資料 AWS Transit Gateway を使用した VPN トンネルスループットの拡張 Transit Gateway VPN AWS Transit Gateway クォータ AWS Direct Connect サービスの制限 AWS Transit Gateway の共有 VPC ピアリングの制限 問題 28 不正解 セキュリティチームが会社の AWS デプロイメントの監査を行っています。セキュリティチームは、2 つのアプリケーションがネットワーク ACL とセキュリティグループによってブロックされるべきリソースにアクセスしている可能性を懸念しています。アプリケーションは、Kubernetes 用の Amazon VPC Container Network Interface（CNI）プラグインを使用する 2 つの Amazon Elastic Kubernetes Service（Amazon EKS）クラスターにデプロイされています。クラスターは同じ VPC 内の異なるサブネットにあり、Cluster Autoscaler が構成されています。セキュリティチームはどの POD IP アドレスが VPC 全体のどのサービスと通信しているかを判断する必要があります。セキュリティチームはフローログの数を制限し、2 つのアプリケーションからのトラフィックのみを調査したいと考えています。最も運用オーバーヘッドが少ない解決策はどれですか？ デフォルト形式で VPC フローログを作成します。EKS ノードからのフローログのみを収集するフィルターを作成します。フローログに srcaddr フィールドと dstaddr フィールドを含めます。 説明
不正解 デフォルト形式の VPC フローログでは srcaddr と dstaddr フィールドが含まれますが、これらは EKS ノードの IP アドレスのみを示し、POD の IP アドレスは示しません。POD の IP アドレスを確認するためには、pkt-srcaddr と pkt-dstaddr フィールドが必要です。また、EKS ノードからのフローログのみを収集するためのフィルターを作成することはできますが、ノードは Cluster Autoscaler によって動的に増減する可能性があるため、運用オーバーヘッドが大きくなります。 回答は不正解です カスタム形式で VPC フローログを作成します。EKS ノードをリソースとして設定します。フローログに pkt-srcaddr フィールドと pkt-dstaddr フィールドを含めます。 説明
不正解 VPC フローログのリソースとして EKS ノードを直接指定することはできません。VPC フローログを作成する際のリソースとして指定できるのは、VPC、サブネット、またはネットワークインターフェイス（ENI）のみです。そのため、この選択肢は技術的に実現不可能です。 カスタム形式で VPC フローログを作成します。EKS ノードからのフローログのみを収集するフィルターを作成します。フローログに pkt-srcaddr フィールドと pkt-dstaddr フィールドを含めます。 説明
不正解 カスタム形式で VPC フローログを作成し pkt-srcaddr と pkt-dstaddr フィールドを含めることは正しいアプローチですが、VPC フローログのフィルターはリソースを指定するためのものではなく、「受け入れ」、「拒否」、「すべて」のトラフィックを選別するためのものです。EKS ノード自体をフィルターの対象とすることはできません。また、Cluster Autoscaler が構成されているため、ノードは動的に増減する可能性があり、各ノードの ENI に対して個別にフローログを設定する必要が出てくるため、運用オーバーヘッドが大きくなります。 正解 カスタム形式で VPC フローログを作成します。アプリケーションサブネットをリソースとして設定します。フローログに pkt-srcaddr フィールドと pkt-dstaddr フィールドを含めます。 説明
正解 カスタム形式で VPC フローログを作成し、アプリケーションサブネットをリソースとして設定することで、対象の 2 つの EKS クラスターが存在するサブネットのトラフィックのみを監視できます。pkt-srcaddr と pkt-dstaddr フィールドを含めることで、POD の IP アドレスを識別できます。この方法は、Cluster Autoscaler でノードが追加されても新しいノードは同じサブネット内にデプロイされるため、継続的なメンテナンスが不要で運用オーバーヘッドが最も少なくなります。 全体的な説明 問われている要件 この問題では、以下の要件を満たす解決策を選択する必要があります： セキュリティチームが POD IP アドレスが VPC 全体のどのサービスと通信しているかを判断できること フローログの数を制限し、2 つのアプリケーションからのトラフィックのみを調査できること 運用オーバーヘッドが最小限であること 前提知識：VPC フローログ VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャするための機能です。フローログデータは Amazon CloudWatch Logs や Amazon S3 に発行できます。 VPC フローログを作成する際には、以下のようなリソースを対象として指定できます： VPC 全体 サブネット ネットワークインターフェイス（ENI） 重要なのは、「EKS ノード」自体を VPC フローログのリソースとして直接指定することはできないという点です。 前提知識：Amazon EKS と VPC CNI プラグイン Amazon EKS クラスターでは、Kubernetes 用の Amazon VPC CNI プラグインを使用してポッドに IP アドレスを割り当てます。このプラグインは、各 Amazon EC2 ノードに ENI を作成し、それらを EC2 ノードにアタッチします。そして、VPC のプライベート IPv4 または IPv6 アドレスを各ポッドとサービスに割り当てます。 通常の VPC フローログの srcaddr/dstaddr フィールドではノードの IP アドレスしか表示されませんが、カスタムフォーマットで作成した VPC フローログに pkt-srcaddr/pkt-dstaddr フィールドを含めることで、ポッドの IP アドレスを識別できます。 前提知識：Cluster Autoscaler 問題では、EKS クラスターに Cluster Autoscaler が構成されていることが言及されています。Cluster Autoscaler は、ワークロードに基づいてクラスターのサイズを自動的に調整する機能で、必要に応じてノードを追加または削除します。これは運用オーバーヘッドを考慮する上で重要なポイントです。ノードが動的に変化する環境では、個々のノードに対してフローログを設定するよりも、ノードが存在するサブネット全体にフローログを設定する方が管理が容易です。 解答の考え方 最適な解決策は、以下の条件を満たす必要があります： POD の IP アドレスを識別できるよう、pkt-srcaddr と pkt-dstaddr フィールドを含むカスタム形式の VPC フローログを使用する 2 つのアプリケーションが存在する EKS クラスターのみのトラフィックを監視するため、それらのクラスターがデプロイされているサブネットをリソースとして指定する Cluster Autoscaler によるノードの動的な変更に対応できるよう、個々のノードではなくサブネットレベルでフローログを設定する
アプリケーションサブネットをリソースとして設定することで、クラスターが存在するサブネット内のすべてのトラフィックを監視でき、ノードが増減しても追加の設定が不要です。また、pkt-srcaddr と pkt-dstaddr フィールドを含めることで、POD の IP アドレスを特定できます。 参考資料 Amazon VPC のフローログの作成 Amazon EKS クラスターの Amazon VPC CNI プラグインを管理する Using VPC Flow Logs to capture and query EKS network communications Amazon EKS の Cluster Autoscaler について 問題 29 不正解 ある企業は、ネットワークロードバランサー（NLB）の背後にある Amazon EC2 インスタンスでアプリケーションをホストしています。ソリューションアーキテクトは、アプリケーションの可用性を向上させるために、2 つ目のアベイラビリティゾーンに EC2 インスタンスを追加しました。これらのインスタンスは NLB ターゲットグループに追加されましたが、運用チームは、トラフィックが最初のアベイラビリティゾーンのインスタンスにのみルーティングされていることに気づきました。 この問題を解決するための、最も運用効率の高いソリューションは何でしょうか？ NLB でプロキシプロトコルを有効にする 説明
不正解 NLB でプロキシプロトコルを有効にしても、新しいアベイラビリティゾーンにトラフィックがルーティングされる問題は解決しません。プロキシプロトコルは、クライアントの接続情報（IP アドレス、ポートなど）をバックエンドサーバーに渡すためのものであり、トラフィックルーティングの問題とは無関係です。 正解 NLB で新しいアベイラビリティゾーンを有効にする 説明
正解 NLB で新しいアベイラビリティゾーンを有効にすることで、ロードバランサーが両方のアベイラビリティゾーンにトラフィックをルーティングするようになります。NLB 作成時に選択したアベイラビリティゾーン以外にインスタンスを追加しても、NLB がそのアベイラビリティゾーンを認識していなければトラフィックを送信しません。新しいアベイラビリティゾーンを有効にするのは簡単な操作であり、最も運用効率の高いソリューションです。 2 番目のアベイラビリティゾーンのインスタンス用に新しい NLB を作成する 説明
不正解 2 番目のアベイラビリティゾーンのインスタンス用に新しい NLB を作成することは、必要以上に複雑で運用負荷が高くなります。2 つの NLB を管理することになり、トラフィック分散の一貫性が損なわれる可能性があります。また、DNS ラウンドロビンなど追加の設定が必要になるため、運用効率が低下します。 回答は不正解です 両方のアベイラビリティゾーンのインスタンスを含む新しいターゲットグループを作成する 説明
不正解 両方のアベイラビリティゾーンのインスタンスを含む新しいターゲットグループを作成しても、NLB が新しいアベイラビリティゾーンを認識していなければ問題は解決しません。現在のターゲットグループには既に両方のアベイラビリティゾーンのインスタンスが含まれていますが、NLB 自体が新しいアベイラビリティゾーンを認識していないことが問題です。 全体的な説明 問われている要件 この問題では、2 つのアベイラビリティゾーンに分散された EC2 インスタンスに対して、NLB が適切にトラフィックをルーティングしない問題を解決する最も運用効率の高い方法を問われています。具体的には、2 番目のアベイラビリティゾーンに追加されたインスタンスにトラフィックが送られていない問題の解決策を求めています。 前提知識 ネットワークロードバランサー（NLB）の特徴と機能 ネットワークロードバランサー（NLB）は、AWS Elastic Load Balancing サービスの一種で、以下の特徴があります： OSI モデルのレイヤー 4（トランスポート層）で動作： TCP や UDP などのプロトコルを使用 接続のルーティングや処理が高速 超低レイテンシーを提供（数万分の 1 秒レベル） 静的 IP アドレスをサポート： 各アベイラビリティゾーンで静的 IP アドレスを割り当て可能 Elastic IP を割り当てることも可能（固定 IP アドレスの使用） 高性能と拡張性： 毎秒数百万のリクエストを処理可能 急激な負荷変動にも対応 接続の維持： クライアントとの接続を維持 ターゲットインスタンスとの接続を維持 ターゲットグループ： EC2 インスタンス、IP アドレス、または AWS Lambda 関数をターゲットとして登録可能 各ターゲットグループはプロトコルとポート番号で設定 ヘルスチェックの設定が可能 アベイラビリティゾーンと NLB の関係 NLB と複数のアベイラビリティゾーンの関係において、重要なポイントは以下の通りです： NLB 作成時のアベイラビリティゾーン選択： NLB 作成時に、サービスを提供するアベイラビリティゾーンを明示的に選択する必要があります 選択されたアベイラビリティゾーンごとに NLB のノードが作成されます NLB のアベイラビリティゾーン認識： NLB は選択されたアベイラビリティゾーンにのみトラフィックをルーティングします NLB に設定されていないアベイラビリティゾーンのインスタンスには、ターゲットグループに追加されていてもトラフィックが送られません アベイラビリティゾーンの追加： NLB 作成後に新しいアベイラビリティゾーンを追加することが可能です クロスゾーンロードバランシング： NLB ではデフォルトでクロスゾーンロードバランシングが無効になっています 有効にすると、すべてのアベイラビリティゾーンのターゲットに均等にトラフィックを分散します 無効の場合、各アベイラビリティゾーンの NLB ノードは同じゾーン内のターゲットにのみトラフィックを分散します ターゲットグループの機能 ターゲットグループは以下の機能を持ちます： ターゲットの登録： 複数のアベイラビリティゾーンにまたがるターゲット（EC2 インスタンスなど）を登録可能 ターゲットはインスタンス ID、IP アドレス、または Lambda 関数で指定可能 ヘルスチェック： 登録されたターゲットの状態を定期的に確認 異常なターゲットには自動的にトラフィックを送信しない プロトコルとポート： 使用するプロトコル（TCP、UDP、TLS など）とポート番号を指定 すべてのターゲットは同じプロトコルとポートを使用 解くための考え方 この問題を解くためには、NLB のトラフィックルーティングの仕組みを理解することが重要です。 問題の特定： 2 番目のアベイラビリティゾーンに EC2 インスタンスが追加され、ターゲットグループに登録されている しかし、トラフィックが最初のアベイラビリティゾーンのインスタンスにのみルーティングされている これは、NLB が 2 番目のアベイラビリティゾーンを認識していないことを示唆している 解決策の検討： NLB が新しいアベイラビリティゾーンにトラフィックをルーティングするためには、そのアベイラビリティゾーンを認識する必要がある NLB で新しいアベイラビリティゾーンを有効にすることが、最も直接的で運用効率の高い解決策 選択肢の評価： 新しい NLB の作成や新しいターゲットグループの作成は、必要以上に複雑で運用効率が低い プロキシプロトコルの有効化は、この問題とは無関係 NLB とアベイラビリティゾーンの関係
したがって、「NLB で新しいアベイラビリティゾーンを有効にする」が最も運用効率の高いソリューションです。この操作は、AWS マネジメントコンソールや CLI から簡単に実行でき、既存のリソースに変更を加えることなく問題を解決できます。これにより、両方のアベイラビリティゾーンにある EC2 インスタンスにトラフィックがルーティングされ、アプリケーションの可用性が向上します。 参考資料 ネットワークロードバランサーのアベイラビリティーゾーン Elastic Load Balancing とは ネットワークロードバランサーの開始方法 ネットワークロードバランサーのターゲットグループ 問題 41 不正解 ある会社が AWS 上に自動販売機の在庫レベルを追跡し、自動的に補充プロセスを開始するアプリケーションを開発しました。この会社はこのアプリケーションを自動販売機と統合し、世界中の複数の市場に自動販売機を配置する計画です。アプリケーションは us-east-1 リージョンの VPC 内にあり、Application Load Balancer（ALB）の背後にある Amazon Elastic Container Service（Amazon ECS）クラスターで構成されています。自動販売機からアプリケーションへの通信は HTTPS 経由で行われます。会社は AWS Global Accelerator アクセラレーターを使用し、アプリケーションエンドポイントアクセス用に自動販売機内にアクセラレーターの静的 IP アドレスを設定する予定です。アプリケーションはアクセラレーターを介してのみアクセス可能であり、インターネット経由で ALB エンドポイントに直接接続することはできないようにする必要があります。どのソリューションがこれらの要件を満たしますか？ 正解 ALB を VPC のプライベートサブネットに構成する。インターネットゲートウェイを接続するが、サブネットルートテーブルにインターネットゲートウェイを指すルートを追加しない。ALB エンドポイントを含むエンドポイントグループでアクセラレーターを構成する。ALB のセキュリティグループを構成して、ALB リスナーポートでインターネットからのインバウンドトラフィックのみを許可する 説明
正解: ALB を VPC のプライベートサブネットに配置し、インターネットゲートウェイを接続しますが、サブネットルートテーブルにはインターネットゲートウェイへのルートを追加しません。これにより、ALB はインターネットから直接アクセスできなくなります。Global Accelerator はエンドポイントへのルートを持つため、アクセラレーターを介した通信が可能になります。セキュリティグループの設定により、ALB が必要なトラフィックのみを受け入れるようになります。 ALB を VPC のプライベートサブネットに構成する。ALB エンドポイントを含むエンドポイントグループでアクセラレーターを構成する。ALB のセキュリティグループを構成して、ALB リスナーポートでインターネットからのインバウンドトラフィックのみを許可する 説明
不正解: この選択肢では、インターネットゲートウェイの設定について言及していません。Global Accelerator がプライベートサブネット内の ALB と通信するためには、VPC にインターネットゲートウェイが必要です。しかし、サブネットルートテーブルにルートを追加しないことが重要であり、これについての言及がないため要件を満たすことができません。 回答は不正解です ALB を VPC のパブリックサブネットに構成する。インターネットゲートウェイを接続する。サブネットルートテーブルにインターネットゲートウェイを指すルートを追加する。ALB エンドポイントを含むエンドポイントグループでアクセラレーターを構成する。ALB のセキュリティグループを構成して、ALB リスナーポートでアクセラレーターの IP アドレスからのインバウンドトラフィックのみを許可する 説明
不正解: ALB をパブリックサブネットに配置し、インターネットゲートウェイへのルートを追加すると、ALB はインターネットから直接アクセス可能になります。セキュリティグループでアクセラレーターの IP アドレスからのトラフィックのみを許可しても、DNS を介して ALB のパブリックエンドポイントが公開されるため、「インターネット経由で ALB エンドポイントに直接接続することはできないようにする」という要件を満たしません。 ALB を VPC のプライベートサブネットに構成する。インターネットゲートウェイを接続する。サブネットルートテーブルにインターネットゲートウェイを指すルートを追加する。ALB エンドポイントを含むエンドポイントグループでアクセラレーターを構成する。ALB のセキュリティグループを構成して、ALB リスナーポートでアクセラレーターの IP アドレスからのインバウンドトラフィックのみを許可する 説明
不正解: ALB をプライベートサブネットに配置していますが、サブネットルートテーブルにインターネットゲートウェイへのルートを追加しています。これにより、このサブネットは実質的にパブリックサブネットとなり、ALB がインターネットと直接通信可能になります。セキュリティグループの制限はありますが、ALB の DNS 名が公開されているため、「インターネット経由で ALB エンドポイントに直接接続することはできないようにする」という要件を満たしません。 全体的な説明 問われている要件 この問題では、以下の主要な要件が提示されています： 自動販売機の在庫追跡アプリケーションが AWS の us-east-1 リージョンに配置されている アプリケーションは ALB の背後にある ECS クラスターで構成されている 自動販売機との通信は HTTPS 経由で行われる AWS Global Accelerator を使用して自動販売機からアプリケーションにアクセスする アプリケーションはアクセラレーターを介してのみアクセス可能であり、ALB への直接インターネット接続は不可 前提知識 AWS Global Accelerator AWS Global Accelerator は、グローバルなユーザーにアプリケーションを提供するためのネットワークサービスです。主な特徴： 静的 IP アドレスを提供し、アプリケーションの耐障害性を向上 AWS のグローバルネットワークを活用して、トラフィックをエッジロケーションで受け取り、最適な AWS リージョンにルーティング クライアントからアプリケーションエンドポイントまでのパフォーマンスを向上 ヘルスチェックによる高可用性の実現 エンドポイントとして、ALB、NLB、EC2 インスタンス、Elastic IP アドレスをサポート Global Accelerator の動作の仕組み： ユーザーは Global Accelerator に割り当てられた静的 IP アドレスに接続 トラフィックは最も近い AWS エッジロケーションに入る AWS のプライベートネットワーク内でトラフィックをルーティング 設定されたエンドポイント（この場合は ALB）にトラフィックを転送 重要な点として、Global Accelerator はプライベートサブネット内のエンドポイントにもトラフィックをルーティングできます。 VPC のサブネットタイプ パブリックサブネット: インターネットゲートウェイへのルートを持つサブネットルートテーブルが設定されている リソースは直接インターネットと通信可能 通常、パブリック IP アドレスを持つリソースをホスト プライベートサブネット: インターネットゲートウェイへのルートを持たない リソースは直接インターネットと通信できない インターネットへの送信トラフィックは NAT ゲートウェイなどを経由 Application Load Balancer (ALB) ALB はレイヤー 7（アプリケーション層）のロードバランサーで、以下の特徴があります： HTTP/HTTPS トラフィックのルーティングに最適化 パスベース、ホストベースのルーティングをサポート ECS のようなコンテナベースのアプリケーション用の統合機能 プライベートサブネットにも配置可能 セキュリティグループを使用してトラフィックを制御 AWS セキュリティグループ セキュリティグループは VPC リソースへのインバウンドおよびアウトバウンドトラフィックを制御する仮想ファイアウォールです： インスタンスレベルで動作（サブネットレベルではない） ステートフル（許可された着信トラフィックの応答は自動的に許可） 許可ルールのみをサポート（拒否ルールはなし） 特定の IP アドレスまたは CIDR ブロックからのトラフィックを許可または制限可能 解くための考え方 この問題を解決するためには、以下の点を検討する必要があります： ALB の配置場所: ALB をパブリックサブネットに配置すると、インターネットからの直接アクセスが可能になる ALB をプライベートサブネットに配置すると、インターネットからの直接アクセスを防げる Global Accelerator との連携: Global Accelerator は AWS のバックボーンネットワークを使用するため、プライベートサブネット内のエンドポイントにもトラフィックをルーティングできる ただし、VPC にはインターネットゲートウェイが接続されている必要がある ルートテーブルの設定: プライベートサブネットのルートテーブルにインターネットゲートウェイへのルートを追加しないことが重要 これにより、インターネットから直接 ALB にアクセスすることを防ぎながら、Global Accelerator からのトラフィックを許可できる セキュリティグループの設定: ALB のセキュリティグループで、適切なポートとソース IP アドレスを制限する必要がある 理想的には、Global Accelerator の特定の IP アドレスからのトラフィックのみを許可するべき 最適な解決策は、ALB をプライベートサブネットに配置し、VPC にインターネットゲートウェイを接続しますが、プライベートサブネットのルートテーブルにはインターネットゲートウェイへのルートを追加しません。これにより、ALB はインターネットから直接アクセスできなくなりますが、Global Accelerator はプライベートネットワークを介して ALB と通信できます。さらに、ALB のセキュリティグループを適切に設定して、必要なトラフィックのみを許可します。
参考資料 AWS Global Accelerator とは AWS Global Accelerator のエンドポイント VPC のサブネット インターネットゲートウェイ Application Load Balancer のセキュリティグループ 問題 45 不正解 ある企業は、名前解決のために VPC で BIND(DNS サーバソフトウェア)を実行するカスタム DNS サーバーを使用しています。VPC は、AWS Organizations の同じ組織に属する複数の AWS アカウントにデプロイされています。すべての VPC はトランジットゲートウェイに接続されています。BIND サーバーは中央 VPC で実行され、オンプレミス DNS ドメインへのすべてのクエリをオンプレミスデータセンターでホストされている DNS サーバーに転送するように構成されています。すべての VPC がカスタム DNS サーバーを使用するようにするために、ネットワークエンジニアはすべての VPC に VPC DHCP オプションセットを構成し、ドメイン名サーバーとして使用するカスタム DNS サーバーを指定しました。 会社内の複数の開発チームが Amazon Elastic File System（Amazon EFS）を使用したいと考えています。ある開発チームが新しい EFS ファイルシステムを作成しましたが、Amazon EC2 インスタンスにファイルシステムをマウントすることができません。ネットワークエンジニアは、EC2 インスタンスが EFS マウントポイント fs-33444567d.efs.us-east-1.amazonaws.com の IP アドレスを解決できないことを発見しました。ネットワークエンジニアは、組織全体の開発チームが EFS ファイルシステムをマウントできるようにするソリューションを実装する必要があります。 これらの要件を満たすステップの組み合わせはどれですか？（2 つ選択してください） efs.us-east-1.amazonaws.com ドメイン用の Amazon Route 53 プライベートホストゾーンを作成します。プライベートホストゾーンを EC2 インスタンスがデプロイされている VPC に関連付けます。プライベートホストゾーンに fs-33444567d.efs.us-east-1.amazonaws.com の A レコードを作成します。A レコードが EFS マウントポイントのマウントターゲットを返すように構成します。 説明
不正解 efs.us-east-1.amazonaws.com ドメイン用のプライベートホストゾーンを作成することは可能ですが、これは AWS サービスドメインであるため、このアプローチは推奨されません。また、EFS ファイルシステム ID ごとにレコードを作成する必要があり、管理オーバーヘッドがかかりスケーラブルではありません。 選択は不正解です 中央 VPC の BIND DNS サーバーが、efs.us-east-1.amazonaws.com へのクエリを Amazon 提供の DNS サーバー（169.254.169.253）に転送するように構成します。 説明
不正解 中央 VPC の BIND DNS サーバーに efs.us-east-1.amazonaws.com ドメインの転送設定を追加することは技術的には機能しますが、長期的には DNS レコードの維持管理のオーバーヘッドが発生します。 選択は不正解です 中央 VPC に Amazon Route 53 Resolver 受信エンドポイントを作成します。すべての VPC DHCP オプションセットを更新して、名前解決に中央 VPC の Route 53 Resolver 受信エンドポイントを使用するようにします。 説明
不正解 Route 53 Resolver 受信エンドポイントはオンプレミスから AWS VPC への DNS クエリを処理するためのものであり、この問題を解決するものではありません。また、DHCP オプションセットで Route 53 受信エンドポイントを DNS サーバーとして指定することはできません。 正しい選択 中央 VPC に Amazon Route 53 Resolver 送信エンドポイントを作成します。すべての VPC DHCP オプションセットを更新して、名前解決に AmazonProvidedDNS を使用するようにします。 説明
正解 現在の設定の問題点は、カスタム DNS サーバー（BIND）が AWS サービスの DNS 名を適切に解決できないことです。すべての VPC DHCP オプションセットを AmazonProvidedDNS を使用するように変更することで、EFS の DNS 名が正しく解決されるようになります。Amazon Route 53 Resolver 送信エンドポイントを作成することで、VPC 内からオンプレミス DNS にクエリを転送することも可能になります。 正しい選択 オンプレミスドメインへのクエリをオンプレミス DNS サーバーに転送するための Amazon Route 53 Resolver ルールを作成します。AWS Resource Access Manager（AWS RAM）を使用してルールを組織と共有します。すべての VPC にルールを関連付けます。 説明
正解 オンプレミスドメインへのクエリを転送するための Route 53 Resolver ルールを作成し、AWS RAM を使用して組織全体と共有することで、すべての VPC からオンプレミスリソースへの DNS 解決を可能にします。これはもう一方の正解選択肢と組み合わせることで、AWS サービス（EFS を含む）とオンプレミスリソースの両方を解決できるハイブリッド DNS 環境を実現します。 全体的な説明 問われている要件 この問題では、次の要件を満たすソリューションを特定する必要があります： EC2 インスタンスが EFS マウントポイントの DNS 名を解決できるようにする 組織全体の開発チームが EFS ファイルシステムをマウントできるようにする オンプレミス DNS ドメインへのクエリも引き続き解決できるようにする 前提知識 DHCP オプションセット DHCP オプションセットは、VPC 内の EC2 インスタンスに対して DHCP（Dynamic Host Configuration Protocol）を介して設定を提供するための AWS のリソースです。DHCP オプションセットには、以下の主要な設定を行うことができます： ドメイン名サーバー（DNS） ドメイン名 NTP サーバー NetBIOS ネームサーバー NetBIOS ノードタイプ 「AmazonProvidedDNS」は、VPC 内のリソース用に AWS が提供する内部 DNS サーバー（169.254.169.253）を指します。この DNS サーバーは、AWS 内部の DNS 名前解決、特に AWS サービスエンドポイントの解決に最適化されています。
Amazon EFS と DNS 解決 Amazon EFS は AWS のフルマネージド型のファイルストレージサービスです。EFS ファイルシステムを EC2 インスタンスにマウントするには、DNS 名を使用します。各 EFS ファイルシステムは、以下の形式の DNS 名を持ちます： file-system-id.efs.region.amazonaws.com 重要なポイントは、この DNS 名が自動的に、接続する EC2 インスタンスと同じアベイラビリティーゾーンにあるマウントターゲットの IP アドレスに解決されることです。この最適化された DNS 解決は、AmazonProvidedDNS を使用している場合にのみ機能します。 カスタム DNS サーバーを使用すると、この最適化が行われず、パフォーマンスが低下したり、可用性の問題が発生したりする可能性があります。 Route 53 Resolver エンドポイントとルール AWS Route 53 Resolver は、ハイブリッド DNS 環境での DNS 解決をサポートするためのサービスです。主な機能は以下の通りです： 送信エンドポイント（Outbound Endpoint）： VPC 内からオンプレミスまたは他のネットワークへの DNS クエリを転送 特定のドメインに対するルールに基づいて転送 受信エンドポイント（Inbound Endpoint）： オンプレミスネットワークから AWS VPC 内のリソースに対する DNS クエリを処理 VPC 内のプライベート DNS ゾーンの解決をサポート 転送ルール（Forwarding Rules）： 特定のドメインへの DNS クエリの処理方法を定義 指定した DNS サーバーへの転送設定 AWS RAM を使用して組織内の他のアカウントと共有可能 解くための考え方 この問題を解決するためには、以下の 2 つの主要な要件に対処する必要があります： EFS マウントポイントの DNS 解決の有効化： カスタム DNS サーバー（BIND）は EFS の DNS 名を適切に解決できない AmazonProvidedDNS を使用することで、EC2 インスタンスは最適な EFS マウントターゲット IP アドレスを取得できる DHCP オプションセットを AmazonProvidedDNS を使用するように変更することが必要 オンプレミス DNS ドメインの解決の維持： AmazonProvidedDNS に切り替えると、オンプレミスドメインの解決ができなくなる Route 53 Resolver 送信エンドポイントとルールを使用して、オンプレミスドメインへのクエリをオンプレミス DNS サーバーに転送する必要がある このルールを組織全体の VPC で使用できるようにするには、AWS RAM を使用して共有する 参考資料 マルチアカウント環境での Route 53 Resolver によるハイブリッドクラウドのための DNS オプション Amazon EFS ファイルシステムのマウント Amazon VPC DHCP オプションセット AWS Resource Access Manager（AWS RAM）によるリソース共有 問題 46 不正解 ある企業は、us-west-2 リージョンの VPC 内のプライベートサブネットで NAT ゲートウェイを使用してインターネット接続を可能にしています。セキュリティ監査により、NAT ゲートウェイを削除する必要が生じました。プライベートサブネットには統合 CloudWatch エージェントを使用するリソースがあります。ネットワークエンジニアは、NAT ゲートウェイを削除しても CloudWatch エージェントが引き続き動作するソリューションを作成しなければなりません。どのような手順の組み合わせが必要でしょうか（3 つ選択）。 正しい選択 VPC に次のインターフェイス VPC エンドポイントを作成します：com.amazonaws.us-west-2.logs と com.amazonaws.us-west-2.monitoring。新しいセキュリティグループをエンドポイントネットワークインターフェイスに関連付けます。 説明
正解：logs と monitoring のインターフェイス VPC エンドポイントを作成することは必要です。CloudWatch エージェントはログとメトリクスの両方を送信するため、これらのエンドポイントを作成することで、NAT ゲートウェイなしでも CloudWatch サービスと通信できるようになります。 VPC エンドポイントを、プライベートサブネットが使用するルートテーブルに関連付けます。 説明
不正解：VPC エンドポイントをルートテーブルに関連付ける必要はありません。インターフェイス VPC エンドポイントはプライベート IP アドレスを持つ ENI (Elastic Network Interface) として実装され、DNS ホスト名を通じてアクセスされます。ルートテーブルへの関連付けは、ゲートウェイ VPC エンドポイント（S3 や DynamoDB 用）には必要ですが、インターフェイス VPC エンドポイントには必要ありません。 選択は正解です プライベートサブネットの IP プレフィックスからのポート 443 で TCP プロトコルを使用する受信トラフィックを許可するエントリを含む新しいセキュリティグループを作成します。 説明
正解：プライベートサブネットからのインバウンドトラフィックを許可するセキュリティグループの作成は必要です。これは VPC エンドポイントのネットワークインターフェイスに関連付けられ、プライベートサブネット内のリソースからエンドポイントへの通信を許可するために必要です。 選択は不正解です VPC に次のインターフェイス VPC エンドポイントを作成します：com.amazonaws.us-west-2.cloudwatch。新しいセキュリティグループをエンドポイントのネットワークインターフェイスに関連付けます。 説明
不正解：com.amazonaws.us-west-2.cloudwatch というエンドポイントは存在しません。CloudWatch サービスへのアクセスには、logs と monitoring のエンドポイントが必要です。 選択は正解です enableDnsHostnames VPC 属性と enableDnsSupport VPC 属性を true に設定して、VPC でプライベート DNS が有効になっていることを確認します。 説明
正解：enableDnsHostnames VPC 属性と enableDnsSupport VPC 属性を true に設定することは必要です。これらの設定はインターフェイス VPC エンドポイントのプライベート DNS 機能を有効にするために必須であり、CloudWatch エージェントが AWS サービスのプライベートエンドポイントに接続するために必要です。 ポート 443 で TCP プロトコルを使用して宛先 0.0.0.0/0 への送信トラフィックを許可するエントリを持つ新しいセキュリティグループを作成します。 説明
不正解：宛先 0.0.0.0/0 へのアウトバウンドトラフィックを許可するセキュリティグループは必要ありません。インターフェイス VPC エンドポイントを使用する場合、トラフィックは VPC 内に留まるため、インターネット向けのアウトバウンドルールは不要です。 全体的な説明 問われている要件 この問題では、NAT ゲートウェイを削除した後でも、プライベートサブネット内のリソースが CloudWatch エージェントを使用して CloudWatch サービスと通信できるようにする方法が問われています。NAT ゲートウェイがなくなるとプライベートサブネットからインターネットへのアクセスができなくなるため、別の方法で CloudWatch サービスにアクセスする必要があります。 前提知識 NAT ゲートウェイとプライベートサブネット NAT（Network Address Translation）ゲートウェイは、プライベートサブネット内のリソースがインターネットやパブリックな AWS サービスにアクセスするために使用されるマネージドサービスです。通常、NAT ゲートウェイはパブリックサブネットに配置され、プライベートサブネットからのトラフィックをインターネットに送信する際に、送信元のプライベート IP アドレスをパブリック IP アドレスに変換する役割を担います。 プライベートサブネットとは、インターネットゲートウェイへの直接のルートを持たないサブネットのことで、通常はプライベート IP アドレスが割り当てられています。プライベートサブネット内のリソースはインターネットに直接アクセスできませんが、NAT ゲートウェイを使用することで、インターネットへの一方向のアクセス（アウトバウンド）が可能になります。 VPC エンドポイント VPC エンドポイントは、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要とせずに、VPC と AWS サービスの間にプライベート接続を確立できるようにする AWS PrivateLink の機能です。 VPC エンドポイントには主に 2 種類あります： ゲートウェイエンドポイント - Amazon S3 や DynamoDB などの特定のサービス向けに設計されています。ゲートウェイエンドポイントは、サブネットルートテーブルに追加されるルートとして実装され、指定された AWS サービスへのトラフィックを AWS のプライベートネットワークを通じてルーティングします。 インターフェイスエンドポイント - より多くの AWS サービスをサポートしており、Elastic Network Interface (ENI) として実装されます。インターフェイスエンドポイントはプライベート IP アドレスを持ち、VPC 内のリソースからのリクエストを AWS サービスにルーティングします。インターフェイスエンドポイントはプライベート DNS 名をサポートしており、これを有効にすると、標準のパブリックエンドポイント名（例：logs.us-west-2.amazonaws.com）を使用してエンドポイントにアクセスできます。 CloudWatch エージェント Amazon CloudWatch エージェントは、Amazon EC2 インスタンスやオンプレミスサーバーからメトリクスやログを収集し、CloudWatch に送信するためのソフトウェアです。統合 CloudWatch エージェントは、以前は別々だった CloudWatch Logs エージェントと CloudWatch メトリクスエージェントの機能を組み合わせたものです。 CloudWatch エージェントは以下の AWS サービスと通信します： CloudWatch Logs (logs.リージョン.amazonaws.com) - ログデータを送信するためのエンドポイント CloudWatch Metrics (monitoring.リージョン.amazonaws.com) - メトリクスデータを送信するためのエンドポイント 通常、CloudWatch エージェントはインターネット経由で上記のエンドポイントと通信しますが、インターネットアクセスを持たない環境では、VPC エンドポイントを使用して通信することが可能です。 プライベート DNS と VPC の DNS 設定 インターフェイス VPC エンドポイントでプライベート DNS 機能を使用するためには、VPC の DNS 設定を有効にする必要があります： enableDnsSupport - この属性が true の場合、VPC 内の DNS サーバーを使用した名前解決が可能になります。 enableDnsHostnames - この属性が true の場合、VPC 内のインスタンスにパブリック DNS ホスト名が割り当てられます。 両方の属性を有効にすることで、標準の AWS サービスエンドポイント名（例：logs.us-west-2.amazonaws.com）を使用して、VPC エンドポイントのプライベート IP アドレスにリクエストをルーティングできるようになります。 セキュリティグループと VPC エンドポイント セキュリティグループは、関連付けられたリソースに対するインバウンド（受信）およびアウトバウンド（送信）トラフィックを制御する仮想ファイアウォールとして機能します。インターフェイス VPC エンドポイントにはセキュリティグループを関連付けることができ、エンドポイントへのアクセスを制御できます。 インターフェイス VPC エンドポイント用のセキュリティグループでは、通常、以下の設定が必要です： インバウンドルール：VPC 内のリソース（通常はプライベートサブネット内）からの HTTPS（TCP/443）トラフィックを許可 アウトバウンドルール：デフォルトでは、すべての送信トラフィックが許可されています 解くための考え方 NAT ゲートウェイを削除した後も CloudWatch エージェントが動作するソリューションを作成するためには、以下の手順で考えることが重要です： 現状の理解: 現在、プライベートサブネット内のリソースは NAT ゲートウェイを通じて CloudWatch サービスにアクセスしています。NAT ゲートウェイが削除されると、このパスが失われます。 代替手段の検討: インターネットを経由せずに AWS サービスにアクセスする方法として、VPC エンドポイントが適切な選択肢となります。 必要なエンドポイントの特定: CloudWatch エージェントは logs と monitoring の両方のサービスにアクセスする必要があるため、これらのサービス用のエンドポイントが必要です。 前提条件の確認: インターフェイス VPC エンドポイントを効果的に使用するためには、VPC の DNS 設定が正しく構成されている必要があります。 アクセス制御: セキュリティグループを使用して、エンドポイントへのアクセスを適切に制御する必要があります。 これらの考え方に基づいて、正解となる手順の組み合わせは以下のとおりです： VPC の DNS 設定を有効にして、プライベート DNS 名を使用できるようにする CloudWatch サービス（logs と monitoring）用のインターフェイス VPC エンドポイントを作成する セキュリティグループを設定して、プライベートサブネット内のリソースからエンドポイントへのアクセスを許可する このアプローチにより、NAT ゲートウェイがなくても、プライベートサブネット内のリソースは AWS のプライベートネットワークを通じて CloudWatch サービスにアクセスできるようになります。
参考資料 VPC エンドポイント経由で CloudWatch Logs にアクセスする AWS サービスのプライベート DNS 名を使用するインターフェイスエンドポイントの作成 AWS サービスの PrivateLink 接続のサポート CloudWatch 統合エージェントのメトリクスの問題のトラブルシューティング インターネットアクセスなしで CloudWatch Logs にログを送信する方法 問題 47 不正解 ある AWS 企業は、アカウント 1 の eu-west-1 リージョンに本番環境 VPC（VPC-A）を持っています。VPC-A は、AWS Direct Connect トランジット VIF を介して AWS Direct Connect ゲートウェイ用に構成されたアイルランドのダブリンにあるオンプレミスデータセンターに接続されているトランジットゲートウェイ（TGW-A）に接続されています。また、この企業はアカウント 2 の eu-west-2 リージョンにある別のトランジットゲートウェイ（TGW-B）に接続されたステージング環境 VPC（VPC-B）も持っています。ネットワークエンジニアは、VPC-B とダブリンのオンプレミスデータセンター間の接続を実装する必要があります。この要件を満たすソリューションはどれですか？（2 つ選択してください） 選択は不正解です Direct Connect 接続に別のトランジット VIF を構成し、TGW-B を関連付けます。許可されたプレフィックスの下で VPC-B の CIDR ブロックをアドバタイズします。 説明
不正解 1 つの Direct Connect 接続に複数のトランジット VIF を構成することはできません。Direct Connect の制限により、1 つの接続につき 1 つのトランジット VIF しか持つことができません。この制約により、このソリューションは実装できません。 正しい選択 TGW-B を Direct Connect ゲートウェイに関連付けます。許可されたプレフィックスの下で VPC-B の CIDR ブロックをアドバタイズします。 説明
正解 TGW-B を Direct Connect ゲートウェイに直接関連付けることで、VPC-B からオンプレミスデータセンターへの接続パスを提供します。Direct Connect ゲートウェイは複数のリージョンにまたがるトランジットゲートウェイの関連付けをサポートしているため、この方法は有効です。これにより、VPC-B の CIDR ブロックをアドバタイズすることで、オンプレミスデータセンターが VPC-B にルーティングできるようになります。 正しい選択 TGW-A と TGW-B 間のリージョン間トランジットゲートウェイピアリングを構成します。トランジットゲートウェイルートテーブルにピアリングルートを追加します。Direct Connect ゲートウェイの関連付けの許可されたプレフィックスリストに VPC-A と VPC-B の CIDR ブロックの両方を追加します。 説明
正解 TGW-A と TGW-B 間のリージョン間トランジットゲートウェイピアリングを構成することで、2 つのリージョン間の接続パスを確立できます。これにより、VPC-B から TGW-B 経由で TGW-A へ、そして Direct Connect 接続を通じてオンプレミスデータセンターへのトラフィックの流れが可能になります。ルートテーブルと Direct Connect ゲートウェイの関連付けに両方の VPC の CIDR ブロックを追加することで、エンドツーエンドの接続が保証されます。 選択は不正解です トランジット VIF を介して TGW-B への AWS Site-to-Site VPN 接続を VPN 接続として構成します。 説明
不正解 トランジット VIF を介して AWS Site-to-Site VPN 接続を設定することは可能ですが、これは Direct Connect ゲートウェイがすでに存在し、トランジットゲートウェイを 1 つ以上関連付けることができる状況では冗長的です。また、VPN は Direct Connect に比べてパフォーマンスが低下し、レイテンシーが高くなる可能性があります。 VPC-A と VPC-B 間のリージョン間 VPC ピアリングを構成します。必要な VPC ピアリングルートを追加します。Direct Connect ゲートウェイの関連付けで許可されたプレフィックスに VPC-B の CIDR ブロックを追加します。 説明
不正解 この方法では VPC-A と VPC-B 間の接続は確立できますが、VPC-B とオンプレミスデータセンターとの直接接続は提供されません。VPC ピアリングは VPC 同士の接続にのみ使用され、オンプレミス環境への接続には使用できません。VPC-A を Transit VPC として使用する場合でも、VPC ピアリングはトランジット接続（中継）をサポートしていないため、このアプローチは無効です。 全体的な説明 問われている要件 この問題では、アカウント 2 の eu-west-2 リージョンにあるステージング環境 VPC（VPC-B）と、アイルランドのダブリンにあるオンプレミスデータセンター間の接続を実装する方法が問われています。現状では、アカウント 1 の eu-west-1 リージョンにある本番環境 VPC（VPC-A）はトランジットゲートウェイ（TGW-A）を介してオンプレミスデータセンターに接続されていますが、VPC-B はまだオンプレミス環境に接続されていません。 前提知識 AWS Direct Connect AWS Direct Connect は、オンプレミスのデータセンターから AWS への専用のプライベート接続を提供するサービスです。これにより、インターネットを経由せずに AWS リソースに直接接続できるため、帯域幅の向上、レイテンシーの低減、セキュリティの強化などのメリットがあります。 Direct Connect には以下の特徴があります： 1Gbps または 10Gbps の専用接続を提供します 複数の VPC への接続をサポートしています プライベート仮想インターフェイス（VIF）、パブリック仮想インターフェイス、中継仮想インターフェイス（Transit VIF）の 3 種類の VIF をサポートしています AWS Direct Connect ゲートウェイ Direct Connect ゲートウェイは、複数の AWS リージョンにまたがる VPC への接続を簡素化するグローバルネットワークサービスです。単一の Direct Connect 接続を使用して、異なるリージョンの複数の VPC に接続できます。 Direct Connect ゲートウェイの主な特徴： グローバルリソースであり、リージョンに依存しません 最大 6 つのトランジットゲートウェイとの関連付けをサポートしています 関連付けられるトランジットゲートウェイは異なるリージョンに存在することができます 各トランジットゲートウェイ関連付けには、許可されたプレフィックスリスト（アドバタイズする CIDR ブロック）を設定する必要があります トランジットゲートウェイ(TGW) トランジットゲートウェイは、VPC、オンプレミスのネットワーク、および AWS Direct Connect ゲートウェイを接続するリージョナルネットワークハブです。これにより、スター型トポロジーを使用して複数のネットワーク間の接続を簡素化できます。 トランジットゲートウェイの主な特徴： リージョナルリソースであり、特定の AWS リージョン内に存在します リージョン間ピアリングをサポートしており、異なるリージョンのトランジットゲートウェイ間の接続が可能です ルートテーブルを使用してトラフィックの流れを制御します 複数のアタッチメントタイプ（VPC、Direct Connect、VPN、ピアリング）をサポートしています 複数のアカウント間で共有することができます トランジット VIF （Transit Virtual Interface） トランジット VIF は、Direct Connect 接続を介してトランジットゲートウェイと Direct Connect ゲートウェイを接続するために使用される仮想インターフェイスのタイプです。 トランジット VIF の重要な制限事項： 1 つの Direct Connect 接続に作成できるトランジット VIF は 1 つだけです トランジット VIF は、Direct Connect ゲートウェイに関連付けられた複数のトランジットゲートウェイ間で共有することができます 現在、トランジット VIF は最大 4 つまで作成できますが、この制限は引き上げることができません リージョン間トランジットゲートウェイピアリング リージョン間トランジットゲートウェイピアリングは、異なる AWS リージョンに存在するトランジットゲートウェイ間の接続を可能にする機能です。 主な特徴： 異なるリージョン間の VPC やオンプレミスネットワーク接続をサポートします ピアリング接続を確立するには、両方のトランジットゲートウェイのルートテーブルにルートを追加する必要があります すべてのトラフィックは暗号化され、AWS のプライベートネットワークを通過します
解くための考え方 本問題を解くためのポイントは以下のとおりです： VPC-B とオンプレミスデータセンターをどのように接続できるかを検討する AWS Direct Connect 接続および Direct Connect ゲートウェイの特性と制限を理解する Direct Connect ゲートウェイは複数のトランジットゲートウェイを関連付けることができる 1 つの Direct Connect 接続に作成できるトランジット VIF は 1 つのみ トランジットゲートウェイの特性と機能を理解する リージョン間ピアリングが可能 ルートテーブルを使用してトラフィック制御が可能 各オプションのメリットとデメリットを比較検討する 直接接続とトランジット経由の接続の違い 構成の複雑さとメンテナンスのしやすさ この問題では、2 つの有効なソリューションが存在します： Direct Connect ゲートウェイに直接 TGW-B を関連付ける方法。これは最も直接的で効率的な接続方法です。 TGW-A と TGW-B 間のリージョン間ピアリングを構成する方法。これはより複雑ですが、両方の VPC 間の接続も同時に提供します。 これらの方法はどちらも VPC-B とオンプレミスデータセンター間の接続を実現します。選択するソリューションは、ネットワーク要件や将来の拡張性に基づいて決定されるべきです。 参考資料 AWS Direct Connect ゲートウェイとは トランジットゲートウェイとは トランジットゲートウェイを Direct Connect ゲートウェイに関連付ける トランジットゲートウェイのピア接続を作成および受諾する AWS Direct Connect のクォータ 問題 48 不正解 企業のデータセンターと 2 つの AWS リージョン（us-east-1 と eu-west-1）間で 1 Gbps の AWS Direct Connect 接続を使用するハイブリッドアーキテクチャを設計するネットワークエンジニアがいます。us-east-1 の VPC はトランジットゲートウェイで接続されており、複数のオンプレミスデータベースにアクセスする必要があります。会社のポリシーによると、eu-west-1 の 1 つの VPC のみが 1 つのオンプレミスサーバーに接続できます。オンプレミスネットワークはデータベースとサーバー間のトラフィックをセグメント化しています。これらの要件を満たすために Direct Connect 接続をどのように設定すべきでしょうか？ 1 つのホステッド接続を作成します。トランジット VIF を使用して us-east-1 のトランジットゲートウェイに接続し、プライベート VIF を使用して eu-west-1 の VPC に接続します。両方の VIF に対して 1 つの Direct Connect ゲートウェイを使用し、Direct Connect 接続場所から対応する AWS リージョンまで、レイテンシが最も低いパスに沿ってルーティングします。 説明
不正解 ホステッド接続では単一の VIF しかサポートしていません。ホステッド接続またはホステッド仮想インターフェースはプライベート仮想インターフェースになり得る単一の仮想インターフェースのみをサポートします。そのため、ホステッド接続を使用して両方のリージョン（トランジット VIF とプライベート VIF）をサポートすることはできません。 1 つのホステッド接続を作成します。トランジット VIF を使用して us-east-1 のトランジットゲートウェイに接続し、プライベート VIF を使用して eu-west-1 の VPC に接続します。各 VIF に対して 2 つの Direct Connect ゲートウェイを使用し、Direct Connect 接続場所から対応する AWS リージョンまで、レイテンシが最も低いパスに沿ってルーティングします。 説明
不正解 ホステッド接続は単一の VIF しかサポートしないため、2 つの Direct Connect ゲートウェイを使用しても、1 つのホステッド接続で両方の VIF タイプ（トランジットとプライベート）をサポートすることはできません。 回答は不正解です 1 つの専用接続を作成します。トランジット VIF を使用して us-east-1 のトランジットゲートウェイに接続し、プライベート VIF を使用して eu-west-1 の VPC に接続します。両方の VIF に対して 1 つの Direct Connect ゲートウェイを使用し、Direct Connect 接続場所から対応する AWS リージョンまで、レイテンシが最も低いパスに沿ってルーティングします。 説明
不正解 トランジット VIF が AWS Direct Connect ゲートウェイに接続されると、そのゲートウェイは別のプライベート VIF をホストすることはできず、トランジット VIF 専用になります。このため、1 つの Direct Connect ゲートウェイで両方の VIF タイプをサポートすることはできません。 正解 1 つの専用接続を作成します。トランジット VIF を使用して us-east-1 のトランジットゲートウェイに接続し、プライベート VIF を使用して eu-west-1 の VPC に接続します。各 VIF に対して 2 つの Direct Connect ゲートウェイを使用し、Direct Connect 接続場所から対応する AWS リージョンまで、レイテンシが最も低いパスに沿ってルーティングします。 説明
正解 専用接続は複数の VIF をサポートしています。Direct Connect 専用接続は最大 50 のパブリックまたはプライベート仮想インターフェースと 1 つのトランジット仮想インターフェースをサポートできます。 また、トランジット VIF とプライベート VIF は別々の Direct Connect ゲートウェイに接続する必要があるため、2 つの異なる Direct Connect ゲートウェイを使用する必要があります。 全体的な説明 問われている要件 この問題では、以下の要件が問われています： 1 Gbps の単一の AWS Direct Connect 接続を使用して 2 つの AWS リージョン（us-east-1 と eu-west-1）にまたがるハイブリッドアーキテクチャを設計すること us-east-1 の VPC はトランジットゲートウェイに接続されており、オンプレミスデータベースにアクセスする必要がある eu-west-1 の 1 つの VPC のみが 1 つのオンプレミスサーバーに接続できる オンプレミスネットワークはデータベースとサーバー間のトラフィックをセグメント化している 前提知識 AWS Direct Connect の接続タイプ AWS Direct Connect には主に 2 つの接続タイプがあります： 専用接続(dedicated connection)： AWS Direct Connect ロケーションで物理的なポートをプロビジョニングします 1Gbps、10Gbps、100Gbps の容量で提供 単一の接続で最大 50 のプライベート/パブリック VIF と 1 つのトランジット VIF をサポート ホステッド接続： AWS Direct Connect パートナーを通じて提供 50Mbps から 10Gbps までの様々な容量で提供 単一の接続につき 1 つの VIF のみをサポート（プライベート、パブリック、またはトランジット） 仮想インターフェース（VIF）のタイプ AWS Direct Connect は 3 つの主要な VIF タイプをサポートしています： プライベート VIF： プライベート IP アドレスを使用して VPC にアクセスするために使用 単一の VPC（Virtual Private Gateway 経由）または Direct Connect ゲートウェイ経由で複数の VPC に接続可能 パブリック VIF： パブリック IP アドレスを使用して AWS パブリックサービスにアクセスするために使用 トランジット VIF： Direct Connect ゲートウェイに関連付けられた VPC トランジットゲートウェイにアクセスするために使用 複数のリージョンやアカウントにわたる数千の VPC に接続可能 Direct Connect ゲートウェイ Direct Connect ゲートウェイ（DXGW）はグローバルに利用可能なリソースで、異なるリージョンや AWS アカウントにまたがる複数の VPC への接続を可能にします。重要な制限として、一つの Direct Connect ゲートウェイはプライベート VIF とトランジット VIF の両方をサポートすることはできません。トランジット VIF が接続されると、その Direct Connect ゲートウェイはトランジットトラフィックのみの専用となります。 トラフィックセグメンテーション この問題の重要な要件は、オンプレミスネットワークがデータベースとサーバー間のトラフィックをセグメント化していることです。これは、us-east-1 の VPC が eu-west-1 の VPC が接続するサーバーにアクセスできないこと、またその逆も同様であることを意味します。この要件を満たすには、トラフィックを明確に分離する必要があります。
解くための考え方 正しい解決策を特定するために、以下の主要なポイントを考慮する必要があります： 接続タイプ: 複数の VIF をサポートするには、専用接続が必要です。ホステッド接続は単一の VIF しかサポートしていません。 VIF の組み合わせ: us-east-1 のトランジットゲートウェイに接続するにはトランジット VIF が必要で、eu-west-1 の単一 VPC に接続するにはプライベート VIF が必要です。 トラフィックセグメンテーション: オンプレミスネットワークのセグメンテーション要件を満たすには、トラフィックを明確に分離する必要があります。これは、異なる VIF と異なる Direct Connect ゲートウェイを使用することで実現できます。 Direct Connect ゲートウェイの制限: 単一の Direct Connect ゲートウェイはトランジットとプライベートの両方の VIF をサポートできないため、2 つの別々のゲートウェイが必要です。 参考資料 AWS Direct Connect 仮想インターフェイスとホステッド仮想インターフェイス AWS Direct Connect ゲートウェイ AWS Direct Connect の制限 AWS Transit Gateway の概要 問題 50 不正解 ある企業は、米国（US）のオンプレミスデータセンターと us-east-1 リージョンのワークロード間に AWS Direct Connect 接続を持っています。この接続は、データセンターを us-east-1 のトランジットゲートウェイに接続するためにトランジット VIF を使用しています。 この企業はヨーロッパに新しいオフィスを開設し、イングランドに新しいオンプレミスデータセンターを設置しています。Direct Connect 接続は、新しいデータセンターと eu-west-2 リージョンの単一の VPC で実行されているワークロードを接続します。企業は、米国のデータセンターと us-east-1 を、ヨーロッパのデータセンターと eu-west-2 に接続する必要があります。ネットワークエンジニアは、可能な限り低いレイテンシーでデータセンターとリージョン間の完全な接続性を確立する必要があります。 これらの要件を満たすために、ネットワークエンジニアはどのようにネットワークアーキテクチャを設計すべきですか？ Direct Connect ゲートウェイとプライベート VIF を使用して、eu-west-2 の VPC とヨーロッパのデータセンターを接続します。新しい Direct Connect ゲートウェイを作成します。us-east-1 のトランジットゲートウェイを新しい Direct Connect ゲートウェイに関連付けます。トランジット VIF とプライベート VIF の SiteLink を有効にします。 説明
不正解 この設計では、プライベート VIF を使用していますが、2 つの異なる Direct Connect ゲートウェイを使用しています。これにより、米国とヨーロッパのデータセンター間のトラフィックには、両方の Direct Connect ゲートウェイを通過する必要があり、追加の通信とレイテンシーが発生します。また、eu-west-2 の VPC はプライベート VIF で Direct Connect ゲートウェイに直接接続されており、将来 EU 地域で追加の VPC を追加する際にスケーラビリティの問題が発生する可能性があります。この設計は、要件を満たすためには最適ではありません。 回答は不正解です eu-west-2 の VPC を新しいトランジットゲートウェイに接続します。Direct Connect ゲートウェイと新しいトランジット VIF を使用して、ヨーロッパのデータセンターを新しいトランジットゲートウェイに接続します。新しい Direct Connect ゲートウェイを作成します。us-east-1 のトランジットゲートウェイを新しい Direct Connect ゲートウェイに関連付けます。両方のトランジット VIF で SiteLink を有効にします。2 つのトランジットゲートウェイをピアリングします。 説明
不正解 この設計はほぼ正解の選択肢と同様ですが、大きな違いは 2 つの異なる Direct Connect ゲートウェイを使用していることです。これにより、米国とヨーロッパのデータセンター間の直接接続が複雑になり、追加の設定とルーティングのオーバーヘッドが発生します。2 つの Direct Connect ゲートウェイを使用すると、データセンター間のトラフィックは両方のトランジットゲートウェイを経由する必要があり、これによって余分な通信が発生し、レイテンシーが増加します。要件である「可能な限り低いレイテンシー」を達成するためには、単一の Direct Connect ゲートウェイを使用する方が効率的です。 正解 eu-west-2 の VPC を新しいトランジットゲートウェイに接続します。Direct Connect ゲートウェイと新しいトランジット VIF を使用して、ヨーロッパのデータセンターを新しいトランジットゲートウェイに接続します。us-east-1 のトランジットゲートウェイを同じ Direct Connect ゲートウェイに関連付けます。両方のトランジット VIF で SiteLink を有効にします。2 つのトランジットゲートウェイをピアリングします。 説明
正解 この設計は最も拡張性の高いソリューションを提供します。eu-west-2 にも新しいトランジットゲートウェイを導入することで、リージョン内の将来の VPC 拡張の柔軟性を確保しています。両方のデータセンターが同じ Direct Connect ゲートウェイに接続され、それぞれのトランジットゲートウェイに関連付けられています。両方のトランジット VIF で SiteLink を有効にすることで、データセンター間のトラフィックが最短パスで（AWS バックボーン経由で）ルーティングされ、最低レイテンシーを実現します。さらに、2 つのトランジットゲートウェイをピアリングすることで、異なるリージョンの VPC 間の通信も可能になります。この構成は、データセンター間、リージョン間、VPC 間のすべての接続要件を満たし、最低レイテンシーを提供する最も効率的な設計です。 Direct Connect ゲートウェイとプライベート VIF を使用して、eu-west-2 の VPC とヨーロッパのデータセンターを接続します。us-east-1 のトランジットゲートウェイを同じ Direct Connect ゲートウェイに関連付けます。トランジット VIF とプライベート VIF の SiteLink を有効にします。 説明
不正解 この設計では、eu-west-2 の VPC とヨーロッパのデータセンターをプライベート VIF で接続していますが、これにはいくつかの問題があります。プライベート VIF は VPC に直接接続するため、将来的なスケーラビリティが制限されます。また、この構成では米国のトランジットゲートウェイと eu-west-2 の VPC 間の通信パスが確立されていません。この設計では VPC 間やリージョン間の将来の拡張性が限られるため、長期的な要件に対して最適ではありません。 全体的な説明 問われている要件 この問題では、以下の要件を満たすネットワーク設計が求められています： 米国のデータセンターと us-east-1 リージョンを、ヨーロッパのデータセンターと eu-west-2 リージョンに接続すること データセンターとリージョン間の完全な接続性を確立すること 可能な限り低いレイテンシーを実現すること 前提知識 AWS Direct Connect とは AWS Direct Connect は、オンプレミスから AWS への専用のプライベート接続を提供するサービスです。インターネット接続と比較して、より一貫した高速なネットワーク性能を提供します。 仮想インターフェイス（VIF）の種類 Direct Connect では、以下の種類の仮想インターフェイス（VIF）が使用できます： プライベート VIF: 特定の VPC に直接接続するために使用 単一の VPC にのみ接続可能 複数の VPC に接続する場合は、VPC ごとに別々のプライベート VIF が必要 パブリック VIF: AWS のパブリックサービス（S3、DynamoDB など）に接続するために使用 VPC には接続しない トランジット VIF: Direct Connect ゲートウェイと AWS Transit Gateway を介して複数の VPC に接続するために使用 複数リージョンでの接続や、複数 VPC への柔軟な接続に適している Direct Connect Gateway Direct Connect Gateway（DX Gateway）は、複数の AWS リージョンにわたる複数の VPC に接続するためのグローバルなネットワークリソースです。1 つの Direct Connect 接続から複数の VPC や AWS Transit Gateway に接続できます。 AWS Transit Gateway AWS Transit Gateway は、VPC とオンプレミスネットワークを接続するためのハブとして機能するリージョナルなリソースです。スポークのように VPC を接続し、ルーティングを一元管理できます。 Transit Gateway Peering 異なるリージョンのトランジットゲートウェイ間でピアリング接続を確立できます。これにより、異なるリージョンの VPC 間でトラフィックをルーティングできるようになります。 SiteLink SiteLink は、AWS Direct Connect のオプション機能で、AWS Direct Connect 接続を介してオンプレミスのデータセンター間で最短のネットワークパスを確立します。SiteLink を有効にすると、トラフィックは AWS のバックボーンネットワークを介して最短のパスでルーティングされ、レイテンシーが低減されます。
解くための考え方 最適なネットワーク設計を選択するために、以下のポイントを考慮する必要があります： データセンター間の接続: 米国とヨーロッパのデータセンター間の接続は、できるだけ直接的かつ低レイテンシーであるべきです SiteLink を有効にすることで、AWS DirectConnect を介したデータセンター間の最短パスが確保され、最低のレイテンシーが実現できます リージョン間の VPC 接続: us-east-1 と eu-west-2 の VPC 間の接続も必要です これは、トランジットゲートウェイピアリングによって実現できます 拡張性と将来性: 設計は将来の VPC やネットワークの拡張に対応できる必要があります 各リージョンにトランジットゲートウェイを配置することで、その後の VPC 追加が容易になります 最適な VIF タイプの選択: トランジット VIF は複数の VPC への接続に最適で、将来的な拡張性も高いです プライベート VIF は単一の VPC には簡単ですが、拡張性に制限があります Direct Connect ゲートウェイの設計: 単一の Direct Connect ゲートウェイを使用することで、設定が簡素化され、データセンター間の直接接続が可能になります 複数の Direct Connect ゲートウェイを使用すると、追加の通信が発生し、レイテンシーが増加する可能性があります 最も低いレイテンシーと完全な接続性を確保するためには、以下の要素を組み合わせた設計が最適です： 両方のリージョンにトランジットゲートウェイを配置 単一の Direct Connect ゲートウェイを使用 両方のデータセンターからトランジット VIF を使用して Direct Connect ゲートウェイに接続 SiteLink を両方のトランジット VIF で有効化 リージョン間のトランジットゲートウェイピアリングを確立 この組み合わせによって、データセンター間のトラフィックは SiteLink を介して直接ルーティングされ、リージョン間の VPC トラフィックはトランジットゲートウェイピアリングを通過します。これにより、すべての接続要件を最低のレイテンシーで満たすことができます。 参考資料 AWS Direct Connect とは Direct Connect SiteLink Direct Connect ゲートウェイ Transit Gateway のピアリング接続 VIF タイプの選択 問題 63 不正解 ある IoT 企業は、MQTT メッセージングプロトコルを通じて定期的に温度、湿度、気圧、位置情報データを送信するハードウェアセンサーモジュールを販売しています。ハードウェアセンサーモジュールは、ロードバランサーの背後にある Linux サーバー上で実行されている同社のオンプレミス MQTT ブローカーにこのデータを送信します。ハードウェアセンサーモジュールには、ブローカーに到達するためのパブリック IP アドレスがハードコードされています。 同社は成長を続けており、世界中で顧客を獲得している。既存のソリューションでは拡張性がなくなり、グローバルに展開しているため、さらに遅延が発生するようになりました。その結果、同社はインフラ全体をオンプレミスから AWS クラウドに移行することを決定した。同社は、すでに世界中に配備されているハードウェアセンサーモジュールを再構成することなく移行する必要がある。また、レイテンシーも最小限に抑える必要がある。 同社は MQTT ブローカーを Amazon EC2 インスタンス上で実行するように移行する。 これらの要件を満たすために、次に何をすべきですか？ 回答は不正解です EC2 インスタンスを Application Load Balancer（ALB）の背後に配置します。TCP リスナーを構成します。ALB の前に AWS Global Accelerator アクセラレーターを作成します。オンプレミスネットワークからの Bring Your Own IP（BYOIP）を Global Accelerator で使用します。 説明
不正解 この選択肢は正解の選択肢と似ていますが、重要な違いがあります。ALB は HTTP/HTTPS プロトコルのみをサポートし、MQTT が使用する TCP レベルプロトコルをサポートしていません。そのため、TCP リスナーを ALB で構成することはできません。MQTT プロトコルを使用するアプリケーションには、NLB が適切なロードバランサーの選択肢です。 正解 EC2 インスタンスを Network Load Balancer（NLB）の背後に配置します。TCP リスナーを構成します。NLB の前に AWS Global Accelerator アクセラレーターを作成します。オンプレミスネットワークからの Bring Your Own IP（BYOIP）を Global Accelerator で使用します。 説明
正解 EC2 インスタンスを NLB の背後に配置し、その NLB を Global Accelerator の背後に配置することで、グローバルなアニーキャスト IP アドレスが提供され、世界中のクライアントからのトラフィックが最も近い AWS エッジロケーションを経由してルーティングされます。BYOIP を使用することで、既存のハードコードされた IP アドレスを維持でき、センサーモジュールの再構成が不要になります。TCP リスナーの構成は MQTT プロトコルをサポートします。この方法により、レイテンシーを最小化しつつ、既存のハードウェアモジュールとの互換性を維持できます。 EC2 インスタンスを Amazon CloudFront ディストリビューションの背後に配置します。オンプレミスネットワークからの Bring Your Own IP（BYOIP）を CloudFront で使用します。 説明
不正解 CloudFront は HTTP/HTTPS トラフィック用のコンテンツ配信ネットワーク（CDN）であり、MQTT のような TCP ベースのプロトコルをサポートしていません。また、CloudFront はキャッシュ可能なコンテンツに最適化されており、双方向の通信を必要とする MQTT メッセージングには適していません。 EC2 インスタンスを Network Load Balancer（NLB）の背後に配置します。TCP リスナーを構成します。オンプレミスネットワークからの Bring Your Own IP（BYOIP）を NLB で使用します。 説明
不正解 EC2 インスタンスを NLB の背後に配置し、TCP リスナーを構成することは適切ですが、NLB は単一のリージョンでのみ機能します。グローバルに展開されたセンサーモジュールからのトラフィックは、単一リージョンの NLB までのパスでインターネット経由のルーティングが必要になるため、レイテンシーが高くなる可能性があります。この選択肢ではレイテンシーを最小化するという要件を満たしていません。 全体的な説明 問われている要件 この問題では、以下の要件を満たすソリューションを選ぶ必要があります： 既存のハードウェアセンサーモジュールを再構成せずに移行する（既存のパブリック IP アドレスを維持） グローバルな環境でレイテンシーを最小化する MQTT メッセージングプロトコルをサポートする 前提知識 MQTT プロトコル MQTT（Message Queuing Telemetry Transport）は、軽量なメッセージングプロトコルで、IoT デバイスに広く使用されています。MQTT は TCP ベースのプロトコルであり、パブリッシュ/サブスクライブモデルを使用してデバイス間の通信を行います。MQTT は以下の特徴を持っています： 低帯域幅での効率的な通信 信頼性の高いメッセージ配信 QoS レベルのサポート 双方向通信 ネットワークロードバランサー（NLB） Network Load Balancer（NLB）は、TCP トラフィックを処理する Layer 4（トランスポート層）のロードバランサーです。NLB の主な特徴は以下の通りです： TCP および UDP プロトコルのサポート 超低レイテンシー 固定 IP アドレスのサポート リージョン内での高可用性 接続の維持（長時間の接続に適している） MQTT のような TCP ベースのプロトコルには、NLB が適切な選択肢となります。 アプリケーションロードバランサー（ALB） Application Load Balancer（ALB）は、HTTP および HTTPS トラフィックを処理する Layer 7（アプリケーション層）のロードバランサーです。ALB は HTTP/HTTPS に特化しており、以下のプロトコルやリクエストタイプをサポートしていません： TCP プロトコル（ALB は HTTP/HTTPS のみ） UDP プロトコル カスタムプロトコル そのため、MQTT のような TCP ベースのプロトコルには適していません。 AWS Global Accelerator AWS Global Accelerator は、アプリケーションのグローバルトラフィックを最適化するサービスです。Global Accelerator の主な特徴は以下の通りです： グローバルな IP アドレスの提供 AWS Global Network の活用による最適なパスのルーティング 最寄りの AWS エッジロケーションへのトラフィック転送 TCP プロトコルのサポート リージョン間のフェイルオーバー BYOIP のサポート Global Accelerator を使用することで、世界中のクライアントからのトラフィックが最も近い AWS エッジロケーションを経由してルーティングされ、レイテンシーが最小化されます。 Bring Your Own IP（BYOIP） BYOIP を使用すると、自社が所有する IP アドレス範囲を AWS に持ち込み、AWS 内で使用することができます。BYOIP の主な利点は以下の通りです： 既存の IP アドレスの維持 IP アドレスのブランディングおよび評判の維持 IP アドレスの変更に伴う顧客への影響の回避 ファイアウォールルールの変更の最小化 この問題のコンテキストでは、ハードウェアセンサーモジュールに既存のパブリック IP アドレスがハードコードされているため、BYOIP を使用することで再構成の必要がなくなります。 解くための考え方 この問題を解くためには、以下のポイントを考慮する必要があります： プロトコルの考慮: MQTT は TCP ベースのプロトコルであり、EC2 インスタンスに実装されたブローカーと通信するには、TCP をサポートするロードバランサーが必要です。NLB は TCP をサポートしているため適切ですが、ALB は HTTP/HTTPS のみをサポートしているため不適切です。 グローバルな展開の考慮: 会社は世界中に顧客を持っており、レイテンシーを最小限に抑える必要があります。単一リージョンの NLB だけでは、グローバルなトラフィックのレイテンシーを最適化できません。AWS Global Accelerator を使用することで、トラフィックが最寄りの AWS エッジロケーションから AWS のグローバルネットワークを経由してルーティングされ、レイテンシーが最小化されます。 既存の IP アドレスの維持: ハードウェアセンサーモジュールには既存のパブリック IP アドレスがハードコードされているため、それらの IP アドレスを維持する必要があります。BYOIP を使用することで、既存の IP アドレスを AWS に持ち込み、Global Accelerator で使用できるようになります。 アーキテクチャの検証: 最適なアーキテクチャは、EC2 インスタンス（MQTT ブローカー）を NLB の背後に配置し、その NLB を Global Accelerator の背後に配置することです。BYOIP を使用して既存の IP アドレスを維持します。
上の図は、AWS Global Accelerator と Network Load Balancer を BYOIP と組み合わせて使用し、世界中に展開された MQTT センサーモジュールからのトラフィックを処理するアーキテクチャを示しています。ハードコードされた IP アドレスを持つセンサーモジュールは Global Accelerator に接続し、トラフィックは最寄りの AWS エッジロケーションから最適なパスで NLB にルーティングされます。NLB は TCP リスナーを使用して MQTT トラフィックを処理し、EC2 インスタンス上で実行されている MQTT ブローカーに転送します。 参考資料 AWS Global Accelerator とは Network Load Balancer の開始方法 AWS Global Accelerator での独自の IP アドレスの取得（BYOIP） AWS での MQTT ブローカーの実行 問題 64 不正解 企業が SD-WAN サイトの大規模展開を計画しており、Transit Gateway に接続された VPC に SD-WAN ハブ仮想アプライアンスを展開します。このソリューションは SD-WAN ハブから他の VPC へのスループットを 5Gbps 以上サポートする必要があります。どのようなソリューションが適切でしょうか？ 正解 トランジットゲートウェイに新しい CIDR ブロックを割り当て、SD-WAN ハブ用の新しい VPC を作成します。VPC アタッチメントで新 VPC をトランジットゲートウェイに接続し、トランジットゲートウェイ Connect アタッチメントを追加します。GRE と BGP パラメータを指定して Connect ピアを作成し、適切なルートを設定します。 説明
正解：トランジットゲートウェイに新しい CIDR ブロックを割り当て、SD-WAN ハブ用の新しい VPC を作成します。VPC アタッチメントで新 VPC をトランジットゲートウェイに接続し、トランジットゲートウェイ Connect アタッチメントを追加します。GRE と BGP パラメータを指定して Connect ピアを作成し、適切なルートを設定します。Transit Gateway Connect アタッチメントは高スループットの GRE トンネルと動的ルーティングのための BGP をサポートしており、要件の 5Gbps 以上のスループットを実現できます。 回答は不正解です トランジットゲートウェイに新しい CIDR ブロックを割り当て、SD-WAN ハブ用の新しい VPC を作成します。VPC アタッチメントでトランジットゲートウェイに接続し、トランジットゲートウェイ Connect アタッチメントを追加します。VXLAN と BGP パラメータを指定して Connect ピアを作成し、適切なルートを設定します。 説明
不正解：VXLAN パラメータを指定した Connect Peer の設定は、AWS Transit Gateway の Connect 機能では VXLAN がサポートされていないため実装できません。AWS Transit Gateway Connect では現在 GRE のみがサポートされています。 新しい VPC を作成し、VPC アタッチメントでトランジットゲートウェイに接続します。SD-WAN ハブとトランジットゲートウェイの間に 2 つの IPsec VPN 接続を作成し、BGP を設定します。 説明
不正解：VPC アタッチメントでトランジットゲートウェイに接続した後、IPsec VPN 接続を使用する方法も、IPsec のスループット制限により 5Gbps の要件を満たすことができません。 新しい VPC を作成し、SD-WAN ハブアプライアンスとトランジットゲートウェイの間に 2 つの IPsec VPN 接続を作成します。これらの接続上で BGP を設定します。 説明
不正解：新しい VPC を作成し、SD-WAN ハブアプライアンスとトランジットゲートウェイの間に 2 つの IPsec VPN 接続を作成する方法では、IPsec VPN の単一接続あたりのスループット上限が約 1.25Gbps であるため、2 つの接続でも 2.5Gbps 程度しか実現できません。ECMP を設定しても要件の 5Gbps に到達しません。 全体的な説明 問われている要件 この問題では以下の要件が問われています： SD-WAN サイトの大規模展開 Transit Gateway に接続された VPC に SD-WAN ハブ仮想アプライアンスを展開する SD-WAN ハブから他の VPC へのスループットが少なくとも 5Gbps である必要がある 前提知識 AWS Transit Gateway (TGW) AWS Transit Gateway は、VPC、オンプレミスネットワーク、SD-WAN ネットワークなどを相互接続するための中央ハブとなるサービスです。これによりスター型接続トポロジーが実現し、多数のネットワーク間の接続管理が簡素化されます。 Transit Gateway の主要な機能としては： 複数の VPC を一つのポイントで接続可能 オンプレミスネットワークとの接続（VPN、Direct Connect など） ルートテーブルによる柔軟なルーティング制御 マルチキャストのサポート 複数のリージョン間での相互接続（Transit Gateway Peering） Transit Gateway に接続するためのアタッチメントタイプには以下があります： VPC アタッチメント：VPC との接続 VPN アタッチメント：IPsec VPN による接続 Direct Connect アタッチメント：AWS Direct Connect による接続 Transit Gateway Peering アタッチメント：異なるリージョンの Transit Gateway 間の接続 Transit Gateway Connect アタッチメント：SD-WAN やその他の接続に最適化された接続 SD-WAN (Software-Defined Wide Area Network) SD-WAN は、ソフトウェアを使用して WAN サービスを管理するアプローチです。複数の接続タイプ（MPLS、4G/5G、インターネットなど）を組み合わせて利用し、アプリケーションレベルでのインテリジェントな経路制御を実現します。 SD-WAN の主な特徴： 中央集中型の管理 アプリケーションベースのポリシールーティング 複数の接続タイプの同時利用と自動フェイルオーバー トラフィックの暗号化 帯域幅の最適化 SD-WAN を AWS と統合する際の一般的なアーキテクチャとして、SD-WAN ハブ仮想アプライアンスを AWS 上に配置し、そこを中継点としてオンプレミスの SD-WAN サイトと AWS リソースを接続するアプローチがあります。 Transit Gateway Connect Transit Gateway Connect は、2020 年に導入された Transit Gateway のアタッチメントタイプで、SD-WAN デバイスと AWS Transit Gateway を統合するために設計されています。特徴としては： 高スループット：基盤となる VPC アタッチメントの帯域幅を活用するため、単一の IPsec VPN 接続の制限（約 1.25Gbps）を超えるスループットを実現可能です。実際には数十 Gbps のスループットをサポートします。 GRE トンネリング：Generic Routing Encapsulation（GRE）プロトコルを使用してトラフィックをカプセル化します。GRE は低オーバーヘッドでパフォーマンスに優れています。 BGP サポート：Border Gateway Protocol（BGP）による動的ルーティングをサポートし、自動化とスケーラビリティを向上させます。 実装方法： 既存の VPC アタッチメントを基盤として使用 Transit Gateway Connect アタッチメントを作成 Connect Peer を設定（GRE および BGP パラメータを指定） 制限事項： 現在は GRE プロトコルのみをサポート（VXLAN はサポートされていない） BGP ルーティングプロトコルのみをサポート Transit Gateway Connect を使用するには基盤となる VPC アタッチメントが必要 IPsec VPN vs Transit Gateway Connect IPsec VPN と Transit Gateway Connect の主要な違い：
解くための考え方 この問題を解くための重要なポイントは： スループット要件の分析： 問題では「少なくとも 5Gbps のスループット」が要求されています。IPsec VPN の単一接続では約 1.25Gbps に制限されるため、2 つの VPN 接続では要件を満たせません。Transit Gateway Connect は基盤となる VPC アタッチメントの帯域幅を活用できるため、5Gbps 以上のスループットを実現可能です。 プロトコルの選択： Transit Gateway Connect は GRE プロトコルのみをサポートしているため、VXLAN を使用することはできません。 アーキテクチャの検討： SD-WAN ハブ仮想アプライアンスを新しい VPC に配置し、Transit Gateway の Connect 機能を活用するアーキテクチャが最適です。これにより、高スループット、動的ルーティング、SD-WAN との簡素化された統合が実現します。 以上の考察から、高スループットを実現するために Transit Gateway Connect を活用し、GRE プロトコルと BGP ルーティングを組み合わせた解決策が最適です。 参考資料 AWS Transit Gateway とは AWS Transit Gateway Connect による SD-WAN 接続の簡素化 AWS Transit Gateway Connect の設定 AWS Transit Gateway に関するよくある質問