実践！AWSネットワーク構築・運用30日チャレンジ: Day 15

Last updated at 2025-07-26Posted at 2025-07-25

Day 15: Amazon CloudWatch：ネットワークメトリクスとアラーム設定

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 15へようこそ！

2週間の基礎固めを終え、今日から第3週がスタートします。この週では、「ネットワーク監視と運用、セキュリティ強化」に焦点を当てていきます。どんなに完璧に設計されたネットワークでも、適切に監視し、異常を早期に検知して対応できなければ、安定した運用は望めません。

今日のテーマは、AWSの監視サービスの中核をなす「Amazon CloudWatch」です。特に、ネットワークに関連するメトリクス（性能指標）の監視と、異常を検知した際のアラーム設定について詳しく見ていきます。

1. Amazon CloudWatchとは？監視の重要性

Amazon CloudWatch は、AWSリソースとアプリケーションを監視するためのフルマネージドサービスです。リソースの使用率、アプリケーションのパフォーマンス、運用状態など、様々なデータをリアルタイムで収集・追跡し、メトリクスとして可視化します。また、設定したしきい値を超えた場合にアラームを発報し、自動的にアクションを実行することも可能です。

なぜネットワーク監視が重要なのか？

問題の早期発見と解決: ネットワークのボトルネック、通信エラー、異常なトラフィックパターンなどを早期に検知し、サービス影響が拡大する前に対応できます。
パフォーマンスの最適化: ネットワークの利用状況を把握することで、リソースの適切なサイジングや、パフォーマンスチューニングのヒントを得られます。
コストの最適化: 不要なトラフィックやリソースの過剰なプロビジョニングを特定し、コスト削減につなげられます。
セキュリティの強化: 異常なネットワークアクティビティを監視することで、潜在的なセキュリティ脅威（例: DDoS攻撃、不正アクセス）を検知できます。
SLA (サービスレベルアグリーメント) の遵守: ネットワークの健全性を継続的に監視することで、サービスの可用性やパフォーマンスに関するSLAを遵守するのに役立ちます。

2. CloudWatchの主要なコンポーネント

CloudWatchは、以下の主要なコンポーネントで構成されています。

メトリクス (Metrics): 監視対象のデータポイント。CPU使用率、ネットワークI/O、ディスクI/O、リクエスト数、エラー率など、様々な数値データが収集されます。AWSサービスはデフォルトで多くのメトリクスをCloudWatchに送信します。
アラーム (Alarms): メトリクスが設定したしきい値を超えた場合にトリガーされる状態。アラームがトリガーされると、通知（SNS）や自動アクション（Auto Scaling、Lambda実行など）を実行できます。
ダッシュボード (Dashboards): 複数のメトリクスやアラームを視覚的にまとめて表示できるカスタム可能なインターフェース。システムの全体像を把握するのに役立ちます。
ログ (Logs): アプリケーションやAWSサービスから出力されるログデータを収集、監視、保存、分析する機能（CloudWatch Logs）。
イベント (Events): AWSリソースの変更や、スケジュールされたイベントなど、AWS環境で発生するイベントをキャプチャし、それに基づいてアクションをトリガーする機能（CloudWatch Events / EventBridge）。

3. ネットワーク関連の主要メトリクス

AWSの様々なサービスは、デフォルトでネットワーク関連のメトリクスをCloudWatchに送信しています。ここでは、特に重要なものをいくつか紹介します。

EC2インスタンス

NetworkIn: インスタンスが受信したネットワークトラフィックのバイト数。
NetworkOut: インスタンスが送信したネットワークトラフィックのバイト数。
NetworkPacketsIn: インスタンスが受信したネットワークパケットの数。
NetworkPacketsOut: インスタンスが送信したネットワークパケットの数。
- ポイント: これらのメトリクスは、インスタンスのネットワーク帯域幅の使用状況や、パケットロスなどの問題を特定するのに役立ちます。

Elastic Load Balancing (ELB) (ALB/NLB)

