AWS QuickSight Cost model on Sessions

Hi Team - Need help in understanding QuickSight pricing.

If we are planning to embed a QuickSight Dashboard in an application ( which is public faced), what is the best pricing model?

We are expecting a user base of 20,000 but not sure about the access pattern.

Need to understand the details below.

  1. When an user accesses an application hosted in the public domain and clicks QuickSight dashboard, internally is it going to be a reader session? How did the authentication and authorization work here? Is QuickSight consider each new user as a new reader or the cost model is session based? Need more info around it.

  2. What is the definition of Session in QuickSight? Let’s say an user is connecting QuickSight in chrome, and open another tab and access QuickSight. Is it a single session or multiple sessions? What is the validity of session.

  3. For unknown usage pattern, what is the best pricing model for reader. Is it good for capacity planning for this requirement?

Hello @Sanjeeb2022 ,

With your scenario having 20K + user base, Capacity pricing would be ideal . Capacity pricing allows QuickSight customers to purchase Reader sessions or QuickSight Q questions in bulk, without having to provision individual Readers in QuickSight. Capacity pricing is ideal for embedded applications or large-scale BI deployments.

  1. based of the volume of user base and being dashboard in pubic domain - you would use anonymous URL embedding. the session would be session capacity.The QuickSight session Capacity pricing model allows purchase of sessions in bulk at discounted rates, for use across large user populations for embedded or BI use cases. With this model, the per-session costs decrease with commitments to larger usage. For Authentication workflow see Build embedded analytics architectures using Amazon QuickSight

  2. Each session within session Capacity pricing is 30 minutes long.Sessions will be renewed in 30-minute intervals and time out 30 minutes after start upon inactivity. In case of embedded sessions, the host application will be responsible for renewing sessions based on setup.

  3. Yes session capacity -Capacity pricing is beneficial when QuickSight dashboards need to be displayed to a large audience with dispersed usage, or in situations where the user population is expected to continually grow. In both cases, the discounts on per-session pricing available with Capacity pricing allow reduction in QuickSight costs over time. Each session within session Capacity pricing is 30 minutes long. Session Capacity pricing also allows use of QuickSight for programmatic access for display on large screens/monitors for consumption by multiple end users.

For more info - Business Intelligence Service – Amazon QuickSight Pricing – AWS

Thank you.
Cheers,
Deep

1 Like

Thanks @Deep for the details. The above information is very useful. I have couple of more questions.

  1. When we embed the QS dashboard in any application, backend the anonymous will be passed to QS and a reader session will be created. If different users will access at same time, I am expecting 2 session will be created as well. Is my understanding correct?
  2. Need one more detail on capacity planning, let’s say we will take the 500 session capacity planning and in a month we crossed that limit and have 600 session, what is the price calculation for extra 100 session. Please help in understanding this.

Again thank you so much for your details.

Regards - Sanjeeb

Hello @Sanjeeb2022 ,

  1. Yes, your understanding is correct.
  2. As per my understanding, The account will be charged for capacity (questions and sessions) consumed from the total capacity purchased. If capacity consumed is more than what is purchased that will be charged at overage capacity. ($0.50 / overage charge per additional session) (** monthly plan 500/month) i.e $50 for additional 100 sessions)

image
Nevertheless, i would recommend to involve your Account team connect with AWS QS specialist to get more insight on this.

Hope this helps.
Cheers,
Deep

Thank you @Deep for the details.

Regards - Sanjeeb