前に 「ROSAって結局どんな時に使うの？」 という採用判断の記事を書いた。あれは「使うか / 手放すか」の話。
この記事はその続き＝「使うと決めた後、実際に立てるときの設定値」
大規模（数十〜数百ノード級・マルチテナント）で本番投入するとき、インフラ/OpenShift勢に突っ込まれない値を先に固めるための実践チートシート。検証は OpenShift 4.18 系／現行 ROSA ドキュメント基準。

0. この記事の立ち位置：マネージドでも自分持ちの設定

前記事の結論は 「ROSAは運用を金で買うプラットフォーム」。コントロールプレーンの運用・アップグレード・障害対応は Red Hat SRE + AWS に手放せる。

でも、手放せない値が残る。それは──

AWS 側の設計（CIDR・IAM/STS・KMS・ネットワーク）で、
しかもインストール後に戻せないもの。

マネージドに預けても、ここだけは自分で正しく決めないとクラスタ再作成コースになる。責任共有モデルで言えば、**Red Hat/AWS に手放した運用の裏で「利用者側に残る設定」**にあたる部分。このチートシートは、その"マネージドでも自分持ちの設定"を設定値レベルで潰すためのもの。だから並び順は「戻せなさ」で決める。

優先度	分類	変更可否	失敗の代償
★★★	アーキ選定 / CIDR設計 / etcd暗号化	インストール後は不可	クラスタ再作成
★★	マシンプール / IAM・STS / Ingress・DNS / コスト設計	一部 day-2 で調整可	再構築 or 慎重な移行
★	ワークロード可用性 / クォータ / アップグレード運用	day-2 で調整可	運用でリカバリ可能

「★★★ を全部埋めてから rosa create cluster を叩く」が鉄則。

「ROSAって何？ / いつ使う？」は前記事に記載しました。ここでは採用は決まった前提で、設定値だけを扱う。

1. ★★★ アーキテクチャ選定（設定に効く差分だけ）

採用判断（HCP か Classic か、そもそも EKS か）は前記事の領分。ここでは設定値に直結する差分だけを押さえる。大規模は原則 HCP 前提で書く。

設定に効く観点	ROSA with HCP	ROSA Classic
自アカウントの最小ノード	worker 2 台〜	7〜9 台（master3 / worker3 / infra2〜3）
control plane ⇔ worker	AWS PrivateLink（別アカウント間）	VPC 内
machine pool と AZ	1 pool = 1 AZ 固定	pool 内でマルチ AZ 可
アップグレード単位	CP と pool を独立に実施可	クラスタ一体
Spot	非対応	専用 pool で対応
STS	必須	前提

設定への波及

HCP は 1 machine pool = 1 AZ。マルチ AZ にしたければ AZ ごとに pool を1本ずつ作る（→ 3章のオートスケーラ設計に直結）。
HCP × CMK は control plane が別アカウントなので、KMS キーポリシー設計が一手増える（→ 6章）。
Spot を大量に使う設計なら Classic か EKS を再検討（採用判断に差し戻し）。

2. ★★★ ネットワーク / CIDR 設計（最重要・変更不可）

machine / service / pod CIDR と host prefix はインストール後に一切変えられない。 マネージドでも自分持ちの設定の筆頭で、しかも AWS 側の設計。500 ノードに届く前に IP 枯渇で詰むのを防ぐ。

2-1. デフォルト値（起点）

項目	rosa フラグ	デフォルト	意味
Machine CIDR	`--machine-cidr`	`10.0.0.0/16`	ノード（EC2）が載る全サブネットを内包
Service CIDR	`--service-cidr`	`172.30.0.0/16`	ClusterIP Service 用
Pod CIDR	`--pod-cidr`	`10.128.0.0/14`	Pod オーバーレイ全体
Host Prefix	`--host-prefix`	`23`	1ノードに切る Pod サブネット（/23 = 510 IP/ノード）

CNI は OVN-Kubernetes が既定（旧 OpenShift SDN は現行リリースで廃止）。SDN 前提の runbook は OVN に読み替える。

2-2. Machine CIDR のサイジング（事故りやすい）

2-3. host prefix と Pod 数の関係

