Chapter 1. Introduction to Red Hat Ansible Automation Platform on Microsoft Azure
1.1. About Ansible Automation Platform on Microsoft Azure
Ansible Automation Platform on Microsoft Azure is a managed application that you can deploy from the Azure Marketplace portal to a resource group in your Azure tenant. Ansible Automation Platform on Microsoft Azure provides access to a library of Ansible content collections, and it is integrated with key Azure services, so you can start deploying, configuring, and managing infrastructure and applications quickly.
1.2. Ansible Automation Platform on Microsoft Azure pricing tier
As of December 16, 2024, Microsoft has adjusted the API, quotas, and limits of Azure Kubernetes Service (AKS) cluster tiers. All Ansible Automation Platform on Microsoft Azure deployments will move from the AKS Free tier to the Standard tier as part of infrastructure changes when upgrading to Ansible Automation Platform 2.5. This transition aligns the management requirements of Ansible Automation Platform on Microsoft Azure deployments to the proper Azure solution. This change increases the Azure infrastructure costs as the new infrastructure is added to the offering.
1.3. Application Architecture
Ansible Automation Platform on Microsoft Azure is installed as a managed application. Red Hat manages both the underlying Azure resources and the software running on it while that infrastructure runs in your Azure tenant.
The managed application resource group (RG) is completely separate from other RGs in your tenant. Red Hat only has access to the managed application RG, with no visibility into other tenant resources.
For information about how this works and how resources and access are isolated from the rest of your Azure resources, refer to Azure managed applications overview in the Microsoft Azure managed applications guide.
Ansible Automation Platform on Microsoft Azure uses the following RGs:
- A new or existing RG in your tenant. This RG includes a single resource referring to the Ansible Automation Platform on Microsoft Azure managed application deployment. Red Hat has access to the managed app to perform support, maintenance, and upgrades, but the RG is outside of Red Hat’s management.
- A multi-tenant managed resource group (MRG) that contains most of the infrastructure needed to operate Ansible Automation Platform on Microsoft Azure. This multi-tenant MRG is shared between the Red Hat tenant and your tenant. Red Hat has full administrative control and you have read-only access to the RG.
- An AKS node pool resource group (NPRG). Microsoft requires the NPRG for AKS deployments. It contains resources that AKS uses to function. It is created on deployment, and it is outside of Red Hat’s management. Refer to Microsoft’s AKS documentation for more information about NPRGs.
Do not interact with any resources in the NPRG unless explicitly directed to by the Ansible Automation Platform on Microsoft Azure SRE team. Changes to resources in the NPRG cannot be protected by Red Hat and can cause irrecoverable damage to the application.
Red Hat cannot restrict your ability to change or delete resources in the NPRG.
When you install Ansible Automation Platform on Microsoft Azure, you choose whether the deployment is public or private. This affects how users can access the Ansible Automation Platform user interfaces.
Regardless of whether you choose a public or private deployment, you must configure network peering for outbound communication from Ansible Automation Platform to the private networks that contain resources that you want to automate against. You can configure network peering from Ansible Automation Platform on Microsoft Azure to your private Azure VNets and to on-premises or multi-cloud networks where transit routing with Azure exists.
1.3.1. Public deployment
Public deployments permit ingress to the Ansible Automation Platform on Microsoft Azure user interfaces over the public internet. Upon deployment, a domain name is issued to the Ansible Automation Platform on Microsoft Azure instance. No configuration is required to access Ansible Automation Platform. You can navigate to the domain from the public internet and log in to the user interfaces.
The following diagram outlines the application resources and architecture that are deployed into the managed application resource group on a public deployment of Ansible Automation Platform on Microsoft Azure into your Azure subscription. The IP ranges change based on the networking address range you set on deployment.

1.3.2. Private deployment
A private deployment of Ansible Automation Platform resides in an isolated Azure VNet with no access from external sources: traffic to and from the public internet and other Azure VNets and subnets is blocked.
To access the URL for the Ansible Automation Platform user interfaces, you must configure network peering.
After you have configured peering and routing, you can access Ansible Automation Platform through a VM on a connected Azure subnet, or directly if your organization has transit routing set up between Azure and your local network.
No two Azure networking configurations are the same. To allow user access to your Ansible Automation Platform URL, your organization needs to work with your Azure administrators to connect the private access deployment.
The following diagram outlines the application resources and architecture that are deployed into the managed application resource group on a private deployment of Ansible Automation Platform on Microsoft Azure into your Azure subscription. The IP ranges change based on the networking address range you set on deployment.

