[アップデート]Amazon Managed Service for Prometheus コレクターがクロスアカウント取り込みをサポートしました

枡川健太郎
2025.03.02
先日 Amazon Managed Service for Prometheus(以降 AMP) のマネージドコレクターがクロスアカウントでのメトリクス取り込みに対応しました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/01/amazon-managed-service-prometheus-collector-cross-account-ingestion/
元々、自前で Prometheus エージェントをインストールするのであれば、別アカウントにある AMP ワークスペースにメトリクスを書き込むことができました。
https://aws.amazon.com/jp/blogs/opensource/setting-up-cross-account-ingestion-into-amazon-managed-service-for-prometheus/
一方で、フルマネージドかつエージェントレスの Prometheus マネージドコレクターを設定した場合は同じアカウントにあるワークスペースしか選択することができませんでした。
https://dev.classmethod.jp/articles/prometheus-managed-collector/
今回、マネージドコレクターを利用しても、クロスアカウントでメトリクスを書き込むことができるようになりました。

これによって、Prometheus の運用負荷を下げつつ、モニタリング専用のアカウントを利用するなど高度な権限分離を可能になりました。
 やってみるアカウント A に EKS クラスターが配置しつつ、運用専用のアカウントとしてアカウント B を作成し、そちらに AMP と Amazon Managed Grafana(以降 AMG) を作成します。
アカウント A に AMP マネージドコレクターを作成し、クロスアカウントでアカウント B の AMP にメトリクスを書き込みます。

アカウント B に配置した AMG から EKS クラスター内のメトリクスを確認する所までやってみます。

手順は下記ページに従います。
https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create
EKS は事前に用意されている前提で始めます。

クロスアカウント取り込み関係なく、下記条件が存在するので気をつけて下さい。
Amazon EKS クラスターには、プライベートアクセスを含むようにクラスターエンドポイントのアクセスコントロールが設定されている必要があります。プライベートとパブリックを含めることができますが、プライベートを含める必要があります。

Amazon EKS クラスター VPC が存在する Amazon では、 DNS が有効になっている必要があります。

https://docs.aws.amazon.com/ja_jp/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create
特にプライベートアクセスが無効になっているかどうかは注意が必要です。
それでは、マネージドコレクター周りの設定に移ります。

まず、アカウント B に AMP ワークスペースを作成します。
次に、アカウント A に IAM ロールを作成します。

信頼関係を下記のように設定します。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "scraper.aps.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "<scraper_ARN>"
        },
        "StringEquals": {
          "AWS:SourceAccount": "<source_account_id>"
        }
      }
    }
  ]
}
ただし、この状態ではマネージドコレクターの ARN がわからないので aws:SourceArn の条件を入れようがありません。

私は、最初は指定せずにマネージドコレクター作成後に追記する方針にしました。

AssumeRole する権限のみを付与しておきます。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::xxxxxxxxxxxx:role/Target"
    }
  ]
}
アカウント B にも IAM ロールを作成します。

こちらは信頼関係を下記のように設定します。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxxxx:role/Source"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<scraper_ARN>"
        }
      }
    }
  ]
}
マネージドコレクターの ARN を後から入れるのは、こちらも同じです。

権限は AmazonPrometheusRemoteWriteAccess を付与します。
続いて、マネージドコレクターを作成します。
aws amp create-scraper \
  --source eksConfiguration="{clusterArn=$EKS_CLUSTER_ARN,subnetIds=[$SUBNET_ID]}" \
  --scrape-configuration configurationBlob=$(cat default.yaml | base64) \
  --destination ampConfiguration="{workspaceArn=$AMP_WORKSPACE_ARN}" \
  --role-configuration '{"sourceRoleArn":"$SOURCE_ROLE_ARN", "targetRoleArn":"$TARGET_ROLE_ARN"}'
作成には 20 分程度かかったので、気長に待ちます。

上手くいかなければ、ソースアカウント (アカウント A) の CloudTrail に記録されている CreateScraper アクションや AssumeRole アクションに理由が書いてあったりします。

