手册

许多 VPC 之间的全网状连接，其中一些具有重叠的 CIDR。

→部署 Transit Gateway。通过向受影响的 VPC 添加唯一的辅助 CIDR 块来纠正重叠的 CIDR。

原因: Transit Gateway 提供可扩展的、传递性路由，但无法在重叠的 IP 范围之间路由。需要进行 IP 纠正。

高吞吐量、低延迟、弹性的混合连接。

→在两个不同的 Direct Connect 位置预置两个专用的 Direct Connect 连接。

原因: 使用两个不同位置可以防止位置级别的故障（光纤中断、断电），从而提供最大的弹性。即使有多个连接，单个位置也是单点故障。

本地部署和 AWS 私有托管区域之间的双向 DNS 解析。

→使用 Route 53 Resolver。创建入站端点供本地查询 AWS。创建出站端点并配置转发规则，供 AWS 查询本地。

原因: 入站端点为本地 DNS 转发器提供可达的 IP。出站端点支持从 VPC 内部进行条件转发。VPC 默认解析器 (VPC+2) 无法从本地访问。

在两个 VPC 之间提供服务级访问，而无需创建网络层路由。

→使用 AWS PrivateLink。在提供商 VPC 中创建 VPC Endpoint Service（由 NLB 支持），并在消费者 VPC 中创建 Interface VPC Endpoint。

原因: PrivateLink 利用消费者 VPC 中的 ENI 提供单向、特定于服务的连接，完全避免了网络级路由和 CIDR 重叠问题。

为私有子网中支持 IPv6 的实例提供仅出站互联网访问。

→创建仅出站 Internet Gateway (EIGW)，并在私有子网的路由表中添加指向 EIGW 的 `::/0` 路由。

原因: EIGW 对出站 IPv6 连接是状态化的，允许返回流量，但阻止未经请求的入站连接，类似于 NAT Gateway，但用于 IPv6。

使用 Transit Gateway 在集中式模型中，通过 AWS Network Firewall 检查所有 VPC 间流量。

→创建带有 Network Firewall 的专用检查 VPC。配置 TGW 路由表，将所有 VPC 间流量发送到检查 VPC。在检查 VPC 内，路由表必须将流量引导至 NFW 端点以实现对称路由。

原因: 此架构需要仔细路由：TGW 将流量发送到检查 VPC；VPC 路由表将其发送到防火墙端点；防火墙将其发送回 TGW 附件 ENI；TGW 将其路由到最终目的地。

使用 Transit Gateway 对 VPC 进行分段（例如，生产与开发），同时允许两者访问共享服务 VPC。

→使用多个 Transit Gateway 路由表。为每个分段（生产、开发、共享）创建一个路由表。将 VPC 与其各自的表关联。传播路由以创建轮辐拓扑，其中辐条只能看到轮毂。

原因: TGW 路由表关联和传播是网络层网络分段和流量隔离的主要机制。

降低托管在单个区域的动态、不可缓存的全球应用程序（例如 API、游戏）的延迟。

→使用 AWS Global Accelerator。它提供任播 IP，将用户路由到最近的 AWS 边缘站点，然后流量通过优化的 AWS 骨干网传输到源站。

原因: Global Accelerator 优化了 AWS 网络上的“第一英里”和“中间英里”，减少了 TCP/UDP 流量的延迟和抖动。CloudFront 更适合缓存内容。

提供从 VPC 到 S3 和 DynamoDB 的私有访问，无需通过互联网。

→为 S3 和 DynamoDB 创建 Gateway VPC Endpoint。这将向指定的子网路由表添加前缀列表条目。

原因: Gateway endpoint 是 S3 和 DynamoDB 私有访问的特定、高性能且免费的机制。其他服务使用 Interface Endpoint (PrivateLink)。

从单个本地 Direct Connect 连接访问多个 AWS 区域中的 VPC。

→使用带有中转虚拟接口 (T-VIF) 的 Direct Connect Gateway。将 DX Gateway 与每个所需区域中的 Transit Gateway 关联。

