How to Migrate from Red Hat OpenShift to Amazon EKS and Cut Licensing Costs

Your container images move to EKS for free. That is the first thing teams get wrong about this migration. They assume the hard part is the workloads, when the workloads are the easy part. The hard part is the OpenShift-specific layer wrapped around them, and the subscription line that layer sits on.

I have spent 15 years around production infrastructure, and I have interviewed 200+ CTOs about why they move platforms. When someone tells me they want off OpenShift, the reason is almost always the Red Hat subscription bill, sometimes the operational weight, occasionally both. This article is the honest version of that migration: what OpenShift actually costs, how every OpenShift primitive maps to vanilla Kubernetes on EKS, the step-by-step plan that does not blow up, and the part nobody budgets for - replacing the developer experience OpenShift shipped in one box.

Key points

• Your images move for free. What costs you is the OpenShift layer: DeploymentConfigs, Routes, ImageStreams, BuildConfigs and Source-to-Image, SecurityContextConstraints, and the oc CLI baked into your CI jobs. Inventory those six object types per project first. That list is your migration plan.
• OpenShift licensing is a Red Hat subscription priced per 2-core pack (self-managed OpenShift Container Platform) or billed on worker vCPU-hours (ROSA), charged on top of the infrastructure bill. Amazon EKS charges a flat $0.10 per cluster per hour for the control plane (about $73/month) plus the EC2 or Fargate you run, with no per-core subscription. The saving is the subscription line you stop paying. Compute it from your own worker-core count, not from someone else's headline percentage.
• Every OpenShift primitive has a standard equivalent: DeploymentConfig to Deployment, Route to Ingress, ImageStream to Amazon ECR, BuildConfig and S2I to your CI plus Dockerfiles or Cloud Native Buildpacks, SCC to Pod Security Admission, project to namespace plus RBAC, oc to kubectl.
• The most common breakage is UID-related. OpenShift's restricted-v2 SCC assigns each pod an arbitrary UID from the project's pre-allocated range, so images that quietly assume root or a fixed UID work there and crash-loop on EKS. Test one image as non-root with a random UID before you plan anything else.
• The real project is replacing what OpenShift bundled: a developer console, self-service projects, builds, GitOps, monitoring, and usable multi-tenancy. Either assemble it (Argo CD, Helm, Backstage, kube-prometheus-stack) if you have platform engineers, or use an internal developer platform like Qovery that runs on a standard EKS cluster inside your own AWS account. Rebuild it with headcount and the licensing savings disappear into payroll.
• Never big-bang it. Run OpenShift and EKS in parallel, drain namespace by namespace, move stateful workloads last, and line up the Red Hat renewal date with your drain schedule so the savings actually land.

What does Red Hat OpenShift actually cost, and where do the EKS licensing savings come from?

OpenShift costs you a Red Hat subscription on top of the infrastructure underneath it, priced per 2-core pack for self-managed OpenShift Container Platform or billed on worker vCPU-hours for ROSA. Amazon EKS has no per-core subscription at all - you pay $0.10 per cluster per hour for the control plane plus the EC2 or Fargate capacity you consume. The licensing saving is exactly the subscription line you stop paying, and it only survives if you do not rebuild OpenShift's platform layer with headcount.

Teams conflate the two OpenShift pricing models constantly, so let me separate them.

Self-managed OpenShift Container Platform is a Red Hat subscription sold per 2-core pack (also expressed as a 1-2 socket pack for bare metal), split into Standard (8x5 support) and Premium (24x7 support) tiers. You run the control plane yourself on your own infrastructure, and the subscription rides on top. Red Hat does not publish a list price for this. The official OpenShift pricing page says pricing "varies based on your sizing and subscription choices" and routes you to sales. So I will not invent a figure. Pull your own contracted per-2-core-pack rate from your Red Hat account team and use that number in the model below.

ROSA (Red Hat OpenShift Service on AWS) is billed differently. Per the ROSA pricing page, the worker-node service fee is $0.171 per 4 vCPU-hour consumed by worker nodes, for both ROSA Classic and ROSA with hosted control planes (HCP). ROSA HCP adds $0.25 per cluster per hour; ROSA Classic has no per-cluster fee. The underlying AWS infrastructure (EC2, EBS, data transfer) is billed separately on your AWS bill. Red Hat publishes commitment discounts too: 1-year and 3-year contracts cut the on-demand worker-node service fee by roughly 33% to 55%.

