Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. Red Hat Ansible Automation Platform on Microsoft Azure post-deployment requirements

Understand the post-deployment requirements for private deployments of Red Hat Ansible Automation Platform on Microsoft Azure, focusing primarily on establishing private network peering.

Deploying Ansible Automation Platform on Microsoft Azure creates an independent managed resource group with its own Azure virtual network (VNet). By default, the platform can only send requests to external networks through the public internet.

To enable access to resources in private, internet-gapped deployments, you must configure Azure network peering between your private VNets and the managed application VNet of Ansible Automation Platform.

Azure network peering allows:

  • Private communication between multiple Azure VNets.
  • Private transit routing between Azure VNets and external VPN-routed networks, which can include on-premises systems or other cloud environments.

Each Azure networking configuration is unique. To enable user access to Ansible Automation Platform, collaborate with your Azure administrators to establish connections between the platform’s deployment, your VNets, and external VPN-routed networks.

Note

Network peering must be configured by Azure administrators in your organization who are familiar with Azure networking. Configuring network changes to your Azure account can cause outages or other disruptions.

The network peering procedures described in this document are not supported by Red Hat, as the processes and services are controlled and managed by Microsoft Azure. Contact Microsoft for assistance in peering Azure networks.

While every effort has been made to align with Microsoft’s documentation for this content, there may be drift in accuracy over time. Microsoft’s documentation is the definitive source for information about networking topics for Azure.

Azure offers different ways to peer private networks. These are typically divided into two categories:

  • Hub-and-spoke peering: In this topology, there is a centralized hub VNet that other virtual networks peer with. This hub network has mechanisms to route traffic through transit routing. Cloud networks, including VPN/Express Connect connections with on-premises and other cloud networks, can communicate through the hub VNet.
  • Azure Virtual WAN (VWAN): Azure Virtual WAN is a networking service that provides simplified hub-and-spoke network modeling across Azure, on-premises, and other VPN/Direct Connect networks. For more about VWAN, refer to Microsoft’s Virtual WAN documentation.
  • Direct peering: Private networks are individually connected to one another with no routing hops between them. This is a simpler peering model: it is useful when you only want to connect a few networks.

Refer to Choose between virtual network peering and VPN gateways in the Microsoft Application architecture fundamentals guide to determine the correct peering approach for your organization.

4.1.1. Hub-and-spoke peering (Transit routes)
Copy link

The Hub-and-spoke peering model establishes a centralized hub VNet for managing private network communication and transit routing between your existing spoke networks and the dedicated Ansible Automation Platform VNet.

Note

Updating route tables incorrectly can break your network. Only execute the steps in these procedures if you are confident that you can reverse any unexpected network behavior.

4.1.1.1. Hub-and-spoke peering process overview
Copy link

Understand the necessary preparation and three core steps for enabling private network communication after deploying the managed application.

Prerequisites

  • You have deployed Ansible Automation Platform on Microsoft Azure.
  • You have configured and tested an Azure VNet hub-and-spoke implementation in your Azure tenant. This prerequisite requires many Azure resources to be configured, including a Virtual Network Gateway.
  • You have configured transit routing between your spoke networks, including your VPNs. Refer to Configure VPN gateway transit for virtual network peering in the Microsoft Azure documentation for instructions.

  • You have identified the following:

    • The CIDR blocks of your existing VNets (including VPNs and direct connects) that need access to Ansible Automation Platform on Microsoft Azure UIs.
    • The CIDR blocks of your existing VNets (including VPNs and direct connects) that contain hosts or endpoints for Ansible Automation Platform on Microsoft Azure.
    • The CIDR blocks of the Ansible Automation Platform on Microsoft Azure VNet from the managed resource group of the application. Refer to Finding the CIDR Block of the managed resource group for instructions.

Before peering any networks, ensure that there is no network address space overlap between your private VNets and your Ansible Automation Platform on Microsoft Azure network.

Procedure

  1. Find the CIDR Block for the Ansible Automation Platform on Microsoft Azure managed application Kubernetes cluster. See Finding the CIDR Block of the managed application Kubernetes cluster.
  2. Configure Network Peering with the Ansible Automation Platform Subnet. See Configuring Network Peering with the Ansible Automation Platform Subnet.

  3. Update the route tables:

    1. Configure route tables from your existing networks to send traffic to the managed application CIDR. You must add routes to the routing tables of every network requesting Ansible Automation Platform user interfaces and of every network that will have automation performed against its resources. See Routing to Ansible Automation Platform on Microsoft Azure.
    2. Configure routing to your VNets for each spoke network that you would like Ansible Automation Platform to communicate with, for automation or for accessing the user interfaces. See Routing to your VNets.

You can use the Resource Groups page to find the CIDR Block of the managed resource group.

Procedure

  1. Navigate to the Resource Groups page in the Azure portal.
  2. Click the managed resource group for Red Hat Ansible Automation Platform on Microsoft Azure. The resource group name is prefixed with “-mrg”.
  3. Select the VNet within the resource group to view its settings in the Overview page.

Verification

The CIDR block of the cluster is displayed in the Address Space.

Within the Azure console, the Azure virtual network (VNet) is known as this virtual network, and the VNet that you want to peer with is known as remote virtual network.

In the Virtual Networks page in the Azure portal, use the following settings to configure peering between the Azure VNet and the VNet that you want to peer with the Ansible Automation Platform on Microsoft Azure app:

Procedure

  1. Under Remote virtual network, select the settings for the virtual network that you want to peer with Azure:

    • Summary:

      • Peering link name: <aap_to_hub_peering_link_name>

      • Peering settings:

        • Traffic to remote virtual network: Allow
        • Traffic forwarded from remote virtual network: Allow

  2. Under Local virtual network, select Settings the Ansible Automation Platform on Microsoft Azure virtual network:

    • Summary:

      • Peering link name: <hub_to_aap_peering_link_name>

      • Peering settings:

        • Traffic to remote virtual network: Allow
        • Traffic forwarded from remote virtual network: Allow
        • Enable this virtual network to use peered VNet’s remote gateway or Route Sever: Enabled

4.1.1.4. Updating the route tables
Copy link

Route tables in the Azure portal are sets of rules, known as routes, that determine how network traffic is directed between subnets, virtual networks (VNets), on-premises networks, and the internet.

Procedure

  1. Before you update the route tables, confirm that you satisfy the Prerequisites for the hub-and-spoke peering process.

Use the Route Tables page in the Azure portal to route traffic to Ansible Automation Platform.

Procedure

  1. Navigate to Route Tables in the Azure portal.
  2. As part of your hub-and-spoke configuration, you created one or more route tables to define the routes between the networks. Click on one of these route tables.
  3. From the route table menu bar, click Routes > Add.

  4. Configure routes from your existing networks to send traffic to Ansible Automation Platform. You must configure routes for any network requesting Ansible Automation Platform user interfaces and for any network that will have automation performed against its resources. For each route that you add, enter the following information:

    • Route name: Enter a route name for the Ansible Automation Platform managed application network
    • Address Prefix: The CIDR block of the managed application kubernetes cluster
    • Next Hop Type: Virtual network gateway
  5. Click OK to save the new route to the route list.
  6. Repeat this procedure for all other route tables where you want to route traffic to Ansible Automation Platform.
4.1.1.4.2. Routing to your VNets
Copy link

Add a route for each spoke network that you would like Ansible Automation Platform to communicate with, for automation or for accessing the user interfaces.

Procedure

  1. Navigate to Route Tables in the Azure portal.

  2. In the list of route tables, select the route table for the Ansible Automation Platform on Microsoft Azure managed application.

    The name of the Ansible Automation Platform route table uses the following convention: 

    aks-agentpool-<numbers>-routetable
  3. From the route table menu bar, click Routes > Add.
  4. Configure routing to your VNets for each spoke network that you would like Ansible Automation Platform to communicate with, for both automation or accessing the user interfaces.

  5. For each route that you add, enter the following information:

    • Route name: Enter a route name for the spoke network that you want Ansible Automation Platform to route to
    • Address Prefix: The CIDR block of the spoke network
    • Next Hop Type: Virtual network gateway
  6. Click OK to save the new route to the route list.

Verification

After you have configured the routing rules, traffic is routed to and from Ansible Automation Platform on Azure through your hub network.

If your organization uses Azure firewall services or third-party firewall appliances through a Virtual Appliance connection, you must configure outbound connectivity from the managed application, to enable Red Hat to maintain your application and to enable automation against external resources.

The easiest way to implement this is to create a firewall rule that allows all outbound traffic from port 443.

If you choose not to allow all outbound traffic from port 443, you must configure routes.

Procedure

  1. For Red Hat to manage and upgrade Ansible Automation Platform on Microsoft Azure and execute security patching, any machine in the Azure Kubernetes service (AKS) cluster must be allowed to submit a request to pull updates for containers used by Ansible Automation Platform.

    1. Add routes in the Ansible Automation Platform route table for outbound traffic from the full CIDR range of the Ansible Automation Platform on Microsoft Azure managed application to the domains listed in the Azure Virtual Appliance Routing with Ansible Automation Platform on Azure article on the Red Hat Customer Portal.
  2. You must also allow traffic from your firewall to any other external domain or IP address that you want Ansible Automation Platform to run automation jobs against. Otherwise, your firewall blocks connectivity between Ansible Automation Platform and destinations for automation.
  3. Ansible Automation Platform requires a public DNS zone to provide SSL certificates. This public DNS zone is in the managed resource group of the deployment. The platform must be able to communicate via DNS queries with the servers listed in the DNS zone to complete certificate challenges with our upstream provider. Blocking this communication prevents successful certificate renewal.

Additional resources

4.1.2. Azure Virtual WAN (VWAN)
Copy link

Create a connection within the VWAN portal that links your selected VWAN hub to the Ansible Automation Platform’s managed application VNet.

Before peering, you must connect a hub network, and at least one spoke network, to the hub network of the Azure VWAN to which you intend to connect Ansible Automation Platform on Microsoft Azure.

Prerequisites

  • A pre-configured Azure VWAN.

  • One or more of the following connections to the VWAN:

    • A DMZ network that contains Azure virtual machines that users can remotely log into to access Ansible Automation Platform on Microsoft Azure.
    • A DMZ network that contains an Azure virtual machine that local machines can connect to with SSH tunneling to access Ansible Automation Platform on Microsoft Azure.
    • A VPN or Direct Connect service to your local network that routes traffic from local machines to Ansible Automation Platform on Microsoft Azure.

Procedure

  1. Navigate to the Virtual Network Connections page for the VWAN that you want to peer with your Ansible Automation Platform instance.

  2. To create a connection between the VWAN hub and your Ansible Automation Platform instance, use the following settings:

    • Connection Name: <Ansible_Automation_Platform_connection_name>
    • Hubs: Select one or more VWAN hub networks that the managed application VNet peers with.
    • Subscription: Select the subscription where Ansible Automation Platform on Microsoft Azure has been deployed.
    • Resource group: The managed resource group of the managed application. It is typically prefixed with “mrg-”.
    • Virtual network: The VNet of the managed application. There is only one VNet in the managed resource group.
    • Propagate to none: No
    • Associate Route Table: Select the default route table or the appropriate route table that your organization has configured for VWAN.
    • Propagate to Route Tables: Select one or more default route tables or the appropriate route table that your organization has configured for VWAN.
    • Propagate to labels: Select labels if your organization uses them.
    • Static routes: Do not complete this field.

Verification

When network peering completes, traffic routes to and from Ansible Automation Platform on Microsoft Azure though your VWAN hub network.

4.1.3. Direct peering
Copy link

You can use direct peering to directly connect virtual networks. When two networks are peered, Azure updates routes between them so that traffic automatically flows between them.

The direct peering method is easier to configure than the hub-and-spoke model. However, the number of direct network peerings is limited. Direct peering becomes difficult to manage as the number of virtual networks grows, because each new network requires peering to all other networks.

4.1.3.1. Configuring direct network peering
Copy link

You can configure network peering between your Azure network and your VNet in the Virtual Networks page of the Azure Portal.

Within the Azure console, the Azure virtual network is known as this virtual network, and the VNet that you want to peer with is known as remote virtual network.

In the Virtual Networks page in the Azure portal, use the following settings to configure the Azure network and the VNet that you want to peer with the Ansible Automation Platform on Microsoft Azure app:

Procedure

  1. Under Remote virtual network, select the settings for the virtual network that you want to peer with Azure:

    • Summary:

      • Peering link name: <aap_to_hub_peering_link_name>
      • Subscription: Select the subscription where you deployed the Ansible Automation Platform on Microsoft Azure.
      • Virtual network: Select the Ansible Automation Platform on Microsoft Azure virtual network: vnet-<aap_identifier>-<region>

    • Peering settings:

      • Traffic to remote virtual network: Allow
      • Traffic forwarded from remote virtual network: Allow
      • Virtual network gateway or Route Server: Use the remote virtual network’s gateway or Route server

  2. Under Local virtual network, select the settings the Ansible Automation Platform on Microsoft Azure virtual network:

    • Summary:

      • Peering link name: <hub_to_aap_peering_link_name>
      • Traffic to remote virtual network: Allow
      • Traffic forwarded from remote virtual network: Allow
      • Enable this virtual network to use peered VNet’s remote gateway or Route Sever: Enabled
  3. After you have configured direct network peering, traffic routes between Ansible Automation Platform on Microsoft Azure and private hosts and IPs on your VNet.

4.2. User defined routing tables
Copy link

You can create user defined routes from the VNet deployed with the managed application to internal network ranges, firewalls, virtual network appliances.

For information on how to configure user defined routes, see Ansible on Azure User Defined Routes.

4.3. Virtual appliance routing
Copy link

The managed application requires access to systems external to your subscription. You must take into account expected outbound traffic that the offering requires in order to be managed by Red Hat and Microsoft.

For information on domains that you must allow as a destination, see Azure Virtual Appliance Routing with Ansible Automation Platform on Azure.

4.4. Private DNS
Copy link

Ansible Automation Platform on Microsoft Azure uses Azure’s managed DNS services when deployed.

For information on how to use private DNS records that cannot be resolved publicly, see Private DNS with Red Hat Ansible Automation Platform on Microsoft Azure.

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 HatBack to top