OpenShift on AWS: A Complete Guide to Red Hat OpenShift Service on AWS — Classic, HCP, and STS

Deploying production-grade Kubernetes with Red Hat OpenShift on AWS, the right way.

Whether you’re a platform engineer looking to modernize your infrastructure, a DevOps architect evaluating managed Kubernetes options, or simply someone curious about what ROSA (Red Hat OpenShift Service on AWS) has to offer. This article is for you.

We’ll break down everything you need to know about ROSA, its deployment models (Classic and Hosted Control Plane), how STS (Security Token Service) fits into the security picture, and how to automate all of it using the official Terraform Red Hat provider.

Grab your coffee ☕, let’s dive in.

🔍 What is ROSA?

Red Hat OpenShift Service on AWS (ROSA) is a fully managed OpenShift service, jointly supported by Red Hat and AWS. It allows you to deploy, manage, and scale OpenShift clusters directly within your AWS environment — without managing the complex lifecycle of the OpenShift platform yourself.

Key highlights:

• AWS-native integration: natively integrated with AWS services like IAM, VPC, ELB, EBS, S3, and more.
• Joint support: a single support experience from both Red Hat and AWS.
• Pay-as-you-go: billed directly through your AWS account.
• Full OpenShift experience: you get the full power of OpenShift (Operators, Developer Console, Pipelines, GitOps, Service Mesh, etc.).

ROSA is available in the AWS Marketplace and can be enabled directly from the AWS Console or via the rosa CLI.

🏗️ ROSA Deployment Models

ROSA currently comes in two deployment models, each designed with different operational philosophies in mind.

🟥 ROSA Classic

What is it?

ROSA Classic is the original deployment model for ROSA. In this model:

The Control Plane (API server, etcd, controllers) runs inside your AWS account.

The Worker Nodes also run in your AWS account.

Red Hat manages the lifecycle, patching, and operations of the control plane via a Site Reliability Engineering (SRE) team.

Architecture Overview

Key Characteristics:

• Multi-AZ by Default (Recommended) ROSA Classic supports deploying across 3 Availability Zones for high availability. The control plane nodes, infrastructure nodes, and worker nodes are spread across AZs.
• Machine Pools Worker nodes are managed through Machine Pools — a concept that allows you to define a group of nodes with specific instance types, sizes, labels, taints, and autoscaling policies.

# Create a machine pool
rosa create machinepool \
  --cluster=my-rosa-cluster \
  --name=gpu-workers \
  --instance-type=g4dn.xlarge \
  --replicas=2 \
  --labels="workload=gpu"

• Managed but Visible Unlike fully abstracted services, with ROSA Classic you can see the EC2 instances, networking resources, and EBS volumes in your AWS account. You have full visibility.

Add-Ons

ROSA Classic supports Red Hat Add-Ons managed services like:

• Red Hat OpenShift Data Foundation (ODF)
• Red Hat Advanced Cluster Security (RHACS)
• OpenShift API Management
• Cluster Logging (EFK stack)

When to Choose Classic?

✅ You need full visibility into your AWS infrastructure.

✅ You have compliance requirements that require the control plane to reside in your account.

✅ You’re already familiar with traditional OpenShift architectures.

✅ You need advanced networking customization (BYO VPC, custom DNS, etc.).

🚀 ROSA with Hosted Control Plane (HCP)

What is it?

ROSA with Hosted Control Plane (HCP) is the next-generation deployment model for ROSA and the direction Red Hat is strategically investing in. It’s inspired by the upstream HyperShift project.

In this model:

• The Control Plane runs in a Red Hat-managed AWS account, fully abstracted from you.
• The Worker Nodes (Data Plane) still run in your AWS account.
• The control plane is lightweight, decoupled, and shared infrastructure managed by Red Hat SRE.

Architecture Overview:

💡 Think of it this way: The control plane becomes just another hosted service you consume, similar to how you consume RDS or EKS managed control planes — you don’t see or manage the underlying servers.

Key Advantages of HCP

1. 🏎️ Faster Cluster Provisioning ROSA HCP clusters typically provision in under 10 minutes compared to 30–45 minutes for Classic. The control plane is pre-optimized and starts almost instantly.

2. 💰 Lower Cost Since the control plane doesn’t run on EC2 instances in your account, you save on compute costs. No master node EC2 instances to pay for.

3. 🔄 Decoupled Upgrades Control plane and data plane upgrades are fully decoupled. Red Hat can upgrade your control plane with zero impact on your workloads, and you can upgrade your worker nodes independently.

4. ⚡ Higher Density Red Hat can host multiple control planes efficiently, making HCP ideal for multi-cluster strategies and cluster-per-team patterns.

5. 🔒 Stronger Security Boundary Since the control plane is not in your account, the blast radius of a potential security incident in your AWS account doesn’t affect the control plane.

HCP Requirements:

ROSA HCP has a few specific requirements:

