ROSA : ce que change un OpenShift managé sur AWS

Cloud Day · Juin · Red Hat

Trente personnes réunies à Bercy, autour d’une question simple : à partir de quel moment cela n’a plus de sens d’exploiter soi-même son plan de contrôle Kubernetes ?

Le Cloud Day de juin y a répondu.

Kubernetes en entreprise : le point d’inflexion

Kubernetes n’est plus un pari technologique. Une large majorité d’organisations l’exploitent en production, et une part croissante font le choix d’un service managé plutôt que d’une plateforme auto-hébergée.

La bascule s’explique simplement : gérer Kubernetes en production, c’est une charge opérationnelle continue (upgrades, patching, monitoring, sécurité, scaling). Les études les plus citées évaluent à environ 40 % la part du temps d’ingénierie absorbée par ces opérations. Un service managé délègue le Day-1 et le Day-2 aux équipes SRE de l’éditeur.

ROSA HCP en pratique

ROSA (Red Hat OpenShift Service on AWS) repose désormais sur le modèle HCP (Hosted Control Plane). Ce qu’il faut en retenir :

• ✅ Aucun nœud master à gérer — le plan de contrôle est hébergé par Red Hat
• ✅ Des SRE Red Hat 24/7/365 sur les upgrades, le monitoring et les incidents
• ✅ Un SLA de 99,95 % en multi-AZ
• ✅ Une facturation AWS unifiée, intégrée au reste de la consommation cloud
• ✅ Le support d’AWS Graviton 3 et 4, avec des gains de coût substantiels face au x86
• ✅ Une intégration native avec STS, EBS, EFS, S3, CloudWatch, KMS et PrivateLink
• ✅ Un déploiement en une quinzaine de minutes

Le modèle Classic n’est plus proposé pour les nouveaux clusters depuis avril 2026 : HCP est la voie recommandée.

Installer un cluster ROSA HCP : les cinq étapes

1. Prérequis — activer ROSA dans AWS, installer les CLI rosa et aws, lier le compte OCM.
2. VPC & réseau — VPC multi-AZ, trois sous-réseaux privés, NAT Gateway et Internet Gateway.
3. IAM & OIDC — rôles STS à l’échelle du compte, configuration OIDC, rôles opérateur.
4. Création du cluster — rosa create cluster –hosted-cp –sts, environ quinze minutes.
5. Post-installation — fournisseur d’identité (Okta, Entra ID, LDAP), machine pools, ArgoCD et monitoring.

ROSA ou ARO ? Le comparatif

Les deux services partagent le même socle OpenShift 4.x, ce qui garantit une portabilité totale des applications. Les différences sont ailleurs :

Le choix se fait donc moins sur OpenShift lui-même que sur l’écosystème cloud dans lequel il s’inscrit.

L’angle FinOps

C’est le sujet qui a le plus animé la salle. Cinq leviers concrets :

• HCP supprime le coût des nœuds de plan de contrôle.
• Graviton 3/4 offre un rapport prix/performance nettement supérieur au x86.
• Savings Plans et Reserved Instances sur la base stable.
• Spot Instances pour les workloads tolérants à l’interruption.
• Kubecost / OpenCost pour le chargeback par namespace et le right-sizing.

Les cas d’usage qui reviennent chez nos clients

Modernisation applicative — conteneurisation progressive, CI/CD intégré.

FinOps cloud — Graviton, Kubecost, right-sizing.

Sécurité & conformité — clusters privés via PrivateLink, chiffrement KMS, Advanced Cluster Security.

Platform engineering — portail développeur self-service, golden paths, guardrails OPA/Kyverno.

Gouvernance multi-cloud — ACM pour piloter ROSA et l’on-premise, GitOps, reprise cross-cloud.

Consolidation de plateformes de virtualisation — OpenShift Virtualization sur bare metal AWS est disponible en GA, ouvrant des trajectoires de rationalisation pour les parcs de machines virtuelles existants.

Et chez Metanext ?

Nous accompagnons les équipes de l’audit initial à l’exploitation en production, en deux temps.

Phase 1 — Assess & Build : audit de l’existant, benchmark de coûts, design réseau et IAM, Terraform/Ansible, IdP et RBAC, observabilité et export des logs vers le SIEM.

Phase 2 — Migrate & Operate : stratégie Keep / Move / Modernize, migration des VM, GitOps (ArgoCD), gouvernance multi-cluster (ACM), FinOps, formation (DO280, DO380) et transfert de compétences pour une autonomie en trois à six mois.

Trois formats : Discovery (2 semaines, audit et Go/No-Go), Starter (4–6 semaines, un cluster, IaC complet, formation) et Enterprise (3–6 mois, multi-cluster, GitOps, migration, support continu).

Merci à Babacar Mbaye Faye (DevOps & Cloud Engineer @Metanext) & Alexia Ollagnon (Partner Manager @Red Hat) et aux trente participants réunis à Bercy.

Questions fréquentes

Quelle différence entre ROSA HCP et ROSA Classic ?

Avec ROSA HCP (Hosted Control Plane), le plan de contrôle Kubernetes est hébergé et exploité par Red Hat : plus de nœuds master à provisionner, gérer ou payer, et un cluster se crée en une quinzaine de minutes. Le modèle Classic déployait ce plan de contrôle dans votre propre compte AWS. Depuis avril 2026, Classic n’est plus proposé pour les nouveaux clusters : HCP est la voie recommandée.

ROSA ou ARO : comment choisir ?

Les deux services reposent sur le même socle OpenShift 4.x : vos applications sont totalement portables de l’un à l’autre. Le choix se joue sur l’écosystème cloud (AWS pour ROSA, Azure pour ARO), le modèle de plan de contrôle (HCP hébergé côté ROSA), l’identité native et le support ARM via Graviton, propre à ROSA. On aligne la décision sur le cloud où résident déjà vos données et vos équipes.

Combien coûte un cluster ROSA ?

ROSA apparaît sur la facture AWS unifiée : vous payez la consommation d’infrastructure (instances, stockage, réseau) plus les frais de service ROSA, sans coût de plan de contrôle en HCP. Le budget dépend surtout de la taille et du profil des workloads, et plusieurs leviers FinOps le réduisent : Graviton 3/4, Savings Plans, Spot Instances et right-sizing via Kubecost. Nous chiffrons un ordre de grandeur précis dès la phase d’audit.

ROSA permet-il d’exécuter des machines virtuelles ?

Oui. Grâce à OpenShift Virtualization (disponible en GA sur bare metal AWS), ROSA fait tourner des machines virtuelles aux côtés des conteneurs, sur une même plateforme. C’est un chemin de consolidation intéressant pour rationaliser un parc de VM existant sans le migrer d’un bloc.