My Daily Cloud Blog

Overview of ROSA Architecture Diagram

When I first started working with ROSA, I’ll be honest — I was overthinking it. I was coming from months, maybe over a year now, of dealing with:

• self-managed Kubernetes,
• DIY OpenShift installs,
• control planes that everyone pretends are easy until something breaks at 2 a.m.

So when someone said, “ROSA is just managed OpenShift on AWS,” my immediate reaction was:

Okay… but who actually owns what when things go wrong?

That question is what this post is really about.

The One Sentence That Changed Everything for Me

Here’s the sentence that finally made ROSA click:

Red Hat runs the control plane. I run my workloads in my AWS account.

That’s it.

Once I stopped trying to mentally map ROSA as “EKS but different” and instead saw it as a clean ownership split, everything else started to make sense.

How ROSA Is Really Split (In Practice)

The Control Plane (Not My Problem — and That’s a Good Thing)

The first thing I had to accept was that I don’t touch the control plane.

No:

• API server patching
• etcd tuning
• upgrade choreography
• “don’t reboot that node yet” moments

All of that lives in Red Hat–managed AWS accounts.

At first, that felt uncomfortable — engineers like control.
But then I realized something important:

I’ve never once added business value by babysitting a Kubernetes control plane.

Red Hat:

• patches it,
• upgrades it,
• monitors it,
• keeps it highly available.

And I get to focus on things that actually matter to my team and my customers.

The Worker Nodes (Very Much My Responsibility)

This is where ROSA started to feel familiar again.

The worker nodes:

• live in my AWS account,
• sit inside my VPC,
• run in my subnets.

This is where:

• applications run,
• containers execute,
• data is processed.

From a security and compliance standpoint, this was huge for me — especially thinking about government and regulated environments.

My data never leaves my AWS account.

That one fact alone removes a lot of friction in security conversations.

The AWS Account Model (Why Security Teams Like ROSA)

In real-world terms, ROSA usually looks like this:

• Red Hat AWS account → control plane
• My AWS account → worker nodes, networking, data

That separation is intentional.

When I had to explain ROSA to security stakeholders, this model actually made the conversation easier, not harder. It’s a very clean boundary, and clean boundaries are exactly what auditors like.

Networking: Where I Stopped Guessing and Started Understanding

Networking is usually where platforms fall apart mentally. ROSA was no exception — until I traced the traffic flow end to end.

Here’s the simplified version I keep in my head now:

User → AWS Load Balancer → OpenShift Router → Service → Pod

A few key realizations for me:

• ROSA uses OpenShift Routes, not raw Kubernetes Ingress
• AWS still handles the heavy lifting at the edge
• OpenShift handles how traffic gets to apps inside the cluster

Once I accepted that Routes are just the OpenShift-native way of doing ingress, I stopped fighting it — and it became one of my favorite features.

(We’ll go deep on this in a later part of the series.)

Identity and Access (Less Magic Than It Looks)

At first glance, ROSA IAM + RBAC looks complex.

In reality, I think of it like this:

• AWS IAM decides who can interact with AWS
• OpenShift RBAC decides what users can do inside the cluster

That separation is actually really powerful. It lets platform teams control the platform without stepping on application teams — something I wish more environments did by default.

The Shared Responsibility Model (The Part You Can’t Ignore)

This was another mindset shift for me.

Red Hat owns:

• control plane uptime,
• platform patching,
• Kubernetes upgrades.

I own:

• applications,
• app security,
• configuration,
• access decisions,
• data protection.

Once I stopped assuming “managed” meant “someone else handles everything,” ROSA became very predictable.

And predictable platforms are the ones that scale well.

Why This Architecture Grew on Me

After spending time with ROSA, here’s why I genuinely like this model:

• I don’t waste energy on undifferentiated platform work
• Security boundaries are clear and defensible
• Compliance conversations are simpler
• Platform teams can focus on enablement instead of firefighting

It feels like OpenShift grown up for real-world operations.

No Lab This Time — And That’s Intentional

This part isn’t about clicking buttons or running commands.

It’s about getting the mental model right.

If you understand:

• where things live,
• who owns what,
• how traffic flows,

then everything we do next will feel logical instead of magical.