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

Important

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.
Note

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.

aap on azure public 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.

Note

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.

aap on azure private 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.

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.

Important

All 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

IOPS

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.

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

© 2025 Red Hat, Inc.