Amazon EKS has no subscription layer. From the EKS pricing page: $0.10 per cluster per hour under standard support (about $73/month per cluster), and if you let a cluster fall onto an older Kubernetes minor version, extended support raises that to $0.60 per cluster-hour (a $0.50 surcharge). On top of the control plane you pay for the compute: plain EC2, EKS Fargate at roughly $0.04 per vCPU-hour and $0.004 per GB-hour in us-east-1, or EKS Auto Mode, which adds a per-instance management fee on top of the EC2 price rather than a flat percentage.

Cost-model comparison

A worked model you can reproduce in a spreadsheet

Here is the arithmetic, so finance can drop in your contracted numbers instead of trusting a vendor slide. Call R your annual self-managed subscription rate per 2-core pack. The subscription line you eliminate is (worker cores / 2) x R. Against that, a single EKS control plane costs about $876/year ($73 x 12), which is a rounding error at any real scale.

Even with a handful of EKS clusters, the control-plane cost stays in the low thousands per year. So the licensing delta is essentially the entire subscription line. Express the result as a range once you plug in R and account for the costs below - never as a single headline percentage, because your estate is not someone else's.

The costs that do NOT disappear on EKS

Be honest with finance about what moves, not vanishes:

• Observability. OpenShift bundled monitoring and logging. On EKS you run CloudWatch Container Insights, Amazon Managed Service for Prometheus and Grafana, or a self-run kube-prometheus-stack. That is real cost, just unbundled.
• A registry. The OpenShift internal registry becomes Amazon ECR at $0.10 per GB-month of storage plus data-transfer-out. Small, but not zero.
• CI runners to replace Source-to-Image builds.
• Platform-engineering time to rebuild the console and self-service layer. This is the big one, and it is the subject of a whole section below.

The second savings lever most teams miss

Bin-packing is independent of licensing and often larger than it. On EKS you can run Karpenter for node consolidation, EC2 Spot for interruptible workloads, and AWS Graviton for better price-performance. The headroom is real: CAST AI's Kubernetes cost benchmark found organizations use, on average, only 13% of provisioned CPUs and 20% of provisioned memory. Graviton instances cost up to 20% less than comparable x86 EC2, and EC2 Spot can save up to 90% off On-Demand. None of that depends on which platform you are leaving - it is a reason EKS plus deliberate FinOps often beats the licensing saving alone.

The honest counter-case

I am not going to pretend this migration is for everyone. If you depend on OpenShift Virtualization to run VMs next to containers, on Red Hat's certifications for a regulated environment, or on a support SLA your auditors specifically require, staying on OpenShift is a defensible decision and this guide is not for you. Moving off a platform to save a subscription only makes sense when that subscription is the problem you actually have.

How do OpenShift resources map to vanilla Kubernetes on EKS?

Every OpenShift-specific object has a standard Kubernetes or AWS equivalent, and for most stateless workloads the conversion is mechanical enough to script. DeploymentConfig becomes Deployment, Route becomes Ingress, ImageStream becomes an ECR repository, BuildConfig becomes a CI pipeline, SCC becomes Pod Security Admission, project becomes namespace plus RBAC, oc becomes kubectl. The exceptions - triggers, lifecycle hooks, operator-supplied SCCs, and OpenShift Virtualization - are where the real work lives.

The first-tier mapping, each line quotable on its own:

• DeploymentConfig to Deployment. Image-change and config-change triggers, lifecycle hooks, and custom rollout strategies have no direct equivalent and must move into CI or an image updater like Argo CD Image Updater.
• Route to Ingress via the AWS Load Balancer Controller, or to the Gateway API (now supported by the controller).
• ImageStream and ImageStreamTag to an Amazon ECR repository plus tags.
• BuildConfig and Source-to-Image to your CI building a Dockerfile or Cloud Native Buildpacks.
• project to namespace plus RBAC plus ResourceQuota plus LimitRange.
• SecurityContextConstraints to Pod Security Admission plus an explicit securityContext.
• oc to kubectl plus a couple of plugins.

The second tier, which teams discover later:

• OpenShift internal registry to Amazon ECR.
• Route edge TLS to an ACM certificate on the ALB, or to cert-manager.
• OpenShift Pipelines (Tekton) to Tekton on EKS, Argo Workflows, or your existing CI.
• OpenShift GitOps to Argo CD installed and operated by you.
• OpenShift Logging and Monitoring to CloudWatch Container Insights, Amazon Managed Prometheus and Grafana, or kube-prometheus-stack.
• OperatorHub operators to upstream OLM or Helm charts, verified one by one.
• OpenShift cluster autoscaling to Cluster Autoscaler or Karpenter.

The arbitrary-UID trap - fix one image before you plan anything else

This is the single most common thing that breaks, and it catches people who never had to think about it. OpenShift's restricted-v2 SCC assigns each pod a UID drawn from the project's pre-allocated range, using the openshift.io/sa.scc.uid-range annotation on the namespace (Red Hat docs). restricted-v2 became the default SCC for authenticated users in OpenShift 4.11. So an image that quietly assumes root, or a hardcoded UID, still runs on OpenShift because the platform hands it a safe UID and group membership.

On EKS, nothing assigns a UID for you. Group-writable directories, hardcoded /home paths, and non-root file-ownership assumptions surface as crash loops the moment the pod starts. The fix is to make the image honestly non-root:

securityContext:
  runAsNonRoot: true
  runAsUser: 1001
  fsGroup: 0
  seccompProfile:
    type: RuntimeDefault

Make writable directories group-writable and owned by GID 0 in your Dockerfile, so an arbitrary or fixed non-root UID can still write. Test exactly one image this way before you plan the rest of the migration. If it survives, most of your stateless fleet will too.

DeploymentConfig is deprecated anyway

You are not giving up a supported primitive. Red Hat's own docs state that as of OpenShift Container Platform 4.14, DeploymentConfig objects are deprecated and new work should use Deployment (Red Hat docs). What you lose moving to a plain Deployment, per Red Hat's comparison: lifecycle hooks (pre/mid/post deployer-pod hooks), user-specified custom deployment strategies, automatic rollback to the last good revision, and the image-change/config-change triggers. Know that list before rollout, not during it. Triggers move into CI or Argo CD Image Updater; rollback moves to your GitOps tooling.

Map SCCs to the right Pod Security level

Kubernetes removed PodSecurityPolicy in v1.25 and replaced it with built-in Pod Security Admission, which has three enforcement levels - privileged, baseline, restricted - in three modes (enforce, audit, warn). Map OpenShift's restricted-v2 to the PSA restricted level rather than over-privileging namespaces to privileged just to make a stubborn pod start. If a workload genuinely needs more, scope the exception to that one namespace.

OpenShift to EKS mapping

What genuinely does not port cleanly

OpenShift Virtualization VMs, the odo inner-loop workflow, third-party operators that ship their own SCCs, and anything that treats the OpenShift internal registry as the source of truth. These are not "convert and move on" items. Flag them early.

And a tooling reality check: kompose is the wrong tool here (it converts Docker Compose, not OpenShift objects). The realistic path is re-authoring manifests as Helm charts or Kustomize overlays, or letting a platform generate them from your repo. A pragmatic starting point is oc get <kind> -o yaml to export, then a scripted pass that strips status, clusterIP, uid, resourceVersion, and OpenShift-specific annotations before you re-apply anything.

What is the safest step-by-step OpenShift to EKS migration plan?

The safest plan runs both platforms in parallel and drains OpenShift one namespace at a time behind weighted Route 53 records or a shared ALB, in eight ordered steps: inventory, landing zone, fix images, pilot one stateless service, validate against numeric thresholds, migrate builds, move stateful workloads last, then decommission in batches aligned with your subscription renewal. The only OpenShift migration I have seen reliably fail is the one that tries to flip everything in a single maintenance window.

Step 0 - Inventory. Export every DeploymentConfig, Route, BuildConfig, ImageStream, SCC binding, Secret, ConfigMap, PVC, and Operator subscription, per project. This spreadsheet is both your migration artifact and the basis for your entitlement-reduction schedule.

for ns in $(oc get projects -o jsonpath='{.items[*].metadata.name}'); do
  for kind in deploymentconfig route buildconfig imagestream pvc; do
    oc get $kind -n "$ns" -o yaml >> "inventory-$ns.yaml"
  done
  oc get rolebindings,scc -n "$ns" >> "inventory-$ns-rbac.txt"