下記はサブネット ID を上手く渡せてなかった場合のエラーです。
    "responseElements": {
        "reason": "Validation error",
        "Access-Control-Expose-Headers": "x-amzn-errortype,x-amzn-requestid,x-amzn-trace-id,x-amzn-errormessage,x-amz-apigw-id,date",
        "message": "Invalid source.eksConfiguration.subnetIds: Member must satisfy constraint: [Member must have length less than or equal to 255, Member must have length greater than or equal to 0, Member must satisfy regular expression pattern: subnet-[0-9a-z]+]",
        "fieldList": [
            {
                "message": "Member must satisfy constraint: [Member must have length less than or equal to 255, Member must have length greater than or equal to 0, Member must satisfy regular expression pattern: subnet-[0-9a-z]+]",
                "name": "source.eksConfiguration.subnetIds"
            }
        ]
    },
マネージドコレクターは VPC Lambda を作成して EKS のコントロールプレーンにプライベートアクセスしてメトリクス情報を取得するので、セキュリティグループの設定なども重要になります。

また、Kubernetes 内の権限設定で弾かれている可能性もあるので、監査ログも確認してみると良いです。

作成できると、ソースアカウント (アカウント A) 側で、マネージドコレクターのステータスを確認できます。
% aws amp list-scrapers
{
    "scrapers": [
        {
            "arn": "arn:aws:aps:ap-northeast-1:xxxxxxxxxxxx:scraper/s-bb6fa120-d479-4778-8291-ceb2a91c4719",
            "createdAt": "2025-02-08T12:55:05.794000+09:00",
            "destination": {
                "ampConfiguration": {
                    "workspaceArn": "arn:aws:aps:ap-northeast-1:xxxxxxxxxxxx:workspace/ws-52675984-5332-4fbf-bc39-80111a9b175c"
                }
            },
            "lastModifiedAt": "2025-02-08T13:11:40.067000+09:00",
            "roleArn": "arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/scraper.aps.amazonaws.com/AWSServiceRoleForAmazonPrometheusScraper_6c5dd3c2-29a7-4",
            "roleConfiguration": {
                "sourceRoleArn": "arn:aws:iam::xxxxxxxxxxxx:role/Source",
                "targetRoleArn": "arn:aws:iam::xxxxxxxxxxxx:role/Target"
            },
            "scraperId": "s-bb6fa120-d479-4778-8291-ceb2a91c4719",
            "source": {
                "eksConfiguration": {
                    "clusterArn": "arn:aws:eks:ap-northeast-1:xxxxxxxxxxxx:cluster/test-cluster",
                    "securityGroupIds": [
                        "sg-02a0b884c2f264939",
                        "sg-0bc3996f05e545c6c"
                    ],
                    "subnetIds": [
                        "subnet-09181196696186fc9",
                        "subnet-011609187505c89a3"
                    ]
                }
            },
            "status": {
                "statusCode": "ACTIVE"
            },
            "tags": {}
        }
    ]
}
statusCode が ACTIVE になっているので、無事設定できました！
 アクセスエントリを利用した権限付与について以前は下記 Kubernetes リソースを作成して、aws-auth 側でも権限追加が必要でした。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aps-collector-role
rules:
  - apiGroups: [""]
    resources: ["nodes", "nodes/proxy", "nodes/metrics", "services", "endpoints", "pods", "ingresses", "configmaps"]
    verbs: ["describe", "get", "list", "watch"]
  - apiGroups: ["extensions", "networking.k8s.io"]
    resources: ["ingresses/status", "ingresses"]
    verbs: ["describe", "get", "list", "watch"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get"]
  - apiGroups: ["metrics.eks.amazonaws.com"]
    resources: ["kcm/metrics", "ksh/metrics"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: aps-collector-user-role-binding
subjects:
- kind: User
  name: aps-collector-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: aps-collector-role
  apiGroup: rbac.authorization.k8s.io
現在、アクセスエントリが有効になっている EKS クラスターに対してスクレイパーを作成すると、アクセスエントリにて自動で権限が追加されるようになっております。

この辺りの設定も楽になってとても良いですね！
 AMG で見てみるターゲットアカウントで Kubernetes cluster monitoring (via Prometheus) を利用して可視化してみました。

無事別アカウントのクラスター内の情報が取得できています。
 まとめAMP のマネージドコレクターを使いつつ、クロスアカウントで AMP に集約する方法を試してみました。

マネージドサービスを使っていても、カスタマイズ性も高まったという所で嬉しいアップデートですね！