Red Hat Ansible Automation Platform Service on AWS
Install and configure Red Hat Ansible Automation Platform Service on AWS
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.
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
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
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
- Log in to your AWS account.
- 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.
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.
- Click .
- Select your desired contract duration.
- If you would like your contract to auto renew, click .
- Select the contract options.
- Optional: Add a purchase order number.
- Click .
Click
. This redirects you to Red Hat Single Sign-On where you must:- Create or sign into your Red Hat account.
- 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.
Enter your AWS account ID and click
.- 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.
- After your AWS ID is validated click .
- Select your required region.
- Click .
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.
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
- An AWS Account
A Red Hat seller issues you a purchase order and provides it to you by email.
- For manual steps see Viewing and subscribing to a private offer page on the AWS Marketplace
Procedure
- Click the link in the private offer email to accept the terms.
- Log in to your AWS account.
- 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.
- Click the URL under the Offer ID column. This redirects you to the Offer Selection page.
- Click .
Click
. This redirects you to Red Hat Single Sign-On where you must:- Create or sign into your Red Hat account.
Connect your AWS account to the Red Hat account.
- If you are connecting to your accounts for the first time you must accept the terms and conditions and click Provision environment page on the Red Hat Hybrid Cloud Console. Here you can start configuring your environment. . This redirects you to the
Enter your AWS account ID and click
.- 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.
- After your AWS ID is validated click .
- Select your required region and click .
- Click .
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.
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.
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.
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
Feature | Red Hat | Customer |
---|---|---|
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.

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.
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.
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 Region | Business 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.
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.
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 help with configuring your automation mesh see Automation mesh for managed cloud or operator environments.
- 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.
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.
Chapter 7. Red Hat Ansible Automation Platform Service on AWS Private Link Connectivity
Private link connectivity is a networking feature commonly used in cloud environments. Private link connectivity allows services to communicate privately over a secure, internal network without exposing traffic to the public internet. On AWS, private link connectivity is known as AWS PrivateLink.
7.1. Key benefits of private link connectivity
- Enables the Ansible Automation Platform Service on AWS control plane to connect to project and execution environment repositories hosted on private networks that are inaccessible from the public internet.
- Keeps automation mesh data within a private network rather than traversing the public internet.
Automation mesh uses industry standard TLS encryption regardless of how automation mesh nodes are connected. Consider this traffic secured in the same manner as all TLS traffic.
7.2. How AWS PrivateLink works
AWS PrivateLink connectivity is supported both into (ingress) and out of (egress) the Ansible Automation Platform control plane. For more AWS specific information about how AWS PrivateLink works, see the Amazon Virtual Private Cloud documentation.
7.2.1. AWS PrivateLink connectivity into the Ansible Automation Platform control plane
For AWS PrivateLink connectivity into the control plane, an AWS Endpoint Service has automatically provisioned AWS PrivateLink connectivity into the control plane in your AWS environment. You must create an AWS Endpoint to connect to this service in your Virtual Private Cloud (VPC), and enable private DNS resolution of the endpoint service hostname. With this in place, any traffic originating from your VPC to the control plane API or mesh ingress connects to a private IP address and does not traverse the public internet. Traffic is stateful, so there is no need to open a private link in the reverse direction for responses to Transmission Control Protocol (TCP) requests that originate from the customer VPC
7.2.2. AWS PrivateLink connectivity out of the Ansible Automation Platform control plane
To enable AWS PrivateLink connectivity from the control plane to your private resources, create one or more Endpoint Services in your VPC and work with Red Hat to create the consuming Endpoints. With this in place, the Ansible Automation Platform control plane can connect privately to your resources such as registries, repositories, and execution nodes. Traffic is stateful, so there is no need to open a private link in the reverse direction for responses to Transmission Control Protocol (TCP) requests that originate from the control plane VPC.
7.3. Enabling AWS PrivateLink connectivity
To enable private link connectivity, submit a customer support ticket and the Red Hat team will assist you with next steps.
You must create two support tickets for bi-directional connectivity: one support case for enabling AWS PrivateLink connectivity into the control plane and another one for enabling AWS PrivateLink connectivity out of the control plane.
Procedure
Navigate to Customer support. The fields auto-fill, however confirm:
- The Account field displays your customer account
- The Owner field displays your login
- The Product field displays Red Hat Ansible Automation Platform On Clouds
- The Version field displays AWS - Managed Service
- Select Configuration for the What can we help you with? section.
- Click .
Use the values in the following templates to copy values into the Title and Describe your problem sections of the support request.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Title: Ansible Automation Platform Service on AWS PrivateLink Template Describe your problem: Enable AWS PrivateLink connectivity from control plane to customer's network Endpoint Service references are for the Endpoint Service created in the customer's VPC. Endpoint Service name: <enter here> Endpoint Service AWS region: <enter here> Endpoint Service ports or port ranges: <enter here> If you have multiple endpoint services, provide the values above for each endpoint service.
Title: Ansible Automation Platform Service on AWS PrivateLink Template Describe your problem: Enable AWS PrivateLink connectivity from control plane to customer's network Endpoint Service references are for the Endpoint Service created in the customer's VPC. Endpoint Service name: <enter here> Endpoint Service AWS region: <enter here> Endpoint Service ports or port ranges: <enter here> If you have multiple endpoint services, provide the values above for each endpoint service.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Title: Ansible Automation Platform Service on AWS PrivateLink Template Describe your problem: Enable AWS PrivateLink connectivity from customer's network to control plane Customer AWS account ID: <enter here> Endpoint AWS region(s): <enter here> URL of your AAP deployment: <enter here> The existing endpoint provided for the initial region (if a PrivateLink has already been configured): <enter here> If you want to setup PrivateLink for additional regions, you must send the above values for those regions. After Red Hat has configured the control plane Endpoint Service allowed principal and supported regions, a response will be added to your support ticket to create your Endpoint and share the Endpoint Service name, which you can find at https://console.redhat.com/ansible/service.
Title: Ansible Automation Platform Service on AWS PrivateLink Template Describe your problem: Enable AWS PrivateLink connectivity from customer's network to control plane Customer AWS account ID: <enter here> Endpoint AWS region(s): <enter here> URL of your AAP deployment: <enter here> The existing endpoint provided for the initial region (if a PrivateLink has already been configured): <enter here> If you want to setup PrivateLink for additional regions, you must send the above values for those regions. After Red Hat has configured the control plane Endpoint Service allowed principal and supported regions, a response will be added to your support ticket to create your Endpoint and share the Endpoint Service name, which you can find at https://console.redhat.com/ansible/service.
- Click .