For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deployment Models

The two e6data deployment models - Serverless (e6data runs the compute) and In Your VPC (compute runs in your Kubernetes cluster) - and how to choose.

e6data offers two deployment models. In both, the Control Plane (workspace management, access control, monitoring, releases) is hosted by e6data, and your data always stays in your cloud account - only the Compute Plane differs.

Serverless
In Your VPC

Compute Plane (clusters, planners, executors)

Runs in e6data's cloud

Runs in your Kubernetes cluster (EKS, AKS)

Catalog metadata, query history

e6data

Your cluster + your cloud storage

Your data

Your cloud account, never moved

Your cloud account, never moved

Query traffic

To e6data's managed compute

Stays entirely within your network

You manage

Nothing - fully managed

The Kubernetes cluster, IAM, and storage lifecycle

Serverless

e6data runs the Compute Plane in its own cloud environment - you don't manage Kubernetes, node pools, or upgrades. e6data accesses your storage through cloud-native identity federation (no long-lived credentials): an AWS IAM role with a trust policy, or an Azure User-Assigned Managed Identity with federated credentials. You grant read-only access and can revoke it at any time.

Choose Serverless when you want the fastest start, don't need to host compute yourself, and want e6data to handle scaling and upgrades. Less ideal when compliance mandates compute inside your VPC, you have strict data-locality needs, or you're air-gapped.

Set up: AWS Serverless · Azure Serverless.

In Your VPC

The Compute Plane runs inside your own Kubernetes cluster, so query traffic never leaves your private network. The Compute Plane authenticates to your storage with the cloud's standard workload identity (EKS Pod Identity/IRSA, or Azure Workload Identity) - no long-lived credentials are stored. The cluster needs outbound access on port 443 to e6data's Control Plane, event sink, monitoring, and container registry (plus public Helm/cert-manager registries during setup); no inbound ports are required.

Operational duties are shared: you own the Kubernetes cluster, cloud IAM, and storage lifecycle; e6data owns component releases, patches, and the workspace lifecycle.

Choose In Your VPC when security or compliance requires compute inside your VPC, you're in a regulated industry, or your data sources have no public routing. Less ideal when you want the fastest start or don't have a platform team to run the cluster.

See also

Last updated

Was this helpful?