Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Prerequisites for Installing Red Hat Ansible Automation Platform on Microsoft Azure

To install Ansible Automation Platform on Microsoft Azure, you must first ensure your environment meets all technical prerequisites.

2.1. Azure requirements
Copy link

  • A subscription for Microsoft Azure.
  • Contributor or Administrator access to that Azure subscription.
  • Access to the Azure command line interface (CLI).

2.2. Ansible Automation Platform requirements
Copy link

  • An account on the Red Hat Red Hat Customer Portal (access.redhat.com).
  • A specific subscription entitlement for Red Hat Ansible Automation Platform.

Microsoft imposes resource limits within each Azure region. The CPU limit is the most likely to impact Red Hat Ansible Automation Platform on Microsoft Azure.

Before you install Ansible Automation Platform on Microsoft Azure, ensure that you have capacity to deploy the managed application into your desired region. Refer to Ansible Automation Platform on Microsoft Azure infrastructure usage for infrastructure requirements.

2.3.1. Regional vCPU limits
Copy link

The Azure resources used during the deployment of the managed application temporarily exceed the resource requirements in Ansible Automation Platform on Microsoft Azure infrastructure usage. The Total Regional vCPUs quota is temporarily consumed when deploying the managed application.

Every Azure region has a separate Total Regional vCPUs quota. To prevent installation failure, ensure that you have at least 80 DDSv5 and 8 DSV3 vCPUs available in the Azure region where you want to deploy the managed application.

You can view the resource quotas for your subscription from the Azure console. Open the My Quotas page and select the region where you wish to deploy the managed application to view your allocation and usage metrics for that region. Ensure that you have selected a single region. Viewing all regions at once does not show the limitations of a single Azure region.

2.3.2. Regional StandardCore limits
Copy link

The StandardCore limit is a compute metric for the resources that are temporarily consumed when deploying the managed application.

It is possible that the Ansible Automation Platform on Microsoft Azure can deploy without hitting the StandardCore limit. When a deployment fails because the consumed resources hit the StandardCore limit, the error message includes container group quota 'StandardCores' exceeded: 

code: DeploymentFailed
message:
  At least one resource deployment operation failed. Please list deployment operations for details.
  Please see https://aka.ms/DeployOperations for usage details.
details:
  - code: DeploymentScriptContainerGroupInvalidSettings
    message:
      Resource type 'Microsoft.ContainerInstance/containerGroups'
      container group quota 'StandardCores' exceeded in region 'eastus'.
      Limit: '10', Usage: '10' Requested: '1'.
Copy to Clipboard Toggle word wrap

2.3.3. Requesting StandardCore limit increase
Copy link

The StandardCore metric is not displayed in the My Quotas page in the Azure console. To request the value of your regional limit, contact Microsoft directly.

If your deployments fail because the consumed resources reach this limit, you must submit a resource increase request for StandardCore to Microsoft. Only submit a quota increase request if you encounter a deployment failure due to this issue.

Use the following information to respond to questions from Microsoft support:

Will the container groups be run in Linux or Windows?
Linux
What will the core and memory be in your Container Group instance?
Red Hat recommends 20 cores, 16 GB
When will you create all the Container Group Instances?
During managed application deployment of Red Hat Ansible Automation Platform on Microsoft Azure
How frequent will you create/delete the container groups?
Only during managed application deployment of Red Hat Ansible Automation Platform on Microsoft Azure

2.4. Azure resource providers
Copy link

Microsoft uses Azure resource providers as a set of REST operations that enable functionality for a specific Azure service in an Azure subscription.

For example, the Key Vault service consists of a resource provider named Microsoft.KeyVault. The resource provider defines REST operations for managing vaults, secrets, keys, and certificates.

The resource provider defines the Azure resources you can deploy in your Azure subscription.

2.4.1. Required Azure Resource Providers
Copy link

Ansible Automation Platform on Microsoft Azure installation requires specific Azure Resource Providers registered in your Azure subscription before you attempt a new installation: 

"Microsoft.Compute"
"Microsoft.ContainerService/"
"Microsoft.DBforPostgreSQL/"
"Microsoft.KeyVault/"
"Microsoft.ManagedIdentity/"
"Microsoft.Network/"
"Microsoft.OperationalInsights/"
"Microsoft.OperationsManagement/"
"Microsoft.Resources/"
"Microsoft.ResourceGraph"
"Microsoft.Storage/"
"Microsoft.Solutions"
Copy to Clipboard Toggle word wrap

