Skip to main content
Welcome. This lesson explains how to use CloudWatch Logs subscription filters and log-streaming architectures to move logs beyond CloudWatch for real-time processing, analytics, compliance, and alerting. When designing centralized logging across accounts and regions, the objective is to build a dynamic pipeline that collects, filters, routes, processes, and analyzes log events. This enables actionable insights, cross-service correlation, and enterprise-grade observability.
A diagram titled "Moving Logs Beyond CloudWatch" showing CloudWatch Logs flowing through subscription filters and real-time processing into a dynamic pipeline that produces alerts, analytics, compliance, and BI.
The pipeline diagram highlights common streamed-log consumers: BI/analytics, security tools, alerting, and compliance. CloudWatch Logs subscription filters provide near-real-time forwarding to downstream services so you can transform, enrich, and route logs where they’re most useful. Key constraint: CloudWatch Logs permits only one active subscription filter per log group. You cannot attach multiple subscription filters to the same log group simultaneously — plan your architecture around this limitation.
A slide diagram explaining the CloudWatch constraint "One Subscription Filter Per Log Group." The left (green) diagram shows a correct setup with one subscription filter routing to multiple destinations, and the right (red) diagram shows the incorrect use of multiple subscription filters.
Plan your destination strategy early. Rather than creating many log groups to work around the single-filter constraint, route from a single subscription filter to a destination that can fan out (for example, Kinesis Data Streams) or perform transformations.
A slide titled "The Critical Constraint You Must Know" showing a design flow: CloudWatch Logs -> Amazon Kinesis Data Streams -> AWS Lambda, with advice to "Plan destination strategy early" to avoid costly rework. Below the stream are icons for Analytics and Security Tools as downstream consumers.
Destination choices and trade-offs Choose the destination that best supports your downstream consumers to avoid costly rework later.
A slide titled "Three Destination Types" showing Amazon Kinesis Data Streams, AWS Lambda, and Amazon OpenSearch Service on the left. The right column outlines "Custom transformation and routing logic" with bullet points about serverless event-driven processing, transform/enrich/route logs, invocation patterns, and integrations.
Cross-account aggregation is essential for unified observability and centralized compliance. A common enterprise pattern uses a central logging account that hosts the primary stream or delivery endpoint (Kinesis stream, Firehose, or S3). Source accounts forward logs via subscription filters into that central destination. Requirements for cross-account ingestion:
  • Resource policies on the destination (e.g., Kinesis or Firehose) that allow the source account to put records.
  • Cross-account IAM roles granting PutRecords/PutRecordBatch for Kinesis, or delivery permissions for Firehose/S3.
  • Secure transport and least-privilege IAM policies to limit scope.
A slide titled "Cross-Account Log Aggregation" showing a circular workflow around "Enterprise Environment." Three colored nodes highlight "Compliance-ready centralized AWS Logging" (blue), "Unified Observability" (green), and "Cost Management" (orange).
Common implementation pattern
A slide diagram titled "Cross-Account Log Aggregation" showing a common implementation pattern with four labeled components: Central Logging Account, 15+ Application Accounts, IAM Roles, and Aggregated Processing. Beneath those are three benefit boxes (centralizes compliance, reduces per-account costs, and enables org-wide log analytics).
Filter patterns let you reduce ingestion volume and focus on signal. Common strategies:
  • Forward only ERROR or FATAL events.
  • Extract and forward specific fields to minimize payload size.
  • Use OR conditions to capture multiple critical levels.
  • Use no filter (pass-through) when you require full fidelity—expect higher ingestion costs.
Example CloudWatch Logs filter patterns:
Filter early to reduce downstream storage and processing costs. Use filtering for alert pipelines, fraud detection, security event capture, and cost optimization.
The image is a slide titled "Filter Patterns for Targeted Processing" showing four strategic use cases arranged in a quadrant: 1) Alert pipelines, 2) Fraud detection, 3) Security events, and 4) Cost optimization, each with a colored corner graphic and icon. The slide is branded © Copyright KodeKloud.
OpenSearch integration options
  • Direct to OpenSearch Service: If OpenSearch is the primary target, use Kinesis Data Firehose or a Lambda transformer to format and index logs directly into OpenSearch Service. This is common when you want real-time indexing and visualization.
  • Lambda bridge to OpenSearch Serverless: When using OpenSearch Serverless (or when significant transformation is needed), insert a Lambda between the subscription and the OpenSearch API. Lambda receives batches, transforms/enriches records, and issues bulk index requests to the OpenSearch Serverless API. Also leverage OpenSearch tiered storage (hot/warm/cold) for cost/performance trade-offs.
A presentation slide titled "OpenSearch Integration Patterns — Direct to OpenSearch Service" showing a colorful arrow-based flow diagram illustrating stages like built-in log ingestion, real-time indexing, and visualization-ready.
If you need serverless transformation before ingestion, use the Lambda bridge pattern. Lambda reads batches from the subscription, performs transformation and enrichment, batches records, and then issues bulk indexing operations to OpenSearch Serverless.
A slide diagram titled "OpenSearch Integration Patterns" showing the "Lambda Bridge Pattern" for serverless log ingestion. It outlines four components—Subscription Filter → Lambda, Transform & Batch, Cost Optimization, and OpenSearch Serverless API—arranged around a central icon.
Kinesis Data Streams: when to choose Kinesis Data Streams is ideal when you need multiple independent consumers, high throughput, ordering guarantees, and flexible retention. Streaming from CloudWatch Log Groups into a Kinesis stream lets you support multiple downstream systems (alerting, archival, SIEM, analytics) concurrently.
A presentation slide titled "Kinesis Data Streams Deep Dive" showing a "Multiple Consumer Architecture Pattern." It illustrates four consumers—Consumer 1: Real-Time Alerting, Consumer 2: Compliance Archival, Consumer 3: Fraud Detection, and Consumer 4: SIEM Integration—displayed as colored stepped blocks with icons.
Lambda considerations in log pipelines When using Lambda for transformation, routing, or ingestion:
  • Account for concurrency and provisioned concurrency needs.
  • Implement robust error handling, DLQs (dead-letter queues), and retry strategies.
  • Optimize memory and timeouts (Lambda max timeout is 15 minutes).
  • Use durable buffers like SQS or Kinesis if downstream systems can cause backpressure or longer processing times.
A presentation slide titled "Lambda Processing Patterns" showing production design considerations arranged as four numbered, color-coded boxes. The items listed include handling concurrent invocations, implementing robust error handling, optimizing function memory, and monitoring health metrics.
Summary — must-know concepts
A presentation slide titled "DOP-C02 Exam Focus Areas" showing five colorful numbered gear icons under the heading "Must-Know Concepts." Each gear lists a short point (e.g., one subscription filter per log group; cross-account IAM configuration; OpenSearch Serverless Lambda requirement; filter patterns reduce volume; Kinesis enhanced fan-out).
A hands-on demo typically follows to show configuration steps, IAM role setup, subscription filter creation, and end-to-end verification. Further reading and references

Watch Video