Amazon SAA-C03: 网络与连接 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

属于 AWS SAA-C03 — 完整学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

VPC 设计与 CIDR 规划

每个 VPC 都始于一个 CIDR 地址块，创建时所做的选择会对后续的对等连接、Transit Gateway 连接以及混合云连接产生影响。主 CIDR 必须在 /16 到 /28 之间，从 RFC 1918 私有地址空间中选择，并且不得与您计划进行对等连接、通过 Transit Gateway 路由或通过 Direct Connect 或 VPN 访问的任何网络重叠。CIDR 地址重叠是导致混合云设计失败的最常见原因，因为 AWS 无法在共享地址空间的两个网络之间进行路由——Transit Gateway 会接受连接，但路由传播会失败或静默地将流量黑洞掉。

当 VPC 的地址空间耗尽时，您无需重建它。最多可以附加四个辅助 IPv4 CIDR 地址块（以及来自一个更广泛池的额外范围，默认总共五个，可通过提升配额来扩展）。辅助地址块可以来自相同的 RFC 1918 范围，也可以来自 100.64.0.0/10 共享地址空间，这在 10.0.0.0/8 已被耗尽或需要运营商级 NAT 空间时非常有用。辅助 CIDR 允许您为扩展（例如 EKS Pod 网络、新的应用层）划分新的子网，而无需对现有工作负载进行 IP 地址重编。

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

一个稳健的设计会为未来增长预留一个 /17 或 /18 的地址块，将子网边界与可用区对齐（每个层级在每个可用区使用一个 /20 的子网是一种常见模式），并为接口终端节点、NAT 网关和负载均衡器消耗的 ENI 预留空间。

VPC 是一种区域级资源，它被划分为多个子网，每个子网都绑定到一个单独的 AZ。“公有”和“私有”的区别纯粹是一个路由决策：公有子网有一条指向 Internet Gateway 的路由 0.0.0.0/0 → igw-xxxx，而私有子网要么没有默认路由，要么将其 0.0.0.0/0 指向一个 NAT 设备。公有子网中的实例还需要一个公有 IP 或 Elastic IP 才能被入站访问；IGW 在私有 IP 和公有 IP 之间执行 1:1 NAT。

NAT 网关、NAT 实例和 IPv6 出口

对于来自私有子网的、仅限出站的 IPv4 互联网访问，NAT 网关是正确的原生方案。托管式 NAT 网关可自动扩展至 45–100 Gbps，每个唯一目标支持 55,000 个并发连接，由 AWS 负责打补丁，并在其所在 AZ 内具有高可用性。NAT 网关按小时和处理的 GB 数据量计费。

NAT 实例——即禁用了源/目标检查的、自行管理的 EC2——是一种传统方案。它们受单个实例吞吐量的限制，必须通过脚本实现故障转移，并在持续负载下成为瓶颈。它们仅适用于非典型需求，如自定义过滤，即便如此，Gateway Load Balancer 虚拟设备通常是更好的选择。

经典的高可用模式是每个 AZ 一个 NAT 网关，每个网关位于该 AZ 的公有子网中，并为每个 AZ 配置一个独立的私有路由表，其默认路由指向本地的 NAT 网关：

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

部署一个跨 AZ 共享的 NAT 网关是一个常见的误区，原因有二。首先，它是一个单点故障：一个 AZ 的中断将导致每个私有子网的出站访问中断。其次，来自其他 AZ 实例的每个数据包都会跨越 AZ 边界，在 NAT 网关处理费用的基础上，还会产生跨可用区数据传输费用（目前为每 GB 单向 0.01 美元）。在有数百 TB 出口流量的工作负载上，这笔费用远超额外 NAT 网关的成本。第二个常见的错误配置是将 NAT 网关本身放置在私有子网中——这样它就没有通往 IGW 的路径，无法正常工作。

对于 IPv6，NAT 既不需要也不可用，因为每个 IPv6 地址都是全局可路由的。要允许仅 IPv6 出站流量同时阻止未经请求的入站流量，请附加一个仅出口互联网网关 (egress-only internet gateway)，并从私有子网将 ::/0 路由到它。常规的 IGW 是双向的，会暴露实例。

VPC 端点：网关 vs. 接口

VPC 端点可将您的 VPC 和 AWS 服务之间的流量保留在 AWS 骨干网上，从而完全避免使用互联网、NAT 网关和互联网网关。有两种根本不同的实现方式，混淆它们是最常见的架构错误之一。