原因: 带有 DX Gateway 的中转 VIF 是连接跨区域多个 Transit Gateway 的可扩展解决方案。带有 DX Gateway 的私有 VIF 具有较低的限制。

集成第三方虚拟防火墙设备以进行透明流量检查。

→使用 Gateway Load Balancer (GWLB)。它在第 3 层运行，并使用 GENEVE 协议封装流量，保留原始源/目标 IP。

原因: GWLB 的 GENEVE 封装使其成为“线中块”，透明地将设备插入网络路径，而无需源 NAT，这对于安全设备至关重要。

在多账户组织中管理数百个 VPC 的 IP 地址分配，以防止重叠并跟踪使用情况。

→使用 Amazon VPC IP Address Manager (IPAM)。创建顶级池并委托区域池以自动化 VPC CIDR 分配。

原因: VPC IPAM 是专为集中式 IP 地址管理而构建的可扩展 AWS 服务，取代了易出错的手动方法。

使用 GRE 隧道和动态 BGP 路由将第三方 SD-WAN 设备与 Transit Gateway 集成。

→使用 Transit Gateway Connect 附件。

原因: TGW Connect 专为 SD-WAN 集成而设计。它支持 GRE 以提供更高的带宽（每个对等体高达 5 Gbps）和 BGP 以实现动态路由。

仅支持 IPv6 的 VPC 需要与互联网上的仅支持 IPv4 的资源进行通信。

→在 VPC 的 Route 53 Resolver 设置中启用 DNS64，并在公共子网中配置 NAT Gateway。将 `64:ff9b::/96` 路由到 NAT Gateway。

原因: DNS64 为 IPv4 目的地合成 AAAA 记录。NAT Gateway 执行从合成的 IPv6 地址到真实 IPv4 地址的 NAT64 协议转换。

连接跨多个区域的数百个 VPC，并具有严格的分段要求（生产、开发、共享服务）。

→使用 AWS Cloud WAN。在单个核心网络策略中定义分段和分段操作，以在全球范围内控制分段间路由。

原因: Cloud WAN 提供集中式、声明性的全球网络策略，与在每个区域管理 Transit Gateway 对等连接和路由表的完整网状结构相比，更具可扩展性且复杂性更低。

在单个位置聚合多个 Direct Connect 连接，以增加带宽和链路冗余。

→配置链路聚合组 (LAG)。所有连接必须具有相同的带宽并终止在同一个 AWS 设备上。

原因: LAG 将物理链路捆绑到一个逻辑链路中。这提供了链路级故障转移，但不能防止设备或位置故障。使用 `minimum links` 定义故障转移阈值。

为多区域应用程序实现低于 60 秒的 DNS 故障转移。

→使用带健康检查的 Route 53 故障转移路由。配置快速间隔（10 秒）健康检查和低故障阈值（1）。使用 Alias 记录或非常低的 TTL（例如，10-60 秒）。

原因: 快速故障转移需要快速检测（快速健康检查）和快速客户端更新（低 TTL 或具有动态 TTL 的 Alias 记录）。

通过同时使用 Site-to-Site VPN 连接的两个隧道来提高聚合 VPN 吞吐量。

→将 VPN 附加到 Transit Gateway。在 Transit Gateway VPN 附件上启用 ECMP 支持。

原因: 默认情况下，VPN 到 TGW 可能只使用一个隧道。如果在 BGP 路由成本相等的情况下，在 TGW 附件上启用 ECMP 可以将流量分布到两个隧道。

确保 Network Load Balancer 后端的 TCP 服务能看到原始客户端 IP 地址。

→按实例 ID 注册目标。如果目标按 IP 注册，请在目标组上启用 Proxy Protocol v2。

原因: 当目标按实例 ID 注册时，NLB 默认保留客户端 IP。如果按 IP 注册，NLB 的 IP 将成为源 IP，需要 Proxy Protocol v2 来传递原始 IP。

当存在多个 Direct Connect 路径时，影响 AWS 如何将流量路由回本地网络。

→在本地路由器中，对不优选的路径使用 BGP AS 路径预置。

原因: 对于从 AWS 出站的流量，客户控制的主要机制是 AS 路径长度。AWS 优先选择 AS 路径最短的路径。您无法在 AWS 侧配置本地首选项。

使 AWS 组织中的分支账户能够将其 VPC 附加到由中央网络账户拥有的 Transit Gateway。

→使用 AWS Resource Access Manager (RAM)。网络账户将 Transit Gateway 与组织或特定组织单位 (OU) 共享。

原因: RAM 是专为跨账户共享 Transit Gateway 等资源而设计的 AWS 服务。这允许集中管理，同时为分支账户启用自助服务附件。

聚合吞吐量超过单个 VPN 隧道 1.25 Gbps 的限制。

→创建多个 Site-to-Site VPN 连接到启用了 ECMP 的 Transit Gateway。

原因: 每个 VPN 隧道限制为约 1.25 Gbps。要扩展，您必须使用多个隧道/连接，并在 Transit Gateway 上利用 ECMP 在它们之间进行负载均衡。

为内部的、非面向互联网的资源（如内部 ALB）配置 Route 53 健康检查。

→创建一个 CloudWatch 警报，该警报监控内部资源的指标（例如，ALB 的 `HealthyHostCount`）。配置 Route 53 健康检查以监控 CloudWatch 警报的状态。

原因: Route 53 健康检查器是外部的。要监控内部资源，它们必须监控代理信号，如 CloudWatch 警报状态，该状态可以由内部指标触发。

当主源（例如 ALB）返回 5xx 错误时，自动将 CloudFront 流量故障转移到辅助源（例如静态 S3 站点）。

→创建 CloudFront 源站组，将 ALB 作为主源，S3 作为辅助源。将其配置为在指定的 HTTP 状态码（例如 500、502、503、504）下进行故障转移。

原因: 源站组是 CloudFront 实现高可用的原生机制，在边缘提供无缝故障转移，无需更改 DNS。

为 Direct Connect 连接到备份 VPN 或辅助 DX 路径实现亚秒级故障转移。

→在 Direct Connect 虚拟接口上启用双向转发检测 (BFD)。在本地路由器上配置 BFD。

原因: 与 BGP keepalive 计时器（默认 90 秒）相比，BFD 提供更快的链路故障检测（低至 300 毫秒），从而实现快速流量收敛。

在两个不同区域的 Transit Gateway 之间启用连接。

→建立 Transit Gateway 对等连接。在每个 TGW 路由表中手动添加静态路由，通过对等附件指向远程区域的 CIDR。

原因: 重要的是，Transit Gateway 跨区域对等连接不支持动态路由传播。所有跨区域路由都必须静态配置。

通过识别特定的阻塞组件（例如路由、NACL、SG），解决 AWS 内部的连接问题。

→使用 VPC Reachability Analyzer。指定源和目标，它将对网络路径配置执行静态分析。

原因: Reachability Analyzer 提供对 AWS 网络构造的明确的逐跳分析，这比 traceroute（可能无效）或手动检查每个组件更有效。

用于合规性的详细 VPC 流日志的长期存储和即席查询。

→以 Parquet 格式和自定义字段布局直接将流日志发布到 S3。使用 Amazon Athena 进行基于 SQL 的即席查询。

原因: S3 是最具成本效益的存储。Parquet 格式对于 Athena 查询非常高效，可降低扫描成本并提高性能。这是流日志分析的无服务器、可扩展模式。

在 AWS 组织中的所有 VPC 上集中执行强制安全组规则并自动补救不合规项。

→使用 AWS Firewall Manager 和安全组审计策略。定义所需规则并配置策略以自动补救不合规组。

原因: Firewall Manager 是跨组织的安全策略（WAF、SG、NFW）的集中治理工具。其具有自动补救功能的审计策略提供了强制执行能力。

