Designing a Secure Hybrid Cloud Architecture for a Core Banking System on Azure: What Real Enterprise Architecture Actually Looks Like

Most cloud architecture discussions make things sound quite simple. You spin up a few services, put them behind a load balancer, and call it a day.

That illusion disappears very quickly when you step into enterprise systems especially banking.

This is a walkthrough of how a core banking platform built on Oracle FLEXCUBE was deployed in a hybrid Azure environment. It’s the kind of system where cloud infrastructure, on-prem networks, legacy expectations and strict security controls all have to coexist without breaking each other.

Problem Statement

The requirement may seem straightforward on paper: deploy a core banking platform for a new regional operation but in reality, the system needed to satisfy a set of constraints that immediately ruled out a simple cloud-native design.

A bank needed to launch operations in a new region, and that meant deploying a full banking stack not just a web application, but the actual system responsible for holding customer balances, processing transactions, and generating reports. At the center of it all sat FLEXCUBE, broken into three main components: the FCUBS servers, which handle core transaction processing, the OBMA servers, which power digital banking and APIs, and the RPT servers, responsible for reporting and analytics.

In this setup nothing connects directly to the cloud deployment, no public endpoint pointing at a load balancer, no direct internet exposure. Instead, every request passes through the on-premises environment, and only then enters Azure through a VPN.

By the time that traffic reaches Azure, it lands in a centralized hub network where multiple layers of security are waiting. All of these components sit on private IPs ranges completely invisible from the outside world.

This wasn’t just about deploying infrastructure. It was about fitting a modern cloud environment into an already established enterprise ecosystem.

Architecture Overview

At a high level, the system followed a hybrid hub-and-spoke architecture.

On-prem infrastructure remained the control point for ingress. Azure provided the compute and networking layer for the application itself. Between them sat a private connection, ensuring traffic never traversed the public internet.

Within Azure, a Hub VNet handled shared services and security controls, while a Spoke VNet in a separate subscription hosted the application workloads. The database layer extended beyond this boundary, running on dedicated Oracle infrastructure but tightly integrated into the network.

The result was not a single environment, but a distributed system spanning multiple trust zones each with a clearly defined responsibility.

Architecture Diagram

                    On-Prem Network
                           │
                    (ExpressRoute)
                           │
                    ┌───────────────┐
                    │   Hub VNet    │
                    │               │
                    │ Azure Firewall│
                    │ Imperva WAF   │
                    │ F5 Load Balancer (VIP: 10.10.2.20)
                    └───────┬───────┘
                            │
                            │
                    ┌───────▼────────┐
                    │   Spoke VNet    │
                    │                │
                    │  FCUBS Servers │ (10.20.1.10 / .11)
                    │  OBMA Servers  │ (10.20.1.20 / .21)
                    │  RPT Servers   │ (10.20.1.30 / .31)
                    │                │
                    └───────┬────────┘
                            │
                            │
                    ┌───────▼────────┐
                    │ Oracle Database│
                    │ (Exadata / RAC)│
                    └────────────────┘

Key Components

The system is composed of multiple layers, each with a distinct purpose.

At the edge of Azure sits the Imperva Web Application Firewall, responsible for inspecting incoming traffic at the application layer. It enforces security policies before requests are allowed any deeper into the system.

Behind it, the F5 Load Balancer exposes a single internal entry point, something like banking-app.internal.corp (10.10.2.20), and distributes traffic across backend application servers. It continuously evaluates node health and ensures traffic is only sent to healthy instances.

The application tier itself is split into three functional domains. The FCUBS servers handle core transaction processing, the OBMA servers manage digital banking and API interactions, and the RPT servers offload reporting workloads to prevent performance degradation in the transactional layer.

Finally, the database layer runs on Oracle infrastructure, typically as a clustered deployment with replication to a disaster recovery environment. It is isolated, private, and treated as the most critical component in the entire system.

Traffic Flow

Understanding how traffic moves through this system is key to understanding why it is designed this way.

A typical request does not go directly to Azure, but instead originates within the bank’s network or a trusted channel, passes through the on-prem environment, and is then routed into Azure via VPN.

Once inside Azure, the request enters the Hub VNet, where it is processed by the Azure Firewall and inspected by the Imperva WAF. Only after passing those checks does it reach the F5 load balancer.

At that point, the load balancer routes the request to the appropriate backend pool typically the OBMA layer for user-facing requests which then communicates with FCUBS to execute the underlying transaction logic. The FCUBS layer interacts with the Oracle database, commits the transaction, and the response flows back through the same path.