HealthyHostCount: ロードバランサーのターゲットグループ内の正常なターゲットの数。
UnHealthyHostCount: ロードバランサーのターゲットグループ内の異常なターゲットの数。
RequestCount: ロードバランサーが処理したリクエストの総数 (ALB)。
TargetConnectionErrorCount: ロードバランサーとターゲット間の接続エラーの数 (ALB/NLB)。
ConsumedLCUs: ALB/NLBが消費したLCU (Load Balancer Capacity Unit) の数。課金に直結します。
- ポイント: これらのメトリクスは、ロードバランサーの健全性、トラフィック量、バックエンドサーバーの応答状況を把握するために不可欠です。

NAT Gateway

BytesOutToDestination: NAT Gatewayから送信されたバイト数。
BytesInFromSource: NAT Gatewayが受信したバイト数。
PacketsDropCount: NAT Gatewayでドロップされたパケットの数。
ErrorPortAllocation: ポート割り当てエラーの数。
- ポイント: NAT Gatewayのボトルネックや、プライベートサブネットからのインターネットアクセスに関する問題を特定するのに役立ちます。

VPN (Site-to-Site VPN)

TunnelState: VPNトンネルのステータス（1=UP, 0=DOWN）。
TunnelDataIn/Out: VPNトンネルを介して送受信されたデータ量。
- ポイント: オンプレミスとのハイブリッド接続の健全性を監視するために重要です。

4. CloudWatchアラームの設定実践

それでは、Day 8でデプロイしたEC2インスタンス（MyWebServer01）のネットワークトラフィックを監視し、異常を検知した際に通知を受け取るアラームを設定してみましょう。今回は、NetworkOut メトリクスが一定量を超えた場合にアラームを発生させます。

4.1. SNSトピックの作成（通知先）

アラームがトリガーされた際に通知を受け取るためのSNS (Simple Notification Service) トピックを作成します。

AWSマネジメントコンソールで「SNS」サービスを開きます。
左側ナビゲーションペインから「トピック」をクリックし、「トピックの作成」ボタンをクリックします。
タイプ: 「スタンダード」を選択します。
名前: cloudwatch-network-alarm-topic
その他の設定はデフォルトのままで「トピックの作成」をクリックします。
作成したトピックの詳細画面で「サブスクリプションの作成」をクリックします。
- プロトコル: Eメール
- エンドポイント: あなたのメールアドレス を入力します。
「サブスクリプションの作成」をクリックします。
入力したメールアドレスに確認メールが届くので、メール内のリンクをクリックしてサブスクリプションを承認します。承認しないと通知が届きません。

4.2. CloudWatchアラームの作成

次に、EC2インスタンスのNetworkOutメトリクスを監視するアラームを作成します。

AWSマネジメントコンソールで「CloudWatch」サービスを開きます。
左側ナビゲーションペインから「アラーム」をクリックし、「アラームの作成」ボタンをクリックします。
「メトリクスを選択」をクリックします。
メトリクスの参照:
- 「EC2 Metrics」をクリックします。
- 「Per-Instance Metrics」をクリックします。
- MyWebServer01 のインスタンスIDを見つけ、その行にある「NetworkOut」メトリクスを選択します。
「メトリクスを選択」をクリックします。
条件の指定:
- 統計: 合計 (Sum)
- 期間: 5分 (5 minutes)
- しきい値:
  - しきい値の種類: 静的
  - NetworkOut が次の場合: 次よりも大きい (Greater)
  - しきい値: 例えば 10000000 (10MB) と入力します。これはテスト用なので、実際の環境に合わせて調整してください。
    - ポイント: 実際の環境では、通常のトラフィック量を把握した上で、異常と判断できる適切な値を設定します。
「次へ」をクリックします。
アクションの設定:
- 通知の送信: アラーム状態
- SNS トピックの選択: 「既存のSNSトピックを選択」を選択し、プルダウンから先ほど作成した cloudwatch-network-alarm-topic を選択します。
「次へ」をクリックします。
名前と説明の追加:
- アラーム名: EC2-MyWebServer01-HighNetworkOut
- アラームの説明: MyWebServer01の5分間の送信ネットワークトラフィックが10MBを超過
「次へ」をクリックします。
プレビューと作成: 設定内容を確認し、「アラームの作成」をクリックします。

アラームが作成されると、最初は「データ不足」または「OK」の状態になります。

4.3. アラームのテスト（オプション）