host prefix	Pod 用 IP/ノード	備考
`/23`（既定）	510	実質は maxPods=250、さらにリクエストが先に効く（→3章）
`/24`	254	高密度にしないなら十分
`/22`	1022	maxPods を上げる場合に

2-4. 全社ネットワークとの衝突回避

Pod / Service / Machine の各 CIDR を オンプレ・他 VPC・TGW 先・OVN 予約レンジと重複させない。
前記事でも触れた通り ネットワーク/IAM は「AWS の設計」として普通に考える。ここは OpenShift に丸投げできない。

2-5. サブネットタグ（LB連携で必須）

private サブネットに internal LB を出すなら、プリフライトで確認：

kubernetes.io/role/internal-elb = 1

3. ★★ マシンプール設計

3-1. インスタンス選定（コストは11章と一体で考える）

汎用 m5/m6i、コスト最適化なら Graviton（m6g 等 ARM） を評価。ただし Graviton で下がるのは EC2 側だけでライセンスは不変（→11章）。
用途別に pool を分ける：latency-sensitive な tier-1 と bursty なバッチを別 pool（別サイズ）にして noisy-neighbor を物理分離。

3-2. オートスケーリング

rosa create machinepool -c <cluster> \
  --name app-az-a \
  --instance-type m6i.2xlarge \
  --availability-zone <az-a> \
  --enable-autoscaling --min-replicas 3 --max-replicas 30 \
  --labels tier=app

HCP は 1 pool = 1 AZ。伸ばしたい AZ ごとに autoscaled pool を1本ずつ。
min は「プラットフォーム必須 + バッファ」を割らない値に。
autoscaler の勘所：Pending Pod が「その pool が足すノード形状に載らない」なら max を上げても伸びない。requests / affinity / instance type のどれかを直す。

3-3. 1ノードあたり最大 Pod 数（maxPods）— 250は上限であって目標ではない

出荷時デフォルトは maxPods = 250 / podsPerCore = 0（＝podsPerCore無効）。素の ROSA では 250 が唯一のカーネル側ノード上限。

ただし現実には 250 には届かない。先に効くのは：

リソースリクエスト（mem/CPU）が圧倒的に先に刺さる。 例：m5.2xlarge（8vCPU/32GiB）の Allocatable は実質 23〜24GiB 前後。アプリPodが平均 512Mi〜1Gi 要求なら 1ノード 25〜45 Pod 程度でスケジュール不能になり、250 の 1/5 以下で頭打ち。
ROSA は OVN-Kubernetes（Geneve オーバーレイ）なので、EKS + VPC CNI のような ENI/セカンダリIP 上限で Pod が刺さらない。 Pod IP は host-prefix（/23=510）から出るので、510 も 250 もリソースが尽きる前に表に出ない。

→ 250 は天井であって設計目標ではない。ノードあたり Pod 数は事実上リクエスト駆動。

チューニングは"下げる方向"が主。 大量の軽量 Pod で詰めると PLEG / conntrack / kubelet 負荷が上がり NotReady に振れ、blast-radius も広がる。安定重視で 110 前後（upstream K8s 推奨）に絞る運用がある。上げるのは稀で、Red Hat も「テスト上限を超えるな、Pod が要るならノードを足せ」。

# KubeletConfig 例：あえて maxPods を絞る（PLEG/blast-radius 対策）
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cap-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    maxPods: 110   # podsPerCore は既定 0（無効）。使うなら明示的に設定する

podsPerCore はデフォルト 0（無効）。上の CR で設定した場合に限り「maxPods と小さい方が効く」ルールが発動する（例 podsPerCore=10 なら 25コア未満で podsPerCore が上限）。素のクラスタの挙動ではない。

4. ★★ キャパシティプランニング（Allocatable の罠）

スケジューラが見るのは Capacity ではなく Allocatable（プラットフォーム予約を引いた後）。

計画上の目安（バージョン・インスタンス・機能で変動する概算）：system 予約 ≈ 4.76 GiB、必須クラスタサービス ≈ 3.8 GiB。
つまり 「32GiB クラスのノード」に 24Gi 要求の Pod が Pending になり得る。請求ではなくスケジューライベントに出る事故。
GiB と GB を混同しない：Gi/Mi は 2 のべき乗、G/M は 10 進。「32 GB インスタンス」＝ 32Gi ではない。
実クラスタでは oc describe node <node> の Allocatable を正とする。
結論：1ノードの Pod 数は maxPods（250）ではなく Allocatable ÷ 平均リクエストで決まる。 インスタンス選定は「maxPods に収まるか」ではなく「requests に対して Allocatable が何 Pod 分あるか」で考える。

