Quick Desktop

[risgpt]

Setting Up Amazon Quick on Desktop When Your IAM Identity Center Home Region Is Not us-east-1

Audience: AWS administrators (AWS Organizations, IAM Identity Center, Amazon Quick / QuickSight)
Scenario covered: Org-level IAM Identity Center home region = ap-south-1 (BOM); an existing Amazon Quick (Web) subscription already homed in ap-south-1 in the same account; goal is to run Amazon Quick on Desktop plus indexing/Knowledge features, which require the Quick account identity region to be us-east-1 (IAD).
Last fact-checked: 6 June 2026 against official AWS documentation (links inline).

Preview-era note. Amazon Quick on Desktop and several of these flows are evolving. Region behavior (notably the hard us-east-1 requirement) and CLI parameters can change. Always re-verify against the linked AWS docs before executing, especially anything destructive.

---

0. TL;DR / Decision Summary

You have two SSO mechanisms for Amazon Quick on Desktop. They solve different problems and are not mutually exclusive. For the common goal of running both Web and Desktop under one identity, Path A (IAM Identity Center) is the recommended, unified approach — so it is presented first.

	Path A — IAM Identity Center (IdC) (unified Web + Desktop)	Path B — OIDC Identity Federation (direct to Okta / Entra / Ping)
What it authenticates	Org-wide identity, SCIM provisioning, group sync, trusted identity propagation — governs Web and Desktop both	Desktop app sign-in via your IdP (OIDC + PKCE) — Desktop only
Touches IdC home region / KMS?	Yes — needs correct KMS key policy in the relevant Region(s)	No — sidesteps the IdC CMK/region problem (for Desktop)
Best when	You want one identity model for Web + Desktop, SCIM auto-provisioning, group-based authZ, Q identity propagation	You only need Desktop SSO and Web auth is handled separately or not a concern
Effort	Higher; replication + cross-region KMS	Low; per-account, no org infra change

Key fact (official): Regardless of which SSO path you choose, the Amazon Quick account’s home (identity) region must be us-east-1 for the Desktop app. The Desktop app connects to us-east-1 for both authentication and inference. Quick on the web can run in other Regions, but Desktop cannot. Source: Setting up Amazon Quick on desktop for enterprise deployments.

Consequence for your case: Because your existing Quick Web subscription is homed in ap-south-1, and the Desktop app needs the account identity region to be us-east-1, you cannot simply “add Desktop” to the ap-south-1 subscription. You must stand up the Quick account in us-east-1 (see Section 5 for the subscription-conflict handling and asset migration).

Recommended for “Web + Desktop, same users”: Go Path A (IdC). One identity model covers both surfaces; you accept the one-time cross-region KMS work. Use Path B (OIDC federation) only when you specifically want a lightweight Desktop-only bolt-on.

---

1. Background: Why This Is Hard

1.1 The region anchors

• IAM Identity Center has a single home Region per org (yours: ap-south-1). IdC data is encrypted with a customer-managed KMS key (CMK).
• Amazon Quick on Desktop requires the Quick account identity region = us-east-1.
• When these differ, the console sign-up/SSO-app flows try to operate against the IdC home Region, and the KMS decrypt call lands in a Region where either the key or its key policy doesn’t permit the calling service.

1.2 The KMS insight most people miss

Two different flows call KMS as different principals, and a multi-Region KMS replica key does NOT inherit the primary key’s key policy — each replica has its own independent policy that you must set.

Flow	Principal hitting KMS	Where the KMS call lands
sso:CreateApplication (IdC registers the Quick app)	sso.amazonaws.com	Region where SSO processes the request
quicksight:CreateAccountSubscription → IdentityStore read	quicksight.amazonaws.com (via identitystore)	Region you target (us-east-1 when forced)

Rule of thumb: Whatever Region the operation runs in, that Region’s KMS key must permit the calling service principals: sso.amazonaws.com, identitystore.amazonaws.com, and quicksight.amazonaws.com.

This is exactly why the original errors appeared, e.g.:

Service: sso.amazonaws.com is not authorized to perform: kms:Decrypt on the resource
associated with this ciphertext because the resource does not exist in this Region ...

quicksight.amazonaws.com is not authorized to perform: kms:Decrypt ...
(Service: Identitystoreinternal, Status Code: 400 ...)

The first is the SSO application-registration path; the second is the IdentityStore read path during subscription creation. Both are KMS key-policy gaps in the Region where the call landed.

1.3 The two senses of “OIDC” (why Path A vs Path B feels contradictory)

A common confusion: “There’s always authentication — whether via IdC or OIDC — so what’s the real difference?” The key is that the Desktop app always speaks OIDC as a protocol, but the identity authority on the other end differs. “Uses OIDC” does not mean “bypasses IdC,” because IdC can itself be the OIDC provider.

	Path A — IdC as the identity authority	Path B — IdP as the OIDC provider
Who Desktop authenticates against	IAM Identity Center	Your IdP directly (Okta/Entra/Ping)
Is an app created in IdC?	Yes. Subscribing with --authentication-method IAM_IDENTITY_CENTER runs sso:CreateApplication, registering Quick as an app in IdC. Users see/select it in the IdC access portal after signing in.	No. The “Extension access” entry holds your IdP’s OIDC endpoints. IdC is not involved.
Governs Web UI too?	Yes — Web and Desktop both	No — Desktop only
Touches cross-region KMS?	Yes	No