可视化和监控跨区域和账户的全球网络拓扑，包括 Transit Gateway、VPN 和 Direct Connect。

→使用 AWS Network Manager。将 Transit Gateway 注册到一个全球网络中，以获得集中式仪表板、拓扑图和健康监控。

原因: Network Manager 专为复杂的全球 AWS 网络提供单一管理平面而构建，整合了监控和管理。

诊断 Direct Connect 连接上的间歇性数据包丢失或错误。

→检查 Direct Connect CloudWatch 指标 (`ConnectionErrorCount`)。在客户路由器上，检查光信号电平（Tx/Rx 光电平）和接口错误计数器（CRC 错误、输入错误）。

原因: 数据包丢失可能是物理层问题。需要 AWS 侧指标和客户侧路由器诊断来隔离问题，例如光纤电缆或收发器性能下降。

自动检测和修复不合规的网络配置，例如允许公共 SSH 访问的安全组。

→将 AWS Config 与托管规则（例如 `restricted-ssh`）结合使用，并使用 SSM 自动化文档配置自动修复操作。

原因: 这提供了一个闭环合规系统。AWS Config 检测到违规，其修复操作触发 SSM 文档以自动修复配置。

主动识别从互联网或其他不受信任网络到敏感资源的不当网络访问路径。

→使用 VPC Network Access Analyzer。定义访问范围并运行分析以获取所有匹配的网络路径列表。

原因: 此工具执行正式的网络验证，分析所有组件（SG、NACL、TGW、IGW）以查找潜在路径，这比手动检查或被动监控更全面。

将来自许多成员账户的 VPC 流日志、DNS 查询日志和网络防火墙日志收集到中央日志记录账户中。

→配置成员账户中的服务，使用跨账户存储桶策略和 IAM 角色，将日志直接发布到日志记录账户中的集中式 S3 存储桶（用于流日志/NFW）或 CloudWatch 日志组（用于 DNS 日志）。

原因: 直接跨账户日志发布是最有效和可扩展的模式，利用原生 AWS 功能，无需代理或复杂的数据管道。

在 Transit Gateway 轮辐架构中，优化特定 VPC 对之间高流量的网络成本。

→对于高流量的 VPC 对，创建直接的 VPC 对等连接以绕过 Transit Gateway。保留 TGW 用于所有其他轮辐流量。

原因: VPC 对等连接没有每 GB 数据处理费用（只有标准数据传输），而 Transit Gateway 有。将高容量点对点流量转移到对等连接可以显著降低成本。

在第 2 层加密 Direct Connect 流量以实现线速性能。

→启用 MACsec (IEEE 802.1AE)。需要在支持 MACsec 的位置提供专用的 10Gbps 或 100Gbps 连接。

原因: MACsec 在客户路由器和 AWS 设备之间提供逐跳加密，以最小的性能开销保护物理链路。

保护 Web 应用程序免受常见攻击（SQLi、XSS）并按国家/地区限制访问。

→使用 AWS WAF。将 Web ACL 附加到 ALB/CloudFront。使用 AWS 托管规则组（例如 `AWSManagedRulesSQLiRuleSet`、`AWSManagedRulesCommonRuleSet`）并创建地理匹配规则。

原因: AWS 托管规则为常见威胁提供开箱即用的保护，而地理匹配规则提供地理控制。这是标准的 WAF 实现模式。

在 VPC 中实施多层应用程序隔离（例如，Web -> 应用程序 -> 数据库）。

→为每个层创建安全组。在规则中使用安全组 ID 引用（例如，app-sg 允许来自 web-sg 的入站流量）。

原因: 引用安全组比使用 CIDR 范围更动态和安全。它会随着实例从层中添加或删除而自动适应。

监控和检测基于 DNS 的威胁，例如 DNS 隧道和与 C2 服务器的通信。

→启用 Route 53 Resolver 查询日志记录。启用 Amazon GuardDuty，它将 DNS 查询日志作为数据源进行分析。

