The flow
Embedding is server-mediated. Your backend calls a QuickSight API to generate a short-lived embed URL, then your frontend loads that URL in an iframe, usually via the QuickSight embedding SDK.
The key APIs are GenerateEmbedUrlForRegisteredUser and GenerateEmbedUrlForAnonymousUser. Embed URLs are short-lived by design — generate them per session, never store or share them.
Your application domain must be allow-listed in QuickSight settings, or the iframe will refuse to load.
Registered vs. anonymous
Registered user embedding maps each viewer to a QuickSight user identity, so row-level security and per-user permissions apply naturally. Use it for internal applications and customer portals where you already have identity.
Anonymous embedding serves users who have no QuickSight identity, billed per session. Because there is no user identity, RLS cannot key on the user — you enforce isolation by passing session tags that the rules dataset matches on instead. This is the multi-tenant SaaS pattern.
Passing context
Parameters can be supplied when generating the embed URL, so the host application pre-filters the dashboard — showing a customer only their own account, for example.
Never rely on a parameter alone for security. A parameter controls what is displayed; row-level security controls what can be queried. Enforce isolation with RLS or session tags and use parameters only for convenience.
This distinction is the most important thing to get right in a multi-tenant embed, and it is a reliable interview question.