1. Start/Stop VMs
We’re talking about Azure here, so this is the most obvious application to Azure Automation and it can save a lot of money! You can run VMs just during working hours, shutting them down and deallocating at the end of the day, or you can start VMs based on need – when a certain job is started, the VM can boot, process the data, then shut down when it’s not needed. This is great for end of period reporting, if there’s a lot of data to process, and for developer environments. There’s lots of ready-to-go runbooks with the ability to filter VMs based on tags, allowing you to schedule some, but not all VMs to shut down – this could be useful for applications that need many servers at certain times of the day, but fewer at off-peak times – provided you cannot set up the application in VM Scale Sets, of course.
2. Replace SQL Agent Jobs
Moving to Azure SQL Database is a great way to reduce server management tasks and costs when migrating to Azure. Unfortunately, the Azure DB service doesn’t have a SQL Agent available due to the nature of the service. You can migrate your SQL Agent jobs to Azure Automation, which can connect to your SQL Databases and easily run automated tasks. If the SQL Agent job needs to access VM data somewhere in your network, you can use Hybrid Runbooks to allow Azure to run the job locally, like a Task Scheduler job. The benefit to Hybrid Runbooks over Task Scheduler is that the job is more likely to run if a server is offline – provided you install more than one hybrid worker!
3. Manage Patches
Did you know that Azure Automation has a native Update Management capability? You can manage your VM updates from a single pane of glass, without needing to invest in a complex configuration management solution. You can quickly onboard VMs and see what patches are missing, triage the most critical patches, and apply them – without having to log into the VM itself. You can schedule regular installation of updates, or apply the specific updates just once. There’s a rich reporting system that can tell you at a glance the current compliance across your servers, and a quick view into whether the installation was successful. The solution can even give you an estimate for how long a given patch will take to install, based on other agents that have installed the same update – that can be tremendously helpful when setting expectations with your business!
Windows is, naturally, supported – using WSUS or public Microsoft update, and some flavours of Linux are supported as well.
4. Respond to an event alert
Azure Automation can start a runbook when a webhook is called. When an event occurs, the source makes an HTTP request to the URL configured for the webhook, containing some data, and Azure Automation can be configured to parse the data and make a change based on that information. An example could be (returning to the first point) starting a VM if an infrequent task relies on the VM running – when a user starts the process, a webhook containing the VM name and the action (Start) could be sent to Azure Automation, and the VM would boot up in a few minutes. Another example of handling events, which has a more direct application for InfoSec and ITPros, is to respond to an event – for example, if a critical service stops on a VM, Azure Automation can run to reboot the VM or restart the service, or if CPU use gets too high, Azure Automation can scale up the application one server at a time. This isn’t limited to Azure VMs; hybrid runbook workers can run scripts inside AWS or on premises just as easily (though the capabilities are limited to what’s possible on the system you’re connecting to)