Are multiple ROSA clusters in a single VPC supported?

Solution Verified - Updated -

Environment

  • Red Hat OpenShift Service on AWS (ROSA classic architecture)
  • Red Hat OpenShift Service on AWS Hosted Control Planes (ROSA HCP)

Issue

  • Are multiple ROSA clusters in a same VPC supported?

Resolution

Short answer

Not supported — when the VPC was created by a ROSA classic or OSD or OCP installation (service-managed VPC). Adding another ROSA cluster (Classic or HCP) into that same service-managed VPC is not supported. Deleting the original cluster can also delete shared AWS resources (for example, load balancers), risking anything else you placed in that VPC. Red Hat Customer Portal

Supported (with design guardrails) — if you bring your own VPC (BYO-VPC) that you created and manage (i.e., not created by the ROSA/OSD installer). With BYO-VPC, you may collocate multiple clusters (ROSA classic, ROSA HCP, or OSD) if you plan for isolation, quotas, and strict ownership of shared resources. Red Hat Documentation

IMPORTANT: Do not install ROSA HCP into a VPC that was created by a ROSA classic/OSD/OCP installer. That configuration is unsupported and carries a high risk of accidental resource deletion or interference. If encountered, treat it as unsupported and open a support case for guidance or see Appendix below. Red Hat Customer Portal

What’s supported (and what’s not)

1) VPC created by a ROSA classic install (service-managed VPC)

  • Not supported: Any additional ROSA clusters (Classic or HCP) in that same service-managed VPC.

  • Why: Uninstalling the original cluster can delete the VPC and dependent resources the installer created (e.g., ELBs), causing collateral outage to other clusters. Red Hat Customer Portal

2) BYO-VPC (customer-created VPC)

  • Supported: Multiple clusters per VPC (Classic, HCP, OSD), with careful design:

    • Network isolation (non-overlapping CIDRs, SGs/NACLs)

    • Strict per-cluster subnets & tags to avoid controller/subnet collisions

    • Quota headroom (ENIs, IPs, ELB counts, NATs)

    • Clear tagging/ownership so deleting one cluster never touches another’s resources

    • Ingress/ELB correctness (subnet discovery tagging for ALB/NLB) Red Hat Documentation+1kubernetes-sigs.github.io

3) Shared VPC (AWS RAM across accounts) — quick note

  • Supported only for ROSA classic (STS) when versions meet prerequisites.
    See the ROSA classic “Shared VPC” guide for requirements, versions, and steps. Red Hat Documentation

  • Not supported for ROSA HCP at this time (except for private preview participants).

Design recommendations (BYO-VPC only)

  • Prefer one VPC per cluster for simplest, risk-free lifecycle boundaries.

  • If collocating, use dedicated subnets per cluster and unique discovery tags so the AWS Load Balancer Controller never adopts the wrong subnets. kubernetes-sigs.github.io

  • For ROSA HCP (which exposes the API via AWS PrivateLink), ensure endpoint SG rules and any peering/TGW paths are explicitly allowed. Red Hat Documentation AWS Documentation

References (authoritative documentation)

Appendix: “I already put multiple clusters in a ROSA-created VPC. What now?”

  1. Do not uninstall the original ROSA classic cluster in that VPC. Uninstalling can remove the VPC and shared resources created by the installer, breaking anything else living there. Red Hat Customer Portal

  2. Plan an exit to BYO-VPC (supported path):

  • Build a new, customer-managed VPC with the correct subnets, routes, and tags. (For ROSA HCP, confirm PrivateLink access rules.) Red Hat Documentation
  • Stand up a new cluster in that customer-managed VPC (Classic or HCP, as appropriate). Red Hat Documentation

  • Migrate workloads:

    • Recreate namespaces/quotas/roles, then redeploy apps and operators.

    • Recreate ingress and ELBs in the new VPC (don’t attempt to “share” them). Use proper subnet tags so controllers attach to the intended subnets. kubernetes-sigs.github.io

    • Migrate data (DB snapshots, S3 buckets, PVC backup/restore) using your DR tooling.

    • Update DNS (Route 53) and rotate any external secrets/credentials.

  1. After cutover, retire the unsupported placement. If decommissioning the original cluster, do it after everything else is gone from that VPC to minimize collateral deletion risk. Red Hat Customer Portal

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments