3. VPC流量成本分析与优化
在 AWS 中，VPC 本身不收费，但流量一旦离开某个边界，就可能开始计费。很多团队账单里“看不懂的那部分”，往往不是 EC2 或 RDS 本身，而是跨子网、跨可用区、跨 VPC、跨区域以及出公网的数据传输费。要治理这部分成本，第一步不是急着改架构，而是先把“哪些流量在什么位置被计费”这件事看清楚。
一、先分清四种计费边界
VPC 内流量是否收费，取决于它是否跨越了计费边界。可以按以下四类理解：
- 同一子网内实例互访：流量不离开子网所在的可用区，通常不产生数据传输费。这是最“便宜”的路径。
- 跨可用区（跨 AZ）流量：同一 VPC 内，实例 A 在 AZ-a、实例 B 在 AZ-b，两者通过私有 IP 通信时，流量会跨越可用区边界，按“区域内跨 AZ 数据传输”计费，通常为每 GB 双向收费（入和出方向都可能计费，具体以账单为准）。
- 跨 VPC 流量：通过 VPC Peering、Transit Gateway、PrivateLink 等方式连接的两个 VPC，流量在 VPC 之间传输时会产生费用。VPC Peering 的跨 VPC 流量按区域和 AZ 关系计费；Transit Gateway 还会额外收取“每 GB 处理费”和“每小时挂载费”。
- 出公网与跨区域流量：通过 Internet Gateway 或 NAT Gateway 访问公网，按出方向流量计费；跨区域（如 us-east-1 到 ap-northeast-1）传输费用更高，且通常双向计费。
这里有一个容易忽略的点：NAT Gateway 本身有小时费，同时按处理的 GB 收费。如果大量实例通过 NAT 访问 S3 或 DynamoDB，而本可以使用 Gateway Endpoint 免费访问，这部分流量就会白白产生 NAT 处理费。这是 VPC 流量优化中最常见、也最容易见效的切入点之一。
二、用 VPC Flow Logs 定位流量来源与去向
VPC Flow Logs 记录的是网络接口（ENI）级别的 IP 流量元数据，字段包括源地址、目标地址、源端口、目标端口、协议、包数、字节数、起止时间、动作（ACCEPT/REJECT）等。它不记录包内容，但足以回答“谁在和谁通信、通了多少字节、被允许还是被拒绝”。
Flow Logs 可以发布到 CloudWatch Logs、S3 或 Kinesis Data Firehose。做成本分析时，推荐先投递到 S3，再用 Athena 查询，因为日志量大、按量查询更经济。下面是一段典型的 Athena 建表与查询示例：
CREATE EXTERNAL TABLE vpc_flow_logs (
srcaddr string, dstaddr string, srcport int, dstport int,
protocol bigint, packets bigint, bytes bigint,
starttime bigint, endtime bigint, action string,
logstatus string, vpc_id string, subnet_id string,
interface_id string, az_id string
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
LOCATION 's3://my-flow-logs/AWSLogs/123456789012/vpcflowlogs/us-east-1/';
-- 按目标地址聚合，找出流量最大的对端
SELECT dstaddr, sum(bytes)/1024/1024/1024 AS gb
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
GROUP BY dstaddr
ORDER BY gb DESC
LIMIT 20;查询结果中，如果发现大量字节流向另一个 AZ 的私有 IP，说明存在跨 AZ 通信；如果流向 NAT Gateway 的私有 IP 且目标端口是 443，说明有实例在通过 NAT 访问外部服务，此时应检查是否可以用 VPC Endpoint 替代。判断依据很直接：字节数大、目标地址集中、且目标服务有免费或更便宜的接入方式，就是优化优先级最高的对象。
三、路由优化策略：把流量留在“便宜”的路径上
识别出问题后，优化手段主要围绕“改变流量路径”展开。常见策略包括：
- 同 AZ 优先：把频繁通信的实例、负载均衡节点、缓存节点尽量放在同一可用区。例如，应用服务器和 Redis 主节点同 AZ，避免每次读写都跨 AZ。
- 用 Gateway Endpoint 替代 NAT：S3 和 DynamoDB 支持 Gateway Endpoint，不额外收费。在路由表中添加指向 Endpoint 的路由后，访问这两个服务的流量不再经过 NAT Gateway。
- 用 Interface Endpoint 替代公网访问：对 Secrets Manager、SSM、ECR 等服务，Interface Endpoint 按小时和 GB 收费，但通常低于 NAT 处理费，且流量不出 VPC。
- 跨 VPC 选型：少量 VPC 互联可用 Peering；VPC 数量多、拓扑复杂时用 Transit Gateway，但要评估其每 GB 处理费是否划算。
- 压缩与缓存：跨 AZ 或跨区域传输前先压缩数据，或引入 ElastiCache、CloudFront 减少重复回源。
四、一个可复用的分析闭环
把上述过程串起来，可以形成一个持续运行的分析闭环：开启 Flow Logs → 用 Athena 按目标地址、AZ、端口聚合 → 对照计费边界判断哪些流量“本可以不花钱” → 调整路由或架构 → 观察下一周期账单和 Flow Logs 中对应流量的字节数是否下降。判断优化是否生效，不看单日波动，而看连续 7 天同一聚合维度的字节数趋势。
图中左侧是 VPC 内部的计费边界：同 AZ 免费、跨 AZ 收费、NAT 有处理费、Gateway Endpoint 免费、跨 VPC 按连接方式收费。右侧是 Flow Logs 的分析链路：采集元数据、投递到 S3、用 Athena 聚合、识别高成本流量、执行路由优化，最后回到流量路径上验证效果。把这张图当作排查清单，逐项对照自己的环境，通常能在第一轮就找到 2～3 个明确的优化点。