Search code examples
azurecloudazure-cloud-servicesazure-runbook

Best practice to deploy Azure Automation Account Runbooks


I'm trying to deploy multiple python runbooks using Azure Automation Account, the python packages used are the same between the runbooks but every runbook corresponds to a different project or initiative. And I'm looking for some architecture design advise here.

So, my question is: Should I create different automation accounts (cause there's not max limit of automation accounts) for every project, in order to maintain the logics separated?

Or should I use the same Automation Account and create different runbooks inside, and try to group similar runbooks logics into the automation account? (the advantage of the latter is that the python packages are loaded only once in one automation account)

Important note: the access permissions will be the same on every runbook, so, permissions wise, there is not problem in creating different or use the same automation account.


Solution

  • When we talk about the automation process, azure bill us for runbook jobs and watchers. For runbook jobs you will be charged for the total number of minutes you run your jobs across all automation account in a month with first 500 minutes free. Check this document for more information on pricing.

    So, pricing won't be any problem in your case. Till now I haven't found any scenario that specifies when we should use single or multiple automation accounts and it's mostly based on the project requirement.

    If your project requirement is to have a model where separation of the logics of the jobs are of most priority then you can create different automation account for multiple runbooks (For example, you might use one account for development, another for production, and so on) or else I would prefer to use the same automation account.

    Check Azure Automation document and Automation account document for more information.