The alarm coverage gaps that hide between AWS accounts

Most alarm-coverage content assumes one account. Real teams running AWS Organizations don't have one — they have production, staging, a security/log-archive account, maybe a sandbox, sometimes a new account per customer. Alarm coverage isn't a single number in that setup. It's N numbers, one per account, and they drift apart the moment nobody's job is to keep them in sync.

• Why alarm coverage drifts between accounts
• What CloudWatch offers for multi-account visibility
• What cross-account observability actually costs
• Setting up a sink and a link
• What cross-account observability does NOT fix
• A practical checklist for auditing multi-account coverage

Why alarm coverage drifts between accounts

The account where your original CloudWatch alarms were hand-built or first templated is usually the best-covered one — it's had the most attention. Every account created after that inherits coverage only if someone remembered to copy the template, and Control Tower or Account Factory account vending doesn't include your custom alarms by default; it provisions the account, not your monitoring setup. Six months later, the newest account in the Organization is often the least monitored one, and nobody notices until an incident happens there specifically.

What CloudWatch offers for multi-account visibility

CloudWatch cross-account observability lets a designated monitoring account search, visualize, and analyze metrics, logs, and traces from other accounts without switching consoles or assuming a role into each one individually. It's built on three pieces: a Sink (created once in the monitoring account, one per region), Sink Policies (which grant source accounts — or a whole AWS Organization — permission to attach), and Links (created in each source account, connecting it to a monitoring account's sink and specifying which telemetry types flow across).

Integrating with AWS Organizations lets a Sink Policy grant access to every current and future account in the Org in one step, instead of adding source accounts one at a time as they're created — the closer this matches how your Org actually grows, the less this drifts out of sync again.

What cross-account observability actually costs

Setting up a sink and a link

# In the monitoring account — create the sink once per region
aws oam create-sink --name central-monitoring-sink

# Attach a sink policy granting the whole Organization access
aws oam put-sink-policy \
  --sink-identifier arn:aws:oam:REGION:MONITORING_ACCOUNT_ID:sink/SINK_ID \
  --policy file://sink-policy.json

# In each source account — create the link to the monitoring account's sink
aws oam create-link \
  --sink-identifier arn:aws:oam:REGION:MONITORING_ACCOUNT_ID:sink/SINK_ID \
  --resource-types AWS::CloudWatch::Metric AWS::Logs::LogGroup AWS::XRay::Trace \
  --label-template '$AccountName'

What cross-account observability does NOT fix

OAM centralizes visibility into whatever already exists in each source account — it doesn't create alarms, backfill missing metrics, or notice a gap on your behalf. Link an account with zero CloudWatch alarms to your monitoring account and you get exactly that: centralized visibility into an account with zero alarms. The underlying coverage problem — a new account provisioned without the standard alarm set — is unchanged. Cross-account observability is a visibility fix, not a coverage fix.

A practical checklist for auditing multi-account coverage

1. List every account currently in the Organization — AWS Organizations console or `aws organizations list-accounts` — and note which ones actually run production workloads.
2. For each account, check whether the baseline alarm set exists (CPU, memory, error rate, disk, and the CIS CloudTrail security alarms) rather than assuming it was copied from the template account.
3. Set up cross-account observability if centralized dashboards and cross-account Logs Insights are worth the trace-copy cost for your team — it's a visibility layer, do this after coverage is confirmed, not instead of confirming it.
4. Make baseline alarm setup part of the account-vending template itself, so every new account starts covered instead of starting from zero.