如何在Azure新建VM时触发运行Python代码的Azure Function

方案1：Event Grid直连Azure Function（与AWS CloudWatch+Lambda对等的最简链路） #

此前搭建Event Grid链路时找不到VM监控触发器，核心问题是找错了事件源的筛选入口——VM创建属于Azure资源管理器的操作类事件，根本不需要依赖VM专用的状态类触发器，可直接给Python Azure Function配置事件网格触发器实现对等能力：

• 为Python运行时栈的Azure Function创建Event Grid类型触发器，无需额外搭建Logic App做中转
• 将事件源范围设置为目标订阅层级（VM创建是订阅下的全局ARM操作，不是单资源的本地状态变更）
• 事件类型筛选勾选Microsoft.Compute/virtualMachines/write操作事件，同时在Function代码中增加判断逻辑：仅当操作返回状态为成功、且对应资源为全新创建的VM时才执行业务代码，排除VM配置修改、重启等同操作类型的误触发场景
• 配置事件网格到Function的访问授权，关闭匿名访问权限，避免非法事件触发
  该链路的能力、触发时机与AWS平台上CloudWatch Events触发Lambda的模式完全对齐，是架构上最对等的实现方式

方案2：Custom Script Extension精准触发（适配VM完全可用的场景） #

如果需要等VM初始化完成、可正常访问后再运行Python代码，可通过VM扩展机制实现更精准的触发：

• 在订阅层级配置自定义脚本扩展的默认部署策略，所有新建VM部署时会自动推送Custom Script Extension
• 扩展的执行逻辑配置为：VM首次开机完成、拿到扩展执行权限后，携带VM的元数据（资源ID、区域、资源组）向Python Azure Function的HTTP触发端点发送请求
• 该方案不会出现ARM层事件触发但VM实际创建失败、无法执行业务的无效场景，触发时机更靠近真实的VM可用状态

之前Logic App搭建链路的问题排查 #

此前用Logic App+Event Grid找不到VM监控触发器的核心原因：

• Logic App的VM专用内置连接器默认仅列出VM运行时状态类触发器（比如关机、重启），没有纳入ARM层的VM创建操作事件
• 正确的Logic App配置方式为：跳过VM专用连接器，直接选择Event Grid连接器，同样绑定订阅级事件源、筛选Microsoft.Compute/virtualMachines/write事件，后续在工作流中调用目标Python Function即可。该链路仅适合需要多步骤编排（比如触发前加审批、通知环节）的场景，无编排需求时无需增加Logic App的中转层，避免额外的运维成本。

常见落地注意事项 #

• 事件订阅的范围不要固定在单个资源组，需在代码逻辑中增加跨资源组事件的识别能力，避免分散在不同资源组新建的VM无法触发
• Python Function代码中需增加Event Grid订阅验证请求的校验逻辑，避免将首次配置事件订阅时的验证请求当成正式VM创建事件执行业务逻辑
• 若使用独立云环境，需核对对应云环境的事件类型名称，避免因事件命名差异导致的筛选失效

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