Lambda CloudWatch Metric SourceAccount Auditor

The Incident (What Does the Error Mean?)

You will see this in CloudTrail or Lambda execution logs:

{
  "errorCode": "AccessDenied",
  "errorMessage": "User: arn:aws:sts::123456789012:assumed-role/my-lambda-exec-role/my-function
                   is not authorized to perform: cloudwatch:PutMetricData
                   with an explicit deny in a service control policy",
  "eventSource": "monitoring.amazonaws.com",
  "eventName": "PutMetricData"
}

Immediate consequence: Every custom metric emission from your Lambda silently fails. If you depend on these metrics for alarms (autoscaling triggers, error-rate alerts, SLA dashboards), those alarms go stale. You are now flying blind in production.

The subtler variant appears when a resource-based policy on a CloudWatch metric namespace or a cross-account role assumption requires aws:SourceAccount to be asserted by the calling service, and your Lambda's execution role never sets it. AWS Lambda does forward aws:SourceAccount automatically in some service-to-service flows, but if your policy has an explicit Deny conditioned on the absence of this key, the call is dead on arrival.

The Attack Vector / Blast Radius

This is a confused-deputy problem. Without aws:SourceAccount scoping:

1. Any AWS service (or compromised Lambda in a different account that has assumed a shared role) can call cloudwatch:PutMetricData and write arbitrary metric data into your namespace.
2. Poisoned metrics can suppress or trigger CloudWatch Alarms — an attacker who can write fake low-error-rate data into your namespace can mask an ongoing breach from your on-call team.
3. In multi-tenant SaaS architectures using shared execution roles, a tenant's Lambda could pollute another tenant's metric namespace, corrupting billing or SLA calculations.
4. If your SCPs enforce aws:SourceAccount as a preventive guardrail (common in AWS Control Tower landing zones), any role missing this condition will be denied — causing widespread Lambda metric blackouts across an entire OU if the role is shared.

Blast radius: All Lambda functions sharing this execution role lose CloudWatch custom metric capability simultaneously. Downstream alarms, dashboards, and autoscaling policies based on those metrics become unreliable.

Prevention in CI/CD

1. Checkov — Block merge if SourceAccount is missing:

Add a custom Checkov policy (CKV_CUSTOM_IAM_CW_SOURCE_ACCOUNT) that fails any Terraform plan where cloudwatch:PutMetricData is allowed without an aws:SourceAccount condition.

# .checkov.yml
checks:
  - id: CKV_CUSTOM_IAM_CW_SOURCE_ACCOUNT
    name: "Ensure cloudwatch:PutMetricData has aws:SourceAccount condition"
    resource: aws_iam_policy_document

2. OPA/Conftest policy for Terraform plans:

deny[msg] {
  stmt := input.resource_changes[_].change.after.statement[_]
  stmt.actions[_] == "cloudwatch:PutMetricData"
  not stmt.condition[_].variable == "aws:SourceAccount"
  msg := "cloudwatch:PutMetricData statement missing aws:SourceAccount condition"
}

3. AWS Config Rule: Enable iam-policy-no-statements-with-admin-access and pair it with a custom Config rule using AWS Lambda that inspects all managed policies for cloudwatch:PutMetricData statements lacking condition keys. Trigger on PutRolePolicy and PutUserPolicy CloudTrail events.

4. SCPs as a backstop (AWS Control Tower): In your Control Tower landing zone, enforce a preventive SCP that explicitly denies cloudwatch:PutMetricData unless aws:SourceAccount matches the account ID. This catches any role that slips through code review:

{
  "Effect": "Deny",
  "Action": "cloudwatch:PutMetricData",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:SourceAccount": "${aws:PrincipalAccount}"
    }
  }
}

This SCP pattern ensures that even if a developer deploys a Lambda execution role without the condition, the SCP catches it at the API layer before it becomes a confused-deputy liability.