如何查看和监控AWS云服务器的实际带宽使用情况？-云小栈

在 AWS 中，云服务器（即 EC2 实例）的实际网络带宽使用情况可以通过多种方式查看和监控，需结合 CloudWatch 指标、VPC 流日志、第三方工具及实例内诊断。以下是系统化、实用的方案：

✅ 一、核心方法：AWS CloudWatch 网络指标（推荐首选）

EC2 实例自动上报以下关键网络指标到 CloudWatch（无需安装X_X，免费基础监控已包含）：

指标名称	含义	单位	说明
`NetworkIn`	实例接收的网络流量（含所有协议：TCP/UDP/ICMP等）	Bytes	包括公网入口（如公网IP）、私网入口（如VPC内通信）
`NetworkOut`	实例发送的网络流量	Bytes	同上，注意：不包含 EBS I/O 或 ENA/EFA 的专用网络流量
`NetworkPacketsIn/Out`	接收/发送的数据包数	Count	可辅助分析连接数或DDoS迹象

📌 重要注意事项：

✅ 这些是ENI（弹性网卡）级别的聚合流量，反映真实进出实例的 IP 层流量。
⚠️ 默认为 5分钟粒度；若需 1分钟粒度，请启用 CloudWatch Detailed Monitoring（需额外费用，且需在创建实例时开启或修改实例属性）。
❌ 不区分公网/私网流量 —— 需结合 VPC 流日志或实例内工具进一步拆分。

🔧 操作步骤（控制台）：

打开 Amazon CloudWatch 控制台
左侧导航 → Metrics → All metrics → EC2 → Per-Instance Metrics
选择目标实例 → 勾选 NetworkIn / NetworkOut
可添加统计方式（如 Average, Sum, Maximum），建议用 Sum 查看总流量（单位换算：1 GB = 1024³ Bytes）

📊 进阶技巧：

创建 CloudWatch Dashboard 可视化实时带宽（支持折线图 + 告警）
设置 告警（Alarm）：例如 NetworkOut > 100 MB/s for 5 minutes → 触发 SNS 通知或 Auto Scaling
使用 CloudWatch Logs Insights 查询自定义日志中的带宽相关事件（需应用主动打点）

✅ 二、精细化分析：VPC Flow Logs（识别流量来源/去向）

当需知道「谁在访问我？流量去了哪里？是否异常？」时，必须启用 VPC Flow Logs：

功能	说明
📍 记录内容	源/目的 IP、端口、协议、字节数、数据包数、动作（ACCEPT/REJECT）、实例ID等
📦 存储位置	Amazon S3（低成本长期存档）或 CloudWatch Logs（便于查询）
🔍 典型查询（CloudWatch Logs Insights）： `sql<br>fields @timestamp, srcAddr, dstAddr, bytes, action<br>\| filter interfaceId = "eni-xxxxxx"<br>\| stats sum(bytes) as totalBytes by bin(1h), srcAddr<br>\| sort totalBytes desc<br>`	快速定位高流量源IP或外连目标

✅ 适用场景： 安全审计、DDoS溯源、排查跨AZ/跨Region流量、识别未预期出站（如X_X外连）

⚠️ 注意：Flow Logs 不记录应用层内容（如HTTP URL），仅L3/L4元数据。

✅ 三、实例内部实时监控（精准到进程/端口）

当需定位「哪个进程/用户/端口占用了带宽」时，需登录实例运行命令：

Linux 实例（推荐工具）：

# 1. 实时流量（按接口）—— 最简单
sar -n DEV 1 5   # 需安装 sysstat：sudo yum install sysstat (AL2/AL2023) 或 apt install sysstat (Ubuntu)

# 2. 按进程查看（需 root）
sudo nethogs eth0    # 实时显示各进程带宽占用（安装：yum install nethogs / apt install nethogs）

# 3. 按连接统计（netstat + awk）
sudo ss -tunp | awk '{print $7}' | cut -d',' -f2 | cut -d':' -f1 | sort | uniq -c | sort -nr

# 4. 使用 iftop（类似 top 的网络版）
sudo iftop -P  # 显示端口，-P 显示端口号

Windows 实例：

使用 Resource Monitor（resmon.exe）→ “Network” 标签页

PowerShell：

Get-NetAdapterStatistics | Select-Object Name, ReceivedBytes, SentBytes
Get-Process | Where-Object {$_.Id -ne 0} | Sort-Object -Property WS -Descending | Select-Object -First 10 Name, Id, WS

💡 提示：可将 nethogs 或 iftop 输出通过 cron 定时抓取并写入日志，再用 CloudWatch Agent 收集到 CloudWatch Logs 分析。

✅ 四、增强方案：CloudWatch Agent + 自定义指标

若需更细粒度（如每秒 HTTP 请求量、数据库连接带宽、特定端口流量），可部署 CloudWatch Agent 并配置自定义指标：

在 EC2 上安装 CloudWatch Agent
编写采集脚本（如用 ss -i 解析 TCP RTT/重传，或 curl 调用应用健康端点）
配置 agent.json 将指标推送到 CloudWatch（支持自定义命名空间，如 MyApp/Network）

✅ 五、其他关键视角补充

场景	工具/服务	说明
EBS 卷带宽瓶颈	CloudWatch `VolumeReadBytes` / `VolumeWriteBytes`	若应用 I/O 高但 NetworkIn/Out 低，可能是 EBS 限速（gp3/io2 有 Baseline/Burst 性能）
负载均衡器（ALB/NLB）流量	ALB 指标：`ProcessedBytes`, `HTTPCode_ELB_5XX_Count`	EC2 的 NetworkIn 可能远小于 ALB 的 `ProcessedBytes`（因 ALB 压缩/缓存）
NAT Gateway 流量	NAT Gateway CloudWatch 指标：`BytesInToVpc`, `BytesOutFromVpc`	出向流量经 NAT 时，EC2 的 `NetworkOut` ≈ NAT 的 `BytesOutFromVpc`（可交叉验证）
突发性能（T系列）	CloudWatch `CPUSurplusCreditsBalance`	CPU 积分耗尽可能导致网络处理延迟（间接影响吞吐）

🚨 常见误区提醒

❌ “EC2 控制台的 ‘Monitoring’ 标签页只显示 5 分钟平均值，无法看到瞬时峰值” → ✅ 启用 Detailed Monitoring（1分钟）即可。
❌ “NetworkIn/Out 包含 EBS 流量” → ❌ 不包含，EBS 是独立存储通道（走 NVMe 或网络存储后端，不经过 ENI）。
❌ “安全组/ACL 会限制带宽” → ❌ 它们只做允许/拒绝（stateful filtering），不限速；带宽由实例类型、ENI 类型（如增强型网络 ENA）、VPC 网络带宽上限决定。
❌ “带宽跑满一定是业务问题” → ⚠️ 也可能是：DDoS、日志刷盘、未关闭的调试端口、恶意扫描、同步备份任务等。

✅ 最佳实践总结

目标	推荐方案
✅ 日常监控与告警	CloudWatch `NetworkIn/Out` + Dashboard + Alarm
✅ 安全审计与流量溯源	VPC Flow Logs（S3 + Athena 查询或 CWL Insights）
✅ 故障排查（哪个进程在发包？）	登录实例运行 `nethogs` / `iftop` / `ss`
✅ 长期容量规划	CloudWatch 指标导出至 S3 → Athena 分析月度趋势
✅ 多维度关联分析	CloudWatch + Flow Logs + Application Logs（通过 CW Agent 统一收集）

需要我为你：

📋 生成一份 CloudWatch 告警 Terraform 模板？
📊 提供 VPC Flow Logs + Athena 查询 SQL 示例（查Top 10外连IP）？
🐧 给出 Ubuntu/AL2 实例一键部署 nethogs + 日志轮转的脚本？
📈 制作一个 带宽监控 Dashboard JSON 导入模板？

欢迎随时告诉我你的具体环境（如实例类型、OS、是否启用了详细监控等），我可以为你定制化输出 👇