• STS is mandatory (more on this below).
• Requires AWS PrivateLink for private cluster configurations.
• Requires the OIDC provider configuration.
• A minimum of 2 worker nodes per hosted cluster.

# Create a ROSA HCP cluster
rosa create cluster \
  --hosted-cp \
  --cluster-name=my-hcp-cluster \
  --region=us-east-1 \
  --version=4.15.0 \
  --compute-machine-type=m5.xlarge \
  --replicas=3 \
  --sts

When to Choose HCP?

✅ You want faster provisioning and lower operational overhead.

✅ You’re building a multi-cluster platform (many clusters per team or environment).

✅ You want to reduce AWS costs by eliminating control plane EC2 costs.

✅ You’re comfortable with the control plane being abstracted away.

✅ You want faster, decoupled upgrades.

🔐 ROSA with STS (Security Token Service)

What is STS and Why Does it Matter?

AWS Security Token Service (STS) is an AWS web service that enables you to request temporary, limited-privilege credentials for AWS resources.

Traditionally, OpenShift (and ROSA Classic originally) used long-lived IAM User credentials stored as secrets inside the cluster. This was a security concern because:

• Long-lived credentials can be leaked or compromised.
• They’re harder to rotate.
• They grant broad permissions persistently.

ROSA with STS changes this by using short-lived, temporary credentials that are:

• Automatically rotated.
• Scoped with least-privilege permissions.
• Bound to specific workloads via OIDC (OpenID Connect).

IAM Roles for ROSA with STS

ROSA STS requires several pre-created IAM roles:

• Installer Role Used by the ROSA installer to create cluster infrastructure
• Control Plane Role Used by the control plane EC2 instances
• Worker Role Used by worker node EC2 instances
• Support Role Used by Red Hat SRE for support access
• Operator Roles Used by specific OpenShift operators (Ingress, Registry, etc.)

You can create these using the rosa CLI:

# Create account-level roles
rosa create account-roles \
  --mode auto \
  --prefix MyPrefix \
  --version 4.15

# Create OIDC provider
rosa create oidc-provider \
  --mode auto \
  --cluster my-cluster

# Create operator roles
rosa create operator-roles \
  --mode auto \
  --cluster my-cluster

STS Best Practices

🔑 Use auto mode during initial setup to let the CLI handle role creation.

🔑 Use custom prefixes to manage multiple ROSA clusters in the same account.

🔑 Regularly audit IAM roles and their policies using AWS IAM Access Analyzer.

🔑 Tag your roles for cost allocation and governance.

Let’s jump to application !!!!!!!!!!!!!!!!

🛠️ Getting Started with ROSA

Before you deploy your first ROSA cluster, make sure you have:

✅ An AWS Account with sufficient quotas.

✅ A Red Hat Account (free to create at console.redhat.com).

✅ ROSA enabled in your AWS account (via AWS Console or CLI).

✅ The rosa CLI installed.

✅ The aws CLI installed and configured.

✅ oc CLI (OpenShift CLI) installed.

# Login to ROSA
rosa login

# Verify AWS credentials
rosa verify permissions
rosa verify quota

# Enable ROSA service
rosa init

Quick Deploy — ROSA Classic with STS

# Step 1: Create account-level roles
rosa create account-roles --mode auto

# Step 2: Create the cluster
rosa create cluster \
  --cluster-name=my-classic-cluster \
  --sts \
  --region=us-east-1 \
  --version=4.15.0 \
  --multi-az \
  --compute-machine-type=m5.xlarge \
  --replicas=3

# Step 3: Create OIDC provider and operator roles
rosa create oidc-provider --cluster=my-classic-cluster --mode auto
rosa create operator-roles --cluster=my-classic-cluster --mode auto

# Step 4: Wait for the cluster to be ready
rosa describe cluster --cluster=my-classic-cluster

# Step 5: Create an admin user
rosa create admin --cluster=my-classic-cluster

🎯 Wrapping Up

Let’s summarize what we covered:

ROSA Classic: Full cluster in your AWS account, maximum visibility and control, STS highly recommended.

ROSA HCP: Hosted control plane managed by Red Hat, lower cost, faster provisioning, STS mandatory, the strategic future of ROSA.

STS: The secure, modern way to give ROSA components access to AWS services using short-lived credentials and OIDC, eliminating the need for long-lived IAM keys.

Whether you’re building a single production cluster or a fleet of clusters for different teams, ROSA gives you the power of OpenShift with the operational simplicity of a managed service — backed by the joint support of Red Hat and AWS.

The combination of ROSA HCP + STS is, in my opinion, the gold standard for deploying OpenShift on AWS today. It’s secure, cost-effective, fast, and fully automatable.

If you found this article helpful, consider giving it a clap 👏 and sharing it with your team. Got questions or feedback? Drop them in the comments below — I’d love to hear about your ROSA experiences!