2.4.2. Registering Azure Resource Providers
Copy link

To register Azure Resource Providers, follow the instructions in the Register resource provider section of the Azure documentation.

2.5. Network
Copy link

When you deploy Ansible Automation Platform on Microsoft Azure, you can configure the following networks in the Networking tab of the form:

  • The networking address range (CIDR block) for the VNet that your Ansible Automation Platform on Microsoft Azure application uses.
  • AKS network CIDR blocks.
Note

Plan your networking configuration before you deploy the Ansible Automation Platform on Microsoft Azure application, because you cannot change it after deployment.

2.5.1. VNet CIDR blocks
Copy link

You can configure the networking address range (CIDR block) for the VNet that your Ansible Automation Platform on Microsoft Azure application uses.

You set the CIDR block for the application in the Configure virtual networks section of the form when you deploy Ansible Automation Platform on Microsoft Azure.

When you are planning your network configuration, bear the following in mind:

  • The managed application requires at least a /24 Vnet that is divided into four subnets. The subnets have minimum address spacing.

    Expand
    Networking entityMinimum CIDR Block

    VNet

    /24

    Cluster subnet

    /26

    Gateway subnet

    /28

    Database subnet

    /28

    Private link subnet

    /28

  • Ensure that the VNet range you configure does not intersect with the default CIDR block for AKS clusters (10.0.0.0/16). The Azure user interface does not prevent you entering this range, but using the default AKS CIDR block for your VNet causes networking issues.
  • To ensure successful network peering and communication between Ansible Automation Platform on Microsoft Azure and your existing networks, your enterprise network ranges must not overlap with the VNet network range.
  • If you do not have any existing Azure VNets, the Azure user interface suggests a default CIDR block and range for the VNet. Do not accept these defaults. Instead, use the network configuration that you have planned.

For information about planning the network address range and completing the networking configuration form on deployment, refer to Red Hat Ansible Automation Platform on Microsoft Azure VNet Preparation.

2.5.2. AKS CIDR Blocks
Copy link

You can configure the AKS network CIDR blocks. Traffic that originates from the AKS cluster appears to come from the range configured in AKS, not from the VNET.

When you are planning your AKS CIDR block configuration, bear the following in mind:

  • Ensure that these network ranges do not overlap with any existing network range in your enterprise network.

  • Do not use the following reserved network ranges:

    Expand
    AKS Reserved CIDR Blocks

    169.254.0.0/16

    172.30.0.0/16

    172.31.0.0/16

    192.0.2.0/24

    172.17.0.1/26

You can configure the AKS network CIDR blocks in the Configure AKS networks area of the networking tab. Do not accept the default values suggested in the Azure user interface. Instead, use the CIDR blocks that you have planned. The settings have the following requirements:

Expand

Network

Description

Requirements

Service CIDR

A CIDR notation IP range from which to assign service cluster IPs.

It must not overlap with any Subnet IP ranges.

Requires a /24 block at minimum. A larger block is not necessary.

This CIDR block must not intersect with the CIDR of the Pod CIDR block.

This CIDR block also must not intersect with the CIDR of the VNET CIDR block.

DNS Service IP

An IP address assigned to the Kubernetes DNS service.

It must be within the Kubernetes service address range specified in serviceCidr.

Must be an IP address in the Service CIDR other than the first IP in that range.

Red Hat recommends using the first .10 IP address within the Service CIDR block.

Pod CIDR

A CIDR notation IP range from which to assign pod IPs when kubenet is used.

Requires a /19 or larger block.

This CIDR block must not intersect with the CIDR of the Service CIDR block.

2.6. Azure Policy
Copy link

Azure Policy is a tool to help organizations enforce compliance of Azure resources to defined standards.

For information on using Azure Policy with Ansible Automation Platform on Microsoft Azure, see Azure Policy and Ansible on Azure.

2.7. Entitling your subscription
Copy link

To access your deployment, you need an existing subscription entitlement that you can assign to your Ansible Automation Platform when you first log in.

For information on obtaining a subscription entitlement and attaching it to Ansible Automation Platform, see Red Hat Ansible Automation Platform on Microsoft Azure Subscription Entitlement Association.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat