AWS Partner Network (APN) Blog

Running Tableau Online on AWS

The following post is a guest post from Nick Brisoux, Product Manager – Cloud at Tableau. Tableau is an Advanced APN Technology Partner and an AWS Big Data Competency Partner. 

Tableau is a self-service visual analytics platform that helps people see and understand their data. Our customers use Tableau Desktop to create charts, graphs, maps and statistical analysis and share their creations and insights with their colleagues. Tableau Online is our cloud analytics solution that allows them to do this easily. We announced the product in July 2013, and it has become the fastest growing product in the history of the company.

Back in 2013, to launch Tableau Online, we started with our own data center in California and later added one in Dublin, Ireland. As more and more users moved to Tableau Online – and with our growth accelerating faster than ever – we quickly realized the challenge ahead of us – how to scale Tableau online in the data center world. To meet the growth of Tableau Online, this year we decided to move to AWS so we can get out of the business of managing data centers and focus on what we do best: helping users see and understand their data.

Even while planning and evaluating what the effort would be to migrate to AWS, we could clearly see the benefits our customers would have by making Tableau Online available on AWS.

  • Focus: With AWS managing the undifferentiated, heavy lifting around infrastructure, we could focus our development resources and cycles on delivering more goodies to our customers faster.
  • Speed: Amazon Redshift is one of the most popular databases with Tableau online, and having Tableau online on AWS could improve visualization loading times and data refresh speed, especially for AWS data sources in the same region.
  • Global: We could deploy Tableau Online in other AWS regions faster and cheaper than we could with traditional physical data centers. This would allow us to expand Tableau Online globally much faster.
  • Availability: Redundant “availability zones” in each AWS region could help us run in a high availability configuration and eliminate potential “single point of failure” scenarios that we currently needed to mitigate for.

In early summer we started working on a proof of concept to deploy Tableau Online in AWS and launched in October, a much shorter turnaround compared to the launch our own data center in Europe.

Building the Deployment

Our primary objective for the proof of concept was to get a Tableau Online deployment in North Virgina (us-east-1) region and also validate our assumption that being closer to users would improve performance. For our PoC, we also had these additional goals:

  • Leverage AWS services wherever possible
  • Leverage existing automation and operational tools
  • Design for high availability and disaster recovery
  • Integrate with our existing shared services (e.g. Identity management)
  • Get the environment ready within a month of the decision to launch

We decided to take a staged approach by breaking down the deployment into its major operational readiness stages. Figure 1 shows the major components of our architecture after many stages of evolution in making Tableau Online available on AWS.

Figure 1 – Tableau Online on AWS Architecture

Stage 1: Setting Up the AWS Environment

The first step for us was to create the network infrastructure for connecting our existing shared services to our new AWS environment. We were quickly able to create this link via IPsec tunnels through AWS VPN Gateways. Then we created production and QA VPCs in a subset of AWS regions and connected them accordingly. We also divided the VPC into logical subnets, and chose a significantly large CIDR range for our external subnet, to minimize the need for customers to adjust their IP whitelisting in the future.

Stage 2:  Deploying Tableau Online on AWS

We decided to deploy the backgrounder processes first since,

  • Much of the work in Tableau Online is done by various Tableau Server background processes
  • These can be deployed outside of the main application stack
  • We could test them with our current production/QA data center deployment

Based on our experience with deploying Tableau Server backgrounder process, we created AMIs for the various Tableau Server process and leveraged AWS services. Once we broke Tableau server into several components, we could quickly and easily deploy instances of these in each VPC utilizing multiple Availability Zones for redundancy.

Once we were satisfied with our deployment of Tableau Server on AWS, we went through our existing full functional test pass to certify that we were ready to onboard customers. At this point we were ready to do our performance testing.

Stage 3: Performance Testing

Given that one of our major goals was deploying as close to the user as possible, we were eager to see how this affected performance, and the improvements for a user in the same AWS region as Tableau Online are impressive. The chart below highlights the dramatic performance improvement for Tableau Online in the Northern Virginia region (us-east-1) versus Tableaus Online in our current west coast data center, when connecting to an Amazon Redshift Cluster in the Northern Virginia region (us-east-1).

The chart shows two metrics:

  1. The time it takes to publish content to Online.
  2. The time it takes for a user to see their dashboard rendered in their browser.

Stage 4: Building Disaster Recovery

An operational readiness requirement for us is to have a proven disaster recovery story. This was accomplished by repeatedly building out and tearing down a full deployment, exercising our failover handling and data recovery procedures for starting new background instances, being resilient for Postgres failover with Amazon RDS, and validating Windows DFSR replication, failover, and consistency. This was fully automated, resulting in a significant reduction of existing operational work.


When we started on this journey we identified some key objectives outlined at the beginning of this blog, and we were able to meet these objectives. This October we launched a production instance of Tableau Online on AWS and started accepting new customer signups.

In addition to the performance benefits customers will see, we also identified others:

  • Instead of running and managing our own Postgres or Load balancer or Caching, all of which required hand crafted replication and deployment, we were able to leverage AWS service such as Amazon RDS for PostgreSQL, Elastic Load Balancing and Amazon ElastiCache. With Amazon RDS, customers get redundancy (including replication and failover) for high availability of the Postgres service, on demand.
  • Instead of using a CDN for our current data center deployments, Amazon CloudFront was simple to use and gave us faster initial page load times since the static content is more effectively served by CloudFront.
  • Cost savings are important, but operational flexibility is a game changer, and AWS allowed us to deliver on this front by providing us various ways to use these managed services through SDK, APIs and deployment tools like AWS CloudFormation with which we can onboard customers faster than ever.
  • Underpinning Tableau Online is our Tableau Server technology, and our work to run Tableau Online on AWS has allowed us to make it easier for our customers to deploy Tableau Server on AWS. For customers who are looking to move Tableau Server to AWS, we have made available CloudFormation scripts for automated deployments and best practices around Amazon EC2 sizing.

Next Up

Tableau recently concluded its annual user conference where we announced our new AWS us-east-1 deployment. Many of our existing Tableau Online customers have already reached out to us so they can take advantage of the new pod. Tableau is a Diamond level Sponsor at the AWS re:Invent 2016 conference, and we look forward to seeing you there.

Want to learn more about Tableau’s journey on AWS? Check out our AWS Partner video, featuring Ashley Kramer, Director of Product Management at Tableau!

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.