Over the last year, I built some analyses pulling data from AWS cur via direct query and everything looked fine till two days ago.
Now, while the corresponding dashboards still work and show data as usual, the source analyses look broken and I’m getting the error “The data source or dataset was deleted or became unavailable while Amazon Quick was ingesting the data into SPICE. You can import the data to try again”.
The data source has not been deleted and I can still see its data in the dataset preview. What is happening?
Thank you for your post and bringing this to attention.
Just out of curiosity, was this outcome in response to any action taking place on your end? Was there any edits made to the dataset, did you try adjusting it from Direct Query to SPICE?
Thanks for the additional details — the fact that recreating the dataset from scratch still fails, and that the dashboard continues to work while the analysis is broken, is a very useful clue.
This pattern is consistent with a few known scenarios:
Most likely cause: CUR dataset/delivery change AWS Cost and Usage Reports (CUR) recently migrated to CUR 2.0 (also known as Data Exports). If your CUR was set up under the legacy CUR delivery method, AWS may have made a backend change to the underlying S3 path or Athena table structure that broke the data source connection for new ingestions — while cached/SPICE data in your dashboards still appears fine because it’s reading from the last successful refresh.
Things to check:
Verify the data source itself — In QuickSight, go to Datasets → [your dataset] → Edit dataset → Data source and confirm the data source is still valid. Try clicking Validate connection to confirm QuickSight can still reach it. Even if the dataset preview shows data, the underlying data source credentials or endpoint may have silently expired or changed
CUR delivery status — Go to AWS Billing Console → Cost & Usage Reports and confirm your report is still actively delivering. Check if the S3 path or Athena database/table name has changed (especially if you were on legacy CUR and it migrated to CUR 2.0)
Athena table availability — Run a test query directly in Athena against the table your QuickSight dataset points to. If the table was recreated as part of a CUR migration, the schema or partition structure may have changed
S3 permissions — Verify the QuickSight IAM role still has s3:GetObject and s3:ListBucket permissions on the CUR S3 bucket path. Sometimes bucket policies change without notice when CUR delivery is reconfigured
SPICE ingestion logs — In QuickSight, go to Datasets → [your dataset] → Ingestion history and check the detailed error message on the failed ingestion — it often contains the exact underlying cause (e.g. table not found, access denied, schema mismatch)
Why does the dashboard still work? Dashboards connected to SPICE display the last successfully ingested data. The error only surfaces when QuickSight attempts a new ingestion/refresh — so the dashboard looks fine but the analysis (which may be triggering a live or fresh query) surfaces the error.
I tried what you suggested, but I found nothing “unusual”, to be more specific:
Verify the data source itself > connections is still valid and SSL is enabled
CUR delivery status > the status is healthy and I am still working using a legacy cur
Athena table availability > legacy cur was not migrated
S3 permissions > cur was not reconfigured
SPICE ingestion logs > I could not find it and checking it seems that this is not available when datasets are configured to use direct queries (not SPICE)
Just checking back in since this thread hasn’t received a response in a while. Were you able to find a solution yourself in the meantime or are you still encountering the same issue? Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!
Hello @GaBon, out of curiosity, if you go into the dashboard and use the “Save as analysis” option to create a fresh analysis, are you seeing the same errors?
I know pushing dashboard updates from an analysis that isn’t the source analysis is much easier now, so maybe you can bypass the issue you are facing. It might be something broken in the JSON of the original analysis if the dashboard is still functioning without a problem.
I managed to resolve this by switching to the legacy UI and creating the dataset from scratch by using the same SQL query. It appears to be an issue with the new UI.