Microsoft AZ-700: Azure Virtual Network の設計 — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Network Engineer AZ-700 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

アドレス空間とサブネットの計画

体系的なIPアドレッシング計画は、将来の手戻りを防ぎ、オンプレミスネットワークや他のVNetとの衝突を回避します。階層的なCIDRブロック（例：主要な事業部門ごとに/16、VNetごとに/24、ロールに応じてサブネットごとに/26–/22）を使用し、拡張、ピアリング、VPN/S2Sサイトマッピングのために連続した範囲を予約します。Azureは、いくつかのプラットフォームサービスに対して名前とサブネットの要件を強制します。GatewaySubnetは存在し（VPNゲートウェイとそのスケールユニットを含むようにサイズ設定されている必要があります）、AzureFirewallSubnetは専用でAzureFirewallSubnetという名前でなければならず、AzureBastionSubnetは専用の/27以上である必要があります。Application Gatewayや多くのネットワーク仮想アプライアンスも、専用のサブネット（他のリソースなし）を必要とします。ピアリングされたVNetとオンプレミスの範囲の間でアドレスが重複しないように計画してください。アドレス空間が重複すると、ピアリング、VPN、ルーティングが機能しなくなります。プラットフォームサービス（AKS、Azure Databaseマネージドインスタンス）をデプロイする際は、サブネットの委任を検討し、それらのサービスに必要なプラットフォームルートと競合するNSGやUDRを配置しないようにしてください。よくある落とし穴は、GatewaySubnetやAzureFirewallSubnetのサイズを小さくしすぎることです。これらのサービスはスケールする可能性があり、時間とともに追加のIPが必要になります。トレードオフ：CIDRを小さくするとアドレス空間を節約できますが、将来の再構成リスクが増加します。CIDRを大きくしてもコストはかかりませんが、管理対象が増加します。すべての割り当てを文書化し、PaaSプライベートエンドポイント、ジャンプホスト、監視エージェント、および出力NAT容量のためにブロックを予約してください。

VNetピアリング、ゲートウェイトランジット、ルートの優先順位

VNetピアリングは低レイテンシ、高帯域幅の接続を提供しますが、推移的ではありません。つまり、ピアリングされたスポークからのトラフィックは、オンプレミスに到達するために2番目のピアリングされたVNetを自動的に経由してルーティングされることはありません。オンプレミス接続を一元化するには、VPN GatewayまたはExpressRouteゲートウェイを備えたハブVNetをデプロイする必要があります。ハブのピアリングでallowGatewayTransitを有効にし、スポークのピアリングでuseRemoteGatewaysを有効に設定します。VPN Gatewayはハブにのみ存在する必要があります。ピアリングには重複しないアドレス空間が必要であり、リージョンピアリングとグローバルピアリングの両方をサポートすることを覚えておいてください（グローバルピアリングではデータ転送料金とわずかに高いレイテンシが発生します）。ルートの優先順位が重要です。ユーザー定義ルート（UDR）はBGPで学習したルートやシステムルートよりも優先され、BGPルートはシステムルートよりも優先されます。出力トラフィック検査のために強制トンネリングが必要な場合は、VirtualAppliance（NVA）またはAzure Firewallを指すUDRを作成し、必要に応じてBGP経由で適切なルートをオンプレミスにアドバタイズします。よくある落とし穴には、ハブでallowGatewayTransitを、スポークでuseRemoteGatewaysを設定し忘れること、スポーク追加後にP2Sクライアント構成を再ダウンロードし忘れること（P2Sクライアントは更新されたルートが必要です）、ピアリングが推移的であると仮定することなどがあります。VPN GatewayのSKUは、スループットとP2S機能に基づいて選択します。本番環境のP2SとBGPにはVpnGw1/2/3を検討してください。Basicは多くの機能が欠けています。

VPN Gateway SKU: VpnGw1 — 中程度のスループット、OpenVPN/IKEv2/P2Sをサポート。VpnGw2 — より高いスループットとTLSスケーリング。VpnGw3 — 最高ののスループットと最大規模。Basic — 機能が限定されており、ハブシナリオには推奨されません。

サービスエンドポイント vs プライベートエンドポイントとDNSへの影響

サービスエンドポイントは、VNetのアイデンティティをAzure PaaSサービス（Storage、SQL、Cosmos DB）に拡張し、サービスのパブリックエンドポイントが選択したサブネットに対してセキュアである一方、トラフィックはMicrosoftのバックボーンを使用するようにします。プライベートエンドポイントは、サブネット内にネットワークインターフェースを配置し、それをPaaSリソースのプライベートIPにマッピングすることで、真のプライベート接続を提供します。DNSの変更なしでシンプルなサブネットレベルのアクセス制御を行いたい場合はサービスエンドポイントを選択し、リソースごとのアクセス、VNetレベルの分離、またはパブリックネットワークアクセスを完全に無効にする必要がある場合はプライベートエンドポイントを選択します。プライベートエンドポイントはENIを作成し、プライベートDNSゾーン（privatelink.<service>.azure.com）に関連付けるか、手動でDNS Aレコードを設定する必要があります。よくある落とし穴はDNSの設定を怠ることで、これによりクライアントはプライベートエンドポイントではなくパブリックIPを解決してしまいます。また、プライベートエンドポイントはターゲットサブネットからIPを1つ消費することも認識しておいてください。IP容量を計画する必要があります。サービスエンドポイントはパブリックエンドポイントを排除しません。ストレージアカウントを完全にロックダウンするには、プライベートエンドポイントを有効にした後、パブリックネットワークアクセスを無効にする必要があります。コストと運用のトレードオフ：プライベートエンドポイントは管理（リソースごとのDNSと承認）と運用上の複雑さがわずかに増加しますが、より強力な分離を提供します。サービスエンドポイントはよりシンプルで低コストですが、粒度は粗くなります。

NATゲートウェイ、Azure Firewall、およびルート設計のトレードオフ

予測可能なアウトバウンドSNATと簡素化されたエグレス管理のためには、サブネットまたはNICにAzure Virtual Network NAT (Standard NAT Gateway) をデプロイし、StandardパブリックIPまたはプレフィックス (Standard SKUのみ) をアタッチします。NAT Gatewayはエフェメラルポートの管理をオフロードします。大量のアウトバウンド接続が予想される場合は、複数のPublic IPプレフィックスをアタッチして利用可能なSNATポートを増やし、多くのVMやコンテナホストでよく見られるポート枯渇を回避してください。Azure Firewallは、一元化されたフルマネージドのステートフルインスペクション、脅威インテリジェンス、およびアプリケーション/FQDNフィルタリングを提供します。基本的なフィルタリングにはAzure Firewall Standardを、TLSインスペクション、IDPS、および強化された脅威対策機能にはPremium SKUを選択してください。ネットワーク仮想アプライアンス (サードパーティNVA) は、豊富な機能やコスト面の代替案を提供しますが、管理、HA構成、およびスケール計画が必要です。VirtualApplianceまたはInternet/NATを指すUDRは、Azureのシステムルートと照らし合わせて評価する必要があります。なぜなら、不適切なUDRはプラットフォームサービスのトラフィック（例えば、サービスエンドポイントのトラフィックやプラットフォーム管理のヘルスプローブをブロックする）を中断させる可能性があるからです。高可用性とパフォーマンスのためには、固定コストのアプライアンスと比較して、ゾーン冗長SKU (Application Gateway v2, Availability Zones内のFirewall) と自動スケーリング機能を検討してください。よくある落とし穴：サブネットとNICの両方にNATをアタッチすると予期しない優先順位が発生する、NATにはStandard Public IPが必要であることを忘れる、AzureFirewallSubnetの命名やサイジングを誤る、UDRは無視されると想定してしまう（実際にはシステムルートを上書きします）。

実践的な問題：ユースケースシナリオ

シナリオ：Contoso Enterprisesは、ハブ&スポーク構成のAzureネットワークを運用しています。West USのハブには、ExpressRouteゲートウェイとVpnGw2 (GatewaySubnet) がホストされています。いくつかのスポークには、アプリケーションサブネットとPaaSサービス用のプライベートエンドポイントが含まれています。リモートの従業員は、ポイント対サイト (P2S) VPNを介してハブに接続します。

課題：リモートユーザーはハブ内のリソースにはアクセスできますが、最近スポークが追加された後、スポーク内のVNetリソースに到達できません。また、一部のP2Sクライアントには古いルートセットが表示されています。

推奨アプローチ：

ハブVNetで、VPNゲートウェイが適切なサイズのGatewaySubnet (少なくとも/27) にデプロイされたVpnGw2であることを確認します。それがピアリングされたトポロジ内で唯一のゲートウェイであり、ExpressRouteがルート交換を介して共存していることを検証します。
ハブからスポークへのピアリングで、ハブ側のピアリングにallowGatewayTransit = trueを設定します。各スポークのピアリングでは、useRemoteGateways = trueを設定し、アドレス空間が重複していないことを確認します。
ハブのVPNゲートウェイから更新されたP2S VPNクライアント構成 (IKEv2/OpenVPNを含む) を再生成して配布し、リモートユーザーにクライアントを再インストールさせて、彼らのルートテーブルに新しいスポークのプレフィックスが含まれるように要求します。
スポークがインスペクションのためにハブ経由でアウトバウンドルーティングを行う必要がある場合は、スポークのルートテーブルに0.0.0.0/0をハブの仮想アプライアンスまたはAzure Firewall (AzureFirewallSubnetにデプロイ) に向けるUDRを追加し、ExpressRoute/VPN上のBGPを介して必要なルートをアドバタイズして戻します。

論理的根拠：useRemoteGatewaysと共にゲートウェイトランジットを有効にすると、追加のゲートウェイを作成することなく、ハブゲートウェイを介してオンプレミスとP2Sのルーティングを一元化できます。一方、P2Sクライアント構成を再発行するとクライアントのルートテーブルが更新され、新しいスポークプレフィックスに到達可能になります。UDRとBGPは、制御されたエグレスとインスペクションのための可視性を確保します。

← ExpressRoute と WAN 接続 · すべてのドメイン · ハイブリッドネットワーク →

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