@similarmetal Team Coffee

【実務目線】ROSA(Red Hat OpenShift on AWS)って結局どんなときに使うの? 〜触ってみた感想と世界的トレンドを調べてみた〜

Posted at 2026-06-24

TL;DR(先に結論)

ROSA = AWS上でフルマネージドに動く OpenShift。KubernetesにRed Hatの「全部入り」を被せて、運用(構築・更新・障害対応)をRed HatとAWSに委譲できるサービス。
「EKSの上位互換」ではなく、思想が違う。EKSは"素のKubernetes+自分で組む"、ROSAは"最初から組み上がっているエンタープライズ製品"。
向いているのは:すでにOpenShift資産がある/規制・コンプラ要件が重い/開発者に「Kubernetesの専門知識なしで」使わせたい組織。
向いていないのは:軽量なクラスタを安く回したい/コントロールプレーンまで自前で握りたい/とにかくAWSネイティブで最小構成にしたいケース。
2026年のトレンドは逆風もある。マネージドの安心感は健在だが、「ライセンス費が下手するとインフラ費を上回る(pricing inversion)」という議論が出てきている。
結論:ROSAは"運用を金で買う"プラットフォーム。人手が足りない・止められない・統制が要る、が揃ったときに効く。

ROSAとは(30秒で)

ROSA(Red Hat OpenShift Service on AWS)は、Red HatとAWSが共同で開発・運用しているマネージドOpenShiftです。ざっくり言うと:

中身はOpenShift(KubernetesにRed Hatの開発者・運用ツールを統合したエンタープライズ製品)
動く場所はAWS(ワーカーノードは自分のAWSアカウント/VPC内で動くのが基本)
面倒を見るのはRed HatのSRE + AWS(インストール・アップグレード・監視・障害対応)
請求はAWSから一本化されて届く。SLAは99.95%。

Kubernetesの「コントロールプレーンを自分で運用する地獄」から解放され、かつ素のk8sにはない「全部入り感」を得られる、というのが基本コンセプトです。

補足:現在の主流デプロイモデルは ROSA HCP(Hosted Control Plane)。コントロールプレーンをRed Hat管理のAWSアカウント側に持つことで、ユーザーはコントロールプレーン用ノードの管理・課金から解放される。最小2ノードから始められるので、小さく試すハードルも下がっている。旧来の ROSA Classic(コントロールプレーンも自分のアカウントに同居)は、リージョンや一部機能の対応状況で残る場面はあるものの、基本はHCPで足りるケースが多い。

そもそも、どんなケースで使うのか

実務とリサーチの両方から見て、ROSAが選ばれる典型パターンは大きく3つです。

1. すでにOpenShift資産がある

オンプレでOpenShiftを運用していて、クラウドへ持っていきたい組織。OpenShiftのRoute、Operator、SCC(Security Context Constraints)、oc CLIといったOpenShift固有の作法ごと移行できるので、アプリの作り直し(リファクタ)を最小化できる。「素のk8sに移すと作法が変わって辛い」部分を、そのまま運べるのが大きい。

2. 規制・コンプラ要件が重い

金融・医療・公共など、RBAC・監査ログ・マルチテナント分離がデフォルトで効いていることに価値がある領域。素のKubernetesだとセキュリティポリシーを自分で組み上げる必要があるが、OpenShiftは最初から「締まっている」。HIPAA/PCI DSS/SOC2系のフレームワークとも相性がいい。

3. 開発者にKubernetesを意識させたくない

プラットフォームチームが薄く、開発者全員を「Kubernetes職人」にする余裕がない組織。OpenShiftの開発者向けUI・ビルド/デプロイのワークフロー・内蔵CI/CD(Tekton)・OperatorHubがあることで、開発者はアプリのロジックに集中できる。「コードから本番まで、人に聞かずに到達できる速度」を買う、というイメージ。

逆に、ROSAを選ばない方がいいのはこのあたり:

軽量なk8sクラスタをとにかく安く回したい → 素のEKS(やもっと安い選択肢)
コントロールプレーンの設定までフルに握りたい → ROSAの管理範囲では制約に当たる
特殊なカーネルモジュール・特権的なノードカスタマイズが必要 → マネージドの制約に引っかかる
AWSネイティブで最小構成を組みたいだけ → OpenShiftの全部入りが過剰になる

実際に触ってみてどうだったか(具体は伏せます)

某案件で、複数のマイクロサービスで構成されるシステムをROSA上で動かし、CI/CDパイプライン(Tekton/ArgoCD系)を組んで運用に乗せる、という経験をしました。規模感や固有構成はぼかしますが、触ってみて素直に感じたことを残しておきます。

良かった点(体感)

「面倒を見てもらえる」安心感がガチで効く。クラスタのアップグレードやコントロールプレーンの健全性で夜中に叩き起こされない、という精神的負荷の軽さは数字に出ない価値。
GitOps(ArgoCD)との相性が良い。「宣言した状態に勝手に収束していく」運用は、人手の薄いチームほど恩恵が大きい。1人〜少人数で複数サービスを面倒見る前提だと、ここで救われる場面が多い。
開発者の認知負荷が下がる。OpenShiftの作法に乗ってしまえば、k8sの生YAMLと格闘する場面が減る。オンボーディングが楽。

しんどかった点(体感)

OpenShift独自の作法(SCC, Route等。DeploymentConfigは現在は非推奨)を覚えるコストは確実にある。「k8s知ってるからいける」と思うと、地味に違うところで詰まる。
コストが見えにくい。ROSAサービス料金 + AWSインフラ料金の二本立てで、油断すると「思ったより高い」になりやすい(後述のトレンドにも通じる話)。
小さく始めたつもりが小さくない。最小構成でもそれなりのベースラインが乗る。検証用に気軽に立てて放置、はやりづらい。

総括すると、「運用を金と引き換えに買う」プラットフォームだと割り切れるかどうかが満足度の分かれ目でした。割り切れる組織には刺さるし、割り切れない(=自分で握りたい/安く済ませたい)組織にはミスマッチになる。

アーキテクチャを考えるときの勘所

ROSAを採用する/しないを判断するときに、実務で効いてくる観点を整理します。

1. 「どこまでマネージドに預けるか」を最初に決める

ROSAの本質は責任分界点を上にずらすこと。コントロールプレーンの運用、ノードのパッチ、k8sのアップグレード——これらを「自分でやる価値があるか?」と問う。やる価値が無い(=コア事業じゃない)なら、ROSA(特にHCP)で預けてしまうのが筋。逆に、ノードやクラスタ構成をもっと自分で握りたいなら素のEKS(データプレーンの自由度が上がる)。コントロールプレーンまで完全に持ちたい場合は、そもそもマネージドではなく self-managed(自前k8s / self-managed OpenShift)の領域になる。

2. コスト構造を二層で見積もる

総コスト = ROSAサービス料金(ライセンス相当) + AWSインフラ料金(ワーカーノード, ストレージ, ネットワーク)。
ROSAサービス料金は概ね「4 vCPUあたり時間課金 or 年間コミット」で効いてくる。ここが見えていないと後で詰む。コミット(年間契約 / プライベートオファー)でかなり下げられるので、PoC→本番移行のタイミングで料金体系を切り替える前提で設計する。

3. ノード戦略でコストは大きく動く

ワーカーノードを Graviton(ARM) に寄せられるアーキテクチャなら、x86比で大きくコスト削減できる余地がある(条件次第で最大級の差)。ただしGravitonで下がるのはインフラ(EC2)側であって、ROSAサービス料金はvCPU課金なのでハードの効率化の恩恵を受けない。vCPUを増やす方向(高コア化)に振ると、その分ライセンス費が比例して跳ねる(=後述の"成功ペナルティ")。ノード選定はコンピュート性能だけでなくライセンス費とのバランスで考える。

4. GitOpsを前提に組む

ArgoCD/Tektonでの宣言的運用を最初から織り込む。少人数運用なら特に、「手で触る運用」を残すほど後で効いてくる。人手の薄さをGitOpsで補う設計にしておくと、ROSAのマネージド性と噛み合う。

5. ネットワーク/IAMの設計はAWS側の作法で

ワーカーノードは自分のVPCに居るので、ネットワーク分離・プライベート構成・STSによるIAM連携はAWSの設計として普通に考える必要がある。「OpenShiftだから」で済まない、AWSアーキテクチャの素養はそのまま要る。

メリット・デメリット整理

メリット

観点	内容
運用負荷	コントロールプレーン運用・アップグレード・障害対応をRed Hat SRE+AWSに委譲。99.95% SLA。
開発者体験	OpenShiftの開発者UI・内蔵CI/CD・OperatorHubで、k8s専門知識への依存を下げられる。
セキュリティ/統制	RBAC・SCC・監査がデフォルトで効く。規制業界と相性が良い。
移行性	オンプレOpenShift資産をリファクタ最小で持ち込める。ハイブリッド/マルチクラウドで一貫した体験。
課金	AWSから請求一本化。タグ連携でコスト追跡しやすい。
VM/AI対応	OpenShift VirtualizationでVMとコンテナを併存、OpenShift AIでAIワークロードも同居可能。

デメリット

観点	内容
コスト	ライセンス費+インフラ費の二層。高密度環境だとライセンス費がインフラ費を上回ることも(2026年の論点)。
学習コスト	OpenShift固有の作法(SCC, Route等)を覚える必要。素のk8s知識だけでは詰まる。
柔軟性	マネージドゆえコントロールプレーンの自由度に制約。特殊なノードカスタマイズは不可な場合がある。
ロックイン	Red Hatスタック(CoreOS, Quay, Ansible等)への依存。脱出時に再設計コストが発生しうる。
過剰性	軽量・最小構成だけが欲しい用途には「全部入り」が重い。

世界的な傾向(2026年時点で調べてみた)

ここは自分の体感だけだと偏るので、最新の論調を調べてみました。面白かったのは、「マネージドの良さ」と「重さへの揺り戻し」が同時に語られていること。

① エンタープライズ・規制業界では依然として強い

Red Hat/AWS/IBMの事例ベースだと、運用効率の改善・開発者時間の回収・開発サイクル短縮といった効果が繰り返し報告されている。特に「インフラ管理から解放されて、アプリ/ビジネスロジックに集中できた」という声が中心。金融・医療・公共・製造のIndustry 4.0など、コンプラと運用委譲の価値が高い領域での採用が続いている。

② VM・AIワークロードへの拡張

近年のアップデートで、OpenShift Virtualization(コンテナとVMを同居)やOpenShift AI(AIモデルのデプロイ)への対応が進んでいる。「コンテナ化しきれないレガシーVMも、modernizeの途中段階としてOpenShift上に乗せられる」という、移行の受け皿としての立ち位置が強化されている。2026年のRed Hat Summitでも、VMモダナイゼーションとAIワークロードのスケーリングが主要テーマに挙がっている。

③ そして"逆風"——pricing inversionと「成功ペナルティ」

一方で2026年は、批判的な論調も無視できないレベルで出てきている。曰く:

Pricing inversion:高密度環境では、OpenShiftのライセンス費が下層のコンピュート(ハードウェア)費を上回るケースが出てきている。
成功ペナルティ:ライセンスがvCPU/コア課金なので、vCPU総数を増やすほどライセンス費が比例して跳ねる。Gravitonへの置き換え(同vCPU)ではライセンスは変わらないが、高コア機への集約などで総vCPUが増えると、ノード数を増やしていなくても値上がりする——ハード効率の改善がライセンス削減につながらない、という逆説。
認知負荷:SCCやDeploymentConfigといった独自抽象が学習コスト・運用フリクションを生む、という指摘。
これらを背景に、「EKS/GKEの上に軽い開発者インターフェースを載せる」モジュラー志向への揺り戻しが一部で進んでいる。

VMware/Broadcomの大幅値上げ騒動以降、「all-in-oneの金色の檻(golden cage)」への警戒感が業界全体で高まっており、OpenShiftの深い統合も同種のロックインリスクとして見られ始めている、という論調もある。

④ EKS vs ROSA の住み分けは健在

調査ベースの整理だと、住み分けはおおむねこう:

EKS:AWSの知識が強く、ネットワーク/IAM/ストレージを自分で握りたいチーム向け。素のk8s体験、軽量、コスト透明性。
ROSA:AWSに全振りしつつ、Red Hatサポート付きのエンタープライズ・プラットフォームが欲しい組織向け。コンプラ要件やOpenShift資産があると特に効く。

「どっちが上」ではなく、何を自分で握りたいか/何を金で手放したいかの選択だ、というのが共通見解。

結論:ROSAってこんなんだよ

長くなったので、自分の言葉でまとめます。

ROSAは「運用と統制を、お金で買えるようにしたOpenShift」。

Kubernetesの運用地獄(コントロールプレーン・アップグレード・障害対応)を、Red HatとAWSに丸ごと委譲できる。
素のk8sにはないエンタープライズの全部入り(セキュリティ・監査・開発者ツール・CI/CD)が最初から効いている。
だから、人手が足りない × 止められない × 統制が要る、この3つが揃った組織には強烈に刺さる。
一方で、安く軽く回したい・自分で握りたいなら、素のEKS(やもっと身軽な選択肢)の方が幸せ。
そして2026年現在、「マネージドの安心感」と「ライセンス費の重さ」は天秤にかかっている。採用判断は機能比較ではなく、"何を手放して何を握るか"という経営判断に近い。

個人的な感想としては、「自分が運用を握ることに価値があるか?」を最初に問うのが一番大事だと思っています。握る価値がないものを律儀に握り続けるのが一番もったいない。ROSAは「そこ、手放していいよ」と言ってくれるサービスでした。

参考リンク

※本記事は一般公開情報と実務での所感をもとにした個人的なまとめです。料金体系・機能は変わるため、採用判断時は必ず公式ドキュメントで最新を確認してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up