Red Hat OpenShift Service on AWS (ROSA)

Red Hat OpenShift Service on AWS（ROSA）は、Red Hat の OpenShift プラットフォームを AWS 上でフルマネージドに利用できるサービスです。OpenShift は Kubernetes を基盤に、開発者向けのワークフローやセキュリティ機能、運用ツールを統合したエンタープライズ向けのコンテナプラットフォームで、ROSA ではそのクラスタの構築・運用・サポートを AWS と Red Hat が共同で引き受けます。

解決する課題

OpenShift は Kubernetes に開発者体験や運用機能を上乗せした強力なプラットフォームですが、自前で構築・運用する場合はコントロールプレーンの冗長化、定期的なバージョンアップ、証明書やオペレーターの管理など、専門知識を要する作業が継続的に発生します。さらに、利用にあたっては Red Hat のサブスクリプション契約と AWS のインフラ契約を別々に扱う必要があり、調達や請求が煩雑になりがちです。

ROSA はこれらを解消し、OpenShift クラスタをマネージドサービスとして提供します。クラスタの運用とサポートは AWS と Red Hat が共同で担い、利用者はアプリケーションの開発・運用に集中できます。請求は AWS のアカウントに統合されるため、OpenShift の利用料金を AWS の請求と一本化でき、調達のハードルも下がります。標準の OpenShift であるため、オンプレミスや他環境の OpenShift で培ったマニフェスト、オペレーター、CI/CD パイプラインをそのまま持ち込みやすい点も移行を後押しします。

主要概念と用語

• OpenShift: Kubernetes を基盤に、開発者向けの操作画面、ビルドやデプロイの仕組み、セキュリティ既定値、オペレーターなどを統合した Red Hat のコンテナプラットフォーム。
• クラスタ: OpenShift の論理単位。コントロールプレーンノードとワーカーノードで構成され、ROSA では AWS と Red Hat がマネージドに運用する。
• コントロールプレーン: API サーバーや etcd などクラスタの中核。ROSA では複数のアベイラビリティゾーンにまたがって冗長化される。
• ワーカーノード: 実際にコンテナを実行する EC2 ベースのノード群。利用者のワークロードが配置される。
• ROSA with HCP: コントロールプレーンを Red Hat 側のアカウントでホストする構成（ホステッドコントロールプレーン）。クラスタの起動が速く、コントロールプレーン分のコストを抑えやすい。
• Classic 構成: コントロールプレーンも利用者の AWS アカウント内に配置する従来型の構成。
• オペレーター: アプリケーションやコンポーネントのライフサイクルを Kubernetes 上で自動管理する仕組み。OpenShift のエコシステムで広く使われる。
• プロジェクト: OpenShift における名前空間に相当する分離単位。マルチテナント運用の基本になる。
• STS: AWS の一時的な認証情報を使ってクラスタに必要な権限を委譲する方式。長期的なアクセスキーを避けられる。
• rosa CLI: ROSA クラスタの作成や管理を行う専用のコマンドラインツール。

仕様・制限・クォータ

ROSA のコントロールプレーンは AWS が管理する形でマネージドに運用され、複数のアベイラビリティゾーンにまたがって冗長化されます。OpenShift のバージョンには定期的に新しいリリースが提供され、各バージョンにサポート期間が設けられているため、利用者は計画的にアップグレードする必要があります。構成としては、コントロールプレーンをホストする ROSA with HCP と、コントロールプレーンも自アカウントに置く Classic があり、起動速度やコスト構造が異なります。

1 クラスタあたりのノード数やワーカーの構成、リージョンあたりのクラスタ数などにはサービスクォータや EC2 側の上限が関係します。これらの上限や利用可能なリージョンは変動するため、設計時には必ず最新の公式ドキュメントとサービスクォータの画面で確認してください。クラスタを動かすには EC2、ロードバランサ、EBS などの周辺リソースも消費するため、それぞれのクォータにも余裕が必要です。

内部の仕組み

ROSA のクラスタは、コントロールプレーンとワーカーノードで構成されます。Classic 構成ではコントロールプレーンとワーカーの双方が利用者の AWS アカウント内の VPC に配置され、ROSA with HCP ではコントロールプレーンが Red Hat 側でホストされ、ワーカーノードのみが利用者の VPC に置かれます。いずれの構成でもコントロールプレーンは複数のアベイラビリティゾーンで冗長化され、API サーバーや etcd の運用は AWS と Red Hat が担います。

ワーカーノードは利用者の VPC 内の EC2 インスタンスとして起動し、OpenShift のスケジューラがポッドを各ノードに割り当てます。AWS リソースへのアクセス権限は STS による一時的な認証情報の委譲で構成され、長期的なアクセスキーをクラスタに保持させずに済みます。ネットワーク面では VPC のサブネットやセキュリティグループ、ロードバランサと統合され、外部公開のためのルーティングは OpenShift のルートやイングレスを通じて行われます。これにより、標準の OpenShift の操作感を保ちながら AWS のネットワーク制御と整合させられます。

設計パターン / ベストプラクティス

• 起動の速さやコントロールプレーン分のコスト最適化を重視するなら ROSA with HCP、コントロールプレーンも自アカウントで管理したい要件があるなら Classic、というように構成を要件で選ぶ。
• ワーカーノードを複数のアベイラビリティゾーンに分散し、ポッドのレプリカやトポロジ分散を活用して単一ゾーン障害の影響を抑える。
• クラスタへの権限委譲は STS ベースで構成し、長期的な認証情報をクラスタに持たせない。付与する権限は必要最小限に絞る。
• OpenShift のプロジェクト（名前空間）とロールベースアクセス制御でテナントやチームを分離し、リソースクォータで使い過ぎを防ぐ。
• オペレーターや CI/CD を活用し、アプリと付帯コンポーネントのデプロイとアップグレードを自動化・標準化する。

運用・監視

ROSA ではクラスタの可観測性として、OpenShift に組み込まれたモニタリングやログ収集の仕組みに加え、AWS のモニタリングサービスやログ集約サービスと連携できます。ノードやポッドのメトリクス、コントロールプレーンやアプリのログを収集し、ダッシュボードやアラートで状態を把握するのが基本です。クラスタの健全性やリソース使用状況を継続的に監視し、容量計画につなげます。

アップグレード運用では、コントロールプレーンを先に新バージョンへ更新し、その後ワーカーノードを順次入れ替える流れが一般的です。ノードの入れ替え時はポッドの退避と再スケジュールが発生するため、レプリカ数や PodDisruptionBudget を適切に設定して可用性を保ちます。ROSA はマネージドサービスとしてアップグレードの実行を支援しますが、タイミングや影響範囲の確認は利用者側の運用計画に組み込む必要があります。

コスト

ROSA のコストは大きく、OpenShift のサブスクリプション相当の料金と、クラスタを動かすための AWS インフラ料金で構成されます。サブスクリプション部分はワーカーノードの規模などに応じて課金され、AWS の請求に統合されます。インフラ部分は、ワーカーノードの EC2 料金、ロードバランサ、EBS などの関連リソース料金がかかります。Classic 構成ではコントロールプレーンのノード分も負担しますが、ROSA with HCP ではその構造が異なります。

コスト最適化の観点では、構成（HCP か Classic か）を要件に合わせて選ぶ、ワーカーノードに適切なインスタンスタイプを選定する、オートスケーリングで余剰ノードを減らす、開発環境を小規模に保つといった工夫が有効です。具体的な料金は変動するため、最新の料金ページとコスト試算ツールで確認してください。

セキュリティ

ROSA では責任共有モデルに従い、コントロールプレーンの基盤やマネージド部分は AWS と Red Hat が保護し、ワークロードやアプリの構成、OpenShift の認可設定は利用者が責任を持ちます。AWS リソースへの権限委譲は STS による一時認証情報で行い、長期キーを避けることが推奨されます。クラスタ内では OpenShift のロールベースアクセス制御とプロジェクト分離で権限を絞り、最小権限を徹底します。

ネットワークでは、クラスタを VPC 内に配置し、サブネットやセキュリティグループ、プライベートなエンドポイント構成で公開範囲を制御します。インターネットに公開しないプライベートクラスタとして構成することもできます。保管時・転送時の暗号化、コンテナイメージの脆弱性スキャン、信頼できるレジストリの利用、ノードやプラットフォームを最新に保つことも基本的なセキュリティ対策です。

関連サービス・比較

同じ AWS 上のマネージド Kubernetes 系サービスである Amazon EKS とよく比較されます。EKS はアップストリームの Kubernetes をそのまま提供するのに対し、ROSA は開発者ツールや運用機能を統合した OpenShift を提供し、Red Hat と AWS の共同サポートを受けられる点が特徴です。

ハンズオン / CLI例

以下は rosa CLI と AWS CLI を使い、利用環境の確認やクラスタの一覧を行う例です。実際のクラスタ作成前には前提条件の確認が必要です。

# AWS の認証情報が有効か確認
aws sts get-caller-identity

# ROSA を利用する前提条件を検証
rosa verify permissions
rosa verify quota --region ap-northeast-1

# 作成済みクラスタの一覧を表示
rosa list clusters

# 特定クラスタの詳細を確認
rosa describe cluster --cluster my-rosa-cluster