Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Quick Suite features unusable when identity region differs from feature-available region

0

Cannot use Quick Suite features with Athena data sources when identity region differs from Quick Suite-supported region

Summary

I have an Amazon Quick (Enterprise) account with identity region in ap-southeast-1 (Singapore). Quick Suite features (Flows, Research, Automate, Index, Desktop, Chat agents) are only available in regions like us-east-1. I can access the Quick Suite UI at us-east-1.quicksight.aws.amazon.com and successfully create data sources, datasets, and topics there — but queries fail at runtime. The same data source, dataset, and topic created in ap-southeast-1 works immediately.

The core issue: QuickSight does not allow Athena query execution from a data source created in a region different from the identity region. Since Quick Suite features only exist in us-east-1 (and a few others) but my identity region is ap-southeast-1, I cannot use Quick Suite features with Athena-backed data.

Steps to Reproduce

  1. Have an existing QuickSight Enterprise account with identity region = ap-southeast-1
  2. Create Iceberg tables in us-east-1 Glue catalog with data in S3
  3. Verify tables work: run JOIN query from Athena CLI in us-east-1 — succeeds, returns 45K+ rows
  4. Navigate to us-east-1.quicksight.aws.amazon.com — Quick Suite UI is visible (Flows, Research, Topics, Extensions, etc.)
  5. Create an Athena data source in us-east-1 — succeeds (status: CREATION_SUCCESSFUL)
  6. Create a dataset with Custom SQL joining multiple tables — succeeds
  7. Create a Q Topic on that dataset — succeeds
  8. Execute a query (via Topic or dataset preview) — FAILS:
COLUMN_NOT_FOUND: Column 'store_id' cannot be resolved or requester 
is not authorized to access requested resources
sourceType: ATHENA
  1. Create the exact same data source, dataset, and topic in ap-southeast-1 — works immediately, returns data

Key Finding

The tables exist in both regions' Glue catalogs. Both are queryable from their respective Athena CLIs. The only variable is where the QuickSight data source/dataset is created:

QuickSight assets created inTables in GlueAthena CLI worksQuickSight query works
us-east-1✅ us-east-1 Glue✅ Yes❌ No — COLUMN_NOT_FOUND
ap-southeast-1 (identity region)✅ ap-southeast-1 Glue✅ Yes✅ Yes

Conclusion: QuickSight can only execute Athena queries when the data source is created in the identity region. Data sources created in other regions fail silently at runtime.

Why This Is a Problem

This creates an impossible situation for customers whose identity region is marked "QuickSight-only" (no Quick Suite features):

  • Quick Suite features (Flows, Automate, Research, Index, Desktop) → only in us-east-1 and select regions
  • Athena data source execution → only works in identity region (ap-southeast-1)
  • Cannot create a second Quick subscription in the same AWS account in a different region
  • Cannot migrate identity region after account creation

Result: I cannot use any Quick Suite feature that depends on data connectivity (Topics with NL queries, Flows that reference datasets, Automate triggers on data thresholds).

What I've Tried

  1. ✅ Created Glue tables in us-east-1 → queries fail from QuickSight
  2. ✅ Created Glue tables in ap-southeast-1 → queries work from QuickSight
  3. ✅ Granted S3 cross-region access to QuickSight service role → no change
  4. ✅ Verified Athena CLI works in both regions independently → both succeed
  5. ❌ Tried creating a new Quick subscription in us-east-1 → "one subscription per account" limit

Misleading Behavior

  • QuickSight allows creation of data sources, datasets, and topics in us-east-1 without any warning
  • The error only appears at query execution time — not at creation time
  • The error message COLUMN_NOT_FOUND is misleading — the column exists, the issue is cross-region execution
  • The Quick Suite UI is fully visible and interactive in us-east-1, giving no indication that it won't work with data

Environment

  • Identity Region: ap-southeast-1
  • Edition: Enterprise
  • Authentication: IDENTITY_POOL (IAM)
  • Quick Suite UI accessible from: us-east-1
  • Athena workgroup: primary (both regions)
  • Tables: Iceberg format in Glue catalog (both regions)
  • Data: S3 bucket in us-east-1

