Red Hat OpenShift Service on AWS (ROSA) provides a model that allows Red Hat to deploy clusters into a customer’s existing Amazon Web Service (AWS) account.

Ensure that the following AWS prerequisites are met before installing ROSA with STS.

Deployment Prerequisites

To deploy Red Hat OpenShift Service on AWS (ROSA) into your existing Amazon Web Services (AWS) account, Red Hat requires that several prerequisites are met.

Red Hat recommends the usage of AWS Organizations to manage multiple AWS accounts. The AWS Organizations, managed by the customer, host multiple AWS accounts. There is a root account in the organization that all accounts will refer to in the account hierarchy.

It is a best practice for the ROSA cluster to be hosted in an AWS account within an AWS Organizational Unit. A Service Control Policy (SCP) is created and applied to the AWS Organizational Unit that manages what services the AWS sub-accounts are permitted to access. The SCP applies only to available permissions within a single AWS account for all AWS sub-accounts within the Organizational Unit. It is also possible to apply a SCP to a single AWS account. All other accounts in the customer’s AWS Organizations are managed in whatever manner the customer requires. Red Hat Site Reliability Engineers (SRE) will not have any control over SCPs within AWS Organizations.

Customer requirements when using STS for deployment

The following prerequisites must be complete before you deploy Red Hat OpenShift Service on AWS (ROSA) clusters using STS.


  • The customer ensures that the AWS limits are sufficient to support Red Hat OpenShift Service on AWS provisioned within the customer’s AWS account.

  • If SCP policies are applied and enforced, these policies must not be more restrictive than the roles and policies required by the cluster.

  • The customer’s AWS account should not be transferable to Red Hat.

  • The customer should not impose additional AWS usage restrictions beyond the defined roles and policies on Red Hat activities. Imposing restrictions will severely hinder Red Hat’s ability to respond to incidents.

  • The customer may deploy native AWS services within the same AWS account.

    Customers are encouraged, but not mandated, to deploy resources in a Virtual Private Cloud (VPC) separate from the VPC hosting Red Hat OpenShift Service on AWS and other Red Hat supported services.

Access requirements

  • Red Hat must have AWS console access to the customer-provided AWS account. This access is protected and managed by Red Hat.

  • The customer must not utilize the AWS account to elevate their permissions within the Red Hat OpenShift Service on AWS cluster.

  • Actions available in the rosa CLI utility or OpenShift Cluster Manager (OCM) console must not be directly performed in the customer’s AWS account.

Support requirements

  • Red Hat recommends that the customer have at least Business Support from AWS.

  • Red Hat may have permission from the customer to request AWS support on their behalf.

  • Red Hat may have permission from the customer to request AWS resource limit increases on the customer’s account.

  • Red Hat manages the restrictions, limitations, expectations, and defaults for all Red Hat OpenShift Service on AWS clusters in the same manner, unless otherwise specified in this requirements section.

Security requirements

  • Volume snapshots will remain within the customer’s AWS account and customer-specified region.

  • Red Hat must have ingress access to EC2 hosts and the API server from allow-listed IP addresses.

  • Red Hat must have egress allowed to the documented domains.

Red Hat managed IAM references for AWS

With the STS deployment model, Red Hat is no longer responsible for creating and managing Amazon Web Services (AWS) IAM policies, IAM users, or IAM roles.

Provisioned AWS Infrastructure

This is an overview of the provisioned Amazon Web Services (AWS) components on a deployed Red Hat OpenShift Service on AWS (ROSA) cluster. For a more detailed listing of all provisioned AWS components, see the OpenShift Container Platform documentation.

EC2 instances

AWS EC2 instances are required for deploying the control plane and data plane functions of ROSA in the AWS public cloud.

Instance types can vary for control plane and infrastructure nodes, depending on the worker node count.

  • Three m5.xlarge minimum (control plane nodes)

  • Two r5.xlarge minimum (infrastructure nodes)

  • Two m5.xlarge minimum but highly variable (worker nodes)

Elastic Block Storage storage

Amazon EBS block storage is used for both local node storage and persistent volume storage.

Volume requirements for each EC2 instance:

  • Control Plane Volume

    • Size: 350GB

    • Type: io1

    • Input/Output Operations Per Second: 1000

  • Infrastructure Volume

    • Size: 300GB

    • Type: gp2

    • Input/Output Operations Per Second: 100

  • Worker Volume

    • Size: 300GB

    • Type: gp2

    • Input/Output Operations Per Second: 100

Elastic load balancers

Up to two Network Elastic Load Balancers (ELBs) for API and up to two Classic ELBs for application router. For more information, see the ELB documentation for AWS.

S3 storage

The image registry and Elastic Block Store (EBS) volume snapshots are backed by AWS S3 storage. Pruning of resources is performed regularly to optimize S3 usage and cluster performance.

Two buckets are required with a typical size of 2TB each.


Customers should expect to see one VPC per cluster. Additionally, the VPC will need the following configurations:

  • Subnets: Two subnets for a cluster with a single availability zone, or six subnets for a cluster with multiple availability zones.

  • Router tables: One router table per private subnet, and one additional table per cluster.

  • Internet gateways: One Internet Gateway per cluster.

  • NAT gateways: One NAT Gateway per public subnet.

Security groups

AWS security groups provide security at the protocol and port access level; they are associated with EC2 instances and Elastic Load Balancers. Each security group contains a set of rules that filter traffic coming in and out of an EC2 instance. You must ensure the ports required for the OpenShift installation are open on your network and configured to allow access between hosts.

Group Type IP Protocol Port range























Additional resources