CloudTrail - Client.DryRunOperation

Question

We are currently ingesting AWS CloudTrail logs into our monitoring platform (eG), and we are facing high noise levels caused by events such as Client.DryRunOperation.

Our goal is to reduce non-actionable events while preserving both security-relevant signals and operational risk-related events, while also ensuring the solution is cost-optimized.

Constraints:

We understand that CloudTrail does not natively support filtering at the errorCode level (e.g., excluding Client.DryRunOperation)
We are looking for best practices to filter events before ingestion into downstream systems
Cost efficiency is a key requirement, especially considering high-volume CloudTrail logs

Questions:

1. What is the most cost-optimized architecture to filter CloudTrail events before forwarding (e.g., CloudWatch Logs + Lambda, Amazon EventBridge, Kinesis, etc.)?
2. Has anyone implemented filtering logic specifically for DryRun operations or similar transient API errors in a cost-efficient way?
3. Is there a known baseline or categorization of CloudTrail events into:
Security-critical
Operational risk-related
Noise/transient

Florian Turnwald · Answer

**To add a modern alternative for those looking to manage log costs and complex querying:**

While standard Trails have the filtering limitations mentioned, consider **AWS CloudTrail Lake**.

Unlike standard S3-backed trails, CloudTrail Lake allows you to use **SQL-based ingestion** filters. This means you can technically exclude specific errorCode values or specific users/roles at the point of ingestion into the data lake. This helps in:
- **Reducing "noise"** before the data is even stored for analysis.
- **Cost Management:** You only pay for the storage of events that meet your specific criteria.

If you are sticking with standard S3/CloudWatch logs, then filtering at the EventBridge or Athena level (as suggested above) remains the industry-standard approach.

Pothuraju Jayakrishna Yadav · Answer

You can’t exclude them directly in CloudTrail trail settings — CloudTrail doesn’t support filtering specific error codes at the source level.

What I usually do instead is keep the trail as-is (for audit purposes) and handle the noise later.

If logs are going to CloudWatch, you can filter them there and ignore events where errorCode = Client.DryRunOperation so they don’t affect alerts.

If you’re using Athena or any log analysis, just exclude them in your queries — that’s usually the easiest and most flexible approach.

For alerts (EventBridge rules), you can add a condition to skip these events so they don’t trigger notifications.

Basically, instead of trying to stop CloudTrail from collecting them (which isn’t possible), it’s better to filter them where you actually consume the logs.

References:

CloudTrail filtering and event structure: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html
CloudWatch Logs filter patterns: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
EventBridge event patterns: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html

CloudTrail - Client.DryRunOperation

Add your answer

Relevant content