Skip to main content
In this lesson we go deeper into CloudWatch Logs and CloudWatch Logs Insights. Topics covered:
  • CloudWatch Logs architecture and data flow.
  • Common ingestion methods and trade-offs.
  • Retention, storage, and cost-optimization strategies.
  • Metric filters, subscription filters, and fan‑out patterns.
  • Querying at scale with Logs Insights.
  • Integration patterns, cross-account aggregation, and best practices.
Note: example pricing figures are directional and change frequently. Treat numbers below as illustrative only.
A slide titled "CloudWatch Logs Architecture" showing a three-layer colored pyramid that illustrates the hierarchy: Log Groups (top), Log Streams (middle), and Log Events (bottom). The caption reads that it structures log data using a simple three-layer hierarchy.
CloudWatch Logs uses a simple three-layer hierarchy:
  • Log Groups — top-level logical grouping (for example, a service, application, or environment).
  • Log Streams — ordered sequences of log events within a group (commonly time-boxed or per-instance streams).
  • Log Events — the individual log entries.
Example: a payment-processor Lambda might have one log group per function, log streams per invocation window or instance, and many log events inside each stream. Ingestion methods and trade-offs Choose an ingestion approach that fits your infrastructure, latency, and operational constraints. The table below summarizes common options and trade-offs. Key ingestion details:
  • Direct API ingestion requires managing PutLogEvents constraints: batch size limits, throughput quotas, and sequence tokens. Use official AWS SDKs or community libraries that handle retries and token management.
  • All ingestion methods require appropriate IAM permissions. Apply least-privilege policies and use resource-based policies for cross-account writes when needed.
Retention policies, storage, and security
  • Retention is configured at the log group level; you cannot set retention per log stream or per event. Every stream and event in a log group inherits the group’s retention setting.
  • Choose retention by balancing compliance, operational usefulness, and cost. Options include days, months, years, or never expire.
  • Encrypt logs at rest using AWS KMS (AWS-managed or customer-managed keys) and keep TLS in transit.
Retention is set at the log group level. All streams and events within a log group inherit that retention policy.
Security best practices:
  • Encrypt sensitive logs at rest with KMS and use TLS for transit.
  • Use least-privilege IAM roles and resource-based policies for cross-account sharing.
  • Use VPC endpoints (PrivateLink) for private connectivity to CloudWatch Logs when required.
  • Enable CloudTrail to audit configuration changes and who accessed logs.
A presentation slide titled "Encryption and Security" showing five best-practice tips. The tips recommend KMS encryption for sensitive logs, least‑privilege IAM, resource‑based cross‑account policies, enabling CloudTrail auditing, and using IAM conditions to restrict access.
Metric filters — creating metrics from logs Metric filters let you convert log events into CloudWatch metrics in near real time without writing custom code. Use them to count occurrences, extract numeric values, and power alarms or dashboards. Important characteristics:
  • Metrics are generated only from new events as they arrive. Metric filters do not retroactively process historical logs unless you re-ingest them.
  • There is no extra processing charge for metric-filter conversions beyond the normal ingestion and storage costs; however, the CloudWatch metrics produced are standard CloudWatch metrics and may incur metric-related charges.
  • Limit: 100 metric filters per log group.
  • Attach metric filters to appropriately organized log groups so filters produce meaningful metrics.
A slide titled "Metric Filters – Creating Metrics From Logs" showing a funnel icon and an arrow that illustrates transforming unstructured log data into actionable CloudWatch metrics.
A presentation slide titled "Metric Filters – Creating Metrics From Logs" showing a four-part circular infographic of key capabilities: Pattern Matching, Namespaces, Dimensions, and Stats. Each quadrant is color-coded and labeled with brief descriptions of how logs are converted into metrics.
A presentation slide titled "Metric Filters – Creating Metrics From Logs" showing two info cards: one says "$0 Processing Cost" and the other "100 Filters per Group" with brief explanatory notes beneath each.
Subscription filters and fan-out patterns A critical production and exam constraint: each log group supports only one subscription filter. Subscription filters stream log events in near-real time to one destination:
  • Kinesis Data Streams
  • Lambda
  • Kinesis Data Firehose
Because of the one-filter-per-log-group limit, common multi-destination patterns include:
  • Kinesis Data Firehose as the single subscription consumer, with Firehose delivering to multiple sinks (S3, OpenSearch, external HTTP endpoints) or invoking processing steps.
  • Kinesis Data Streams for real-time fan-out where multiple consumers can independently read from the stream.
  • A Lambda consumer that fans out to multiple downstream systems (S3, OpenSearch, third‑party APIs, etc.).
