OpsCanary
awsobservabilityPractitioner

Mastering Log Group-Level Subscription Filters in AWS

5 min read AWS DocsNov 8, 2026Reviewed for accuracy
Share
Practitioner — Hands-on experience recommended

Log group-level subscription filters exist to streamline the flow of log data from CloudWatch Logs to various AWS services. This capability is essential for building observability into your applications, allowing you to process logs in real-time and trigger actions based on log events. By forwarding log events that match specific filter patterns, you can efficiently manage and analyze your logs without manual intervention.

When you set up a subscription filter, logs are sent to your chosen service in gzip format, which helps reduce bandwidth usage. AWS Lambda receives this data base64 encoded in the awslogs.data field, while Kinesis Data Streams records contain the gzip bytes directly. After configuring the subscription filter, CloudWatch Logs will forward all incoming log events that match your defined filter pattern to the designated stream. This setup allows for seamless integration with services like Kinesis, Lambda, and more, enabling powerful log processing workflows.

In production, you need to be aware of potential throttling issues. If the volume of log data exceeds the capacity of your Kinesis stream, you may experience throttling, which can lead to dropped log events after 24 hours. To mitigate this, consider using on-demand capacity mode for your Kinesis streams and monitor your stream with CloudWatch metrics. Additionally, ensure your filter pattern is optimized to match the stream's capacity to avoid overwhelming it. Remember to create a trust policy and a permissions policy before setting up your subscription filter to ensure proper permissions are in place.

Key takeaways

  • →Use gzip format for efficient log data transfer.
  • →Ensure AWS Lambda receives data base64 encoded in the awslogs.data field.
  • →Monitor your Kinesis stream with CloudWatch metrics to identify throttling issues.
  • →Create a trust policy and permissions policy before setting up subscription filters.
  • →Limit your filter pattern to match the capacity of your Kinesis stream.

Why it matters

In production, real-time log processing can significantly enhance your application's observability and responsiveness. Efficiently routing logs to processing services allows for quicker detection of issues and improved operational insights.

Code examples

programlisting
aws logs put-subscription-filter \ --log-group-name "CloudTrail/logs" \ --filter-name "RootAccess" \ --filter-pattern "{$.userIdentity.type = Root}" \ --destination-arn "arn:aws:kinesis:region:123456789012:stream/RootAccess" \ --role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
programlisting
$C:\>aws kinesis create-stream --stream-name "RootAccess" --shard-count 1
programlisting
aws iam create-role --role-nameCWLtoKinesisRole--assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
DigitalOceanSponsor

Simple, affordable cloud — VMs, Kubernetes, and managed databases in minutes. Trusted by 600,000+ developers. Spin up a Droplet in 60 seconds.

Try DigitalOcean →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.