Azure Traffic Managerとは？DNSベース負荷分散の仕組みと6つのルーティング方式・Front Doorとの使い分けを実装目線で解説

Azure Traffic Managerは、DNSの応答内容を切り替えてクライアントを複数のエンドポイントへ振り分けるサービスです。通信そのものは経由しません。この記事では、CNAMEを返す名前解決の流れ、6つのルーティング方式の設定値、プローブ間隔と障害許容数から逆算するフェールオーバー所要時間、Front Doorとどちらを採るかの判断基準をまとめました。数値は2026年9月3日時点のMicrosoft Learnの記載に基づきます。

まとめ：DNSベース負荷分散としての立ち位置と採用可否の結論

Traffic Managerの本質はDNS応答の出し分けです。プロキシではないため、TLS終端もキャッシュもWAFも持ちません。裏を返せば、HTTP以外のプロトコルでも、Azure外のサーバーでも、インターネットから到達できれば同じ仕組みで振り分けられます。この汎用性が持ち味です。

採否の線引きは明快です。HTTP／HTTPSのWebアプリでキャッシュ配信やWAF、パスベースの振り分けが要るならAzure Front Doorを選びます。Microsoftも両方を重ねる構成は案内していません。非HTTP通信、オンプレミスとAzureを並走させる移行期、リージョン単位のフェールオーバーだけが要件という場合は、Traffic Managerのほうが軽く済みます。

設計で効いてくるのはDNSキャッシュです。切替時間はプローブ間隔・障害許容数・TTLの合計で決まる。この前提で可用性要件を握るところが実装の勘所になります。

DNSレベルで動作する仕組みとプロキシ型ロードバランサーとの構造差

まず押さえるのは、Traffic Managerがトラフィックの通り道に立たない構造です。ここを取り違えると、TLS証明書の置き場所やログの取得場所の設計を誤ります。

CNAME応答で直結する名前解決フローとtrafficmanager.netの役割

プロファイルを作ると <プロファイル名>.trafficmanager.net が払い出され、自社ドメインからCNAMEでこれを指します。クライアントが partners.example.com を引くと、権威DNSがCNAMEで example.trafficmanager.net を返し、再帰DNSがTraffic Managerのネームサーバーへ問い合わせます。Traffic Managerはルーティング方式と正常性チェックの結果からエンドポイントを1つ選び、CNAMEとして返す。再帰DNSがそれを解決し、最終的なAレコードがクライアントへ渡ります。

DNSの仕様上、ゾーン頂点（example.com のようなネイキッドドメイン）にCNAMEは置けません。頂点で受けるなら、ドメインをAzure DNSでホストしてエイリアスレコードでプロファイルを指すか、Traffic Managerリンクレコードを使ってCNAMEホップなしでIPアドレスを返す構成にします。この回避策を知らずに「wwwなしでは使えない」と結論づける例は珍しくありません。

プロキシを介さない設計で生じるプロトコル非依存性と可視化の限界

選ばれたエンドポイントへは、クライアントが直接接続します。Traffic Managerはゲートウェイでもプロキシでもなく、クライアントとサービスの間を流れるトラフィックを一切見ていません。この性質から扱えるプロトコルに制約がなく、HTTPでもTCPでもUDPでも成立します。

裏返しとして、アクセスログやリクエスト内容はTraffic Manager側では取れません。得られるのはDNSクエリ量とエンドポイントの正常性だけで、アプリケーションログは各エンドポイントで集めます。この点がロードバランサーの仕組みと振り分け方式で扱うプロキシ型の製品と決定的に異なる部分です。既存のTCPセッションも、DNS応答が変わった時点では切れません。旧エンドポイントから確実に退避させたいなら、アプリ側でセッション継続時間に上限を設けておきます。

Azure・外部・入れ子の3種類のエンドポイントと指定できる形式

エンドポイントは3種類あります。Azureエンドポイントは同一サブスクリプション内のApp ServiceやPublic IPリソースを直接指定するもの。外部エンドポイントはFQDNまたはIPv4／IPv6アドレスで指定し、他社クラウドやオンプレミスの機材を対象にできます。入れ子になったエンドポイントは、別のTraffic Managerプロファイルを子として登録する形です。

入れ子は「1プロファイル1ルーティング方式」の制約を越える手段でもあります。親をパフォーマンス方式でリージョン選択に、子を重み付け方式でリージョン内の配分に、という二段構えは入れ子でしか組めません。

6つのトラフィックルーティング方式の挙動差と設定値から見る選定基準

ルーティング方式はプロファイル単位で1つだけ選びます。変更はダウンタイムなしで1分以内に反映されるため、後から切り替える前提で始めても構いません。ただし方式ごとに失敗の仕方が違います。

優先順位1〜1000と重み付け1〜1000の設定値が生む分散の差

優先順位方式は、エンドポイントに priority を1〜1000で振り、小さい値から順に使います。同じ値を複数に付けることはできず、省略時は登録順で既定値が入ります。プライマリが劣化と判定された時点で次の値へ切り替わる、単純なフェールオーバー構成です。

重み付け方式は weight を1〜1000で指定し、DNSクエリごとに重みに応じた確率で1つを選びます。省略時の既定は1。注意点が1つあります。DNS応答はキャッシュされるため、クライアントや再帰DNSサーバーの母数が小さい環境では配分が大きく偏るのです。社内プロキシ経由の従業員向けアプリで5対5に設定しても、実際は片側へ張り付く事態が起こり得ます。母数の小さい環境での重み付けは避けます。

パフォーマンスと地理的の判定根拠の違いとデータ所在地要件での選択

パフォーマンス方式は、地理的な距離ではなくネットワーク遅延で近さを決めます。Traffic Managerが持つインターネット遅延テーブルからDNSクエリ送信元のIP範囲を引き、往復時間が最小のAzureデータセンター内のエンドポイントを返す仕組みです。テーブルは定期更新されるため、同じクライアントが日をまたいで別のエンドポイントへ向くこともあります。エンドポイントごとの負荷は見ていません。

地理的方式は、クエリ送信元の地理的リージョンをエンドポイントへ明示的に割り当てます。粒度は世界・地域グループ・国／地域の3階層に加え、オーストラリア・カナダ・米国のみ州レベルまで指定可能。データ所在地の規制対応のように確定的な境界が要るならこちらです。ただし1つのリージョンは1つのエンドポイントにしか割り当てられず、そのエンドポイントが停止していてもフェールオーバー先は選ばれません。実運用では各エンドポイントを子プロファイル（エンドポイント2つ以上）にした入れ子構成にし、どのリージョンにも一致しないIPアドレス向けに「世界」の受け皿を必ず置きます。受け皿がなければNODATAが返ります。

複数値・サブネットが機能する条件とフォールバック未設定時のNODATA

複数値方式は、1回のDNS応答で正常なエンドポイントを複数返し、クライアント側に再試行させます。返却数の既定は2件。成立条件が厳しく、すべてのエンドポイントが外部型かつIPv4／IPv6アドレスで指定されている場合にしか機能しません。FQDN指定が1つでも混ざると使えない点は、設計前に確認しておきます。

サブネット方式は、送信元IPアドレス範囲とエンドポイントを対応付けます。CIDR表記でも範囲指定でも書けますが、プロファイル内で範囲が重複してはいけません。ここでもアドレス範囲を持たないフォールバック用エンドポイントを1つ置きます。置き忘れると、未定義のIP帯からのアクセスにNODATAが返ります。

エンドポイント正常性監視の設定値とフェールオーバー完了までの時間設計

Traffic Managerは既定で監視が有効です。ここで設定する3つの値とDNSのTTLが、そのまま障害時の切替時間を決めます。可用性のSLOはこの4つから逆算します。

プローブ間隔30秒と10秒・障害許容数0〜9・タイムアウトの組み合わせ

プローブのプロトコルはHTTP・HTTPS・TCPから選びます。HTTPSでも証明書の有効性は検証されず、存在の確認のみ。TLS 1.0および1.1のサポートは2025年2月28日に終了しています。

プローブ間隔は30秒（通常）と10秒（高速）の2択で、既定は30秒です。10秒側は追加課金の対象。障害の許容数は0〜9で、既定は3。0にすると1回の失敗で即座に劣化と判定されます。タイムアウトは間隔に連動し、間隔30秒なら5〜10秒（既定10秒）、間隔10秒なら5〜9秒（既定9秒）の範囲で設定します。

HTTP／HTTPS監視では、想定する状態コード範囲を 200-299, 301-301 の書式で最大8個まで指定できます。既定は200のみが成功扱い。302リダイレクトを返す構成のまま既定値で監視すると、アプリは動いているのに全エンドポイントが劣化と判定される事故が起きます。ヘルスチェック専用のパスを用意し、そこで200を返す作りが確実です。

検知からトラフィック移動までの所要時間の内訳とDNS TTLの決め方

切替完了までの時間は、次の3つの足し算になります。

1. 障害発生から検知まで：プローブ間隔 ×（障害許容数 + 1）。間隔30秒・許容数3なら4回連続失敗で劣化と判定されるため、最大で約120秒
2. DNS応答の更新：劣化判定後、Traffic Managerのネームサーバーがそのエンドポイントを応答に含めなくなるまで
3. キャッシュの失効：再帰DNSとクライアントが保持する旧応答が、TTLの経過まで残る

TTLは0秒から2147483647秒まで設定できます。短くすればキャッシュは早く切れる一方、Traffic Managerへの問い合わせが増えてDNSクエリ課金も比例して膨らみます。フェールオーバー重視なら30〜60秒から始め、クエリ数の実績を見て調整するのが扱いやすい落としどころ。間隔10秒・許容数0・TTL 30秒まで詰めれば1分弱まで縮められますが、秒単位の切替が要件なら、DNSベースという方式自体が合っていません。

AzureTrafficManagerサービスタグでプローブ到達性を確保する設定

プローブは複数の場所から送られます。エンドポイント側のNSGやファイアウォールでこれを遮ると、アプリが正常でも全エンドポイントが劣化と判定されるのです。NSGやAzure Firewallでは AzureTrafficManager サービスタグを許可するのが推奨で、IP範囲の変更に自動追随します。Azure外のアプライアンスではサービスタグを使えないため、Microsoftが公開するIP範囲のJSONを取り込んで定期更新する運用にします。

押さえておきたい挙動が1つあります。対象となる全エンドポイントが劣化した場合、Traffic Managerは全部が正常であるかのように応答を返すのです。監視設定を誤っていても表面上は疎通して見える、ということでもあります。プロファイルの監視状態が「オンライン」かを公開前に確認し、「劣化」のまま運用に入らないことがフェールオーバーを機能させる前提。なお、プライベートアドレスに解決されるエンドポイントは監視対象外で、「常にトラフィックを提供する」設定が強制されます。内部名前解決を担うプライベートDNSの領域とは扱いが分かれます。

Front Door・Application Gatewayとの機能差と併用を避ける判断

Azureのトラフィック分散は、グローバル層とリージョン層、HTTP専用と汎用の2軸で整理すると迷いません。Traffic Managerはグローバル層かつ汎用の位置です。

Front Doorとの機能差と両方を重ねない構成に寄せる判断基準

Azure Front Doorは、クライアントに近いPOPで接続をいったん終端し、オリジンへは別の長寿命な接続を張ります。TLS終端・キャッシュ配信・パスベースのルーティング・WAFはこの構造だから提供できるもの。名前解決の答えを返すだけのTraffic Managerにはどれもありません。

Microsoftは、ほとんどのソリューションでどちらか一方を使い、両方を重ねないよう案内しています。判断基準は単純。対象がHTTP／HTTPSで、キャッシュ・WAF・URL単位の振り分けのいずれかが要るならFront Doorへ寄せます。Front DoorのStandard／Premiumの違いと採用判断を整理した記事と本記事は、この分岐の左右を担当する対の関係。逆に、非HTTPを含む場合や、クライアントとオリジンの間に何も挟みたくない場合はTraffic Managerです。両方を直列に置くと、障害時の切替経路が二重になって切り分けが難しくなります。

Application Gatewayと二段で組む階層構成と監視パスの揃え方

Application Gatewayはリージョン内のL7ロードバランサーで、URLパスによる振り分けやWAF、セッション固定を担います。Azure Load BalancerはリージョンのL4分散で、VM群へのTCP／UDP分散を受け持つ層。この2つとTraffic Managerは層が違うため競合しません。

実務でよく組む形は、Traffic Managerでリージョンを選び、各リージョンの入口にApplication Gatewayを置いてL7の処理を担わせる二段構成です。Traffic Managerのエンドポイントには、各リージョンのApplication GatewayのパブリックIPまたはFQDNを外部エンドポイントとして登録します。この形なら、リージョン障害はDNSで、リージョン内のインスタンス障害はバックエンドプールで吸収できるわけです。監視パスを両層で揃えないと、片方だけが劣化を検知して挙動が食い違います。

Traffic Managerを採用する条件と見送るべき場面の切り分け

ここからは判断を言い切ります。Traffic Managerは万能な入口ではなく、適合条件が限定されたサービスです。

非HTTP通信と外部エンドポイント併存でTraffic Managerを選ぶ条件

次のいずれかに当てはまるなら、Traffic Managerを採用します。

• HTTP／HTTPS以外のプロトコルを分散する（メール、独自TCPプロトコル、ゲームサーバーなど）。Front DoorもApplication GatewayもHTTP専用のため、選択肢が1つに絞られる
• Azure以外のエンドポイント（他社クラウド、オンプレミス）をAzureと同じプロファイルで束ねる
• クライアントへ直接つながせたい。中継が入らないため送信元IPがそのまま届き、TLSも端から端まで自前で管理できる
• リージョン単位のDR切替だけが要件で、分単位の切替時間を許容できる

移行案件では、オンプレミスとAzureを重み付け方式で並走させ、重みを10対90、50対50と動かしながら切り戻せる状態を保つ使い方が効きます。AWS・Google Cloud・Azureのインフラ構築では、この段階的な移し替えの設計と切り戻し手順の整備までを支援しています。

即時切替・WAF・キャッシュ要件がある案件で採用を見送る理由

