コンテナ監視の設計(AMP / Managed Grafana / CloudWatch Observability / Fargate の制約)

調査時点: 2026-07。料金・クォータは当時の値。

AMP と CloudWatch の役割分担#

AMP(Amazon Managed Service for Prometheus)はメトリクス(数値)しか扱えず、生ログは保存できない。そのためトラブル調査は 2 段階になる。

「どこで何が起きているか」を数値で検知する → AMP(PromQL(Prometheus のメトリクスを検索・集計するクエリ言語) で数千コンテナを高速集計・アラート)
「なぜ起きたか」をログのテキストで突き止める → CloudWatch Logs(Logs Insights で ERROR を検索)

監視対象	推奨	理由
アプリ・Kubernetes のメトリクス	AMP + Managed Grafana	PromQL で大量コンテナを集計
コンテナの生ログ	CloudWatch Logs	確実に保存でき、Logs Insights で検索
ALB / RDS などコンテナ外の AWS リソース	CloudWatch 標準	手軽で確実

AMP ワークスペースと AMG ワークスペース#

同じ「ワークスペース」でも役割は逆。

比較	AMP ワークスペース	AMG(Amazon Managed Grafana)ワークスペース
本質	時系列データの保管庫(DB)。S3 バケットに近い境界	可視化の画面(Web サーバー)。QuickSight に近い
発行される URL	`remote_write` などの API エンドポイント(ワークスペース ID 入り)	人間がブラウザで開くサインイン URL
主な設定	リテンション、アラート / レコーディングルール	データソース接続、ダッシュボード、プラグイン
認証	IAM(プログラム用)	IAM Identity Center / SAML 2.0(人間のログイン)
分割の目的	データ・請求の分離(prod / dev)	運用チーム・閲覧権限の分離

AMP は本番と開発でワークスペースを分ける。開発で誤って大量のメトリクスを出しても本番の監視と請求に影響しない。クロスアカウントの書き込みはワークスペースのリソースベースポリシーで許可できる。アクティブシリーズ上限は変更可能なクォータなので、具体値は都度確認する。

AMG のデータソース認証#

方式	評価
AWS SDK Default(ワークスペースの IAM ロール)	同一アカウント内の第一候補。ローテーション不要
IAM roles(AssumeRole)	複数アカウントを 1 画面で監視するとき。長期クレデンシャルを持たない
アクセスキー + シークレット	非推奨。漏洩リスクと手動ローテーション。OSS 版 Grafana からの互換用途のみ

トラブルシュートは「Access Denied / Unauthorized」なら IAM ポリシー・信頼関係(AssumeRole は借りる側のポリシーと貸す側の信頼関係の両方が要る)、「Network Timeout」なら VPC エンドポイント・SG・ルーティングを疑う。必要な読み取り権限の例は CloudWatch なら cloudwatch:GetMetricData / ListMetrics、AMP なら aps:QueryMetrics。

AMG のクロスアカウントとコスト#

クロスアカウント監視は、アクセス許可タイプ「サービス管理」+ Organizations 連携で自動プロビジョニングするか、「顧客管理」で各アカウントに AssumeRole 用ロールを手動で作る
ライセンス料は「1 ワークスペース × 1 アクティブユーザー」ごとに月額(当時 Editor 9 USD、Viewer 5 USD)。ダッシュボード数は無料。ワークスペースを 1 つに統合し、フォルダ権限でチームを分けるのが最も効くコスト削減。作成者以外は Viewer にする

収集エージェントの選定#

EKS ノード上にデプロイされる点は同じで、同階層の選択肢。基本はどれか 1 つ。

選択肢	扱えるデータ	特徴	選ぶ場面
CloudWatch Observability アドオン	メトリクス + ログ(裏で CloudWatch Agent + Fluent Bit)	EKS で有効化するだけ。AWS サポート対象	まず最初に試す。AWS 完結で手離れ重視
Grafana Alloy	メトリクス・ログ・トレース・プロファイル。OTel ベース	1 エージェントに集約。クラスタリングで HA	脱ロックイン、1 つの OSS で一元管理
Prometheus Agent	メトリクスのみ	TSDB を持たない超軽量モード。HA は苦手	ログ収集は既存(Fluent Bit 等)があり、AMP への転送だけ欲しい

アドオンすら不要なのは次の 4 パターン: Datadog / New Relic などの SaaS に全振り(二重収集になる)、マルチクラウド前提で kube-prometheus-stack を自前運用、アプリから OTel SDK で直接送るエージェントレス、ALB ログと EC2 の標準メトリクスで足りる使い捨て環境。

CloudWatch Agent と OpenTelemetry(ADOT)#

比較	CloudWatch Agent	OTel / ADOT
思想	AWS 専用に最適化	ベンダー非依存の標準
データ	メトリクス、ログ(トレース不可)	メトリクス、ログ、トレース
送信先	CloudWatch のみ	CloudWatch、AMP、Datadog など自由
計装	StatsD / collectd でアプリの数値も吸える(手動計装)	自動計装が強い