So your observation — “when we subscribe to Quick it creates an app in IdC which users select after signing in” — is exactly right for Path A (IdC). It is not true for Path B, where Desktop talks straight to your IdP and no IdC app exists. Both are “OIDC”; the difference is who is the authority.

1.4 The identity region anchors more than auth — it also anchors indexing/Knowledge/Spaces

The Quick account’s identity (home) region is fixed at subscription creation. It governs not just sign-in but also where index/Knowledge/Spaces features can initialize. The Web UI region selector only changes where you view/operate — it does NOT move the identity region. This is why selecting us-east-1 in the Web UI while the account identity is still ap-south-1 fails with Unable to initialize Quick index in this region: the backend can’t bootstrap an index in a region that isn’t the identity anchor. Desktop and indexing both require identity region = us-east-1; neither can be satisfied by toggling the region picker.

This is well-documented behavior for the underlying QuickSight engine (verified 6 June 2026):

• “When initially setting up the account, the identity region is selected. Further when creating namespaces, they have to be created in the selected identity region.” — QuickSight Community
• “…there is no way to change identity region in QuickSight other than dissolving the QuickSight account and setting up afresh in the default region required.” — QuickSight Community
• User/group/namespace operations called from a non-identity region fail with Operation is being called from endpoint <X>, but your identity region is <Y>. Please use the <Y> endpoint (example).

The index/Spaces failure is the same class of region-anchor mismatch surfacing through the Knowledge/Spaces feature. See Section 5 (migration) and the Section 7 troubleshooting row.

1.5 Flow diagram — how the pieces fit

                              ┌─────────┐
                              │  USER   │
                              └────┬────┘
                  ┌────────────────┴────────────────┐
                  │                                  │
           ┌──────▼──────┐                    ┌──────▼──────┐
           │ DESKTOP app │                    │   WEB UI    │
           │ OIDC + PKCE │                    │ (region     │
           │ loopback    │                    │  selector = │
           │ :18080      │                    │  VIEW ONLY) │
           └──┬───────┬──┘                    └──────┬──────┘
              │       │                               │
   Path A     │       │  Path B                       │ Path A
  (unified)   │       │  (Desktop                     │ (base auth method)
              │       │   only)                       │
              │       └───────────────┐               │
              │                       │               │
       ┌──────▼───────────────┐  ┌─────▼───────┐      │
       │ IAM IDENTITY CENTER  │  │  YOUR IdP   │      │
       │ app via              │  │ Okta/Entra/ │      │
       │ sso:CreateApplication│  │ Ping        │      │
       │ home=ap-south-1      │  │ token by    │      │
       │ + replica us-east-1  │  │ email;      │      │
       └──────┬───────────────┘  │ NO IdC app  │      │
              │                  └─────────────┘      │
              │◄───────────────────────────────────────┘
       ┌──────▼───────────────┐
       │ MULTI-REGION KMS     │
       │ ⚠ replica policy     │
       │   NOT inherited      │
       └──────────────────────┘

   ────────────────────────────────────────────────────────────
   IDENTITY-REGION ANCHOR (applies to BOTH paths):
     • Desktop app          → requires identity region = us-east-1
     • Index/Knowledge/Spaces → initializes ONLY in identity region
     • Web region selector   → changes VIEW only, never moves identity
     • To move it            → re-subscribe in us-east-1 (Section 5)
   ────────────────────────────────────────────────────────────

Reading the diagram:

• Path A (recommended): Web and Desktop → IdC → multi-Region KMS. One unified identity; the us-east-1 replica key policy must be set (it isn’t inherited).
• Path B: Desktop → your IdP directly. No IdC app, no KMS, Web unaffected (Web keeps its own base auth method).
• Identity-region anchor (both paths): Desktop and index/Knowledge/Spaces both demand identity region = us-east-1. The Web region selector does not move it — only re-subscribing in us-east-1 (Section 5) does.

---

2. Prerequisites

• AWS Organizations with an org-level IAM Identity Center instance (home Region ap-south-1).
• IAM Identity Center multi-Region replication configured with a replica in us-east-1. (This is the newer IdC multi-Region capability; the home Region stays ap-south-1, with a replica in IAD.)
• A multi-Region customer-managed KMS key: primary in ap-south-1, replica in us-east-1.
• Administrator credentials in the management or delegated-admin account.
• AWS CLI v2 (recent enough to expose --iam-identity-center-instance-arn on quicksight create-account-subscription).
• For Path B: access to your IdP (Okta and/or Entra) to register an OIDC public client.

Least privilege caveat. The KMS statements below scope by aws:SourceAccount and (where applicable) kms:ViaService and encryption-context keys. Avoid kms:* for service principals. Keep the existing key-administrator and root statements intact.

---

3. Path A — IAM Identity Center + Multi-Region Replication (Recommended; unified Web + Desktop)

Use this when you want one identity model across both Web and Desktop, or when you need IdC’s capabilities (SCIM provisioning, group sync, trusted identity propagation for Q/embedding). IdC governs both surfaces under a single sign-in. The Quick account still must be in us-east-1 for Desktop.

Step A1 — Confirm IdC replication to us-east-1

aws sso-admin list-instances --region us-east-1

You should see your instance ARN (arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx) returned from the us-east-1 endpoint, with replication Active.

Step A2 — KMS key policy on the PRIMARY key (ap-south-1)

Add/keep these statements (in addition to your root, key-admin, and grant statements). Replace <ACCOUNT_ID>.

{
  "Sid": "AllowIAMIdentityCenterToUseTheKMSKey",
  "Effect": "Allow",
  "Principal": { "Service": "sso.amazonaws.com" },
  "Action": [
    "kms:Decrypt",
    "kms:ReEncryptTo",
    "kms:ReEncryptFrom",
    "kms:GenerateDataKeyWithoutPlaintext"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "<ACCOUNT_ID>" }
  }
},
{
  "Sid": "AllowIdentityStoreToUseTheKMSKey",
  "Effect": "Allow",
  "Principal": { "Service": "identitystore.amazonaws.com" },
  "Action": [
    "kms:Decrypt",
    "kms:ReEncryptTo",
    "kms:ReEncryptFrom",
    "kms:GenerateDataKeyWithoutPlaintext"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "<ACCOUNT_ID>" },
    "StringLike": { "kms:EncryptionContext:aws:identitystore:identitystore-arn": "*" }
  }
},
{
  "Sid": "AllowQuickToUseTheKMSKey",
  "Effect": "Allow",
  "Principal": { "Service": "quicksight.amazonaws.com" },
  "Action": [ "kms:Decrypt", "kms:DescribeKey" ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "<ACCOUNT_ID>" },
    "StringLike": {
      "kms:ViaService": [
        "sso.*.amazonaws.com",
        "identitystore.*.amazonaws.com"
      ]
    }
  }
},
{
  "Sid": "AllowSSOAndIdentityStoreToDescribeKMSKey",
  "Effect": "Allow",
  "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] },
  "Action": "kms:DescribeKey",
  "Resource": "*"
}

Least-privilege note on the SSO statement. The default IdC-generated policy often constrains the sso.amazonaws.com Decrypt with kms:EncryptionContext:aws:sso:instance-arn. During the Quick application-creation flow, the encryption context passed by SSO may not match that condition, producing kms:Decrypt AccessDenied. If you must keep an encryption-context condition for tightness, test it against the actual flow; if it blocks creation, scope instead by aws:SourceAccount (as above). Prefer aws:SourceAccount + service principal over removing all conditions.

Step A3 — KMS key policy on the REPLICA key (us-east-1)

Apply the same four statements to the us-east-1 replica key. Replica key policies are independent and are not inherited from the primary. This is the step most commonly missed, and it is exactly what produced the quicksight.amazonaws.com ... kms:Decrypt (Identitystoreinternal) error when the operation was forced to us-east-1.

Step A4 — Verify both key policies

# Primary (ap-south-1)
aws kms get-key-policy --region ap-south-1 \
  --key-id <PRIMARY_KEY_ID> --policy-name default --query Policy --output text

# Replica (us-east-1)
aws kms get-key-policy --region us-east-1 \
  --key-id <REPLICA_KEY_ID> --policy-name default --query Policy --output text

Confirm both contain the sso, identitystore, and quicksight statements.

Step A5 — Create the Quick subscription via CLI (force us-east-1 + explicit IdC ARN)

The console GUI is hardwired to the IdC home Region. The CLI lets you override both the Region and the IdC instance ARN so the SSO app and subscription are created in us-east-1.

aws quicksight create-account-subscription \
  --region us-east-1 \
  --edition ENTERPRISE \
  --authentication-method IAM_IDENTITY_CENTER \
  --aws-account-id <ACCOUNT_ID> \
  --account-name "<unique-quick-account-name>" \
  --notification-email "<email@example.com>" \
  --admin-group "<YourAdminGroupName>" \
  --iam-identity-center-instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx"

• --region us-east-1 → subscription/SSO app created in IAD.
• --iam-identity-center-instance-arn → bypasses the GUI’s home-region auto-resolution. (Confirmed parameter on CreateAccountSubscription; see API reference.)
• Add --author-group / --reader-group as needed. For Q, use --edition ENTERPRISE_AND_Q plus --first-name --last-name --email-address --contact-number.

Note: create-account-subscription is not supported in US East (Ohio), South America (São Paulo), or Asia Pacific (Singapore). us-east-1 is supported. The account Region is derived from the CLI/SDK config (hence --region us-east-1). Source: create-account-subscription CLI reference.

Step A6 — Verify

aws quicksight describe-account-subscription \
  --region us-east-1 --aws-account-id <ACCOUNT_ID>

Expect AccountSubscriptionStatus: ACCOUNT_CREATED.

Web + Desktop both covered. With IdC as the base auth method, the Web UI signs in through IdC immediately, and the Desktop app rides the same IdC identity (users select the Quick app in the IdC access portal). No separate Desktop auth configuration is required for the unified model.

Permanent choice. Per AWS, “Identity methods can’t be changed after your account is created.” The --authentication-method IAM_IDENTITY_CENTER you set here is locked for the life of the account — switching later requires a full Section 5 recreate.

Mobile app under IdC — field-tested. The official doc says the Quick mobile app “is not supported” with IdC-integrated accounts, but that refers to the app’s direct in-app sign-in (account name + username/password). The IdC access-portal-initiated SSO flow does work (tested 6 June 2026): authenticate to your IdP (Okta) → land in the app chooser / IAM Identity Center → select the Quick app that sso:CreateApplication created → signed in on mobile. The session also persisted across app restarts (token refresh held). So mobile users on a Path A account should sign in through the IdP/IdC portal flow, not the app’s direct-login screen. (Sign-in and session persistence both confirmed by hands-on test; the “direct login unsupported, portal SSO works” split is the consistent reading of the official wording — verify in your tenant.)

