Azure App Service自动缩放：如何处理新增出站IP的白名单配置？

这确实是Azure App Service自动缩放场景下非常常见的痛点——当Web A扩容出全新实例时，出站公网IP会发生变化，直接导致被App B的防火墙规则拦截。我之前帮不少客户处理过类似需求，整理了几个最实用的解决方案：

方案1：使用虚拟网络（VNet）集成 #

• 把Web A和App B部署到同一个虚拟网络，或者通过VNet peering连接两个不同的VNet。这样两个服务之间的流量会走Azure内网，不再依赖公网出站IP。
• 在App B的防火墙规则中，直接添加Web A所在VNet的CIDR地址段即可。后续Web A自动缩放的新实例会自动加入VNet，内网IP始终在允许范围内，完全不会出现IP拦截问题。
• 注意：需要确保Web App使用的SKU支持VNet集成（比如Basic及以上，推荐Premium系列）。

方案2：启用App Service服务端点（Service Endpoints） #

• 这是比VNet集成更轻量的方案，不需要复杂的VNet配置。在Web A的网络设置中，启用App Service类型的服务端点，这样Web A发往App B的流量会通过Azure骨干网络传输，并且App B可以识别到请求来自Web A这个特定资源。
• 在App B的防火墙规则里，选择“允许来自特定Azure资源的访问”，直接选中Web A的资源即可。这种方式不需要维护任何IP地址，缩放时新实例自动继承服务端点配置，访问权限不受影响。
• 优势：配置简单，同订阅/跨订阅都支持，适合大多数中小规模场景。

方案3：配置固定出站IP或出站IP前缀 #

• 如果你的业务必须依赖公网IP访问，可以给Web A配置固定出站IP或者出站IP前缀：
  • 固定出站IP：使用Premium v2/v3或Isolated SKU的Web App，可以获得固定的出站IP地址（最多10个），把这些IP全部加到App B的白名单里。
  • 出站IP前缀：给Web App分配一个出站IP前缀（CIDR段），只需要把这个前缀加到App B的白名单，后续所有缩放实例的出站IP都会落在这个段内。
• 注意：这个方案需要更高等级的SKU，成本会有所上升，而且需要定期确认IP前缀是否有变更（Azure一般不会随意变更，但还是建议监控）。

方案4：通过中间层统一入口（适合已有架构） #

• 如果你的系统已经在使用Azure Front Door或者API Management，可以把它们作为流量中间层：Web A先请求Front Door/APIM，再由中间层转发到App B。
• 只需要把Front Door或APIM的公网IP前缀加到App B的白名单里，Web A的缩放实例只需要访问中间层即可，完全不用考虑IP变化的问题。
• 适合已经有统一入口架构的场景，额外成本较低。

个人推荐优先级 #

我一般优先推荐服务端点或者VNet集成，这两个是Azure官方主推的原生解决方案，稳定性最高，不需要手动维护IP列表，后续运维成本极低。如果必须用公网IP，出站IP前缀是比固定单个IP更灵活的选择。

内容的提问来源于stack exchange，提问作者j_r