OpenShift Belongs in the Same Kubernetes Inventory as EKS and AKS
Most cloud governance tooling models a Kubernetes cluster by the API that created it, which covers 100% of EKS, GKE and AKS and 0% of Red Hat OpenShift Service on AWS. Call the AWS EKS API, get EKS clusters. Call the Azure API, get AKS. Call the GCP API, get GKE. That works until a team runs Red Hat OpenShift Service on AWS, at which point the model produces a confident, complete, wrong answer: the ROSA cluster is running in the account, it bills EC2 and EBS for all 24 hours of the day, and ListClusters does not return it. Kubernetes is the container orchestrator all four of these managed services package: a control plane that schedules workloads onto worker nodes and continuously reconciles live state back toward what was declared.
The failure is quiet. Nobody gets an error. Inventory reports a number, that number is short, and no part of the system knows it.
ZopDay now discovers ROSA clusters through OpenShift Cluster Manager and lists them on the infrastructure page next to EKS, GKE and AKS. Machine pools can be resized by hand, or handed to the cluster autoscaler with the limits it works within set per pool. The point of the change is not that a fourth cluster type is supported. It is that the fourth cluster type is supported in the same place, with the same controls, as the other three.
A ROSA Cluster Is Invisible to a Discovery Pass That Only Speaks EKS
ROSA runs on AWS, in your account, on your EC2 instances. It is not an EKS cluster. The control plane is operated by Red Hat, the cluster’s identity lives in OpenShift Cluster Manager, and the AWS control-plane APIs that enumerate managed Kubernetes have nothing to say about it. A discovery pass built on those APIs sees the worker EC2 instances as loose compute and never associates them with a cluster.
That association is what every downstream policy runs on. Instance sizing needs to know a node belongs to a pool with a scaling floor before it recommends a smaller instance type. Overnight scheduling needs to know a node is cluster capacity before it proposes stopping it at night. Cost attribution needs the cluster boundary to charge the workload to a team rather than to an unlabelled pile of instances.
The asymmetry matters more than it looks. An unsupported resource type in a report is a visible gap: the column is empty and somebody asks why. An undiscovered cluster is an invisible gap, because the report is full and internally consistent. It is simply describing a smaller estate than the one you have.
Machine Pools Are Node Groups With a Different Owner
OpenShift names worker capacity differently, which is most of why ROSA feels like a separate world. It is not. A machine pool is the unit that holds an instance type, a replica count and a set of scaling limits, in the same way an EKS managed node group or an AKS node pool does.
| Service | Worker capacity unit | Scaling limits set on | Control plane operated by |
|---|---|---|---|
| Amazon EKS | Managed node group | The node group | AWS |
| Google GKE | Node pool | The node pool | |
| Azure AKS | Node pool | The node pool | Microsoft |
| ROSA | Machine pool | The machine pool | Red Hat |
Once the vocabulary lines up, the two operations a platform team actually performs are the same across all four. Set the size directly, or set the range and let the autoscaler pick inside it. ZopDay exposes exactly those two: resize a machine pool by hand, or turn on the cluster autoscaler and set its minimum and maximum per pool.
Keeping the operations identical is a deliberate constraint, not a convenience. A platform team that has to remember which cluster type takes which action will eventually apply the wrong one, and the cluster where the mistake lands is the one they touch least often. That is nearly always the odd cluster out.
A Hosted Control Plane Moves the Autoscaler Config Out of Your Cluster
ROSA has two topologies, and they disagree about where the autoscaler’s configuration is stored. On a classic cluster, the control plane runs in the customer’s AWS account and the autoscaler is configured by a ClusterAutoscaler resource inside the cluster, which is where any OpenShift-native tool would look for it.
On a hosted control plane cluster, the control plane runs in a Red Hat owned AWS account. The customer account holds worker capacity and nothing else. There is no in-cluster ClusterAutoscaler resource to read, because the component that would own it is not running in your cluster. The configuration lives on the HostedCluster resource, reachable through the hypershift client.
ZopDay reads the hosted-cluster path through the hypershift client and surfaces minimum and maximum per node pool in the same drawer as a non-hosted cluster. The reader never learns which topology they are on, because for this operation it does not change what they are deciding. It changes which API answers.
This is the shape of the work in almost every managed Kubernetes integration: the operation is common, the storage location is vendor-specific, and the cost of getting it wrong is a control that silently reads stale values. A tool that guesses one location and falls back to the other on error will report an autoscaler as disabled whenever the fallback path itself fails, which is the wrong default in both directions.
Patch the Config That Exists, Never Write a Second One
The autoscaler service reads and patches the configuration already present. It does not create a new one. That single sentence in the release notes carries the whole safety argument.
An OpenShift cluster is operator-reconciled. Controllers inside it continuously drive live state back toward declared state. If an external service writes a fresh autoscaler configuration alongside the one the cluster already has, two writers now claim the same field, and the cluster behaves according to whichever wrote last. Scaling limits flap. The drawer shows one range, the cluster enforces another, and the disagreement surfaces as unexplained node churn hours later.
| Write strategy | On a cluster with no config | On an operator-reconciled cluster | Failure signature |
|---|---|---|---|
| Create a new configuration | Works | Two writers on the same field | Limits flap, node churn with no matching action in the audit trail |
| Read and patch the existing one | Nothing to patch, reports it plainly | Single writer, declared state preserved | Visible refusal instead of silent drift |
This works when the cluster already has an autoscaler configuration to read. It fails when it does not, because there is nothing to patch, and the service reports that rather than creating one. Read-and-patch trades one capability for one guarantee. It cannot bootstrap an autoscaler onto a cluster that has never had one configured, and it will say so rather than inventing a config. In exchange, it can never be the second writer in a fight it did not know it started. For a control that changes how many instances an account runs overnight, that is the correct side of the trade.
Inventory Parity Is the Precondition for Every Governance Action
Call the property this change is chasing inventory parity: a resource is governed only when it appears in the same list, described in the same vocabulary, and driven by the same controls as its peers. Parity is not the same as coverage. A tool can support ROSA in a separate integration, on a separate page, with its own terminology, and honestly claim coverage while delivering none of the parity that makes a policy applicable.
The test is mechanical. Ask whether a policy written without naming a cluster type applies to the new cluster. If instance sizing has to be taught what a machine pool is, parity failed. If the autoscaler drawer forks by control-plane topology, parity failed. If the cluster appears in inventory but the scheduling engine skips it, parity failed at exactly the point where it costs money.
ZopDay already imports existing EKS, GKE and AKS clusters and monitors live Kubernetes state across 21 resource pages, and ZopNight’s inventory spans 380+ resource types across the three major providers. Adding a fourth managed Kubernetes service to that surface is worth doing precisely because the surface already exists. The cluster becomes subject to the policies that were already written, on the day it is discovered, without anybody writing a ROSA-shaped exception.
That is the whole benefit, and it is worth being blunt about how narrow it sounds. Nothing here makes ROSA cheaper on its own. It makes ROSA eligible for the same work that made the rest of the estate cheaper.
