Centralized cross-account logging and monitoring with CloudWatch and OpenSearch
One place to search every account's logs, one place to watch every account's alarms, without copying operators into each account.
The problem: logs scattered across accounts
In an AWS Organization, each workload lives in its own account with its own CloudWatch log groups: application logs, VPC Flow Logs, CloudTrail events. That isolation is good for blast radius, but it means an operator investigating an incident would otherwise have to log in to every account separately to read logs, and a security team would have no single searchable view.
The centralized logging pattern keeps each account as the owner of its raw logs but streams a copy of the events that matter into one central logging account. Nothing is moved or deleted at the source; a subscription filter simply forwards matching events, so each account still retains its own log groups for local troubleshooting.
The problem: logs isolated in every account
Trace
Each workload lives in its own account and owns its raw logs: application logs, VPC Flow Logs and CloudTrail events, all confined to that account. Good for blast radius, but an operator investigating an incident has to assume a role into each account and read its log groups one at a time, and a security team has no single searchable view across the estate.
The ingestion path: subscription filters to a central stream
CloudWatch Logs subscription filters deliver log events in near real-time to a downstream target. For a centralized design, the target is a cross-account destination: in the central logging account you create a log destination backed by an Amazon Kinesis data stream and attach a destination access policy that lists which source accounts may write to it. Each workload account then creates a subscription filter that points at that destination ARN and includes a filter pattern so only matching events are forwarded.
From the Kinesis data stream, Amazon Data Firehose reads the records, buffers them, and can invoke an AWS Lambda function to parse or enrich each record before delivery. Firehose then fans the same stream out to two destinations: an Amazon OpenSearch Service domain for indexing, and an Amazon S3 bucket. This is the standard shape for real-time cross-account log aggregation.
Ingestion path: subscription filters to a cross-account destination
Trace
In the central logging account you create a CloudWatch Logs destination backed by an Amazon Kinesis data stream, with a destination access policy that names which source accounts may write to it. Each workload account creates a subscription filter with a filter pattern that points at the destination ARN, so only matching events are forwarded in near real-time into the central Kinesis stream, where Amazon Data Firehose picks them up.
OpenSearch for search, S3 for archive
The two Firehose destinations serve two different jobs. Amazon OpenSearch Service is the hot, searchable tier: operators use the built-in OpenSearch Dashboards to run full-text queries and build visualizations across logs from every account at once, which is exactly what OpenSearch Service is designed to load streaming data into.
Amazon S3 is the durable, cheap archive tier. Firehose lands the raw records in S3, and an S3 lifecycle rule can transition older objects to a colder storage class such as Glacier to control cost while still meeting long retention requirements. Keeping the searchable index small and time-bounded while S3 holds the full history is what keeps the OpenSearch domain affordable.
Two tiers: OpenSearch for search, S3 for archive
Trace
From the Kinesis stream, Amazon Data Firehose buffers the records, optionally invokes a Lambda transform, then fans the same stream out to two destinations. OpenSearch Service is the hot, searchable tier where operators run full-text queries and build visualizations across every account in OpenSearch Dashboards. Amazon S3 is the durable, cheap archive tier: Firehose lands raw records there and an S3 lifecycle rule transitions aged objects to a colder class such as Glacier.
Monitoring across accounts: cross-account observability and alarms
Logging answers 'what happened'; monitoring answers 'is something wrong right now.' CloudWatch cross-account observability lets you designate one monitoring account that can view metrics, log groups, and alarms from many source accounts, so an operator sees the whole estate from a single CloudWatch console without switching roles into each account.
Detection still comes from metric filters and alarms. A metric filter turns a matching log pattern (for example, repeated 'ERROR' lines or a specific HTTP 5xx string) into a CloudWatch metric, and an alarm on that metric fires when a threshold is crossed. The alarm publishes to an Amazon SNS topic, which notifies the on-call team. That log-pattern-to-metric-to-alarm-to-SNS chain is the core notification loop this exam expects you to build.
Monitoring: cross-account observability plus the alarm loop
Trace
Keep the two halves separate. CloudWatch cross-account observability designates one monitoring account that can read metrics, log groups and alarms from many source accounts, so an operator sees the whole estate from one console without switching roles. Detection is a separate chain: a metric filter turns a matching log pattern (repeated ERROR lines, a 5xx string) into a CloudWatch metric, an alarm fires when a threshold is crossed, and the alarm publishes to an SNS topic that pages the on-call team.
What this teaches for the exam
When a scenario asks for a single searchable view of logs from many accounts, the answer is a subscription filter forwarding to a cross-account destination in a central account, not copying operators into each account or manually exporting log files. When it asks how the aggregated logs become searchable, the answer pairs OpenSearch Service (search and dashboards) with S3 (archive), fed by Data Firehose.
And when a scenario asks how an operator gets notified that something is wrong, keep the two halves separate: cross-account observability gives the unified monitoring view, while a metric filter plus a CloudWatch alarm plus an SNS topic is the mechanism that actually pages someone.
Centralized cross-account logging and monitoring pipeline
Trace
Each workload account keeps its own CloudWatch log groups, but a subscription filter streams matching events to a cross-account destination that points at a Kinesis data stream in one central logging account. Amazon Data Firehose buffers and (optionally) transforms the records with Lambda, then delivers them to an Amazon OpenSearch Service domain for search and dashboards and to Amazon S3 for cheap long-term archive. Separately, CloudWatch cross-account observability lets a monitoring account read metrics, logs, and alarms from every source account, and metric filters raise alarms that notify an SNS topic.
