Made in container

ExpressRoute の直近 1 日とか 1 週間の通信量を確認したい場合は、NPM を有効化して Log Analytics のクエリを使うと便利です。

NPM を有効化していない方は、まず以下のドキュメントの通り設定しましょう。

• ExpressRoute に使用する Network Performance Monitor の構成
  https://docs.microsoft.com/ja-jp/azure/expressroute/how-to-npm

NPMを有効化して ExpressRoute 回線の監視を有効化しておくと、Log Analytics の [Network Performance Monitor] – [NetworkMonitoring] というテーブルにログが記録されるようになりますので、以下の様なクエリで期間内の値を合算することで転送量が取得できます。Log Analytics の画面上部で対象となる期間 (時間の範囲) を指定し、クエリ内のリソース URI の箇所だけ適宜変えて使ってください。

(送受信)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| extend BitsTotalPerSecond = BitsInPerSecond + BitsOutPerSecond
| summarize sum(BitsTotalPerSecond)

(受信のみ)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| summarize sum(BitsInPerSecond)

(送信のみ)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| summarize sum(BitsOutPerSecond )

あと、1 ヶ月分を 1 日単位で集計したい等という場合には、期間を 1 ヶ月にした上で、以下の様にクエリに少し足すと 1 日単位での集計にしたりもできます。

 | summarize sum(BitsTotalPerSecond) by bin(TimeGenerated, 1d) 

ExpressRoute と名の付くサービスが増えてきたので、SKU 毎の機能差をまとめておこうと思います。
(以下は 2019/11 現在の情報に基づきます。)

3 種類の ExpressRoute サービス

• ExpressRoute Circuit (ExpressRoute 回線):
  接続プロバイダーを介して Azure と 50Mbps – 10Gbps で閉域接続するサービス
  (普通は ExpressRoute といったらこれ)
• ExpressRoute Global Reach:
  2 つの ExpressRoute 回線を介して、オンプレミス間を接続するサービス
  (例えば、東京・大阪で ExpressRoute 回線を 1 つずつ用意すれば、東阪間を MS Backbone 経由で行える)
• ExpressRoute Direct:
  Azure のエッジルーターと 10Gbps / 100Gbps で直接接続するサービス
  (要個別申請＆国内で提供されているのか不明)

各 SKU の概要

• ExpressRoute Standard:
  ER の接続場所と同一地域のリージョンにのみ接続可能
  (例えば ER を東京で契約した場合、東日本・西日本リージョンのみに接続可能)
• ExpressRoute Premium:
  世界中のリージョンに接続可能
  (ER を東京で契約していても、米国や欧州のリージョンにも接続可能)
• ExpressRoute Local (最低 1Gbps からの提供):
  ER の接続場所の最寄のリージョンにのみ接続可能な代わりに、送信データ転送に関する課金なし
  (ER を東京で契約した場合、東日本リージョンのみ接続可能)
  # 1Gbps の無制限からだと結構なお値段なので、あえて選ぶメリットあんまりないかな…

Standard / Premium の違い

PaaS のサービス等で、海外リージョンへの接続性が必要になることも多いので、悩んだら Premium SKU を使っておけばいいと思います。

App Service ドメインで購入したドメインの期限が迫ってきて、donotreply@secureserver.net のアドレスから、こんなメールが届きました。

内容的には確かに自分が買ったドメインではあるものの、メールの送信元が Azure でも Microsoft でもないし、迷惑メールに仕分けされてたんで一瞬怪しいなぁと思ってググったら、自分のブログが出てきました（

よく考えたら App Service ドメインって裏は GoDaddy 系 (?) で、管理画面は secureserver.net でしたね。一件落着。

Azure ポータルで App Service ドメインの設定を再確認しましたが、自動更新を有効にしてたので特に何もせずにスルーしても平気そうでした。

せっかくなので [ドメインの更新] から手動で更新して、スクショだけ取っておきましたとさ。

おしまい。

[サマリー]

• ExpressRoute の Microsoft Peering を構成すれば、Azure や Office 365 (要個別承認) の Public IP に対して閉域網で通信できます。
• ただし、Azure Portal や Office 365 宛の通信は ExpressRoute のみでは完結せず、一部は Internet 宛の通信が必要です。
• Proxy や Azure Firewall 等で URL フィルターはできますが、ACL や NSG のように IP でフィルターすることはできません。

[詳細]