アプリ監視自体は CloudWatch Agent でも可能。OTel を選ぶ差はトレース対応・自動計装・脱ロックインの 3 点。

AMP へのメトリクス送信経路#

Prometheus をエージェントモード + DaemonSet(Kubernetes の各ノードに Pod を 1 つずつ配置する仕組み) で動かし、remote_write で AMP へ直送する。DaemonSet は全ワーカーノードに 1 Pod ずつ常駐させる仕組みで、ノードが増えても監視漏れが起きない
オンプレや他社クラウドからは Public エンドポイントへ remote_write
プライベートサブネットの EKS からは VPC エンドポイント(PrivateLink)経由にする。NAT Gateway 経由だとデータ処理料金が乗り、経路もインターネットに出る

EKS Fargate の制約#

Fargate のホスト OS は AWS 管理のブラックボックスで、Pod ごとに専用の極小 VM が払い出される。

コンポーネント	可否	理由
node-exporter	不可	DaemonSet が配置できない(ノードを複数 Pod で共有しない)
cAdvisor	不可	kubelet のエンドポイントが非公開
kube-state-metrics	可	API サーバーに問い合わせる Deployment として動く

したがって Fargate のインフラ監視(CPU / メモリ)は CloudWatch Container Insights に委ねる。Prometheus / AMP に戻すのは、アプリ内部のカスタムメトリクスを PromQL / Grafana で一元化したい要件が出たときだけ。

紛らわしい Insights 系の名称#

名称	対象	実体	Fargate
CloudWatch Container Insights	EKS / ECS / Kubernetes	コンテナ監視機能の総称	対応
Container Insights	主に ECS	ECS クラスター設定のトグル名	対応
CloudWatch Lambda Insights	Lambda	Lambda レイヤーとして付与	対応
Amazon CloudWatch Observability	EKS	EKS 専用の管理アドオン(DaemonSet 使用)	不可

CloudWatch Observability アドオンは EKS Fargate(DaemonSet 不可)、ECS Fargate(クラスターアドオンの概念がない)、Lambda のいずれでも使えない。

プル型とプッシュ型#

コンテナは固定 IP を持たないが、Prometheus は Kubernetes API に「今どこで何台動いているか」を問い合わせる Service Discovery でプルを成立させる
プッシュ型が必須になるのは、短命なサーバーレス / バッチ(取りに行く前に消える)、閉域網(インバウンドを開けない)、大規模分散 IoT(IP を把握できない)の 3 場面
Lambda はプル不可。どうしても Prometheus に乗せるなら Pushgateway を中継させる。EKS Fargate は API サーバー経由のダイレクトスクレイプで技術的に可能だが運用負荷が高い

PromQL#

メトリクス名 + ラベルで系列を特定し、rate / sum で集約する時系列専用言語。SQL が表の JOIN や業務集計を得意とするのに対し、PromQL は「過去 5 分のエラー率の変化」のような計算に向く。

1
sum(rate(http_requests_total{app="frontend"}[5m]))

時間指定は 3 通り: @ <Unix 秒>(絶対)、offset 1d(相対)、Grafana のタイムピッカー(実務の本命。クエリには時間を書かない)。

CloudWatch は PromQL と OTel メトリクスにネイティブ対応し、Query Studio での実行と PromQL ベースのアラームが使える。提供時期の正確な日付は裏取りが必要。

可視化ツールの選定(Grafana / Superset / QuickSight)#

比較	Grafana	Apache Superset	Amazon QuickSight
用途	システム監視(秒〜分のリアルタイム)	BI(バッチ更新の業務分析)	BI(マネージド)
得意なデータ	時系列、ログ、トレース	RDB / DWH	Athena / Redshift など AWS 内データ
運用	セルフホストか AMG	自前(EC2 / EKS)	不要
コスト	AMG はユーザー課金	ライセンス無料。サーバー代のみ	ユーザー数 / セッション課金

Superset は Grafana の競合ではなく QuickSight の OSS 版にあたる。閲覧者が数百〜数千人なら Superset、少人数で運用を持ちたくないなら QuickSight が安い。

低頻度・小規模なアクセスログ統計#

本格的な BI は過剰。固定費 0 に近い順に:

Logs Insights のクエリ(stats count_distinct(client_ip) by bin(1w) など)を CloudWatch ダッシュボードにピン留め
Contributor Insights でトップ N ランキングを常時表示
ログが S3 なら Athena で集計し、EventBridge + Lambda で週 1 回 Slack に投稿、またはグラフが要るなら QuickSight を 1 ユーザー分だけ契約

オンプレの余剰リソースで Superset を動かし、AWS からは集計後の小さな CSV だけ落とす構成も、データ転送の無料枠(当時 100GB/月)に収まるなら追加費用ゼロで成立する。

更新履歴#

2026-07-18: 初版(ローカル調査ノート)
2026-10-17: Wiki へ移植、概念ページとして再構成