done

Step 1 - Build the EKS landing zone. Create the cluster with eksctl, Terraform (terraform-aws-modules/eks), or EKS Blueprints. Install the AWS Load Balancer Controller for Routes, External Secrets Operator, ECR repositories with lifecycle policies, EKS Pod Identity or IRSA for workload IAM, logging and metrics agents, and Karpenter for node provisioning.

Step 2 - Fix images before you touch manifests. This is where the surprises live. Remove root assumptions, set an explicit non-root securityContext with a fixed UID and fsGroup, and re-test now that no SCC assigns a UID for you. Do this before manifest conversion, not after.

Step 3 - Pilot one stateless service. Re-author it as a Helm chart or Kustomize overlay, deploy to EKS, and split traffic between the two clusters with Route 53 weighted records or a shared ALB target group. One service. Not a wave.

Step 4 - Validate against numeric gates, not vibes. Define p95 latency delta, error rate, HPA behaviour under load, log and metric parity, and alerting coverage as numbers. Write down the rollback trigger as a threshold ("p95 up more than 15% for 10 minutes") so the on-call engineer does not have to make a judgment call at 2am.

Step 5 - Migrate builds. Replace S2I and BuildConfigs with CI-built images pushed to ECR, then port or replace Tekton pipelines. Strip oc out of CI jobs at this step - not earlier, or you break the OpenShift side you are still running.

Step 6 - Move stateful workloads last. Prefer managed services (Amazon RDS, ElastiCache, MSK) over self-hosted operators where you can. For the rest, plan PersistentVolume migration explicitly with the EBS CSI driver and VolumeSnapshot classes for snapshot-and-restore, or application-level replication, plus a real downtime window. Stateful migration is the one place a maintenance window is acceptable.

Step 7 - Decommission in batches and align renewal. Reduce entitlements as you drain, and check the Red Hat renewal date on day one. An auto-renewal mid-migration is the most expensive scheduling mistake in this entire project. If the contract renews in four months and your drain takes six, you just paid for a year you did not need.

Rollback discipline: keep each OpenShift namespace running at minimal replicas until the EKS path has survived one real traffic peak - a Monday morning, a marketing push, a batch window - not one synthetic load test.

This is not just my opinion on sequencing. AWS publishes its own migration guidance through AWS Prescriptive Guidance and the AWS Containers blog, and the parallel-run, drain-by-namespace pattern is the one they converge on too.

What developer experience do you lose when you leave OpenShift, and how do you replace it?

You lose seven things on day one: the developer web console, self-service project creation, Source-to-Image builds, the integrated registry, built-in monitoring dashboards, namespace multi-tenancy guardrails, and the oc workflow your developers already know by muscle memory. Amazon EKS ships a Kubernetes API endpoint and nothing else. Replacing that layer is the real project, and your choice here decides whether the licensing savings survive contact with payroll.

Here is what actually disappears the morning after cutover:

• The web console developers used to see their apps, logs, and builds.
• Self-service: a developer could create a project and ship without filing a ticket.
• S2I builds that turned a git repo into a running pod with no Dockerfile.
• The integrated registry that "just worked" with builds.
• Monitoring dashboards that existed without anyone wiring them up.
• Multi-tenancy guardrails that kept teams out of each other's namespaces.
• The oc CLI and the habits built around it.

There are three honest ways to replace it.

Path A - Assemble it yourself

Argo CD or Flux for GitOps, Helm or Kustomize for templating, Backstage for the developer portal, kube-prometheus-stack or Amazon Managed Prometheus/Grafana for observability, Karpenter for node efficiency, Kyverno or OPA Gatekeeper for policy. This is the right call if you already have platform engineers who want to own the stack.

Be clear-eyed about the upkeep. These are mature projects - Argo CD is CNCF Graduated (since December 2022, ~24k GitHub stars) and Cloud Native Buildpacks graduated in 2026. But Backstage is still CNCF Incubating, and a production Backstage portal is a staffed internal product, not a weekend install. Someone owns the integration between all of these. Someone owns EKS version upgrades on the 14-month standard support window. That someone is a salaried platform engineer, and in the US that is well into six-figure total comp (check levels.fyi for current ranges). Two or three of them and you have spent the licensing savings on payroll. That can still be the right trade - just do the math honestly.

Path B - An internal developer platform

This is the path most teams without a dedicated platform org should price first. At Qovery, we built exactly for this gap: Qovery runs on a standard EKS cluster inside your own AWS account (BYOC), so the AWS bill and any Savings Plans or EDP discounts stay in your name. It gives developers git-push deployments, per-pull-request preview environments, environment auto-stop for non-production, per-environment RBAC that maps cleanly onto what OpenShift projects gave you, managed cluster upgrades, and databases backed by managed cloud services.

The part that matters for a platform migration: Qovery is multi-cloud. The same workflow targets AWS, GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster. So leaving OpenShift does not swap one lock-in for another - which is the whole reason you are reading a migration article in the first place.

Path C - Keep a managed OpenShift experience

If the real complaint is self-managed operational pain rather than the subscription line, ROSA removes the ops and keeps the entire OpenShift ecosystem. SUSE Rancher Prime and VMware Tanzu are alternative commercial control planes worth pricing too. There is no shame in deciding the subscription was never the real problem.

Where Qovery is the wrong answer

I would rather tell you this up front. If your developer interface is built around custom CRDs, your own operators, deep Tekton pipelines, or service-mesh-level traffic control, raw Argo CD plus Helm fits you better than any opinionated platform. And these paths are not mutually exclusive - Qovery runs on a standard EKS cluster, so kubectl, Helm, and Argo CD keep working right alongside it, and nothing stops you from moving to Path A later if your team grows into it.

Replacement matrix

How long does an OpenShift to EKS migration take, and what blows up the timeline?

Plan in months and in waves, not sprints. A landing zone plus pilot typically takes weeks, stateless waves run team by team, and stateful workloads plus decommissioning close the project. The schedule is driven by your OperatorHub operator count and your stateful workloads - not by microservice count. 200 stateless services sharing one Helm chart pattern move faster than 12 services sitting behind five custom operators.

The five real timeline drivers:

• How many OperatorHub operators you actually use (each needs an upstream equivalent or a rewrite).
• How many stateful services and PersistentVolumes you have.
• How deeply oc is wired into CI and developer habits.
• Whether your images assume root or a fixed UID.
• How many teams need retraining on the new workflow.

A wave model you can copy:

• Wave 0: landing zone plus one pilot service. Weeks, not days.
• Waves 1-n: stateless services, grouped by team, so each team learns the new flow once.
• Then: builds and CI.
• Then: stateful workloads.
• Finally: decommission and reduce entitlements.

Treat those bands as estimates, not benchmarks - your operator and stateful counts move them more than anything I can put in a table.

The common blowups, each with its mitigation:

• SCC-to-Pod-Security mismatches. Mitigation: the fix-one-image step above, done first.
• Third-party operators with no upstream equivalent. Mitigation: inventory and spike these in Wave 0, not Wave 5.
• Route annotations with no Ingress analogue - sticky sessions, custom timeouts, path rewrites. Mitigation: translate them to ALB annotations during the pilot while the blast radius is one service.
• PV migration with no acceptable downtime window. Mitigation: move to managed data services where possible, and negotiate the window early for the rest.
• A subscription renewal that forces a rushed cutover. Mitigation: check the date on day one and schedule backward from it.

The under-budgeted line is change management. Developers who only ever used oc and the OpenShift console need a working replacement interface on day one of Wave 1. If they do not have one, they will route around you and ship from laptops, and your careful migration turns into shadow infrastructure. This is exactly why the developer-experience choice in the previous section is not a nice-to-have.

Tie the schedule to money explicitly. Map each decommissioned worker node back to reclaimed cores, so finance sees savings land per wave instead of waiting for final cutover. And use the EKS 14-month standard plus 12-month extended support window to set your upgrade cadence before you hand the cluster over to whoever owns it next - do not inherit an extended-support surcharge because nobody scheduled the upgrade.

Should you migrate to EKS, move to ROSA, or stay on self-managed OpenShift?

Choose by what you are actually trying to fix. If the pain is the per-core subscription line, EKS plus a deliberate developer-experience replacement wins. If the pain is operating OpenShift yourself, ROSA removes the ops and keeps the ecosystem. If the pain is compliance, auditor-mandated SLAs, or OpenShift Virtualization, stay where you are. The mistake is migrating to solve a problem you do not have.

Decision rules by driver:

