AWS渠道折扣 AWS VPC Flow Logs 流量日志分析：如何定位异常大流量攻击与内网扫描？

很多人搜这个标题，真正想解决的不是“Flow Logs 是什么”，而是这几件事：

日志开了以后，能不能真的把异常流量找出来；
新 AWS 账号该怎么开、怎么付费、会不会被风控；
日志越查越多，成本会不会失控；
一旦发现攻击，下一步该先改安全组、NACL，还是先保日志证据。

先给结论：VPC Flow Logs 能定位“谁在打、打到哪、用了多少流量、是放行还是拒绝”，但它看不到请求内容。也就是说，它很适合抓大流量异常、端口扫描、横向探测、内网异常访问，但如果是 HTTP 层的恶意请求、SQL 注入、业务参数攻击，还得结合 WAF、ALB、GuardDuty 一起看。

1）先把账号、实名认证、付款方式弄清楚，不然后面日志都开不起来

AWS 国际站没有国内云那种固定形式的“实名认证流程”，但账户能不能顺利启用，核心看支付验证和风控审核。我见过不少人不是卡在技术，而是卡在账号环节：

新号用虚拟卡/预付卡，容易触发支付验证失败；
IP、开户地址、卡片国家不一致，容易被判高风险；
多人共用一个账号，后续找回、权限和审计都很麻烦；
先开太多区域、太多服务，会被系统认为异常使用。

更稳的做法是：用公司可追溯的邮箱注册，绑定能正常扣款的国际信用卡或企业卡，第一天就开 MFA，再马上设置 Budget 告警。AWS 不是“先充值再用”，它是后付费模式，所以你要靠预算线控制风险，而不是靠余额。

如果你是企业账号，建议把以下资料一次准备好：

公司英文名、注册地址、账单地址；
付款卡持有人信息与公司信息尽量一致；
税务资料、发票需求、联系人邮箱；
高权限账号和日常使用账号分开。

实操里最容易失败的，不是“开通账号”，而是付款验证不通过后反复重试。这会让风控更紧。遇到一次失败，先停下来，换稳定卡片、换干净网络、检查账单地址，不要连续撞。

2）Flow Logs 放哪儿，决定你后面查不查得起

很多人一上来就把整个 VPC 全开，结果日志量暴涨，三天后开始删日志。我的建议很直接：先按排障目标选落地方式。

方案	适合场景	成本感受	实际问题
CloudWatch Logs	临时排障、当天就要查结果	偏高	日志量大时，存储和查询都容易贵
S3 + Athena	长期留存、复盘审计、按天查	明显更稳	查询没 CloudWatch 快，但更适合做历史分析
只开关键 ENI / 子网	先抓异常点，不想全量烧钱	最低	漏看其他网段，但对定位攻击通常够用

经验建议：如果你现在是“怀疑有攻击”，先只开出问题的实例、NAT Gateway、负载均衡后端 ENI，或者可疑子网，别把整个 VPC 一次性全开。等定位到源头，再决定是否扩范围。

还有一个很实用的点：1 分钟聚合适合抓突发，10 分钟聚合适合看趋势。如果你是在查某个时段被打穿，先用 1 分钟；如果是周报级别复盘，用 10 分钟更省钱。

3）异常大流量攻击，先看“谁、打到哪、打多大”

Flow Logs 里最有价值的不是“总流量”，而是异常聚集点。我通常按这四步查：

先找流量峰值时间：哪一分钟 bytes/packets 突然上去；
看源 IP 是否集中：单源高流量，还是多源打同一目标；
看目的端口是否集中：80/443、22、3389、3306 这些端口最常见；
看 action：是 ACCEPT 还是 REJECT，能区分打进来了还是被挡住了。

一个常见场景：业务服务器突然出网流量暴涨，最后发现不是被打，而是某台机器在向外同步数据或被木马拉走数据。这个时候，你要优先查：

同一 srcaddr 是否持续向多个 dstaddr 发包；
bytes 是否远高于平时，但 packets 不算多；
是否只在某个时间段爆发；
是否和新部署、备份任务、镜像拉取时间重叠。

如果你用 Athena，可以先跑这种思路的查询：

SELECT srcaddr, dstaddr, dstport, action, SUM(bytes) AS total_bytes, COUNT(*) AS cnt
FROM flow_logs
WHERE year='2025' AND month='01' AND day='15'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY total_bytes DESC
LIMIT 20;

这类结果出来后，别急着下结论。看前 20 条里：

如果是一个源打一个目的，且 bytes 极高，优先怀疑单点异常或被控主机；
如果是很多源打同一个目的、同一个端口，优先怀疑外部攻击或压测失控；
如果 ACCEPT 很多且流量大，说明已经穿过安全组；
AWS渠道折扣 如果 REJECT 激增，说明扫描还在被挡，但目标已经暴露在外网或内网探测面上。

4）内网扫描怎么识别：看“范围”和“频率”，不是只看端口

内网扫描最典型的特征，不是流量大，而是探测面广、连接短、目标多。真正干这类分析时，我会重点看下面几种模式：

同一源 IP 在 5～10 分钟内访问大量目的 IP；
同一源 IP 连续扫多个端口，尤其是 22、23、25、135、139、445、3389、3306；
大量 REJECT 记录，说明在探路但没拿到通路；
连接持续时间很短，每次都像“试一下就走”；
固定时间窗口重复出现，常见于脚本、漏洞扫描器、资产盘点工具。

再给你一个更实用的判断方法：如果某个源 IP 在短时间里命中很多不同的 dstaddr 或 dstport，就先当扫描看；如果它只命中一个目标但端口很多，也要怀疑是横向探测。

不过这里有个坑：别把正常的资产扫描、EDR 检查、堡垒机巡检误判成攻击。我处理过不少误报，最后问题都出在“没有白名单”。所以建议你先整理这几类正常探测源：

运维堡垒机；
安全扫描器；
AWS渠道折扣 容器平台健康检查节点；
EDR / 漏扫 / 资产盘点系统。

5）成本怎么控：别让排障日志把账单打穿

AWS渠道折扣 VPC Flow Logs 的成本，通常不是“开没开”，而是你开了多大范围、保留多久、查多频繁。实际做法上，我一般这样分：

临时排障：开可疑子网或 ENI，保留 24～72 小时；
长期留存：落 S3，再配生命周期规则做归档；
高流量环境：只开关键业务段，不要全 VPC 无脑全量。

成本对比上，经验上可以这么理解：

CloudWatch 更适合“马上要查”，但日志越多越贵；
S3 + Athena 更适合“事后分析”，尤其是按天、按周复盘；
只保留必要字段，能明显减少体积，别把没用的字段全塞进去。

如果你的账号刚开，付款方式不稳定，建议先把预算告警设成：

日级告警：防止一天烧太快；
月级告警：防止测试没关；
异常费用邮件：直接发给运维和财务。

这一步很关键，因为不少 AWS 新号不是被攻击打挂，而是被日志、查询、存储和 NAT 转发费用一起拖高。

6）几个高频问题，基本都是实战里踩出来的

Q1：只靠 VPC Flow Logs 能不能直接定位攻击源？
能定位到源 IP、目的 IP、端口、流量大小，但不能看到请求内容。如果是 HTTP 层攻击，必须叠加 WAF / ALB / 应用日志一起看。

Q2：新 AWS 账号为什么一开日志就出问题？
通常不是日志本身，而是账号侧风控：付款卡未通过、账单信息不一致、网络环境异常、一次性开太多服务。处理方式是先把卡和账单信息稳定下来，再小范围开通。

Q3：能不能直接买现成 AWS 账号来查日志？
不建议。账号归属、付款责任、后续找回、权限审计都很麻烦。尤其是要长期留存安全日志，账号必须归自己控制，否则后面审计链条会断。

Q4：查询太慢怎么办？
别硬查全量。先缩时间窗口，再按 srcaddr、dstaddr、dstport、action 过滤；长期场景优先把日志放 S3，按日期分区，再进 Athena 查。

7）我给你的实际决策建议

如果你现在是“怀疑有异常大流量或内网扫描”，按这个顺序做最省时间：

先确认账号付款正常，别让风控卡住日志开关；
只对可疑 ENI / 子网开启 Flow Logs，先别全量；
优先查峰值时间段，找 top source / top destination / top port；
看到 REJECT 激增，优先排查扫描；看到 ACCEPT 且 bytes 暴涨，优先排查外联、横向或被控主机；
把结果同步给安全组、NACL、WAF、主机侧日志做闭环。

如果你愿意，我可以继续帮你补一版“AWS Flow Logs Athena 查询模板”，直接按异常大流量、端口扫描、内网横向访问三个场景分别给可复制的 SQL。