1.3.3. Security
Ansible Automation Platform on Microsoft Azure follows security best practices from both Red Hat and Microsoft. The following resources describe the security posture of the application and the infrastructure.
Data encryption in flight and at rest
- All Azure Storage Services enable server-side encryption by default using service-managed keys
- All Azure hosted services are committed to providing Encryption at Rest options
- Azure encryption overview
- All communications between services within Azure Kubernetes Service (AKS) (for example, Ansible Automation Platform, Postgres, storage accounts) use Transport Layer Security (TLS) v1.2 or higher.
- Azure security baseline for Azure Kubernetes Service (AKS)
Password storage
- The customer-supplied Ansible Automation Platform admin password is encrypted in transit. It is accessible to site reliability engineers (SREs) from the Kubernetes API and can be reset by the SREs upon customer request.
Keys generated with industry standards
Key installation, rotation
SSL/TLS traffic encryption
- All communications between services within AKS (for example, Ansible Automation Platform, Postgres, storage accounts) use TLS v1.2 or higher.
- All communications to Ansible Automation Platform UIs, either via the application gateway for public deployments or the nginx ingress for private deployments, use TLS v1.2 or higher.
API security
- Any parts of the Ansible Automation Platform APIs that could leak any sensitive information are only accessible via authenticating as a known Ansible Automation Platform user and require that user to have the right level of authorization to use those APIs. In a private deployment, access to the Ansible Automation Platform APIs is only accessible to the customer via the route they choose to connect to the private deployment.
- The Kubernetes API is private and only accessible from a private endpoint
- Workload identity is enabled and it allows Kubernetes applications to access Azure cloud resources securely with Microsoft Entra ID.
Updates and patching
- The Red Hat SREs regularly update the Kubernetes version, underlying node OS, and Ansible Automation Platform version to the latest available stable versions to get the latest features, bug fixes, and security fixes.
1.4. Disaster recovery
When you deploy Ansible Automation Platform on Microsoft Azure, you must enable or disable disaster recovery in the Business Continuity
tab of the form. There is no default setting for disaster recovery.
The disaster recovery feature incurs additional Azure infrastructure costs. See Ansible Automation Platform on Microsoft Azure infrastructure usage for details of the Service Shape of the Storage account.
If you want to enable disaster recovery on an existing instance of Ansible Automation Platform on Microsoft Azure, contact Red Hat customer support.
The disaster recovery feature creates a nightly backup of your managed application and stores it in a paired region that is geographically distant to your primary region. For information about regional pairings, refer to Azure cross-region replication pairings for all geographies in the Azure reliability documentation.
For information about recovering your application after a service-impacting event, see the Disaster recovery for Ansible Automation Platform on Azure article on the Red Hat customer portal.
1.5. Ansible Automation Platform on Microsoft Azure infrastructure usage
When you install Ansible Automation Platform on Microsoft Azure, you deploy the following infrastructure into your Microsoft Azure subscription:
- Managed identity
- A Microsoft Azure service that enables Ansible Automation Platform components to communicate with other Microsoft Azure services such as database, DNS, storage, and other services.
- Key vault
- A secure key vault used to store secrets that are unique to the Ansible Automation Platform deployment.
- Log Analytics Workspace
- A Microsoft Azure service that enables Red Hat site reliability engineers to inspect the operations of Ansible Automation Platform on Microsoft Azure.
- Private DNS Zone
- Manages local DNS requests for the services used by Ansible Automation Platform on Microsoft Azure.
- Storage account
The Microsoft Azure service is used for file and block storage such as local storage of projects and containers.
Service Shape:
- If disaster recovery is not enabled: StorageV2 - Standard_LRS
- If disaster recovery is enabled: StorageV2 - Standard_GRS
- Virtual network
The Microsoft Azure service is used to manage all internal networking and dependent services such as the Azure Application Gateway.
Service Shape: Application Gateway: WAF_v2
- Azure Kubernetes service (AKS)
The Kubernetes cluster used to deploy Ansible Automation Platform applications and services.
ImportantAll deployments will move from the Azure Kubernetes Service (AKS) Free tier to the Standard tier as part of infrastructure changes when upgrading to Ansible Automation Platform 2.5.
Service Shape for all Ansible Automation Platform plan sizes:
- Compute nodes: Standard_D4ds_v5 (4 vCPUs x 16 GiB)
- Autoscaling minimum nodes: 3
- Autoscaling maximum nodes: 20
- Azure Database for PostgreSQL
A Microsoft Azure database service used for Ansible Automation Platform’s PostgreSQL database. The following table presents the different configuration tiers based on the plan purchased.
Ansible Automation Platform plan size (minimum node count)
Database shape configuration
Database storage
50
Standard_D2s_v3
512 GB
Provisioned 2,300; up to 3,500
400
Standard_D4s_v3
512 GB
Provisioned 2,300; up to 3,500
1000
Standard_D4s_v3
512 GB
Provisioned 2,300; up to 3,500
2500
Standard_D4s_v3
512 GB
Provisioned 2,300; up to 3,500
5000
Standard_D4s_v3
1 TB
5000
10000
Standard_D4s_v3
1 TB
5000
Exact infrastructure usage depends on the length of time that the managed application is deployed in your tenancy, and the automation requirements that might cause the Kubernetes cluster to autoscale to meet the demands of your workload.
Microsoft provides a Pricing calculator to estimate your costs for Microsoft Azure products and services. Red Hat has configured an example scenario in the pricing calculator: use the Red Hat Ansible Automation Platform on Azure Infrastructure Estimate to tune Kubernetes expected auto scaling variables based on your organization’s workloads.
If Red Hat determines that a deployment’s automation might exceed the capabilities of the current tier of the deployment, then Red Hat site reliability engineers will work with you to upgrade the infrastructure tier based on automation needs.
1.6. Lifecycle management
Red Hat Ansible is responsible for the monitoring, health, and maintenance of the underlying services and Ansible Automation Platform on Microsoft Azure core systems as well as the operation of Ansible Automation Platform on Microsoft Azure itself. This includes lifecycle management of the components.
1.7. Ansible Automation Platform on Microsoft Azure scaling
Ansible Automation Platform on Microsoft Azure default configuration of Microsoft Azure cluster autoscaler for autoscaling, with the following settings to limit the number of nodes:
- Minimum Nodes: 3
- Maximum Nodes: 20
1.8. Migration
Red Hat does not provide a solution to migrate existing deployments to Ansible Automation Platform on Microsoft Azure.