• Cost-driven: go EKS, and spend part of the saving on the platform layer deliberately.
• Ops-driven: price ROSA before you migrate. You may be solving the wrong problem.
• Compliance-driven or VM-heavy: stay. OpenShift Virtualization and Red Hat's certifications do not have clean EKS equivalents.
• Skills-driven: ask who owns the replacement platform layer for the next three years, and budget for them.

Decision rules by team shape:

• Zero dedicated platform engineers: EKS plus an internal developer platform.
• One or two platform engineers for 20+ developers: EKS plus an IDP, or a very disciplined Argo CD setup - not an open-ended Backstage build.
• Mature platform team with existing Helm and Argo CD experience: EKS DIY.

The multi-cloud angle matters more than it looks. EKS plus a cloud-agnostic platform layer keeps the door open to GCP, Azure, Scaleway, or your own self-managed Kubernetes later. If a future cloud move is even plausible, do not re-platform onto AWS-only primitives on the way out of one lock-in and into another. For what it is worth, managed Kubernetes is where the market already sits - Datadog's container research has found the large majority of Kubernetes organizations run on a managed service rather than rolling their own control plane.

A checklist you can run this week:

• Export the per-project inventory (Step 0 above).
• Count your OperatorHub operators.
• Run one image as non-root with a random UID and see if it survives.
• Pick the pilot namespace.
• Confirm the Red Hat subscription renewal date.
• Price the same worker cores as plain EC2 under one $0.10/hour EKS control plane.

Decision table

Leaving OpenShift is not about proving Red Hat wrong. OpenShift is good software. It is about matching what you pay to what you actually use - and if the subscription line is bigger than the value it returns, the move pays for itself. Just make sure you count the platform layer before you count the savings.

How do you migrate from Red Hat OpenShift to Amazon EKS?

Run both platforms in parallel and drain OpenShift one namespace at a time. Inventory every OpenShift object per project, build an EKS landing zone, fix images to run non-root with a random UID, pilot one stateless service behind weighted traffic, validate against numeric gates, migrate builds off Source-to-Image, move stateful workloads last, and decommission in batches aligned with your Red Hat renewal date. Never attempt a single-window big-bang cutover.

How much can you save on licensing by moving from OpenShift to EKS?

The licensing saving is the entire Red Hat subscription line you stop paying. Amazon EKS has no per-core subscription - just $0.10 per cluster per hour (about $73/month) plus the compute you run. Compute your own number as (worker cores / 2) x your contracted per-2-core-pack rate, minus the unbundled costs you pick up (observability, registry, CI, and the platform team). Express it as a range for your estate, not a headline percentage from someone else's.

What is the EKS equivalent of an OpenShift Route, DeploymentConfig, and ImageStream?

A Route becomes a Kubernetes Ingress (or Gateway API) served by the AWS Load Balancer Controller through an ALB. A DeploymentConfig becomes a standard Deployment - and DeploymentConfig is already deprecated by Red Hat as of OpenShift 4.14. An ImageStream becomes an Amazon ECR repository with tags, with image-change triggers moving into your CI or Argo CD Image Updater.

Do I need to change my container images to move from OpenShift to EKS?

Often yes, and it is the most common breakage. OpenShift's restricted-v2 SCC assigns each pod an arbitrary UID from the project's range, so images that assume root or a fixed UID work there and crash-loop on EKS, where nothing assigns a UID for you. Set runAsNonRoot: true, an explicit runAsUser and fsGroup, and make writable directories group-writable with GID 0. Test one image this way before planning the rest.

How long does an OpenShift to EKS migration take?

Months, in waves, not a single sprint. The landing zone plus a pilot takes weeks; stateless services migrate team by team; stateful workloads and decommissioning close it out. Timeline is driven by your OperatorHub operator count and stateful workloads, not by how many microservices you run - a large fleet of similar stateless services moves faster than a dozen services behind custom operators.

Should I move to ROSA instead of EKS to reduce OpenShift costs?

If your pain is operating OpenShift yourself rather than the subscription, ROSA is worth pricing first - it removes the ops and keeps the full OpenShift ecosystem, billed at $0.171 per 4 vCPU-hour of worker nodes (HCP adds $0.25/cluster/hour). But ROSA still carries a service fee that plain EKS does not. If your pain is specifically the per-core cost, EKS plus a deliberate developer-experience layer saves more.