你以为云上的网络只是"能通就行"?
错。当你的弹性云主机突然无法被远程访问,当带宽账单比服务器还贵,当NAT规则配错导致整段业务瘫掉——你才会意识到:网络产品选错了,比不选更可怕。
作为一名在一线摸爬滚打多年的开发工程师,我见过太多团队在网络产品上"凭感觉选":需要公网出口?买个弹性IP。带宽不够?再买个弹性IP。结果账单炸了,架构乱了,运维疯了。
今天,我就以天翼云的网络产品矩阵为样本,从弹性IP、共享带宽、NAT网关、云专线、边缘弹性公网IP五大核心产品切入,逐一拆解每个产品的适用场景、架构逻辑和实战要点。这不是产品说明书,这是一份用踩坑换来的选型指南。
一、弹性IP:公网访问的"第一张门票"
1.1 它是什么?
弹性IP(EIP)是一个可以独立申请、绑定、解绑的公网IP地址。它不依附于任何实例,绑谁用谁的,解绑了还能再绑别人——这就是"弹性"二字的含义。
1.2 什么时候必须用?
| 场景 | 为什么必须用 |
|---|---|
| 网站/API面向公网提供服务 | 域名要解析到一个固定的公网IP上,弹性IP就是这个IP。解绑故障实例后可快速绑定到正常实例,业务不断。 |
| 远程管理云主机 | 云主机绑定弹性IP后,你就可以通过这个IP从任何地方SSH/RDP登录。不用弹性IP,你只能在控制台里操作。 |
| 跨可用区容灾 | 弹性IP支持跨可用区绑定,配合负载均衡可实现公网出口的主备切换,满足同城双中心或两地三中心的高可用需求。 |
| 域名备案 | 备案时需要填写一个公网IP地址,弹性IP可以直接作为备案登记信息。 |
1.3 关键特性:别忽视这些细节
- 即开即用,分钟级交付:不像传统IDC申请IP要等一周,弹性IP几分钟就能到手。
- 支持IPv4/IPv6双栈:弹性IP提供IPv4访问能力,IPv6带宽提供IPv6访问能力,满足不同业务场景。
- 独立生命周期管理:在控制台可独立查看状态、绑定情况、带宽大小、到期时间,支持续订、释放、解绑故障实例。
1.4 踩坑预警
弹性IP绑定ECS后,如果ECS释放了但EIP没解绑,EIP会继续按量计费。很多团队的"隐形账单"就是这么来的。解决方案很简单:设置自动解绑策略,或者定期清理僵尸EIP。
二、共享带宽:带宽成本的"杀手锏"
2.1 它解决什么问题?
假设你有10台云主机都需要访问公网,每台都买一个独享带宽的弹性IP——假设每台5Mbps,总共50Mbps,成本是10份钱。
共享带宽的逻辑是:把这10个弹性IP加到同一条共享带宽线路里,大家共用一个带宽上限。 所有IP的带宽总和不超过共享带宽的上限就行。
2.2 什么时候该用?
| 场景 | 为什么选共享带宽 |
|---|---|
| 多台云主机访问互联网 | 带宽/流量波动较大的业务,错峰访问时总带宽远低于各主机带宽之和,共享带宽可大幅降低成本。 |
| ELB+多台ECS的经典架构 | 负载均衡绑定弹性IP,后端多台ECS通过SNAT共享带宽出公网,省钱又好管。 |
| NAT网关+多台云主机 | NAT网关的SNAT规则绑定弹性IP,这些IP可以加入共享带宽,实现批量出公网。 |
2.3 核心规则
- IPv4共享带宽最多可添加30个公网IPv4地址。
- 支持包年包月和按需计费两种模式。
- 弹性IP加入共享带宽后,原本的独享带宽功能被移除,不再单独计费。
- 支持自助添加和移出IP,立即生效,可根据业务实时调整。
2.4 实战案例
某企业有20台云主机需要访问公网,每台峰值5Mbps但实际使用不到2Mbps。如果每台买独享带宽,月均成本约2000元。改用共享带宽(30Mbps),月均成本降至600元,节省70%。关键是:20台主机的流量峰值加起来也才40Mbps,30Mbps的共享带宽完全够用——因为不是所有主机同时跑满。
三、NAT网关:网络架构的"瑞士军刀"
NAT网关是整个网络产品矩阵里最灵活、场景最多的产品。它只做两件事:SNAT(源地址转换)和DNAT(目的地址转换)。但就是这两件事,撑起了80%的云上网络架构。
3.1 公网NAT网关:两大核心场景
场景一:SNAT——多台云主机共享一个公网IP出网
当VPC内大量云主机需要主动访问公网(比如下载更新包、调用外部API),但你不想给每台都绑弹性IP——用NAT网关的SNAT功能。
配置逻辑:一条SNAT规则 = 一个子网 + 一个弹性IP。VPC内没有弹性IP的资源,通过SNAT规则自动共享弹性IP访问公网。
价值:节省弹性IP资源,避免云主机IP直接暴露在公网上,安全+省钱双赢。
场景二:DNAT——云主机面向公网提供服务
当VPC内的云主机需要对外提供Web服务、API服务,但你不想把所有端口都暴露到公网——用NAT网关的DNAT功能。
配置逻辑:绑定弹性IP,通过端口映射,将访问弹性IP特定端口的请求转发到目标云主机的指定端口。
举个例子:
- 弹性IP的80端口 → 云主机A的10080端口
- 弹性IP的8080端口 → 云主机B的20080端口
- 弹性IP的443端口 → 云主机C的30443端口
一个弹性IP,三台云主机,三个服务,互不干扰。
3.2 私网NAT网关:混合云的"粘合剂"
公网NAT解决的是"上公网"的问题,私网NAT解决的是"线上线下用私网互通"的问题。
| 场景 | 怎么用 |
|---|---|
| VPC互访地址冲突 | 两个业务VPC子网都是192.168.1.0/24,无法直接互通。通过私网NAT网关,用不冲突的中转IP实现互通。 |
| 混合云指定源IP访问 | 金融场景要求用固定私网IP访问。通过私网NAT的SNAT,云上实例用固定中转IP访问本地IDC。 |
| 云间高速访问互联网 | 本地IDC通过云专线上云后,购买公网NAT网关,SNAT出公网,比每台服务器单独买EIP省钱得多。 |
3.3 高可用SNAT:别让一个IP毁了你的业务
SNAT规则支持配置多个弹性IP(最多5个),系统随机选择出公网。当其中一个EIP被DDoS攻击封堵时,业务自动切换到其他EIP——不需要人工干预。
某电商平台的实战数据:大促期间某EIP被攻击封堵,系统在秒级内自动切换到备用EIP,业务零中断。
3.4 NAT网关集群:横向扩展
当单NAT网关性能达到瓶颈(如SNAT最大支持100万连接),可创建多个NAT网关组成集群,配合自定义路由表分散流量,实现公网访问能力的横向扩容。
四、云专线:混合云的"高速公路"
4.1 它是什么?
云专线是连接本地数据中心与天翼云VPC的专属通道。物理专线一端连你的IDC网关,一端连天翼云的专线网关,实现安全、可靠、高速的内网级通信。
4.2 三大核心场景
| 场景 | 解决什么问题 |
|---|---|
| 大规模数据迁移/持续性传输 | 需要大量带宽、高稳定性。云专线支持1G普通带宽和10G超大带宽,轻松应对TB级数据迁移。 |
| 混合云高可用架构 | 多条专线连接,支持链路负载和主备两种接入方式,链路故障自动切换,保障业务不中断。 |
| 核心业务与非核心业务隔离 | 核心业务放本地IDC,非核心业务(开发测试)放云上,云专线打通实现互联互通,数据独占链路,安全隔离。 |
4.3 专线类型全家桶
支持IPRAN、PON、OTN、CN2、MSTP、IP虚拟专网等多种类型,企业可根据带宽需求、延迟要求、预算灵活选择。
某金融机构采用双CN2专线接入,实现了本地交易系统与云上分析系统的低延迟互通,端到端时延控制在5ms以内,满足了监管对核心业务延迟的严格要求。
五、边缘弹性公网IP:低时延的"最后一公里"
5.1 它和弹性IP有什么区别?
弹性IP是"区域级"的公网IP,边缘弹性公网IP是部署在边缘节点的公网IP,更靠近用户,延迟更低。
5.2 四大杀手级场景
| 场景 | 为什么选边缘弹性公网IP |
|---|---|
| IoT物联网 | 大量设备需要稳定的网络连接,边缘IP提供低延迟、高可靠的接入。 |
| 实时音视频 | 视频会议、在线直播对延迟极其敏感,边缘IP可将时延压到最低。 |
| 边缘数据分析 | 数据在边缘节点实时处理,无需回传云端,带宽成本骤降。 |
| 智能家居/智慧城市 | 各种智能设备通过边缘IP接入,实现低延迟的控制和管理。 |
六、选型决策树:一张图搞定
| 你的需求 | 选什么 |
|---|---|
| 云主机需要固定公网IP,做网站/API | 弹性IP |
| 多台云主机出公网,想省带宽费 | 共享带宽 + 弹性IP |
| VPC内大量主机出公网,不想每个都绑EIP | NAT网关(SNAT) |
| 云主机对外提供服务,但不想暴露所有端口 | NAT网关(DNAT) |
| 本地IDC和云上VPC需要高速互通 | 云专线 |
| 混合云场景需要指定私网IP互访 | 私网NAT网关 |
| 边缘场景需要低延迟公网接入 | 边缘弹性公网IP |
| SNAT出公网需要高可用防封堵 | NAT网关 + 多EIP池 |
七、写在最后:网络产品不是"买了就完了"
很多团队的误区是:网络产品是"基础设施",买了就不用管了。
大错特错。
弹性IP不解绑会持续计费,共享带宽的IP池需要动态调整,NAT网关的SNAT规则需要监控连接数,云专线的链路需要配置健康检查——这些都是运维的活。
天翼云提供了完整的可视化运维能力:弹性IP和NAT网关的流量监控、共享带宽的使用率统计、云专线的链路状态——但工具给你了,用不用是你的事。
网络产品选对了,你的架构稳如磐石;选错了,你的业务就是在沙滩上盖楼。
作为开发工程师,你写的每一行代码最终都要通过网络到达用户。网络的品质,就是你应用的天花板。 而这些产品,就是帮你把天花板抬高的工具。
别等出了事才来研究网络——现在就打开控制台,对照你的架构,看看每个环节是不是都选对了。