実際にアラームが動作するかテストしてみましょう。MyWebServer01 に大量のデータを送信させることで、NetworkOut メトリクスを意図的に上昇させることができます。

MyWebServer01 のパブリックIPアドレス（またはALBのDNS名）にWebブラウザからアクセスし、何度かページをリロードしてトラフィックを発生させます。
または、SSHでMyWebServer01に接続し、大きなファイルをダウンロードするなどの操作を行うことで、NetworkOutを増やすことができます。
```
# 例: 大きなファイルをダウンロード（注意: 実際にダウンロードされます）
# curl -O http://speedtest.tele2.net/100MB.zip
```
CloudWatchの「アラーム」画面で、作成したアラームのステータスが「アラーム状態」に変化するか確認します。
設定したメールアドレスにアラーム通知が届くことを確認します。

5. AI時代におけるネットワーク監視の考慮事項

AI/MLワークロードでは、ネットワークのパフォーマンスが学習や推論の速度に直結するため、より詳細で高度な監視が求められます。

GPUインスタンスのネットワークメトリクス: GPUインスタンス（例: Pシリーズ、Gシリーズ）のNetworkIn/Outメトリクスを監視し、学習データの転送がボトルネックになっていないかを確認します。特に、分散学習ではインスタンス間の通信量も重要です。
EFA (Elastic Fabric Adapter) の監視: EFAを使用している場合、通常のネットワークメトリクスに加えて、EFA固有のパフォーマンスメトリクス（例: efa_packets_in, efa_packets_out, efa_rx_drops, efa_tx_drops など）を監視し、ネットワークの健全性と効率性を確保します。
VPCエンドポイントの監視: S3やSageMakerなどのVPCエンドポイントを経由するデータ転送量やエラー率を監視し、データアクセス経路のパフォーマンスと信頼性を確認します。
Transit Gatewayのフローログとメトリクス: 複数のVPCやオンプレミスとの接続ハブとなるTransit Gatewayのトラフィック量、パケットドロップ、エラーなどをCloudWatchメトリクスやVPC Flow Logs（次回のDayで詳しく説明）で監視し、ネットワーク全体の健全性を把握します。
異常検知と機械学習: CloudWatchには、メトリクスの異常を自動的に検知する機械学習ベースの機能（Anomaly Detection）があります。これを活用することで、通常のトラフィックパターンから逸脱した異常を自動的に検知し、アラートを発報できます。これは、DDoS攻撃の兆候や、アプリケーションの予期せぬトラフィック増加などを早期に発見するのに非常に有効です。
カスタムメトリクス: アプリケーション固有のネットワークパフォーマンス指標（例: 推論APIの応答時間、データ転送の完了時間）をCloudWatchにカスタムメトリクスとして送信し、監視することも重要です。

本日のまとめと次へのステップ

今日は、AWSリソースの監視の中核をなす「Amazon CloudWatch」について学び、特にネットワーク関連のメトリクスとアラーム設定を実践しました。

CloudWatchは、メトリクス、アラーム、ダッシュボード、ログなどのコンポーネントで構成される。
EC2、ELB、NAT Gateway、VPNなど、様々なAWSサービスがネットワーク関連のメトリクスをCloudWatchに送信している。
CloudWatchアラームを設定することで、メトリクスが特定のしきい値を超えた場合に通知を受け取ったり、自動アクションを実行したりできる。

ネットワークの健全性を継続的に監視することは、安定したシステム運用に不可欠です。CloudWatchを使いこなすことで、問題の早期発見、パフォーマンス最適化、セキュリティ強化に大きく貢献できます。

明日のDay 16では、「VPC Flow Logs：ネットワークトラフィックの可視化と分析」と題して、VPC内のIPトラフィックに関する詳細な情報をキャプチャし、監視・分析するための「VPC Flow Logs」について学びます。CloudWatchメトリクスが「量」を見るのに対し、Flow Logsは「誰が、どこへ、何を、いつ」通信したかという「詳細」を見るための強力なツールです。

今日のCloudWatchアラーム設定、無事に通知を受け取ることができましたか？ネットワーク監視の第一歩を踏み出せたなら、ぜひ「いいね」👍で教えてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up