In-Memory Databases & Caching
How do I enable private connectivity (VPC peering/PrivateLink) in Redis Cloud Pro?
8 min read
Private connectivity in Redis Cloud Pro lets your applications talk to Redis over your own cloud network instead of the public internet. That means lower latency, simpler compliance, and no public endpoints exposed—using either VPC peering or PrivateLink/Private Service Connect, depending on your cloud provider and plan.
Quick Answer: You enable private connectivity in Redis Cloud Pro by creating a Redis Cloud VPC in the same region as your application, then requesting either VPC peering or PrivateLink/Private Service Connect from the Redis Cloud console or via support. Once approved, you update your routing/DNS so your apps use the private endpoint instead of the public hostname.
The Quick Overview
- What It Is: A way to connect your Redis Cloud Pro databases to your AWS, GCP, or Azure networks using private networking options like VPC peering and PrivateLink (or cloud equivalents).
- Who It Is For: Teams running Redis Cloud Pro in production who need stronger network isolation, predictable latency, or compliance with “no public internet” policies.
- Core Problem Solved: Eliminates exposure of Redis over the public internet and reduces network hops, lowering latency and tightening your security posture.
How It Works
Redis Cloud Pro runs your databases inside a Redis-managed VPC. Private connectivity connects that Redis VPC to your own cloud network:
- VPC peering: Your VPC and the Redis Cloud VPC exchange routes. Traffic between them stays on the provider’s backbone, with private IPs and no public internet.
- PrivateLink / Private Service Connect / Private Endpoint: The provider exposes Redis as an endpoint inside your VPC. Your apps talk to a private, regional endpoint; Redis stays behind Redis’s VPC boundary.
You configure this in three main phases: prepare your network, request the private connection in Redis Cloud, then update applications to use the new private path.
-
Phase 1 – Prepare your cloud VPC
- Make sure your app runs in the same cloud provider and region as your Redis Cloud Pro subscription (for peering/PrivateLink to be available).
- Confirm CIDR ranges don’t overlap with Redis’s VPC ranges (Redis will provide or validate this during setup).
- Decide which connectivity model you want:
- VPC Peering: Simple, low overhead; no NAT or proxy needed.
- PrivateLink / PSC / Private Endpoint: Better isolation, one-way access from your VPC to Redis.
-
Phase 2 – Enable private connectivity in Redis Cloud Pro
- In the Redis Cloud UI:
- Go to your Redis Cloud Pro / subscription.
- Open the Network or Connectivity settings.
- Choose VPC peering or PrivateLink / Private Service Connect.
- Enter the required details:
- For peering: your VPC ID, region, account/project ID, and CIDR.
- For PrivateLink-style: your VPC, subnets, security group, and acceptance options.
- Redis provisions a Redis Cloud VPC (if not already created) and sets up the requested connection.
- Some flows are self-service (click-through in the console); others require opening a support ticket to finish peering from Redis’s side.
- In the Redis Cloud UI:
-
Phase 3 – Point applications at the private endpoint
-
Once the connection is active:
- For VPC peering: Redis provides a private hostname or IP range. Your VPC routing sends traffic to Redis via the peering link.
- For PrivateLink / PSC: Redis appears as a private endpoint in your VPC; you get a private DNS name (often
*.privatelink.*equivalent).
-
Update application configs to use the private hostname instead of the public one.
-
Verify connectivity with a simple Redis CLI test from a host inside your VPC:
redis-cli -h <private-hostname> -p 6379 -a $REDIS_PASSWORD PING -
Watch your Prometheus/Grafana dashboards or built-in metrics: you should see lower network latency and traffic coming from private ranges.
-
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| VPC peering for Redis Cloud Pro | Connects your VPC and Redis Cloud VPC at the network layer with private IPs | Keeps Redis traffic on the cloud backbone with low, stable RTT |
| PrivateLink / Private Service Connect endpoints | Exposes Redis as a private endpoint inside your VPC | Strong isolation; no inbound paths from Redis into your VPC |
| Region-aligned private Redis Cloud VPC | Runs Redis close to your app in the same region | Minimizes cross-region hops and tail-latency for real-time apps |
Ideal Use Cases
- Best for latency-sensitive microservices: Because VPC peering and PrivateLink keep Redis traffic inside the provider’s private network, you get tighter p95/p99 latency and more predictable tail behavior for real-time APIs, queues, and counters.
- Best for regulated and enterprise workloads: Because there’s no public ingress path to Redis, it’s easier to satisfy “private network only” policies and reduce your exposed attack surface, especially when combined with Redis ACLs and TLS.
Limitations & Considerations
-
Region and provider constraints:
Private connectivity is region-specific and provider-specific. You typically can’t peer across regions or across clouds (for example, an AWS VPC peering to a GCP Redis Cloud deployment). Align your Redis Cloud Pro subscription with the same region and provider as your app. -
Routing, CIDR, and ops overhead:
- VPC CIDR ranges must not overlap with the Redis Cloud VPC ranges, or peering fails.
- You’ll need network/SRE involvement to manage route tables, security groups, and DNS.
- Warning: Misconfigured routes or security groups can look like Redis “down” when it’s actually a network block. Always test from a bastion host inside the peered VPC and check both Redis logs and cloud VPC flow logs.
Pricing & Plans
Private connectivity options such as VPC peering and PrivateLink-style endpoints are generally available on Redis Cloud Pro and higher tiers, sometimes as add-ons depending on region and provider.
Typical pattern:
- Redis Cloud Pro: Best for teams that need production-grade Redis with private connectivity, automatic failover, clustering, and strong SLAs—all on a dedicated Redis-managed VPC.
- Redis Cloud Ultimate / Enterprise add-ons: Best for organizations that also need Active-Active Geo Distribution, higher SLAs (up to 99.999%), and more complex network topologies (multi-region architectures, multiple VPCs, or shared services VPC patterns).
Note: Exact pricing and availability for VPC peering/PrivateLink vary by cloud provider and region. Confirm in the Redis Cloud console or with Redis sales if you’re planning a broad multi-account/multi-region rollout.
Frequently Asked Questions
Do I use VPC peering or PrivateLink for Redis Cloud Pro?
Short Answer: Use VPC peering when you want straightforward, private, bidirectional network connectivity. Use PrivateLink / Private Service Connect when you want a one-way, service-style endpoint exposed into your VPC with stricter isolation.
Details:
-
VPC peering:
- Simple, low-latency L3 connectivity between your VPC and Redis Cloud’s VPC.
- Routes are added in both directions; there’s no NAT or gateway in the path.
- Good fit for single-account or simple multi-account setups where you trust the network boundaries.
-
PrivateLink / PSC / Private Endpoint:
- Redis is exposed as a service endpoint in your VPC.
- Connectivity is typically one-way (from your VPC to Redis); Redis can’t initiate traffic back.
- Better for hub-and-spoke or large enterprise environments where you want to centralize access from many VPCs or accounts into a single private endpoint.
If you’re unsure, most teams start with VPC peering for a single region/app and move to a PrivateLink-style pattern when they centralize shared services or tighten compliance requirements.
Will enabling private connectivity affect my existing Redis endpoints?
Short Answer: It adds a new private path; you then migrate your apps to use the new private hostname instead of the public one.
Details:
- When you configure peering or PrivateLink, Redis Cloud Pro keeps your existing public endpoint available until you deliberately stop using it or disable public access.
- The safe migration path is:
- Set up the private connection.
- Test connectivity from a non-critical client inside your VPC.
- Roll out configuration changes to point production workloads at the private endpoint.
- Monitor p95/p99 latency and error rates using your Prometheus/Grafana dashboards or Redis’s monitoring.
- Once you’re confident, optionally lock down public access to reduce surface area.
- Warning: Don’t remove the public endpoint or tighten ACL/firewall rules until you’ve verified that all critical clients are using the private hostname (including background jobs, legacy services, and admin tooling).
Summary
Enabling private connectivity for Redis Cloud Pro with VPC peering or PrivateLink-style endpoints moves your Redis traffic off the public internet and onto your own cloud network. You get lower, more predictable latency for real-time and AI workloads, a cleaner security posture for compliance, and a topology that aligns with how modern microservices and platform teams think about “private-only” services. The flow is straightforward: align region/provider, configure peering or PrivateLink in Redis Cloud, then switch your apps to the private hostname while watching latency and error metrics.