Your workloads are split across a dozen AWS accounts and an on-call engineer has to assume a role into each one to read its CloudWatch data. How does AWS cross-account observability change that, and what does it not give you?

## The problem it solves Multi-account is the AWS-recommended isolation boundary, and it is also the reason incident response is slow. Telemetry is regional and account-scoped, so an engineer chasing one request across three accounts logs into three consoles, or maintains a role-assumption dance, and cannot draw a single graph of the whole thing. ## Sinks and links Cross-account observability is implemented by **Observability Access Manager (OAM)**, and it has exactly two objects: - A **sink** in the **monitoring account** — the account whose console you want to live in. One per region. Its resource policy states who may attach to it, typically expressed with an organization condition rather than an account list so new accounts work automatically. - A **link** in each **source account**, pointing at the sink's ARN and declaring what it shares. ```bash # in the monitoring account aws oam create-sink --name central-observability # in each source account aws oam create-link \ --label-template '$AccountName' \ --resource-types AWS::CloudWatch::Metric AWS::Logs::LogGroup AWS::XRay::Trace \ --sink-identifier arn:aws:oam:eu-west-1:111122223333:sink/abcd1234 ``` The direction matters and is frequently asked: the **source account initiates the sharing**. The monitoring account cannot reach in and take data; it can only publish a sink that source accounts choose to attach to. That is what makes the model acceptable to a security team — sharing is a decision the data owner makes. ## The resource types A link names the categories it exposes, including `AWS::CloudWatch::Metric`, `AWS::Logs::LogGroup`, `AWS::XRay::Trace`, and further types such as Application Signals services. Sharing is per type, so a source account may expose metrics but withhold log groups. Links also support **filtering**, so you can share a subset — particular log groups, particular metric namespaces — rather than everything. That is the lever to use when a source account holds sensitive log data: share metrics broadly, share logs narrowly. The `--label-template` matters more than it looks. Everything in the monitoring account's UI comes from several accounts at once, and `$AccountName` is what stops "which `payments` log group is this?" from being a question during an incident. ## What the monitoring account can then do - Put **metrics from several accounts on one dashboard widget**, with the account chosen per widget or driven by a dashboard variable. - Run **Logs Insights queries across log groups in several accounts** in a single query. - Follow a **trace across account boundaries** in one view, which is the single biggest win when the request path crosses account lines. ## What it explicitly is not - **Not a data movement.** Nothing is copied. The telemetry stays in the source account, in its log groups, under its retention and its KMS keys, and is billed there. If you wanted a copy, that is a subscription filter or Metric Streams — a different mechanism entirely. - **Not an authorization grant to people.** The link gives the *monitoring account* read access; individual principals in it still need their own IAM permissions. Setting up a sink does not make every engineer in the monitoring account a reader. - **Not two-way.** Source accounts get nothing from the monitoring account and cannot see each other. - **Not global.** Sinks are per region. A multi-region estate needs one per region, and the monitoring account switches region as it always did. - **Not a substitute for owning alarms.** Alarms and their actions have historically been the responsibility of the account that owns the resource. Be deliberate about where alarms live and who is paged, rather than assuming the monitoring account inherits the whole notification story. ## The predecessor, and why it still comes up Before OAM, cross-account dashboards were done with an IAM role in each source account named **`CloudWatchCrossAccountSharingRole`**, which the monitoring account assumed to render graphs. You will still meet it in older estates. It was narrower — dashboard and console rendering — and had no notion of sharing log groups or traces wholesale. If you find it, treat it as legacy and plan the move to sinks and links. ## Rolling it out The practical order is: pick the monitoring account (a dedicated one, not the organization management account); create the sink per region with an organization-scoped policy; deploy links from source accounts as code so new accounts get one automatically at vending time; start with metrics and traces; add log groups deliberately, with filters where the content is sensitive. Then delete the per-account bookmark sprawl, because the failure mode of this feature is that half the estate is linked and nobody trusts the central view enough to use it.