Subscription filters support cross-account delivery using appropriate IAM roles and resource policies.
Each log group supports only one subscription filter. To deliver to multiple destinations, use a fan-out pattern (Kinesis Streams, Firehose, or Lambda forwarding).
A presentation slide titled "Subscription Filters – The ONE Filter Limitation" with a four-step timeline listing: 01 Destinations, 02 One Filter Rule, 03 Fan-Out Pattern, and 04 Cross-Account Delivery. Each step briefly notes that logs can stream to Kinesis Streams/Lambda/Firehose, that each log group supports only one subscription filter, using Kinesis for fan-out, and support for cross-account delivery.
Distinguishing Kinesis Streams vs Firehose:
  • Kinesis Data Streams: best for low-latency, real-time processing and fan-out to multiple consumers.
  • Kinesis Data Firehose: best for durable, batched delivery to S3, OpenSearch, or third‑party endpoints and for built-in buffering and transformation.
CloudWatch Logs Insights — querying at scale CloudWatch Logs Insights offers a powerful query language to search, filter, extract fields, aggregate, and visualize results across log groups. Pricing is typically based on data scanned by a query, so minimizing scanned volume reduces cost. Example Logs Insights query:
Tips to reduce Logs Insights costs:
  • Limit the date range and scope to the smallest set of log groups necessary.
  • Filter early in the query pipeline to reduce scanned data.
  • Use structured logging (JSON fields) so you can extract precise fields without scanning entire messages.
  • Consider exporting older logs to S3 and running occasional ad-hoc analytics there instead of frequent large-scale Logs Insights scans.
A presentation slide titled "CloudWatch Logs Insights – Querying at Scale." It shows four colorful icons and labels illustrating features: Searching logs, Filtering events, Extracting fields, and Aggregating and visualizing results.
Cost optimization and data lifecycle Practical strategies to manage cost while preserving observability:
  • Selective retention — keep short retention for noisy, low-value logs and longer retention for critical logs.
  • Export and archive — offload cold logs to S3 and use lifecycle rules to Glacier/Deep Archive for long-term storage.
  • Log sampling — ingest a percentage (for example 1–10%) of high-volume, low-value events instead of everything.
  • Structured logging — emit JSON to enable precise field extraction and efficient queries.
  • Early filtering — drop or redact low-value or sensitive events before ingestion or before querying.
A slide titled "Cost Optimization Strategies" showing four colorful rounded panels labeled Selective Retention, S3 Export for Archives, Log Sampling, and Structured Logging, each with a short tip and an icon. The panels are blue, orange, green, and purple respectively.
Integration patterns and cross-account aggregation Common production needs:
  • Centralize logs from multiple AWS accounts into a security or central logging account.
  • Consolidate logs across Regions.
  • Forward logs to SIEMs or third-party logging platforms (Splunk, Datadog, Sumo Logic).
  • Store and index logs in OpenSearch for advanced search and fuzzy matching beyond Logs Insights.
Typical cross-account aggregation pattern:
  • Source account log groups stream to a subscription consumer (for example, a Firehose or Lambda) that assumes an IAM role with permission to write to the destination account’s S3 or OpenSearch.
  • Ensure resource-based policies and KMS key policies (if encrypting) allow the intended cross-account principals.
An infographic titled "Integration Patterns" showing a colorful semicircular diagram around a cloud icon that lists four log-integration options: Cross-Account Aggregation, Multi-Region Consolidation, SIEM Integration, and OpenSearch Integration, each with an icon and brief description.
Best practices and exam tips
  • Use structured logging (JSON) and consistent naming/semantics across services.
  • Apply appropriate log levels (DEBUG/INFO/WARN/ERROR/CRITICAL); avoid logging PII—mask or redact if necessary.
  • Use selective retention and S3 lifecycles instead of relying on CloudWatch for indefinite archiving.
  • Account for the one subscription filter per log group limit — design fan-out using Kinesis Streams, Firehose, or Lambda forwarding.
  • Create billing alarms to monitor ingestion and storage costs.
  • When using KMS encryption, ensure key policies allow the required principals to avoid accidental access issues (common exam trap).
A presentation slide titled "Best Practices and Exam Tips" showing three colorful panels labeled "Structured Logging," "Appropriate Log Levels," and "Core-Aware Architecture." Each panel includes an icon and brief guidance (use JSON logs, set correct log levels, and apply retention/monitoring and billing policies).
Key takeaways
  • Hierarchy: log groups → log streams → log events.
  • Retention is defined at the log group level.
  • Metric filters convert new log events into CloudWatch metrics (limit 100 filters/group); metric generation does not add processing charges beyond normal ingestion and storage, but the resulting metrics may incur CloudWatch metric charges.
  • Each log group supports only one subscription filter — use Kinesis Streams/Firehose or a Lambda forwarder to achieve multi-destination fan-out.
  • Use selective retention, S3 archiving, sampling, and structured logging to control costs and improve query efficiency.
  • Filter noise early and restrict Logs Insights queries to reduce scanned data and lower query costs.
Further reading and references That concludes this section on CloudWatch Logs and CloudWatch Logs Insights beyond the basics. Try hands-on exercises and scenario-based questions to apply these patterns.

Watch Video