What is the maximum size of a cross-account sink policy in Cloudwatch?

When it comes to configuring cross-account access for CloudWatch data aggregation using the Observability Access Manager (OAM) in AWS, understanding the limits of the associated resource policies is crucial, especially if you are planning to grant access to a large number of source accounts individually by account ID.

Maximum Size of a Resource Policy in CloudWatch

The maximum size for resource policies in AWS services is typically 20 KB. This is a general limit applicable to IAM policies, resource policies, and service control policies in AWS.

Implications for OAM Sink Policy

Given this 20 KB limit, you might encounter scalability issues if you need to individually specify a large number of source accounts in your resource policy. Here are some details and considerations:

1. Policy Size Limitation:

• A standard IAM or resource policy with a 20 KB limit can accommodate a limited number of account IDs, especially considering the structure and required syntax for each statement.

2. Alternatives for Scaling:

• AWS Organizations: If possible, organizing your accounts under AWS Organizations can help. You can use organization units (OUs) to simplify the policy statements by allowing access to an entire OU instead of individual accounts.
• Policy Aggregation: Consider aggregating policies or using condition keys to simplify and reduce the size of the policy statements.

Example of Resource Policy

Here’s an example of how a typical resource policy might look when granting access to multiple accounts:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111111111111:root",
          "arn:aws:iam::222222222222:root",
          "arn:aws:iam::333333333333:root"
          // Add more account ARNs here
        ]
      },
      "Action": "cloudwatch:GetMetricData",
      "Resource": "*"
    }
  ]
}

Scaling Beyond the Limit

If you are close to or exceeding the 20 KB limit, here are some strategies to consider:

1. Use Organizations and OUs:

• If your accounts are under AWS Organizations, you can simplify your policies by granting access to the organization unit (OU) rather than individual accounts.

2. IAM Roles with Cross-Account Trust:

• Create IAM roles in the monitoring account and establish cross-account trust relationships. This allows source accounts to assume the role, reducing the need to list each account individually in the resource policy.

3. Batch Updates:

• If you need to manage a large number of accounts, consider automating the policy updates and batch processing to handle policy constraints dynamically.

4. Contact AWS Support:

• For specific limits and assistance with large-scale setups, consider reaching out to AWS Support. They might offer tailored solutions or best practices for your use case.

Summary

• Resource Policy Size: The maximum size for resource policies in AWS, including those for CloudWatch OAM sinks, is generally 20 KB.
• Scalability Considerations: Given the policy size limit, specifying a large number of individual account IDs directly in the policy might not be feasible. Consider using AWS Organizations, IAM roles with cross-account trust, or automating policy updates to handle a large number of source accounts.
• AWS Support: For further assistance and specific limits, contacting AWS Support is recommended.

By understanding these constraints and planning accordingly, you can set up a scalable and manageable solution for aggregating CloudWatch data across multiple accounts.

After messing around with a POC here I found the following:

The resource policy attached to the sink is only evaluated when the link is first created in the source account. That opens the possibility of bypassing the limit on size by editing the policy just in time when onboarding new accounts.

It does not appear that any permissions are evaluated when data passes from one account to the other. Or possibly the permissions in question are not exposed to users. I tested this by revoking the permission in the resource policy after I had configured a link. Data continued to flow with no interruption. Unfortunately that is probably a deal breaker for my use case, as it leaves the monitoring account with no way to break the link unilaterally. Oh well, there are alternative approaches that will also suit my requirements.