2026.10.16 Azure

Azure Red Hat OpenShift（ARO）とは？AKSとの違い・料金の実額・az aro createでの構築手順【2026年10月】

Azure Red Hat OpenShift（ARO）は、Red HatのKubernetes製品であるOpenShiftを、MicrosoftとRed Hatが共同で運用するAzureのマネージドサービスです。2026年9月16日には「hosted control planes」方式がパブリックプレビューになりました。この記事では、責任分担、AKSとの違い、東日本リージョンでの料金の実額、az aro createからoc loginまでの手順、サポート期限を整理し、AROを選ぶ組織とAKSで足りる組織の条件を示します。

まとめ：AROはAKSとの費用差でOpenShift一式と共同サポートを買うサービス

AROは「OpenShiftをAzureで、パッチと監視を任せて使う」ためのサービスです。料金は高めで、標準アーキテクチャの最小構成（マスター3台・ワーカー3台）は東日本リージョンの従量課金で月額約2,004ドルになります。同じワーカー3台をAKSのFreeティアで動かすとVM代は約543ドルなので、差額の大半はマスターVMとOpenShiftライセンスです。

その差額で買えるのは、MicrosoftとRed Hatの共同サポート、99.95%のSLA、Route・Operator・ビルド機能を含むOpenShift一式です。すでにオンプレミスでOpenShiftを動かしている組織や、Red Hatのサポート契約を前提に監査を通している組織なら、AROを選ぶ理由になります。OpenShift資産が無く、Kubernetesを初めて本番に入れるチームなら、AKSで足ります。

AROの標準方式とhosted control planesの配置・運用差

AROのノードはAzureの仮想マシンで動き、請求もAzureの請求書にまとまります。Microsoft Learnの概要ページは、AROをRed HatとMicrosoftが共同で設計・運用・サポートするサービスと説明し、2026年10月時点で「標準」と「hosted control planes」の2つのデプロイ方式を併記しています。

MicrosoftとRed Hatの共同運用で利用者に残る作業の範囲

マスターノード・ワーカーノード・仮想ストレージの運用は、MicrosoftとRed Hatの担当です。責任分担表（Responsibility Assignment Matrix）では、アプリケーション・データ・開発者向けサービスは利用者の担当で、クラスターのバージョンは「共有」に分類されています。共有の中身を見ると、更新の予定告知とリリースノートの公開がMicrosoftとRed Hat、更新の開始と自社アプリの互換性テストが利用者です。

つまり「バージョンアップは自動で進む」と考えるのは誤りです。更新ボタンを押す担当者と、事前検証の手順を社内に持っておく必要があります。

2026年9月プレビューのhosted control planesで変わる配置

標準アーキテクチャでは、APIサーバーやetcdを動かすマスターノードが利用者のサブスクリプション内に3台並びます。hosted control planes方式はHyperShiftプロジェクトを土台に、コントロールプレーンをMicrosoftとRed Hatの共有管理基盤へ移し、利用者側に残るのはワーカーノードだけです。Azure Updatesの告知（詳細はMicrosoftの公式ブログ）では、数分でのクラスター作成、ワークロードIDによる短命トークン、etcdの既定暗号化と持ち込み鍵（BYOK）が挙げられています。

プレビューの提供はUK South、East US 2、West Europeなど8リージョンで、2026年10月16日時点で日本は含まれません。料金ページも「Cluster Management料金」が加わるとだけ書き、金額は未掲載です。国内の本番は当面、標準アーキテクチャが前提です。

AKSとAzure Red Hat OpenShiftの違いをSLA・料金・同梱機能で比較

同じAzure上のKubernetesでも、AKSは「Kubernetesを素の形で提供し、周辺は自分で選ぶ」サービスで、AROは「OpenShiftの構成一式を運用込みで提供する」サービスです。AKSそのものの機能はAKS（Azure Kubernetes Service）の解説にまとめています。

AKSとAROの比較表：コントロールプレーン課金・SLA・ノード上限

項目	ARO（標準アーキテクチャ）	AKS
コントロールプレーン	利用者側のVM3台（Linux VM料金）	Free無料・S/Pは管理料金あり
SLA	99.95%	S/P：99.95%・AZなし99.9%
追加ライセンス	ワーカー4vCPUあたり0.171ドル／時	なし
最大ノード数	250台	Free：1,000台・S：5,000台

表中のSはStandard、PはPremiumの略記です。SLAはStandard／Premiumが対象で、FreeにはSLAがありません。AKSの数値はAKSの価格レベルのページ、AROの数値は概要・作成手順・料金の各公式ページに基づきます。

OpenShift独自のRoute・Project・Operatorが既存資産に効く場面

AROに同梱されるのは、Kubernetesに加えてイメージレジストリ、ログ、監視、CI/CD、Webコンソールまでを組み合わせた一式です。外部公開はIngressではなくRoute、名前空間はProject、ミドルウェアの導入はOperatorHubのOperatorで扱います。オンプレミスのOpenShift Container Platformで書いたマニフェストやパイプラインは、AROへほぼそのまま持ち込めます。

OpenShiftの作法を持たない組織では、この一式がそのまま学習コストに変わります。Kubernetesの基本概念から確認したい場合はKubernetesの仕組みの解説が前提知識になります。

Azure Red Hat OpenShiftの料金を東日本リージョンの最小構成で試算

AROの料金ページによると、標準アーキテクチャの請求はAzureインフラ（VM・ストレージ・ネットワーク）とOpenShiftライセンスの2本立てで、マスターにはLinux VM料金だけがかかります。

ライセンス4vCPUあたり時間0.171ドルと予約購入の割引幅

OpenShiftライセンスはワーカーノードのvCPU数で決まり、VMの種類に関係なく4vCPUあたり0.171ドル／時です。2026年10月16日にAzure Retail Prices APIで取得した4vCPUの予約価格は、1年1,004ドル、3年1,977ドルでした。従量で1年動かすと約1,498ドルなので、1年予約で約33%、3年予約なら約56%下がります。常時稼働の本番ワーカーは予約、検証環境は従量と分けて買います。

マスター3台・ワーカー3台で月額約2,004ドルになる費用の内訳

az aro createの既定サイズは、マスターがStandard_D8s_v5、ワーカーがStandard_D4s_v5です。東日本（japaneast）のLinux従量単価で計算すると次のようになります。

内訳	時間単価	月額（730時間）
マスター D8s_v5 ×3台	0.496ドル×3＝1.488ドル	約1,086ドル
ワーカー D4s_v5 ×3台	0.248ドル×3＝0.744ドル	約543ドル
OpenShiftライセンス（12vCPU）	0.171ドル×3＝0.513ドル	約374ドル
合計	2.745ドル	約2,004ドル

ディスク、ロードバランサー、データ転送は含みません。単価は変わるので、見積もり前に次のリクエストで取り直してください。

curl -s "https://prices.azure.com/api/retail/prices?\$filter=productName%20eq%20'Azure%20Red%20Hat%20OpenShift%20General%20Purpose'%20and%20skuName%20eq%20'4%20vCPU'" \
  | jq '.Items[] | {type, reservationTerm, retailPrice}'

az aro createでクラスターを作りoc loginで接続するまでの作業

ここからは公式クイックスタートのクラスター作成手順に沿って、Azure CLIで標準アーキテクチャのクラスターを作ります。Azure CLIは2.67.0以上が必要です。

作成前の44コアのクォータ確認とリソースプロバイダー登録の事前作業

作成時に必要なコア数は44コアです。内訳はブートストラップ8コア、マスター24コア、ワーカー12コアで、インストール後にブートストラップが消えて36コアに落ち着きます。新規サブスクリプションの既定クォータでは足りないため、最初にDSv5ファミリーの空きを確かめ、不足なら引き上げを申請します。

LOCATION=japaneast
az vm list-usage --location $LOCATION \
  --query "[?contains(name.value, 'standardDSv5Family')]" --output table

az provider register --namespace Microsoft.RedHatOpenShift --wait
az provider register --namespace Microsoft.Compute --wait
az provider register --namespace Microsoft.Storage --wait
az provider register --namespace Microsoft.Authorization --wait
az aro get-versions --location $LOCATION --output table

最後のコマンドで、そのリージョンで作成できるバージョンの一覧が出ます。権限は、VNetを含むリソースグループに対する共同作成者とユーザーアクセス管理者（または所有者）、加えてサービスプリンシパルを作れるMicrosoft Entra IDの権限が要ります。Entra IDの権限体系はMicrosoft Entra IDの解説を参照してください。

2つの空サブネットを持つVNet作成からaz aro create実行まで

AROはマスター用とワーカー用に、何も載っていないサブネットを2つ要求します。公式手順と同じアドレス帯で書くと次のとおりです。

RESOURCEGROUP=aro-rg
CLUSTER=cluster
VIRTUALNETWORK=aro-vnet

az group create --name $RESOURCEGROUP --location $LOCATION
az network vnet create --resource-group $RESOURCEGROUP \
  --name $VIRTUALNETWORK --address-prefixes 10.0.0.0/22
az network vnet subnet create --resource-group $RESOURCEGROUP \
  --vnet-name $VIRTUALNETWORK --name master-subnet --address-prefixes 10.0.0.0/23
az network vnet subnet create --resource-group $RESOURCEGROUP \
  --vnet-name $VIRTUALNETWORK --name worker-subnet --address-prefixes 10.0.2.0/23

az aro create --resource-group $RESOURCEGROUP --name $CLUSTER \
  --vnet $VIRTUALNETWORK --master-subnet master-subnet --worker-subnet worker-subnet \
  --version <x.y.z>

<x.y.z>に入れるのは、前のh3で確認したバージョンです。作成には約45分かかり、作成時に指定できるワーカーは50台まで、作成後は250台まで増やせます。OperatorHubのOperatorを使う予定があるなら、Red Hatのプルシークレットを--pull-secretで渡しておきます。サービスプリンシパルで作ったクラスターは後からマネージドIDへ移行できないので、認証方式は作成前に決めてください。

kubeadminの資格情報取得とocコマンドでのログイン確認

作成が終わったら、公式の接続手順どおりにkubeadminの資格情報とAPIサーバーのURLを取り、ocコマンドでログインします。

az aro show --name $CLUSTER --resource-group $RESOURCEGROUP \
  --query "consoleProfile.url" --output tsv

apiServer=$(az aro show --resource-group $RESOURCEGROUP --name $CLUSTER \
  --query apiserverProfile.url --output tsv)
kubevar=$(az aro list-credentials --name $CLUSTER --resource-group $RESOURCEGROUP \
  --query kubeadminPassword --output tsv)
oc login $apiServer --username kubeadmin --password $kubevar
kubevar=""
oc get nodes

6台のノードがReadyなら構築は完了です。kubeadminは初期用なので、IDプロバイダーの設定後は日常の操作に使いません。

バージョン更新とサポート期限：4.21までのカレンダーと更新責任

AROで運用の手間が出るのは、構築よりも更新です。サポートライフサイクルのページ（2026年9月25日更新）を基に、期限の読み方を整理します。

約4か月ごとのマイナー更新と奇数版・偶数版EUSのサポート期限差

OpenShiftのマイナー版は約4か月ごと、パッチ版はおおむね毎週出ます。2026年10月時点の新規作成で選べる最新は4.21（AROでの提供開始2026年8月17日）で、stableチャネルの終了は2027年8月3日です。偶数版にはEUS（延長サポート）が付き、4.20はstableが2027年4月21日、EUSが2027年10月21日まで延びます。

更新チャネルはfast・stable・eusだけが対象です。candidateチャネルで更新するとLimited Support扱いになり、ロールバックもできません。長く据え置きたい本番は偶数版をeusチャネルで持ち、奇数版は検証環境で試す、という分け方が期限から逆算した運用になります。

72時間以内の強制パッチとLimited Supportに落ちる条件

深刻なCVEが出た場合、利用者には72時間以内に最新パッチへ更新するよう通知が来ます。期限内に更新しないと、AROのSREによる自動パッチ適用の対象になる場合がありますので、期限内の更新が必要です。サポート期限を過ぎた版で動かし続けたり、AROが管理するコンポーネントを外したり置き換えたりすると、クラスターはLimited Supportになり、SREの監視とSLAが外れます。

更新を年1回のイベントにする組織とは相性が悪く、月1回のパッチ適用枠を最初から体制に組み込むことになります。

Azure Red Hat OpenShiftを採用すべき組織と見送るべき組織の条件

ここまでの費用と運用の条件から、判断を言い切ります。AROは「OpenShiftがすでに社内標準になっている組織」のためのサービスで、Kubernetesの入口として選ぶ製品ではありません。

AROを選ぶ条件：OpenShift資産とRed Hatサポートが前提の現場

次のどれかに当てはまるなら、AROを第一候補にしてかまいません。

オンプレミスのOpenShift Container Platformがあり、同じマニフェスト・Operator・パイプラインをAzureへ広げたい
監査や社内規程で、Kubernetes基盤にRed Hatのサポート契約が求められている
OpenShift Virtualizationで、VMとコンテナを同じ基盤に載せる計画がある
マスターの運用とパッチを外部に任せたいが、Kubernetes専任の担当者を置けない

月額約2,000ドルの基盤費を、自前運用の人件費より安いと言える規模が目安です。

AKSで足りる条件：月数百ドル規模の予算とKubernetes初導入

OpenShiftの資産が無く、ワーカー3台程度で始める案件なら、AROは採用しません。AKSのFreeティアならVM代だけで済み、本番でもStandardティアの管理料金を足せば99.95%のSLAが付きます。コンテナを数個動かすだけなら、Kubernetesを意識しないAzure Container Appsのほうが運用はさらに軽くなります。

そもそもオーケストレーションが必要かどうかはコンテナオーケストレーションの判断の解説で整理しています。ARO・AKS・Container Appsのどれに載せるか、費用試算と移行計画まで含めて相談したい場合は、Azureを含むインフラ構築の支援で構成案から検討できます。

Azure Red Hat OpenShiftの導入でよくある質問

ARO の検討段階で出やすい質問を5つ取り上げます。

AROとAWSのROSA、OpenShift Dedicatedの違いは何ですか？

いずれもマネージドOpenShiftで、違いは載るクラウドと運用主体です。AROはAzure専用で、MicrosoftとRed Hatが共同で運用し、請求はAzureにまとまります。AWSにはROSA（Red Hat OpenShift Service on AWS）があり、OpenShift DedicatedはRed HatがAWSやGoogle Cloud上で提供する形態です。主に使っているクラウドで選ぶのが自然です。

AROは日本のリージョンで使えますか？

標準アーキテクチャは、Microsoftが2019年12月のリージョン拡張でJapan Eastへの提供を告知しています。作成できるバージョンは、az aro get-versionsにlocationとしてjapaneastを渡すと確認できます。一方、2026年9月にプレビューとなったhosted control planes方式は8リージョン限定で、2026年10月16日時点で日本は含まれていません。国内のデータ所在が要件なら、標準アーキテクチャで設計してください。

AKSで動いているアプリはAROへそのまま移せますか？

Deployment・Service・ConfigMapといった標準リソースはそのまま適用できます。調整が要るのは、rootユーザーで動く前提のコンテナイメージと、Ingressを前提にした外部公開の設定です。OpenShiftは既定のセキュリティ制約でコンテナを非rootかつランダムなUIDで起動するため、書き込み先ディレクトリの権限で起動に失敗する例が多く出ます。本番の前に検証用クラスターで全マニフェストを一度流しておくと安全です。

OpenShiftのライセンスをRed Hatから別に買う必要はありますか？

必要ありません。AROのOpenShiftライセンスはワーカーノードのvCPU数に応じてAzureの請求に含まれます。Red Hatのプルシークレットは、OperatorHubなどRed Hatのレジストリにあるコンテンツを使うためのもので、渡してもライセンス料金は変わりません。

AROのクラスターを止めて費用を抑えることはできますか？

標準アーキテクチャでは、マスター3台が常時動く前提のため、夜間だけ止めるといった使い方には向きません。ワーカー台数を減らせばライセンスとVM代は下がりますが、マスター分の約1,086ドル／月は残ります。hosted control planes方式は使っていない時間帯に開発・テスト環境を縮小できると告知されていますが、まだプレビューでCluster Management料金も未公表です。比べるのは正式提供と料金の公開後にしてください。