Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ROSA デザインパターン v1.2 (2026/10/09 更新)

ROSA デザインパターン v1.2 (2026/10/09 更新)

Red Hat が提供する AWS 上の OpenShift の Managed Service である ROSA (Red Hat OpenShift on AWS) の代表的なデザインパターンと、ネットワーク周りの設計で必要になる知識の解説を行っています。

※対象は ROSA HCP (Hosted Control Plane) のみで、一つ前のアーキテクチャーである ROSA Classic についてはカバーしていません。

Avatar for Yuhki Hanada

Yuhki Hanada

April 16, 2026

More Decks by Yuhki Hanada

Other Decks in Technology

Transcript

  1. はじめに ROSA (Red Hat OpenShift on AWS) の構築は、Red Hat の

    OpenShift のバリエーションの中でも最も簡単な製品だ と思います。 またデフォルトで AWS Managed の IAM Policy を使用し、セキュリティ的にも強固な OpenShift が簡単に構築でき るようになっています。 一方で、実際のプロダクション環境にデプロイする場合は、様々な要件が発生し、ROSA の知識だけではなく AWS の ネットワークの知識や、証明書の知識などの様々な知識を考慮した上で設計する必要があり、ITインフラのフルスタッ クに近いナレッジが求められます。 この資料では、これまでの提案活動なかで、質問に回答するために作った資料や、社内でテストされたネットワーク構 成などを、できるだけグラフィカルに理解しやすいように、書き起こしまとめたものです。 また、このドキュメントの中でも、複数箇所で参照していますが、私を含む弊社の Cloud Expert が手を動かして実験 したドキュメント群が以下のサイトで公開されています。思い付いたアーキテクチャーで、実現可能か知りたいものが ある場合は、以下のサイトで併せて検索していただく事をおすすめいたします。 Managed OpenShift Tutorials https://cloud.redhat.com/experts/
  2. Single ~ Multi AZ 構成 Single AZ 構成 2 AZ

    構成 Multi AZ 構成 ROSA Cluster ROSA Cluster ROSA Cluster AZ 1 AZ 1 AZ 2 いずれの構成でも可能ですが、最低 Node 本数は2本となります。 AZ 1 AZ 2 AZ 3
  3. ROSA Cluster インストール 基本Network Sample 構成 Public Cluster 用 Network

    Private Cluster 用 Network (Egress Lockdown) Private Cluster 用 Network Internet Gateway Internet Outbound [1] NAT Gateway S3 VPC Endpoint ECR DKR VPC Endpoint ROSA Cluster ROSA Cluster ROSA Cluster ECR API VPC Endpoint STC VPC Endpoint Internet 上の Registry からコンポーネントをダウ ンロードします。 [1] 2.12. Firewall prerequisites for Red Hat OpenShift Service on AWS AWS閉域網内の Registry からコンポーネントをダ ウンロードします。
  4. 接続要件概要 (ROSA Cluster 周辺) AWS Console OpenShift Console (GUI) は一般のアプリケーショ

    ンと同じ仕組みで、ROSA上にホストされている。 Red Hat Hybrid Cloud Console[1] ログイン ログイン インターネットアクセス Red Hat AWS Account User AWS Account AWSレベルの状況確認 ROSA VPC ROSA node 拡張 / Upgrade 操作 OpenShift Console (GUI) へのアクセス アプリ開発者 / 管理者 アプリ 使用者 AssumeRole ユーザー用 IAMRole インストール、ステータスチェック NLB A) Public (インターネット公開) or B) Private Private Link User Controlplane A) Public (Red Hat が Endpoint をホスト) or B) Private (VPC Endpoint) AZ 1 AZ 2 インストール/アップデート コンポーネント取得 AZ 3 A)インターネット上の Registry or B) AWS閉域網内 ECR (Red Hat がホスト。Red Hat 提供 コンポーネントのみ) ROSA Cluster OpenShift CLI へのアクセス (oc / kubectl CLI) [1] HCC と略されたり、もう少し正確に OCM(OpenShift Cluster Manager) と呼ばれる事もあります。OCMは HCC 内のOpenShift Cluster 全般を管理するアプリです。
  5. 接続要件概要 (管理用の CLI コマンド) CLI コマンド名 説明 アクセス先 oc kubectl

    に OpenShift の独自コマンドを追加したもの。 Private 構成 AWS VPC 内の ROSA HCP Controlplane VPC Endpoint Public 構成 インターネット上の Red Hat がホストする Controlplane Endpoint アップデート インターネット上の Red Hat Repository から取得 Private 構成 AWS VPC 内の ROSA HCP Controlplane VPC Endpoint Public構成 インターネット上の Red Hat がホストする Controlplane Endpoint アップデート インターネット上の Red Hat Repository から取得 Kubernetes / OpenShift でカバーしていないインフ ラ・レイヤーに近い部分の管理 Private 構成 インターネット上の OCM (OpenShift Cluster Manager) Endpoint 例: ・ROSA cluster のインストール / アンインストール ・OIDC provider の追加 ・machinepool (Nodeのプール) の設定変更 ・cluster の Upgrade アップデート インターネット上の Red Hat Repository から取得 AWS レベルでの 障害対応等のDay2運用 (ROSA としては必須ではない) Private 構成 インターネット上の 各 AWS Service Endpoint Public構成 AWS内の 各 AWS Service 用 Endpoint アップデート インターネット上の AWS Repository から取得 kubectl rosa aws oc コマンドで代換えできるため、通常は使用する必要 はない。 Public構成 ※この他にも Knative CLI [1]や Tekton 用の CLI [2]もありますが、要件依存でかつ、ROSA Cluster の運用に使用するものではないため省略しています。 [1] Chapter 4. Knative CLI for use with OpenShift Serverless [2] Chapter 5. Pipelines CLI (tkn)
  6. 接続要件概要 (管理用の GUI) CLI コマンド名 対応する GUI アクセス先 oc OpenShift

    Console ROSA 上のアプリケーションへのインターフェイスを提供している AWS NLB. rosa Red Hat Hybrid Cloud Console https://console.redhat.com/ aws AWS Management Console https://console.aws.amazon.com/
  7. Public Cluster kubectl / oc Developers / Admin users. Kubernetes

    API Server の Endpoint はインターネットに公開 Application users AWS Cloud Red Hat Managed Endpoint ROSA VPC Amazon Route 53 NLB VPC End Point Service NAT Gateway NAT Gateway NAT Gateway AZ 1 AZ 2 AZ 3 VPC End Point ・Public Cluster として作成した場合の構成。 • OpenShift (Kubernetes) API 用の エンドポイント カスタマーアプリケーション の両方が、インターネットに公開 された構成 Private Link User Controlplane • Internet Gateway
  8. ユーザーアプリケーションのみをインターネットに公開 User アプリケーション (OpenShift Console含む) の Endpoint は Public internet

    Application users AWS Cloud Red Hat AWS Account Internet Gateway Amazon Route 53 ROSA VPC Customer VPC NLB public subnet VPC End Point Service Private Link User Controlplane public subnet public subnet Transit Gateway VPC End Point NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする private subnet rosa kubectl / oc Developers / Admin users. Kubernetes API Server の Endpoint は VPC Endpint とし て作成され、インターネットに公 開されない。 AZ 1 AZ 2 ・Public Cluster として作成した後、OpenShift (Kubernetes) API 用の Endpoint を Privateに変更 AZ 3
  9. API Endpoint の Private / Public の切り替え HCC (Hybrid Cloud

    Console) から、作成後の構成の変更が可能 OpenShift (Kubernetes) API 用 の Endpoint インターネット公開 / 内部公開を 切り替えられる ユーザーアプリケーション用の Endpoint 10 インターネット公開 / 内部公開を 切り替えられる
  10. ユーザーアプリケーションのみをインターネットに公開 インターネット向け Endpoint インターネット向け Endpoint 切り替え AWS Cloud Internet Gateway

    Red Hat Managed Endpoint Amazon Route 53 ROSA VPC 切り替え NLB 内向き Endpoint Private Link User Controlplane VPC End Point Service public subnet public subnet public subnet NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 VPC End Point 内向き Endpoint kubectl / oc
  11. Private Cluster (Public Cluster として作成した後、全ての Endpoint を Privateに変更) User アプリケーション

    (OpenShift Console含む) の Endpoint は Private インストール時に Public Cluster として導入す る場合は、Public Subent / NAT Gateway は 必要 internet AWS Cloud Red Hat AWS Account Internet Gateway Amazon Route 53 ROSA VPC Customer VPC NLB public subnet VPC End Point Service Private Link User Controlplane public subnet public subnet Transit Gateway VPC End Point NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet 管理コマンドの内、rosa コマンドはインターネッ トアクセスを常に必要と する private subnet rosa kubectl / oc Kubernetes API Server の Endpoint は VPC Endpint とし て作成され、インターネットに 公開されない。 Developers / Admin users. AZ 1 AZ 2 AZ 3 ・テスト/ PoC目的では、Public Cluster としてインストールした方が使い勝手が良い。 ・後から Private に変更すれば、セキュリティを高めつつ、コンポーネントのアップーデートに必要なアウトバウンドのアクセス経路は維持される。 Application users
  12. Default Ingress Controller (NLB) + Second Ingress Controller (NLB) 例

    デフォルトの Ingress Controller は、 OpenShift Console と紐付いているため 、セキュリティのために外部非公開にす る 外部公開用のアプリ用 の追加 Ingress Contrlller (NLB) デフォルトの Ingress Controller (NLB) 内部専用にする internet Application users AWS Cloud Red Hat AWS Account Internet Gateway Amazon Route 53 ROSA VPC NLB(Default) public subnet VPC End Point Service Private Link User Controlplane public subnet Customer VPC NLB(Second) public subnet Transit Gateway VPC End Point NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする private subnet rosa kubectl / oc Kubernetes API Server の Endpoint は VPC Endpint として作成され、 インターネットに公開され ない。 Developers / Admin users. AZ 1 AZ 2 AZ 3 ・ユーザーアプリケーションとOpenShift Console (GUI) は、同じ NLB (Default)を共有する。 ・OpenShift Console が紐付いてる NLB(Default) は Private にしてセキュアにしつつ、ユーザーアプリケーションは、別の NLB(追加 IngressController) でインター ネットに公開する。
  13. ROSA Private Cluster インストール時に Private Cluster として導入する 場合は、Public Subent /

    NAT Gateway は必要な い。 Red Hat AWS Account internet への outbound は必要 (パッチ、バージョンアップなど) Customer AWS Account internet Internet Gateway Amazon Route 53 ROSA VPC Customer VPC NLB VPC End Point Service Private Link Transit Gateway VPC End Point Red Hat Managed System oc / kubectl rosa Pod Pod Pod Developers / Admin users. AZ 1 AZ 2 AZ 3 Application users ・初期状態から Private クラスターとしてインストールするので、ROSA VPC 内に Private Subnet が存在していない。 ・インストールやアップデート時のコンポーネントの取得のために、何らかのルートでインターネットアクセスを許可するか、Egress Lockdown構成を取る必用がある
  14. Egress Lockdown 構成 internet Private Cluster と Network 構成は同じだが、Red Hat

    が提供するコンポーネントについては、AWS 内部にある Red Hat が管理する Registry から提供するため Internet アクセスは必要無い。 AWS Cloud Amazon Route 53 ROSA VPC Red Hat Managed System Customer VPC NLB private subnet private subnet private subnet インストール用 / アップデート・コンポーネントの取得 Red Hat 提供のイメージの取得 Transit Gateway ROSA Private Cluster Private Link AZ 1 Amazon Elastic Container Registry (Amazon ECR) AZ 2 AZ 3 管理コマンドの内、rosa コマンドはインターネッ トアクセスを必要とする private subnet Day2: IDMS feature rosa kubectl / oc Developers / Admin users. Red Hat が提供するミラ ー・レジストリ ・OpenShift ・Operators by RedHat mirror-registry Operator Hub 上の 3rd Party Operator用の Registry Application users ・2025年2Qから新たに加わった機能。ROSAクラスタのインストール用/アップデート用イメージと、Operator Hub 上のRed Hat 提供 Operator はAWS内のECRから提 供される。 ・Operator Hub 上の 3rd Party の Operatorは、 mirror registry をユーザーが作成して対処する必要がある。
  15. Private Cluster AWS Cloud コンテナはインターネット上の Repository から取得するため 、インターネットのアウトバウンドが必要。 デバックや、この後の拡張しすさを考えて、AWS ではしばし

    ばこのようなネットワーク構成が推奨される。機能として分離 させる事が必須ではない。 Amazon Route 53 Egress VPC public subnet NAT Gateway Internet Gateway public subnet NAT Gateway ROSA VPC private subnet private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 ROSA Private Cluster TGW ENI private subnet TGW ENI TGW ENI TGW ENI Transit Gateway デフォルトでは、Install 用のパッケージや、アッ プデートなどを行うため、インターネットへのア クセスが必要になる。 ※ Install 時に Egress Lockdown オプションを使 うと、Red Hat 提供のパッケージについては、イ ンターネットへの直接アクセスは必要なくなる。 control plane NLB 2AZ構成を取っているのは AZ の 冗長化のため。 ・ROSAクラスタのインストール用/アップデート用イメージと、Operator Hub の提供イメージなどを、インターネット経由で取得する場合の構成 ・Inbound のトラフィックは許可する必用はない。 TGW ENI
  16. Private Cluster AWS Cloud Transit Gateway 用に専用に、小さなサブネット を作るのは、デバックなどを考えたベストプラク ティスとされる。(Network のトラフィックを流す

    ために必ず必要というわけではない) Amazon Route 53 Egress VPC public subnet NAT Gateway Internet Gateway public subnet NAT Gateway ROSA VPC transit gateway subnet control plane NLB private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 ROSA Private Cluster TGW ENI transit gateway subnet transit gateway subnet transit gateway subnet transit gateway subnet TGW ENI TGW ENI TGW ENI TGW ENI Transit Gateway https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html ROSA の VPC にtransit gateway 用に専用にサブネットを作成。Transit Gateway 専用のサブネットはデバッグなどを考えたベストプラクティスとされている 。
  17. Private Cluster AWS Cloud Amazon Route 53 Egress VPC public

    subnet AWS Firewall Endpoint ROSA VPC public subnet NAT Gateway transit gateway private subnet private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 ROSA Private Cluster TGW ENI transit gateway subnet Internet Gateway AWS Network Firewall control plane NLB transit gateway subnet transit gateway subnet Frewall Rule Sets TGW ENI AWS Firewall を使用して、Outbound アク セス先を限定する事ができる。 TGW ENI TGW ENI Transit Gateway AWSが組織で広く使用されている場合、この ような Firewall や Proxy が既に AWS環境内 に設置されている場合も多い。 Egress VPC の中に、OutBound のアクセス先を制御するために AWS Firewall を導入。必用なアクセス先はドキュメントに記載されている。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-sts-aws-prereqs#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs
  18. Cluster Wide Proxy を使った Outbound トラフィック制御 AWS Cloud HTTP Proxy

    を Outbound のトラフィック を制御するために設置。 Amazon Route 53 Whitelist で ROSA や 3rd Party Operator が必要とするアクセスだけを許可する。 Egress VPC public subnet NAT Gateway Internet Gateway public subnet NAT Gateway ROSA VPC private subnet transit gateway subnet private subnet private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 transit gateway subnet transit gateway subnet TGW ENI In this case, using two AZs for high availability control plane (Red Hat VPC) ROSA Private Cluster TGW ENI TGW ENI NLB TGW ENI TGW ENI Transit Gateway transit gateway subnet transit gateway subnet HTTP または HTTPS プロキシのアドレスを指定してく ださい。 HTTPS プロキシを使用する場合は、プロキシの CA 証 明書を ROSA の信頼バンドルに追加する必要がありま TGW ENI TGW ENI す。(透過型プロキシを使用する場合も、信頼バンドル への CA 証明書の追加が必要です。) Egress VPC の中に、OutBound のアクセス先を制御するために Proxy Server を導入。必用なアクセス先はドキュメントに記載されている。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-sts-aws-prereqs#rosa-hcp-firewall-prerequisites_rosa-sts-aws-prereqs
  19. Public Cluster 例 (AWS Security Reference Architecture に沿った構成) トラフィックを精査するための Firewall

    を置いた 専用の VPC インバウンド・トラフィック専用の VPC AWS Cloud Firewall / Inspection VPC Inbound VPC Internet Gateway AZ 1 GWLB Endpoint TGW ENI TGW ENI NLB AZ 2 TGW ENI AZ 1 Firewall equipment AZ 2 Gateway Load Balancer Akamai WAF TGW ENI Firewall equipment Amazon Route 53 GWLB Endpoint Transit Gateway アウトバウンドの出口専用の VPC ROSA VPC Outbound VPC AZ 1 AZ 1 Internet Gateway AZ 2 NAT Gateway NAT Gateway NLB (2nd IngressController) NLB AZ 2 AZ 3 TGW ENI TGW ENI TGW ENI AWS SRA https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/network.html TGW ENI TGW ENI control plane
  20. ROSA Outbound Traffic Requirement AWS firewall prerequisites デフォルト構成で Outbound で許可する必要があるドメインなどはドキュメントに記載があります。

    Outbound を Proxy や Firewall で絞るためには、このガイドに沿った宛先を許可する必要があります。 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/prepare_your_environment/rosa-hcpprereqs#rosa-hcp-firewall-prerequisites_rosa-hcp-prereqs • 2.9.1.1 Domains for installation packages and tools • 2.9.1.2 Domains for telemetry • 2.9.1.3 Domains for Amazon Web Services (AWS) APIs • 2.9.1.4 Domains for your workload • 2.9.1.5 Optional domains to enable third-party content • 2.9.1.6 Outbound firewall rules for the ROSA CLI for clusters with egress zero • 2.9.1.7 Outbound firewall rules from Red Hat Hybrid Cloud Console for clusters with egress zero 注: “Egress ロックダウン” と呼ばれる、ROSAを含む Red Hat 提供コンポーネントに関しては、AWS内の Red Hat Managed の ECR からダウンロード を行い、インターネットアクセス無しの Closed の環境を作成する方法もあります。
  21. ROSA の IngressController とは? • • OpenShift で用意されている HTTP(S)アプリをクラスター 外に公開する仕組み。

    ROSA HCPの場合は、kind: IngressController を作成する とNLB や Route Pod が作られる (ROSA 導入時に “default” という名前の IngressController が作成される) • IngressController は追加で作成する事ができる。 • Router Pod は、kind: Route を参照してトラフィックを適 切なアプリにルーティングする。 apiVersion: operator.openshift.io/v1 kind: IngressController metadata: annotations: Owner: cloud-ingress-operator ingress.operator.openshift.io/auto-delete-load-balancer: "" creationTimestamp: "2022-06-06T03:51:42Z" finalizers: - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller generation: 6 name: default namespace: openshift-ingress-operator resourceVersion: "584329" uid: ed99f19c-699b-42c9-b2f5-35b3d7785555 …. HTTP(S) インターネット 公開 or 内部のみ HTTP(S) NLB (default) [1] IngressController NAT Gateway NodePort ClusterIP HTTP App1 Pod HTTP App2 Pod Service ClusterIP Service ClusterIP Route Route Service LoadBalancer namespace namespace opensfhit-ingress [3] Router Pod [4]
  22. OpenShift Console と default の IngressController OpenShift Console インターネット 公開

    or 内部のみ HTTP(S) OpenShift Console へのアクセスも、 ユーザーのアプリも同じ NLBを通過 NLB (default) [1] ユーザーアプリ ユーザー・リクエスト (HOST header 値) ユーザー・リクエスト (Host Header値) (console-openshift-console.[ROSA domain]) (www.example.com) User取得ドメイン (www.example.com) IngressController CNAME ROSA 用 domain NAT Gateway (console-openshiftconsole.[ROSAdomain]) A Record ROSA 用 domain [userapp route名].[ROSAdomain] A Record NodePort OpenShift Console ユーザー APP Pod Service ClusterIP Service ClusterIP Route Route openshift-console user namespace 基本的にユーザーが変更して はいけないエリア ClusterIP [3] Router Pod [4] Service LoadBalancer opensfhit-ingress NLB IP (abc.region.amazon.aws.com) NLB IP (abc.region.amazon.aws.com) NLB Target NLB Target Router Pod Router Pod Route (console-openshift- Route (www.example.com) console.[ROSA domain]) OpenShnift Cosole Pod User Application Pod ROSA では、Route の変更を許可され ていないので OpenShift Console につ いては 独自ドメインは使用できない。 ユーザーアプリは、Route を自由に設 定できるので、独自ドメインが利用で きる
  23. CloudFront を使用した WAF 構成 WAF Amazon CloudFront AWS Cloud Internet

    Gateway ROSA導入時に自動作成される default IngressController の NLB OpenShift Console ドメインと 紐付いているので、セキュリテ ィのために、外部非公開にする 。 OpenShift Console の独自ドメ イン化は、2026年9月の ROSA CLI v1.2.65 から可能になって います[1] この部分はインターネット通信 (NLBはインターネットに Open) ROSA VPC 追加 IngressController を構成する NLB NLB public subnet public subnet NLB default の NLB と同じで ROSA(OpenShift) 上の複数のアプリケーシ ョンで共有が可能です。 public subnet ラベルを使って、default の IngressController と対象アプリを振り分 けます。 作成には独自ドメインが必要です。 NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 第5章 チュートリアル: AWS WAF と Amazon CloudFront を使用した Red Hat OpenShift Service on AWS ワークロードの保護 https://docs.redhat.com/ja/documentation/red_hat_openshift_service _on_aws/4/html-single/tutorials/index#cloud-experts-usingcloudfront-and-waf [1] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/web_console/index#customizing-web-console
  24. CloudFront を使用した WAF 構成 + Cloud Front VPC Origin Amazon

    CloudFront WAF AWS Cloud Internet Gateway この部分は AWS のネットワーク ROSA VPC 開発者 ROSA導入時に自動作成される default IngressController の NLB Outer NLB (Origin) 追加 IngressController を構成する NLB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にし ています。 OpenShift Console の独自ドメ イン化は、2026年9月の ROSA CLI v1.2.65 から可能になって います[1] VPC Origin を使用するためには、Security Group を持った NLB が必 要ですが、IngressController の NLB は、Security Group を持たず 、後から追加もできません。そのため、前段に通常の NLB をデプロイ し、CloudFront の VPC Origin にします。 NLB (default) private subnet private subnet Inner NLB private subnet default の IngressController の NLB と同じで ROSA(OpenShift) 上 の複数のアプリケーションで共有が可能です。 ラベルを使って、default の IngressController と対象アプリを振り分 けます。 作成には独自ドメインが必要です。 AZ 1 AZ 2 AZ 3 Using a Private IngressController with CloudFront on a ROSA Cluster https://cloud.redhat.com/experts/rosa/nlb-cf-vpco/ [1] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/web_console/index#customizing-web-console
  25. “AWS Load Balancer Operator (ALBO)” を使用した ALB(+WAF) 構成 アプリ・ユーザー AWS

    Cloud Internet Gateway ROSA導入時に自動作成される default IngressController の NLB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にし ています。 OpenShift Console の独自ドメ イン化は、2026年9月の ROSA CLI v1.2.65 から可能になって います[1] ROSA VPC 開発者 ALB NLB public subnet public subnet public subnet NAT Gateway NAT Gateway NAT Gateway private subnet private subnet private subnet App AZ 1 AZ 2 AZ 3 AWS WAF “AWS Load Balancer Operator” を使 用して ALB をデプロイします。 ALB一つにつき、ROSA (OpenShift) 上 のアプリケーションが一つだけ紐付きま す。ROSA の IngressController と違い 、アプリケーション間での共有はできま せん。 AWS Load Balancer Operator を使用する場合は、Application Pod 毎に専用の ALB がデプロイされます。 第6章 チュートリアル: AWS WAF と AWS ALB を使用した Red Hat OpenShift Service on AWS ワークロードの保護 https://docs.redhat.com/ja/documentation/red_hat_opens hift_service_on_aws/4/html/tutorials/cloud-experts-usingalb-and-waf [1] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/web_console/index#customizing-web-console
  26. Ingress Contrller を使用した NLB + ALB (WAF) 構成 アプリ・ユーザー AWS

    Cloud Internet Gateway ROSA導入時に自動作成される default IngressController の NLB ROSA VPC ユーザーが手動で作製する ALB 開発者 ALB OpenShift Console のドメイン と紐付いているので、セキュリ ティのために、外部非公開にす る。 AWS WAF 追加で Deploy 可能な IngressController の NLB default の NLB と同じで ROSA(OpenShift) 上の複数のアプリケーシ ョンで共有が可能です。 NLB OpenShift Console の独自ドメ イン化は、2026年9月の ROSA CLI v1.2.65 から可能になって います[1] NLB ラベルを使って、default の IngressController と対象アプリを選択し ます。 作成には独自ドメインが必要です。 private subnet private subnet private subnet AZ 1 AZ 2 AZ 3 ROSA 標準の IngressController を使うため、複数のアプリケーシ ョンで、ALB と NLB を共有する事ができます。 Adding a Private Ingress Controller and a Public ALB to a ROSA Cluster https://cloud.redhat.com/experts/rosa/private-ingress-controllerwith-alb/ [1] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/web_console/index#customizing-web-console
  27. HTTP / TCP (non HTTP) アプリケーションの外部公開 – ROSA 標準の構成 TCP(non

    HTTP) HTTP(S) TCP(non HTTP) ROSA 標準では、”Service” Type=LoadBalancer に対して、 CLB が生成されます。 Internet Gateway CLB [2] tcp 9000 tcp 9001 NLB (default) [1] CLB [2] ROSA 標準の IngressController NAT Gateway NodePort NodePort ClusterIP ClusterIP TCP App1 Pod Listen 9000 TCP App2 Pod Listen 9001 Service LoadBalancer Service LoadBalancer namespace namespace NodePort ClusterIP HTTP App1 Pod HTTP App2 Pod Service ClusterIP Service ClusterIP Route Route Service LoadBalancer namespace namespace opensfhit-ingress [3] Router Pod [4] [1] For HTTP(S) workload, the default NLB is shared among HTTP(S) applications. The incoming traffic is routed ro router pods whicht route the traffic to each pod based on HTTP host header. [2] CLB is deployed for each TCP(non HTTP) app. The CLB can’t be shared between different Pod applications. [3] With OpenShift, Router Pods posses pod ip addresses and use them to access Pods for better performance. [4] Two Router pods are deployed by default for redundancy
  28. “AWS Load Balancer Operator” を使った HTTP(S)アプリケーション AWS Load Balancer Operator

    を使 用して HTTPSアプリケーションをデ プロイした場合は、アプリケーショ ンに対して専用の ALB がデプロイさ れます。 HTTP(S) HTTP(S) HTTP(S) “Service” type=LoadBalancer に annotation が必用です。 ROSA 標準の NLB は、HTTP(S) ア プリケーション間で共用が可能です 。 Internet Gateway ALB NLB (default) ALB ROSA 標準の IngressController NAT Gateway NodePort NodePort ClusterIP ClusterIP HTTP App1 Pod HTTP App2 Pod Service NodePort Service NodePort Ingress Ingress Route Service LoadBalancer namespace namespace namespace opensfhit-ingress AWS Load Balancer Operator を使う事で、ALBを使用したユーザーアプリケーションの公開が可能 NodePort HTTP App Pod ClusterIP Service ClusterIP Router Pod ROSA 標準の IngressController を 使用した、HTTP(S) アプリケーショ ンは、Router Pod が Host ヘッダー を見て適切なアプリケーションにト ラフィックを ルーティングします。
  29. “AWS Load Balancer Operator” を使った TCPアプリケーション TCP アプリケーション用の NLB は、アプリケーション毎に専用

    の NLB が使用されます。 TCP(non HTTP) TCP(non HTTP) TCP アプリケーション用の NLB は、アプリケーション毎に専用 の NLB が使用されます。 HTTP(S) ROSA default IngressController の NLB は、 HTTP(S)アプリケーション間で共用されます。 Internet Gateway NLB [2] tcp 9000 tcp 9001 NLB (default) [1] NLB [2] ROSA 標準の IngressController Router Pod が、Route の情報を元に トラフィックをルーティングします。 NAT Gateway NodePort NodePort ClusterIP ClusterIP TCP App1 Pod Listen 9000 TCP App2 Pod Listen 9001 Service LoadBalancer Service LoadBalancer namespace namespace NodePort ClusterIP HTTP App1 Pod HTTP App2 Pod Service ClusterIP Service ClusterIP Route Route Service LoadBalancer namespace namespace opensfhit-ingress [3] Router Pod [4] [1] HTTP(S) のアプリケーションには、default NLB が共通で使用されます。外部からのトラフィックは、router pod に送られ、HTTP Host ヘッダーを元に各アプリケーションにルートされます。 [2] TCP アプリケーション( 非HTTP) には、NLBがデプロイされます。一つの TCPアプリケーションに対して、一つのNLB がデプロイされます。アプリ間での共用はできません。 [3] OpenShift では、標準的な Kubernetes とは違い、Service 経由せずに直接 Pod のIPへトラフィックをルートします。これによって Peformace が向上すると言われています。 [4] Router Pod はデフォルトでは2つデプロイされています。
  30. ネットワークは管理者が集中管理する(Shared VPC subnet ) Network Resource の管理を、ROSA Cluster 作成用の AWS

    Account には渡さず、特定の AWS Account で一括管理したい 時に使用される構成です。 AWS organization ROSA Cluster の Zone を作成 Route53 User AWS Account-A (Owner) User AWS Account-B (Participant) AWS Managed Policy Resource Access Manager ROSASharedVPCEndpointPolicy ROSASharedVPCRoute53Policy Resource Access Manager を使用して public network / private network を AWS Account B と共有 AWS Managed Policy ROSA…..Policy ROSA…Policy ROSA…Policy ROSA Cluster Worker Nodes private subnet rosa create dns-domain rosa create oidc-config rosa create account-roles rosa create operator-roles rosa create cluster Route53 Role VPC Endpoint VPC End Point Role Networkリソース は、Account A の AWS アカウ ントで、集中的に管理されます。 Installer Role Ingress Operator Cloud Credential Role Assume Role Network 関連の AWS Roles (AWS Account B の Role から AssumeRole を許可) ControlPlane Operator Cloud Credential Role ROSA Cluster 作成関連の AWS Roles https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_rosa_with_hcp_clusters/rosa-hcp-shared-vpc-config
  31. 基盤チームとCluster使用者で VPC分割する例 基盤チームは、Cluster の作成を、使用者の AWS Account に対して行う。クラスター作製後も、運用サポートとして ROSA Cluster の

    API にアクセスできるようにしておきたい。 ROSA Service Account ( Red Hat SRE Managed ) Red Hat SRE 管理 AWS Account (ユーザーからは不可視) Cluster使用者 VPC (AWS Account –A) ROSA Cluster A Hosted Controlplane VPC Service Endpoint AWS PrivateLink User AWS Account-A cluster 使用者は基本 的に、自力で運用を 行うが、必用に応じ て基盤チームのサポ ートを使用する。 User AWS Account-B VPC Endpoint private subnet EC2 bastion A クラスターを管理 private subnet ROSA Cluster A Worker Nodes 基盤チーム VPC (AWS Account –B) VPC Endpoint サポート用の踏み台 (oc コマンドの実行) private subnet Cluster の作成など は、AssumeRole にて行い、クラスタ ーを払い出す EC2 bastion B https://docs.redhat.com/ja/documentation/red_hat_openshift_service_on_aws/4/html/install_rosa_with_hcp_clusters/rosa-additional-principals-overview_rosa-hcp-aws-private-creating-cluster
  32. 別の AWS Account から oc コマンドでクラスターを監視する例 監視製品が、oc コマンドを使用して Cluster を監視している。

    oc コマンドは、監視サーバー上で実行され、かつ ROSA Cluster とは別の AWS Account に存在する。 Controlplane には、 PrivateLink 経由で アクセスできる ROSA Classic Account Red Hat SRE AWS Accont VPC Service Endpoint VPC Service Endpoint private subnet User Controlplane 運用 AWS Account PrivateLink private subnet oc command で Cluster 監視 VPC Endpoint private subnet SRE 監視サーバー Red Hat SRE 管理 AWS Account ( ユーザーからは不可視) ROSA Classic Cluster EC2
  33. プライベート・クラスター 疑似テスト環境例 AWS Cloud ROSA Cluster インストール用VPC 疑似オンプレ環境 Bastion VPC

    ROSA VPC Browser public subnet ROSA controlplane STS endpoint 作業者 Internet Amazon Route 53 private subnet ECR API Endpoint (SSH portforward) ssh NLB (Internal) ssh terminal transit gateway subnet Internet Gateway Bastion Server ROSA Cluster NAT Gateway Transit Gateway Private Cluster を作成し、テストしたい場合、プライベート・クラスターにアクセスするためのルートが必用になる。 踏み台サーバーを作成して、ssh の prtoforwarding で踏み台にアクセスする事ができる。 ECR DKR Endpoint S3 endpoint
  34. プライベート・クラスター 疑似テスト環境例 AWS Cloud 作業者 疑似オンプレ環境 Bastion VPC Browser terminal

    ROSA Cluster インストール用VPC Internet ROSA VPC Amazon Route 53 ROSA controlplane STS endpoint private subnet ECR API Endpoint NLB (Internal) AWS Client VPN Client AWS Client VPN Client VPN ENI transit gateway subnet Bastion Server S3 endpoint ROSA Cluster 10.0.1.0/24 10.11.0.0/16 Transit Gateway Private Cluster を作成し、テストしたい場合、プライベート・クラスターにアクセスするためのルートが必用になる。 踏み台サーバーを作成して、AWS VPN を使用する事で、踏み台サーバーにアクセスする事ができる。 10.0.0.0/16 ECR DKR Endpoint
  35. ROSA HCP Public Cluster IPアドレス要件例 (3AZ) Private Subnet のアドレスレンジは、2026年4月現在でサポートされる最大数の 500

    Compute Nodes を収用できる事を想定して設計して います。(Compute Node が少なければ、必要なアドレスを Compute Node 数に従って縮小する事も可能です。) VPCとして最低でも /22 (1024) が必要になる AWS ではサブネットにつき、5つ のIPアドレスが予約される[1] AZ2 AZ3 /28 (16) /28 (16) /28 (16) NATGW NATGW NATGW public subnet public subnet public subnet AZ1 /24 (256) private subnet /24 (256) private subnet Internet へのアウトバウンドのために必要 インターネットのアウトバウンドの経路が別にあ る(Transit Gateway経由など)のであれば、な くても良い。 prefix IPアドレス数 /24 (256) private subnet ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) 一つの AZ は、167以 上(+5の AWS予約分) の IPレンジが必要。 /20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128 /26 64 /27 32 /28 16 ・全ての Subnet の IP アドレスの合計以上の VPC の IPアドレスのレンジが必要です。 ※/28 は AWSで作成できる最小 ・各AWS Subnet は、5つの予約アドレスが必要になります。NAT Gateway は追加で IPアドレスを使用します。その他に のサブネットです。 Firewall 用の Subnet を VPC 内に設置するなど、要件によって必要なアドレス数は異なるため正確な最低要件は実際には環境依 存です。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types
  36. ROSA HCP Clsuter IP アドレス最小要件まとめ Multi AZ 2 AZ Single

    AZ Public Cluster 最小 MachineCIDR /24 (256 IP addresses)[3] /24 (256 IP addresses)[3] /25 (128 IP) [3] Private Cluster 最小 MachineCIDR /24 (256 IP addresses)[3] /24 (256 IP addresses)[3] /24 (256 IP addresses)[3][4] ・AWS ではサブネットにつき、5つの IPアドレスが予約されます[1] ・AWS Service 用の EndPoint 等も作 成されるので、実際に Worker Node に使用できるIPアドレスは確保した Network サイズ以下です。 ・2026/05月時点で Worker Node の 最大数は 500ですが、最小のネットワ ークを作成した場合、ネットワークサ イズにより Worker Node 数が制限さ れます。 [4] 2026/05/07 現在、 現在の以下の検証環境で、Single AZ + Private Cluster の場合は、Single AZ + Public Cluster より大きな Machine CIDR を要求する事 が確認されています。(この仕様は、ドキュメントの [3] の記述と一致していませ ん) 検証環境 : ROSA CLI 1.2.61 : ROSA (OpenShift) Version 4.21.12 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions
  37. ROSA HCP Public Cluster IPアドレス最小要件 (3AZ) ROSA最低要件 : Machine CIDR

    = /24 (256) [3] ※これ以下はインストーラーが動作しない 要件をクリアするために、/25 を各 AZ に割り当てる。 VPCとして最低でも /23 (512) が必要になる AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] AZ2 AZ3 /28 (16) /28 (16) /28 (16) NATGW NATGW NATGW public subnet public subnet public subnet AZ1 /25 (128) /25 (128) private subnet private subnet Internet へのアウトバウンドのために必要 インターネットのアウトバウンドの経路が別にあ る(Transit Gateway経由など)のであれば、な くても良い。 prefix IPアドレス数 /25 (128) private subnet ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 ・全ての Subnet の IP アドレスの合計以上の VPC の IPアドレスのレンジが必要です。 ・各AWS Subnet は、5つの予約アドレスが必要になります。NAT Gateway は追加で IPアドレスを使用します。その他に Firewall 用の Subnet を VPC 内に設置するなど、要件によって必要なアドレス数は異なるため正確な最低要件は実際には環境依存です。 /20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128 /26 64 /27 32 /28 16 ※/28 は AWSで作成できる最小 のサブネットです。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions
  38. ROSA HCP Public Clsuter IP アドレス最小要件 (2AZ / Single AZ)

    2AZ 構成 Single AZ 構成 VPCとして最低でも /23 (512) が必要になる VPCとして最低でも /24 (256) が必要になる AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] AZ1 AZ2 /28 (16) /28 (16) /28 (16) NATGW NATGW NATGW public subnet public subnet public subnet /25 (128) /25 (128) private subnet private subnet AZ1 ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) /25 (128) private subnet サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 ROSA最低要件 Machine CDIR = /24 (256) [3] ※これ以下はインストーラーが動作しない ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 ROSA最低要件 Machine CIDR = /25(128) [3] Single AZ では最低要件が変わる [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions
  39. ROSA HCP Private Cluster IPアドレス最小要件 (3AZ) ROSA最低要件 : Machine CIDR

    = /24 (256) [3] ※これ以下はインストーラーが動作しない 要件をクリアするために、/25 を各 AZ に割り当てる。 VPCとして最低でも /23 (512) が必要になる /25 (128) /25 (128) private subnet private subnet /25 (128) private subnet ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 ・全ての Subnet の IP アドレスの合計以上の VPC の IPアドレスのレンジが必要です。 ・各AWS Subnet は、5つの予約アドレスが必要になります。NAT Gateway は追加で IPアドレスを使用します。その他に Firewall 用の Subnet を VPC 内に設置するなど、要件によって必要なアドレス数は異なるため正確な最低要件は実際には環境依存です。 prefix IPアドレス数 /20 4096 /21 2048 /22 1024 /23 512 /24 256 /25 128 /26 64 /27 32 /28 16 ※/28 は AWSで作成できる最小 のサブネットです。 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions
  40. ROSA HCP Private Clsuter IP アドレス最小要件 (2AZ / Single AZ)

    2AZ 構成 Single AZ 構成 VPCとして最低でも /24 (256) が必要になる AZ1 AZ2 VPCとして最低でも /24 (256) が必要になる AZ1 AWS ではサブネットにつき、5つ のIPアドレスが予約されます[1] /25 (128) /25 (128) /24 (256) private subnet private subnet private subnet ROSA での最大 Compute Node 数は 500 [2] (2026年4月 現在) サポートされる最大の 構成への拡張はこのネ ットワーク構成ではで きません。 2026/05/07 現在、 現在の以下の検証環境で、Private Cluster の場合は、Public Cluster より大きな Machine CIDR を要求する事が確認されています。(この仕様は、ドキュメン トの [3] の記述と一致していません) 検証環境 : ROSA CLI 1.2.61 : ROSA (OpenShift) Version 4.21.12 [1] https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html [2] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-hcp-instance-types [3] https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html-single/networking_overview/index#machine-cidr-description_cidr-range-definitions
  41. 変更履歴 2026/05/07 V1.1 スライド 32,35-36の追加 2026/06/26 V1.2 スライド 3-7 の追加

    2026/10/09 V1.3 スライド24-27を ROSA Console ドメインのカスタムドメインの機能のリリースに伴い、記述を更新。 スライド41 のタイポの修正 “/24(128)”→”/24(256)”
  42. Thank you linkedin.com/company/red-hat youtube.com/user/RedHatVideos Red Hat is the world’s leading

    provider of enterprise open source software solutions. Award- facebook.com/redhatinc winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. 44 twitter.com/RedHat