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

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.

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

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

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.

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 disaster recovery for the list of supported and backup regions.

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.

Learn about your responsibilities and Red Hat’s responsibilities. Understanding these roles helps you manage your product effectively.

The following optional configurations include custom domains and AWS PrivateLink setup. You can implement these settings to meet your specific security and networking requirements.

You can access the control plane through the Ansible Automation Platform user interfaces and APIs.

During the initial configuration of an Ansible Automation Platform Service on AWS deployment, you will 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.

If you need help accessing your deployment, submit a support request through Customer support.

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.

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:

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

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:

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.

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.

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.

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.

The platform is a managed service with robust built-in security, including RBAC and data encryption at rest and in transit (AES-256).

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.

All Ansible Automation Platform capabilities in the operator-based deployment model are supported.

Ansible Automation Platform control plane is accessible through its user interfaces, APIs, and mesh ingresses. While each service instance has an auto-generated Red Hat URL, you can set up a custom domain. This customization process varies based on whether you plan to use AWS PrivateLink or not.

To use custom domains, you must configure three DNS records according to your service’s connectivity model. These records will be explained in greater detail in the following sections. The conventions for these records are:

You can create custom subdomains under the domain you own.

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:

Understand the automation mesh architecture and the connectivity requirements for the execution plane

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.

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.

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.

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.