ネットワークオブザーバビリティの「水源」を探る第4回

【クラウドという新大陸】主要3大クラウドの「ネイティブテレメトリ」

第4回の今回は、「AWS」「GC」「Azure」のネットワークテレメトリの水源に着目し、ネイティブデータの価値と新たな分断の課題について解説します。

6:30

導入：物理なき世界で、いかに「見る」か

前回まで、私たちはオンプレミスという物理的な“大地”の上で、ネットワークの状態を観測するための“水源”を探求してきました。SNMPという共通言語が抱える現代的な課題、Syslogが語る詳細なイベントの物語、そしてNetFlow/sFlowが描き出す通信の潮流。これらはすべて、物理的なポートやケーブル、つまり確固たる実体を持つ機器を流れるデータを捉えるための技術でした。

しかし、現代のインフラストラクチャーは、その重心をクラウドという“新大陸”へと急速にシフトさせています。物理的なルーターやスイッチに触れることなく、数回のクリックで巨大なネットワークが構築されるこの世界で、私たちは一体何を、どのように「見る」べきなのでしょうか。オフィスのサーバーラックで点滅していたリンクランプは、もはや存在しません。私たちの前には、APIコールとウェブコンソールという、純粋に論理的なインターフェースが広がっているのです。

この変化は、ネットワークの観測手法における根本的なパラダイムシフトを意味します。もはや私たちは、機器に“聞きに行く”(ポーリングする) のではなく、クラウドプラットフォームそのものが生まれながらに(ネイティブに)提供する観測データ、すなわち「テレメトリ」を受け取ることから始めなければなりません。

本稿では、主要なクラウドプラットフォームである「Amazon Web Services(AWS)」「Google Cloud(GCP)」「Microsoft Azure」が提供するネットワークテレメトリの“水源”に焦点を当てます。これらのネイティブなデータが持つ価値と、その裏で静かに進行している新たな「分断」という課題を明らかにしていきましょう。

クラウドネットワーク観測の基本単位：
「VPC Flow Logs」

クラウドにおけるネットワーク観測の旅は、多くの場合「VPC Flow Logs」という名の“水源”から始まります。VPC(Virtual Private Cloud)とは、ユーザーがクラウド内に構築する、論理的に隔離されたプライベートなネットワーク空間です。そしてVPC Flow Logsは、そのVPCの境界や内部を行き交うすべてのIPトラフィックのメタデータを記録する機能であり、いわば第3回で探求したトラフィックFlowデータのクラウドにおける実装と位置づけられます。

これは、NetFlow/sFlowが「配送伝票」に喩えられたように、「いつ、誰が、誰と、どのプロトコルとポートを使って、どれくらいの量の通信を行ったか」という情報を記録する点で、その目的は共通しています。しかし、その出自の違いから、決定的な差異も存在します。

エージェントレス: NetFlow/sFlowがネットワーク機器側での設定を必要としたのに対し、VPC Flow Logsはクラウドプラットフォームのネイティブ機能として提供されるため、仮想マシン(インスタンス)に何かをインストールする必要はありません。
フルマネージド: データの生成と収集はすべてクラウドプロバイダーによって管理されます。管理者が行うべきは、この機能を有効にし、生成されたログの保存先を指定することだけです。

この手軽さと網羅性から、VPC Flow Logsはクラウド環境におけるセキュリティ分析(不正アクセスの検知など)やネットワークのトラブルシューティングにおける、第1のデータソースとして広く活用されています。

3大クラウドの「通信日誌」：その仕様と差異

VPC Flow Logsは非常に強力な“水源”ですが、注意すべき点があります。それは、かつてSNMPの世界で各ベンダーが「拡張MIB」を個別に開発し、標準が形骸化していった歴史をなぞるように、基本的な概念は共通しているものの、その具体的な仕様はクラウドプロバイダーごとに異なるという事実です。この「方言」の違いを理解することは、マルチクラウドが当たり前となった現代において極めて重要です。

Amazon Web Services(AWS): VPC Flow Logs

AWSは、この分野の草分け的存在です。VPC内のネットワークインターフェース(ENI)単位でトラフィックをキャプチャし、そのログをAmazon S3やCloudWatch Logsといった他のAWSサービスに出力します。

特徴:
- ログのフォーマットが柔軟にカスタマイズ可能。デフォルトでも多くの情報を含んでいますが、パケットのTCPフラグなど、より詳細な情報をフィールドとして追加できます。
- キャプチャ対象をVPC全体、特定のサブネット、または特定のENIと柔軟に選択できます。
ログの基本フォーマット(一部抜粋):
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
有効化の設定例(AWS CLI):
以下のコマンドは、指定したVPCのすべてのトラフィック(許可/拒否)をキャプチャし、そのログをCloudWatch Logsの特定のロググループに配信する設定例です。
```
　aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0123456789abcdef0 \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name my-vpc-flow-logs
```