逆に、以下が1つでもあるなら採用しません。代替に振ります。

第一に、RTOが秒単位の要件。DNSキャッシュは制御できないため、TTLを0にしても中継するリゾルバの実装次第で残ります。この場合はAnycastで受けるFront Door、またはリージョン内で完結するLoad Balancerに寄せます。第二に、WAFや静的コンテンツのキャッシュが要件に入る場合。結局Front Doorを重ねて二重構成になるため、最初からFront Doorだけで組みます。第三に、再帰DNSサーバーの母数が小さい環境での重み付け分散。社内向けアプリのカナリアリリースを重みで制御して配分が効かなかった、という失敗はここに起因します。この用途にはApp Serviceのデプロイスロットや機能フラグを使います。

DNSクエリ課金と正常性チェック課金の二階建て構造とコストの読み方

課金は大きく2本立てです。1つはDNSクエリの従量課金で、100万クエリあたりの単価が月10億クエリを境に2段階になります。もう1つは正常性チェックの月額で、Azureエンドポイントと外部エンドポイントで単価が分かれ、エンドポイント数に比例。ここに高速間隔プローブ（10秒）、HTTPS監視、入れ子エンドポイント、リアルユーザー測定、Traffic Viewがアドオンとして上乗せされます。単価は改定されるため、見積もりは料金計算ツールで実施時点の値を確認してください。

費用構造から導ける設計指針は2つ。TTLを短くするとDNSクエリ数が増えて従量分が膨らむため、切替時間の要件と課金のバランスで決めること。高速プローブやHTTPS監視はエンドポイント数ぶん効くため、要件のある系統だけに絞ること。Azure Monitorによる監視の仕組みと料金モデルと合わせ、可用性まわりの費用として一括で見積もると判断しやすくなります。

よくある質問

導入検討でよく挙がる疑問を、公式ドキュメントに沿って整理します。

Azure Traffic ManagerとAzure DNSは何が違いますか？

Azure DNSはDNSゾーンをホストする権威DNSサービスで、レコードの内容は静的に管理します。対してTraffic Managerは、エンドポイントの正常性とルーティング方式に応じて応答内容を動的に変える仕組み。役割が競合しないため、実際には併用します。自社ドメインをAzure DNSでホストし、CNAMEまたはエイリアスレコードでプロファイルを指す構成が標準的です。

フェールオーバーはどのくらいの時間で完了しますか？

検知に「プローブ間隔 ×（障害許容数 + 1）」、切替の反映にDNSのTTLぶんがかかります。既定値（間隔30秒・許容数3・TTL 30秒）なら検知に最大約120秒、キャッシュ失効に最大30秒で、合計おおむね2分半前後。間隔10秒・許容数0・TTL 30秒まで詰めれば1分弱まで短縮できますが、高速プローブは追加課金の対象です。既存のTCP接続は維持されるため、その分の退避はアプリ側のセッション設計で吸収します。

Traffic ManagerでSSL証明書の設定は必要ですか？

Traffic Manager側に証明書を置く設定はありません。TLSはクライアントとエンドポイントの間で直接ネゴシエートされるため、証明書は各エンドポイントに配置します。カスタムドメインで受けるなら、コモンネームやSANはそのドメイン名に対して発行しておくこと。監視プロトコルにHTTPSを選んだ場合も有効性は検証されず、期限切れでも監視は成功します。

オンプレミスのサーバーをエンドポイントにできますか？

できます。外部エンドポイントとしてFQDNまたはIPv4／IPv6アドレスで登録する形です。条件は、Traffic Managerのプローブがインターネット経由で到達できること。オンプレミス側のファイアウォールでIP範囲を許可し、監視用のパスやポートを開けておきます。到達できないエンドポイントは「常にトラフィックを提供する」設定が強制され、自動フェールオーバーは働きません。

Front DoorとTraffic Managerを併用してもよいですか？

Microsoftはどちらか一方を使う構成を案内しており、両方を重ねることは推奨されていません。判断はHTTP／HTTPSかどうかと、キャッシュ・WAF・パスベース振り分けの要否で切り分けます。例外的に検討されるのは、非HTTPの系統が同一ドメイン配下に混在するケース。その場合もホスト名を分けて片方だけを通す設計にします。

関連記事

• Azure Front Doorとは？CDN・グローバル負荷分散・WAFの仕組み：本記事と対で使い分けを判断する対象。
• ロードバランサーとは？仕組み・種類・振り分け方式：DNSベースとの構造差を掴む前提知識。
• Azure Application Gatewayとは何か？その概要と重要性を解説：二段構成で下段を担うL7層。
• Azure Monitorとは？監視の仕組みとLog Analyticsの関係：エンドポイント状態のアラート化に。
• Azure Virtual Machinesとは？VMシリーズ・料金モデルと可用性設計：エンドポイント側の可用性設計。