网关端点仅适用于 Amazon S3 和 DynamoDB。它们是一个路由表条目——一个指向端点本身的前缀列表（例如，在 us-east-1 中 S3 的 pl-63a5400a）。没有 ENI，没有 DNS 变更，没有小时费用，也没有安全组（访问由路由表和端点策略控制）。由于它们是基于路由的，因此它们只适用于 VPC 内部的资源——通过 Direct Connect 访问 S3 的本地网络无法使用它们。

接口端点 (AWS PrivateLink) 是放置在您子网中的带有私有 IP 的 ENI，按可用区（AZ）每小时和每 GB 收费。它们几乎适用于所有其他服务——SQS、KMS、Secrets Manager、ECR、STS、SSM、SNS 等数百种服务——以及作为端点服务发布的第三方服务。接口端点支持私有 DNS，它会覆盖公共服务主机名以解析到端点的私有 IP，因此 SDK 和 CLI 无需更改代码。由于它们由 ENI 支持，因此安全组适用。

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

成本逻辑至关重要：默认情况下，任何从私有子网流向公共 AWS 服务的流量都会通过 NAT 网关，费用约为 0.045 美元/GB。对于每天向 S3 推送 1 TB 数据的容器化工作负载，NAT 网关路径和网关端点路径之间的差异每月可达数千美元。当接口端点大规模替代 NAT 出口流量或合规性要求禁止互联网路由时，它们是值得的。

陷阱：为网关端点附加安全组（它们没有 ENI）；假设网关端点可以从本地访问（实际上不能——应使用接口端点或混合模式 EC2 → S3 网关端点 → 独立的 DX 路径）；在接口端点上禁用私有 DNS 并期望未经修改的 SDK 调用能够工作（它们将通过互联网访问公共端点，完全违背了端点的初衷）；创建了网关端点但忘记关联私有子网的路由表（流量会静默地继续使用公共路径）；尝试为没有网关端点的服务（例如 KMS）使用网关端点——只有 S3 和 DynamoDB 支持。

VPC 间连接：对等连接 vs. 中转网关

VPC 对等连接是两个 VPC 之间的一对一、非传递性的第 3 层连接，可以跨相同或不同账户、相同或不同区域。流量通过 AWS 骨干网传输，没有带宽瓶颈，也没有小时费用——您只需为跨可用区或区域间的数据传输付费。两个特性限制了对等连接：(1) 它是非传递性的——如果 A 与 B 对等，B 与 C 对等，那么 A 无法通过 B 到达 C；(2) CIDR 范围不能重叠。要将 N 个 VPC 以全网状结构连接，需要 N(N-1)/2 个对等连接，并且每个连接都需要在双向编辑路由表；对于 30 个 VPC，这意味着 435 个对等连接。期望对等连接能扩展到数百个 VPC 是一个陷阱。

中转网关 (TGW) 是一个区域性云路由器。每个 VPC、VPN 或 Direct Connect 网关都是一个连接（attachment），TGW 路由表控制哪个连接可以到达哪个前缀。这将 O(n²) 的网状结构转换为 O(n) 的连接，并实现了中心辐射型拓扑，其中安全 VPC 可以托管防火墙来检查所有 VPC 间的流量。TGW 支持传递路由，原生终止 VPN 和 Direct Connect 网关关联，并可以通过 Resource Access Manager 在 AWS Organizations 间共享，以便中央网络团队控制路由，而工作负载账户拥有自己的 VPC。TGW 会增加每小时每个连接的费用以及大约 0.02 美元/GB 的处理费用。

对于跨区域连接，TGW 对等连接通过 AWS 全球骨干网将不同区域的 TGW 连接起来，流量经过加密——每个区域一个 TGW，以网状或中心辐射型设计进行对等连接。这避免了跨区域 VPC 对等连接会重新引入的 N 平方问题。

路由表的管理是这里的隐形杀手。创建一个对等连接或 TGW 连接本身并不会起任何作用，直到在两个 VPC 的子网路由表中添加指向 pcx- 或 tgw- 目标的显式 CIDR 路由，并且安全组允许该流量。静默的连接失败几乎总是可以追溯到路由缺失，或安全组中引用了错误的源 CIDR 而导致的隐式拒绝。

混合连接：Site-to-Site VPN 与 Direct Connect 对比

选择 Site-to-Site VPN 还是 Direct Connect，实际上是在“快速部署和内置加密”与“一致的低延迟、专用带宽和可预测的吞吐量”之间进行权衡。

Site-to-Site VPN 在客户网关（本地路由器）与 Virtual Private Gateway 或 Transit Gateway 之间建立两个 IPsec 隧道。每个隧道的上限约为 1.25 Gbps。流量在网络层加密，当与 TLS 结合使用时，可以满足网络层和会话层的加密要求。它通过公共互联网传输，因此延迟和抖动是可变的，但它可以在几分钟内就绪，每小时成本仅为几美分。当需要立即建立连接、带宽需求不大或用作备份路径时，应使用它。

