Hi all, hoping someone who's been through this can sanity-check our approach before we provision more infrastructure.
What we're trying to do
We have 10+ existing production dashboards on Tableau Cloud that currently point at a publicly-accessible Redshift cluster. We're migrating them to a new Redshift cluster that sits inside a private AWS VPC. The dashboards have to stay exactly as they are - same layout, calcs, filters. Rebuilding from scratch isn't an option at the moment.
What's working
Bridge is set up and healthy:
- Dedicated pool created (not the default pool), status Ready
- Bridge client installed on an EC2 inside the VPC, connected, assigned to the pool
- Redshift host in the Private Network Allowlist, mapped to that pool
- Security group on the cluster allows 5439 from the Bridge instance
- Credentials verified — can browse schemas and tables through the connection
Changing the connection and creating an extract from within the Tableau Cloud workbook editor works fine, and the job details confirm it routed through Bridge.
What's failing
Every scheduled or manual extract refresh fails with:
This server violates the ip allowlist/blocklist restrictions
Unable to connect to the Amazon Redshift server "<our-cluster>.<our-region>.redshift.amazonaws.com"
We tried deleting and recreating the schedule, reassigning the Bridge client to the pool, and reverifying the allowlist mapping. Same result every time.
What we think is going on
From the Limitations section of the embedded data sources doc (
help.tableau.com/current/online/en-us/to_bridge_eds.htm), workbooks published via the REST API or uploaded through the Tableau Cloud web interface don't support Bridge refreshes when data sources are embedded. Ours was published using "Publish As" from web authoring, so we think that's the cause. The documented workarounds are to publish from Tableau Desktop, or publish the data source separately and connect the workbook to it.
Where we've got stuck
We hit three walls trying to follow those workarounds:
- Repointing an existing workbook to a published data source is a Replace Data Source operation, and per the docs that's Tableau Desktop only, not available in Tableau Cloud.
- We can't publish one of our two data sources separately (for one of our workbooks but there are some other as well in similar structure) anyway, Desktop greys it out with "Data sources with calculations that reference other data sources must be embedded."
- We installed Tableau Desktop and the Amazon Redshift ODBC 2.x driver locally and tried connecting directly. It times out. An nslookup shows the hostname resolves to a private IP via a VPC endpoint, so the cluster genuinely isn't reachable from outside the VPC. No firewall or SG change fixes that, if I am not wrong.
Our workbook is also 63 MB, over the 50 MB web upload limit, so uploading through the web UI isn't an option regardless.
Questions
- Has anyone confirmed that publishing a workbook from Tableau Desktop actually resolves the embedded-data-source Bridge refresh issue when the source is in a private VPC specifically? The docs say it should, but we haven't validated it end-to-end yet and don't want to build infrastructure on an assumption.
- Is running Tableau Desktop on a VM inside the VPC the normal approach for this, or is there a cleaner pattern we're missing?
- Is there any supported way to repoint an existing workbook from an embedded data source to a published data source without Desktop?
- More generally, if you've migrated a set of existing workbooks to a private VPC data source, what did your process actually look like? Trying to settle on the right pattern before repeating it 10+ times.
Happy to share more detail if useful. Thanks in advance.
#Tableau Cloud
When working with Bridge, what I recommend you is to use Published Data Sources. Working with workbook embedded datasources take longer to refresh (the last time I tried it took like 10x more time). Why? when you are using published data sources, the extract is created in the machine (e.g the ec2), therefore the extract is created in the machine and the info travels really fast between your redshift and your bridge client. However, when refreshing workbook embedded datasources, the extract is created in Tableau Cloud. Therefore, all the info travels through the internet to Tableau Cloud, and then Tableau Cloud creates the extract. Thus, the transfer speed redshift->Tableau Bridge->Tableau Cloud is not as good as in your VPC.
The first thing you should take a look is make sure everything is correctly set up for your Bridge Client. Thus, I recommend:
a. Go to Settings->Bridge Tab and make sure your Bridge client is Connected.
b. Make sure your <our-cluster>.<our-region>.
is in the allow list of the bridge pool, and that the bridge client is in the allowed pool. If you are using a local ip instead to connect from the bridge to the redshift make sure to include that also in the allowlist.
c. Verify your Bridge Client machine can use ports 80 and 443 for incomming outgoing connections to Tableau Cloud ips (
https://help.tableau.com/current/pro/desktop/en-us/publish_tableau_online_ip_authorization.htm
). If using Tableau Bridge on Windows, make sure it is configured to run as service (not as application)
https://help.tableau.com/current/online/en-us/to_bridge_site_settings_win.htm
c. Go to Explore, create button, new datasource. Use as server the local ip, or the hostname identifier your bridge uses to connect to redshift.
d. If you can connect to your Redshift, then the Bridge is working correctly.
Now, some steps at the workbook:
e. Go to your workbook, datasources tab. Edit the connection and make sure to use as host/server the hostname your bridge uses to connect to Redshift (that is also in the allowlist of the settings->bridge tab). Review other parameters as password if needed.
f. Go to the Extract refreshes tab, delete all schedules.
g. Create new schedules, and try to refresh.
If this does not resolve the question, go to the jobs section, hover over the job, and take a screenshot so we can take a look of the error.
If this post resolves the question, would you be so kind to "Accept this Answer"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.
Regards,
Diego Martinez
Tableau Visionary and Tableau Ambassador
