Non-prod to prod or versioning for non self service model

Question & Answer
,
1

We traditionally do not have a self service model where all the reports are built directly in a production environment; we have an internal team that will create most of our analysis in a dev environment first and promote up stream. I don’t see how that kind of process flow would work with QuickSight.

  1. Can we spin up different instances of QuickSight?
  2. If we can spin up different instances, how would we migrate connections, datasets, analysis, dashboards across the different instances?
  3. If all within the same instance, how would you easily differentiate between a DEV, TEST, UAT, or PROD analysis or dataset? Without the ability to group by folders, this would be too many items to scroll through and would be quite confusing.

Is anyone else doing this type of waterfall type of implementation or are there any best practices out there?

2

Hi @pyi -

  1. You can only have one QuickSight instance per AWS account. A common approach is to have separate non-prod and prod AWS accounts.

  2. You can leverage QuickSight API/SDKs for both cross-account and same-account deployments. See example blog BIOps: Amazon QuickSight object migration and version control | AWS Big Data Blog

  3. One approach is to put nonprod (dev, test, uat) in one account and prod in another. You can use shared folders/user groups to segment the nonprod stages. Managing Dashboards/Analyses can be done completely through the UI but you’ll want to leverage the API for DataSets/DataSources. There is currently a limitation where you can’t switch a DataSet’s DataSource in the UI.

2 Likes