Direct Connect (DX) 提供从本地路由器到 AWS Direct Connect 站点的专用光纤连接（1、10 或 100 Gbps）。它绕过公共互联网，从而实现一致的延迟和更高的吞吐量。DX 的出口流量定价远低于互联网出口流量，这在每天传输数百 GB 数据时尤为重要。预置过程需要数周时间——涉及交叉连接（cross-connects）、授权书（LOA）和 BGP 配置。

这里主要有两个陷阱。首先，单独使用 Direct Connect 不会加密流量。私有线路不等于加密保护的通道。要在 DX 上满足加密要求，需要在其上层叠加一个 Site-to-Site VPN，或者在支持的专用端口上使用 MACsec 进行第二层加密。其次，一个原始的 DX 连接本身无法路由到多个 VPC。一个私有 VIF 连接到单个 Virtual Private Gateway，而该网关又附加到单个 VPC。要访问多个 VPC——尤其是跨账户和跨区域的 VPC——需要使用 Direct Connect Gateway 通过 transit VIF 关联到 Transit Gateway，然后将每个 VPC 附加到该 TGW：

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

典型的生产模式是使用两个 DX 连接，分别位于两个 DX 站点并终止于不同的客户路由器，同时将 Site-to-Site VPN 作为自动 BGP 故障转移的备份——当 DX 正常工作时，通过 BGP AS-path prepending 或 MED 将流量引导至 DX；如果 DX 发生故障，BGP 会撤销 DX 路由，由 VPN 接管流量。

负载均衡器：ALB、NLB 和 GWLB

ALB 是第 7 层负载均衡器，理解 HTTP 语义——支持主机和路径路由、WebSockets、重定向、基于 cookie 的粘性会话。对于非 HTTP 的协议，如 MQTT、原始 TCP、基于 UDP 的 syslog、SMTP 等，它不是合适的工具。ALB 使用基于 DNS 的寻址方式，其 IP 地址会随时间变化；不能为其分配 Elastic IP。当客户端需要将目标 IP 加入白名单时，单独使用 ALB 是不合适的——应使用带 EIP 的 NLB，或者在 ALB 前面加上 Global Accelerator 提供的两个静态 Anycast IP。“解析一次 ALB 的 DNS 并将 IP 地址固定在防火墙规则中”是一个陷阱：AWS 会在不通知的情况下更改这些 IP。

NLB 是第 4 层负载均衡器，可扩展至每秒处理数百万个流。它默认保留真实的客户端源 IP（目标可以看到真实的客户端），支持为每个 AZ 分配一个静态 Elastic IP，并能处理高吞吐量的 TCP/UDP 工作负载。在过去，NLB 不支持在负载均衡器本身上配置安全组——客户端的 CIDR 必须直接在目标的安全组（SG）中被允许。AWS 在 2023 年为 NLB 添加了可选的安全组功能，但许多现有设计仍然基于其经典行为。

典型的面向公众的模式是：

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

在后端安全组中，将 ALB 的安全组作为源（而不是某个 CIDR）是最小权限原则的最佳实践，并且能自动覆盖来自 ALB 的 ENI 的健康检查流量。ALB 本身位于至少两个 AZ 的公有子网中（路由指向 IGW）；而目标则位于私有子网中。将面向互联网的 ALB 放置在私有子网中是一个典型的错误配置——目标注册会成功，但客户端无法访问它。

Gateway Load Balancer (GWLB) 是为透明地插入第三方虚拟设备（如防火墙、IDS/IPS、DPI）而专门构建的。它在第 3 层运行，使用 UDP 6081 端口上的 GENEVE 协议封装来转发所有 IP 协议。流量通过 GWLB 端点 (GWLBe) 到达 GWLB——GWLBe 是一个接口端点，位于子网中，并在路由表中显示为一个目标：

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

该端点通过 PrivateLink 将数据包转发到 GWLB，GWLB 使用流粘性在设备集群中进行负载均衡，以确保同一流的双向流量都命中同一个设备。在中心辐射型（hub-and-spoke）检查架构中，辐射 VPC 连接到一个 TGW，其路由表会强制东西向流量在到达目标 VPC 之前，先通过检查 VPC（包含 GWLB 和虚拟设备）。入口流量检查则使用边缘路由表，将从 IGW 到 Web 层的流量首先重定向到 GWLBe：

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

对于集中式、跨账户的流量检查，这是正确的解决方案——自己用 EC2、自定义路由表技巧和故障转移脚本来“造轮子”，只是在重复发明 GWLB 已原生提供的功能。

