ECS vs ROSA

At a Glance

This is the pattern behind a real decision, generalised for publication: a bank running OpenShift on-premises evaluates ROSA as the obvious next step in a cloud migration, then reconsiders in favour of ECS. What follows is not an argument that ROSA is wrong. It's the decision record a Design Authority would actually want to see: what each option costs, what it demands operationally, what it means for a regulated institution's third-party risk posture, and what gets traded away either way.

Context

OpenShift's appeal to a regulated bank was never really "Kubernetes." It's a bundle of compliance-adjacent defaults: Security Context Constraints enforcing non-root execution by default, integrated RBAC and OAuth against existing LDAP/AD/SAML, built-in image scanning via Quay, all layered on an existing Red Hat enterprise support relationship that lowers procurement and security-review friction. Add a hybrid-cloud narrative that resonates with a regulatory environment openly uncomfortable with single-cloud dependency, and on-premises OpenShift is a coherent, defensible choice, not an accident of history.

When that same bank moves to AWS, ROSA is the path of least resistance by design: the same manifests, Operators, RBAC model, and Helm-based tooling carry over, jointly operated by Red Hat and AWS under a single AWS invoice. The question this article works through is what happens when that default gets scrutinised against a workload that may not need everything OpenShift provides, priced against an AWS-native alternative, and read against where banking regulation is actually heading.

Options Considered

A. Stay on-premises

No migration risk, existing compliance sign-off, the existing Red Hat relationship intact. But it doesn't achieve the migration's actual objectives (elasticity, data-centre exit, the shift from capex to opex), and on-premises OpenShift's own cost and complexity trajectory doesn't stand still while the bank waits. Absa's own experience, covered below, shows that trajectory in public.

B. ROSA

Near-zero re-platforming effort. Joint Red Hat and AWS operational model with a 99.95% SLA. Retains OpenShift's SCC, OAuth, and Quay-based compliance tooling. Available in af-south-1 since February 2022, both Classic and Hosted Control Plane. Set against that: a two-part cost structure (AWS infrastructure plus a Red Hat per-vCPU service fee, roughly $0.171/hr per 4 vCPU worker plus an optional $0.25/hr cluster fee), a managed control plane that removes infrastructure toil but not Kubernetes-specific toil (Operator lifecycle, RBAC and SCC configuration, upgrade cadence), and a second critical ICT vendor entering the bank's third-party risk register alongside AWS.

C. EKS, the unexamined middle option

Worth naming even though it wasn't the live choice in this case: EKS keeps the Kubernetes API and CNCF ecosystem while dropping Red Hat's licensing layer, at a lower flat control-plane fee than ROSA's per-vCPU model. It also drops OpenShift's SCC, OAuth, and Quay-scanning defaults, which would need rebuilding from separate components (OPA/Gatekeeper, image scanning, IRSA) rather than inherited from the platform. Still a genuine re-platforming effort away from OpenShift-specific constructs, and still the full Kubernetes operational surface. A real option; not examined further here because it wasn't the one this case study's decision was actually between.

D. ECS: the option chosen

Single AWS vendor, single bill, single support relationship. No control-plane licensing fee. Native IAM Task Roles remove the IAM-to-Kubernetes-RBAC mapping layer entirely; native awsvpc networking gives every task a real ENI with no CNI overlay; ALB and NLB integration is native. Real migrations cite this directly: In The Pocket moved off Kubernetes to ECS/Fargate citing Helm-maintenance fatigue and a cheaper first invoice. Capital One and AQR Capital Management both run ECS/Fargate as AWS-native compute after their own data-centre exits. What it costs: no Kubernetes API compatibility, a narrower ecosystem with no Helm or Operator equivalent, and compliance tooling that has to be assembled from separate AWS-native services rather than inherited from the platform.

Networking Architecture

The diagram above compresses a real planning exercise into four boxes. Each layer on both paths was, or will need to be, deliberately designed, not inherited for free, and a Design Authority should expect to see that design made explicit before either path is signed off.

ROSA clusters run inside a bank's own VPC, not an AWS-managed one, which means the networking underneath it is real infrastructure someone has to plan. Three CIDR ranges have to be sized and coordinated together: the Machine CIDR for worker nodes, the Service CIDR for internal Kubernetes service IPs, and the Pod CIDR for the OVN-Kubernetes overlay pods actually run on. None of the three can overlap each other, and none can overlap on-premises ranges or any other VPC in the hybrid path, or routing breaks in ways that are painful to diagnose after the fact. For a bank specifically, the private-only ("PrivateLink") cluster configuration is the one worth confirming directly: API server and application ingress reachable only via private connectivity, never the public internet, consistent with a no-internet-exposure posture a regulated institution would typically require. Ingress itself runs through the OpenShift Router (HAProxy) behind an AWS load balancer, with Routes mapping hostnames to internal services, the layer that most directly hands off to whatever fronts the bank's traffic today.

ECS's networking model asks a different, and in some ways simpler, set of questions, but they are not fewer questions. Task networking mode awsvpc gives every task its own ENI with a real private IP drawn straight from the VPC subnet, not from a separate overlay network the way pods are on the ROSA path. That is a materially different IP consumption pattern: subnets sized around a Pod CIDR's overlay addressing need to be re-checked against ECS's one-real-IP-per-task model, not assumed to carry over. Security groups apply per task or service, replacing whatever NetworkPolicies and Security Context Constraints currently express as internal segmentation, a genuine mapping exercise from one model to the other rather than an automatic translation. Service discovery moves to AWS Cloud Map or ECS Service Connect in place of the cluster's internal CoreDNS, and any PrivateLink posture carried over from ROSA needs equivalent VPC endpoints stood up for ECS itself and any AWS services in its path.

The layer most likely to get underestimated sits above both platforms: whatever already handles load balancing and DNS-based traffic steering for the on-premises estate, commonly an F5 BIG-IP deployment in a banking environment, local load balancing paired with global, DNS-based traffic management. Migrating the platform underneath does not resolve what happens to that layer. It stays as the front door with AWS load balancing behind it, it gets retired in favour of ALB or NLB, or it runs in a deliberately hybrid state during transition, and that is a decision a Design Authority should see made explicitly rather than left to default. Two things commonly complicate whichever choice is made. Custom logic layered onto existing virtual servers, header rewriting, custom health checks, client-IP preservation, SSL offload and re-encryption, has no automatic equivalent in ALB listener rules and needs a deliberate inventory before it can be safely retired. And whether a given client connects via a resolved hostname or a specific IP address is often a direct consequence of how that global traffic management layer was configured for it historically, which matters more than it looks: hostname-based clients can be migrated by changing what the name resolves to, invisibly to them, while IP-pinned clients cannot move without direct coordination, since the backend changing breaks them immediately with no graceful transition. In practice this is rarely a clean list. It is a partner integration configured against a hardcoded IP three system owners ago, a batch job on a schedule nobody watches, a firewall rule written before anyone thought to ask why. Finding them means reading connection logs, not asking people to remember.

A platform migration plan that doesn't first know which of its clients connect by IP and which by hostname isn't ready to commit to a cutover strategy yet, regardless of how sound the orchestrator decision underneath it is.

A Regional Precedent: Absa

The underlying complaint, that OpenShift's cost and operational burden climb over time independent of any cloud decision, isn't hypothetical. Absa's own published account describes exactly this: by late 2018, its OpenShift environment had become difficult to manage and costs had started climbing, driven by a mega-cluster approach hitting scaling limits. Absa evaluated the market and moved to Rancher, reporting management costs down 75%, management time down 80%, and platform stability up 80%.

Absa's destination was Rancher, still a Kubernetes distribution, not ECS or another AWS-native orchestrator. This isn't direct evidence for the ROSA-to-ECS move specifically. It's strong, named, regional evidence that the OpenShift cost and complexity problem this article is built around is real and has already happened at a major South African bank. Source: Absa: Driving Scale and Innovation in African Banking, a SUSE-published customer case study.

Reconsidering ROSA: Three Forces

Cost

