How do I enable private connectivity (VPC peering/PrivateLink) in Redis Cloud Pro?

Most teams reach Redis Cloud Pro because they’re already fighting noisy-neighbor latency, egress bills, or security reviews that hate “public internet” paths. Private connectivity—VPC peering or PrivateLink-style endpoints—is how you keep Redis traffic on your cloud backbone, lock it behind your own network controls, and still get fully managed Redis performance.

Quick Answer: In Redis Cloud Pro, you enable private connectivity by creating a private networking deployment (per-region VPC), then configuring either VPC peering (same cloud, same region) or PrivateLink‑style service endpoints (cross-account / stricter isolation) between your Redis Cloud VPC and your application VPCs. You finish by updating DNS and security rules so apps only talk to Redis over those private links.

The Quick Overview

What It Is: Private connectivity in Redis Cloud Pro keeps traffic between your apps and Redis inside your cloud provider’s private network, using mechanisms like VPC peering and PrivateLink-style service endpoints.
Who It Is For: Platform, security, and backend teams running Redis Cloud Pro on AWS/Azure/GCP who need low-latency, high-throughput access without exposing Redis over the public internet.
Core Problem Solved: Solves latency, egress cost, and security/compliance issues that come from sending Redis traffic over public IPs or traversing the open internet.

How It Works

Redis Cloud Pro runs your databases inside a dedicated Virtual Private Cloud (VPC) in your chosen region. Private connectivity wires that Redis VPC to your own application VPCs using your cloud provider’s native networking features:

VPC Peering: Direct, private routing between your app VPC and the Redis Cloud VPC in the same cloud/region.
PrivateLink / Private Endpoint–style access: Service endpoints that let you connect from other accounts or more complex topologies without full VPC peering.

Once the private connection is set up, Redis Cloud Pro exposes private endpoints. You point your app’s Redis client at those private hostnames or IPs, and all traffic stays on the cloud provider’s backbone—no public IPs, no internet hops.

At a high level:

Create / choose your Redis Cloud Pro deployment:
Pick region + cloud provider and ensure the deployment supports private networking.
Enable private connectivity in Redis Cloud:
In the Redis Cloud console, configure VPC peering or PrivateLink-style connectivity, and capture the connection parameters (VPC ID, service name, CIDRs).
Wire up your cloud networking:
In AWS/Azure/GCP, create the peering connection or private endpoint, update route tables + security, then switch your apps to use the new private Redis endpoints.

Step-by-step: VPC peering in Redis Cloud Pro

Note: Exact screens and labels may differ slightly by cloud provider and Redis Cloud UI version, but the workflow is the same.

1. Verify your Redis Cloud Pro deployment

Log in to the Redis Cloud console.
Confirm you’re using a Pro subscription in the right cloud provider and region.
Check that the deployment is in a dedicated VPC (not a shared test environment).

If you’re not sure whether your current deployment supports private networking, contact Redis Support or your Redis account team before you proceed.

2. Collect your app VPC details

In your cloud provider (example: AWS):

Identify the VPC ID where your applications run.
Note the CIDR block (for overlap checks).
Identify the region (must match the Redis Cloud deployment’s region for peering).
Confirm you have permissions to create:
- VPC peering connections
- Route table updates
- Security group / NACL changes

Warning: Overlapping CIDR ranges between your VPC and the Redis Cloud VPC will block peering. You may need to adjust CIDRs or use a different VPC.

3. Request / configure VPC peering from Redis Cloud

In the Redis Cloud console:

Navigate to your Pro deployment → Networking / Private connectivity.
Choose VPC Peering as the connectivity type.
Enter your app VPC details:
- Cloud provider (e.g., AWS)
- Region (e.g., us-east-1)
- Your VPC ID
- Your VPC CIDR (if requested)
Submit the peering request.

Depending on setup, Redis Cloud Pro will either:

Automatically create the peering connection to your VPC, or
Provide a Redis VPC ID and account/organization ID you use to create an inbound peering connection from your side.

4. Accept and finalize peering in your cloud

Using AWS as an example:

# List pending peering connections
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=pending-acceptance

# Accept a specific connection
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-1234567890abcdef0

Then update your networking:

Route tables:
- In your app VPC route table, add a route pointing the Redis VPC CIDR to the new peering connection.
- Redis Cloud’s side will have equivalent routes configured.
Security groups / NACLs:
- Allow outbound traffic from your app subnets to the Redis VPC CIDR on the Redis port (typically 6379 or TLS port, e.g., 6380).
- If you explicitly whitelist source CIDRs, include your app subnets.

Note: Peering is non-transitive. If you have a hub-and-spoke topology, each VPC that needs Redis access must have its own peering or use PrivateLink-style endpoints.

5. Switch your apps to use private endpoints

Once peering is active and routes are in place:

In the Redis Cloud console, locate the private endpoint hostname (or IP) for your database.
Update your app’s Redis connection string to point to the private hostname instead of the public one.

Example (Node.js):

import { createClient } from 'redis';

const client = createClient({
  url: 'redis://your-db-id.priv.redis-cloud.example.internal:6379',
  socket: {
    tls: true, // if your plan uses TLS
  },
});

await client.connect();

Test from an EC2 instance (or equivalent) inside the peered VPC:

redis-cli -h your-db-id.priv.redis-cloud.example.internal -p 6379 PING
# Expect: PONG

Once confirmed:

Remove any public connectivity paths you no longer need.
Update firewall rules to prevent direct internet access to Redis.

Step-by-step: PrivateLink / private endpoints in Redis Cloud Pro

When you can’t, or don’t want to, use full VPC peering—cross-account scenarios, shared services VPC, or stricter isolation—PrivateLink (AWS) or Private Endpoint (Azure/GCP equivalent) lets you expose Redis as a private service.

