Microsoft AZ-700: ネットワークの監視とトラブルシューティング — 学習ガイド

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

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

可観測性ツールとデータソース

Azureネットワークにおける可観測性は、Network Watcher、Azure Monitor (Log Analytics)、およびリソースからのテレメトリを中央のワークスペースまたはストレージアカウントにストリーミングする診断設定が中心となります。Network Watcherは、パケットキャプチャ、IPフローの確認、ネクストホップ、接続のトラブルシューティング、およびConnection Monitorを提供します。Connection Monitor v2は、マルチエンドポイント、マルチプロトコルのテストをサポートし、クエリ可能なテレメトリとして結果をLog Analyticsワークスペースに保存します。NSGフローログはNetwork Watcherを介して有効になり、JSONレコードをストレージアカウントに書き込みます。Traffic Analyticsを有効にすると（フローログとLog Analyticsワークスペースが必要）、これらのログがアプリケーションや地理的なインサイトと視覚化で強化されます。Azure Firewall、Application Gateway/WAF、Front Door、およびロードバランサーの診断設定は、シグナルを関連付けるために同じLog Analyticsワークスペースにルーティングする必要があります。よくある落とし穴には、ストレージアカウントのファイアウォールルールがフローログの書き込みをブロックする、古いテナントでリージョンごとにNetwork Watcherを有効にするのを忘れる、ストレージとLog Analyticsで保持ポリシーに一貫性がない、といった点が含まれます。コストと機能のトレードオフは明確です。低コストのアーカイブのために生ログをストレージアカウントに書き込むか、クエリとアラートのためにLog Analyticsに取り込むか（高コストですが、診断価値ははるかに高い）です。診断パイプラインが書き込みでき、アナリストがログを読み取れるように、ロールベースのアクセス制御（必要に応じてMonitor ReaderとStorage Blob Data Reader）を設定する必要があります。

パケットキャプチャ、Connection Monitor、および詳細な診断

パケットレベルのトラブルシューティングには、Network Watcherのパケットキャプチャ（ポータル/CLI/PowerShell経由）を使用して、PCAPファイルをストレージアカウントまたはローカルVMファイルに作成します。過剰なストレージ使用とパフォーマンスへの影響を避けるため、パケットキャプチャフィルター（プロトコル、送信元/宛先IP、ポート）とサイズ/時間制限を設定します。高速ネットワークを備えた高スループットのVMでは、ホスト側のパケット可視性が制限される場合があります。オフロードされたパケットを見逃さないように、VNet TAPを使用してトラフィックをコレクターVMまたはNVAにミラーリングします。Connection Monitorは、アクティブな合成テストに使用します。送信元と宛先のエンドポイント（IP、FQDN、ポート）を定義し、テスト頻度を選択し、複数セグメントの診断のためにホップごとのレイテンシとパスのキャプチャを有効にします。特定の5タプルがNSG/UDRによって許可されているか拒否されているかを確認するにはIPフローの確認を、有効なルーティングを確認するにはネクストホップを使用します。注意点：Windows VMでのパケットキャプチャは昇格された権限を必要とする場合があり、OSのオフロードによる影響を受ける可能性があります。パケットキャプチャはCPU/ディスク負荷が高くなる可能性があるため、的を絞ったフィルターと時間制限を設けることが推奨されます。大規模な継続的パケットインスペクションには、VNet TAPを、PCAPストリームを取り込むことができるパケット分析アプライアンスやクラウドSIEMと組み合わせます。

NSGフローログ、Traffic Analytics、およびセキュリティ診断

NSGフローログ（バージョン2）は、タイムスタンプ、5タプル、バイト/パケット数、および決定（許可/拒否）を含むフローレコードを提供します。ペイロード、アプリケーション層のセッション詳細、または復号化されたTLSは含まれません。Traffic Analyticsは、フローログをトップトーカー、ASN、地理マッピングで強化し、Log Analyticsワークスペースを必要とします。Azure Firewall、Application Gateway/WAF、およびAzure Front Doorは独自の診断を出力します。これらは統一されたクエリのためにLog Analyticsに送信する必要があります。重要な設計上の落とし穴：NICレベルで適用されたNSGルールは、サブネットレベルのルールよりも優先されます。デフォルトルール（例：AzureLoadBalancer、インターネットルール）が存在し、削除はできず、より高い優先度のルールで上書きすることしかできません。フローログの有用性は、保持と取り込みの戦略次第です。Log Analyticsでの長期保持は高価ですが、短期保持ではフォレンジック証拠を失うリスクがあります。NSGフローログをFirewallの診断ログおよびKustoクエリに基づくアラートルールと組み合わせて、ラテラルムーブメントやデータ窃取を検出します。修正措置を計画する際は、SNATポートの枯渇を緩和するためにAzure Firewallに専用のパブリックIPを追加することを検討し、Log Analyticsのコストが高すぎる場合はDiagnosticSettingsを活用してEvent Hubsにルーティングし、SIEM統合を行うことを検討してください。

