as anyone else seen ICEBERG_CURSOR_ERROR: Failed to read Parquet file from Athena engine v3 against Apache Iceberg tables managed by Amazon Security Lake (the OCSF v2.0 source tables in amazon_security_lake_glue_db_<region>.amazon_security_lake_table_<region>_<source>_2_0), where the offending files read cleanly via pyarrow?

Looking for: AWS confirmation of a known regression, or peer customers seeing the same symptom, or a customer-side workaround that doesn't require Lake Formation DDL access on Security-Lake-managed tables.

Setup

• Region: us-east-1
• Athena workgroup engine: v3
• Security Lake delegated admin account ingesting all 7 OCSF v2.0 AWS sources: sh_findings, vpc_flow, s3_data, route53, waf, lambda_execution, cloud_trail_mgmt
• Tables are Iceberg (format-version 2), Lake-Formation-managed — we cannot ALTER TABLE, OPTIMIZE, or VACUUM them
• Dashboards on Athena have been working fine for months; failures started recently and are spreading

Symptom

Athena queries that read the parquet body (column projection, GROUP BY on data columns, UNNEST) over a window that includes one or more affected files fail with ICEBERG_CURSOR_ERROR. Manifest-only queries succeed because they don't open parquet bodies.

Reproduction shape:

-- Manifest-only — SUCCEEDS (0 bytes scanned)
SELECT COUNT(*) FROM <sh_findings_table>;

-- Body read, narrow window — SUCCEEDS today (affected files happen to be older than 7 days)
SELECT severity, COUNT(*)
FROM <sh_findings_table>
WHERE region = 'us-east-1'
  AND time_dt > current_timestamp - INTERVAL '7' DAY
GROUP BY severity;

-- Body read, wider window — FAILS
SELECT severity, COUNT(*)
FROM <sh_findings_table>
WHERE region = 'us-east-1'
  AND time_dt > current_timestamp - INTERVAL '30' DAY
GROUP BY severity;
-- ICEBERG_CURSOR_ERROR: Failed to read Parquet file:
-- s3://<security-lake-bucket>/aws/SH_FINDINGS/2.0/region=us-east-1/accountId=<account>/eventDay=20260424/<file>.gz.parquet

The pattern is consistent across all 7 OCSF v2.0 sources, across multiple eventDay partitions, and across multiple producer accounts in our org. Athena reports only the first failing file per query and aborts, so the actual count of affected files is likely larger than what error-message enumeration finds.

What I've validated

The parquet files themselves are fine. Downloaded a representative sample of offending files from S3 and read them with pyarrow on Ubuntu 24.04 LTS. They open in milliseconds with valid OCSF v2.0 schema and row counts that match the asl_rows value in S3 object metadata. Schema metadata on every file shows writer.model.name = 'avro' and a populated parquet.avro.schema key, indicating Security Lake's Avro→Parquet compactor path.

The Iceberg metadata is fine. Downloaded the current metadata.json for one of the affected tables:

• format-version: 2
• 1 partition spec, 4 fields — asl_version (identity), region (identity), accountid (identity), time_dt_day (day-transform on time_dt)
• Properties: amazon_securitylake_append_strategy = "append", history.expire.max-snapshot-age-ms = 21600000 (6h), write.metadata.delete-after-commit.enabled = true
• Manifests reference the affected parquet files coherently

The compactor is actively producing affected files. S3 LastModified on offending parquet objects clusters in the last 1–12 hours and re-touches old eventDay partitions. Lifecycle rule is SecurityLake_Generated_Rule_<source>_2.0 with ServerSideEncryption AES256, confirming Security-Lake-managed writes (not user uploads).

What I've ruled out

• Parquet corruption — pyarrow proves the bytes are valid
• Iceberg metadata corruption — metadata.json downloads, parses, and lists the affected files coherently
• Schema drift on the consumer side — we don't write to these tables and our queries match the published OCSF v2.0 schema
• Single-day blip — affects 7 sources, multiple accounts, multiple eventDays, growing daily
• Engine version misalignment — engine v3 is the only option in our workgroup
• Tunable read settings — Lake Formation blocks ALTER TABLE ... SET TBLPROPERTIES ('read.parquet.vectorization.enabled' = 'false') on Security Lake tables

What I've tried for workaround

• OPTIMIZE table REWRITE DATA USING BIN_PACK — blocked by Lake Formation
• Snapshot time travel FOR TIMESTAMP AS OF — 6h snapshot retention doesn't reach a pre-failure state
• Direct S3 rewrite via pyarrow — risky for compliance, and the compactor would overwrite on the next run
• Per-query time_dt-range exclusion of bad partitions — works briefly, brittle as new affected files keep appearing

The actual questions

1. Has AWS acknowledged a regression in engine v3's Iceberg-aware vectorized parquet reader against Security Lake's Avro→Parquet compactor output format (writer.model.name = 'avro')?
2. For Security-Lake-managed tables where customers cannot run DDL, is there a documented customer-side workaround other than registering the same S3 parquet files in a separate Hive-style external table (which works, but is operationally messy)?
3. Is anyone else seeing this, and roughly when did it start on your account?

Happy to provide pyarrow output, S3 HEAD output, or full Athena QueryExecutionId traces in a follow-up.