如何配置AAS防火墙永久允许Azure托管生成代理IP访问

针对问题1：是否可参照Azure SQL的配置逻辑，在AAS防火墙中开启允许所有Azure服务访问 #

AAS没有提供和Azure SQL对等的「允许所有Azure内部服务访问」的内置配置开关，无法直接套用Azure SQL的配置逻辑实现全Azure服务的豁免放行。
AAS防火墙仅支持基于明确IP地址、CIDR地址段的白名单规则，不存在内置的Azure服务标签豁免选项。如果直接配置0.0.0.0/0放通所有地址，等同于完全关闭公网防火墙，安全风险极高，生产环境严禁采用该操作。

针对问题2：AAS配置变更后防火墙规则被重置，如何实现规则持久化 #

配置变更后规则被清空的核心原因是：更新AAS配置的请求采用了全量覆盖逻辑，请求Payload中没有携带原有防火墙规则，导致未在更新请求中显式声明的规则被直接清除。可根据实际场景选择以下方案解决：

• 优先替换为自托管DevOps代理
  将DevOps生成代理部署在自有可控的VNet子网内，给AAS配置VNet防火墙规则，仅放通该代理所在子网的地址段即可。该方案不需要维护零散的公网IP白名单，也不会受微软托管代理IP池动态变动的影响，稳定性和安全性最高。
• 将防火墙规则固化到基础设施即代码（IaC）模板
  如果使用ARM/Bicep/Terraform等IaC工具管理AAS实例配置，把所有需要保留的白名单规则（包括运维出口固定IP、业务依赖服务的固定出口IP）全部显式写入模板的firewallSettings配置块，部署时选择增量部署模式而非全量覆盖模式，后续所有AAS配置变更都通过该模板执行，就不会出现规则被清空重置的问题。
• 微软托管代理场景下使用动态规则方案
  如果必须使用微软托管的DevOps生成代理，不需要持久化添加大范围的Azure IP段：可在流水线中执行AAS表刷新任务前增加2个前置步骤：
  1. 获取当前流水线运行的代理出口公网IP
  2. 调用AAS管理接口将该临时IP加入防火墙白名单
     等刷新任务执行完成后，增加一个后置步骤自动删除这条临时IP规则即可。该方式不需要维护庞大的Azure IP池列表，也不会触发AAS防火墙规则的配额限制，同时避免了规则被配置变更冲掉的问题。

注意：不要尝试将整个Azure公有云的IP段全部加入AAS白名单，AAS单实例的防火墙规则条目有明确配额限制，全量添加Azure IP段不仅会快速触达配额上限，还会极大扩大实例的公网攻击面。

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