Delivering Enterprise-Grade OpenShift on AWS

Overview

We recently completed a production deployment of Red Hat OpenShift Service on AWS (ROSA) for a leading banking customer in India. The engagement delivered a fully managed, enterprise-grade Kubernetes platform hosting an OutSystems ODC Self-Hosted application environment — entirely within the customer’s own AWS account.

This wasn’t a lift-and-shift, and it wasn’t a proof-of-concept we could iterate on quietly. It was a greenfield build for a regulated financial services organization, which meant data sovereignty, security posture, and business continuity weren’t nice-to-haves we’d get to eventually — they were the starting point for every decision we made. This post is less a feature list and more a walk through how we actually thought about the problem, what we prioritized, and what we’d tell another team about to do the same thing.

How we deployed a production Red Hat OpenShift cluster on AWS for a banking customer — and what the experience taught us about building security and resilience in from day one.

The Business Context

The customer operates in a heavily regulated corner of Indian financial services, and that shaped almost everything about how this engagement went. Their compliance obligations meant application data and workloads needed to stay within infrastructure they fully controlled, security controls needed to be demonstrable — not just present, but auditable — and disaster recovery couldn’t be an afterthought bolted on after go-live. There also needed to be a clean line between who operates the platform and who deploys applications onto it, which is a distinction that sounds obvious until you’re actually drawing the RBAC boundaries.

Given all of that, the platform choice mattered more than it might for a less regulated workload. We needed something that gave us enterprise support, deep native integration with AWS’s security and identity services, and complete data sovereignty — without asking the customer’s team to become full-time Kubernetes operators in the process. ROSA on AWS was the clearest path to all three at once.

Why ROSA

The appeal of Red Hat OpenShift Service on AWS, once you’ve worked with it, is less about any single feature and more about what it removes from your plate. AWS and Red Hat jointly operate the control plane, which means the customer’s platform team never has to think about etcd health, master node patching, or control-plane upgrades — that operational weight simply isn’t theirs to carry. What they do get is a platform that speaks fluent AWS: IAM, KMS, Secrets Manager, CloudWatch, CloudTrail, and RDS all integrate with the cluster without any bridging layer or custom tooling.

There’s also a commercial angle worth mentioning, because it affects how quickly something like this can actually get approved internally. ROSA bills through the AWS invoice on a consumption basis, so there’s no separate license negotiation slowing things down, and support runs jointly across AWS and Red Hat rather than requiring the customer to juggle two vendors when something goes wrong. And underpinning all of it, the cluster runs entirely inside the customer’s own AWS account — nothing about how it’s managed changes the fact that their data never leaves their control.

Getting Security Right From the Start

We didn’t treat security as a phase to bolt on once the infrastructure was “working.” It was the lens we used to make almost every architectural call, and it shows up in four or five distinct layers that reinforce each other.

Identity was the first thing we got firm about. Every piece of access to AWS resources runs through STS with short-lived credentials — there are no long-lived IAM keys sitting in the cluster or on someone’s laptop waiting to be leaked. Cluster administrative access is federated through the customer’s own identity provider over SAML/OIDC, which meant platform access could ride on the same joiner-mover-leaver processes the rest of the organization already trusted, rather than inventing a parallel process just for this platform. Inside OpenShift itself, RBAC adds a second layer that governs who can touch which namespaces and workloads, and cluster-admin rights are held by a small, named group with break-glass controls rather than being something anyone on the team could reach for casually.

Network isolation followed a similar philosophy of keeping the blast radius small. The cluster sits inside its own VPC with a clean three-tier layout — public subnets hold nothing but the load balancer and NAT gateways, private application subnets hold every worker node with no public IPs at all, and the database subnets are isolated even from the application tier, reachable only from the specific worker security group. Spreading worker nodes across three Availability Zones, and giving each AZ its own NAT gateway rather than sharing one, meant that losing an entire zone would degrade capacity rather than take the platform down — a distinction that matters a lot more in a regulated environment than it might elsewhere.

Encryption was non-negotiable throughout, and we used customer-managed KMS keys everywhere rather than relying on AWS-managed defaults, specifically so the customer retains full control over key policies and rotation. That covers etcd at the cluster level, EBS volumes on every worker node, and RDS storage, all under the same key. Credentials never touch plaintext anywhere in the system — application and database secrets live in Secrets Manager, encrypted with that same key, and TLS 1.2+ is enforced on everything entering the cluster through the load balancer.

None of that matters much without a way to prove it’s actually happening, which is where audit comes in. CloudTrail captures every API call across the account, VPC Flow Logs capture everything at the network level, and OpenShift’s own audit logs flow into CloudWatch alongside them. Together with CloudWatch alarms and SNS notifications routing anything unusual to the operations team, this gives the customer’s compliance function a genuinely complete, tamper-evident record — not a partial one they’d have to supplement later during an audit.

The last piece of the security picture lives inside the cluster itself, where applications are separated by namespace, each with its own resource quotas, network policies, and RBAC boundaries. Pod-to-pod communication is explicit rather than assumed, so if one application were ever compromised, its ability to reach anything else running on the same cluster is genuinely contained rather than theoretically contained.

Building for the Day Something Goes Wrong

For a platform supporting a regulated financial workload, we couldn’t treat disaster recovery as something to figure out later. It needed to be a real, tested capability from the outset, and the design centers on cross-region database replication as the core of that story.

The primary RDS PostgreSQL database lives in AWS Mumbai, and we maintain an asynchronous cross-region read replica in Hyderabad that typically stays within a few seconds of the primary under normal conditions. If Mumbai ever became unavailable, that replica can be promoted to a standalone primary, giving the customer a genuinely documented recovery path — an RPO measured in seconds, and an RTO aligned to what their business actually needs rather than what happened to be convenient to build. We didn’t want DR readiness to be an assumption sitting untested in a document somewhere, so replica lag is continuously monitored through CloudWatch, with alarms that would catch it drifting before it became a real problem.

Replication alone doesn’t protect against everything, though — it won’t save you from a bad deployment that corrupts data, or a mistaken delete that propagates to the replica before anyone notices. That’s what the backup layer is for: automated backups with 35-day retention give point-in-time recovery to any moment in that window, manual snapshots get taken before anything risky like a major deployment or upgrade, and AWS Backup orchestrates both RDS and EBS backups against retention policies the customer’s team actually defined rather than defaults we assumed were fine.

Underneath both of those sits the resilience of the cluster itself within the primary region — worker nodes spread across three AZs, NAT gateways per zone, and the load balancer routing across whatever’s healthy. Stack all three together and you get resilience at every scale that matters: a node failing is something OpenShift’s scheduler handles without anyone noticing, an AZ failing is something the multi-AZ architecture absorbs, and a full regional failure is something the Hyderabad replica exists specifically to answer.

Making Deployment Something You Can Trust

A platform without a real delivery pipeline behind it tends to become a platform people are afraid to touch, which defeats half the point of building it well in the first place. So alongside the infrastructure, we put a CI/CD pipeline in place that governs how anything actually reaches the cluster.

Everything — application code and platform manifests alike — lives in source-controlled Git repositories, and nothing goes to production without moving through the pipeline first. Code comes in on commit or merge, gets built into container images that are tagged and scanned for known vulnerabilities before they ever reach a registry, runs through automated tests and policy checks, and only then gets deployed using GitOps-style declarative manifests. Even after deployment, health checks run automatically to confirm the application actually came up correctly before the pipeline calls the job done.

The governance built into that pipeline was as much about matching the customer’s existing change management culture as it was about good engineering practice. Production deployments require a manual approval gate, so promotion is always a deliberate act by someone authorized to make it. If a deployment fails its health checks, rollback happens automatically rather than waiting for someone to notice something’s wrong. Every deployment leaves a full audit trail — who approved it, what went out, when — and every image is scanned before it’s allowed to run and signed so that only artifacts the pipeline itself produced can ever be deployed. Taken together, that’s a deployment process that’s auditable and repeatable by construction, which is exactly the kind of operational maturity a regulated financial institution needs to see.

What It Actually Delivers

Step back from the mechanics and the outcomes are fairly concrete. The architecture directly supports the customer’s data sovereignty, encryption, audit, and DR obligations under Indian financial regulation, and every control we put in place has a clear reason for existing rather than being there because it seemed like good practice in the abstract. The customer isn’t inheriting a platform they’ll need to harden later — security, DR, monitoring, and CI/CD were all live before the first application was deployed onto it, which is a meaningfully different starting position than most teams get.

The platform is also built to grow rather than to be replaced. ROSA scales horizontally, so additional applications, additional worker nodes, and additional environments are additions to the existing design rather than reasons to redesign it — which matters because this is meant to be infrastructure the customer builds on for years, not months. The fully managed control plane and joint AWS/Red Hat support mean their team spends its time on their applications rather than firefighting the platform underneath them, and the consumption-based billing model means scaling the platform is a business decision made with clear cost visibility, not a procurement event that has to be planned around months in advance.

What We’d Tell Another Team Doing This

A handful of things stood out enough during this engagement that we think they’re worth carrying forward.

The first is that compliance-driven architecture gets a lot easier when the platform you’re building on actually supports it natively. Because ROSA integrates so tightly with IAM, KMS, and CloudTrail, most of what the customer’s compliance team needed turned out to be something we could configure rather than something we had to build custom tooling for. That’s a real, practical advantage of choosing managed services for regulated workloads, and it’s easy to undervalue until you’ve felt the difference.

The second is that disaster recovery has to be a decision you make at the start, not a feature you retrofit later. The cross-region replica, the backup strategy, and the multi-AZ layout were all part of how we designed this from day one, not additions after the fact — and it’s dramatically cheaper and more reliable to build it that way than to try bolting real DR onto a platform that’s already live and serving traffic.

The third is that a CI/CD pipeline with real governance built in pays for itself almost immediately, and not just from a compliance standpoint. The same controls that satisfy an auditor — approval gates, full audit trails, automated rollback — are the same controls that make day-to-day deployments faster and safer for the team actually doing them. We went in assuming there’d be some tension between compliance and velocity, and mostly found there wasn’t.

And the broader lesson, which feels true well beyond this one engagement, is that the hard part of enterprise cloud work today isn’t standing up infrastructure — that part is comparatively easy now. The hard part is aligning identity, security, audit, and operational process across an organization that already has its own way of doing things, and making sure the platform respects that rather than fighting it. That’s where we think experienced delivery teams earn their keep, and it’s the part of this project we’re most proud of getting right.

Where This Goes Next

The platform is live now, carrying real business workloads for the customer, and the architecture is built to absorb whatever comes next — more applications, more environments, evolving compliance requirements — without needing to be rethought from scratch. For us, this engagement reinforced something we already believed going in: the cloud deployments that matter most are the ones still delivering value years after go-live, and that only happens when the fundamentals — security, resilience, operational discipline, and genuine fit with how the customer’s organization actually works — are right from the beginning rather than something you go back and fix.

We’re proud of what came out of this one, and we’re already carrying what we learned into the next engagement in this space.

Closing Reflection

Enterprise cloud platforms are no longer just about scalability—they must deliver security, resilience, and operational confidence from day one. The real challenge is not deploying OpenShift on AWS, but engineering a platform that meets evolving business and compliance demands without compromising agility. Organizations that get this right will accelerate innovation while building a secure foundation for long-term growth.

Ready to modernize your enterprise platform on AWS? Contact us today

Date: 10/07/2026  :   Written by –