At the professional level, the interesting monitoring problems aren’t inside one account — they’re across dozens of them. A DOP-C02 scenario rarely asks “how do I set a CloudWatch alarm?” It asks “how do I see logs from 40 accounts in one place, keep them for seven years, and let the platform team query traces from every workload without giving them 40 sets of credentials?” That is the Monitoring and Logging domain at organization scale, and it’s where a lot of otherwise-strong candidates lose points.
This guide takes a DevOps-scale view of observability for the AWS Certified DevOps Engineer – Professional (DOP-C02) exam. It assumes you already know single-account CloudWatch — metrics, alarms, Logs Insights, X-Ray — which the DOP-C02 monitoring and observability guide covers. Here we build one level up: how logs, metrics, and traces are aggregated and governed across many accounts and Regions, and which AWS primitive solves each fan-in problem.
The Core Problem: Telemetry Is Trapped Per Account
By default, every account’s CloudWatch metrics, log groups, and X-Ray traces live only in that account and Region. That isolation is good for blast radius but terrible for operations: an on-call engineer would need to assume a role into each account just to read a log. The DOP-C02 exam expects you to break that isolation deliberately and safely, using one of two broad patterns:
| Pattern | What moves | Best for |
|---|---|---|
| Central logging account | Log data is copied/streamed into one account | Long-term retention, search, compliance, analytics |
| Cross-account observability | Nothing moves — one account is granted read views into others | Live dashboards, alarms, and troubleshooting across accounts |
They are complementary. You use a central logging account for durable, queryable log storage, and cross-account observability so a monitoring team can watch live telemetry everywhere. Knowing which the question is describing is half the battle.
Pattern 1: A Central Logging Account
The reference design is a dedicated Log Archive account (in AWS Organizations landing zones this is a standard core account) that receives log data from every other account. The building blocks:
CloudWatch Logs subscription filters → a destination
A subscription filter on a log group streams matching log events in near-real-time to a delivery target. In a single account that target is often a Lambda or a Kinesis stream. Across accounts, you point it at a cross-account CloudWatch Logs destination — an object in the central account that references a Kinesis Data Stream or Kinesis Data Firehose and carries a policy naming which source accounts may write to it.
The end-to-end flow for durable central storage looks like this:
Source account log group
└─ subscription filter
└─ (cross-account) Logs destination in central account
└─ Kinesis Data Firehose
└─ Amazon S3 (partitioned, lifecycle-managed)
└─ Athena / OpenSearch for searchFirehose is the workhorse for the storage leg: it buffers, optionally transforms, compresses, and writes to S3 (or a search domain) without you managing consumers. S3 then becomes the queryable, cheap, long-retention system of record, with Athena for ad-hoc SQL over the archived logs.
Why not just export?
Candidates sometimes reach for one-off CloudWatch Logs export to S3. That’s a manual, batch operation meant for occasional extraction — not a pipeline. When a question stresses continuous, near-real-time, or automatic aggregation of new log data, the answer is a subscription filter to a destination, not an export task. That contrast is a classic exam distractor.
CloudTrail is a special case
Organization-wide API audit logging has its own turnkey mechanism: an organization trail delivers CloudTrail events from every account (including accounts created later) into a central S3 bucket automatically. You don’t wire per-account subscription filters for CloudTrail — you enable an org trail from the management or delegated-administrator account. Reserve the subscription-filter pipeline for application and service logs in CloudWatch Logs.
Pattern 2: CloudWatch Cross-Account Observability
The second pattern moves views, not data. CloudWatch cross-account observability designates one account as a monitoring account and links source accounts to it, so operators working in the monitoring account can see and query telemetry that still physically lives in the source accounts.
The architecture uses two objects:
- A sink in the monitoring account — the thing source accounts attach to. It carries a policy that governs which accounts (or which Organization/OU) may link.
- A link in each source account — points at the monitoring account’s sink and declares which telemetry types to share.
Monitoring account
└─ observability sink (policy: allow accounts in OU xyz)
▲ ▲ ▲
│ │ │
link link link
(acct A) (acct B) (acct C) ← source accounts share selected telemetryOnce linked, an engineer in the monitoring account gets cross-account dashboards, can run Logs Insights queries spanning source accounts, and can build alarms on cross-account metrics — without copying data or juggling credentials. The telemetry types you can share are selected at the link (metrics, logs, and traces), so the design question is usually what each source account should expose, not whether the mechanism works.
Because the sink policy can be scoped to an Organization or specific OUs, this pairs naturally with the account-provisioning approach in provisioning and governance at scale: new accounts created by your Account Factory can be linked to the monitoring account as part of their baseline.
Central logging account vs monitoring account — don’t conflate them
These are two different roles and the exam likes to test the distinction:
| Central logging account | Monitoring account | |
|---|---|---|
| What it holds | Copies of log data (in S3/OpenSearch) | Live views into other accounts |
| Data movement | Yes — streamed via Firehose/destinations | No — data stays in source accounts |
| Primary use | Retention, compliance, analytics | Dashboards, alarms, live troubleshooting |
| Key objects | Logs destination, Kinesis, Firehose, S3 | Observability sink + links |
A mature platform runs both: durable central storage and a live cross-account monitoring pane.
Aggregating Metrics: Metric Streams
Logs aren’t the only telemetry you centralize. CloudWatch metric streams push metrics in near-real-time (via Firehose) to a destination — commonly S3 for a metrics lake, or a third-party monitoring destination your organization already uses. Contrast this with the pull-based GetMetricData API: metric streams are the push, continuous-delivery answer when a question asks how to get all account metrics into an external analytics or observability platform without polling.
So the fan-in toolkit, by telemetry type:
| Telemetry | Continuous aggregation mechanism |
|---|---|
| Logs | Subscription filter → cross-account destination → Firehose → S3/search |
| Metrics | Metric stream → Firehose → S3 or third-party destination |
| Traces (X-Ray) | Shared via a cross-account observability link |
| API audit events | Organization CloudTrail → central S3 bucket |
Deploying the CloudWatch Agent Fleet Consistently
Centralized reading is pointless if the sources emit inconsistent data. Memory, disk, and custom application metrics require the CloudWatch agent, and at fleet scale you don’t hand-configure hundreds of instances. The exam-favored pattern:
- Store one canonical agent configuration in SSM Parameter Store.
- Use the
AmazonCloudWatch-ManageAgent/ agent-config SSM documents (via State Manager or Run Command) to install and start the agent using that parameter. - State Manager re-applies the configuration on a schedule, so drift self-heals and new instances converge automatically.
This ties observability to the configuration-management story in configuration management and IaC: the agent config is version-controlled and pushed the same way as any other desired-state configuration, not clicked in per host.
Governing Retention and Cost at Scale
Two governance levers show up repeatedly in DOP-C02 logging scenarios:
- Log group retention. New CloudWatch log groups default to never expire, which quietly becomes the biggest line item in a large estate. Set an explicit
retentionInDayson every log group — and enforce it. A common automation: an EventBridge rule matchingCreateLogGroup(from CloudTrail) triggers a Lambda that applies the standard retention policy, so no log group is ever created without one. - Tiered storage for the archive. In the central account, use S3 lifecycle rules to transition archived logs from Standard to cheaper tiers over time, matching your compliance window. This is where the central-logging pattern earns its keep versus indefinite CloudWatch Logs retention.
Define these with infrastructure as code so they apply uniformly. Managing log groups, retention, subscription filters, and the observability sink/links through CloudFormation or the CDK — rather than the console — is what makes the design repeatable across an Organization and is exactly the automation altitude the exam rewards.
# Enforce retention on a log group (the value the auto-remediation Lambda would apply)
aws logs put-retention-policy \
--log-group-name /aws/app/payments \
--retention-in-days 400Turning Aggregated Logs into Alarms
Central visibility should drive action, not just storage. A metric filter on a log group turns matching log patterns (say, ERROR or a specific status code) into a CloudWatch metric you can alarm on. At scale, standardize these filters through IaC so every application log group emits the same error metric, then build cross-account alarms in the monitoring account. When an alarm fires, route it through the incident and event-response flow described in incident response and auto-remediation so detection connects to a runbook.
This closes the loop: consistent agents produce comparable telemetry → subscription filters and streams aggregate it → metric filters and cross-account alarms detect problems → EventBridge and automation respond.
Exam-Day Decision Signals
Map the phrasing to the mechanism quickly:
| Question says… | Reach for |
|---|---|
| ”near-real-time, continuous log aggregation” | Subscription filter → destination → Firehose |
| ”one-time extract of old logs to S3” | CloudWatch Logs export task |
| ”view/query logs and metrics from many accounts, no data copy” | Cross-account observability (sink + links) |
| “durable, queryable, long-retention log store” | Central logging account (Firehose → S3 → Athena) |
| “all account metrics into an external/analytics platform” | Metric streams |
| ”org-wide API audit logging, including future accounts” | Organization CloudTrail → central bucket |
| ”logs never expire / cost is exploding” | Enforce retentionInDays + S3 lifecycle |
| ”consistent memory/disk metrics across the fleet” | CloudWatch agent config in SSM + State Manager |
Practice With Professional-Level Scenarios
Cross-account observability is a domain where the concepts are learnable in an afternoon but the distinctions — destination vs export, monitoring account vs logging account, metric stream vs GetMetricData — only stick when you’ve answered enough scenario questions to internalize the signal words. The professional exam’s long, multi-service scenarios are specifically designed to make you pick between plausible-sounding options.
The AWS Certified DevOps Engineer – Professional (DOP-C02) Mock Exam Bundle gives you eight full-length mock exams — 600 questions in the same 75-question, 180-minute format as the real exam — with detailed explanations that call out exactly these Monitoring and Logging distinctions. Pair it with the DOP-C02 study plan to sequence observability alongside SDLC automation and resilience, and cross-reference multi-account and cross-Region CI/CD and security and compliance automation, which share the same Organizations foundation.
Conclusion
Monitoring and Logging at the professional level is an aggregation-and-governance problem. Two patterns carry most of the weight: a central logging account that ingests log data through subscription filters and cross-account destinations into Kinesis Data Firehose and S3 for durable, queryable storage; and cross-account observability, where a monitoring account uses a sink and per-account links to see live metrics, logs, and traces without moving any data. Around them sit metric streams for centralizing metrics, organization CloudTrail for audit events, the CloudWatch agent deployed consistently via SSM, and retention/lifecycle policies enforced through IaC and automation. Learn to distinguish continuous pipelines from one-off exports, and a logging account from a monitoring account, and the toughest Monitoring and Logging scenarios resolve to a single clear answer.
Frequently Asked Questions
What’s the difference between a central logging account and a monitoring account?
A central logging account stores copies of log data (typically streamed via Firehose into S3 for retention and analytics). A monitoring account holds live views into other accounts through CloudWatch cross-account observability — the data stays put in the source accounts and is read in place. Large organizations run both.
When do I use a subscription filter versus exporting logs to S3?
Use a subscription filter to a destination for continuous, near-real-time streaming of new log events — the basis of an aggregation pipeline. Use a CloudWatch Logs export task only for occasional, manual, batch extraction of existing logs. If the scenario stresses “continuous” or “automatic,” it’s a subscription filter.
How does cross-account observability actually connect accounts?
You create an observability sink in the monitoring account (with a policy naming which accounts or OUs may attach) and a link in each source account pointing at that sink. The link selects which telemetry types — metrics, logs, traces — the source account shares. No credentials are shared and no data is copied.
How do I centralize metrics rather than logs?
Use CloudWatch metric streams, which push metrics in near-real-time through Kinesis Data Firehose to a destination such as S3 (a metrics lake) or a third-party monitoring destination. It’s the push-based alternative to repeatedly polling the GetMetricData API.
How do I stop log groups from retaining data forever?
Set an explicit retention on every log group with put-retention-policy, and automate enforcement: an EventBridge rule on the CreateLogGroup event triggers a Lambda that applies your standard retentionInDays. In the central account, add S3 lifecycle rules to tier and expire archived logs on your compliance schedule.
Is this the same as the single-account CloudWatch content?
No. Single-account monitoring (metrics, alarms, Logs Insights, X-Ray) is the foundation and is covered in the DOP-C02 monitoring guide. This article is the organization-scale layer on top: aggregating and governing that same telemetry across many accounts and Regions.