VPC Peering
不走公网、不暴露端口、用私有 IP 直连——让缓存快得像和你的服务住在同一个机房里。下面这张图，就是它和「走公网」的区别。
VPC 是什么？Peering 又是什么？
VPC（Virtual Private Cloud，虚拟私有云）就是你在云上圈出的一块「自己的网络」。里面的服务器有各自的私有 IP，默认和别人的网络互不相通——像一个上了锁的院子。
而 VPC Peering（对等连接）做的事只有一件：把两个原本互不相通的院子，开一道只有彼此能走的门。打通之后，两边的机器可以用私有 IP 直接对话，就像它们本来就在同一个局域网里。
两栋独立的大楼，各有门禁。VPC Peering 就是在两栋楼之间修一条专用连廊——不用出门走大马路（公网），住户之间直接串门。而且这条连廊不共享：别人的楼接不进来。
只在 Redis Cloud Pro 提供。 VPC Peering 不支持 Essentials 套餐。如果你在 Essentials 上，需要先升级到 Pro（或考虑 Private Service Connect / PrivateLink 等其它私有连接方式）。
三个词：私有、低延迟、可控
Redis 是缓存和实时数据库，它对延迟极其敏感。把连接放进私有网络，既省掉了公网的绕行，也省掉了一整类安全风险。
私有
流量不经过公网，也不必把数据库端口暴露到互联网上。攻击面直接消失一大块。
低延迟
少了公网绕行和额外网关跳数，请求路径更短、更稳定，对缓存命中的收益最直接。
可控
配合 CIDR 允许列表和路由表，你精确决定谁能连、流量走哪条路。
关键只有两样：私有 IP + 路由表
Redis Cloud 的数据库跑在 Redis 自己的一个 VPC 里。当你发起对等连接，云厂商会在你的 VPC 和 Redis 的 VPC 之间建立一条对等链路。
但链路建好还不够。你还得在路由表里加一条规则：「凡是发往 Redis VPC 网段的流量，都从这条对等连接走」。数据包查到这条路由，就直接钻进私有隧道，抵达 Redis——这一步经常被忘记，也是「连不通」最常见的原因。
一条铁律：两个 VPC 的 CIDR 网段不能重叠。 否则路由器无法判断某个 IP 到底该发给哪一边。规划网段时就要错开，例如应用用 10.0.0.0/16，Redis 用 192.168.0.0/24。
在 AWS 上，三步搞定
配置并发起对等连接 · 在 Redis Cloud 控制台
进入 Subscriptions → 选择订阅 → Connectivity → VPC Peering → Add peering。填入这些信息，然后点 Initiate peering，记下 Peering ID。
批准对等请求 · 在 AWS 控制台
按 AWS 的指引接受这条 VPC peering 连接。当连接状态变为 active 后，回到 Redis Cloud，在顶部的绿色横幅里点 Modify my route tables now。
更新路由表 · 别漏了这步
在你那个应用 VPC 对应的路由表里，加一条路由：
完成后，把应用的连接串从公网地址切换到私有 endpoint——否则流量还是走公网，白配了。
在 Google Cloud 上，两步
GCP 是「两边都要发起」的对等模型——Redis 发出一半，你用 gcloud 从自己这侧把另一半接上。
配置并发起对等连接 · 在 Redis Cloud 控制台
Subscriptions → Connectivity → VPC Peering → Add peering。填入 GCP 的 Project ID 和要对等的 Network name。填完后，先复制那条 gcloud 命令（批准时要用），再点 Initiate peering，记下 Cloud peering ID。
批准对等请求 · 用 gcloud CLI
用 gcloud CLI 执行刚才复制的那条命令，从 Google 这一侧把对等请求接上。建立后，同样记得把连接串切换到私有 endpoint。
五个高频翻车点
把 Redis 请进隔壁房间
VPC Peering = 用私有 IP，把你的 VPC 和 Redis 的 VPC 直接连起来。省掉公网绕行，砍掉暴露风险，只留下一条又短又安全的路。
