AWS公网IPv4费用不起眼，为什么时间久了也会越积越多？
这两年看 AWS 账单时，有一项费用越来越容易被忽略：Public IPv4。
以前很多人开 EC2 的习惯是，机器创建出来顺手配一个公网 IPv4，测试机、跳板机、小服务都这么用。
单台机器看起来没什么。
但账号里机器一多，尤其是长期挂着一些低配实例的时候，公网 IPv4 的费用就会慢慢变得很显眼。
比如有些项目本身 EC2 配置就不高：
2 台生产机3 台测试机1 台跳板机6 台机器全部长期占着公网 IPv4。
单独看每个 IP 的费用不算夸张，但一年累计下来，就已经不是完全可以忽略的数字了。
更麻烦的是，有些公网 IP 其实根本没有必要存在。
很多服务器并不需要直接暴露公网 IP比较常见的一种架构是：
Internet ↓ALB ↓EC2真正需要对公网提供访问的是 ALB。
后面的 EC2 完全可以放在 Private Subnet，通过内网和 ALB 通信。
但不少早期项目为了方便，创建 EC2 时直接：
Auto-assign public IPv4 = Enable久而久之，所有服务器都有公网 IP。
功能上当然能用，但实际上多花了一块没太大必要的费用。
测试环境最容易留下这类资源生产环境一般有人盯。
测试机反而最容易出现：
机器一个月只用几次但是一直开着公网 IPv4 也一直占着甚至 EC2 后来不用了，Elastic IP 还留在那里。
所以我现在看到 AWS 小额账单时，除了 EC2、EBS、流量，也会顺手看看：
Public IPv4 到底有多少个？
尤其是账号里有十几台、几十台小机器的时候。
能走内网的尽量走内网并不是说所有公网 IPv4 都应该删。
有些跳板机、富强、固定出口或者特殊业务，本身就需要公网地址。
但如果只是：
应用服务器
数据库
Redis
内部 API
Worker
这些资源其实通常没有必要直接暴露公网。
可以考虑：
Private Subnet+NAT Gateway / NAT Instance+ALB+SSM Session Manager具体怎么设计还是看业务。
这里也不能为了省几个 IPv4，反而搞出更高的 NAT Gateway 成本。
所以重点不是“看到 IPv4 就删”，而是看看：
这个 IP 到底有没有必要长期存在。
小账单最容易被这种固定费用吃掉如果一个账号每个月 AWS 只有几百美元，这种固定的小费用反而特别明显。
比如：
公网 IPv4EBS 快照闲置磁盘CloudWatch LogsRoute 53旧 Elastic IP单独看都不大。
但这些东西凑在一起，可能就是账单里很稳定的一部分。
很多 AWS 成本优化其实不是去动核心生产架构，而是把这些长期没人管的小项目一点点清掉。
用量上来以后，再看商务结算如果 AWS 一个月只有几百美元，最应该先做的还是资源清理。
但如果已经稳定到：
每月几千美元甚至几万美元这个阶段除了技术侧优化，也可以顺手看看账单结算方式。
我们这边目前主要做 AWS 账单结算和商务支持，不参与客户开发、部署和日常运维。
客户原来的 AWS 环境、技术团队、账号使用方式都可以保持不变，我们主要根据实际月度使用规模评估相应的结算方案和商务优惠。
所以如果现在 AWS 已经有一定规模，可以把两件事分开看：
技术上，把没必要花的钱清掉。
商务上，把本来就必须花的钱看看有没有更合适的结算方式。
这两块一起处理，效果通常比单纯盯着某一个 EC2 实例省几十块更明显。
标签：AWS、EC2、Public IPv4、云成本、AWS账单
页:
[1]