Introduction
Azure Automation is a tool used to automate various processes across hybrid cloud estates built to simplify cloud management and reduce human error. Among a variety of capabilities, it is often used as a governance mechanism and integrated into DevOps pipelines to simplify resource configurations. While it is not typically included in the serverless category with Logic Apps, Functions, and other Azure messaging and eventing tools, it runs in a similar fashion on shared infrastructure.
However, like isolating other serverless workloads, you can also run Azure Automation processes (a.k.a. Runbooks) on Hybrid Runbook Workers. Hybrid Runbook Workers are typically deployed on premises and activated by Azure Automation to allow Azure Automation to interact with infrastructure or resources that sit behind a firewall:
Private Endpoints
A limitation of Azure Automation today is that it cannot natively interact with Azure resources that leverage Private Endpoints. If you’re not familiar with Private Endpoints, they’re a networking construct in Azure created to place a private IP address into your virtual network and restrict public connectivity to PaaS services. It’s a great way for customers to increase the security of their network paths and helps our regulated customers meet specific compliance requirements.
A customer of mine recently wanted to leverage Azure Automation to interact with an Azure SQL database behind a Private Endpoint. To solve for this, we deployed a Hybrid Runbook Worker inside of their Virtual Network:
The Hybrid Runbook Worker can run on Windows or Linux VMs and the VM only has to be running while the job needs to run. You can also run several Hybrid Workers in a group to ensure high availability. Depending on the complexity of the Automation task, you may be able to simply leverage an existing VM in your environment.
In my Azure lab, I simply created a new Azure SQL database loaded with sample data. To test the connection, I used PowerShell’s Invoke-Sqlcmd inside of an Azure Runbook running on the Hybrid Worker. You can also test connectivity from the VM using the method outlined in this blog post.
What’s Next?
Note that this pattern is different than leveraging a Private Endpoint for the Azure Automation resource itself. That functionality is still in Public Preview, but it would hypothetically allow you to drop a Private Endpoint for the Azure Automation account in your virtual network as well.
As with most Azure features in Preview, it’s best to fully test them when they’re marked GA (Generally Available). It’s also possible that this new connectivity pattern will support native connectivity to other Azure PaaS services over Private Endpoints without needing Hybrid Workers deployed in your virtual network.
