AWS認定資格 WEB問題集＆徹底解説DevOpsエンジニア プロフェッショナル（DOP）

Red Hat OpenShift Service on AWS (ROSA) の概要と試験出題ポイントは？

AWSサービスの一つであるRed Hat OpenShift Service on AWS (ROSA)はどんな内容なのでしょうか？また、AWS認定資格のDevOpsエンジニア-プロフェッショナル(DOP)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか？
ここでは、そんなあなたの疑問に回答していきたいと思います

Red Hat OpenShift Service on AWS (ROSA) 徹底解説 | AWS認定試験の頻出ポイントまとめ

1. サービス概要

Red Hat OpenShift Service on AWS（ROSA）は、Red HatのエンタープライズKubernetesプラットフォームであるOpenShiftを、AWS上のマネージドサービスとして利用できるサービスです。 AWSとRed Hatが共同で提供・運用し、クラスターのインストール、保守、アップグレードはRed HatのSRE（サイト信頼性エンジニア）が24時間体制で担当します。Red Hatは99.95%の稼働率SLAを提供しています。

OpenShiftのAPI、Webコンソール、oc CLI、Operator、Route、Source-to-Image（S2I）ビルドなどがそのまま使えるため、オンプレミスのOpenShiftで動いているワークロードを、作り直しを最小限にしてAWSへ移せるのが最大の価値です。 サービスの有効化とソフトウェア契約の購入はAWSのROSAコンソールから行い、費用はAWSの請求にまとめられます。

DOP-C02の試験ガイドは対象サービスにROSAを掲載しています。Amazon EKSとの使い分け（OpenShift固有の資産・運用体制を維持したいかどうか）が判断の軸になります。

2. 主な特徴と機能

2.1 共同サポートとSREによる運用

  • クラスターの構築、パッチ、アップグレード、障害対応をRed HatのSREが担い、利用者の運用チームはアプリケーションに集中できる。
  • サポート窓口はAWSとRed Hatの両方から利用でき、両社が連携して対応する。
  • Kubernetesのコントロールプレーンは複数のアベイラビリティーゾーンにまたがって高可用性を確保する。

2.2 2つのアーキテクチャ: HCPとクラシック

  • ROSA with HCP（Hosted Control Planes）: コントロールプレーン（etcd、APIサーバー、OAuthなど）はRed Hatが所有するAWSアカウントでホストされ、ワーカーノードだけが利用者のアカウントに置かれる。ワーカーとコントロールプレーンはAWS PrivateLinkで通信する。最小2台のEC2から作成でき、作成が速く、インフラ費用も抑えやすい。コントロールプレーンとマシンプールを別々にアップグレードできる。新規構築で推奨される方式。
  • ROSA classic: コントロールプレーンもワーカーも利用者のアカウントとVPCに置かれる。専用のインフラノードを持ち、シングルAZで7台、マルチAZで9台のEC2が最小構成。クラスター全体を一度にアップグレードする。

2.3 OpenShiftの開発者体験をそのまま

開発者は従来どおりoc CLIやOpenShiftのWebコンソールを使い、Operator、OpenShift Pipelines、OpenShift Serverless、Service Meshなどのツールを利用できます。 マニフェストやCI/CDをEKS向けに書き換える必要がないため、移行時の手戻りと開発者の学習コストを抑えられます。

2.4 AWSサービスとの連携

  • アプリケーションからAmazon RDS、Amazon S3、Amazon DynamoDBなどのマネージドサービスを利用できる。
  • AWS Controllers for Kubernetes（ACK）を使えば、KubernetesのマニフェストからAWSリソースを作成・管理できる。
  • Elastic Load Balancing、EBS/EFSなどのストレージ、CloudWatchへのログ転送などと組み合わせられる。