An illustrative model at 200 vCPU / ~400GB, roughly a mid-size banking division running 50–100 services, puts ROSA at approximately $164,500/year against roughly $86,500–$87,400/year for ECS on EC2 or Fargate, built from published unit pricing. The Red Hat service fee alone is close to the size of the underlying compute bill, nearly doubling the effective cost of running the identical footprint: a gap on that order is close to the fully-loaded annual cost of a senior platform engineer, money now spent on a licensing layer instead of the team that would otherwise absorb the operational load it's meant to remove. This likely understates the real gap: CNCF's own FinOps survey found Kubernetes clusters average only 10% CPU and 20% memory utilisation in practice, and 49% of enterprises reported cost increases specifically after Kubernetes adoption. Neither number is ROSA-specific, but neither improves on a platform charging by the vCPU-hour for capacity that's sitting idle four-fifths of the time.

Operational complexity that "managed" doesn't remove

A managed control plane removes infrastructure toil, not Kubernetes-specific toil. Red Hat's own 2025/2026 fleet management report found 62% of organisations say Kubernetes complexity is actively slowing business initiatives, 59% report skills gaps, and only 13% report fully automated cluster upgrades. That distinction is easy to lose in a sales conversation: "managed" describes who patches the control plane, not who reconciles a stuck Operator lifecycle at 2am or resolves an RBAC binding that's quietly blocking a deploy. ECS abstracts the scheduling layer entirely: task definitions and services, no pods, RBAC, or network policies to hand-manage.

Layers that exist only to make Kubernetes work on AWS

The CNI overlay and the IAM-to-RBAC mapping shown in the diagram above don't serve a banking requirement. They exist because Kubernetes needs them to run inside AWS's own network fabric. ECS's native awsvpc mode and IAM Task Roles remove both, not by cutting a corner, but because the platform was built inside AWS's model rather than layered on top of it.

The Regulatory Lens

Two-vendor arrangements like ROSA aren't just an operational question for a bank. Red Hat operates the managed control plane; that control plane is itself materially dependent on AWS infrastructure underneath. The EBA's Guidelines on Outsourcing Arrangements define exactly this structure as chain, or sub-outsourcing: where a contracted service provider itself relies significantly on another provider for the service it delivers. That classification isn't academic. It requires the bank to secure contractual flow-down of audit rights, security obligations, and termination rights through the full chain, not just with the provider it directly contracts.

The broader regulatory direction points the same way. The Basel Committee's third-party risk principles (finalised in 2025) name concentration risk and systemic impact from disruption at critical providers as governance considerations banks must build into their frameworks. The ECB reports 30% of significant EU banks' outsourcing budgets concentrated on just ten providers, and named outsourcing concentration a 2025 supervisory priority. US interagency guidance from the OCC, Federal Reserve, and FDIC explicitly notes banks may have limited negotiating leverage in concentrated provider markets, cloud computing named directly.

For a South African bank specifically, this needs a precise framing. SARB's existing regime, Directive 3/2018 and Guidance Note 5/2018, is risk-based and principles-based. It does not yet contain DORA-style prescriptive rules about provider count. SARB's March 2025 consultation paper on cloud computing and data offshoring explicitly names concentration risk as a driver for a new framework, and the FSCA and Prudential Authority are jointly developing a Cloud Computing and Data Offshoring Joint Standard, but as of this research neither publication timing nor scope has been settled. The accurate statement for a South African Design Authority is that regulation is moving this direction, evidenced by the EU, Basel, and US positions, and that SARB has signalled it's watching the same risk, not that SARB currently mandates a single-vendor architecture.

POPIA adds a further, more concrete point: a cloud provider is an "operator" under POPIA, and the bank as "responsible party" retains the obligation to ensure that operator maintains adequate security. A ROSA deployment puts Red Hat's SREs in a position of operational access to the managed control plane, which reasonably expands the bank's operator-oversight and contractual-assurance obligations relative to an AWS-only ECS deployment where AWS is the sole operator in the chain.

Regional Realities: af-south-1 and Hybrid Costs

A Design Authority needs to know what's actually available before approving either path. ECS, EKS, App Mesh, X-Ray, ECR, Inspector, ACM Private CA, Config, and VPC Lattice are all confirmed present in af-south-1. ROSA has been available since February 2022. One genuine, currently live gap sits outside the orchestrator question entirely: Amazon Managed Grafana is not available in af-south-1, one of only twelve regions globally where it runs. Amazon Managed Prometheus reached af-south-1 in June 2025, so metrics storage can stay in-region, but the visualisation and alerting layer typically paired with it cannot, without either a cross-region call to Frankfurt, Ireland, or London, or self-hosting Grafana in-region and taking back the operational burden this whole decision is trying to reduce. That constraint applies regardless of whether the platform underneath is ROSA or ECS.

On data transfer: internet egress out of af-south-1 runs $0.154/GB, roughly 70% above the standard $0.09/GB US and EU baseline, a real premium worth sizing explicitly for a hybrid architecture with sustained on-premises-to-cloud sync. AWS Direct Connect is physically present via Teraco's CT1 facility in Cape Town, with a 100 Gbps expansion completed in August 2025, and Direct Connect pricing generally runs below internet egress for comparable routes. An illustrative 1TB/day sustained replication load (core banking or customer-record synchronisation, stated here as an assumption, not a researched figure) costs roughly $56,000/year over the public internet at the af-south-1 rate, or an estimated $42,000/year over Direct Connect at a conservative discount. That's a real, recurring line item a Design Authority should size on its own merits rather than treat as background noise.

Whether it differs between ROSA and ECS: no, not for this boundary-crossing cost. AWS meters data transfer at the network boundary, the VPC internet gateway or Direct Connect interface, based on where bytes cross it, not which orchestrator sent them. Identical replication volume over an identical path costs the same regardless of what sits on the AWS side. Where a real difference exists is inside the cluster: Istio's own benchmarks put a single service mesh sidecar at roughly 0.2 vCPU and 60MB of memory, a genuine, additive compute cost that OpenShift Service Mesh carries and ECS's native networking doesn't, reserved per service instance, all the time. That's a compute story, not a bandwidth story, and it's real either way.

What Gets Traded Away

A credible decision record doesn't hide the cost of its own recommendation. Moving to ECS means giving up Kubernetes API compatibility and the CNCF ecosystem's breadth: no Helm, no Operators, a narrower third-party tooling market. It means rebuilding OpenShift's SCC, OAuth, and Quay-scanning compliance bundle from separate AWS-native services rather than inheriting it from the platform. And it means accepting a materially less mature service mesh story at exactly the point of decision: AWS is retiring App Mesh in September 2026, and its replacement, ECS Service Connect, doesn't natively provide the default mutual-TLS-everywhere posture that OpenShift Service Mesh ships with out of the box. Achieving equivalent zero-trust networking on ECS means composing IAM, a private certificate authority, and sidecar-based TLS manually: standing up AWS Private CA, issuing and rotating certificates per task, injecting a sidecar proxy into every task definition, and maintaining that pipeline as a piece of infrastructure the platform team now owns rather than inherits, or adopting a self-managed mesh, which reintroduces some of the operational load ECS was chosen to avoid.

This is the clearest concrete cost in the whole comparison, and it belongs in the record, not buried under the numbers that favour the recommendation.

Decision Framework

Consequences

Choosing ECS over ROSA is a right-sizing decision, not a downgrade, when the workload profile supports it. The bank gains a single AWS vendor and billing relationship, removal of a licensing fee that roughly doubles compute cost at the illustrative scale modelled above, deeper native integration with IAM and VPC networking, and a regulatory posture more defensible under where third-party risk oversight is heading globally, even without SARB currently mandating it. It gives up Kubernetes portability that the evidence suggests was already largely illusory in practice, ecosystem breadth it may never fully use, and a service mesh story that is genuinely, currently less mature than what OpenShift ships by default. Both of those are real trade-offs. Neither is a reason to default to the familiar option without running the numbers first.

This is a generalised pattern drawn from real architecture decisions, not a specific institution's confidential position. It reflects the kind of cloud architecture and regulatory-aware engineering work behind ByTheodore's consulting practice.