Requested Resolution

  1. Fix the core issue: Allow QuickSight to execute Athena queries in the region where the data source was created, not only the identity region
  2. Or: Enable Quick Suite features in all regions where QuickSight Enterprise exists (including ap-southeast-1)
  3. Or: Provide an identity region migration tool for existing accounts
  4. Or: Allow multiple Quick subscriptions per account in different regions
  5. Immediate: Surface a clear error at data source/dataset creation time: "Your identity region is ap-southeast-1. Data sources must be created in that region for queries to execute."
  6. Immediate: Change the runtime error from COLUMN_NOT_FOUND to an explicit region mismatch message

Tags: Quick Suite, Athena, cross-region, identity region, Topics, Q, data source, Glue catalog, COLUMN_NOT_FOUND

Topics
Analytics
Tags
Amazon Quick Sight
Language
English

asked a month ago69 views

2 Answers
1

You are correct: this is a architectural limitation within QuickSight, not a simple configuration or IAM issue.

When your QuickSight Identity Region is tied to ap-southeast-1, the underlying execution engine and service integrations remain anchored there. Even if you access the Quick Suite UI in us-east-1, successfully create the data source, and ensure cross-region IAM policies are in place, QuickSight's backend routing fails to correctly pass the execution context to Athena in the non-identity region. The COLUMN_NOT_FOUND message is a phantom error masking this cross-region integration failure.

Since AWS does not provide self-service tooling to decouple or migrate the Identity Region, viable resolutions are:

  • AWS Support Intervention: Open a technical support case and explicitly request either a manual migration of your QuickSight Identity Region to us-east-1, or an exception to the "one subscription per account" limit so you can provision a native us-east-1 instance.

  • Data Pipeline Workaround: Replicate the required Iceberg/Glue metadata and S3 data into ap-southeast-1, or use Athena Federated Query to bridge the gap, ensuring the QuickSight data source is natively created and executed in your Identity Region.

See:

EXPERT

answered a month ago

0

I understand you're experiencing a significant limitation with Amazon QuickSight where Quick Suite features are unavailable in your identity region (ap-southeast-1), but creating data sources in regions where Quick Suite is available (like us-east-1) results in query execution failures.

Based on the available information, Amazon Q in QuickSight Generative BI features are indeed supported in ap-southeast-1 (Asia Pacific Singapore), along with several other regions including us-east-1, us-east-2, us-west-2, and various regions in Europe and Asia Pacific. However, some regions like ca-central-1 (Canada Central), eu-north-1 (Europe Stockholm), eu-central-2 (Europe Zurich), and sa-east-1 (South America São Paulo) do not have scenario support available.

The cross-region query execution issue you're describing appears to be a fundamental architectural constraint where QuickSight requires data sources to be in the same region as your identity region for successful query execution. This creates a challenging situation when Quick Suite features aren't fully available in your identity region.

For your specific situation, I recommend:

  1. Verify Quick Suite availability: Double-check that the specific Quick Suite features you need (Flows, Research, Automate, etc.) are actually unavailable in ap-southeast-1, as the region does support Amazon Q in QuickSight Generative BI features according to AWS documentation.

  2. Contact AWS Support: Given the complexity of this cross-region limitation and its impact on your ability to use Quick Suite features, I strongly encourage you to work with AWS Support through the AWS Support Center (https://console.aws.amazon.com/support/). They can provide specific guidance on your account configuration and may have solutions or workarounds not publicly documented.

  3. Review your Support plan: If you need faster response times for this business-critical issue, consider reviewing your AWS Support plan options to ensure you have the appropriate level of support for your needs.

The behavior you're describing—where data source creation succeeds but query execution fails with misleading error messages—represents a significant user experience issue that AWS Support should be made aware of, even if the underlying architectural constraint cannot be immediately changed.
Sources
AWS Regions, websites, IP address ranges, and endpoints - Amazon Quick

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content