3. アーキテクチャおよび技術要素

  1. AWSのROSAコンソールでROSAを有効化し、Red Hatのアカウントと連携する。
  2. クラスター用のVPCを用意する（HCPではAZごとにパブリック/プライベートサブネットを用意し、マルチAZなら3つのAZが必要）。
  3. rosa CLIで、アカウント単位のIAMロールとポリシー、OIDC設定、Operator用のIAMロールを作成する。
  4. rosa create clusterでクラスターを作成する。HCPでは利用者のVPCにワーカーノードが作られ、コントロールプレーンへはPrivateLinkで接続する。
  5. クラスター組み込みのOAuthサーバーにIDプロバイダー（GitHub、LDAP、OpenID Connectなど）を設定し、ユーザーに権限を付与する。
  6. 開発者はocやWebコンソールからアプリをデプロイし、AWSのマネージドサービスと連携させる。

4. セキュリティと認証・認可

  • AWS STSによる一時的な認証情報: ROSAはクラスターの構築や各Operatorの動作に、長期のアクセスキーではなくSTSの短期の認証情報を使う。アカウント単位のロール、Operator単位のロール、OIDCプロバイダーで権限を分ける。
  • IAMポリシー: HCPはAWS管理ポリシーを、クラシックはサービスが定義したカスタマー管理ポリシーを使う。rosa CLIのmanualモードでは、作成コマンドを出力して管理者がレビューしてから実行できる。
  • プライベートクラスター: APIとIngressをプライベートにしたクラスターを作れ、Direct ConnectやVPN経由の社内アクセスに限定できる。
  • ユーザー認証と権限: IDプロバイダーを設定し、cluster-adminやdedicated-adminなどの権限を必要な人にだけ付与する。HTPasswdは単一の管理者を作るための補助的な手段。
  • コンプライアンス: AWS GovCloudではFedRAMP HighやHIPAA適格の認定を受けている（HCP・クラシックとも）。
  • 監査: AWS側のAPI呼び出しはCloudTrailに記録される。

5. 料金形態

ROSAの費用は「ROSAのサービス料金」と「AWSインフラ料金」の2つで構成されます。

  • ワーカーノードのサービス料金: ワーカーノードが使う4 vCPUあたり1時間0.171 USD（オンデマンド）。全標準リージョンで同一。
  • HCPのクラスター料金: ROSA with HCPのクラスターには、上記に加えて1クラスターあたり1時間0.25 USDがかかる。
  • 契約による割引: ワーカーノードのサービス料金には1年・3年の契約があり、オンデマンドより33〜55%程度安くなる。
  • AWSインフラ料金: ワーカーノード、（クラシックでは）コントロールプレーンとインフラノードのEC2、EBS、ロードバランサー、データ転送などの料金。HCPはコントロールプレーンを利用者のアカウントに置かないため、この部分を抑えやすい。

6. よくあるアーキテクチャ・設計パターン

  • オンプレOpenShiftの移行: DeploymentConfig、Route、S2Iビルド、Operatorなどを多用するアプリを、マニフェストとCI/CDを作り直さずにROSAへ移す。クラスター運用はRed HatのSREに任せ、費用はAWSの請求へ統合する。
  • ハイブリッド運用: オンプレのOpenShiftとROSAで同じプラットフォームと運用手順をそろえ、ワークロードを段階的にクラウドへ寄せる。
  • 移行後のモダナイゼーション: ROSA上のアプリからRDSやS3などのマネージドサービスを使い、データベースの運用負担も減らす。
  • 閉域の業務システム: プライベートクラスターとDirect Connectで、社内ネットワークからだけ使えるOpenShift基盤を作る。

6.1 EKSとの使い分け

  • ROSAを選ぶ: OpenShift固有の資産（Route、S2I、Operator、oc前提の運用）を維持したい、OpenShiftのサブスクリプションとRed Hatのサポートを続けたい、クラスター運用をSREに任せたい。
  • EKSを選ぶ: OpenShiftへの依存がなく、アップストリーム互換のKubernetesとAWSネイティブの機能（EKS Auto Mode、Pod Identityなど）を使いたい。OpenShiftの資産がある場合、EKSへの移行はマニフェストやパイプラインの書き換えを伴う。
  • EC2上に自分でOpenShiftを構築する: 可能だが、インストール・アップグレード・障害対応を自社で抱えることになる。