トラブルシューティングのパターン、ルーティングの落とし穴、設計のトレードオフ

接続性のトラブルシューティングを行う際は、階層的なアプローチに従います。まずリソースレベルのNSG/UDRを検証し、有効なルートとネクストホップを確認します。次にIP Flow VerifyとConnection Troubleshootを使用し、必要であればパケットキャプチャやVNet TAPにエスカレーションします。ルーティングの落とし穴は、強制トンネリング、重複するCIDR、または適切なリターンルートなしにトラフィックをAzureFirewallSubnetに送信する誤って構成されたUDRで表面化することがよくあります。負荷分散とスケールのためには、L4対L7のニーズやグローバル対リージョンのトラフィック管理に基づいて、Azure Standard Load Balancer、Application Gateway WAF、Front Doorの中から選択します。以下のSKUのトレードオフを考慮してください：

Azure Firewall Standard vs Premium: Premiumは、より高いコストでTLSインスペクション、IDPS、URLフィルタリングを追加します。詳細なトラフィックインスペクションと規制要件の遵守が必要な場合にPremiumを選択します。
Azure Front Door Standard vs Premium: Premiumは、高度なWAF機能とプライベートリンク統合をサポートします。Standardは、一般的なグローバルCDN＋ルーティング用途で低コストです。
VNet TAP vs パケットキャプチャ: TAPは高コストですが、大規模環境でのロスレスキャプチャや、高速ネットワークがパケットをオフロードする場合に必要です。トレードオフは、パフォーマンス、コスト、回復性を中心に展開されます。NVAはFirewall Premiumよりも安価であったり、機能が豊富であったりする場合がありますが、HA（高可用性）構成で設計しない限り、管理オーバーヘッドと単一障害点のリスクが増加します。可観測性のニーズと取り込みコストのバランスを取るために、SNAT容量を計画し、予備のパブリックIPを予約し、診断パイプラインを準備します。

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

シナリオ：Contoso Electronicsは、EastUSとWestEuropeの2リージョンでAzure環境を運用しており、ハブ&スポークVNet、ハブにAzure Firewall Standard、複数のスポークにApplication Gateway WAF、そして監視用の中央Log Analyticsワークスペースを配置しています。最近、スポークに展開した一連の本番VMから、ExpressRoute回線経由でオンプレミスのSQLクラスターへの接続で断続的な障害が発生していると報告がありました。

課題：パケットレベルの明確な証拠がないまま、オンプレミスリソースへの断続的な接続性と高いレイテンシーが発生しています。既存のNSGフローログは有効ですが、許可されたフローが表示されるのみで、レイテンシーのメトリクスはありません。

推奨アプローチ：

代表的なVMからオンプレミスのSQL FQDNおよびIPに対し、TCPポート1433を使用してConnection Monitor v2を展開し、30秒ごとにテストを設定し、結果を中央のLog Analyticsワークスペースに送信して、ホップごとのレイテンシーと到達可能性をキャプチャします。
影響を受けているVMでNetwork Watcherのパケットキャプチャを有効にし、SQLクラスターの送受信IPとポート1433でフィルタリングし、ライフサイクルポリシーを設定したストレージアカウントにPCAPを保存します。同時に、高速ネットワークが存在する場合は、スポークサブネットでVNet TAPを有効にして、専用のコレクターVMにトラフィックをミラーリングします。
Azure Firewall (Standard) の診断設定を構成し、アプリケーションログとネットワークログを同じLog Analyticsワークスペースに送信します。そして、Connection Monitorの結果、ファイアウォールログ、NSGフローログを結合する相関クエリを実行し、ファイアウォールのSNAT枯渇やポリシーによるドロップを検出します。
インシデント発生中に、障害が発生している5タプルに対してIP Flow VerifyとNext Hopを使用します。SNATや非対称ルーティングが疑われる場合は、Azure Firewallに追加のパブリックIPを追加するか、スポークにNAT Gatewayをデプロイして予測可能なエグレスを確保し、ハブ経由でルーティングするようにUDRを更新します。

論理的根拠：Connection Monitorは、合成的な、タイムスタンプ付きの到達可能性とホップごとのレイテンシーを提供します。パケットキャプチャとVNet TAPは、OSのオフロードによってトラフィックが不明瞭になる場合に、ロスレスのフォレンジックデータを提供します。Log AnalyticsでファイアウォールとNSGのログを関連付けることで、ポリシー、SNAT、または非対称ルーティングの問題を特定します。パブリックIPの追加やNAT Gatewayの導入は、ポート枯渇を緩和し、エグレスの動作を安定させます。

← 負荷分散とトラフィック管理 · すべてのドメイン · Azure Virtual WAN とハブアンドスポーク →

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