用于消费者到提供商服务的 PrivateLink

除了为 AWS 服务提供接口终端节点外，PrivateLink 还支持与第三方或其他 AWS 账户发布的服务建立私有连接。提供商将其服务置于 NLB 之后，并创建一个VPC 终端节点服务。消费者在自己的 VPC 中创建针对该服务的接口终端节点。

关键的方向性规则是：连接总是由消费者向提供商发起。 提供商无法向消费者的 VPC 发起连接。流量绝不会触及互联网，只有特定的目标服务是可达的（与 VPC 对等连接不同，后者会暴露整个提供商 VPC），并且由于两端只暴露终端节点 IP，因此不会出现 CIDR 重叠问题。对于消费者 VPC 没有 IGW、没有 VPN、也没有 Direct Connect 的 SaaS 或供应商数据库访问模式，这是典型的解决方案。VPC 对等连接会暴露整个 CIDR 范围并要求 IP 不重叠；TGW 连接的路由范围很广；通过互联网的公共 API 不是私有的。

Global Accelerator 和 Route 53

AWS Global Accelerator 分配两个静态任播 IPv4 地址，从全球 AWS 边缘站点进行通告。客户端流量从最近的边缘站点进入，并通过 AWS 骨干网传输到最近的健康区域终端节点（ALB、NLB、EIP 或 EC2）。这同时解决了两个问题：为 ALB 提供静态 IP（修复了白名单问题），以及通过绕行公共互联网为全球分布的用户减少抖动和延迟。它为那些不适用 CloudFront（用于缓存内容）的场景加速了不可缓存的 TCP/UDP 流量。

Route 53 解决的是另一个问题——DNS 级别的流量导向。Global Accelerator 影响的是数据平面本身；Route 53 只影响 DNS 解析，解析之后 TCP 连接会去往解析出的 IP 所在的任何地方。两者经常结合使用：一个 Route 53 别名记录指向一个 Global Accelerator，该加速器前端对接区域性的 ALB。

Route 53 路由策略：

延迟路由和地理位置路由经常被混淆：延迟路由旨在最小化用户感知的 RTT；地理位置路由则强制执行数据驻留要求，而不考虑延迟。多区域故障转移要求对主节点进行健康检查。别名记录是 AWS 特有的，可以直接解析到 ALB、NLB、CloudFront、S3 网站和 API Gateway 终端节点，无查询费用，并且——与 CNAME 不同——它可以在区域顶点（zone apex）使用。

Route 53 Resolver 通过 .2 地址（VPC CIDR 基地址 + 2）在 VPC 内部应答 DNS 查询。对于混合 DNS，入站终端节点允许本地解析器查询 AWS 中的私有托管区域；出站终端节点及转发规则允许 VPC 资源解析本地名称。如果没有这些，EC2 实例将无法解析 corp.internal，本地服务器也无法解析 db.prod.internal——这是一个细微的故障点，只有当应用程序开始跨环境查找时才会显现。接口终端节点需要启用私有 DNS，以使 SDK 调用能命中终端节点的 ENI；否则，调用仍会通过互联网访问公共终端节点，从而失去了使用接口终端节点的意义。

安全组、NACL 和最小权限

安全组是有状态的——返回流量会被自动允许——并在 ENI 级别上操作。NACL 是无状态的，在子网边界上操作。NACL 中的任何 TCP 规则都要求明确的入站和出站规则；因为客户端会从临时端口范围中选择一个源端口，所以返回方向的规则必须允许端口 1024–65535（Linux 默认使用 32768–60999；更宽的范围涵盖了 Windows 和其他技术栈）。忘记设置临时返回端口规则是导致连接在完成 SYN 后但在响应时挂起的典型原因。

为了在不同层级间实现最小权限，安全组规则应引用其他安全组 ID，而不是 CIDR。这可以与 Auto Scaling 一起扩展，并避免使用脆弱的 IP 白名单：

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL 是一种粗粒度的爆炸半径控制工具，不能替代安全组。为了“深度防御”而收紧 NACL，但没有相应地修改安全组，通常会破坏出站发起的流量（例如通过 NAT 网关进行的 yum/apt 更新），因为无状态的返回流量会被静默丢弃。路由表最终决定了可达性：即使安全组规则很宽松，如果路由表中缺少到目的地的条目，流量也无法送达；反之，只有当 S3 前缀列表路由实际安装在托管工作负载的子网的路由表中时，网关终端节点才有效。

决策参考

← 数据传输与迁移 · 所有领域 · 内容分发、边缘与性能优化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →