Amazon SAP-C02: 网络与混合连接 — 学习指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

VPC 架构与分段模式

设计 VPC 拓扑始于爆炸半径管理和可预测的路由。对于小型部署，采用包含多个子网和严格安全组的单一 VPC 模式可能很高效，但随着团队和应用的增长，单一 VPC 模式会变得脆弱：资源配额、跨团队治理以及“吵闹的邻居”都会增加运营风险。每个团队使用多个 VPC 或每个团队使用一个账户的模型可以改善隔离效果和 IAM 边界；使用 AWS Organizations 为团队创建独立的账户，并为 DNS、日志记录和身份认证设置一个共享服务账户。对于 VPC 间的连接，VPC peering 简单且延迟低，但它不具备传递性，并且在大规模部署时操作繁重。Transit Gateway (TGW) 取代了“中转 VPC”模式：它支持数千个连接（attachment），集中管理路由表，并简化了多播或中心辐射型（hub-and-spoke）模式。PrivateLink (接口 VPC 端点) 可以在不将服务暴露到互联网的情况下实现服务级别的隔离，这对于跨账户的微服务至关重要。常见的陷阱包括：仅依赖安全组进行分段（它们是状态化的，对于东西向流量过滤而言粒度较粗），忘记 NACL 的无状态行为，以及没有规划 CIDR 分配（重叠的 CIDR 会阻碍 peering 和 DX 的正常工作）。决策的关键在于成本与可管理性之间的权衡：TGW 有连接成本，但降低了每个 peering 的复杂性；多账户隔离增加了 landing zone 的开销，但减小了爆炸半径。务必记录 CIDR 规划、路由传播规则以及共享服务的所有权，以避免配置漂移。

混合连接、路由与弹性

混合连接的选择取决于吞吐量、抖动、延迟和一致的公网出口地址。对于大规模稳定流量，与 Internet VPN 相比，AWS Direct Connect (DX) 的私有 VIF 能提供确定性的带宽和更低的数据传出成本；使用 Direct Connect Gateway 可以跨越多个区域，或连接到 Transit Gateway 以实现集中式路由。Site-to-Site VPN（使用 BGP 的托管式 IPsec）可用于快速设置，或作为 DX 的弹性备份；配置 BGP 时需使用适当的 ASN 和路由优先级，以避免非对称路由。关键的路由陷阱包括：本地和云端 CIDR 重叠、TGW 中不正确的路由传播，以及假设流量可以在 peered VPC 之间传递路由。MTU 和分片问题可能会中断 VPN 流量——应测试路径 MTU 并在设备上调整 MSS。对于多区域架构，可以考虑在多个位置部署 active/active 模式的 DX，或者将 DX 与 VPN 故障转移相结合。权衡之处在于：专用的 DX 连接成本更高，但能减少抖动和出口费用；VPN 更便宜、更简单，但在高吞吐量下稳定性较差。为了实现可预测的故障转移，架构设计时应包含两条独立的隧道、位于不同位置的冗余 DX 连接，以及用于控制路径选择和限制的显式 TGW 路由表。

DNS、PrivateLink 与服务连接模式

DNS 是混合云和多账户网络的核心。使用 Route 53 Private Hosted Zones 进行 VPC 范围内的解析，并使用 Route 53 Resolver 的入站/出站端点，以实现在本地 DNS 和 AWS DNS 之间的条件转发。这支持分离水平 DNS（split-horizon DNS），即内部域名解析为私有 IP，而公共记录保持全局可用。PrivateLink（接口端点）为 AWS 服务或 SaaS 合作伙伴提供由 ENI 支持的私有连接，流量无需通过公共互联网路由；与之相对的是用于 S3 和 DynamoDB 的网关端点（Gateway Endpoints），后者成本更低，并且使用路由表而非 ENI。PrivateLink 避免了因 VPC CIDR 冲突而暴露服务的问题，并通过服务接受策略支持跨账户的消费者。常见的陷阱包括：忘记将私有托管区域关联到所有消费者 VPC，没有为本地域创建 Route 53 Resolver 规则，以及低估了每个端点 ENI 的 IP 地址消耗。决策标准：对于高吞吐量的 S3/DynamoDB 访问，优先选择网关端点以避免 NAT 成本；当需要以更严格的安全性私下访问 API 端点或第三方服务时，使用接口端点。监控 DNS 延迟，并通过变更控制来设置 TTL，以管理故障转移行为。

出口、NAT 设计、安全控制和运营实践

出口架构影响成本、可审计性以及与第三方的集成。NAT Gateway 为私有子网提供托管的、高可用的 IPv4 出口，并能按可用区（AZ）自动扩展；对于低吞吐量场景，NAT Instances 更便宜，但需要运营维护和故障转移脚本。通过连接到 Transit Gateway 的专用出口 VPC 来集中化出口流量，可以强制实现一致的出站 IP、检查点和简化的策略，但会引入发夹路由和潜在的带宽瓶颈。对于 IPv6，请使用 Egress-Only Internet Gateway。使用 AWS Systems Manager Session Manager 替代 SSH 堡垒机，以实现审计并消除公共入站凭证；Session Manager 通过 SSM agent 工作，无需开放 SSH 端口。如需高级过滤和深度包检测（DPI），可在 TGW 之后部署 AWS Network Firewall 或第三方设备。成本与性能的权衡：NAT Gateway 易于使用，但会产生每 GB 的费用——使用 VPC endpoints 可以减少 S3 出口流量和 NAT 成本。运营陷阱包括：未启用 VPC Flow Logs 进行流量故障排查，保留可能导致数据泄露的宽泛出口规则，以及使用无意中阻止生命周期操作的 SCPs 或 IAM 策略；应强制执行最小权限原则，并将所有日志记录到中央账户进行分析。

实践问题：Acme 金融服务公司 — 为第三方白名单实现集中且可预测的出口

场景：Acme 金融服务公司在两个 AWS 区域运行多个应用 VPC，这些 VPC 通过一个 Transit Gateway 连接，并通过 Direct Connect 和 VPN 与本地数据中心相连。不同账户中的多个应用程序必须调用一个合作伙伴 API，该 API 只接受来自单个公共 CIDR 块的请求。

挑战：为所有跨区域的应用 VPC 提供一个高可用、可审计的出口路径，该路径具有一个可预测的单一公共 CIDR 块，同时最大限度地减少延迟和运营开销。

推荐方法：

使用 BYOIP (Bring Your Own IP) 将一个公共 IPv4 CIDR 引入 AWS，并从该 CIDR 中分配 Elastic IPs 作为出口地址。
在每个区域构建一个集中式出口 VPC，其中包含位于多个可用区（AZ）的 NAT Gateway；将 BYOIP Elastic IPs 与这些 NAT Gateway 关联，并将出口 VPC 连接到 Transit Gateway。
更新 TGW 路由表，使所有应用 VPC 将 0.0.0.0/0 路由到出口 VPC 连接点，启用路由传播和跨可用区的健康检查故障转移；根据需要配置本地路由以优先选择本地出口。
在出口 VPC 中部署 Network Firewall 或托管的 IDS 进行出站过滤，启用 VPC Flow Logs 和 CloudWatch 警报，并使用 Route 53 Resolver 满足任何 DNS 转发需求。

理由：通过 TGW 和 NAT Gateway 集中化出口，并使用 BYOIP 提供的 IP 空间，可以为白名单提供一个可预测的 CIDR，同时保持高可用性和集中监控。这种方法在运营简单性、安全控制和满足合作伙伴对单一公共 CIDR 的要求之间取得了平衡。

← 组织复杂性与多账户策略 · 所有领域 · 安全、身份与合规性 →

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