晚上十一点，我端着杯子看上月云账单。五台服务器，CPU 和内存那两栏很老实，倒是「公网带宽」和「公网 IP」这两行，数字精神得有点过分。
我数了数：五台机器，五个公网 IP。其中三台只在凌晨跑批处理；一台专门拉 Docker 镜像、装依赖；剩下一台才真正对外提供网站服务。也就是说，我为「能上网」这件事一口气买了五次单，而真正在用的可能连一次都不到。
这事挺像我早年家里的做法：每个房间都装电话机，结果只有客厅那台有人打。后来换成一部座机加分机，话费没涨，线还少了。云上的「分机」，就是 NAT 网关。
一、先把话说清楚：NAT 网关到底是个啥
NAT 网关（NAT Gateway）是阿里云提供的全托管网络地址转换服务。注意「全托管」三个字，它不是让你开一台机器自己跑 iptables，而是平台替你维护的高可用组件，分两种规格路数：
- 公网 NAT 网关：把 VPC 内的私网 IPv4 地址转换成 EIP，让多台服务器共享 EIP 访问公网。这一种是绝大多数人真正需要的。
- VPC NAT 网关：把 VPC 内的私网 IPv4 转成 NAT IP，主要用来解决地址冲突网络之间的互访，或者满足「必须用指定地址访问对方」这类诉求。
如果你只是嫌公网 IP 太多太贵，看第一种就够了。第二种属于专线、多云互通、地址段重叠时的救火队员，平时用不到。
（顺手把入口放这儿：想直接翻说明和计费口径的，NAT 网关产品页上写得很全，价格也以页面上实时展示的为准，别信我这种二手转述。）
二、SNAT 和 DNAT：一个管出、一个管进
很多人第一次配 NAT 网关会懵：规则里一会儿 SNAT、一会儿 DNAT，到底谁管谁。其实没那么玄，一句话拆开：
| 规则 | 方向 | 干什么用 | 典型场景 |
|---|---|---|---|
| SNAT | 内网 → 公网 | 内网地址换成公网 IP 出去 | 拉镜像、装依赖、调用外部 API、上报日志 |
| DNAT | 公网 → 内网 | 公网某个 IP/端口映射到内网某台机器 | 内部测试机临时对外开放、指定端口提供服务 |
记住一个顺口溜就行：SNAT 是出门，DNAT 是开门。
配 SNAT 时你是按「哪个交换机/网段能出网」放行的，不是一台一台点名。后面再加机器，只要在同一个交换机里就能上网，不用重配规则——弹性伸缩场景下这点非常省事。
三、三种「让服务器上网」的姿势，把账本摊开
同样是让五台机器访问公网，路子不止一条。我按自己踩过的顺序列一下：
方案一：每台机器各配一个 EIP
最直观。谁要上网谁自己买，互不干扰，管理界面上一目了然。
代价也很直观：EIP 是要单独计费的，机器越多，这份「上网门票」买得越多。而且公网 IP 一多，暴露面也跟着涨——每多一个公网 IP，就多一个被人扫、被人撞的入口。
方案二：自建代理（找一台有公网 IP 的机器跑 iptables / squid）
这是省钱派的老办法，我也干过。确实能省下好几个 IP 的钱，但那台代理机从那天起就成了心脏起搏器：它挂了全体服务器一起断网，而它往往是你最不常登录的那一台；单点扛所有出口流量，被刷被打第一个遭殃；规则全靠手工维护，换个人接手先读半天配置；出问题要救它，还得先找一台能上公网的机器——鸡生蛋，蛋生鸡。
省的是钱，赌的是运气。哪个月运气差一点，夜里爬起来修代理的成本，比省下的那点钱贵多了。
方案三：一台公网 NAT 网关，大家共享出口
内网机器照旧不配公网 IP，通过 SNAT 规则统一从网关出去，绑定一个或多个 EIP。
机器数量再怎么涨，出口这一层还是那一个（或一组）EIP，账单结构简单，规则也好维护。而且官方页面写的几项能力，恰好都落在痛点上：
- 安全访问：通过 SNAT 让内部服务地址不对外暴露，外部也没法主动发起连接；
- 节省成本：共享公网 IP 资源，省掉一批 IP 持有费和带宽费；
- 主备高可用：多级容灾架构，SLA 有保障，不会像我那台自建代理一样说没就没；
- 自动弹性：随业务弹性扩容（部分规格支持，选型时留意），流量突增时能自动伸缩，不至于像代理机那样被一波流量打满。
另外还有两块容易被忽略但真用得上：权限与审计，可以给 RAM 用户、用户组、RAM 角色绑定策略，针对资源、API、Tag 做细粒度授权，谁能在哪个环境改 NAT 规则，写清楚；日志与监控，NAT 网关自带开箱即用的可视化流量日志分析，配合云监控和网络智能服务，能看清到底是谁在往外跑、跑了多少。
四、钱到底花在哪几个口子
一说省钱，就得把账算细，不然容易变成「感觉便宜」。
用 NAT 网关这套方案，账单上主要出现三个口子：
- EIP 本身。绑在 NAT 网关上的那几个公网 IP，本身有自己的计费口径（IP 保有费、带宽配置）。
- 公网带宽。固定带宽也好，按使用流量也罢，出口流量最终都要在这条线上过一遍，这部分和你原来给 ECS 配带宽是同一种性质，只是集中到了出口。
- NAT 网关实例。按规格（容量单位）计费，支持不同规格档位，也提供包年包月和按量付费等不同付费方式。
所以正确的比较方式不是「NAT 网关一个月多少钱 vs 一个 EIP 多少钱」，而是「NAT 网关 + 一个共享 EIP + 一份出口带宽」对比「N 个 EIP + N 份带宽」。N 越大，天平越往共享出口这头偏；N 等于 1 的时候，天平大概率纹丝不动——这一点先讲清楚，省得你看完觉得被忽悠了。
具体数字我不写死，官方页面的价格会调整，以实时展示为准。按上面三个口子各取一次当前价，填进自己那张表，五分钟就能算明白。
五、什么时候该上 NAT 网关
命中下面任意两条，就值得认真评估：有多台无公网 IP 的 ECS 需要出网（拉镜像、装依赖、调三方 API、传日志）；对接的第三方要求固定 IP 白名单，而你的出口还在来回换；跑 K8s / 容器集群，一堆节点要统一出口；有批量处理、爬取、定时任务这类「只出不进」的负载。
六、什么时候别上，把钱省下来
- 只有一两台机器要出网：共享出口省下的钱不够覆盖网关实例成本，老老实实买 EIP 更划算；
- 服务器需要被公网主动访问：NAT 网关解决的是出网，对外提供服务请用 EIP 直连或负载均衡；
- 出入向流量都极大：出口带宽一样要计费，集中之后并没有凭空变便宜，重点还是把流量本身优化掉。
七、我见过（也踩过）的六个坑
- 以为 NAT 网关「既管出又管进」。它默认只做 SNAT。要让外部访问内部，得配 DNAT 规则，或者干脆走负载均衡。
- 忘了 EIP 和带宽是另外买的。NAT 网关实例本身不自带公网出口带宽，第一次算预算漏这两项的人不少。
- 出口 IP 只有一根，被人封了全军覆没。对外的目标站如果按 IP 限速或封禁，整个内网的业务会一起趴窝。稳妥做法是绑多个 EIP 分散出口。
- 日志没开，出事全靠猜。可视化日志分析不是默认就给你记录到位的，需要主动打开；不然流量异常时你只能对着监控图发呆。
- 规格选太小。业务量涨上来之后，网关的连接数和处理能力会成为新瓶颈，选型时留出余量，或者挑支持弹性伸缩的规格。
- 路由表没指过去。SNAT 规则配了，但交换机路由表里默认路由没指向 NAT 网关，表现就是「明明配了却上不了网」——这个坑我蹲了半小时才反应过来。
八、照着做：接入步骤清单
真要动手，顺序大致是这样：
- 确认目标 ECS 都在同一个 VPC 内，并规划好承载出口的子网/交换机；
- 创建公网 NAT 网关，选择地域、规格与付费方式（地域要和 ECS 一致）；
- 为网关绑定 EIP，按出口规模决定绑一个还是多个；
- 配置 SNAT 规则，指定允许出网的交换机或网段；
- 如有对外需求，再配 DNAT 规则，只放必要的 IP 和端口；
- 检查交换机路由表，确认默认路由指向 NAT 网关；
- 打开流量日志分析，给运维同学配一份 RAM 只读/运维策略，把「谁能改规则」写进制度里。
七步走完，回头看账单，那两行让你血压升高的数字通常会安静不少。
九、最后一句实在话
云上花钱最贵的往往不是单价，而是为「可能要用」重复买单。五台机器五个公网 IP，本质上不是技术问题，是当时懒得想、后来懒得改。
NAT 网关不值高深，它就是把「每家一部电话」换成「一部总机加分机」的老智慧。该不该换，照前面三个口子的账算一遍就有答案；不该换的时候，也别为了架构好看硬上。
省下的钱不一定很多，但出口只有一个、规则只有一份、排查只有一条线——这三件事带来的踏实感，值。
