Choose Telemetry Access for a Customer-Controlled AWS Tenant

Compare customer-local diagnosis, scoped cross-account visibility and approved extracts with explicit read, unmask, export, retention and missing-evidence boundaries.

Choose telemetry access from the customer's accepted evidence boundary, rather than automatically forwarding every dedicated tenant's logs to the vendor. Compare customer-local diagnosis, a scoped cross-account view and an approved extract against the same incident question. Record who controls the source, which reader can inspect it, whether unmasked data is permitted and what copies an investigation creates.

This article helps customer operations and vendor support agree how to diagnose one workflow in a customer-controlled AWS account. It does not redesign all instrumentation or prescribe legal retention. The example uses fictional event references, counts and dispositions; no AWS link, log query, export, masking policy or customer access was tested. Documentation supports the named service distinctions. The access record and proposed checks remain engineering recommendations requiring the actual customer's approved scope.

1. Ask for the evidence needed to make one incident decision

For an interrupted report delivery, support may need the operation reference, release and configuration revision, failing stage and destination-result status. It may not need the full report, an authorization header or customer names. Agree those fields with the customer data and incident owners. Calling a field metadata does not establish that it is nonsensitive or permitted to leave the account.

Begin with a question the recipient can answer from the proposed representation. Can the vendor distinguish an authorization denial from a timeout? Can it identify the correct release and preserve an uncertain delivery? A packet that contains no protected data but also lacks these observations may be unsuitable for the agreed support duty. State that limit and choose a narrower diagnostic route instead of adding unrestricted debug capture.

Record the source scope: account, Region, event family, resource class and observation period. Keep actual identifiers in the approved restricted record. Repeated log-group names in different accounts are not equivalent evidence sources. A vendor operator should not infer the right source from a tenant display name, and an empty interval should not be used to prove that a report was never attempted.

The production telemetry governance paper owns field minimization, first persistence and derivative-copy review. This blog adds a narrower decision: how the customer-controlled source exposes enough evidence to vendor support, and who can authorize that exposure. A dedicated installation changes the account boundary, but it does not itself grant the vendor diagnostic rights.

2. Compare three access arrangements without changing the question

Customer-local diagnosis keeps ordinary investigation in the customer's approved tools. The vendor supplies the expected evidence question and receives an approved safe finding or packet. This can suit a customer that prohibits external log reading. Its limitations include the customer's operator availability, tooling knowledge and ability to produce the needed representation. The support agreement must acknowledge those dependencies rather than advertise autonomous vendor diagnosis.

A scoped cross-account view can let authorized vendor operators inspect selected observability sources without implementing the same raw-log export pipeline. CloudWatch cross-account observability links source and monitoring accounts within a Region; selected log groups and metric namespaces can limit sharing. Source accounts manage their links. Review the exact mechanism, selected data and reader permissions instead of generalizing this into unrestricted cross-Region access.

An approved extract creates a portable incident packet in a named destination. It can be useful when the vendor cannot have ordinary live access or when a bounded investigation needs a preserved observation. It also introduces a retained copy with a receiving owner, permitted readers and disposition duty. Extract approval should identify the fields, period and destination; it should not authorize every future support attachment or upload to another analysis service.

Customer-local diagnosis

Customer operator inspects the approved source and provides the agreed finding. Hold if required evidence cannot be produced; no implicit vendor read access.

Scoped cross-account view

Source owner approves the selected sharing boundary and reader scope. Review query, unmask and extraction capabilities separately; a view is not permission for arbitrary onward copies.

Approved extract

Named packet, destination and receiving owner. Record its completeness limits, retention and later disposition; source-link removal cannot recall the packet.

The alternatives can coexist for different purposes. A vendor might receive fleet health metrics while the customer keeps detailed security evidence local. An exceptional investigation can use a narrow extract without changing routine collection. Record each path independently. A choice that answers timing diagnosis does not automatically meet business-effect reconciliation or security investigation requirements.

3. Distinguish a shared view from a new collection destination

Do not use the phrase central observability for every mechanism. The selected sharing relationship, subscription destination and stored investigation packet have different copy and access implications. A monitoring account's permission to inspect a source does not settle the retention of query results saved in a ticket. Likewise, stopping a forwarder does not establish disposal of data already delivered to its destination.

CloudWatch Logs subscription-filter documentation describes forwarding to supported destinations. Such a destination requires its own capacity and failure review. For its Kinesis Data Streams example, AWS documents retry of throttled deliverables for up to 24 hours followed by dropping failed deliverables. Do not promise lossless incident evidence or apply that specific example as a universal delivery guarantee for every integration.

Where the organization uses CloudWatch Logs cross-account and cross-Region centralization, AWS describes rules replicating log data into a central repository through AWS Organizations. That is a separate mechanism from merely choosing a read arrangement for an independently governed customer. Do not assume a customer's account belongs to the vendor's organization or that this replication capability establishes the customer's consent.

Choose the actual path before reviewing claims such as data stays in the customer's account. Include query outputs, screenshots, downloaded results, attachments, notebooks and model-assisted analysis when they exist. A live view can still produce an extract through an authorized reader. A copy register should identify observed destinations, permitted uses and unresolved paths, not assert that no copies exist because the architecture diagram has no export arrow.

4. Review read, unmask and export as different authorities

Ordinary support might inspect a masked representation while a customer security investigator has a separately approved unmasked path. CloudWatch Logs data protection masks matching detected data at egress and identifies the separate logs:Unmask permission. Its documentation also says that enabling a policy does not mask events ingested before that time. A masked screenshot cannot prove raw data was never collected or that historical evidence is remediated.

Review the selected detectors and actual field formats. A customer-specific document fragment might not match a managed identifier. An error wrapper can put a prohibited value in free text instead of the expected field. Test with fabricated markers and inspect the relevant representation without using production payloads as test strings. A zero finding count is not a general sensitivity assessment.

Someone able to change a subscription, source link or collection policy can alter future exposure even if their current role cannot read every event. Include configuration authority in the access record. Separately identify who may download or share query results. Interface hiding alone cannot establish that a backend operation is denied; proposed checks should cover the API and export paths used in actual support.

When a customer withdraws a shared view, confirm the intended future access state through approved observation. Preserve the outstanding-copy register. Previous extracts can remain under a valid retention decision or require reviewed restriction and disposition. Do not claim all-copy deletion from a removed source link, nor broaden a role to bypass the customer's withdrawal during an urgent incident.

5. Diagnose a fictional missing operation receipt

Fictional packet P4 covers three expected report operations E1, E2 and E3 for tenant T4. The customer approves safe operation references, stage and release fields. The vendor receives receipts for E1 and E3; E2 is missing. The packet states that its source filter changed during the observation period. No production query, filter change or report delivery occurred in this example.

The offline coverage check reports three expected references, two received and missing E2. This is a count of supplied references, not a 67 percent delivery-success estimate. It cannot establish whether E2 was denied, dropped, excluded by the source filter, read under the wrong scope or successfully delivered without a receipt. The vendor should ask the authorized source or receiving owner for the particular missing evidence rather than repeat the operation.

Purpose and scope

P4 investigates report delivery for fictional T4. Approved packet contains safe references and stage/release fields, not report payloads.

Expected references

E1, E2 and E3. Supplied receipts cover E1 and E3; missing E2 remains explicit.

Coverage limit

Source filter changed in the period. No evidence yet resolves whether E2 was collected, visible to the reader or committed at the destination.

Customer authority

Customer source owner can arrange an approved local check. Receiving owner separately establishes business-effect state.

Review disposition

Hold the completeness claim and preserve E2's uncertainty. No automatic replay or privilege expansion.

A duplicate receipt should not disguise a missing operation. The companion rejects duplicate reference lists rather than treating their length as coverage. It also reports unexpected references, which can indicate a scope error in the supplied packet. These validations only inspect inert local inputs. They cannot authenticate a receipt, enforce a customer permission or infer that the selected source captured every relevant event.

6. Stop a leaking or unobservable path without losing the incident

STOP the proposed access or extract when its destination is unapproved, its scope cannot be established, its representation contains prohibited data or its reader unexpectedly sees another tenant. Use the organization's permitted containment procedure. Preserve the event period and safe references so the incident can continue through a narrower customer-local route. The article grants no permission to delete logs or alter account policy.

For unavailable telemetry, distinguish source collection failure, link or reader failure and destination ingestion failure. Record the gaps and the next authorized observer. Recovering a connection can restore new evidence without backfilling a lost interval. A healthier dashboard should not erase that coverage limitation. Reconcile uncertain business effects through their receiving authority rather than infer them from resumed telemetry.

When correcting a collection schema, inspect queued and retained representations separately. An old batch can contain fields that the new producer no longer emits. Restoring a prior component can also restore forbidden capture. Recovery should preserve useful permitted fields and the approved boundary, rather than automatically revert to unrestricted debug logging until an incident appears resolved.

Track historical exposure as a separate owned issue. Source minimization can improve future capture while old exports and attachments remain. Their approved disposition, access restriction and eventual evidence are distinct from restarting incident diagnosis. A partner completing its collection fix cannot declare customer data erased from all destinations it has not inspected.

7. Hand over the source, access and copy record

Create one record with the incident question, source scope, permitted fields, source controller and actual reader. Name the arrangement: customer-local query, scoped view or approved extract. Include read, unmask, export and configuration authorities separately. Add the observation period, policy or link revision, sampling and loss limits, receiving owner and known copies. Keep actual sensitive references restricted.

Define success with both diagnostic and boundary evidence. Can an operator using only the permitted packet identify the failing stage and preserve an uncertain effect? Do valid unintended readers fail at the actual enforcement boundary? Does the receiving owner know which extracts remain and what ends their use? An empty packet or administrator-only successful query does not answer these questions.

Use the sensitive telemetry audit playbook for the broader controlled audit and the redaction-before-collection article for upstream persistence. Before scheduling the next customer support review, choose one missing receipt and complete its source/access/copy record. Resolve the narrow evidence gap before adding another permanent telemetry destination.

Download the editable offline boundary records. The ZIP supplies the blank telemetry record and inert coverage fixture. No email, network transmission, provider request or cloud configuration is required.