场景一 对外提供服务的标准架构
网页和 App 走 CDN + ALB，行情、下单这类实时接口直连 NLB；服务器自己上网则统一从 NAT 网关出去。
- 用户从来不直接连到 EC2：服务器在私有子网里，没有公网地址，只有负载均衡和 NAT 网关能碰到它。
- 同一个域名可以按用途分流——网页走 CDN + ALB，行情下单直连 NLB，各走各的最优路径。
- 两个可用区互为备份，一个机房整体故障时另一个继续服务，负载均衡会自动把流量都导过去。
场景二 多个园区互通，出网集中管理
生产、数据分析、共享服务各自一个 VPC，都接到 Transit Gateway；对外访问统一从共享服务园区出去，便于审计和管控。
- 每个园区只接中枢一次就能按需互通，再加一个园区也只是多接一根线，不用两两拉线。
- 谁能访问谁由中枢上的策略决定：分析园区可以读共享服务，但看不到生产数据库。
- 对外访问集中从一个园区出去，日志、防火墙规则、可用地址都只需要维护一份。
场景三 自建机房与云上打通（混合云）
本地机房通过专线接入 AWS，双向互访：本地系统调用云上服务，云上也能回写本地数据库。蓝线是去、绿线是回。
- 专线延迟稳定、波动小，适合数据库同步、批量数据回传这类怕抖动的流量。
- 一般再挂一条加密 VPN 作为备份（橙色路径），专线中断时流量自动切过去。
- 两边像同一个内网，可以按业务节奏逐步上云，不必一次性全部搬迁。
场景四 全球就近访问，区域故障自动改道
用户分布在世界各地，Route 53 把每个人指向最近而且健康的区域；主区域整体故障时，流量整体切到备用区域。
- 用户永远被指向「最近而且健康」的入口，切换发生在域名层面，客户端不用做任何改动。
- 两个区域之间用中枢对等互联做数据同步，走的是 AWS 自己的骨干网，不经公网。
- 切换通常几十秒内生效；事先确认备用区域的容量接得住，避免切过去反而被压垮。
场景五 对方只放行固定 IP：NLB 在前，ALB 在后
机构客户的防火墙只认固定 IP，但你又想按路径分流。做法是入口放 NLB（绑固定 EIP，IP 永不变），NLB 后面挂 ALB 去做七层路由。
- 1-4 域名解析到 NLB 的固定 EIP，客户防火墙只需要放行这一个地址；NLB 再把连接交给 ALB。
- 5-8 ALB 按 /order、/market 把请求分给不同的 EC2 组，各自读自己的库和缓存。
- 9-12 回程原路返回。ALB 之后换机器、加机器都不影响对外的那个 IP。
- 代价是多一跳（约几百微秒）和一份 NLB 费用；换来的是入口 IP 永远不变。
场景六 只给合作方开的接口：专线 + 内网 NLB，全程不碰公网
对方是机构，不接受走公网。用专线把两边内网打通，接口只挂在内网 NLB 上，公网上根本查不到、也连不上。
- 1-4 对接系统经客户网关走专线进 AWS，落到 Transit Gateway，再转发给内网 NLB。全程私有地址。
- 5-6 NLB 把请求交给私有子网的 EC2，EC2 读数据库。这些资源都没有公网地址。
- 紫色虚线：私有托管区负责把内网域名解析成 NLB 的私有 IP，对方用域名而不是硬编码 IP。
- 合作方只能访问这一个 NLB，看不到 VPC 里的其他任何东西；要更细的权限隔离可以再叠 PrivateLink。
场景七 一个统一入口，后面是多个业务 VPC
业务按团队拆成多个 VPC，但对外只想有一个域名、一个入口。入口 VPC 放 CloudFront + ALB，再经 Transit Gateway 把请求送到各业务 VPC。
- 1-5 对外只有一个域名：CloudFront → ALB → 鉴权层。加业务不用改域名，也不用再开一个公网入口。
- 6-8 鉴权通过后经 Transit Gateway 转到对应的业务 VPC。中枢上的路由决定谁能到谁，交易 VPC 和风控 VPC 互相不通。
- 9-10 各业务 VPC 自己闭环访问数据，数据不跨 VPC 裸奔。
- 11-12 响应原路回到边缘再返回用户；能缓存的内容留在边缘，下次不再打到入口 VPC。
场景八 灰度上云：Route 53 加权，先切 10% 流量
系统要从自建机房搬到云上，但不敢一次性切。用 Route 53 加权路由先放 10% 到云上，云上应用暂时还经专线读本地数据库，验证稳了再逐步加权重。
- 1 同一个域名在 Route 53 里配两条加权记录：2-5 一成流量进云上（CloudFront → ALB → 新版应用），6 九成还留在本地入口。
- 7-10 云上应用暂时还要读本地数据库，走 Transit Gateway + 专线回本地，延迟可控且不经公网。
- 11-13 云上这一支的响应正常返回用户。观察一段时间没问题，就把权重从 10% 调到 50%、100%。
- 最后一步才是把数据库也搬上云，切完再把专线降级成备份。权重随时可以调回 0，回滚成本很低。
场景九 跨区域灾备：双专线落两地，Route 53 健康检查自动切
机房拉两条专线分别落到两个区域，两个区域各自完整部署，数据库单向同步。主区域整体出问题时，Route 53 按健康检查把流量切到备区域。
- 1-4 正常情况：Route 53 把用户指向东京，ALB → EC2 → 主库，一条链路走完。
- 5-6 东京整体不可用时，健康检查失败，同一个域名解析改指新加坡的 ALB，客户端不用改任何配置。
- 7-10 本地机房两条专线分别落到两个区域的 Transit Gateway，任何一个区域接管时本地系统都能连上。
- 11 主库到只读副本单向同步，12 两地 TGW 对等互联，走 AWS 骨干网不经公网。
- 关键是平时就要在备区域留够容量（或用能快速扩容的方式），否则切过去照样撑不住。