oc describe node <node> | grep -A6 Allocatable

5. ★★ IAM / STS / OIDC

HCP は STS 前提（短命トークン、1時間以内で失効）。長期 IAM ユーザーキーは使わない。前記事で言う「AWS の作法」がそのまま要る領域。

5-1. ロールの2階建て

種類	役割	代表的な managed policy
account-wide roles	プロビジョニング・SRE サポートの土台	`ROSAInstallerPolicy` / `ROSASRESupportPolicy` / `ROSAWorkerInstancePolicy` ほか
operator-specific roles	Pod 単位（Ingress・EBS CSI 等）に OIDC 経由付与（IRSA）	`ROSAIngressOperatorPolicy` / `ROSAAmazonEBSCSIDriverOperatorPolicy` ほか

5-2. 大規模での定石

OIDC config は再利用可能な形で1つ作る（rosa create oidc-config --mode auto）。複数クラスタで使い回す。
kubeadmin は IdP 検証後に削除。外部 IdP（Azure AD / Okta 等）で MFA と RBAC を統一。
アプリの AWS アクセスは IRSA 一択。ServiceAccount ごとに最小権限ロール。trust の sub は system:serviceaccount:<ns>:<name> まで絞る（* や緩い StringLike 禁止）。

rosa list operator-roles --prefix <prefix>
rosa list idps -c <cluster>

6. ★★★ 暗号化（etcd / KMS / EBS）

6-1. etcd 暗号化の判断

etcd は 既定で AES ブロック暗号化済み。その上で KMS CMK による追加暗号化を選べる。
CMK etcd 暗号化はおよそ 20% の性能オーバーヘッド。要件が明確な場合だけ有効化（不要なら無効のまま推奨）。
インストール時のみ設定可（後付け不可）。

6-2. フラグの違い（混同注意）

フラグ	暗号化対象
`--kms-key-arn`	worker の root ボリューム / EBS
`--etcd-encryption` + `--etcd-encryption-kms-arn`	etcd データベース

rosa create cluster --sts --hosted-cp --mode auto \
  --cluster-name <name> --region <region> \
  --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 \
  --pod-cidr 10.128.0.0/14 --host-prefix 23 \
  --oidc-config-id $OIDC_ID --operator-roles-prefix $PREFIX \
  --kms-key-arn $KMS_ARN \
  --etcd-encryption --etcd-encryption-kms-arn $KMS_ARN

HCP × CMK の落とし穴：control plane が別アカウントにあるため、KMS キーポリシーに operator ロール（*-kube-system-kms-provider 等）を許可しないと worker が起動しない。キー作成とキーポリシー更新を必ずセットで。

6-3. ストレージ暗号化

新規は既定 gp3 StorageClass、PV は既定で暗号化。他 SC は暗号化設定時のみ。
イメージレジストリは S3（SSE-S3）で at-rest 暗号化済み。

7. ★★ Ingress / DNS / ロードバランサ

private を基本線に。規制・本番の internet-facing estate は private API + 限定 ingress。PrivateLink 経由で SRE 管理を private に保つ。
HCP の DNS は「公開 DNS 名 → VPC 内 private IP に解決」（RDS 等と同じ）。IP 直書き禁止、FQDN のみ。
IngressController を分離：プラットフォーム/CI 用とテナントアプリ用で別 IngressController、blast-radius を縮小。

Route TLS 終端の使い分け

Route 種別	終端位置	用途
`edge`	router で終端	一般 HTTPS
`reencrypt`	router 終端後、backend へ再暗号化	backend まで TLS
`passthrough`	Pod までクライアント TLS を貫通	mTLS 等。ALB で TLS 終端すると壊れる

証明書は cert-manager / External DNS Operator で GitOps 化（コンソール手作業を避ける）。前記事の「GitOps 前提で組む」がここにも効く。

8. ★★ セキュリティハードニング

SCC は restricted（restricted-v2）を基本。特権が要るなら privileged ではなく custom SCC。
securityContext 明示：allowPrivilegeEscalation: false / runAsNonRoot: true / readOnlyRootFilesystem: true / capabilities drop-all → 最小 add / seccompProfile: RuntimeDefault。
NetworkPolicy / EgressFirewall は OVN-Kubernetes 前提。既定は全 Pod 間疎通なので namespace 単位で default-deny。
外向きは EgressFirewall（FQDN/CIDR 許可）で exfiltration を防ぐ。
Compliance Operator（OpenSCAP）で CIS/PCI-DSS/FedRAMP を自動監査。HCP では worker 上で走らせる。
default SA を本番 Deployment に使わない。API を叩かない Pod は automountServiceAccountToken: false。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: <team-ns>
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

9. ★ ワークロード可用性（大規模で効く）

PDB の定番事故：replica 2 に minAvailable: 2 を張ると ノードドレインが永久に終わらず、アップグレードが止まる。原則 maxUnavailable: 1 を許容 or メンテ前に replica を増やす。
スプレッド：podTopologySpreadConstraints で hostname（ノード）と zone（AZ）に分散。容量不足を Pending で顕在化させたいなら DoNotSchedule。
ingress/gateway 系の高接続 Pod は 1ノード集中で conntrack/FD/エフェメラルポートを枯らす。最低3レプリカ + ノード/AZ 分散 + PDB。
probe：liveness と readiness を同一エンドポイントで使い回さない（負荷時に再起動ループ）。/livez と /readyz を分ける。
クォータ：各 project に ResourceQuota + LimitRange。全 container に requests/limits 必須化（Kyverno/Gatekeeper で強制）。事業部横断は ClusterResourceQuota。
JVM は CPU ベース HPA（memory を OS に即返却しないので memory HPA が効きにくい）。

10. ★ アップグレード戦略（HCP の強み）

HCP は CP → machine pool を段階的に上げられる。チームごとにメンテ窓が違う大規模で効く。
machine pool 更新は Node Surge（maxSurge で余剰ノードを先に用意 → 旧ノードを drain）。PDB と maxSurge が正しければ容量を落とさず更新。
更新前後で oc get clusteroperators の Degraded を潰す。

rosa list upgrade -c <cluster>
rosa upgrade cluster -c <cluster> --version <ver>     # CP を先に
rosa upgrade machinepool -c <cluster> <pool>          # pool を後で

11. ★★ コスト / ライセンス効率の設計レバー（"成功ペナルティ"を設定で殺す）

前記事で書いた pricing inversion / 成功ペナルティ（vCPU課金なので総vCPUを増やすとライセンスが比例で跳ねる）を、設定でどう効かせるか。ここが両記事の接続点。

11-1. 課金構造をもう一度、設定目線で

ROSA の worker サービスフィーは 4 vCPU あたり課金：

契約	目安（worker / 4vCPU）
オンデマンド	$1,500 / 年
1年コミット	$1,000 / 年
3年コミット	$667 / 年

EC2 実費は別。3年 HCP + EC2 Savings Plan で、オンデマンド Classic 比おおよそ 68% 減の試算も出ている。

11-2. 唯一効くレバー：vCPUあたりのワークロード密度

ライセンスは vCPU に比例する。だから コスト単価を下げるレバーは「同じ vCPU にどれだけ載せるか」＝ requests 適正化。

maxPods を上げても、大きいノードにしても、ライセンス単価は下がらない。 効くのは 3〜4章で見た「requests 駆動の密度」。過剰な requests を削って vCPU あたりの実効 Pod 数を上げるのが、実は最大のコスト施策。
requests が実測の 2〜3 倍で張られている、が大規模だと当たり前に起きる。VPA レコメンド / メトリクスで棚卸しすると、ノード台数（=vCPU=ライセンス）がそのまま減る。

11-3. Graviton は「EC2 側だけ」下がる

Graviton 化で下がるのは EC2 実費だけ。ライセンス（vCPU課金）は不変。
なので Graviton の判断は 「EC2 削減 vs ARM 対応の工数」で閉じる。ライセンス削減を期待して Graviton に寄せると読み違える。ARM 対応済みイメージなら素直に EC2 コストが浮く、で十分。