---

4. Path B — OIDC Identity Federation (Desktop-only bolt-on)

This is the native, lowest-risk Desktop-only SSO path. It uses the OIDC authorization-code flow with PKCE and a public client (no client secret). It does not require IAM Identity Center at all, and it sidesteps the entire IdC/KMS/region problem for Desktop. Source: desktop-enterprise-setup.

Scope clarification — Path B only covers the Desktop app. OIDC Extension access governs Desktop sign-in only. It does not change how the Web UI authenticates — Quick on the web continues to use the account’s base authentication method (the --authentication-method chosen at create-account-subscription, e.g. IAM Identity Center). Consequences:

• If you want a single, unified identity model across both Web and Desktop, use Path A (IdC) as the account base auth method (Section 3) and let it cover Web; Desktop then rides the same identity. Path B is unnecessary in that case.
• If you pick Path B alone, you end up with two identity stories: Web on the account’s base method, Desktop on the OIDC extension. That’s more moving parts, not fewer — appropriate only when you specifically want a lightweight Desktop bolt-on and don’t need unified governance.
• Bottom line: “I need both Web and Desktop working well” points to Path A (IdC) as the base method, not Path B. The two surfaces unify under one sign-in. Path B is a Desktop-specific add-on, not a Web auth solution.

How it works: the Desktop app opens a browser to your IdP’s authorization endpoint, receives an auth code on a loopback redirect (http://localhost:18080), exchanges it for tokens via PKCE, validates the token, and maps the user by email (the IdP email must exactly match the Quick user’s email).

Strict accuracy requirement. In the Quick management console you create an “Extension access” entry that holds the five OIDC values (Issuer, Authorization endpoint, Token endpoint, JWKS URI, Client ID). This configuration cannot be edited after creation — if any value is wrong you must delete it and recreate. So copy/paste each value verbatim and ensure every endpoint comes from the same authorization server.

4.1 Okta — create the OIDC app

1. Okta Admin Console → Applications → Applications → Create App Integration.
2. Sign-in method: OIDC - OpenID Connect.
3. Application type: Native Application → Next.
4. Settings:
   • App integration name: Amazon Quick Desktop
   • Grant type: Authorization Code AND Refresh Token (Refresh Token is required for long-lived sessions)
   • Sign-in redirect URIs: http://localhost:18080
   • Assignments: assign the appropriate users/groups
5. Save. On General, note the Client ID.
6. PKCE (S256) is enforced automatically for native apps; client authentication must be None (public client).

Scopes & access policy (Okta):

• Security → API → Authorization Servers → select your server (e.g. default) → Scopes: ensure openid, email, profile, offline_access are enabled.
• Access Policies tab: ensure a policy/rule applies to this app and allows the Authorization Code and Refresh Token grant types, with your users/groups in scope.

Okta OIDC endpoints (use the default custom authorization server — replace <OKTA_DOMAIN> with e.g. your-org.okta.com):

Field	Value
Issuer URL	https://<OKTA_DOMAIN>/oauth2/default
Authorization endpoint	https://<OKTA_DOMAIN>/oauth2/default/v1/authorize
Token endpoint	https://<OKTA_DOMAIN>/oauth2/default/v1/token
JWKS URI	https://<OKTA_DOMAIN>/oauth2/default/v1/keys
Client ID	from step 5 (Okta client IDs start with the digit 0, i.e. 0oa...)

Critical Okta gotchas — verify each one (these are the real failure modes):

1. Org URL vs admin host. Use the org URL https://<OKTA_DOMAIN> (e.g. integrator-xxxx.okta.com). The -admin.okta.com host serves only the Okta admin console and has no /oauth2/... endpoints (you’ll get 404 / “Page Not Found”).
2. Same server for ALL endpoints. If you use the default custom server, then Issuer, Authorize, Token, Userinfo, and JWKS must all contain /oauth2/default/. Mixing the org server (/oauth2/v1/..., no /default) with the custom server causes downstream failures such as User info request failed (HTTP 401) and token-validation/JWKS-key-mismatch errors, because each authorization server signs and validates with its own keys.
3. Client ID character confidence. Okta client IDs begin with a zero 0, not a capital letter O. A single 0→O typo yields 400 Bad Request.
4. Authoritative source. Pull every value verbatim from the discovery document and copy issuer, authorization_endpoint, token_endpoint, userinfo_endpoint, and jwks_uri:
   https://<OKTA_DOMAIN>/oauth2/default/.well-known/openid-configuration

4.2 Microsoft Entra ID — create the OIDC app

1. Azure portal → Microsoft Entra ID → App registrations → New registration.
2. Settings:
   • Name: Amazon Quick Desktop
   • Supported account types: Single tenant
   • Redirect URI platform: Public client/native (mobile & desktop)
   • Redirect URI: http://localhost:18080
3. Register. On Overview, note Application (client) ID and Directory (tenant) ID.
4. API permissions → Add a permission → Microsoft Graph → Delegated permissions: add openid, email, profile, offline_access. Grant admin consent if your org requires it.
5. Authentication → Advanced settings → Allow public client flows = Yes. Confirm http://localhost:18080 is listed under mobile/desktop redirect URIs. Save.

Entra OIDC endpoints (replace <TENANT_ID>):

Field	Value
Issuer URL	https://login.microsoftonline.com/<TENANT_ID>/v2.0
Authorization endpoint	https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize
Token endpoint	https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token
JWKS URI	https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys

Entra refresh tokens require the offline_access scope; without it users re-authenticate frequently. PKCE is enforced automatically for public clients.

4.3 (Ping Identity)

PingFederate and PingOne are also supported. The pattern is identical: public/native client, redirect http://localhost:18080, grant types Authorization Code + Refresh Token, scopes openid email profile offline_access. For PingFederate, also enable Return ID Token On Refresh Grant in the OIDC policy and ensure the email claim is in the Attribute Contract for both initial and refresh grants. See the IdP tables in the official doc.

4.4 Register the Extension Access in the Quick console

1. Sign in to the Amazon Quick management console (us-east-1 account).
2. Permissions → Extension access → Add extension access.
3. Select Desktop application for Quick → Next.
4. Enter, verbatim, the five values from your IdP (Issuer URL, Authorization Endpoint, Token Endpoint, JWKS URI, Client ID). Double-check before saving — this cannot be edited later.
5. Add.
6. Then Connect apps and data → Extensions → Add extension → select the Desktop application extension access you just created → Create.

4.5 Verify

Install the Desktop app, choose Enterprise login, and authenticate with corporate credentials. The app spins up a temporary listener on http://localhost:18080 to catch the redirect.

Operational tip: Always drive the login from the app, not by hand-pasting URLs into a browser. The 127.0.0.1:18080 listener only exists while the app is mid-login; pasting URLs manually (or taking too long) yields ERR_CONNECTION_REFUSED. Confirm nothing else holds the port: lsof -nP -iTCP:18080 -sTCP:LISTEN.

---

5. Handling the Existing ap-south-1 Quick Web Subscription (Same Account) → Move to us-east-1

Because Desktop + indexing/Knowledge features require the Quick identity region = us-east-1, and a single AWS account has one Quick identity region, you must move from ap-south-1 to us-east-1. There is no in-place Region move for a Quick account — you export assets, unsubscribe, recreate in us-east-1, and re-import.

Destructive operation ahead. Unsubscribing deletes users, folders, and assets in the old Region. This is irreversible. Take complete asset-bundle exports first, validate them, and get stakeholder sign-off. Plan a maintenance window.

5.1 What you CAN migrate with the Asset Bundle APIs

Asset bundle import/export supports these asset types (asset-bundle-ops):

• Analyses
• Dashboards
• Data sources
• Datasets
• Shared folders
• Restricted folders
• Refresh schedules
• Themes
• VPC connections

NOT supported by the asset bundle APIs (these data source / dataset types must be recreated/reconnected manually):

• Adobe Analytics, File (uploaded files), GitHub, JIRA, Salesforce, ServiceNow, Twitter

Also not covered by asset bundles (recreate/re-grant separately):

• User and group identities / namespace membership (re-provisioned via your IdP/SCIM or RegisterUser / group APIs)
• Per-resource sharing permissions to specific users/groups (re-apply after import; bundles carry asset definitions, not necessarily all principal grants in the target)
• Knowledge bases / vector indexes, Spaces, chat agents, connectors/extensions (region-bound — recreate in us-east-1)
• OAuth consents for built-in connectors (each user re-authorizes; ~2 min, by design)

5.2 Pre-migration: export everything from ap-south-1

1. Inventory dashboards, analyses, datasets, data sources, themes, refresh schedules, folders, VPC connections.
2. Export with dependencies. Start an export job in ap-south-1:

aws quicksight start-asset-bundle-export-job \
  --region ap-south-1 \
  --aws-account-id <ACCOUNT_ID> \
  --asset-bundle-export-job-id "bom-export-$(date +%Y%m%d%H%M%S)" \
  --resource-arns "arn:aws:quicksight:ap-south-1:<ACCOUNT_ID>:dashboard/<ID>" \
  --include-all-dependencies \
  --export-format QUICKSIGHT_JSON

• --include-all-dependencies pulls each dashboard’s theme, datasets, and data sources automatically.
• Up to 5 export jobs can run concurrently per account. Poll with describe-asset-bundle-export-job. Source: StartAssetBundleExportJob.
• Use --export-format CLOUDFORMATION_JSON if you’d rather rehydrate via CloudFormation.

3. Poll and download:

aws quicksight describe-asset-bundle-export-job \
  --region ap-south-1 --aws-account-id <ACCOUNT_ID> \
  --asset-bundle-export-job-id "<job-id>"
# When JobStatus=SUCCESSFUL, download the file from the returned DownloadUrl

4. Record non-bundle config: data source connection details/credentials (especially for unsupported types), refresh schedules, VPC connection params, namespaces, group/user mappings, and all sharing permissions.

5.3 Unsubscribe the ap-south-1 account

Quick accounts have termination protection ON by default. You must disable it first, then delete. Deletion via API requires an Enterprise account; otherwise use the unsubscribe screen. Sources: Remove-QSAccountSubscription, How do I delete my Amazon Quick account.

# 1) Disable termination protection (run against the account's identity region: ap-south-1)
aws quicksight update-account-settings \
  --region ap-south-1 \
  --aws-account-id <ACCOUNT_ID> \
  --default-namespace default \
  --no-termination-protection-enabled

# 2) Delete the subscription
aws quicksight delete-account-subscription \
  --region ap-south-1 \
  --aws-account-id <ACCOUNT_ID>

If the API path is blocked (e.g., not Enterprise), use the console unsubscribe screen:
https://us-east-1.quicksight.aws.amazon.com/sn/console/unsubscribe (select the correct account/region context).

5.4 Recreate in us-east-1

• Path A (IdC — recommended, unified Web + Desktop): run Step A5 (create-account-subscription --region us-east-1 --iam-identity-center-instance-arn ...) after the KMS replica policy is fixed (Steps A2–A4). This makes IdC the base auth method covering both surfaces.
• Path B (OIDC federation — Desktop-only bolt-on): create the Quick account in us-east-1 (Enterprise) with your chosen base auth method, then configure OIDC Extension access (Section 4) for Desktop sign-in. Remember Path B governs Desktop only; Web continues on the account’s base auth method.

5.5 Re-import assets into us-east-1

# Upload your downloaded bundle, then:
aws quicksight start-asset-bundle-import-job \
  --region us-east-1 \
  --aws-account-id <ACCOUNT_ID> \
  --asset-bundle-import-job-id "iad-import-$(date +%Y%m%d%H%M%S)" \
  --asset-bundle-import-source '{"Body": "fileb://bundle.qs"}' \
  --failure-action ROLLBACK

• Use override parameters to remap ARNs/Region, data source credentials, and VPC connection IDs to the us-east-1 environment.
• --failure-action ROLLBACK keeps imports atomic during testing.

Do this step-by-step and own each action. Inspect the exported bundle, validate dependencies, supply credentials deliberately, and verify each import before moving on. Manual control here is intentional — it lets you catch remapping/credential issues per asset rather than discovering them after a bulk run.

Optional — automate later with CloudFormation. If you would rather manage Quick assets as version-controlled infrastructure (git-reviewed, repeatable across environments, drift-detected) instead of one-off imports, you can export in CloudFormation format instead of the native bundle: run start-asset-bundle-export-job with --export-format CLOUDFORMATION_JSON, then deploy with aws cloudformation deploy. This makes a CloudFormation stack own the assets (as AWS::QuickSight::* resources) — note that out-of-band console edits then count as drift and deleting the stack deletes the assets. For a one-time cutover, the native QUICKSIGHT_JSON path in this section is simpler; consider the CloudFormation route only if you want ongoing IaC governance. See AWS::QuickSight resource types and assetbundle-export.

5.6 Post-migration

1. Recreate Knowledge bases / Spaces / chat agents / connectors/extensions in us-east-1 (region-bound; re-crawl/re-index content).
2. Reconnect unsupported data sources (Salesforce, ServiceNow, JIRA, File uploads, etc.) and re-enter credentials.
3. Re-provision users/groups (IdP/SCIM or RegisterUser/group APIs) and re-apply sharing permissions.
4. Users re-authorize OAuth for built-in connectors (Outlook/Slack/etc.) on first use.
5. Validate dashboards, refresh schedules, and row-level security.

---

6. Path A vs Path B — Which Should You Choose?

Need	Recommended path
Both Web UI and Desktop working under one unified identity	Path A — IdC as the account base auth method. IdC covers Web and Desktop with one sign-in. Path B would only cover Desktop, leaving Web on a separate method.
SCIM auto-provisioning, IdC group sync, trusted identity propagation for Q / embedded analytics with end-user identity	Path A — IdC + replication.
Already mid-way through IdC replication and want centralized org identity	Path A, finish Steps A2–A6.
Just Okta/Entra/Ping SSO into Quick Desktop only, minimal blast radius (Web auth handled separately or not a concern)	Path B — OIDC federation. No IdC, no cross-region KMS. Note: this does not govern Web sign-in.
Want the cleanest isolation without touching org-wide IdC	Consider a dedicated account with an account-level IdC instance homed directly in us-east-1, or just Path B.

Honest take: Path A vs Path B is fundamentally about whose identity model governs the account, not about Web-vs-Desktop — both surfaces work under either. Path B (OIDC federation) only authenticates the Desktop app; the Web UI always uses the account’s base authentication method. So:

• If you want both Web and Desktop unified under one sign-in (and especially if you already run IdC), choose Path A — IdC as the base auth method. Both surfaces ride the same identity; accept the one-time cross-region KMS work (Steps A2–A4) and CLI creation (Step A5).
• Choose Path B only for a lightweight Desktop-specific bolt-on where you don’t need IdC governance and Web auth is handled independently. It removes the IdC home-region + cross-region KMS dependency that triggers the kms:Decrypt failures, but it does nothing for Web.
• The two can coexist: you can run org-wide IdC (covering Web + Desktop) and still layer OIDC federation for Desktop if you have a specific reason — but for most “Web + Desktop together” cases, plain Path A is the cleaner answer.

6.1 What you lose if you choose Path B for Desktop while Web stays on IdC

If you keep Web on IdC (Path A) but put Desktop on OIDC federation (Path B), you’re running a hybrid. It works, but you give up:

• One identity story. Web is governed by IdC (groups, provisioning); Desktop authenticates straight to your IdP by email match. Two mechanisms to document and debug.
• Email-match becomes the linchpin for Desktop. Path B maps users purely by email — the IdP token email must exactly equal the Quick user’s email. Drift (alias change, casing, different provisioned address) breaks Desktop sign-in even when Web works.
• IdC group-based authorization for Desktop. Path A gates Desktop access by IdC group membership/role; Path B gates only at IdP app-assignment + the email existing as a Quick user.
• Trusted identity propagation for Desktop. IdC propagates the end-user identity into Q, embedded analytics, and identity-aware data sources (Redshift/Lake Formation RLS). Path B’s email-mapped session does not carry it.
• No KMS savings in this case. Because Web stays on IdC, you still maintain the cross-region KMS setup for Web — Path B for Desktop adds a second auth path on top rather than removing the IdC tax.

Net: Path B = fastest Desktop sign-in, but Desktop becomes an email-matched island outside IdC governance. For “same users, both surfaces,” Path A (IdC) for both is the coherent choice.

6.2 Feasibility check (verify before you commit)

Both paths are technically feasible for the scenario in this doc, but each has a hard dependency to confirm first:

Option	Feasible when	Verify with
Path A — IdC unified	IdC multi-Region replication is available for your org instance and a replica exists in us-east-1. This capability is available for organization instances connected to an external IdP across the enabled-by-default commercial Regions (AWS What’s New, Feb 2026).	Step A1 (list-instances --region us-east-1)
Path B — OIDC federation	Your IdP can expose a public/native OIDC client with loopback redirect and refresh tokens. No IdC dependency.	IdP discovery doc + Section 4
Either	Account identity region can be set to us-east-1 (requires the Section 5 migration since your account is currently ap-south-1).	Section 5

Regional constraint (confirmed for us-east-1): In a specific set of Regions — af-south-1 (Cape Town), ap-southeast-3 (Jakarta), ap-southeast-5 (Malaysia), eu-south-1 (Milan), eu-central-2 (Zurich) — Quick accounts can only use IAM Identity Center for identity and access. us-east-1 is NOT in that list, so in your target Region both Path A (IdC) and Path B (OIDC federation) are feasible; Path A is the recommended unified choice, not the only one. Source: Using IAM Identity Center.

Identity method is locked at creation. Per the same doc: “Identity methods can’t be changed after your account is created.” So the base auth method you pick at Step A5 (or when creating the account for Path B) is permanent for that account — another reason the choice matters and why changing it later means a Section 5 recreate.

Path A and the mobile app — use portal SSO (field-tested). AWS docs state the Quick mobile app “is not supported” with IdC-integrated accounts, but in practice that applies to the app’s direct in-app sign-in. The IdP/IdC-portal-initiated SSO flow works (tested 6 June 2026): Okta sign-in → app chooser → IAM Identity Center → select the Quick app → signed in on mobile, and the session persisted across restarts. Guidance for Path A mobile users: sign in via the IdP/IdC portal, not the app’s account-name/direct-login screen. (Sign-in and session persistence confirmed by hands-on test; treat the official “not supported” line as referring to direct login. Re-verify in your own tenant and IdP.)

Cost reminder (Case 1 — same users on both surfaces): Stay in one account. A second account double-licenses every overlapping user. Consolidating into one us-east-1 account (Section 5) keeps a single license per person across Web + Desktop. Verify data-residency constraints before migrating ap-south-1 data to us-east-1.

---

7. Troubleshooting Reference (Real Errors → Cause → Fix)

Symptom	Likely cause	Fix
sso.amazonaws.com is not authorized to perform: kms:Decrypt ... resource does not exist in this Region	KMS key policy in the Region where SSO runs is missing the sso statement, or its encryption-context condition doesn’t match the app-creation flow	Add/relax the sso.amazonaws.com statement on that Region’s key, scoped by aws:SourceAccount (Steps A2/A3)
quicksight.amazonaws.com is not authorized ... kms:Decrypt (Identitystoreinternal)	us-east-1 replica key missing quicksight + identitystore statements (replica policies aren’t inherited)	Add quicksight, identitystore (and sso) statements to the us-east-1 replica key (Step A3)
Console always targets ap-south-1 for Quick + IdC	GUI hardwired to IdC home Region	Use CLI create-account-subscription --region us-east-1 --iam-identity-center-instance-arn ... (Step A5)
Subscription-already-exists / conflict when creating in us-east-1	Same account already has Quick (Web) in ap-south-1 (one identity region per account)	Export assets → unsubscribe ap-south-1 → recreate in us-east-1 (Section 5)
Failed to create space: Unable to initialize Quick index in this region. Please request IAM admin to set up Quick index (even though Web UI region selector = us-east-1)	Account identity region is still ap-south-1. Index/Knowledge/Spaces initialize only in the identity region; the Web UI region selector changes view/operation context only — it does not move the identity anchor	Recreate the account with identity region = us-east-1 (Section 5 migration). Same root cause as the Desktop us-east-1 requirement — not a separate bug (Section 1.4)
Browser: DNS_PROBE_FINISHED_NXDOMAIN on the IdP authorize URL	Okta domain missing .okta.com suffix in config	Use FQDN https://<OKTA_DOMAIN> from discovery doc
Okta 404 Page Not Found on /oauth2/.../authorize	Using the -admin.okta.com host (admin console has no OAuth endpoints)	Use the org URL https://<OKTA_DOMAIN> (no -admin)
Okta 400 Bad Request (immediately)	client_id typo — leading O instead of zero 0	Copy exact client ID (0oa...) from Okta General tab
Okta 400 ... Policy evaluation failed, access_denied	App not assigned to user/group, or auth-server access policy doesn’t allow the app/grant types	Assign app to user/group; ensure default server access policy allows Authorization Code + Refresh Token and the requested scopes
User info request failed (HTTP 401) after getting a code	Token issued by one auth server but /userinfo (or JWKS) called on a different server	Make Issuer/Authorize/Token/Userinfo/JWKS all /oauth2/default/; pull from .well-known/openid-configuration
JWKS/token validation failure	JWKS URI from the org server (/oauth2/v1/keys) while token is from the custom server	Use https://<OKTA_DOMAIN>/oauth2/default/v1/keys
ERR_CONNECTION_REFUSED on 127.0.0.1:18080	App’s loopback listener not running (hand-pasted URLs, app not in login, or timeout)	Drive login from the app, complete promptly; check port with lsof -nP -iTCP:18080 -sTCP:LISTEN
invalid_scope (Okta)	offline_access not enabled on the auth server, or access policy lacks Refresh Token grant	Enable offline_access scope; allow Refresh Token grant in the policy
redirect_mismatch	Redirect URI in IdP not exactly http://localhost:18080 / not a public-client/native platform	Set redirect URI exactly; mark client public/native
“User not found” after sign-in	IdP token email ≠ Quick user email	Ensure emails match exactly; provision the user in Quick
Token validation failure	Issuer URL in Extension access ≠ IdP issuer	Match issuer exactly (verbatim from discovery doc)
Extension access has a wrong value and won’t save changes	Extension access cannot be edited after creation	Delete the extension access and recreate with correct values

---

8. Future: Regional Migration (e.g., when a closer Region supports Desktop)

Today the Desktop app requires the Quick identity region us-east-1 for both authentication and inference (official doc). If/when AWS adds Desktop support in a Region closer to you (e.g., ap-south-1 or ap-southeast-2), migrating back follows the same export → unsubscribe → recreate → import pattern as Section 5, in reverse.

What recreates vs. carries over on any Quick Region move:

Component	Migrate via	Notes
Dashboards, analyses, datasets, data sources, themes, refresh schedules, folders, VPC connections	Asset Bundle APIs	Region/ARN/credential overrides on import
Unsupported data sources (Salesforce, ServiceNow, JIRA, File, GitHub, Adobe, Twitter)	Manual recreate	Re-enter credentials
Users/groups, namespace membership, sharing permissions	IdP/SCIM + RegisterUser/group APIs; re-apply grants	Not fully carried by bundles
Knowledge bases / vector indexes, Spaces, chat agents, connectors/extensions, embed URLs	Recreate in new Region	Region-bound; re-crawl/re-index
OAuth connector consents	User re-authorizes	~2 min, by design
Desktop app + local configs (MCP, local memory)	No migration needed	App just signs into the new Region

Forward-looking disclaimer: No public commitment is implied here about which Regions will support Desktop or when. Treat any third-party community write-ups (e.g., HackMD setup notes) as informal; verify against the official AWS docs before acting. Community reference observed: https://hackmd.io/@arranp/SJaGryVlMl (informal, not authoritative).

---

9. Source References (fact-checked)

• Setting up Amazon Quick on desktop for enterprise deployments (OIDC, us-east-1 requirement, Okta/Entra/Ping endpoints, Extension access not editable, troubleshooting): Setting up Amazon Quick on desktop for enterprise deployments - Amazon Quick
• CreateAccountSubscription (API; IAMIdentityCenterInstanceArn): CreateAccountSubscription - Amazon Quick Sight
• create-account-subscription (CLI; supported/unsupported Regions): create-account-subscription — AWS CLI 2.35.2 Command Reference
• Asset bundle operations (supported/unsupported asset & data source types): Asset bundle operations - Amazon Quick Sight
• StartAssetBundleExportJob (dependencies, concurrency, permissions): StartAssetBundleExportJob - Amazon Quick Sight
• Asset bundle export operations: Asset bundle export operations - Amazon Quick Sight
• Delete subscription / termination protection: QuickSight: Remove-QSAccountSubscription Cmdlet | AWS Tools for PowerShell
• How do I delete my Amazon Quick account (unsubscribe screen): How do I delete my Amazon Quick Sight account? - Amazon Quick
• AWS KMS multi-Region keys (replica keys have independent key policies): Multi-Region keys in AWS KMS - AWS Key Management Service
• QuickSight identity region is fixed at account setup; namespaces created in identity region: We are getting an "Access Denied Exception" saying our operation is being called on us-east-2 but our identity region is us-east-1, but as far as we can tell, our Quick Sight setup is for us-east-2 - #3 by Koushik_Muthanna
• No in-place identity-region change (recreate account): Changing Default AWS region
• IAM Identity Center multi-Region support (org instances with external IdP, enabled-by-default commercial Regions): AWS IAM Identity Center enables account access and application use in multiple AWS Regions - AWS
• Using IAM Identity Center with Quick (Regions where IdC is the only identity option): Using IAM Identity Center - Amazon Quick

---

Document generated for an internal runbook. Re-verify region behavior and CLI parameters against the linked AWS docs before each execution, particularly destructive steps in Section 5.