The application subnet hosts multiple servers, but they are not interchangeable. Each group has a very specific role. The FCUBS servers sit at the core, handling the actual business logic of banking. When money moves, when balances change, and when transactions are committed, it happens there. These servers are stateful, sensitive, and absolutely critical. There are at least two of them, typically something like fcubs-app-01 (10.20.1.10) and fcubs-app-02 (10.20.1.11), running in a clustered setup behind the load balancer so that one can fail without bringing the system down.

In front of them sits the OBMA layer (Oracle Banking Mobile & Internet layer). These servers handle user-facing interactions mobile banking, web sessions, and API calls. When a customer logs into their banking app or triggers a transfer, the request first lands on OBMA before being passed down to FCUBS. You might see hosts like obma-app-01 (10.20.1.20) and obma-app-02 (10.20.1.21) quietly handling that orchestration.

Then there are the RPT servers, which exist for a very deliberate reason. Reporting workloads can be heavy, and running them directly against the core system would degrade performance. So reporting is isolated onto its own nodesrpt-app-01 (10.20.1.30) and rpt-app-02 (10.20.1.31)allowing the system to generate audit reports and analytics without interfering with real-time transaction processing.

The database layer adds another dimension entirely.

Rather than running a standard database inside the same environment, the system relies on Oracle Exadata connected into the network. The application servers communicate with it over private IPs, never exposing it externally. A primary database cluster handles live transactions, while a secondary environment stays in sync through DataGuard replication for disaster recovery, ready to take over if needed.

All of these layers sit behind a single entry point: the F5 load balancer.

Externally, everything resolves to a single internal domain, something like:

banking-app.internal.corp → 10.10.2.20

From there, the load balancer distributes traffic across the backend servers, continuously checking their health and removing any node that stops responding. Under normal conditions, this entire process is invisible. Requests flow in, get routed, processed, and returned without anyone thinking about the path they took.

By the time a single request completes, it has traversed multiple layers of validation, routing, and processing each one intentionally placed.

Challenges Faced

One of the more interesting aspects of this deployment was how seemingly unrelated issues manifested.

At one point during deployment, the application behaved in a way that didn’t make immediate sense. Accessing it directly through a server worked perfectly:

https://fcubs-app-01.internal.corp:7102

But going through the load balancer — the actual intended entry point — failed:

https://banking-app.internal.corp:5111

The initial assumption leaned toward a routing or load balancing misconfiguration. In reality, the root cause was a TLS mismatch.

The certificate installed on the servers did not include the load balancer’s fully qualified domain name in its Subject Alternative Name. As a result, when traffic was routed through banking-app.internal.corp, the TLS handshake failed before the request could even reach the application. Updating the certificate resolved the issue instantly, highlighting how trust boundaries can sometimes be mistaken for network problems.

DNS also played a critical role. The load balancer relied on internal name resolution to map the application domain to its virtual IP. Any inconsistency in DNS configuration resulted in failed connectivity, even when all underlying infrastructure was functioning correctly.

Another challenge emerged from application expectations around shared storage. The requirement to maintain a shared /u02 mount across multiple FCUBS nodes introduced a constraint that is uncommon in cloud-native systems but standard in enterprise applications. FLEXCUBE expects certain directories to behave as shared storage because multiple nodes rely on the same files, whether for deployments, batch processing, or report generation.

The solution involved introducing shared storage, typically NFS-backed or something like Azure NetApp Files, and mounting it across both nodes so that /u02 appeared identical from each server’s perspective. Once in place, the cluster behaved as expected, with both nodes operating against the same underlying data.

Even time configuration surfaced as a subtle but impactful issue. Different components in the system were running in different time zones. On the surface, that seems harmless. In practice, it creates inconsistencies that ripple through everything transaction logs, audit trails, and reporting data. Events appear out of order, timestamps don’t align, and debugging becomes unnecessarily difficult.

The fix was simply to standardize everything to a single timezone in this case, something like UTC+0. Once aligned, logs made sense again, and the system behaved predictably.

Lessons Learned

What becomes clear in systems like this is that architecture is less about individual components and more about how they interact.

A load balancer is not just distributing traffic; it becomes part of the application’s identity through DNS and TLS. A certificate is not just a security artifact; it determines whether communication is even possible. Storage is not just persistence; it defines how clustered systems behave. Even time, something often taken for granted, becomes a dependency that can affect data integrity.

Designing in this space requires thinking beyond services and focusing on relationships. Every layer introduces a dependency, and every dependency introduces a potential failure point. The goal is not to eliminate complexity that is rarely possible but to make it intentional, observable, and manageable.

And once you begin to see systems this way, the architecture stops being a collection of parts and starts becoming a system you can reason about end to end.