AWS EC2实例偶现Network In与CPU利用率过高问题排查求助

这种情况我之前帮不少用户排查过，结合你提到的「无自定义任务、新实例也出现问题」这些关键点，大概率是AWS内部操作或者外部网络扫描这类非业务因素导致的，给你列几个最常见的原因和对应的排查方法：

• AWS内部健康检查与系统维护
  AWS会定期对EC2实例执行健康检查（比如挂载在ELB下的实例，ELB会持续发送探测请求），还有底层宿主机的系统维护操作，这些都会在短时间内引发入站流量和CPU的波动——哪怕是刚创建的新实例，默认配置下也可能触发这类检查。

  • 排查步骤：
    1. 登录EC2控制台，进入「事件历史」（Event History），筛选异常时间段的事件，看有没有对应的维护通知；
    2. 如果实例关联了负载均衡，查看ELB的健康检查配置，确认检查频率和请求类型，判断是否和峰值时间匹配。

• 外部网络扫描/恶意探测
  只要你的EC2实例拥有公网IP，就很容易被全网扫描工具盯上，比如针对22（SSH）、80/443（HTTP/HTTPS）等常用端口的探测，大量的无效连接请求会直接推高入站流量，同时CPU需要处理这些请求，也会跟着飙升。

  • 排查步骤：
    1. 在实例上执行抓包命令：sudo tcpdump -i any -n host <你的实例公网IP>，观察流量来源IP和请求端口，判断是否为批量扫描流量；
    2. 开启VPC Flow Logs，筛选入站流量的源IP和请求类型，进一步确认是否为恶意探测。

• AWS默认代理服务的周期性交互
  EC2实例默认会预装CloudWatch Agent、SSM Agent这类服务，它们会定期和AWS后台通信，比如上报监控数据、接收服务更新指令，偶尔的批量数据同步或服务升级可能引发短暂的流量和CPU波动。

  • 排查步骤：
    1. 查看CloudWatch Agent日志（默认路径：/var/log/amazon/cloudwatch-agent/），看异常时间段是否有大量日志上报记录；
    2. 用strace跟踪SSM Agent进程（进程名一般是amazon-ssm-agent），查看是否有频繁的网络调用行为。

• DNS解析请求异常
  如果实例的应用或系统有大量DNS解析需求，当DNS缓存失效、或者AWS DNS服务器出现短暂波动时，会产生大量的DNS响应流量，间接导致CPU负载上升——这个概率相对低，但也可以排查确认。

  • 排查步骤：查看系统日志（/var/log/messages或syslog），搜索DNS相关日志，看是否存在短时间内大量解析请求的情况。

从你提供的流量峰值趋势来看，这种突发性的短时间飙升，非常符合扫描、健康检查这类非业务流量的特征，建议先从上面几个方向入手排查。

内容的提问来源于stack exchange，提问作者Daniel