11-4. "成功ペナルティ"回避の実装ルール

高コア機への無闇な集約はライセンスを増やす。集約するなら「vCPU 総数を増やさず密度を上げる」方向（＝ requests 適正化）で。コア数を増やして詰めると、その分ライセンスが乗る。
定常 production pool は Savings Plan / コミットで握る。worker フィー（コミット）と EC2（Savings Plan）は別々に最適化する。
Spot は Classic pool のみ（HCP 非対応）。fault-tolerant なバッチはこちら。

11-5. 損益分岐の目安（前記事の"EKSとの天秤"を数式化）

ROSA上乗せ ≒ (workerフィー × vCPU規模) + ライセンス
純k8s(EKS)コスト ≒ CP実費($73/月/cluster) + 運用人件費 + アドオン構築工数

→ 「浮く人件費 > ROSA上乗せ」なら ROSA、逆なら EKS/自前

チームが薄いうちは ROSA が勝ちやすく、vCPU規模が大きく専任SREを常設できる体力が出ると EKS/自前が追い抜く、という交差が典型。前記事の「何を握って何を手放すか」が、ここで vCPU 規模の数字に落ちる。

12. 上限・クォータ早見表

項目	値 / 目安	備考
ROSA HCP worker 上限	500	machine CIDR は `/22`+
maxPods / ノード（既定）	250	実際はリクエストが先に効く
HCP 最小 machine CIDR	`/25`（1AZ）/ `/24`（multi-AZ）	下限強制
HCP 最小 worker	2	Classic は 7〜9
本番 AZ 数	3 以上	AZ ごとに autoscaled pool
worker サービスフィー	4vCPU あたり課金	コミットで削減
AWS サービスクォータ	VPC/EIP/ELB ルール等	設計レビュー時に増枠申請

13. インストール前チェックリスト（変更不可な値）

rosa create cluster の前に、以下を全部確定させる。

HCP か Classic か（Spot 要件なら再検討 → 前記事の採用判断へ）
Machine CIDR（500ノードなら /22+、Network Calculator で検算済み）
Service / Pod CIDR / host prefix（全社ネットワークと非重複）
host prefix と Pod 密度の整合（将来の requests 込み）
AZ 構成（3AZ、AZ ごとの pool 計画）
etcd 暗号化の要否（CMK なら 20% オーバーヘッド承知）
KMS：--kms-key-arn（EBS）と --etcd-encryption-kms-arn（etcd）を区別、キーポリシーに operator ロール許可
private / PrivateLink / zero-egress 方針
OIDC config を再利用可能な形で作成
account/operator roles を最小権限で
IMDSv2（--ec2-metadata-http-tokens required）の要否
vCPU 規模の見積り（ライセンス費 = "成功ペナルティ" を先に試算）
AWS Service Quotas 増枠申請

まとめ：手放していい運用の裏で、この値だけは握る

前記事の結論は「ROSAは運用を手放していい」だった。この記事はその裏面。

運用は手放せる。でも AWS 側の、戻せない値だけは自分で握らないといけない。

CIDR / host prefix — 500ノードを見据えて /22+、Network Calculator で検算
etcd / KMS — 要否とキーポリシーをインストール前に確定
IAM / STS — IRSA 最小権限、OIDC 再利用
コスト — ライセンスは vCPU 課金。単価を下げるレバーは requests 密度だけ。Graviton は EC2 側のみ
あとは day-2（マシンプール・クォータ・アップグレード）で調整可能

この順で潰せば、インフラ勢にも OpenShift 勢にも刺されにくく、かつ「運用を手放した分のコスト」も見える構成になる。

参考（一次情報を必ず当たること）

ROSA Best Practices and Recommendations（Red Hat Cloud Experts）
ROSA / OpenShift 公式ドキュメント（Architecture models / Data protection / Nodes / Networking）
OpenShift Network Calculator（CIDR 検算）
AWS ROSA User Guide（暗号化 / shared responsibility / service quotas）
前記事：「ROSAって結局どんな時に使うの？」（採用判断編）

本記事の数値は OpenShift 4.18 系／2026年時点のドキュメントに基づく。インストール後に変更不可な値は、必ず最新の公式ドキュメントと Network Calculator で再確認してから本番投入すること。