# 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.
* [Private Connectivity with AWS](https://cloud.docs.scylladb.com/stable/cluster-connections/private-connectivity/private-connectivity-aws/index.md)
* [Private Connectivity with GCP](https://cloud.docs.scylladb.com/stable/cluster-connections/private-connectivity/private-connectivity-gcp/index.md)
## 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.