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."

What you want to know	Available in exported logs	Reliability
Which operator the plan chose	Yes, full physical plan tree with operator names	Exact
Whether a stage has severe skew	Yes, via rounded record and byte counts	Reliable only across several orders of magnitude
Whether one task read 20% more than another	No, rounding hides differences within an order of magnitude	Not usable
Why an executor stopped	Yes, as a category such as out of memory or decommissioned	Exact category, no detail
What the exception was	No, message text, stack trace and exception class are removed	Not available
Which table was scanned	No, table names are redacted including your own	Not available

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

Limitation	Detail
Query date floor	Only SQL queries run after 11 August 2026
Job type	PySpark jobs not supported
Differential privacy	Queries using differential privacy cannot export logs
Query state	Terminal only; validation failures and pre-`STARTED` cancellations excluded
Bucket Region	Destination bucket must be in the same Region as the collaboration
Encryption	No KMS key parameter; the bucket's default encryption applies
Cancellation	An export cannot be cancelled once started

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

What did AWS Clean Rooms add on 11 August 2026?

AWS added export of privacy-enhanced Spark analysis logs for SQL analyses to an Amazon S3 bucket you own. The logs give insight into Spark execution details such as the physical plan, configuration settings, memory use and why executors stopped. AWS positions it as helping customers optimize and troubleshoot queries in a collaboration.

Why are the numbers in exported Clean Rooms logs wrong?

They are deliberately approximate. Record counts, byte volumes, spill sizes and peak memory are rounded down to an order of magnitude so an exact count cannot reveal the size of another member's data. AWS gives the example of a task that read 1,342 records reporting 1,000. Anything below 100 reports as 0.

Can I see the error message for a failed Clean Rooms query?

No. Error message text, stack traces and the underlying exception class name are all removed, because an error message can quote the value that caused it. The Spark error class is preserved for the query and the job. The reason a stage failed and the reason a task was killed are also redacted.

Which queries can export analysis logs?

Only SQL queries run after 11 August 2026 that reached a terminal state of SUCCESS, FAILED, CANCELLED or TIMED_OUT. PySpark jobs are not supported, queries using differential privacy are excluded, and queries that failed validation or were cancelled before reaching STARTED status cannot export logs.

Who is allowed to export the logs?

You need the CAN_EXPORT_QUERY_ANALYSIS_LOG member ability and you must be either the query runner or the payer of that query. Holding the ability alone is not sufficient. The AWS What's New post says collaboration owners grant the ability; the user guide says every collaboration member must approve the change request.

Do exported Clean Rooms logs need an IAM role?

No. AWS Clean Rooms writes exported logs using your own identity, so they land only where your existing permissions allow. Before the export begins, Clean Rooms writes a zero-byte validationSuccess object to the destination bucket to confirm write access, so permission problems fail immediately rather than in the background.

How are exported analysis logs encrypted?

AWS Clean Rooms does not accept a KMS key for log export. Exported logs use the destination bucket's default encryption configuration, so you configure the bucket to use a customer managed key before exporting. If the bucket already uses SSE-KMS with a customer managed key you do not have permission to use, the request fails immediately.

Can exported logs be used for cost or capacity dashboards?

No. Every count is rounded down to an order of magnitude and values under 100 report as zero, so summing them produces a total that is wrong by construction. Use them to spot skew across several orders of magnitude and to read plan shape and executor stop categories instead.

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.