Azure Portal や Office 365 にアクセスをする際に F12 や Fiddler トレースをとれば明らかなように、単一のページを表示するだけでも裏では多量の通信先へアクセスが行われています。Azure Portal は様々な REST API を叩いて各種リソースの情報を呼び出して表示をしていますが、どのブレード (ページ) を開くかによって REST API も様々ですし、アイコン等は Azure 外の CDN 上でホストされていることもあり、通信先は ExpressRoute でアクセスできる Public IP だけではありません。

このため、完全閉域で Internet に一切アクセスできない環境からは、Azure Portal 等へアクセスをすることはできません。

なお、Proxy や Azure Firewall 等で URL フィルターをしている場合には、以下のブログやドキュメントに記載の URL を許可してあげることで概ね解決できるかと思います。(IP は変動する可能性もあり非公開のため、ACL や NSG で IP フィルターにて制御することはできません。)

※「概ね」と書いているのは、Azure Portal は毎日のように実装が変わるものであり、新機能が追加された際に通信先が追加される可能性も十分考えられるからです。

• ネットワーク制限がかかった環境から Azure 上のリソースを管理する場合のベスト プラクティス
• ファイアウォールまたはプロキシ サーバーのセーフリストに Azure portal の URL を追加する

また、Office 365 については、以下のドキュメントやリンク先の RSS / JSON / PAC ファイルに、ER の疎通可否 (ER 列の「はい / いいえ」)、URL / IP / Port などが詳しくまとまっています。上記 Azure の場合と同様に、ワイルドカード指定で IP 未記載のものもありますので、ACL や NSG で IP フィルターを行うことはできないものと認識しましょう。

• Office 365 の URL と IP アドレスの範囲

あと、Azure AD Connect の通信も、証明書の失効確認等で Azure 外のエンドポイントと通信するらしいので、ExpressRoute だけでは完結しないとのことです。

IP も FQDN も変動するおそれがありますし、ぶっちゃけ管理工数がバカにならないので、法規制があるような場合を除いては Internet 宛の通信を制限しない方が良いと思います。

セキュリティやコンプライアンス上の理由で、Azure VM には直接 Public IP を紐づけられないように制限したいといったシナリオがあるかと思います。そういう場合には Azure Policy を利用することで制限することが可能ですのでご紹介しておきます。

まず、Azure Portal で [ポリシー] の [定義] を開くと、既に用意されている組み込みのポリシーが表示されます。あいにく、組み込みポリシーには Public IP を禁止するようなものがありませんので、 [+ ポリシー定義] から新規ポリシーを作成します。

ポリシー定義の画面では、ポリシー定義の場所 (サブスクリプションなど) を選択して任意の名前を付け、ポリシー ルールの箇所に具体的なポリシーの設定内容を定義します。今回は VM (厳密には NIC) に Public IP を付けることを禁止したいので、リソース タイプが networkInterfaces で、かつ NIC の ipconfigurations に publicIpAddress が設定されていない事を強制するため、以下のようなポリシーを定義します。

ポリシー定義の例

{
  “mode”: “All”,
  “policyRule”: {
    “if”: {
      “allOf”: [
        {
          “field”: “type”,
          “equals”: “Microsoft.Network/networkInterfaces”
        },
        {
          “not”: {
            “field”: “Microsoft.Network/networkInterfaces/ipconfigurations[*].publicIpAddress.id”,
            “exists”: “false”
          }
        }
      ]
    },
    “then”: {
      “effect”: “deny”
    }
  },
  “parameters”: {}
}

ポリシーが作成できたら、[割り当て] からポリシーを適用したいサブスクリプションやリソース グループを選択して割り当てます。

以下のようなメッセージが表示され、初回のスキャンが完了するまでに 30 分ほど時間がかかります。気長に待ちましょう。

初回の評価が終わると、既存のリソースでポリシーに準拠していないリソースがリストアップされます。

また、ポリシーの適用後に NIC に Public IP を紐づけて保存しようとすると、以下のようにエラーになるので、意図した通りに制限できたことが分かります。

JSON でポリシー定義を良い感じ書けば自由に制御できるので、Azure リソースのスキーマを理解したうえで使いこなしましょう。ちなみに、Azure Policy のプロパティに指定できるエイリアスは、Azure PowerShell で調べることが可能なので、この辺を使いこなすと楽だと思います。

https://docs.microsoft.com/ja-jp/azure/governance/policy/tutorials/create-custom-policy-definition#find-the-property-alias