7. 設定・デプロイ手順（ハンズオン例）

ROSA with HCPのクラスターをCLIで作成する流れです。

  1. ROSAコンソールでROSAを有効化し、前提条件（サービスクォータ、ELBのサービスリンクロールなど）を確認してRed Hatのアカウントと連携する。
  2. AWS CLI、rosa CLI、oc CLIを用意し、rosa loginでログインする。
  3. VPCとサブネットを用意する（ロードバランサー用のサブネットタグを付ける）。
  4. アカウント単位のロールを作る: rosa create account-roles --force-policy-creation
  5. OIDC設定を作る: rosa create oidc-config --mode=auto
  6. Operatorロールを作る: rosa create operator-roles --prefix PREFIX --oidc-config-id OIDC_ID --hosted-cp
  7. クラスターを作成する: rosa create cluster --cluster-name demo --sts --mode=auto --hosted-cp --operator-roles-prefix PREFIX --oidc-config-id OIDC_ID --subnet-ids SUBNET_IDS
  8. IDプロバイダーを設定し、管理者権限を付与する: rosa create idp --cluster=demo --interactive、rosa grant user cluster-admin --user=USER --cluster=demo
  9. コンソールのURLを確認してログインし（rosa describe cluster -c demo）、アプリをデプロイする。

8. 試験で問われやすいポイント

8.1 サービス選択

  • Q: オンプレミスのOpenShiftで動くアプリを、マニフェストや開発者の操作手順を変えずにAWSへ移し、クラスターの運用も自社で抱えたくない。
    A: ROSA。OpenShiftのAPIとツールをそのまま使え、クラスターの構築・保守・アップグレードはRed HatのSREが担う。
  • Q: 同じ要件でEKSを選ぶと何が問題になる？
    A: DeploymentConfig、Route、S2IなどOpenShift固有の資産をKubernetes標準やAWSのサービスへ書き換える必要があり、開発者の操作手順も変わる。
  • Q: EC2にOpenShiftを自分でインストールする案の欠点は？
    A: インストール、バージョンアップ、24時間の障害対応を自社の運用チームが抱え続ける。
  • Q: OpenShiftの費用をAWSの請求にまとめたい場合は？
    A: ROSAコンソールで有効化し、ソフトウェア契約もAWS経由で購入する。料金はAWSの請求に含まれる。

8.2 アーキテクチャ

  • Q: ROSA with HCPのコントロールプレーンはどこで動く？
    A: Red Hatが所有するAWSアカウント。利用者のアカウントにはワーカーノードだけが置かれ、PrivateLinkで接続する。
  • Q: HCPがクラシックより有利な点は？
    A: 作成が速く、必要なEC2が少ない（最小2台）ためインフラ費用を抑えやすい。コントロールプレーンとマシンプールを別々にアップグレードできる。

8.3 セキュリティ

  • Q: ROSAがAWSリソースを操作するときの認証方式は？
    A: AWS STSによる短期の認証情報。アカウント単位のロール、Operatorロール、OIDCプロバイダーを使う。
  • Q: IAMロールの作成内容を事前にセキュリティチームにレビューさせたい場合は？
    A: rosa CLIをmanualモードで実行し、出力されたコマンドをレビューしてから実行する。
  • Q: 社内からのみアクセスできるクラスターにするには？
    A: --privateでプライベートなAPI/Ingressのクラスターを作り、Direct ConnectやVPNで接続する。

8.4 料金

  • Q: ROSAの料金の構成要素は？
    A: ワーカーノードの4 vCPUあたりのサービス料金（HCPはさらにクラスターごとの時間料金）と、EC2などのAWSインフラ料金。
  • Q: 長期利用でサービス料金を下げるには？
    A: 1年または3年のROSA契約を購入する。
広告

お役立ち情報

姉妹サイト

AWS

Microsoft Azure

アンケート

サイト情報