在AWS上怎样提升实例的网络带宽？

在 AWS 上提升 EC2 实例的网络带宽，核心逻辑其实就一条：网络性能与实例规格（Instance Type）强绑定。AWS 不会允许你给一个低配实例强行超频到高端实例的网卡速度。

如果你发现当前实例跑不满带宽，或者延迟高、丢包，通常需要从以下几个维度排查和优化。这不是简单的“调参数”，而是架构和选型的问题。

1. 确认实例类型是否支持更高的网络性能

这是最基础也最关键的一点。AWS 将实例分为不同的网络性能等级：

• Basic Network Performance：如 T2/T3（突发型）、M1/M3（老旧世代）。这些实例的网络带宽是共享且有限的，受 CPU 积分限制影响大，不适合高吞吐场景。
• Up to 10 Gbps：如 M4、C4、R4 等上一代主流实例。
• Higher Network Performance：如 M5、C5、R5、X1、P3 等现代通用/计算优化实例。它们基于 Nitro 系统，提供了更低的延迟和更高的带宽。
• Highest Network Performance (EBS Optimized & High Throughput)：如 Hpc1、Inf1、以及最新的 C7g/M7g 等 Graviton 或高性能系列。部分实例支持高达 100 Gbps 甚至 200 Gbps 的网络带宽。

操作建议：
检查你的 describe-instances 输出中的 NetworkInfo 字段，特别是 MaximumBandwidthGbps。如果你的业务需要 10G+ 带宽，却还在用 T3 或 M4，换实例是唯一解。不要试图通过软件优化来突破硬件限制。

2. 启用并优化 EBS Optimized 与 IOPS

虽然这主要影响磁盘 IO，但间接影响网络感知。如果大量数据从 S3 或 EBS 加载，磁盘瓶颈会被误认为是网络瓶颈。

• EBS Optimized：在现代实例（M5/C5/R5 及以后）中，EBS Optimized 默认开启且免费。确保你没有关闭它。
• 吞吐量模式：对于 gp3 卷，你可以独立调整吞吐量（Throughput），最高可达 4,000 MiB/s。如果网络带宽很高，但磁盘读写慢，整体体验依然卡顿。

3. 使用 Placement Groups（放置组）降低延迟

如果你的应用是高并发、低延迟敏感型（如高频交易、实时游戏服务器、HPC 集群），普通部署会导致跨可用区（AZ）或机架间的网络跳数增加，延迟飙升。

• Cluster Placement Group：将所有实例放在同一个 Availability Zone 内的同一个物理机架上。这会启用 Enhanced Networking 并最小化跳数，提供最低的延迟和最高的每流pps（packets per second）。
• 注意：此策略牺牲了可用性（单 AZ 故障会影响所有实例），仅适用于容错性要求不高但对性能极致要求的场景。

4. 利用 ENA（Elastic Network Adapter）和 SR-IOC

AWS 的 Nitro 系统依赖 ENA 来实现高性能网络。

• 确保驱动最新：在 Linux 实例上，确保安装了最新版本的 ena-driver 和 aws-kernel-modules。旧内核或缺少驱动会导致回退到虚拟网卡（virtio-net），性能大幅下降。

  # Ubuntu/Debian 示例
  sudo apt-get install linux-aws linux-headers-$(uname -r)
  sudo modprobe ena

• SR-IOV (Single Root I/O Virtualization)：ENA 支持 SR-IOV，允许虚拟机直接访问物理网卡，绕过 Hypervisor 开销。大多数现代 AWS 实例默认启用此功能，无需额外配置，但需确保操作系统内核支持。

5. 负载均衡器（ELB/ALB/NLB）的选择

前端入口如果是 ELB，也可能成为瓶颈。

• Classic Load Balancer (CLB)：已停服，勿用。
• Application Load Balancer (ALB)：适合 HTTP/HTTPS，最大处理能力约 10-15 Gbps，取决于实例大小。
• Network Load Balancer (NLB)：关键！ NLB 基于 ENI 直接转发 TCP/UDP 流量，几乎无协议栈开销，能轻松达到 100 Gbps+ 吞吐量，延迟极低。如果你的应用是 TCP/UDP 长连接、数据库XX、游戏服务器，务必使用 NLB。

6. 客户端与 DNS 优化

有时问题不在 AWS 内部，而在外部：

• DNS 解析：确保使用 Amazon Route 53 或本地快速 DNS。慢 DNS 会导致建立连接前就耗时过长。
• TCP Window Scaling：确保操作系统启用了 TCP Window Scaling 和 Selective ACKs（SACK）。Linux 默认开启，Windows Server 2012+ 也默认开启。检查方法：

  sysctl net.ipv4.tcp_window_scaling
  # 应为 1

• MTU 设置：AWS VPC 标准 MTU 是 9001（Jumbo Frames），但并非所有路径都支持。如果在内网传输大文件，可尝试将接口 MTU 设为 9001 测试性能提升，但需确保对端也支持，否则会导致分片或丢包。谨慎操作，多数情况下保持 1500 更稳定。

7. 监控与诊断工具

别猜，看数据。

• CloudWatch Metrics：重点监控 NetworkIn / NetworkOut、StatusCheckFailed、CPUUtilization。
• EC2 Serial Console：如果网络完全不通，通过串行控制台登录排查防火墙或路由表。
• iperf3 测试：在同 VPC 内两台实例之间运行 iperf3，测真实带宽。

  # 服务端
  iperf3 -s
  # 客户端
  iperf3 -c <server_ip> -t 10 -P 4  # 多线程测试

  如果 iperf3 跑不到实例标称带宽，再考虑是否是安全组规则限流（Security Group 本身不限速，但某些第三方防火墙 appliance 会限速）。

总结行动清单

1. 查规格：确认当前实例类型的最大网络带宽是否满足需求。不够？升级实例族（如 M5 → M6i 或 C7g）。
2. 换 LB：如果是 TCP/UDP 高并发，改用 NLB。
3. 放位置：低延迟需求，使用 Cluster Placement Group。
4. 更新驱动：确保 ENA 驱动和内核为最新版本。
5. 压测验证：用 iperf3 实测，排除应用层代码效率问题（如 Java GC 停顿、Python GIL 锁等）。

记住，在 AWS 上，“贵”往往意味着“快”。想要更好的网络性能，最直接的方式就是选择更高一代、更大规格的实例。任何软件层面的 tweaks 都无法超越硬件架构的限制。