AWS控制台里那个"自动分配IP"的勾，点下去只需要0.3秒。但当你在第17次架构评审会上被网络团队追问"这64个IP到底从哪扣的"时，才会意识到这个默认值埋了多深的坑。
Amazon FSx for NetApp ONTAP的Multi-AZ部署，表面上是个勾选框的复杂度，实际是把传统企业存储的高可用逻辑，强行塞进VPC路由表的32位前缀里。今天拆这台机器的网线。
单AZ是合租，Multi-AZ是异地恋
Single-AZ部署的逻辑很直给：active节点和standby节点挤在同一个子网，像合租室友共用一根网线。节点挂了？standby接管IP，客户端甚至不会触发TCP重传。
Multi-AZ把这对室友强行拆散到两个可用区。AWS的可用区隔离是物理级的——光纤、电力、洪水风险全部独立——但代价是子网不能跨AZ。AZ-A的IP地址，AZ-B的节点这辈子都碰不到。
这就产生了一个经典的产品经理困境：用户要的是一个永远可达的端点，但底层基础设施拒绝提供固定的锚点。
AWS的解法不是DNS轮询，不是负载均衡器，而是直接往你的VPC路由表里写/32主机路由。他们给这个东西起了个名字叫"Floating IP"，但行为和传统网络里的浮动IP完全不同——它不绑定在网卡上，而是绑定在路由表的下一跳指针上。
路由表里的魔术：ENI指针的瞬移
创建Multi-AZ文件系统时，AWS会索要一个IP范围。从这个范围里抠出来的地址，不会出现在任何EC2实例的网卡配置里。它们以/32路由的形式躺在你的路由表中，目标指向当前active节点的弹性网络接口（ENI）。
控制台里看到的路由表大概长这样：
Destination 198.19.0.12/32 → Target eni-0abc123def4567890
这个eni-0abc123def4567890属于AZ-A的active节点。当健康检查失败，FSx的后台服务会在秒级内把这条路由的目标改成AZ-B的standby节点ENI。没有DNS TTL过期，没有连接池重建，纯粹是三层路由的指针切换。
Varun Seth在AWS Community Builders的分享里点破了这个设计的精妙之处：「它是个brilliant, DNS-free failover mechanism」。DNS-free这个词很关键——企业NAS迁移最怕的就是客户端缓存，而路由表更新对所有客户端是瞬时生效的。
但精妙是有代价的。这个代价就是IP地址的预算管理。
64个IP的默认陷阱
如果你在控制台里一路点"下一步"，AWS会默默勾选"自动分配浮动IP"，然后从VPC主CIDR的最后64个地址里划走一块。这个设计假设你的网络规划像AWS文档示例一样整洁：一个/16 VPC，前半段给计算，后半段给存储，井水不犯河水。
现实网络很少这么理想。我见过一个案例：某金融客户的VPC里跑着2000+ EC2实例，最后/26的地址池早被批量化部署的容器节点吃干抹净。创建FSx文件系统时，控制台没有任何警告，后台任务却在IP分配阶段挂起45分钟后报错。
更隐蔽的问题是路由表传播。FSx注入的/32路由会出现在所有关联该路由表的子网中。如果你的网络架构用了多个路由表做流量分段——比如把生产环境和开发环境的路由隔离——需要手动把FSx的路由复制到每一张表，否则会出现"部分子网能挂载，部分子网超时"的诡异现象。
IP范围规划的三种实战模式
企业落地时通常有三种策略，各有利弊。
模式一是"预留圣地"：在VPC设计阶段就抠出一段/24专供FSx浮动IP，像保护区一样禁止其他服务占用。这需要网络团队有前瞻性，但代价是地址空间的长期闲置。
模式二是"独立CIDR"：给VPC附加一个专门的secondary CIDR，比如10.255.0.0/16，全部划给存储服务。这个方案最干净，但需要确保所有客户端子网的路由表都指向这个CIDR，否则跨CIDR的流量会被VPC的local路由黑洞。
模式三是"精准手术"：手动指定一个极小的范围，比如/29，刚好覆盖当前文件系统的端点数量。这个方案省地址，但每次扩容文件系统（增加NFS/SMB端点或iSCSI LIF）都要重新调整IP池，运维负担最重。
Varun Seth的建议是：「enterprise networks are rarely that clean」。翻译过来就是，别指望自动分配能猜中你的网络拓扑，手动指定是唯一可控的选项。
故障切换的隐藏时序
路由表更新虽然快，但不是瞬时的。AWS文档里不会告诉你的是，从节点故障被检测到路由表更新完成，中间有15-30秒的窗口期。这段时间里，新的TCP连接会失败，已有连接的NFS客户端会进入重传等待。
对于iSCSI工作负载，这个窗口更危险。多路径I/O（MPIO）配置不当的Windows服务器，会在切换期间把路径错误标记为失败，导致磁盘脱机。NetApp的ONTAP在本地部署时，故障切换可以控制在秒级，因为控制器之间有心跳直连和NVRAM镜像。云端的Multi-AZ剥离了这些硬件假设，把高可用完全委托给VPC的控制平面。
另一个边缘案例是跨VPC访问。如果客户端在另一个VPC（通过VPC Peering或Transit Gateway），Floating IP的路由不会自动传播到对端。需要在Peering连接或TGW路由表中手动添加静态路由，指向FSx所在VPC的CIDR。很多迁移项目在这个阶段卡壳，因为网络团队默认"VPC Peering就是全网可达"，忽略了/32路由的特殊性。
监控盲区：路由表变更没有CloudTrail
最反直觉的一点是：FSx对路由表的修改不会出现在你的CloudTrail事件里。这不是bug，是设计取舍——这些路由被视为AWS托管资源，变更由服务主体发起，对客户账户不可见。
这意味着你无法用标准手段审计"昨晚2点那次切换到底是计划内维护还是真的故障"。唯一的观测点是文件系统层面的事件（通过EventBridge），但事件粒度只到"failover initiated"，不会告诉你具体哪条路由被改到了哪个ENI。
对于合规要求严格的行业，这个盲区需要额外的补偿措施：定期快照路由表状态，或者通过Lambda轮询比对当前路由与基线配置。
写在最后
AWS的Floating IP设计，本质上是把NetApp ONTAP的双控制器架构，翻译成VPC能理解的方言。翻译过程中丢失了一些原生能力（比如亚秒级切换），但换来了云环境的弹性伸缩。
这个权衡是否值得，取决于你的工作负载对RTO的敏感度。对于绝大多数文件共享场景，30秒内的中断是可接受的；但对于跑在iSCSI上的老旧数据库，可能需要重新评估架构，或者退回到Single-AZ部署配合应用层的高可用。
你的网络团队最近一次检查VPC路由表，是什么时候？
热门跟贴