Google Cloud(GCP): VPC Flow Logs

GCPのVPC Flow LogsもAWSと同様の目的を持ちますが、アーキテクチャにいくつかの違いが見られます。ログはサブネット単位で有効/無効を設定し、Cloud Loggingに集約されます。

特徴:
- デフォルトでトラフィックがサンプリングされる期間があります。これによりログの量を調整できますが、すべての通信を網羅できない可能性がある点に注意が必要です。これは、第3回で解説したsFlowの思想に近いアプローチと言えます。
- ログにはGKEクラスタ名やインスタンス名といったGCPの内部的なメタデータを付与する機能があり、リソースの識別に役立ちます。

ログの基本フォーマット(JSON形式の一部抜粋):

{
  "connection": {
    "src_ip": "10.0.1.2",
    "dest_ip": "192.168.0.1",
    "src_port": 12345,
    "dest_port": 443,
    "protocol": 6, // TCP
  },
  "packets_sent": "10",
  "bytes_sent": "850",
  ...
}

有効化の設定例(gcloud CLI):
指定したサブネットでフローログを有効にするコマンド例です。
```
　gcloud compute networks subnets update my-subnet \
--region=us-central1 \
--enable-flow-logs
```

Microsoft Azure: NSG Flow Logs

AzureのアプローチはAWSやGCPとは少し異なります。フローログはVPC(VNet)やサブネットではなく、ネットワークセキュリティグループ(NSG)というファイアウォール機能に紐づけて有効化します。これは「どの通信を許可/拒否したか」というセキュリティの文脈がより強いことを意味します。

特徴:
- NSGのルールにより「許可(Allow)」または「拒否(Deny)」されたトラフィックの情報が記録されます。これは、第3回のコラムで紹介したCiscoのNSEL(NetFlow Secure Event Logging)の思想に通じるものです。
- ログはAzure Storage AccountにJSON形式で書き出されます。

ログの基本フォーマット(バージョン2の一部抜粋):

{
  "time": "2025-10-17T10:00:00.123Z",
  "systemId": "<GUID>",
  "macAddress": "00-0D-3A-12-34-56",
  "ruleName": "AllowInternetOutbound",
  "flows": [
    {
      "flowTuples": [
        "1665997200,10.1.0.4,13.107.21.200,49568,443,T,O,A,C,10,6520,12,8364"
        // UnixTime,SrcIP,DstIP,SrcPort,DstPort,Protocol,Direction,RuleAction,FlowState,Packets,Bytes...
      ]
    }
  ]
}

有効化の設定例(Azure CLI):
特定のNSGに対してフローログを有効化し、指定したストレージアカウントに保存する設定例です。
```
　az network nsg flow-log create \
--nsg myNsg \
--resource-group myResourceGroup \
--storage-account myStorageAccount \
--enabled true
```

結論：統一された概念、分断される仕様

クラウドへのシフトは、ネットワーク観測の世界に大きな恩恵をもたらしました。物理的な制約から解放され、プラットフォームが提供するネイティブなテレメトリによって、私たちは広大な仮想ネットワークの隅々まで、エージェントレスで容易に可視化する強力な手段を手に入れたのです。AWS、GCP、Azureが提供するFlow Logsは、現代のネットワークオブザーバビリティにおける、間違いなく最も重要な“水源”の1つと言えるでしょう。

しかし、その一方で、私たちは新たな課題に直面しています。それは、標準化の欠如による「仕様の分断」です。各プロバイダーが提供するログは、その目的こそ似ていますが、有効化の方法、データのフォーマット、そして含まれる情報の粒度に至るまで、すべてが異なります。マルチクラウド環境でこれらの方言が異なる“水源”から水を汲み、一貫した視点でネットワーク全体を理解しようとするとき、私たちはその翻訳作業に多大な労力を強いられることになるのです。

そして、この「分断」の潮流は、パブリッククラウドの世界に留まりません。筆者が「Interop Tokyo 2025」で各出展社にヒアリングした限りでは、オンプレミスの世界でも従来の機器ベンダーが自らの管理プラットフォームをクラウド化し、独自のAPIを通じてテレメトリを提供する動きが加速しています。

次回は、このもう1つの大きな潮流、「Cisco Meraki」や「Juniper Mist AI」といった、ベンダー独自のクラウドプラットフォームが提供する「API」というパンドラの箱を開けていきます。クラウドネイティブのテレメトリとベンダーAPI、この2つの潮流が交錯する現代において、ネットワークオブザーバビリティの探求は、さらに複雑で奥深い領域へと進んでいきます。

※記載されている商標について
本記事に記載されている会社名、製品名、サービス名は、一般に各社の登録商標または商標です。

この記事のキーワード：