3. AWS全球基础设施与网络基础

负载均衡和弹性伸缩并不是孤立存在的服务，它们最终都要落在具体的物理位置和网络边界之内。要理解为什么一个 ALB 能跨多个可用区分发流量、为什么 Auto Scaling 组需要指定子网、为什么安全组和 NACL 会同时影响访问结果，就必须先建立 AWS 全球基础设施与 VPC 网络的分层认知。本节从“资源放在哪里”和“流量怎么走”两条线索展开，为后续部署打好基础。

一、全球基础设施：Region、AZ 与 Edge Location

AWS 把全球基础设施划分为三个关键层级。最外层是 Region（区域），例如 ap-northeast-1（东京）、us-east-1（弗吉尼亚北部）。Region 是相互隔离的地理集群，每个 Region 内部拥有独立的电力和网络，跨 Region 通信必须经过公网或专线，因此 Region 决定了数据驻留、延迟基线和容灾半径。

Region 内部由多个 AZ（Availability Zone，可用区）组成。AZ 是同一区域内物理隔离的独立数据中心集群，拥有独立的供电、制冷和网络，但 AZ 之间通过低延迟、高带宽的私有光纤互联。东京区域通常有 3 个以上 AZ，例如 apne1-az1、apne1-az2、apne1-az3。AZ 之间的往返延迟一般在 1～2 毫秒量级，这使跨 AZ 的同步复制和负载均衡成为可行方案。弹性架构的核心原则就是：把实例分散到至少两个 AZ，避免单点故障。

最外层还有 Edge Location（边缘站点），它是 CloudFront、Route 53、Global Accelerator 等服务的接入点，数量远多于 Region，直接靠近终端用户。边缘站点不运行用户的 EC2 实例，而是负责缓存、DNS 解析和流量就近接入。理解这三层关系，就能明白：Region 决定合规与容灾，AZ 决定高可用，Edge Location 决定终端体验。

二、VPC 与子网：把资源放进正确的网络边界

VPC（Virtual Private Cloud）是你在 AWS 中独占的虚拟网络，需要指定一个 IPv4 CIDR 网段，例如 10.0.0.0/16，可提供约 65536 个地址。VPC 是区域级资源，但它本身不跨 AZ；真正跨 AZ 的是你在其中创建的子网。

子网（Subnet）是 VPC 网段的细分，必须绑定到某一个 AZ，不能跨 AZ。按访问能力分为两类：公有子网的路由表指向 Internet Gateway（IGW），其中的资源可拥有公网 IP 并与互联网双向通信；私有子网不直接指向 IGW，出站流量通常经 NAT Gateway 转发，外部无法主动访问其中的实例。典型三层架构会为每个 AZ 各建一个公有子网和一个私有子网，例如 10.0.1.0/24 与 10.0.11.0/24 位于 az1，10.0.2.0/24 与 10.0.12.0/24 位于 az2。

规划子网时要注意：AWS 会保留每个子网的前 4 个和最后 1 个地址，因此 /24 实际可用 251 个。ALB 至少需要两个不同 AZ 的子网，Auto Scaling 组也应把实例分散到多个子网，这正是弹性架构与网络规划直接耦合的地方。

三、路由表：决定流量往哪里走

路由表（Route Table）是一组路由规则，决定子网内流量去往哪个目标。每个子网必须关联一张路由表，未显式关联的子网使用 VPC 主路由表。路由表按最长前缀匹配选择规则，例如：

公有子网路由表 rt-public
  10.0.0.0/16   → local（VPC 内部互通）
  0.0.0.0/0     → igw-0a1b2c3d（Internet Gateway）

私有子网路由表 rt-private
  10.0.0.0/16   → local
  0.0.0.0/0     → nat-0e5f6a7b（NAT Gateway，位于公有子网）

如果私有子网实例需要访问外网下载补丁，却把 0.0.0.0/0 指向 IGW，就会因为私有子网没有公网路由能力而失败；反过来，公有子网若缺少 IGW 路由，实例即使有公网 IP 也无法出网。排查连通性问题时，路由表往往是第一个要看的对象。

四、安全组与 NACL：两道互补的防线

安全组（Security Group）作用于实例或 ENI 级别，是有状态的：你只配置允许规则，默认拒绝所有入站、允许所有出站；一旦允许了某条入站流量，其返回流量会自动放行，无需再写反向规则。安全组还支持引用其他安全组作为源，便于分层授权，例如让 Web 层安全组只接受来自 ALB 安全组的 80/443 端口。

NACL（Network ACL）作用于子网级别，是无状态的：必须同时配置入站和出站规则，且规则按编号从小到大匹配，一旦命中就停止，最后有一条默认拒绝所有（*）。NACL 支持显式拒绝，适合做子网级的粗粒度封禁，例如拒绝某个恶意网段。

五、为负载均衡与弹性伸缩做准备

把上述概念落到部署上，可以形成一条清晰的检查链。假设要在东京区域部署一个高可用 Web 服务，示例规划如下：VPC 使用 10.0.0.0/16；在 az1、az2 各建公有子网 10.0.1.0/24、10.0.2.0/24 和私有子网 10.0.11.0/24、10.0.12.0/24；公有子网路由 0.0.0.0/0 指向 IGW，私有子网指向 NAT Gateway；ALB 放在两个公有子网，Auto Scaling 组的实例放在两个私有子网；ALB 安全组开放 443 给 0.0.0.0/0，应用安全组只接受来自 ALB 安全组的 8080 端口。

这样做的结果是：ALB 天然跨两个 AZ，任一 AZ 故障时仍可分发流量；Auto Scaling 组在多个子网中启动实例，容量不足时可在健康 AZ 内扩容；私有子网实例不暴露公网，只能经 ALB 访问，安全边界清晰。后续配置目标组、健康检查、伸缩策略时，所有参数都建立在这套网络骨架之上。若网络规划有误，例如子网只覆盖一个 AZ、路由表指向错误、安全组未放行健康检查端口，负载均衡和弹性伸缩都会表现为“配置正确但不工作”。因此，先把 Region、AZ、VPC、子网、路由表、安全组和 NACL 的关系理顺，是后续所有工程操作的前提。