監視サービスの全体像
AWS の監視・可観測性（Observability）サービスは大きく4つの役割に分かれる。
| 役割 | AWSサービス | オンプレ対応 |
|---|---|---|
| メトリクス監視・アラート | CloudWatch Metrics + Alarm | Zabbix / Nagios / Datadog |
| ログ集約・検索 | CloudWatch Logs | Fluentd + Elasticsearch / Splunk |
| 分散トレーシング | AWS X-Ray | Jaeger / Zipkin / Dynatrace |
| 大規模ログ分析・可視化 | OpenSearch Service（+ Dashboards） | Elasticsearch + Kibana |
判断フロー
CloudWatch Metrics — メトリクス監視
CloudWatch Metrics は AWS リソースのメトリクスを自動収集・保存し、Alarm（閾値アラート） で通知する。 EC2・RDS・ALB などの AWS マネージドサービスのメトリクスはデフォルトで自動収集される。
主なメトリクス収集対象：
- EC2：CPU 使用率・ネットワーク I/O・ディスク I/O（5分間隔がデフォルト。詳細モニタリングで1分間隔）
- RDS / Aurora：DB コネクション数・クエリレイテンシ・バッファヒット率
- ALB / NLB：リクエスト数・4xx/5xx エラー率・レイテンシ
- Lambda：呼び出し数・エラー数・タイムアウト・コンカレンシー
- カスタムメトリクス：アプリの独自メトリクスを PutMetricData API で送信
⚠️ EC2 のメモリ使用率はデフォルトで取れない
EC2 の CPU / ネットワーク / ディスク I/O は自動収集されるが、メモリ使用率・ディスク空き容量はデフォルトでは取れない。CloudWatch Agent をインストールすることでこれらのメトリクスを収集できる。オンプレから移行する際、メモリ監視が抜ける落とし穴として要注意だ。
Alarm の設定ポイント：
- アラーム → SNS トピック → Email / Slack（Lambda 経由）/ PagerDuty で通知
- アラーム → Auto Scaling Policy で自動スケールアウト/インのトリガーにも使える
- Composite Alarm で複数条件の AND/OR 組み合わせアラームを定義できる
CloudWatch Logs — ログ集約・検索
CloudWatch Logs は AWS サービスおよびアプリのログを集約・保存・検索するサービスだ。 EC2 / ECS / Lambda / RDS などから CloudWatch Agent や SDK でログを送信する。
Logs Insights：
CloudWatch Logs Insights は SQL ライクなクエリ言語でログを分析できる機能だ。
「エラーログの件数を時系列で集計」「特定のリクエスト ID のログを追跡」などが GUI 上で実現できる。
💡 ログの保持期間を設定する
CloudWatch Logs はデフォルトでログを永続保存するが、それが原因でコストが膨らむケースが多い。保持期間（1日〜10年）を必ず設定しよう。長期保管が必要なログは S3 にエクスポートし、Glacier へのライフサイクルポリシーで低コスト保管する。
X-Ray — 分散トレーシング
AWS X-Ray はマイクロサービス・コンテナ・Lambda などの サービス間リクエストをエンドツーエンドで追跡する分散トレーシングサービスだ。 「API のどのコンポーネントでレイテンシが発生しているか」「エラーの連鎖がどこから来ているか」を可視化する。
X-Ray を選ぶケース：
- マイクロサービス構成で、障害発生時にどのサービスが原因か特定できない
- Lambda のコールドスタートや DB クエリのボトルネックを計測したい
- API Gateway → Lambda → RDS の全レイテンシを一覧で確認したい
X-Ray SDK をアプリに組み込み、AWS SDK の呼び出しを自動インストルメントすることで、コードの変更量を最小化して導入できる。
OpenSearch Service — 大規模ログ分析
Amazon OpenSearch Service（旧 Amazon Elasticsearch Service）は Elasticsearch / OpenSearch 互換のマネージドサービスだ。 CloudWatch Logs より複雑なクエリ・全文検索・可視化（OpenSearch Dashboards / 旧Kibana）が必要な場合に選択する。
OpenSearch Service を選ぶケース：
- 秒間数万件のログを全文検索したい
- 多次元のダッシュボード（地図・折れ線・ヒートマップ等）を構築したい
- オンプレで Elasticsearch + Kibana を使っていて移行先を探している
- セキュリティログ分析（SIEM 的な用途）
⚠️ OpenSearch Service はコストに注意
OpenSearch Service はデータノードを常時起動するコスト構造のため、CloudWatch Logs より高コストになりやすい。「Logs Insights で十分か」を先に検討しよう。本当に必要なのは大規模ログ分析が必要なチームだ。
オンプレ監視ツールとの対応
| オンプレ | AWS 移行先 | 補足 |
|---|---|---|
| Zabbix / Nagios（死活監視・メトリクス） | CloudWatch Metrics + Alarm | CloudWatch Agent で独自メトリクスも収集 |
| Fluentd / Logstash（ログ転送） | CloudWatch Agent / Fluent Bit（ECS） | ECS は Fluent Bit が AWS 統合でサポート |
| Elasticsearch + Kibana（ログ分析） | OpenSearch Service + Dashboards | API 互換あり（バージョンによって差異あり） |
| Datadog / Dynatrace（APM） | X-Ray + CloudWatch（または継続利用） | Datadog は AWS 統合エージェントでそのまま使える場合も多い |
💡 サードパーティ監視ツールとの共存
Datadog / Dynatrace / New Relic などを既に使っている場合は、無理に AWS ネイティブに置き換えずそのまま継続するケースも多い。これらのツールは AWS との統合が充実しており、EC2 / ECS / Lambda のメトリクスをエージェントや API 経由で収集できる。移行コスト（学習・設定移行）と監視品質のバランスで判断しよう。
実務での設計パターン
パターン1：標準的な Web システムの監視構成
- CloudWatch Metrics：EC2 / ALB / RDS のリソース監視
- CloudWatch Agent：EC2 のメモリ・ディスク使用率を追加収集
- CloudWatch Alarm → SNS → Slack（Lambda 経由）でアラート通知
- CloudWatch Logs：アプリログ・アクセスログを集約
- CloudWatch Dashboard：主要メトリクスを1画面で可視化
パターン2：マイクロサービスの可観測性構成
- 上記 + X-Ray でサービス間トレーシング
- 大量ログ分析が必要な場合のみ OpenSearch Service を追加
✅ 次の章では…
PART 08 ではこのシリーズのまとめとして、各レイヤーの判断フローを1枚の早見表に集約する。移行設計の場で参照できる形に整理する。