← Platform Foundations

▶ Play from here · 202 min

Starts this lesson and continues through 27 more to the end of the course.

Regions, and where your assets actually live

The most Region-scoped service you will use

Almost everything in Quick Sight is Region-scoped, and the console works hard to hide that from you. Datasets, dashboards, analyses, data sources, SPICE capacity — all of it belongs to one Region, and none of it is visible from another.

The result is a specific, recurring conversation: "The dashboard's gone." It isn't. You're in us-west-2 and it's in us-east-1.

Two Region selectors that ignore each other

This is documented, unambiguous, and still catches everyone (Configure SPICE memory capacity, verified 2026-08-09):

"The AWS Management Console and the Amazon Quick console each have an AWS Region selector that works independently from the other. Changing the selected AWS Region in the AWS console doesn't change the AWS Region in Amazon Quick."

And:

"If you open Amazon Quick from the AWS Management Console, Amazon Quick opens in the account that you used to sign in to that console. However, it opens in the last AWS Region that you selected in Amazon Quick."

Read that carefully. Opening the product from the console does not put you in the console's Region. It puts you in whatever Region you last used inside Quick — possibly weeks ago.

⚠️ There's a stronger warning for the plain URL:

"If you open Amazon Quick using the http://quicksight.aws.amazon.com URL, Amazon Quick automatically selects your account and AWS Region. You can't view your AWS account from Amazon Quick. We recommend using a different method to open Amazon Quick when you want to work with SPICE capacity."

AWS telling you to stop using an entry point is rare. Take it seriously: for anything that spends money or changes shared state, don't arrive via that URL.

How to know where you are, in two seconds

Read the Region out of the URL. The docs give the pattern:

https://us-east-1.quicksight.aws.amazon.com/sn/admin
        ^^^^^^^^^

The profile menu also shows the Region's friendly name — "N. Virginia" for the URL above — and lets you switch.

From the CLI, always pass --region explicitly. AWS says so directly:

"The AWS Region isn't always required, and if you don't provide it, the AWS CLI uses your default AWS Region from your AWS configuration. We recommend that you always explicitly provide the AWS Region."

That's not pedantry. A create-ingestion against the wrong Region returns ResourceNotFoundException (HTTP 404) — which reads like "the dataset is gone" and sends you looking for the wrong problem entirely. Region is the first thing to check on any 404 (Q2, lesson 3).

The gap between API Regions and console Regions

Here's a finding worth having. The AWS General Reference publishes two separate tables for this service: "QuickSight" service endpoints, and "QuickSight Websites".

They do not contain the same Regions. Verified 2026-08-09, these Regions have a documented API endpoint but appear in no entry in the websites table:

I am reporting the documentation gap, not asserting what it means — AWS does not explain the difference between the two tables, and I could not verify from the pages fetched whether these Regions genuinely lack a console entry point or are simply missing from the second table.

What to do with that: if you are planning a deployment in one of those seven Regions, verify the console experience before you commit, rather than assuming parity with us-east-1. And if you need certainty, it's a precise, easily-answered question for AWS Support: "Is there a console web endpoint for Quick Sight in sa-east-1? The websites table in the General Reference does not list one."

Note also the two GovCloud Regions use the quicksight.us-gov-*.amazonaws.com form in both tables, rather than the <region>.quicksight.aws.amazon.com pattern used by commercial Regions.

What is and isn't Region-scoped

"Each AWS account can have a separate Amazon Quick subscription and can be used in multiple AWS Regions."

So: one subscription, one set of users, many Regions — and assets that don't cross between them.

⚠️ There is no documented "move a dashboard to another Region" operation. The mechanism you'd actually use is asset export and import via the API (covered in Q7), which is a build-and-promote process, not a migration button. Treat Region choice as expensive to change.

Choosing a Region

In priority order:

1. Where your data is. Direct query across Regions means cross-Region latency on every visual; SPICE ingestion across Regions means moving your data on every refresh. Co-locate with Athena, Redshift, RDS, or S3.
2. Where your capacity is. Signup asks you to "choose the AWS Region that you want to use for your initial data storage capacity, called SPICE" — the default lands there.
3. Data residency obligations. Usually a constraint rather than a choice.
4. Where your users are. Real, but the smallest factor of the four — dashboard rendering is far less latency-sensitive than query execution.

The opinionated default: put Quick Sight in the same Region as your warehouse, and accept that users elsewhere have a slightly slower page load. The alternative — fast page loads over slow cross-Region queries — is worse in every way that users actually notice.

Check yourself

1. You open Quick from the AWS console while the console is set to eu-west-1. Which Region does Quick open in?
2. create-ingestion returns HTTP 404 ResourceNotFoundException. First hypothesis?
3. A colleague says the dashboard has disappeared. What do you ask them to read out?
4. You need the same dashboard in us-east-1 and eu-west-1. What's the mechanism?
5. Your warehouse is in sa-east-1. What should you verify before committing?

Answers

1. Not necessarily eu-west-1. It opens in the last Region you selected inside Quick. The two selectors are independent.
2. The wrong Region — far more often than a wrong dataset ID. Always pass --region explicitly.
3. The Region out of their URL: https://<region>.quicksight.aws.amazon.com/.... Or the Region name in the profile menu.
4. Build it twice, promoted via asset export/import through the API (Q7). There is no documented move-between-Regions operation; assets are Region-scoped.
5. That a console web endpoint exists there. sa-east-1 has a documented API endpoint but appears in no entry of the "QuickSight Websites" table in the AWS General Reference. Confirm with AWS Support before committing.

Teaching this section

• Demo first, explain second. Change the Region in the AWS console, open Quick, and let the room watch it land somewhere else. It's ten seconds and it inoculates people permanently.
• Make everyone read their own URL out loud. In a group of ten, two are usually in a Region they didn't intend.
• Good discussion: "Which Region should our production account be in, and what does that cost the people in the other office?" The right answer — co-locate with the data — is unpopular and correct.
• Watch for: the assumption that a dashboard can be moved. Establish early that Region choice is a build-and-promote decision, not a setting.
• Timing: 15 min presented, 15 discussion and hands-on.