Quicksight costs - Capacity Vs User based pricing

Q&A
, , ,
1

Hello QS Community,

We are developing an application using embedded Quick Sight dashboards with Amazon Q features enabled. We need to clearly understand the session pricing and compliance implications for two potential architectures (we are open to suggestions).

Some context: we’re going to have multiple users and we can’t manually manage each one on aws quicksight (maybe if there is any api to register it through our application that management could work).

Could you please clarify the following scenarios?

Scenario 1: User-Based Pricing with a Single Registered User

In this model, our backend uses a single registered Quick Sight user ARN (e.g., an author or reader user) to call generate_embed_url_for_registered_user. This generated URL is then surfaced to our platform’s multiple end-users (who do not have their own Quick Sight identities).

  • 1. Compliance: Is this a compliant use of the user-based pricing model, or is this considered “multiplexing” and against the terms of service?
  • 2. Session Counting: If this model is compliant, and one of our end-users refreshes the page multiple times within a 30-minute window, does each refresh (which triggers a new generate_embed_url call) count as a new, billable 30-minute session? Or do all refreshes fall under the single, initial session?

Scenario 2: Capacity-Based Pricing with Anonymous Users

In this model, our backend calls generate_embed_url_for_anounymous for each end-user, passing a unique SessionId for that user’s interaction.

  • 1. Session Continuity: Our understanding is that a session lasts until 30 minutes of inactivity. If a user refreshes their page or navigates away and returns within this 30-minute window, will all this activity be considered part of the same single session, provided we correctly maintain and pass the same SessionId?
  • 2. Refresh Impact: To confirm, a page refresh by the user (triggering a new generate_embed_url call from our backend with the same SessionId) will not consume a new session from our capacity, correct?
  • 3. Amazon Q Impact: How does the use of Amazon Q features (Generative Authoring, Q&A, etc.) within the embedded dashboard affect session consumption or cost specifically within the capacity pricing model?

In summary, our primary goal is to understand the session counting mechanics, especially regarding page refreshes, and to confirm which price model should be better for our scenario.

Thank for the assistance in advance.

2

Hi @qs-Luis

Welcome to Quick Sight Community .
Thanks for sharing the details.

For the Scenario 1 : With User based pricing one quicksight user must map to only one individual user , multiplexing is against fair usage policy . Please check the Quick Sight service terms here ( section 40.4)

For Scenario2: while generating the embedding url you can specify the max session time limit and within limit every 30 minute will be counted as 1 session . And any new api call to generate embed url will be considered as new session . Instead you need to use the front end sdk to navigate from one dashboard to another dashboard within the same session . And separate Amazon Q Questions Capacity pack needs to be enabled for additional details here.

I would recommend to connect with AWS Account Team and request for detailed architecture review session .

3

Hi @qs-Luis,

Thank you for your clarification.

I understand the point regarding Scenario 1. The restriction on multiplexing in the service terms (section 40.4) is clear, and we will not proceed with that architecture.

Regarding Scenario 2 (Capacity-based/Anonymous Embedding), I have a follow-up question based on your feedback, as there seems to be a contradiction that would heavily impact our implementation.

You mentioned that “any new api call to generate embed url will be considered as new session”.

However, reading the documentation you sent me, the frontend embedding SDK requires a valid URL for initialization (as I’m using now). As confirmed by the API documentation and our previous discussions, this URL is single-use and cannot be cached.

Consider this common user flow in our Single Page Application (SPA):

  1. A user loads our application and views the embedded dashboard. We call generate_embed_url_for_anonymous_user for the first time, passing a SessionId.
  2. The user then navigates to a different tab within our application, which unmounts the dashboard component.
  3. The user navigates back to the dashboard tab, still within the original 30-minute window.

To re-render the dashboard, we are forced to call the API again to get a new, valid embed URL.

So, the core question is: In this standard SPA navigation pattern, does this necessary second API call—made for the same user within the 30-minute window—truly count as a new billable session?

If every API call to get a fresh URL starts a new session, it would make the pricing model unfeasible.

Could you please confirm this specific point?

Thank you.

4

Hi @qs-Luis

When users navigate across multiple tabs in the application, we recommend not tearing down the DOM element used to embed Quick Sight dashboards. Instead of calling the GenerateEmbedUrlForAnonymousUser API again, use your web framework’s best practices to hide and show the iframe as needed. Avoid remounting or reloading the iframe to preserve session state and improve performance. The exact method depends on your tech stack (display: none` in plain HTML/JS, v-show in Vue, or toggling visibility in React without unmounting).

5

Thanks again, @apjvinod. That’s a very clear explanation.

Your advice on using a hide/show strategy for the iframe is perfect for handling navigation between tabs, we’ll definitely implement that to preserve the session.

This leads me to a follow-up question regarding full page refreshes. In that scenario, the DOM is rebuilt, so the hidden iframe is lost.

What is the recommended best practice to handle this?

Any insights on this would be greatly appreciated!

6

Hi @qs-Luis,

Hope this message finds you well! I saw that your most recent post in this topic has not been answered for a while. Just wanted to check in to see if you were able to find an answer on your own or if you would still like assistance. If we do not receive a response in the next 3 business days, I’ll close this topic.

7

Hi @qs-Luis,

Since we have not heard back, I will close out this topic. However, if you have any additional questions, feel free to create a new post in the community and link this discussion for relevant information if needed.

Thank you!