用 NLB 静态入口 + 事件驱动自动化适配 RDS 私有 IP 变更
背景与问题
在跨账户、跨 VPC 共享数据库的场景中，消费方通常需要一个稳定、长期不变的私有入口。但 Amazon RDS 分配的私有 IP 并不稳定：故障转移、实例重启、stop/start 都可能导致私有 IP 发生变化。
RDS 官方建议始终通过 DNS 端点而非 IP 访问数据库。然而在通过 AWS PrivateLink 跨账户暴露数据库时，链路上必须使用 Network Load Balancer（NLB），而 NLB 的 IP 目标组只接受 IP 地址、不接受域名。这就形成了一个矛盾：消费方需要稳定的入口，后端的真实 IP 却随时可能改变。
本方案的目标，是将这种变化消化在 Provider 一侧，使其对消费方完全透明。
整体设计
整体架构可分为四层：消费侧、服务侧、自动化侧，以及将三者串联起来的端到端效果。
核心思路是：NLB 对外提供静态、不变的入口；自动化机制负责保证目标组中注册的 IP 始终指向当前正确的 RDS 实例。消费方访问的始终是同一个 PrivateLink 端点，后端 IP 的变化对其不可见。
消费侧（Consumer Network）
消费方账户中的 Application 与 Client 通过 AWS PrivateLink 访问数据库。
对消费方而言，连接信息一次配置、长期不变：一个 VPC Interface Endpoint，对应一个稳定的 DNS 名称。消费方既不感知 Provider 侧的 NLB 与 RDS，也不感知任何 IP 变化。所有复杂度都收敛在 Provider 内部。
服务侧（Provider VPC）
服务侧是数据通路的主干，自左向右依次为：
Endpoint Service → Network Load Balancer → IP 目标组 → RDS 主实例
- Endpoint Service 是 PrivateLink 在 Provider 侧的入口，必须挂载在 NLB 之前，这是 PrivateLink 的硬性要求。
- Network Load Balancer（NLB） 提供一组静态、不变的 IP 与 DNS，是对外承诺的稳定入口。无论后端如何变化，该入口保持不变。
- IP 目标组 是会发生变化的部分。图中标注的
Current target: RDS private IP表示目标组当前注册的是 RDS 主实例的私有 IP，该值由自动化机制改写，是整套机制的作用点。 - RDS 主实例 / Standby Failover 库：如图右上角批注所示，RDS 的私有 IP 会在故障转移、重启、stop/start 时发生变化。这是 RDS 的正常行为，方案需要适配而非规避。
单看这一层，通路虽然连通，但一旦 RDS IP 变化，目标组中注册的就是过期 IP，健康检查随即失败、连接中断。因此它必须配合下面的自动化机制才完整。
自动化侧（Automation）
自动化是将易中断链路转化为自愈链路的关键。触发源有两类，一被动一主动：
- RDS event：通过 RDS 事件订阅，在故障转移、重启等动作发生时立即产生事件，反应及时。
- Scheduled check：定时巡检作为兜底，覆盖未产生事件或事件漏发的情况。两者结合可兼顾时效与可靠性。
两类触发源统一汇入 Amazon EventBridge，由其路由至核心的 AWS Lambda（RDS IP Sync）。Lambda 被触发后完成三项工作：
- Resolve DNS + DescribeDBInstances：解析 RDS 端点 DNS、并调用
DescribeDBInstances查询实例信息，获取当前主实例真正的私有 IP。由于 DNS 始终指向当前主库，这是判断 IP 是否正确的权威来源。 - Register / Deregister Targets：将过期 IP 从目标组中移除，并注册新的 IP。
- 该动作通过图中 Update targets 路径作用到服务侧的 IP 目标组上，完成闭环。
值得注意的是，自动化部分与数据通路相互解耦。即便 EventBridge 或 Lambda 出现故障，已注册的目标组仍可正常转发流量，不会立即中断服务，仅暂时失去追踪新 IP 的能力。整体爆炸半径较小。
端到端流程（End-to-End Outcome）
将各层串联，一次完整的 IP 变更按如下流程被吸收：
- RDS 事件触发，或定时探针触发 —— 故障转移、重启发生，或巡检到点。
- Lambda 发现 RDS 最新的私有 IP —— 通过 DNS 解析与 API 查询获得权威结果。
- NLB 目标组被更新 —— 移除旧 IP、注册新 IP，健康检查恢复通过。
- 消费方继续使用稳定的私有端点 —— 全程无感，PrivateLink 端点不变。
从消费方视角看，过程无任何变化；从 Provider 视角看，一次潜在的连接中断已被静默消化。
落地注意事项
以下几点在实施时容易被忽略，但对方案成败影响较大：
- 以 DNS 为唯一可信源。 不缓存 IP，每次同步均从 RDS 的 DNS 端点重新解析。故障转移后内部 DNS 会指向新主库，这是判断当前主实例的依据。
- 事件驱动与定时巡检并用。 仅靠事件可能漏发，仅靠轮询则收敛较慢，两者叠加可兼顾时效与可靠性。巡检间隔应依据 RTO 要求确定。
- 合理配置 NLB 健康检查。 目标切换瞬间会出现短暂不健康，健康检查的阈值与间隔决定了流量切换至新 IP 的速度，过松收敛慢、过紧易抖动。
- 保证 Lambda 幂等。 事件与巡检可能在相近时间触发同一次同步，Lambda 应能识别目标组中已是正确 IP 的情形并跳过，避免重复 register/deregister 造成抖动。
- IAM 权限最小化。 Lambda 仅需
DescribeDBInstances，以及对特定目标组的RegisterTargets与DeregisterTargets权限。 - 关注跨可用区配置。 若主备位于不同 AZ，故障转移后新主库 IP 通常落在另一 AZ，需确认 NLB 已开启跨区负载均衡、目标组允许跨 AZ 注册，否则切换后将无法连通。
小结
方案的核心是将"变"与"不变"分开管理：NLB 对外提供永不变的静态入口，EventBridge 与 Lambda 在后台同步目标组中的 IP；中间通过 PrivateLink 完成跨账户的私有连接，消费方始终只访问同一个稳定端点。
该方案不改变现有 RDS 配置、不要求消费方做额外配合，可作为增量能力叠加在既有架构之上，具备低侵入、爆炸半径小、对使用方透明的特点。