Amazon ANS-C01: 网络性能与监控 — 学习指南
属于 AWS Advanced Networking Specialty ANS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
增强网络和低延迟网络架构
AWS 中的增强网络是一套操作系统和虚拟机管理程序级别的功能，可显著提高每秒数据包数（PPS）、降低延迟和 CPU 开销，并为每个虚拟接口提供更高的吞吐量。主要技术包括 Elastic Network Adapter (ENA) 和 Elastic Fabric Adapter (EFA)。ENA 为大多数现代 EC2 实例系列提供基于 SR-IOV 的高性能网络。EFA 是一种绕过操作系统 (OS-bypass) 的类 RDMA 设备，专为 HPC 和紧密耦合的 MPI/libfabric 工作负载而设计。要启用 ENA，您需要确认实例类型支持 ENA，并且 Linux AMI 已安装 ENA 驱动程序；您可以通过编程方式使用 EC2 API 调用（例如在需要时使用 InterfaceType=efa 的
undefined
）或使用
undefined
来启用或查询 ENA 支持。EFA 的附加方式是创建一个 InterfaceType=efa 的网络接口 (
undefined
) 或使用启用了 EFA 的网络接口启动实例；该实例必须运行受支持的内核和 libfabric/efa 内核模块，并且通常需要放置在集群置放群组中，以获得最低的主机内延迟和最高的对分带宽。
置放群组通过控制实例在底层网络架构中的位置来影响性能。集群置放群组倾向于将实例放置在单个机架或低延迟网络域中，以实现最大的东西向带宽和一致的延迟——这对于许多 EFA 用例是必需的。分散置放群组强制实施主机级别的分散以避免相关性故障，但不会改善延迟。对于突发性高吞吐量场景，实例系列和 vCPU 数量定义了基准网络带宽配额；例如，某些实例大小宣称提供高达 25 Gbps 或 100 Gbps 的带宽，但如果没有 ENA/EFA，数据包处理和 TCP 协议栈可能会成为瓶颈。在为数千个并发 TCP 连接（例如，gRPC over TLS）进行架构设计时，应选择具有高并发连接能力的实例类型，启用 ENA，并且在 EKS 中运行时优先选择 NLB / target-type=ip 以实现直接 Pod 寻址，从而避免节点端口瓶颈。
用于可观测性与策略执行的关键服务和配置
监控网络健康状况和诊断瓶颈依赖于 VPC Flow Logs、CloudWatch 指标、Traffic Mirroring 以及 Reachability/Access Analyzer 的组合。VPC Flow Logs 提供每个流的元数据（源/目的 IP、端口、数据包数、字节数、操作），您可以将其发送到 CloudWatch Logs 或 S3，并使用 CloudWatch Logs Insights 进行查询，以查找大流量前缀或通信量最大的来源。对于实时的数据包级检查，Traffic Mirroring 允许您创建一个镜像目标和一个筛选器，然后创建会话 (
undefined
,
undefined
)，将流量从 ENI 复制到运行在 EC2 中的检查设备或 AWS Network Packet Broker 合作伙伴。
CloudWatch 公开了不同层级的相关指标：EC2 实例指标，如
undefined
和
undefined
；AWS/ApplicationELB 下的 Application Load Balancer 指标，如
undefined
、
undefined
和
undefined
；AWS/NetworkELB 下的 Network Load Balancer 指标，如
undefined
和
undefined
；以及用于虚拟接口
undefined
的 AWS/DirectConnect 指标。使用 CloudWatch Alarms 和针对流日志的 Contributor Insights 来检测饱和流。对于路径和配置验证，Reachability Analyzer (通过 EC2 API
undefined
/
undefined
) 允许您对穿越路由表、NACL、安全组以及 VPN/Direct Connect 连接的端到端数据包路径进行建模和测试，而 Network Access Analyzer 则帮助您检测跨 VPC 和 AWS Organizations 的意外网络访问路径。
围绕负载均衡和安全访问的设计模式与权衡
当您需要真正的端到端 TLS、在后端实现双向 TLS (mTLS)，同时支持数千个 gRPC 连接时，首选的设计模式是使用 TCP 模式的 Network Load Balcer。NLB 默认会保留客户端的源 IP，并且可以通过 AWS Load Balancer Controller 为 EKS 服务创建，使用诸如 service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" 和 target-type=ip 这样的注解来将流量直接发送到 Pod IP。在 443 端口上使用 TCP 直通意味着后端 Pod 将终止双向 TLS（客户端和服务器证书验证），因此流量永远不会在负载均衡器中被解密，从而保留了双向身份验证。这种模式能够很好地扩展连接数，因为 NLB 的设计目标是支持数百万的并发连接和较低的单连接开销。
对于需要在负载均衡器上进行 TLS 终止并需要基于路径路由到多个目标组的架构，Application Load Balancer 是正确的选择，因为它支持 HTTP/2 和 gRPC、基于路径的路由以及基于主机的规则。为了在 ALB 终止 TLS 时提供准确的客户端 IP 日志记录，请确保后端应用程序解析 X-Forwarded-For 标头（ALB 会自动注入），或者如果您需要在 TCP 层保留源 IP，则将 NLB 与 PROXY 协议结合使用。如果您使用 Global Accelerator 来提供静态任播前端 IP，并希望防止客户端绕过加速器直接访问 ALB 的 URL，请锁定 ALB 的安全组，使其只接受来自加速器静态 IP（分配给加速器的两个静态地址）的入站流量，从而拒绝直接的互联网访问。
对于具有严格的按业务单元控制和扩展需求的多账户共享服务，AWS PrivateLink（由内部 NLB 支持的 VPC Endpoint Services）通常是最安全和可扩展的模式。共享服务所在的 VPC 通过 Network Load Balancer 端点（使用 aws ec2 create-network-interface 和目标组）发布服务，并将其作为 VPC Endpoint Service 暴露出来。服务消费者账户在自己的 VPC 中创建接口端点，这些端点会连接到服务提供商的 NLB；提供商通过端点策略和安全组来控制访问，流量永远不会穿越集中的路由平面。当您需要完全的路由可见性和可传递的连接性时，Transit Gateway 是合适的选择，但它会集中化路由，并且在按服务进行访问控制方面的粒度不如 PrivateLink 精细。
常见陷阱与决策标准
一个常见的错误是假定实例宣称的带宽是无限的；实例系列和大小设定了硬性的网络限制，扩缩容时应考虑将流量分散到多个 ENI，并为了获得一致的性能而将实例放置在集群置放群组中。另一个陷阱是仅依赖 CloudWatch 的 NetworkIn/NetworkOut 指标，而没有关联 VPC Flow Logs 来将流量归因于特定的 VPC、子网或业务单元；需要使用 Flow Logs 和 Traffic Mirroring 来隔离是哪个虚拟接口或应用程序导致了 Direct Connect 饱和。此外，当需要端到端双向 TLS 时，应避免在 ALB 上终止 TLS——如果策略要求后端能看到客户端证书，请选择使用 NLB 进行 TLS 直通，或执行带有正确证书验证的 TLS 桥接，但要明确信任建立的位置。
在诊断像 Direct Connect 这样的共享物理链路上的间歇性饱和问题时，需要跨层关联指标：AWS/DirectConnect 的虚拟接口指标、VPC Flow Logs 的每个子网/ENI 的字节计数，以及 EC2 的 Network* 指标以了解实例级别的行为。使用 Reachability Analyzer 来验证非对称路由或错误的路由传播是否导致了返回路径问题，并使用 Traffic Mirroring 捕获数据包转储以进行深度协议检测。
实践问题：用例场景
AcmeIoT 面临一个问题：全球的自动售货机必须通过 gRPC 和双向 TLS 连接到一个 EKS 托管的后端。连接数必须达到数千个，服务必须保持端到端加密，并且后端 Pod 需要通过 Cluster Autoscaler 和 HPA 进行动态扩缩容。
为 Kubernetes Service 创建一个类型为 Network Load Balancer 的 AWS LoadBalancer，使用 AWS Load Balancer Controller 和注解来指定 NLB 及 target-type=ip (service.beta.kubernetes.io/aws-load-balancer-type: “nlb” 和 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: “ip”)。在端口 443 上配置一个 TCP 监听器，以便 NLB 执行纯 TCP 直通；不要在 NLB 上配置 TLS 证书。
在应用 Pod 中实现双向 TLS 终止和验证。每个 Pod 都应提供一个服务器证书并验证客户端证书，使用与 AWS Secrets Manager 或 SSM Parameter Store 集成的短期证书轮换流程。通过使用 target-type ip 确保 Pod IP 是可达的，并确保在目标组上配置了 TCP 或 gRPC 健康检查。
通过选择具有 ENA 支持和足够网络带宽的实例来确保高连接规模，启用 ENA（通过 AMI 中的 ENA 驱动程序确认，并在需要时使用
undefined
启用 ena-support），并使用 Cluster Autoscaler 根据 Pod 请求来扩展节点，从而将 Pod 部署到多个节点上。对于需要一致延迟的紧密耦合集群，使用置放群组，并在多个可用区部署足够数量的节点。
- 使用 CloudWatch 和 VPC Flow Logs 进行监控和验证。为 NLB 的 ActiveFlowCount/NewFlowCount 和 EKS worker EC2 的 NetworkIn/Out 创建 CloudWatch 指标和警报。使用 VPC Flow Logs 识别任何流量最高的“话痨”，并使用 Reachability Analyzer (
undefined
/
undefined
) 在自动扩缩容事件期间验证路由路径。如果需要数据包级别的调试，可以创建 Traffic Mirroring 会话到一个检查实例。
AWS 的设计原理：TCP 模式下的 Network Load Balancer 会保留源 IP，支持海量并发连接，并且因为它不终止 TLS，所以允许端到端的 TLS。将 target-type ip 与 AWS Load Balancer Controller 结合使用，可以与 EKS 的自动扩缩容语义集成，从而使新的 Pod IP 能够被动态注册为目标。ENA 和适当的实例选型提供了处理数千个并发 TLS 连接所需的原始网络容量，而不会导致主机 CPU 耗尽。同时，CloudWatch、VPC Flow Logs、Reachability Analyzer 和 Traffic Mirroring 的组合提供了检测和修复饱和或路由问题所需的可观测性。
← 内容分发与边缘网络 · 所有领域 · 自动化、IaC 与网络运维 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →