Start a conversation

AI

Run OpenShift 5 on AWS With Less Work

November 12, 2026 · Symvoulos Team · 6 min read

A quick overview of Red Hat Openshift5, key capabilities and benefits to leveraging the AWS managed service.

Platform teams have three jobs at once. They must keep apps safe, fix problems fast, and plan upgrades without surprises. OpenShift 5 on Red Hat OpenShift Service on AWS (ROSA) aims to provide value across all 3.

Fix problems faster

Lightspeed now works inside the ROSA console. Teams can ask plain questions such as "why is this deployment failing?" The answers are grounded in official Red Hat and ROSA documentation. Think of a car dashboard that explains the warning light instead of only showing it.

Integrating a model is the step that sets the bill. Lightspeed does not bring its own model, so you connect one before you install the operator.

Integration usually follows four steps.

  1. Pick the model host. A cloud API needs internet access. A model hosted on OpenShift AI or RHEL AI can run offline.
  2. Mirror the container images for a disconnected cluster. Then point Lightspeed at the model endpoint.
  3. Set your telemetry and data rules, so you know where chats go.
  4. Test answers on real cluster questions. Track the cost per question from day one.

Cost moves with that first choice. A cloud API charges per token, so the bill grows with every question. A self hosted model costs GPUs, power and staff, but the cost per question falls when the GPUs stay busy. Low or spiky use often costs less on an API.

The same work opens an upside. One model can serve many internal tools, so its fixed cost spreads across them. Fewer per token fees and tighter data control can lift return, but only when the uses are steady.

Building this also raises AI skill inside the team. Platform staff learn to serve models, test answers and track cost. Developers learn to call the model safely. Start with one internal service and one clear measure.

You need GPUs, people who can run them, and a plan for model updates and security patches. Models can give wrong answers, so keep a person in the loop for any change to a live cluster. Our bias is open models for internal services, since you can pin a version and keep data at home. Closed models still lead on the hardest tasks though so they can act as a backstop.

Source: Red Hat blog, How Red Hat OpenShift 5 transforms operations for Red Hat OpenShift Service on AWS

Build Security In

OpenShift 5 embeds zero trust controls in the core platform. It uses minimal base images and Red Hat Enterprise Linux CoreOS 10. The platform tracks vulnerabilities on an ongoing basis and gives a full software bill of materials, or SBOM, for each build.

An SBOM is an ingredient list for software. You can see what is inside before you ship it.

Several standards bodies shape how an SBOM is built and shared. Four of them matter most.

  • NTIA, 2021. The U.S. National Telecommunications and Information Administration published the first minimum elements for an SBOM in July 2021. It followed Executive Order 14028 from May 2021.
  • CISA, 2025 update. CISA and its partners published updated minimum elements. The update adds component hash, license, tool name and generation context. It covers open source, AI systems and software as a service.
  • SPDX and CycloneDX. SPDX is the ISO/IEC 5962:2021 standard, maintained through the Linux Foundation. CycloneDX began at OWASP and is now the Ecma standard ECMA-424. Both formats are recognized under Executive Order 14028.
  • NIST SP 800-218. NIST's Secure Software Development Framework sets secure build practices for software makers. It was written under Executive Order 14028.

Vendors apply these standards to each release. Red Hat publishes SBOM files in SPDX format for its products. It also publishes CSAF and VEX files that say which known flaws affect each product, so scanners can cut false alarms.

The EU Cyber Resilience Act raises the stakes. Vulnerability reporting began on September 11, 2026, and most duties, including SBOM documentation, apply from December 11, 2027. Finding affected products within hours is hard without an SBOM.

Standards do not solve everything. CISA's draft acknowledged that SaaS and AI software raise problems the SBOM model does not fully cover. One analyst says the update improves the label but may not change outcomes, so treat an SBOM as an inventory tool, not a shield.

Our bias is open formats, SPDX or CycloneDX, so you can move between tools. Ask every vendor for SBOMs in one of these formats with each release.

Source: Red Hat blog, How Red Hat OpenShift 5 transforms operations for Red Hat OpenShift Service on AWS

Upgrade With Less Fear

Standard support now runs 24 months for each release, up from 18. Starting with 5.2, every third release gets up to three years of extended support on designated releases. That gives five years of total support on those releases.

Before an upgrade, automated preflight checks look at API compatibility and update risk. Think of a pilot's checklist and equipment validation which runs before takeoff.

Source: Red Hat blog, How Red Hat OpenShift 5 transforms operations for Red Hat OpenShift Service on AWS

Dynamic Scaling

ROSA with a hosted control plane moves the cluster brain into a Red Hat owned AWS account. Your account holds only the worker nodes, where your apps run.

Hosted control plane - 2 accounts

Think of air traffic control and that Red Hat operates the tower. Your planes are the worker nodes in your own account. In practice this has often lowered infrastructure cost, speeds up provisioning and reduces the chance of accidental changes to the control plane.

Source: Red Hat blog, How Red Hat OpenShift 5 transforms operations for Red Hat OpenShift Service on AWS

Risks and options

Use these points as a checklist before you commit.

  • Less direct control. The control plane sits outside your account. That helps speed. Teams that need deep control may prefer self-managed OpenShift.
  • Cloud lock-in. ROSA runs on AWS. OpenShift itself is open source, so workloads stay portable in principle. The managed service does not.
  • Cost. The claim that you pay only for worker nodes is worth testing. Compare total cost with your current setup, including staff time.
  • AI helper. Answers are grounded in docs, but a person should approve any change. Ask where prompts are processed and what data is stored.

Keep the platform open at its core so you can move if needed. Use a managed service where its speed gain and ROI is clear.

Next step

Red Hat has a learning path for moving classic clusters to hosted control planes. It is linked from the Red Hat article: Migrating applications from Red Hat OpenShift classic clusters to a hosted control plane

Of course, always reach out to us to collaborate!

References

© 2026 Symvoulos LLP. You may quote or excerpt this article with attribution and link to the original URL as well as referenced material. Republication in full, adaptation, translation, or use as the basis of derivative or secondary works requires attribution. Removal or alteration of attribution is prohibited.

Stathy Touloumis is President of Symvoulos (Symv), a boutique technology consultancy serving all sectors of business and government entities including regulated enterprises. His experience spans over 30 years with most recent to state, local, and public entities across infrastructure modernization, security, service delivery strategy, and the governance questions raised by AI adoption. Symvoulos’ expertise starts where most stall: multi-year cost models, risk vectors and staffing plans an agency can defend in a budget hearing. Be sure to follow us at symv.ai.

Want to talk about your own case?

Share a few details. A person on our team will reply.

Start a conversation

← All articles