Linden Consulting.
DevOps

CloudWatch PutMetricData AccessDenied: Monitoring-Berechtigungslücken beheben

2026-05-24 · 8 Min. Lesezeit

Ihr Monitoring ist gerade verstummt. Das Dashboard für Custom Metrics ist leer, die Alarme feuern nicht, und irgendwo in Ihren Anwendungslogs finden Sie dies:

An error occurred (AccessDenied) when calling the PutMetricData operation:
User: arn:aws:sts::123456789012:assumed-role/my-app-role/i-0abc123def456
is not authorized to perform: cloudwatch:PutMetricData on resource: *

Oder aus einer Lambda-Funktion:

[ERROR] ClientError: An error occurred (AccessDenied) when calling the
PutLogEvents operation: User: arn:aws:sts::123456789012:assumed-role/
my-lambda-role/my-function is not authorized to perform:
logs:PutLogEvents on resource: arn:aws:logs:us-east-1:123456789012:
log-group:/aws/lambda/my-function:log-stream:2026/05/24/[$LATEST]abc123

Wenn CloudWatch Ihre Metriken oder Logs ablehnt, wird Ihr gesamter Observability-Stack blind. Sie können keine Ausfälle erkennen, keine Performance-Probleme untersuchen, und Ihre Alarme hören auf zu funktionieren. Ich habe erlebt, wie dies dazu führte, dass Produktions-Incidents stundenlang länger dauerten als nötig, weil das Team keine Metriken hatte, um das ursprüngliche Problem zu diagnostizieren.

So beheben Sie systematisch jede CloudWatch-Berechtigungslücke.

Schritt 1: Identifizieren, was abgelehnt wird

Die Fehlermeldung verrät drei Dinge: den aufrufenden Principal, die verweigerte Aktion und die Ziel-Ressource. Analysieren Sie diese sorgfältig, denn jeder Punkt deutet auf eine andere Lösung hin.

Bestätigen Sie zunächst die aufrufende Identität:

aws sts get-caller-identity

{
    "UserId": "AROAEXAMPLEID:i-0abc123def456",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/my-app-role/i-0abc123def456"
}

Prüfen Sie dann, welche Policies an diese Rolle angehängt sind:

aws iam list-attached-role-policies --role-name my-app-role
aws iam list-role-policies --role-name my-app-role

Inspizieren Sie jede Policy, um die CloudWatch-Berechtigungen zu finden:

# Für verwaltete Policies
aws iam get-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/my-monitoring-policy \
  --version-id v1 \
  --query 'PolicyVersion.Document'

# Für Inline-Policies
aws iam get-role-policy \
  --role-name my-app-role \
  --policy-name MonitoringPermissions

Ursache 1: Fehlende cloudwatch:PutMetricData-Berechtigung

Die naheliegendste Ursache. Die IAM-Rolle hat cloudwatch:PutMetricData in keiner ihrer Policies. Dies passiert, wenn eine Rolle für einen bestimmten Zweck erstellt wurde und Monitoring später hinzugefügt wurde, ohne die Berechtigungen zu aktualisieren.

Die Mindest-Policy für das Veröffentlichen von Custom Metrics:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData"
      ],
      "Resource": "*"
    }
  ]
}

Beachten Sie, dass cloudwatch:PutMetricData keine Berechtigungen auf Ressourcenebene unterstützt — die Resource muss "*" sein. Sie können jedoch einschränken, in welche Namespaces eine Rolle publizieren darf, indem Sie den cloudwatch:namespace-Condition-Key verwenden:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyApp/Production"
        }
      }
    }
  ]
}

Dies ist tatsächlich eine Best Practice — es verhindert, dass eine Rolle versehentlich Metriken in den falschen Namespace publiziert oder Metriken einer anderen Anwendung überschreibt.

Ursache 2: Namespace-Einschränkung stimmt nicht überein

Wenn Ihre Policy die cloudwatch:namespace-Bedingung verwendet, muss der Namespace in Ihrem PutMetricData-Aufruf exakt übereinstimmen. Dies ist case-sensitive.

Testen Sie mit der CLI:

aws cloudwatch put-metric-data \
  --namespace "MyApp/Production" \
  --metric-name "RequestCount" \
  --value 1 \
  --unit Count

Wenn die Policy MyApp/Production erlaubt, aber Ihre Anwendung Metriken an myapp/production sendet, wird der Aufruf abgelehnt. Überprüfen Sie den exakten Namespace-String in Ihrem Anwendungscode.

Eine häufige Variante dieses Problems tritt auf, wenn Teams umgebungsbasierte Namespaces wie MyApp/Staging und MyApp/Production verwenden, die IAM-Policy aber nur einen davon erlaubt. Verwenden Sie eine Wildcard-Bedingung für Flexibilität:

{
  "Condition": {
    "StringLike": {
      "cloudwatch:namespace": "MyApp/*"
    }
  }
}

Ursache 3: CloudWatch-Logs-Berechtigungen fehlen

