Clean Rooms log export, 11 August 2026: every count is rounded down and stack traces are gone

Summary. On 11 August 2026 AWS Clean Rooms added export of Spark analysis logs for SQL queries, pitched as "greater optimization and troubleshooting capabilities". The exported logs are redacted, and the redaction rules are stricter than the announcement suggests. Record counts, byte volumes, spill sizes and peak memory are rounded down to an order of magnitude, so a task that read 1,342 records reports 1,000 and any measurement below 100 reports as 0. Error message text, stack traces and the underlying exception class name are removed entirely. Table names are redacted, including your own. Only queries run after 11 August 2026 are eligible, PySpark jobs are not supported, and neither are queries using differential privacy. The AWS What's New post says collaboration owners grant the export ability; the user guide says every collaboration member must approve the change request. Those are not the same requirement. The destination bucket must sit in the same Region as the collaboration, and on a collaboration created before 11 August 2026 there is nothing to export until the query is rerun.

What the export gives you

AWS Clean Rooms runs SQL queries on Apache Spark. Until the 11 August 2026 launch there was no way to see Spark execution detail for a query that ran inside a collaboration, because those logs sit on top of several members' data. Only queries run after 11 August 2026 qualify, and a query must reach one of four terminal states before its logs can be exported.

The user guide is direct about why raw logs were never an option: "A query runs across data contributed by several collaboration members. Raw Spark logs can therefore reveal information about another member's data, such as table names, storage locations, and data values. For that reason, AWS Clean Rooms does not give you the raw logs. Instead, it produces a redacted copy in which customer data and member metadata are redacted."

What survives redaction is a genuinely useful subset. The physical plan tree keeps its operator names, so HashAggregate, SortMergeJoin and Exchange are all visible and you can see the shape the engine chose. Spark configuration survives where the values are numbers, sizes or fixed keywords: driver and executor cores and memory, memory fractions, dynamic allocation, adaptive query execution settings, default parallelism, the shuffle partition count, the broadcast join threshold, the maximum partition size and the scheduler mode. Column names of scanned tables survive. And the reason each executor stopped survives as a category, which the guide calls "often the fastest way to explain why a query failed".

That is enough to diagnose a class of problem. It is not enough to diagnose an error.

The numbers are rounded down, on purpose

This is the part that changes how you use the feature, and it is documented on a separate page most readers will not open. From Understanding redacted logs: "Record counts, byte volumes, spill sizes, and peak memory measurements are rounded down to an order of magnitude, because an exact count can reveal the size of another member's data. A task that read 1,342 records reports 1,000. Measurements below 100 report as 0."

Then the caveat that follows it, which is the operative sentence for anyone planning to act on these figures: "Because every figure is rounded down, a task that reports 100 and a task that reports 1,000 might have read nearly the same number of records. Treat figures that differ by only one order of magnitude with caution; larger differences, such as 1,000 against 10,000,000, still reliably indicate skew."

Spark driver metrics for broadcasts, scans and writes do report values, and those are rounded down the same way. Per-task metrics attached to plan operators show no value at all, because the underlying per-task figures are removed; the guide points you to the stage view instead. And if a log record is one Clean Rooms does not recognise, "all of its text is replaced with [REDACTED], including its field names, and all of its numbers are replaced with zero."

So the honest framing of this feature is narrow and still worth having: it tells you where the work piled up, not what went wrong. The announcement's own example is consistent with that reading — "a third-party measurement provider collaborating with a publisher can identify an anomalous data skew". Skew is exactly the thing order-of-magnitude rounding still reveals.

No error text, no stack traces, no exception class

For failures rather than slowness, the redaction goes further than most teams will expect. The guide lists what is removed: "Error message text and stack traces – Because an error message can quote the value that caused the error, message text and stack traces are removed. The name of the underlying exception class is also redacted, because an exception thrown by a user-defined function carries a name that the query author chose. The Spark error class is preserved instead, for the query and the job. The reason a stage failed and the reason a task was killed are redacted as well."

You get the Spark error class. You do not get the message, the trace, the exception type, the stage failure reason or the task kill reason. A FAILED query therefore yields a category and a plan shape, and you reconstruct the rest by reasoning about the plan.

Two smaller redaction rules matter when you read the plan. Expressions are written as function calls rather than mathematical notation, so a comparison appears as EqualTo(#12, [REDACTED]) rather than (a = 5), and user-defined function names do not appear at all. Redacted values also take two forms: the literal string [REDACTED] inside the plan, and an empty field, blank string or absent value elsewhere. The guide notes both mean the same thing and that "empty and placeholder fields are normal and don't indicate a problem with the export."

Column names of scanned tables survive, but names the query creates do not. The reasoning is worth quoting because it explains an otherwise odd rule: "A name that a query creates is generated from the expression it names, and that generated name can contain a value from the query: SELECT 'confidential' produces a column named confidential."

Who can export, and the contradiction about who grants it

Three conditions must all hold before an export is possible, per the guide's prerequisites: your membership has the CAN_EXPORT_QUERY_ANALYSIS_LOG ability, you are the query runner or the payer of that query, and the query has reached a terminal state of SUCCESS, FAILED, CANCELLED or TIMED_OUT. The guide is explicit that the ability alone is not enough: "you can export logs only for queries that you ran or that you paid for."

The two AWS pages disagree on how the ability is granted. The What's New post says: "Collaboration owners grant a member the ability to export analysis logs when they create a collaboration or submit a change request to grant the ability to a member of an existing collaboration." The user guide's prerequisite says: "Your membership has the CAN_EXPORT_QUERY_ANALYSIS_LOG member ability. Every collaboration member must approve a change request to grant this ability."

Owner-grants and unanimous-approval are materially different for planning. On a collaboration with four members, the second reading means four approvals before anyone can debug a slow query. Assume the user guide is correct — it is the more specific and more recently maintained surface — and get the ability granted at collaboration creation rather than discovering the change request process during an incident. The same change request mechanism governs member abilities generally, which is also how the minimum aggregation threshold rules get set on an analysis rule.

The limits that will actually block you

The date floor is the one that catches people first. If you are investigating a query that has been slow since July, there is nothing to export. Rerun it.

The encryption rule is the one that catches people second, and it has a sharp edge. Clean Rooms does not accept a KMS key for log export; exported logs use the destination bucket's default encryption configuration. To get a customer managed key, you configure the bucket's default encryption before exporting. Separately, if the bucket already uses SSE-KMS with a customer managed key, you must hold permission to use that key or "the export request fails immediately".

The IAM model is unusually simple and worth noting because it removes a step teams expect: "You don't need to create an IAM role for log export. AWS Clean Rooms writes the exported logs using your own identity, so it writes the logs only where your own permissions already allow." Before the asynchronous work begins, Clean Rooms writes a zero-byte object named validationSuccess to the destination to confirm it can write there, so a permissions problem fails fast rather than silently in the background. Securing that bucket is explicitly your responsibility: block public access, and enable server access logging if you need a record of who read the exported logs.

Starting an export by API is one call:

            aws cleanrooms start-analysis-log-export \
    --membership-identifier <membership-id> \
    --analysis-id <protected-query-id> \
    --analysis-type PROTECTED_QUERY
          

It returns an export ID and a status of IN_PROGRESS, then redacts and copies in the background. The query details page carries an export history table with the status of each attempt.

How to actually use this

Treat exported logs as a skew and configuration tool, and keep your own instrumentation for everything else. Concretely: read the plan tree first and look for an Exchange or SortMergeJoin where one side is several orders of magnitude larger than the other, because that difference survives rounding. Read the executor stop categories next, because out-of-memory and decommissioned are exact even when the numbers are not. Read the Spark configuration third, since parallelism, shuffle partition count and broadcast join threshold all come through with real values and are usually what you would change anyway.

Do not build alerting or cost attribution on the record counts. A figure that reports 0 may be anything under 100, and two tasks reporting 100 and 1,000 may be near-identical. Any dashboard that sums these numbers produces a total that is wrong by construction.

The tool answers where the work went. It will not tell you what threw.

India-specific considerations

For Indian teams running Clean Rooms collaborations between a brand and a publisher or a measurement partner, the redaction model works in your favour under the Digital Personal Data Protection Act 2023, because the export cannot carry another member's data values, table names or storage locations out of the collaboration. The obligation that does land on you is the destination bucket. AWS states that securing it is the exporter's responsibility, so treat it as a data store under your own retention and access policy, block public access, and turn on server access logging if you need to show who read the files.

The same-Region rule is an operational constraint worth checking early: a collaboration in ap-south-1 must export to an ap-south-1 bucket, and cross-Region export is not supported. If your analytics tooling and your Spark History Server instance sit in another Region, plan the read path rather than the write path.

What is still unknown

AWS points to the Clean Rooms quotas page for "the number of exports that can run at the same time", and that concurrency figure is the one number a team automating exports would want in advance. AWS has also not documented whether PySpark job support is planned, nor resolved the owner-grants versus unanimous-approval discrepancy between the announcement and the user guide. Verify the approval path against your own collaboration's change request flow before you promise anyone a debugging capability.

FAQ

How eCorpIT can help

eCorpIT builds and operates data platform engineering for teams running Spark workloads and privacy-constrained analytics, including Clean Rooms collaboration design, member ability planning and the external instrumentation you still need when the exported logs cannot carry an error message. We are a CMMI Level 5 and ISO 27001:2022 certified organisation with senior-led teams in Gurugram. If a Clean Rooms query is slow and the logs are not telling you why, talk to us.

References

1. AWS Clean Rooms supports exporting privacy-enhanced analysis logs for SQL, AWS What's New, 11 August 2026

1. Exporting query analysis logs, AWS Clean Rooms User Guide

1. Understanding redacted logs, AWS Clean Rooms User Guide

1. Considerations and limitations for log export, AWS Clean Rooms User Guide

1. How redacted logs differ from standard Spark logs, AWS Clean Rooms User Guide

1. Change requests and member abilities, AWS Clean Rooms User Guide

1. AWS Clean Rooms Differential Privacy, AWS Clean Rooms User Guide

1. Quotas for AWS Clean Rooms, AWS Clean Rooms User Guide

1. StartAnalysisLogExport, AWS Clean Rooms User Guide

1. What is AWS Clean Rooms, AWS Clean Rooms User Guide

1. Digital Personal Data Protection Act 2023, Ministry of Electronics and Information Technology, Government of India

Last updated: 22 August 2026.