Ansible Automation Platform Service on AWS Product Lifecycle and Upgrades
Note: This page will change as Red Hat Ansible Automation Platform Service on AWS is updated. Check back frequently and subscribe to changes for the latest information.
Version Lifecycle
Red Hat Ansible Automation Platform Service on AWS will employ a continuous release approach to versioning, meaning that customers' control plane will be upgraded to the latest version that Red Hat supports on a cadence that Red Hat defines. Red Hat Ansible Automation Platform Service on AWS cannot be locked to a specific version.
As a managed service, Red Hat will provide upgrades to the offering as per the cadence defined below in order to deliver modern application features, product fixes, and security updates.
| AAP Service on AWS Infrastructure | Ansible Automation Platform |
|---|---|
| Continuously Released outside of AAP version | Updated to maintain cadence with the most recently published version of Ansible Automation Platform |
Planned Upgrade Windows
Red Hat has defined windows in which upgrades will occur, and those windows may change over time in an effort to improve service offerings. Every effort will be taken to reduce or eliminate any downtime during these windows. However, these windows are provided to allow for system maintenance downtime should it be required.
In the cases where operations require more time than the planned window, then the operation time will have precedence over the defined window time. The "upgrade window" timeline is not synonymous with an expected outage timeline; it defines the time over which upgrades are planned to occur.
| Cadence | Expected Upgrade Window | Time | Purpose |
|---|---|---|---|
| Ad Hoc | N/A | As needed for security reasons | Critical CVE patches |
| Daily | 1 hour | 2 AM ET / 2AM UTC / 2AM JST | CVE patches (NA, EMEA and APAC times respectively) |
| Weekly | 2 hour | 2 AM ET Tuesdays | Ansible Automation Platform and infrastructure upgrades(North America Deployments). |
| Weekly | 2 hour | 2 AM UTC Tuesdays | Ansible Automation Platform and infrastructure upgrades(EMEA Deployments). |
| Weekly | 2 hour | 2 AM JST Tuesdays | Ansible Automation Platform and infrastructure upgrades(APAC Deployments). |
Note: These windows are only a guidance, and Red Hat reserves the ability to perform platform operations as needed to maintain the health of Ansible Automation Platform Service on AWS deployments.
Uptime Policy
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 are 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.
Scope of Coverage
Red Hat Ansible Automation Platform Service on AWS includes Red Hat Premium Support, which can be accessed by using the Red Hat Customer Portal.
See Red Hat Ansible Automation Platform Service on AWS Production Support Terms of Service for support response times.
Any Service level agreement (SLAs) for the service itself are defined in Appendix 4 (Online Subscription Services) of the This content is not included.Red Hat Enterprise Agreement Product Appendices.
AWS support is subject to a customer’s existing support contract with AWS.