CloudWatch Logs verwendet einen vollständig separaten Satz von IAM-Aktionen im Vergleich zu CloudWatch Metrics. Wenn Ihre Anwendung sowohl Metriken als auch Logs schreibt, benötigen Sie beide Berechtigungssätze.

Der vollständige Satz an CloudWatch-Logs-Berechtigungen für eine Anwendung:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:us-east-1:123456789012:log-group:/myapp/*",
        "arn:aws:logs:us-east-1:123456789012:log-group:/myapp/*:log-stream:*"
      ]
    }
  ]
}

Anders als PutMetricData unterstützen CloudWatch-Logs-Aktionen Berechtigungen auf Ressourcenebene. Sie können den Zugriff auf bestimmte Log-Gruppen per ARN-Muster einschränken. Die Ressource muss sowohl Log-Group- als auch Log-Stream-ARNs enthalten.

Ein häufiger Fehler ist, den Log-Group-ARN einzuschließen, aber den Log-Stream-ARN zu vergessen:

"Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/myapp/*"

Dies erlaubt CreateLogGroup und DescribeLogGroups, aber verweigert PutLogEvents, da diese Aktion auf einen Log Stream abzielt, nicht auf eine Log Group. Sie benötigen das *:log-stream:*-Suffix.

Ursache 4: Lambda-Ausführungsrolle ohne CloudWatch-Berechtigungen

Lambda-Funktionen erhalten automatisch CloudWatch-Logs-Berechtigungen durch die verwaltete Policy AWSLambdaBasicExecutionRole. Aber wenn Ihre Funktion Custom Metrics publiziert, benötigen Sie zusätzliche Berechtigungen.

Prüfen Sie, was Ihre Lambda-Rolle hat:

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'Role'

aws iam list-attached-role-policies \
  --role-name my-lambda-role

Wenn Sie AWSLambdaBasicExecutionRole sehen, aber nicht CloudWatchFullAccess oder eine benutzerdefinierte Policy, kann die Funktion Logs schreiben, aber keine Metriken.

Die AWSLambdaBasicExecutionRole enthält nur:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Um Custom-Metric-Berechtigungen hinzuzufügen, fügen Sie eine zusätzliche Policy an:

aws iam put-role-policy \
  --role-name my-lambda-role \
  --policy-name CloudWatchMetrics \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "cloudwatch:PutMetricData",
          "cloudwatch:GetMetricData",
          "cloudwatch:ListMetrics"
        ],
        "Resource": "*"
      }
    ]
  }'

Ursache 5: EC2-Instance-Profil ohne Monitoring-Berechtigungen

EC2-Instanzen verwenden Instance Profiles für den Zugriff auf AWS-Services. Wenn der CloudWatch Agent installiert ist, aber das Instance Profile die richtigen Berechtigungen nicht hat, scheitern Metriken und Logs stillschweigend oder mit AccessDenied-Fehlern im Agent-Log.

Instance Profile prüfen:

# Instance Profile von der Instanz abrufen
aws ec2 describe-instances \
  --instance-ids i-0abc123def456 \
  --query 'Reservations[0].Instances[0].IamInstanceProfile.Arn'

# Rollen im Instance Profile auflisten
aws iam get-instance-profile \
  --instance-profile-name my-instance-profile \
  --query 'InstanceProfile.Roles[*].RoleName'

Der CloudWatch Agent benötigt diese Mindest-Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams",
        "ec2:DescribeTags",
        "ec2:DescribeVolumes",
        "ec2:DescribeInstances",
        "ssm:GetParameter"
      ],
      "Resource": "*"
    }
  ]
}

AWS bietet die verwaltete Policy CloudWatchAgentServerPolicy für diesen Zweck:

aws iam attach-role-policy \
  --role-name my-ec2-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Prüfen Sie das CloudWatch-Agent-Log auf spezifische Fehler:

# Auf Amazon Linux / RHEL
cat /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log | grep -i "error\|denied\|unauthorized"

Ursache 6: VPC-Endpoints für CloudWatch fehlen

Wenn Ihre Anwendung in einem privaten Subnetz ohne Internetzugang läuft, benötigt sie VPC-Endpoints, um CloudWatch und CloudWatch Logs zu erreichen. Ohne diese Endpoints laufen API-Aufrufe in einen Timeout, anstatt AccessDenied zurückzugeben — aber das Symptom sieht gleich aus: fehlende Metriken.

Vorhandene VPC-Endpoints prüfen:

aws ec2 describe-vpc-endpoints \
  --filters "Name=vpc-id,Values=vpc-abc123" \
  --query 'VpcEndpoints[*].{
    ServiceName: ServiceName,
    State: State,
    VpcEndpointType: VpcEndpointType
  }'

Sie benötigen Endpoints für beide Services:

# CloudWatch-Metrics-Endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc123 \
  --service-name com.amazonaws.us-east-1.monitoring \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-abc123 subnet-def456 \
  --security-group-ids sg-abc123

# CloudWatch-Logs-Endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc123 \
  --service-name com.amazonaws.us-east-1.logs \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-abc123 subnet-def456 \
  --security-group-ids sg-abc123

Die Security Group am VPC-Endpoint muss eingehende HTTPS-Verbindungen (Port 443) von der Security Group Ihrer Anwendung erlauben.

Ursache 7: Cross-Account-Observability nicht konfiguriert

Wenn Sie Metriken von einem Konto an ein zentrales Monitoring-Konto senden möchten, benötigen Sie CloudWatch Cross-Account Observability. Ohne diese Konfiguration schlagen PutMetricData-Aufrufe an den Namespace eines anderen Kontos fehl.

Richten Sie das Monitoring-Konto als Sink ein:

# Im Monitoring-Konto
aws oam create-sink \
  --name central-monitoring \
  --tags Key=Environment,Value=Production

Dann verknüpfen Sie Quellkonten:

# In jedem Quellkonto
aws oam create-link \
  --label-template '$AccountName' \
  --resource-types "AWS::CloudWatch::Metric" "AWS::Logs::LogGroup" \
  --sink-identifier arn:aws:oam:us-east-1:999999999999:sink/sink-id

Ursache 8: Ressourcenbasierte Policy auf Log-Gruppen

CloudWatch Logs unterstützt ressourcenbasierte Policies auf Log-Gruppen. Wenn eine Log-Gruppe eine restriktive Policy hat, kann selbst eine Rolle mit korrekten IAM-Berechtigungen abgelehnt werden.

Ressourcen-Policy prüfen:

aws logs describe-resource-policies

# Eine bestimmte Log-Gruppe auf Subscription Filter und Policies prüfen
aws logs describe-log-groups \
  --log-group-name-prefix "/myapp/" \
  --query 'logGroups[*].{
    logGroupName: logGroupName,
    retentionInDays: retentionInDays,
    kmsKeyId: kmsKeyId
  }'

Wenn die Log-Gruppe mit einem KMS-Schlüssel verschlüsselt ist, benötigt die schreibende Rolle zusätzlich kms:GenerateDataKey- und kms:Decrypt-Berechtigungen auf diesem Schlüssel.

Prävention und Best Practices

Verwenden Sie die verwalteten AWS-Policies als Ausgangspunkt. CloudWatchAgentServerPolicy für EC2, AWSLambdaBasicExecutionRole für Lambda, dann fügen Sie Custom-Metric-Berechtigungen nach Bedarf hinzu.

Testen Sie die Metrik-Publikation zuerst über die CLI. Bevor Sie Anwendungsänderungen deployen, verifizieren Sie von derselben Rolle aus:

aws cloudwatch put-metric-data \
  --namespace "MyApp/Production" \
  --metric-name "TestMetric" \
  --value 1 \
  --unit Count

Wenn dies erfolgreich ist, sind die IAM-Berechtigungen korrekt und Anwendungsfehler liegen im Code.

Konfigurieren Sie den CloudWatch Agent zentral über den AWS Systems Manager Parameter Store:

aws ssm put-parameter \
  --name "/cloudwatch-agent/config" \
  --type String \
  --value file://cloudwatch-agent-config.json

Überwachen Sie Ihr Monitoring. Erstellen Sie einen CloudWatch-Alarm auf die Heartbeat-Metrik des CloudWatch Agents. Wenn der Agent aufhört zu publizieren, werden Sie benachrichtigt, bevor Ihre Dashboards leer werden.

Verwenden Sie Namespace-Konventionen konsistent. Standardisieren Sie auf ein Format wie Firma/Anwendung/Umgebung, damit IAM-Condition-Policies vorhersehbar und wartbar sind.

Überprüfen Sie Berechtigungen vierteljährlich. IAM Access Analyzer kann Rollen identifizieren, die CloudWatch-Berechtigungen haben, die sie nicht mehr benötigen, und Rollen, denen erforderliche Berechtigungen fehlen.

Wann Sie Hilfe holen sollten

CloudWatch-Berechtigungsprobleme, die nach Überprüfung aller oben genannten Punkte bestehen bleiben, beinhalten oft komplexe Interaktionen zwischen SCPs, Permission Boundaries, VPC-Netzwerk und Cross-Account-Konfigurationen. Wenn Ihr Monitoring ausfällt, ist Ihre Fähigkeit, andere Probleme zu erkennen und zu diagnostizieren, beeinträchtigt — es lohnt sich, dies schnell zu beheben. Wir helfen Teams beim Aufbau zuverlässiger Observability-Stacks auf AWS. Wenn Ihr Monitoring Lücken hat oder Sie Hilfe beim Design einer Cross-Account-CloudWatch-Architektur benötigen, kontaktieren Sie uns für eine kostenlose Beratung. Wir prüfen Ihre Monitoring-Berechtigungen und stellen sicher, dass nichts durchs Raster fällt.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen