Red Hat Ansible Automation Platform Service on AWS


Ansible on Clouds 2.x

Install and configure Red Hat Ansible Automation Platform Service on AWS

Red Hat Customer Content Services

Abstract

Ansible Automation Platform helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments. This guide helps you to understand the installation and use of Ansible Automation Platform Service on AWS. This document has been updated to include information for the latest release of Ansible Automation Platform Service on AWS.

Providing feedback on Red Hat documentation

If you have a suggestion to improve this documentation, or find an error, you can contact technical support at https://access.redhat.com to open a request.

Important

Disclaimer: Links contained in this document to external websites are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

Chapter 1. Introduction to Red Hat Ansible Automation Platform Service on AWS

With the Red Hat Ansible Automation Platform Service on AWS, you can purchase and deploy Ansible Automation Platform through AWS Marketplace. Red Hat configures and provisions an Ansible Automation Platform environment and then maintains it, ensuring reliability and security.

Chapter 2. Red Hat Ansible Automation Platform Service on AWS PULL and PUSH models

2.1. Automation using the Red Hat Ansible Automation Platform Service on AWS control plane

The Red Hat Ansible Automation Platform Service on AWS offers a deployment of Ansible Automation Platform deployment purchased through AWS Marketplace. Red Hat configures and provisions an Ansible Automation Platform. The Red Hat team handles the setup and maintenance of the Ansible Automation Platform, ensuring reliability and security.

While Red Hat manages the control plane, the execution plane is implemented in your network using automation mesh hop nodes and execution nodes. For help with configuring execution nodes see Automation mesh for managed cloud or operator environments.

There are two ways to configure the communication between control nodes and execution nodes:

  • The PULL connectivity model (recommended)
  • The PUSH connectivity model

2.2. PULL connectivity

Remote automation mesh nodes can access Ansible Automation Platform using a 'polling' or 'pull' model, which does not require opening ingress ports in your enterprise network. The pull model initiates a WebSocket from the remote execution node to the control plane hop node secured with mTLS for authentication and encryption. This model eliminates the need to deploy hop nodes into your demilitarized zone (DMZ) to establish connectivity to private networks if private networks have outbound internet connectivity. Proxy servers that terminate TLS are not supported and will disrupt automation mesh connectivity.

Figure 1 Pull model

Pull model

2.3. PUSH connectivity

You can design their automation mesh architecture using the push model and configure the communication ports. The default port is 27199. If you choose a different port ensure it does not conflict with an existing service, such as HTTPS. Ansible Automation Platform Service on AWS supports current automation mesh features that push communication to both hop nodes and execution nodes.

Figure 1 Push model

Push model

Chapter 3. Setting up Red Hat Ansible Automation Platform Service on AWS

To set up Red Hat Ansible Automation Platform Service on AWS you must first accept an offer. You can accept a public offer through the AWS marketplace, or a private offer directly from a Red Hat seller.

3.1. Accepting a Public offer

To set up Red Hat Ansible Automation Platform Service on AWS you must link your Amazon Web Services (AWS) and Red Hat accounts through the AWS marketplace. When you link your accounts you can provision and configure your cluster through the Red Hat Hybrid Cloud Console.

Prerequisites

  • An AWS Account

Procedure

  1. Log in to your AWS account.
  2. Navigate to the Discover products page of the AWS Marketplace. If you have already accepted your offer you can find it in the Manage subscriptions page.
  3. In the search field search for "Red Hat Ansible Automation Platform Service on AWS".

    • Depending on your region select one of the following:

      • For EMEA, select Red Hat Limited.
      • For the rest of the world, select Red Hat.
  4. Click View purchase options.
  5. Select your desired contract duration.
  6. If you would like your contract to auto renew, click auto renewal settings.
  7. Select the contract options.
  8. Optional: Add a purchase order number.
  9. Click Create contract.
  10. Click Click here to set up your account. This redirects you to Red Hat Single Sign-On where you must:

    1. Create or sign into your Red Hat account.
    2. Connect your AWS account to the Red Hat account. This redirects you to the Provision environment page on the Red Hat Hybrid Cloud Console. Here you can start configuring your environment.
  11. Enter your AWS account ID and click Verify.

    • This account ID must be the account ID that purchased the offer from the AWS Marketplace. The system does not recognize associated or nested accounts.
  12. After your AWS ID is validated click Next.
  13. Select your required region.
  14. Click Provision.

Verification

This redirects you to the Environment details page of the Instances, where you can see all the details of your created instance. Here you can check whether your instance is Ready or still in a Provision in progress state.

Provisioning your environment can take up to two hours. When it is ready, you will receive a confirmation email at the address linked to your account.

Important

Update your password as soon as possible. The confirmation email includes a link to your admin password, which you will use to log in and change your password. This link is one-time use, so be prepared before clicking it.

If you did not receive the email or the initial admin password has expired, you must to submit a support ticket and the Red Hat team will assist you with next steps.

3.2. Accepting a Private offer

A private offer is sent to you directly from a Red Hat seller. A private offer includes specific pricing and licensing terms for your account and has an expiration date. If you do not accept the offer by that date, you will either be moved to the public offer for the product or no longer subscribed to it.

Prerequisites

Procedure

  1. Click the link in the private offer email to accept the terms.
  2. Log in to your AWS account.
  3. Navigate to the Private Offers page of the AWS Marketplace. If you have already accepted your offer you can find it in the Manage subscriptions page.
  4. Click the URL under the Offer ID column. This redirects you to the Offer Selection page.
  5. Click Create contract.
  6. Click Click Set up your account. This redirects you to Red Hat Single Sign-On where you must:

    1. Create or sign into your Red Hat account.
    2. Connect your AWS account to the Red Hat account.

      1. If you are connecting to your accounts for the first time you must accept the terms and conditions and click Connect accounts. This redirects you to the Provision environment page on the Red Hat Hybrid Cloud Console. Here you can start configuring your environment.
  7. Enter your AWS account ID and click Verify.

    • This account ID must be the account ID that purchased the offer from the AWS marketplace. The system does not recognize associated or nested accounts.
  8. After your AWS ID is validated click Next.
  9. Select your required region and click Next.
  10. Click Provision.

Verification

This redirects you to the Environment details page of the Instances, where you can see all the details of your created instance. Here you can check whether your instance is Ready or still in a Provision in progress state.

Provisioning your environment can take up to two hours. When it is ready, you will receive a confirmation email at the address linked to your account.

Important

Update your password as soon as possible. The confirmation email includes a link to your admin password, which you will use to log in and change your password. This link is one-time use, so be prepared before clicking it.

If you did not receive the email or the initial admin password has expired, you must to submit a support ticket and the Red Hat team will assist you with next steps.

Chapter 4. Configuring Red Hat Ansible Automation Platform Service on AWS

After you subscribe to Ansible Automation Platform Service on AWS and gain access to Ansible Automation Platform, you must configure your automation mesh nodes and set up your automation jobs.

For help with configuring your automation mesh see Automation mesh for managed cloud or operator environments.

Warning

Do not change the "Gateway proxy URL" settings. Altering the gateway proxy might cause false outages on the status page.

Chapter 5. Red Hat Ansible Automation Platform Service on AWS Service Definition

5.1. Account management

This section provides an overview of the billing and environment management operations.

5.1.1. Billing

Red Hat Ansible Automation Platform Service on AWS is billed through Amazon Web Services (AWS). Pricing is based on the number of managed active nodes and related infrastructure management costs. Discount tiers are available for pre-purchasing managed active nodes at the start of a billing cycle.

The service includes one Ansible Automation Platform deployment and 10 Red Hat Enterprise Linux (RHEL) entitlements for running your automation execution plane.

5.1.2. Deployment-self-service

You can self-service deployments including, but not limited to, the following operations:

  • Buy and deploy an Ansible Automation Platform on AWS environment.
  • Cancel an Ansible Automation Platform on AWS environment subscription.

When you cancel or do not renew a subscription in the AWS Marketplace, the service begins the deprovisioning process 72 hours after the cancellation.

Important

The system keeps an encrypted backup for a limited time after unsubscription to prevent data loss from accidental unsubscription.

You may request a complete purge of the backup data after unsubscription, with the understanding that there is permanent data loss.

If you initiate a cancellation, your deployment will begin to shut down. If you initiated the cancellation in error you have 72 hours from the initial cancellation to submit a Support ticket and the Red Hat team will assist you in recovering the cancelled deployment.

5.1.3. Regions and availability zones

Each supported region is paired with a companion AWS region where backup data is stored in the event of a primary region catastrophe that requires restoration in another AWS region. Refer to Backup and diaster recovery for the list of supported and back up regions.

5.1.4. Service level agreement

Any service level agreements (SLAs) for the service itself are defined in Appendix 4 (Online Subscription Services) of the Red Hat Enterprise Agreement Product Appendices.

5.1.4.1. Limited support status

When a deployment transitions to "Limited Support" status, Red Hat will no longer troubleshoot execution plane issues. The SLA is no longer applicable and credits requested against the SLA are denied. However, this does not mean you lose all product support. A deployment can return to full support if you address the issues that caused the limited status.

A deployment might move to a Limited Support status for several reasons, including:

Lack of an execution plane
A customer execution plane is required for automation. If you have not configured one or if it’s in a degraded state, you must fix these issues before receiving automation support.
Unsupported Execution Plane Dependencies
Both Red Hat Enterprise Linux (RHEL) and OpenShift-based execution planes need regular maintenance and upgrades to meet minimum supported versions for Ansible Automation Platform dependencies. You can upgrade these resources using various methods, such as Ansible for patching, Red Hat Satellite, or DNF automatic updates. Keeping your OS, cluster, and receptor resources updated with supported Ansible Automation Platform helps reduce support issues.

5.1.5. Responsibilities

FeatureRed HatCustomer

Control plane infrastructure

Execution plane infrastructure

Control plane deployment

Control plane uptime

Control plane upgrades

Control plane backup and restore

Control plane security

Execution plane (automation mesh) deployment

Execution plane uptime

Execution plane upgrades

Execution plane backup and restore

Execution plane security

Settings and configuration

Automation content

Application integrations

Identity and access

5.2. Control plane

The Ansible Automation Platform control plane includes the application UIs, APIs, components, and services used for managing automation. Red Hat manages these within its own infrastructure.

Each customer deployment is fully isolated at the infrastructure layer. Every deployment provisions its own dedicated network, compute, and database resources, remaining entirely independent from all other customer environments. By enforcing this level of isolation, there is a reduce the risk of data leakage or unauthorized cross-deployment interactions, ensuring that actions and information remain confined within their designated environments.

A diagram depicting two customer deployments. Both deployments are identical

5.2.1. Customer access

Your access to the control plane is specific to the Ansible Automation Platform user interfaces and APIs.

During the initial configuration of an Ansible Automation Platform Service on AWS deployment, you receive the URL for your deployment. You can also find this information through the Red Hat Hybrid Cloud Console (HCC).

The administrator account’s initial password is provided to the HCC user who performed the initial deployment.

Important

Change this password immediately after your first login to Ansible Automation Platform.

If you need help accessing your deployment, submit a support request through the Red Hat Customer Portal.

5.2.2. Service uptime

Uptime for Red Hat Ansible Automation Platform Service on AWS is measured by user access and function of the Ansible Automation Platform control plane. This is measured through the uptime of the product web user interface and REST APIs. Measurements are calculated through successful HTTP response codes (200) to entry points of the UI and API. If either of these return an unsuccessful response code, or are unavailable and time out entirely, then the service will be considered to be in an outage state. Uptime of the execution plane, which is managed by customers, is not included as part of the uptime of the service. Customers are responsible for ensuring that the execution plane is redundant, scalable, and available in order to meet customer uptime objectives.

5.2.3. SRE access and management

Site Reliability Engineering (SRE) access is limited to the infrastructure and services running Ansible Automation Platform. Red Hat only accesses the Ansible Automation Platform interfaces or APIs in exceptional cases, such as during support engagements.

SRE access to control plane resources is restricted to operations that require human intervention and cannot be automated. Any access follows a request-and-approval process and is audited to ensure only authorized personnel can perform these operations.

SREs access resources and audit data are collected when:

  • The SRE team requests access to cluster resources using a tool that allows temporary access. This tool generates a log entry detailing the time and the SRE team member who requested access.
  • Audit logs are created for any management operation performed on a customer instance and are sent to a centralized logging system.
Important

Red Hat erases job logs every 30 days.

5.2.4. Backup and disaster recovery

Red Hat maintains daily database and file system snapshots in a separate region from each deployment.

Component

Snapshot Frequency

Retention Policy

Database

Daily

7 days

File System

Daily

7 days

This recovery data is used if an AWS regional outage cannot be resolved in a reasonable time.

Customer data is replicated to a predefined secondary region based on the deployment region. The currently paired regions are:

Primary RegionBusiness Continuity Region

us-east-1

us-west-2

us-east-2

us-west-2

us-west-2

us-east-1

eu-central-1

eu-central-2

eu-west-1

eu-north-1

eu-west-2

eu-west-1

ap-southeast-2

ap-south-1

ap-east-1

ap-south-1

ca-central-1

us-east-2

To recover an Ansible Automation Platform deployment in a different AWS region, a customer must submit a request specifying their preferred deployment region from the available options. Red Hat evaluates the request and begins building an instance in that region. Data from the previous instance is recovered from the customer’s business continuity region. The customer is responsible for any necessary post-deployment network configuration to integrate the new instance into their environment.

Note

Backup data is not directly accessible to customers. The data is only used in the event of infrastructure failure, not customer configuration errors. Red Hat encourages using configuration-as-code practices to maintain a customer-hosted backup of your configuration.

5.2.5. Infrastructure monitoring

Red Hat is responsible for monitoring the control plane. You do not have access to add any additional monitoring to the resources that run the control plane.

5.2.6. Application monitoring and customer audits

The Ansible Automation Platform activity stream provides detailed information about access to Ansible Automation Platform and usage. To retain this information for auditing or compliance, you must export the logs to supported logging services for retention and querying.

5.2.7. Status notification

Red Hat communicates the health and status of Red Hat Ansible Automation Platform Service on AWS clusters through the Red Hat Hybrid Cloud Console, email notifications to the original deployment contact, and any additional contacts you specify.

5.2.8. Security

5.2.8.1. Identity and access management

Ansible Automation Platform includes a built-in user model for configuring users and RBAC permissions that define access. Red Hat recommends using an enterprise identity provider with Ansible Automation Platform to implement multi-factor authentication for users. See the Access management and authentication guide for more information.

Note

Red Hat advises keeping at least one local administrator account with a long, complex password for emergency access.

5.2.8.2. Encryption

Data is encrypted at rest in both the database and file system using AWS KMS Service, which uses AES-256 encryption. Data in transit is encrypted with TLS 1.2 or higher.

We use AWS Customer Managed Keys (CMKs) to enforce encryption across databases, Amazon S3 buckets, and AWS Secrets Manager secrets. These KMS keys are securely stored in AWS Key Management Service (KMS) under Customer Managed Keys. KMS keys are automatically rotated every 365 days to reduce the risk of key compromise. The Amazon S3 bucket is used for automation hub configuration and backups. AWS Secrets Manager secrets is leveraged to store sensitive information such as credentials and configuration details.

5.2.9. Hosted components

The objective of this offering is to provide an Ansible Automation Platform deployment as a managed service, relieving customers of managing the Ansible Automation Platform control plane. Unless specified otherwise, all Ansible Automation Platform capabilities in the operator-based deployment model are supported.

Feature

Availability plans

Event-Driven Ansible

This service does not offer Event-Driven Ansible directly, but you can deploy a self-managed instance of Event-Driven Ansible that can be used with the service.

5.3. Execution plane

You can only run test and cleanup jobs on the default or controller execution planes. All other automation must be configured to run on your execution plane.

As part of the Ansible Automation Platform Service on AWS subscription, you receive 10 Red Hat Enterprise Linux (RHEL) entitlements for running the execution plane. Additional RHEL or OpenShift licenses can be purchased separately.

5.3.1. Shape

Your execution plane’s size and shape depend on the type of automation and the locations connected to the mesh. Use the following guidelines for your automation mesh implementation:

Ansible Automation Platform minimum requirements:

  • Hop Nodes: Red Hat Ansible Automation Platform Service on AWS includes two hop nodes that customers can use to peer with execution nodes. They typically require minimal resources. The shape of a hop node depends on the number of connected execution nodes. A virtual machine (VM) with 2 vCPUs and 2 GB RAM can route traffic for 2-4 execution nodes.

  • For automation in fewer locations (such as specific geographies or clouds), create a mesh with fewer VMs that can be scaled vertically. Most clouds and hypervisors allow shape changes with minimal downtime.
  • For CPU or RAM-intensive automation, use larger machine shapes.
  • For automation spanning multiple locations, create a mesh with nodes that connect to those locations.
  • Consider using different CPU architectures, like ARM, and reserved instances to reduce execution plane costs.
  • To configure redundancy in the automation mesh, set up at least two mesh nodes of the same shape in different availability zones within the same region, connecting each machine to both hosted hop nodes.
  • Use OpenShift if auto-scaling the execution plane is necessary.

5.3.2. Networking

5.3.2.1. Automation mesh

Ansible Automation Platform Service on AWS provides default “mesh-ingress” hop nodes. These hosted hop nodes allow execution nodes to poll for automation work through egress from a customer’s private network, eliminating the need to open inbound firewall ports. Hosted hop nodes use port 443 for inbound traffic.

The following is an example of an execution node in a private address space with egress-only internet access connected to Ansible Automation Platform Service on AWS through this model.

Execution node in a private address space

You can also configure the automation mesh with outbound connectivity from the control plane to your execution plane, allowing you to specify the ports used by the automation mesh.

You can use the Automation mesh for managed cloud or operator environments documentation for instructions.

5.3.2.2. Connectivity

The execution plane can communicate with the control plane under the following conditions:

  • Polling (mesh-ingress): Execution nodes must route stateful egress traffic to the Ansible Automation Platform deployment domain over port 443.
  • Push: A configurable firewall port must be open in the customer’s remote networks to allow Ansible Automation Platform to push information to execution nodes.

You can configure automation mesh nodes behind firewalls, proxy servers, and similar services. These services route or proxy traffic originating from Ansible Automation Platform without altering headers, payload, or other information that would affect functionality of the automation mesh.

You can restrict access to the control plane by providing CIDR blocks to the Red Hat support team through a Customer support request. This controls the inbound access to the control plane limiting it to the IP ranges you provide for traffic over the public internet. The application of these rules do not apply to traffic over PrivateLink. These restrictions do not affect outbound traffic that originates from the control plane.

5.3.3. Monitoring

You can configure monitoring and hardening tools of your choice on the execution plane. You are responsible for their operation, functionality, and maintenance, ensuring they do not interfere with the execution plane’s operation.

Any additional workloads on the execution plane requires extra resources from the virtual machines or OpenShift clusters where the tools are deployed. Make sure to size resources accordingly to accommodate these additional requirements.

5.3.4. DNS

Execution nodes use the DNS configuration of the host machine for DNS queries. Configure DNS using standard RHEL network practices to ensure proper lookups during automation execution.

5.3.5. Networking with overlapping CIDR blocks

Automation mesh connects the control plane to multiple networks that share the same Classless Inter-Domain Routing (CIDR) block (that is, the same class A address space repeated across different clouds or data centers). Execution nodes regard their deployment network as the local network. You must have at least one execution node instance paired with an instance group to target automation in each network.

5.3.6. Updates and maintenance

Automation mesh execution nodes are designed to minimize the need for patching the execution plane when the control plane is updated. However, future updates to the technology will require customer involvement to update the components in each execution plane node. When patches are needed, customers should follow the process for updating an automation mesh node. For help with updating your receptor see the Updating Receptors section of the Automation mesh for managed cloud or operator environments.

5.4. Support

Red Hat Ansible Automation Platform Service on AWS includes Red Hat Premium Support, accessible through the Red Hat Customer Portal.

For support response times, refer to the Production Support Terms of Service.

AWS support is subject to the customer’s existing support contract with AWS.

Chapter 6. Red Hat Ansible Automation Platform best practices

This section covers Ansible Automation Platform product use that has specific content or context for using Ansible Automation Platform as a service.

6.1. Configure automation to use instance groups

Red Hat Ansible Automation Platform Service on AWS requires that customers implement their own automation execution plane. Job templates must use a customer-configured instance or container group to run. If omitted, job runs can seem non-functional and eventually time out due to automation execution failure. Each job template must be assigned to a customer-configured instance group to function.

6.2. Syncing content with private automation hub

Private automation hub allows you to attempt to sync all content between automation hub or Ansible Galaxy. However, this synchronization fails due to the storage and resource demands of such a large task. When syncing content from external sources, limit the synchronization to the collections your organization plans to use, focusing on recent or known used versions to reduce the synchronization scope.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
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.