Amazon SAP-C02: ネットワーキングとハイブリッド接続 — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Solutions Architect Professional SAP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

VPCアーキテクチャとセグメンテーションパターン

VPCトポロジの設計は、爆発半径の管理と予測可能なルーティングから始まります。小規模なデプロイメントでは、複数のサブネットと厳格なセキュリティグループを持つ単一のVPCが効率的ですが、チームやアプリケーションが成長するにつれて、単一VPCパターンは脆弱になります。リソースクォータ、チーム間のガバナンス、そしてノイジーネイバーが運用リスクを増大させます。チームごとに複数のVPCを割り当てるモデルや、チームごとにアカウントを割り当てるモデルは、分離性とIAMの境界を改善します。AWS Organizationsを使用してチームごとに個別のアカウントを作成し、DNS、ロギング、アイデンティティのために共有サービスアカウントを使用します。VPC間の接続には、VPCピアリングがシンプルで低レイテンシーですが、非推移的であり、大規模になると運用負荷が高くなります。Transit Gateway (TGW) は「トランジットVPC」パターンを置き換えるものです。数千のアタッチメントをサポートし、ルートテーブルを集中管理し、マルチキャストやハブアンドスポークパターンを簡素化します。PrivateLink (インターフェイスVPCエンドポイント) は、サービスをインターネットに公開することなくサービスレベルの分離を可能にし、クロスアカウントのマイクロサービスにとって重要です。よくある落とし穴には、セグメンテーションをセキュリティグループのみに依存すること（ステートフルであり、東西トラフィックのフィルタリングには粒度が粗すぎる）、NACLのステートレスな動作を忘れること、CIDR割り当てを計画しないこと（重複はピアリングやDXの妨げになる）などがあります。意思決定は、コストと管理性のトレードオフにかかっています。TGWにはアタッチメントコストがかかりますが、ピアリングごとの複雑さを軽減します。マルチアカウントによる分離は、ランディングゾーンのオーバーヘッドを増加させますが、爆発半径を縮小します。ドリフト（構成のずれ）を避けるために、CIDR計画、ルート伝播ルール、共有サービスの所有者を常に文書化してください。

ハイブリッド接続、ルーティング、および回復性

ハイブリッド接続の選択は、スループット、ジッター、レイテンシー、そして一貫したパブリックな出口アドレスに依存します。AWS Direct Connect (DX) のプライベートVIFは、大規模で安定したフローに対して、インターネットVPNと比較して確定的な帯域幅と低い下り（egress）コストを提供します。複数のリージョンにまたがる場合や、ルーティングを集中管理するためにTransit Gatewayにアタッチする場合は、Direct Connect Gatewayを使用します。Site-to-Site VPN（BGPを使用したマネージドIPsec）は、迅速なセットアップやDXへの回復力のあるバックアップとして使用されます。非対称ルーティングを避けるために、適切なASNとルート優先度でBGPを設定します。ルーティングにおける主な落とし穴は、オンプレミスとクラウドのCIDRの重複、TGWでの不適切なルート伝播、ピアリングされたVPC間での推移的ルーティングを想定してしまうことです。MTUとフラグメンテーションはVPNトラフィックを中断させる可能性があります。パスMTUをテストし、デバイスのMSSを調整してください。マルチリージョン構成では、複数のロケーションでのアクティブ/アクティブなDX、またはDXとVPNフェイルオーバーの組み合わせを検討します。トレードオフ：専用のDX回線はコストが高いですが、ジッターと下り（egress）料金を削減します。VPNは安価でシンプルですが、高スループット時には安定性に欠けます。予測可能なフェイルオーバーを実現するために、2つの独立したトンネル、別々のロケーションにある冗長なDX接続、そしてパス選択と制限を制御するための明示的なTGWルートテーブルを使用してアーキテクチャを設計します。

DNS、PrivateLink、およびサービス接続パターン

DNSは、ハイブリッドおよびマルチアカウントのネットワーキングにおいて中心的な役割を果たします。VPCスコープの名前解決にはRoute 53プライベートホストゾーンを使用し、オンプレミスとAWSのDNS間で条件付きフォワーディングを有効にするにはRoute 53 Resolverのインバウンド/アウトバウンドエンドポイントを使用します。これにより、内部名はプライベートIPに解決され、パブリックレコードはグローバルのまま維持されるスプリットホライズンDNSがサポートされます。PrivateLink（インターフェイスエンドポイント）は、パブリックインターネット経由でトラフィックをルーティングすることなく、AWSサービスやSaaSパートナーへのプライベートなENIベースの接続を提供します。これは、より安価でENIではなくルートテーブルを使用するS3およびDynamoDB用のゲートウェイエンドポイントとは対照的です。PrivateLinkは、サービスをVPCのCIDR競合にさらすことを避け、サービス承認ポリシーによってクロスアカウントのコンシューマーをサポートします。よくある落とし穴には、すべてのコンシューマーVPCにプライベートホストゾーンを関連付けるのを忘れること、オンプレミスドメイン用のRoute 53 Resolverルールを作成しないこと、エンドポイントごとのENIのIP消費量を見誤ることなどがあります。判断基準：NATコストを避けるために、高スループットのS3/DynamoDBアクセスにはゲートウェイエンドポイントを選択します。より厳格なセキュリティが求められるAPIエンドポイントやサードパーティサービスへのプライベートアクセスが必要な場合は、インターフェイスエンドポイントを使用します。DNSのレイテンシーを監視し、変更管理のもとでTTLを設定してフェイルオーバーの動作を管理します。