1. Enable private endpoint access in Redis Cloud

In the Redis Cloud console:

Go to your Pro deployment → Networking / Private connectivity.
Select PrivateLink / Private Endpoint mode.
Redis Cloud will either:
- Provide a service name (e.g., an AWS com.amazonaws.vpce-svc-XXXX style name), or
- Walk you through endpoint configuration in your cloud.

Capture:

The service name
Supported AZs (availability zones)
Any required endpoint policies

2. Create a private endpoint in your VPC

Using AWS as an example:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-1234567890abcdef0 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.vpce-svc-abc123.redis-cloud \
  --subnet-ids subnet-aaa subnet-bbb \
  --security-group-ids sg-redis-endpoints

Then:

Accept the endpoint from the Redis side if required (some flows are auto-approved).
Wait for the endpoint status to become available.

3. Configure DNS and security

Ensure your endpoint’s private DNS is enabled or configure a custom private hosted zone that maps the Redis hostname to the endpoint’s private IPs.
In your app VPC:
- Allow outbound traffic from app subnets to the endpoint ENI security group.
- Confirm no direct internet access is needed to reach Redis.

Test from an instance in your VPC:

dig your-db-id.priv.redis-cloud.example.internal

redis-cli -h your-db-id.priv.redis-cloud.example.internal -p 6379 PING

If DNS returns a private IP from the endpoint and PING returns PONG, your PrivateLink path is working.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
VPC Peering Integration	Connects your app VPC directly to the Redis Cloud Pro VPC via private routes	Keeps Redis traffic off the public internet with low latency
PrivateLink / Private Endpoint Support	Exposes Redis as a private service endpoint in your VPC	Safely connect across accounts/topologies without full peering
Private Endpoints + TLS	Combines private networking with encrypted connections	Reduces attack surface while meeting compliance/security mandates

Ideal Use Cases

Best for high-throughput, latency-sensitive APIs: Because VPC peering provides sub-millisecond access over the cloud provider’s backbone, ideal for session stores, rate limiting, and hot-path AI features.
Best for regulated / zero-trust environments: Because PrivateLink-style endpoints let you lock Redis behind your own VPC boundaries, identity, and inspection pipelines, without exposing public IPs.

Limitations & Considerations

CIDR overlap (VPC peering):
If your app VPC CIDR overlaps with the Redis Cloud VPC CIDR, peering fails.
Workaround: Use a non-overlapping VPC, adjust CIDRs, or choose PrivateLink-style endpoints instead.
Network complexity & cost:
Private endpoints and peering add network hops, ENIs, and potential data processing charges from your cloud provider.
Workaround: Centralize Redis access in a shared services VPC, monitor costs and latency with Prometheus/Grafana and Redis’s v2 latency metrics, and minimize cross-region paths.

Warning: Avoid mixing public and private endpoints for the same app in production. You can trigger confusing split-brain behavior in your observability and security tooling. Once private connectivity is live, standardize on it and update all client configs.

Pricing & Plans

Private connectivity is available with Redis Cloud Pro running in a dedicated VPC. Pricing typically includes:

Redis Cloud Pro resources: RAM/throughput/regions as part of your subscription.
Cloud networking charges: Your cloud provider may bill for:
- Data transfer across peering links
- Interface endpoint hours (for PrivateLink/Private Endpoint)
- Cross-AZ data if applicable

If you buy Redis Cloud via AWS Marketplace, your Redis charges can appear on your AWS bill, making it easier to reconcile app + networking costs in one place.

Pro (VPC Peering–only) setups: Best for teams in a single account/region needing simple, low-latency private networking with minimal operational overhead.
Pro with PrivateLink / Private Endpoint: Best for multi-account, shared services, or regulated workloads where you need explicit service endpoints, central control, and stronger isolation.

Note: For exact pricing and whether private connectivity features are included or add-ons in your region, talk to Redis sales or your account representative.

Frequently Asked Questions

Do I still need TLS if I use VPC peering or PrivateLink?

Short Answer: Yes, you should keep TLS enabled even with private connectivity.

Details:
VPC peering and PrivateLink keep traffic on private networks, but they don’t encrypt the payload by default. Redis Cloud Pro supports TLS; keeping it enabled:

Protects against misconfigurations or future topology changes
Aligns with most compliance frameworks (PCI, SOC 2, HIPAA)
Makes it safer to add new VPCs or endpoints later without exposing plaintext traffic

In your clients, ensure you configure the TLS flag (e.g., socket.tls: true in Node, or rediss:// URIs).

Can I connect multiple VPCs to the same Redis Cloud Pro deployment?

Short Answer: Yes, but each VPC needs its own peering or private endpoint configuration.

Details:
VPC peering is non-transitive, so connecting VPC A ↔ Redis does not automatically give VPC B access. You have options:

Multiple VPC peerings: Each app VPC peers directly with the Redis Cloud VPC.
PrivateLink / private endpoints: Create separate interface endpoints in each VPC that needs access.
Shared services VPC pattern: Centralize certain services (like Redis) in one VPC and expose them via PrivateLink, keeping cross-account access manageable.

Design your topology with your security team: define which accounts and VPCs can resolve Redis’s private DNS and which security groups are allowed to connect.

Summary

Private connectivity in Redis Cloud Pro gives you fast, secure, and compliant access to Redis by keeping all traffic inside your cloud backbone. VPC peering is the simplest path for same-account, same-region workloads, while PrivateLink-style endpoints unlock cross-account and stricter isolation scenarios. Once configured, you get the usual Redis Cloud benefits—sub-millisecond latency, built-in reliability, and AI-ready data structures—without the risk and inconsistency of public internet paths.

Next Step

Get Started