原因: GuardDuty 具有内置的威胁情报，可分析 DNS 日志以检测已知的恶意域、DGA 和异常查询模式，这些模式表明数据泄露。

确保 S3 内容只能通过 CloudFront 访问，而不能直接通过 S3 URL 访问，同时仍允许其他 IAM 主体访问。

→使用源访问控制 (OAC)。更新 S3 存储桶策略，允许来自 OAC 服务主体和任何其他所需 IAM 角色/用户的访问。

原因: OAC 是 OAI 的现代替代品。它创建了一个可在存储桶策略中引用的服务主体，提供更精细和灵活的访问控制。

阻止用户绕过 CloudFront 直接访问 ALB 源站。

→配置 CloudFront，在源站请求中添加带有秘密值的自定义 HTTP 标头。创建 ALB 侦听器规则，检查此标头和值，阻止没有此标头和值的请求。

原因: 这提供了比基于 IP 的限制（使用托管前缀列表）更强的保护，因为它验证请求来自您的特定分发。两者结合使用可实现纵深防御。

在不安装代理的情况下，从特定的 EC2 实例捕获完整的网络数据包数据以进行取证分析。

→使用 VPC 流量镜像。在实例的 ENI 上配置镜像会话，将流量复制到目标（例如，NLB 前置的分析工具）。

原因: 流量镜像提供无代理的完整数据包捕获，这对于深入的取证分析至关重要。流日志仅提供元数据。

为面向公众的应用程序提供全面的 DDoS 防护。

→订阅 AWS Shield Advanced。将保护与关键资源（CloudFront、ALB、EIP、Route 53）关联。使用 AWS WAF 进行第 7 层缓解。在攻击期间与 Shield 响应团队 (SRT) 合作。

原因: Shield Advanced 提供增强的检测、针对 DDoS 引起的扩展的成本保护，以及获得 SRT 专家协助的权限，这对于业务关键型应用程序至关重要。

从私有证书颁发机构为内部微服务颁发和自动轮换 TLS 证书。

→使用 AWS Private Certificate Authority (Private CA) 创建 CA。使用 AWS Certificate Manager (ACM) 颁发和管理该 CA 颁发的私有证书的生命周期（包括自动续订）。

原因: 这种组合提供了一个完全托管的私有 PKI 解决方案，自动化了内部证书的复杂生命周期，而无需公开。

阻止 AWS 组织中任何成员账户的任何用户创建或附加 Internet Gateway。

→在组织根目录应用服务控制策略 (SCP)，拒绝 `ec2:CreateInternetGateway` 和 `ec2:AttachInternetGateway` 操作。

原因: SCP 提供预防性护栏，不能被成员账户中的 IAM 策略覆盖，使其成为强制执行组织范围安全策略的最终工具。

使用 AWS Network Firewall 解密和检查 HTTPS 流量以查找威胁，然后重新加密。

→在 ACM 中创建或导入 CA 证书。在防火墙策略中创建引用此 CA 的 TLS 检查配置。将 CA 证书分发给客户端系统作为受信任的根 CA。

原因: Network Firewall 通过中间人方法执行 TLS 检查，使用您提供的 CA 动态重新签名证书。客户端必须信任此 CA 以避免证书错误。

阻止 AWS 组织中所有 VPC 对已知恶意域名的 DNS 查询。

→在中心账户中使用 AWS 托管域名列表创建 DNS Firewall 规则组。通过 RAM 共享规则组，并将其与成员账户中的 VPC 关联。

原因: DNS Firewall 提供托管的、可集中更新的威胁情报，以在 DNS 解析层阻止恶意域名，这是一项关键的安全控制。

加密同一 VPC 中 EC2 实例之间的所有网络流量，无需更改应用程序。

→使用基于 AWS Nitro System 的实例类型。

原因: Nitro 实例在硬件级别自动加密实例之间的所有流量，提供透明的线速加密，无需配置。