Was this page helpful?
Configure Private Connectivity¶
Available with the Premium plan
Private Connectivity routes all database traffic between your application and ScyllaDB Cloud exclusively over the cloud provider’s backbone network, with unidirectional connectivity, no public internet exposure, and no CIDR conflicts commonly associated with VPC peering.
On AWS, Private Connectivity uses AWS PrivateLink.
On GCP, it uses GCP Private Service Connect.
Setting up a private connection involves two steps: creating the service endpoint in the ScyllaDB Cloud console, and creating the consumer endpoint in your own AWS or GCP account. Both steps are covered in the guides below, organized by cloud provider.
Feature Status¶
Private Connectivity is configured per datacenter. If your cluster spans multiple datacenters, you can configure a separate private connection for each datacenter.
Why Use Private Connectivity¶
VPC Peering and Transit Gateway require bidirectional routing between your VPC and ScyllaDB Cloud, which many enterprise security teams flag as too broad an exposure. Private Connectivity addresses this with a strictly unidirectional, service-scoped model.
Key benefits:
No public internet exposure. Traffic stays entirely within the cloud provider’s backbone network. No internet gateway, NAT device, or public IP address is required on either side.
Unidirectional by design. Your VPC initiates connections to ScyllaDB Cloud. ScyllaDB Cloud cannot initiate connections into your environment.
Zero Trust posture. ScyllaDB cannot reach into your network. Access is scoped to the ScyllaDB service endpoint only, limiting blast radius to a single service.
Zero CIDR conflict risk. There is no VPC peering relationship between the consumer and producer VPCs. IP address ranges do not need to be coordinated.
Compliance alignment. Private Connectivity satisfies the network isolation requirements of PCI-DSS, HIPAA, SOC 2 Type II, and FedRAMP.
Simplicity. No IP allowlists, no route table changes on both sides.
Full Shard, Token and Rack Awareness. Private Connectivity maintains full shard, token, and rack awareness when used with the supported ScyllaDB Cloud drivers.
You can use Private Connectivity alongside VPC Peering or Transit Gateway on the same cluster. Combining connection types is supported but weakens the network isolation guarantees described above. Limit this to cases where explicitly required.
How It Compares to VPC Peering¶
Attribute |
Private Link / PSC |
VPC Peering |
|---|---|---|
Customer setup |
Endpoint attachment only (simple) |
Route tables on both sides (moderate) |
IP conflict risk |
None — IPs are fully independent |
CIDRs must not overlap |
Network adjacency |
None — unidirectional only |
Bidirectional routing established |
Provider-initiated connections |
Impossible by design |
Theoretically possible via misconfigured security groups |
Blast radius |
Scoped to one service only |
Any resource in the peered VPC |
Enterprise security posture |
Meets the stricter requirements of regulated industries |
Considered insecure by many enterprise security teams |
Security and Compliance Alignment¶
Requirement |
How Private Link / PSC Addresses It |
|---|---|
Data stays within the cloud boundary |
Routed via cloud provider backbone only — never internet-routed |
Network segmentation |
No shared routing table; strictly unidirectional connectivity; customer initiates the connection |
Third-party access control |
Customer creates/revokes endpoints in their VPC — immediate, no coordination needed |
Zero Trust posture |
Provider cannot initiate connections into the customer environment |
Zero network adjacency |
No bidirectional routing established; ScyllaDB Cloud cannot initiate connections into customer VPC |
All of the above are often strong recommendations for PCI-DSS, HIPAA, and SOC 2 Type II.
Cost Considerations¶
Private Connectivity does not add charges to your ScyllaDB Cloud subscription. However, because the feature relies on AWS PrivateLink or GCP Private Service Connect infrastructure provisioned in your cloud account, you will incur additional charges from your cloud provider. These charges are either billed directly to you by AWS or GCP or, if billed to the provider side, passed through as-is by ScyllaDB Cloud.
Those charges depend on:
The number of VPC endpoints and Availability Zones in use (hourly charge per AZ).
The volume of data processed through the private endpoint each month.