Egress、NAT設計、セキュリティ統制、および運用プラクティス

Egressアーキテクチャは、コスト、監査性、サードパーティとの統合に影響します。NAT Gatewayは、プライベートサブネット向けにマネージド型で高可用性なIPv4 Egressを提供し、AZごとに自動スケーリングします。一方、NATインスタンスは低スループットのユースケースでは安価ですが、運用メンテナンスとフェイルオーバースクリプトが必要です。専用のEgress VPCをTransit GatewayにアタッチしてEgressを集中化すると、一貫したアウトバウンドIP、検査ポイント、簡素化されたポリシーを強制できますが、ヘアピンルーティングや潜在的な帯域幅のボトルネックが発生します。IPv6の場合は、Egress-Onlyインターネットゲートウェイを使用します。監査とパブリックなインバウンド認証情報の排除のために、SSH踏み台サーバーをAWS Systems Manager Session Managerに置き換えます。Session Managerは、SSHポートを開けることなくSSMエージェント経由で動作します。高度なフィルタリングとDPIのためには、TGWの背後にAWS Network Firewallまたはサードパーティ製アプライアンスをデプロイします。コストとパフォーマンスのトレードオフ: NAT Gatewayは簡単ですが、GB単位の課金が追加されます。S3のEgressコストとNATコストを削減するためにVPCエンドポイントを使用します。運用上の落とし穴には、トラフィックのトラブルシューティングのためにVPCフローログを有効にしないこと、データ漏洩を可能にする広範なEgressルールを残すこと、意図せずライフサイクル操作をブロックするSCPやIAMポリシーを使用することなどがあります。最小権限を徹底し、分析のためにすべてを中央のアカウントに記録してください。

実践的な問題: Acme Financial Services — サードパーティのホワイトリスト登録のための一元化された予測可能なEgress

シナリオ: Acme Financial Servicesは、2つのAWSリージョンにまたがって複数のアプリケーションVPCを運用しており、それらはTransit Gatewayで接続され、オンプレミスのデータセンターとはDirect ConnectおよびVPNで接続されています。別々のアカウントにあるいくつかのアプリケーションは、単一のパブリックCIDRブロックからのリクエストのみを受け付けるパートナーAPIを呼び出す必要があります。

課題: リージョンをまたがるすべてのアプリケーションVPCに対して、予測可能な単一のパブリックCIDRブロックを持つ、高可用性で監査可能なEgressパスを提供しつつ、レイテンシーと運用オーバーヘッドを最小限に抑えること。

推奨アプローチ:

BYOIP (Bring Your Own IP) を使用してパブリックIPv4 CIDRをAWSに持ち込み、そのCIDRからEgressアドレスとして使用するElastic IPを割り当てます。
各リージョンに、複数のAZにまたがるNAT Gatewayを持つ一元化されたEgress VPCを構築します。BYOIPで持ち込んだElastic IPをそれらのNAT Gatewayに関連付け、Egress VPCをTransit Gatewayにアタッチします。
すべてのアプリケーションVPCが0.0.0.0/0をEgress VPCアタッチメントにルーティングするようにTGWルートテーブルを更新し、ルート伝播とAZ間のヘルスチェックによるフェイルオーバーを有効にします。必要に応じて、オンプレミスのルーティングがローカルのEgressを優先するように設定します。
アウトバウンドフィルタリングのためにEgress VPCにNetwork FirewallまたはマネージドIDSをデプロイし、VPCフローログとCloudWatchアラームを有効にし、DNS転送のニーズがあればRoute 53 Resolverを使用します。

理論的根拠: TGWとNAT Gatewayを介してEgressを集中化し、BYOIPで提供されたIPスペースを使用することで、高可用性と一元的な監視を維持しつつ、ホワイトリスト登録のための予測可能なCIDRを提供できます。これにより、運用の簡素さ、セキュリティ統制、そして単一のパブリックCIDRを要求するパートナーの要件とのバランスが取れます。

← 組織の複雑性とマルチアカウント戦略 · すべてのドメイン · セキュリティ、アイデンティティ、コンプライアンス →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →