Amazon Managed Service for Prometheus

解決する課題

オープンソースの Prometheus は強力ですが、自前で運用すると次の負担が生じます。

• サーバーのスケーリングと冗長化を自分で設計しなければならない
• 長期保存のためにストレージ容量を確保・管理し続ける必要がある
• 監視基盤そのものが落ちると監視できないという単一障害点になりがち

Amazon Managed Service for Prometheus は、これらの取り込み・保存・クエリの基盤を AWS が運用し、利用者は Prometheus 互換の使い勝手だけを受け取れるようにします。

主要概念と用語

• ワークスペース: メトリクスを取り込み・保存・クエリする論理的な隔離単位。テナント分離の基本
• PromQL: Prometheus のクエリ言語。マネージド側でもそのまま使える
• リモートライト（remote write）: Prometheus サーバーやエージェントが収集したメトリクスをワークスペースへ送り込む仕組み
• スクレイプ: 監視対象のメトリクスエンドポイントを定期的に取得すること
• AWS マネージドコレクター: AWS 側が運用するスクレイパー。エージェントの運用負担を減らせる
• ルールとアラート: 記録ルール（recording rules）とアラートルール（alerting rules）で集計やしきい値判定を行う
• アラートマネージャー: アラートの集約・抑制・通知ルーティングを担う

仕様・制限・クォータ

• メトリクスの取り込みは主にリモートライト経由で行う。互換性のため Prometheus 標準の API を踏襲する
• クエリは PromQL と互換 API で行い、既存の Prometheus 向けツールと連携しやすい
• ワークスペース単位で取り込みレート、アクティブ系列数、クエリ同時実行などにサービスクォータがあり、多くは引き上げ申請が可能
• メトリクスには保持期間が設定され、期間を過ぎたデータは自動的に削除される
• リージョン単位のサービスであり、可用性のためにマネージド基盤側で冗長化されている

内部の仕組み

利用者はワークスペースを作成し、メトリクスの送信元（Prometheus エージェントや AWS マネージドコレクター）からリモートライトでデータを送ります。取り込まれた時系列メトリクスはマネージド基盤に保存され、PromQL でクエリできます。

• 取り込み・保存・クエリの各レイヤは AWS がスケールさせるため、利用者はサーバー台数を意識しない
• 記録ルールで事前集計し、アラートルールでしきい値を評価する。発火したアラートはアラートマネージャーが通知先へルーティングする
• 可視化は基盤に内蔵されないため、一般に Grafana（Amazon Managed Grafana を含む）をクエリ用フロントエンドとして組み合わせる

設計パターン / ベストプラクティス

• EKS との組み合わせ: Kubernetes クラスタのメトリクスを AWS マネージドコレクターでスクレイプし、運用負担を最小化する
• 可視化は Grafana に分離: メトリクス基盤とダッシュボードの役割を分け、Grafana 側で複数データソースを統合する
• 高カーディナリティを抑える: ラベルの組み合わせ爆発はコストと性能に直結するため、不要なラベルを付けない
• 記録ルールで前計算: 頻繁に使う重い集計は記録ルール化し、クエリ時の負荷を下げる

運用・監視

• 取り込みが止まる場合は、送信側のリモートライト設定・到達性・IAM 権限を確認する
• 系列数や取り込みレートがクォータ上限に達していないかを点検する
• アラートが鳴らない場合は、ルールの評価とアラートマネージャーのルーティング設定を確認する
• 基盤側の使用状況メトリクスは CloudWatch でも確認でき、容量計画に活用できる

コスト

• 主に取り込んだメトリクスのサンプル量、保存しているデータ量（系列と保持期間）、実行したクエリ量に応じて課金される
• 高カーディナリティや過剰な取り込み間隔はコストを押し上げるため、ラベル設計とスクレイプ間隔の見直しが効く
• 不要に長い保持期間を避け、必要な粒度だけを保持する

セキュリティ

• アクセス制御は IAM で行い、リモートライトやクエリの呼び出しには SigV4 署名による認証が必要
• 保存データは暗号化され、鍵管理に KMS を利用できる
• **VPC エンドポイント（PrivateLink）**を使えば、インターネットを経由せずプライベートに接続できる
• 操作の監査証跡は CloudTrail に記録される

Well-Architected の観点

• 運用上の優秀性: 監視基盤の運用を AWS に委譲し、可観測性の維持に集中できる
• 信頼性: マネージド側の冗長化により、監視基盤が単一障害点になりにくい
• セキュリティ: IAM 認証・暗号化・PrivateLink で安全に取り込み・クエリできる
• コスト最適化: カーディナリティと保持期間の管理が継続的なコスト最適化の鍵になる

試験で問われるポイント

関連サービス・比較

同じ監視領域の CloudWatch とよく比較されます。

ハンズオン / CLI例

# ワークスペースを作成
aws amp create-workspace --alias demo-monitoring

# ワークスペースの一覧と状態を確認
aws amp list-workspaces \
  --query "workspaces[].{ID:workspaceId,Alias:alias,Status:status.statusCode}"

# 特定ワークスペースの詳細（リモートライト/クエリ用のエンドポイントを含む）
aws amp describe-workspace --workspace-id ws-0123456789abcdef