DataHub Cloud Tenancy Model: Dedicated vs. Shared Resources and Self-Hosted Options – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: Cloud Tenancy, Infrastructure Isolation, and Deployment Models

Issue

Organizations evaluating or onboarding to DataHub Cloud often have questions about the tenancy model: specifically, whether backend infrastructure resources (such as MySQL/RDS, Kafka/MSK, and Elasticsearch/OpenSearch) are dedicated per customer or shared across tenants, whether those resources reside in an isolated VPC or AWS account under customer control, and what alternative deployment options exist for customers with strict security or data residency requirements.

You Might Be Asking

Are my MySQL, Kafka, and Elasticsearch instances shared with other DataHub Cloud customers?
Does my DataHub Cloud deployment run in its own isolated VPC or AWS account?
Can the VPC or AWS account be transferred to or controlled by my organization for security reasons?
Is there a supported option to run DataHub entirely within my own cloud infrastructure?
What is "DataHub Enterprise" and how does it differ from DataHub Cloud?
Does DataHub support a control-plane / data-plane separation model similar to other enterprise SaaS vendors?

Solution

Confirm whether your contract includes dedicated infrastructure.
DataHub Cloud enterprise contracts typically include dedicated backend resources — MySQL (RDS), Kafka (MSK), and Elasticsearch/OpenSearch — that are provisioned exclusively for your tenant and are not shared with other customers. Non-production or proof-of-concept environments may use shared infrastructure, which is standard for trial deployments. Review your contract or contact your DataHub account team to confirm the scope of resource dedication for your specific agreement.
Understand the network isolation model.
Even when backend resources are dedicated to your tenant, they reside within a DataHub-managed VPC and AWS account — not within a VPC or AWS account owned or controlled by your organization. Logical and network-level isolation is enforced through mechanisms such as:
- Customer-specific resource naming and provisioning
- IP allowlisting / network access controls scoped to your organization's IP ranges
- Customer-specific topic prefixes for logical Kafka isolation
- Dedicated Application Load Balancers (ALBs) where applicable
All operational management — including access controls, scaling, upgrades, monitoring, and security — is handled by the DataHub Cloud engineering and SRE teams. Customers interact with the environment exclusively through the DataHub UI and APIs.
Understand what "dedicated AWS account" means in context.
Some enterprise DataHub Cloud customers are provisioned with a dedicated AWS account. However, this account is still owned and managed by DataHub — it is not transferred to or controlled by the customer organization. This model improves billing and blast-radius isolation but does not grant the customer administrative access to the underlying cloud account or VPC.
Evaluate the self-hosted / DataHub Enterprise option if customer-controlled infrastructure is required.
If your organization requires that all infrastructure — including the VPC, cloud account, compute, and data stores — remain under your direct control, the appropriate path is a self-hosted DataHub Enterprise deployment. In this model:
- Your organization provisions and owns all underlying cloud infrastructure.
- DataHub software is deployed within your environment (e.g., your own AWS, GCP, or Azure account).
- Your internal teams (or a managed services arrangement) are responsible for operations, scaling, and upgrades.
- DataHub provides software licensing and support.
This deployment model is chosen at contract time and represents a fundamentally different operational arrangement from DataHub Cloud. It is particularly relevant for organizations that need to surface sensitive internal business context through DataHub and cannot route that data through a third-party managed environment.
```
# Example: High-level self-hosted deployment architecture
# Your organization owns and manages:
#   - AWS/GCP/Azure account and VPC
#   - Kubernetes cluster (e.g., EKS, GKE, AKS)
#   - MySQL / Amazon RDS instance
#   - Kafka / Amazon MSK cluster
#   - Elasticsearch / OpenSearch cluster
#   - DataHub application pods (GMS, MAE consumer, MCE consumer, frontend)
#
# DataHub provides:
#   - Software distribution (Helm charts, Docker images)
#   - Enterprise license
#   - Support and guidance

# Refer to the DataHub self-hosted deployment documentation for
# Helm-based installation:
# https://docs.datahub.com/docs/deploy/kubernetes
```
Engage your DataHub account team for architecture discussions.
If your security posture requires a control-plane / data-plane separation model — a pattern common among enterprise SaaS platforms — this is a commercial and solutions architecture discussion that should involve your DataHub account executive and solutions engineering team. Factors to discuss include:
- The sensitivity of the data or metadata being ingested (e.g., business context, semantic layers)
- Your organization's cloud security and data residency policies
- Whether AWS PrivateLink or other network connectivity options satisfy your security requirements within the DataHub Cloud model
- Whether a self-hosted Enterprise deployment is commercially and operationally feasible for your team

Additional Notes

The DataHub Cloud tenancy model is designed to provide strong operational isolation between customers while allowing DataHub to fully manage the underlying infrastructure on your behalf. This is the standard model for DataHub Cloud and is appropriate for most enterprise use cases, including those with network-level access controls such as AWS PrivateLink. However, organizations with requirements to keep all infrastructure — including cloud account ownership — within their own control should evaluate the self-hosted DataHub Enterprise option from the outset of contract discussions. Switching deployment models after initial onboarding is not a short-term configuration change and requires dedicated planning, scoping, and implementation work. If your data sensitivity requirements have evolved since your initial contract was signed (for example, due to new product capabilities that surface sensitive internal business context), proactively raise this with your DataHub account team to explore the available options.

Issue

You Might Be Asking

Solution

Additional Notes

Related Documentation