Running financial workloads in the cloud is fundamentally different from hosting typical enterprise or consumer applications. Availability is non-negotiable. Security must be engineered into every layer. Compliance is continuous, not a milestone. And failures - whether technical or operational - carry real financial, legal, and reputational consequences.

This series explores what it actually takes to run production-grade financial workloads on Microsoft Azure.

This series is divided into three parts, each focusing on a distinct layer of responsibility in a financial platform.

Part 1 establishes the secure foundation. It covers how internet-facing traffic enters the platform, how global and regional security controls are applied, and how private network boundaries are enforced. Topics include secure ingress, Web Application Firewall layers, network isolation, identity foundations, and baseline security monitoring.

Part 2 moves deeper into the platform, focusing on how financial systems actually process work. It explores containerized business logic, transaction processing, asynchronous messaging, authoritative data stores, caching strategies, and secure integration with on-premises or legacy core systems.

Part 3 addresses what happens after deployment. It covers high availability and disaster recovery, observability and incident response, cost governance, operational discipline, and the controls required to pass audits and operate continuously in regulated environments.

Together, these three parts form a cohesive blueprint for designing, operating, and evolving secure, resilient financial platforms on Azure - reflecting how such systems are built, reviewed, and run in the real world.

This series is written for cloud architects, senior engineers, and technology leaders responsible for financial workloads on Azure. It assumes familiarity with Azure fundamentals and focuses on architectural reasoning rather than step-by-step implementation.

Whether you’re modernizing an existing platform or designing a new one from first principles, the objective is simple: build systems that customers can trust, regulators can approve, and operations teams can run with confidence.

Before diving into architecture and design patterns, it’s worth addressing a fundamental question: why would a bank choose Azure in the first place?

Banking workloads operate under a different set of rules. Regulatory compliance is mandatory, not negotiable. Customers expect their banking applications to work flawlessly at 3 AM on a Sunday, just as they do during a weekday lunch rush. Security must be designed in from day one. And perhaps most importantly, modern digital platforms must integrate with decades-old core banking systems that are not going away anytime soon.

Microsoft Azure aligns well with these realities through a combination of scale, governance, and enterprise-grade capabilities.

Compliance-ready foundation
Azure maintains a broad set of certifications, including PCI DSS, ISO 27001, SOC 1/2/3, and multiple regional banking standards. While banks remain responsible for application-level and operational compliance, starting with a certified infrastructure foundation significantly reduces audit effort and accelerates regulatory readiness.

Global footprint with data residency control
With data centers across more than 70 regions worldwide, Azure enables banks to meet strict data residency and sovereignty requirements. When regulators mandate that customer data must remain within national boundaries - such as French customer data staying in France - Azure’s regional isolation makes this achievable without architectural contortions.

Enterprise-grade support and SLAs
Banking systems don’t fail conveniently. Azure offers 24/7 enterprise support with committed response times, which is critical when a production outage occurs in the middle of the night. For regulated, revenue-critical platforms, rapid access to senior support engineers is not a luxury - it’s operationally essential.

First-class hybrid capabilities
Most banks cannot migrate everything to the cloud in one move. Core banking systems, mainframes, and specialized platforms often remain on-premises for years. Azure’s hybrid capabilities support gradual modernization, allowing cloud-native digital channels to coexist securely with on-premises systems without forcing an all-or-nothing migration.

Let’s build this step by step, starting with a high-level view of what a production-grade banking website looks like when designed and operated on Azure.

This diagram illustrates the core components and trust boundaries of the architecture. Once traffic passes through Application Gateway, all services operate exclusively on private IPs inside the Virtual Network, with no direct public exposure.

When a customer opens a banking app or navigates to the bank’s website, their request doesn’t go straight to an application server in a data center. It first enters the platform through Azure Front Door - the global entry point for all web traffic.

Think of Front Door as the reception desk of a highly secure office building. Every visitor arrives here first. Requests are inspected, routed to the correct location, and flagged if anything looks suspicious. Only then are they allowed to proceed further into the building. Front Door performs this role at a global scale for banking traffic.

At a high level, Front Door is responsible for:

Global load balancing
Banking customers are geographically distributed, and latency directly impacts user experience. Front Door routes each request to the nearest healthy Azure region. A customer in Singapore is served from Southeast Asia, while a customer in New York connects to East US. This proximity-based routing minimizes latency and improves responsiveness.

SSL termination at the edge
TLS encryption and decryption are computationally expensive. Front Door terminates HTTPS connections at the edge, offloading cryptographic work from backend services. This allows application servers to focus on business logic rather than encryption overhead, while still maintaining end-to-end security.

Edge caching for static content
Static assets such as images, CSS files, and JavaScript bundles are cached at edge locations worldwide. When customers load the banking website, these assets are delivered from a nearby edge cache instead of crossing continents. The result is faster page loads and reduced load on backend systems.

Layered DDoS protection
Front Door benefits from Azure’s platform-level DDoS protection at the edge, primarily mitigating Layer 7 (application-layer) attacks such as HTTP floods and malicious request patterns. For volumetric Layer 3/4 attacks targeting virtual networks, banks typically complement this with Azure DDoS Network Protection. Together, these layers provide defense both at the global edge and within the network infrastructure.

In short, Azure Front Door provides a globally distributed, resilient, and secure entry point - ensuring banking websites remain fast, available, and protected for customers worldwide, regardless of where they connect from.

A Web Application Firewall (WAF) is enforced at two critical points in the architecture, creating layered protection from the global edge down to the regional network boundary.

WAF is enabled directly on Azure Front Door, inspecting incoming requests before they enter any Azure region. At this stage, obvious malicious traffic - such as SQL injection attempts, cross-site scripting payloads, and bot-driven attacks - is blocked early, preventing unnecessary load on regional infrastructure.

This edge-level inspection is particularly important for banking platforms, where even rejected traffic can translate into cost, latency, or operational noise if allowed to propagate deeper into the system.

The second - and more authoritative - layer of enforcement occurs at Azure Application Gateway with WAF v2, deployed on a private IP address within the regional Virtual Network.

In production banking environments, traffic flows from Front Door to Application Gateway over Microsoft’s private backbone. Application Gateway marks the transition from public ingress to private network. Once traffic passes this point, it never leaves the private network boundary.

The typical request flow looks like this:

Customer → Front Door (public, global) → Application Gateway (private IP, regional) → App Service (VNet integrated, private)

This design ensures that Azure App Service has no public endpoint. It is reachable only through Application Gateway, which enforces centralized security policies inside the Virtual Network.

At both layers, WAF inspects every request for known attack patterns, including:

WAF relies on managed rule sets that Microsoft updates regularly. When new vulnerabilities are discovered in common frameworks or libraries, updated detection rules are pushed automatically - providing protection against emerging threats without requiring manual intervention.

In addition to managed rules, banks typically define custom WAF rules to reflect business context. For example:

Once a request has passed through Front Door, Application Gateway, and WAF, it reaches the application layer. This is where real banking interactions are processed - checking balances, transferring funds, paying bills, and managing accounts.

This layer is deliberately designed to balance security, scalability, and operational simplicity, especially for internet-facing workloads.

The web frontend - what customers interact with through their browsers - typically runs on Azure App Service. App Service is a fully managed platform for hosting web applications without the burden of managing servers, operating systems, or patching cycles.

Think of it as renting an apartment instead of building a house. Microsoft handles the plumbing (server maintenance), electrical work (OS patching), and foundation (infrastructure availability). Development teams focus on application logic and customer experience rather than keeping servers alive.

In production banking environments, it’s common - and intentional - to separate the web frontend on App Service from backend microservices running on Azure Kubernetes Service.

This separation provides several benefits:

App Service is optimized for externally exposed workloads, while AKS is reserved for internal, tightly controlled services. This clear separation of concerns creates strong boundaries between public-facing components and sensitive backend systems.

A critical configuration detail in banking architectures is how App Service connects to downstream services.

App Service uses VNet Integration to access backend resources such as API Management, databases, and messaging services over private IP addresses. Traffic never traverses the public internet.

Just as importantly, the App Service itself has no public inbound endpoint. It accepts traffic only from Application Gateway inside the Virtual Network. This ensures that all inbound access is centrally inspected, logged, and controlled.

Auto-scaling
Banking traffic is highly variable - month-end bill payments, salary days, or regulatory deadlines can cause sudden spikes. App Service automatically scales out when thresholds such as CPU usage or request queue depth are exceeded, then scales back down when demand subsides. This maintains performance while controlling costs.

Deployment slots
New releases are deployed to a staging slot, tested in a production-like environment, and then swapped into production with zero downtime. If issues arise, rollback is immediate. This is critical for banking systems where failed deployments directly impact customers.

Built-in authentication
App Service integrates natively with Microsoft Entra ID, as well as other identity providers. Offloading authentication reduces custom security code and ensures consistent, centrally managed identity enforcement.

Always-on availability
Banking applications cannot afford cold starts. The Always On feature keeps applications warm and responsive 24/7, ensuring consistent performance even during low-traffic periods.

Modern banking platforms are not built as single monolithic applications. Instead, functionality is exposed through APIs (Application Programming Interfaces) that are consumed by web frontends, mobile apps, partner integrations, and internal systems.

Azure API Management sits in front of these APIs and acts as the central traffic controller. In production banking environments, API Management is typically deployed in internal mode within the Virtual Network, reachable only via private IP addresses. External access is routed through Application Gateway, ensuring all API traffic remains within controlled network boundaries.

The modern deployment model uses API Management v2 tiers - Standard v2 or Premium v2 - which offer improved VNet integration, better performance, and more flexible scaling compared to the legacy tiers.

The choice of tier is not just a cost decision - it directly impacts resilience, scalability, and regulatory posture.

API Management enforces authentication and authorization consistently across all APIs. It can validate JWT tokens, enforce API keys, and integrate with OAuth 2.0 flows backed by Microsoft Entra ID. Every API call is verified before it reaches backend services, reducing the risk of unauthorized access.

To protect backend systems, API Management applies rate limits and quotas. For example, a consumer mobile app might be limited to 1,000 requests per hour, while internal systems are granted higher thresholds. This prevents both malicious abuse and accidental overload caused by poorly designed integrations.

API consumers and backend services often evolve at different speeds. API Management can transform requests and responses on the fly - converting XML to JSON, adding or removing headers, or reshaping payloads - without forcing changes on either side.

Every API call is logged and measured. Operations teams gain visibility into usage patterns, response times, error rates, and failure trends. This telemetry is invaluable for troubleshooting incidents, identifying performance bottlenecks, and planning future capacity.

Banking APIs evolve, but breaking changes are unacceptable. API Management supports running multiple API versions in parallel. Older mobile apps can continue using v1 endpoints while newer clients adopt v2, allowing controlled, non-disruptive evolution of services.

The Standard v2 tier uses consumption-based pricing and is well suited for single-region or moderate-scale workloads, while Premium v2 is designed for mission-critical, multi-region banking platforms with higher availability and resilience requirements.

A critical aspect of any banking architecture - and one that deserves explicit attention - is network isolation. In a production banking environment, all backend services must operate within private networks, with no direct exposure to the public internet. Public access is tightly controlled and terminates at well-defined ingress points only.

This approach significantly reduces attack surface and enforces clear trust boundaries across the platform.

Core platform services such as databases and storage must never be publicly reachable. Services like Azure SQL Database, Azure Storage, and Azure Cosmos DB should be accessed exclusively via private endpoints.

Private endpoints assign these services private IP addresses within the bank’s Virtual Network, ensuring traffic flows entirely over the private network and never traverses the public internet.

Application services such as Azure App Service and Azure Functions use VNet Integration to communicate with backend systems over private IP addresses. This eliminates reliance on public service endpoints and enforces consistent, network-level isolation for all east–west traffic.

In banking deployments, Azure API Management is typically deployed in internal mode, exposing only a private IP address within the Virtual Network. External clients never connect to API Management directly. Instead, inbound traffic flows through Application Gateway, which handles public-to-private routing, inspection, and enforcement.

This ensures APIs remain fully private while still supporting secure external consumption.

Backend microservices running on Azure Kubernetes Service are exposed only through internal load balancers. These load balancers have no public IP addresses and are reachable exclusively from within the Virtual Network.

As a result, Kubernetes services cannot be accessed directly from the internet, even if misconfigured at the application layer.

Network Security Groups (NSGs) enforce fine-grained traffic rules between subnets and services. For example:

These controls ensure that each component communicates strictly on a need-to-know basis.

Banking applications require security at every layer. This approach - known as defense in depth - assumes that any single control can fail. Real security comes from overlapping protections, where the failure of one layer is contained and mitigated by others.

In regulated financial environments, identity and secrets management form two of the most critical security pillars.

Microsoft Entra ID provides centralized authentication and authorization across the platform. Instead of each application managing its own users and credentials, identity is enforced consistently at the platform level.

For bank employees and operators, Entra ID enables:

For customer-facing applications, Entra ID for customers (formerly Azure AD B2C) manages authentication flows. It supports:

This allows banks to provide secure, user-friendly authentication experiences without building and maintaining custom identity platforms.

Applications require secrets - database credentials, API keys, certificates, and encryption keys. Storing these in source code or configuration files creates unacceptable risk. If the codebase is compromised, all secrets are exposed.

Azure Key Vault provides centralized, secure storage for sensitive material, including:

Applications retrieve secrets from Key Vault at runtime, not at deployment time. Access is controlled using Entra ID, ensuring that only explicitly authorized applications and identities can read specific secrets. Every access attempt is logged for auditability.

Key Vault now uses role-based access control (RBAC) instead of legacy access policies. RBAC provides:

For new banking deployments, RBAC should always be the default choice.

For highly sensitive cryptographic operations - such as encrypting account numbers or personally identifiable information - Key Vault supports hardware security modules (HSMs). Encryption operations occur inside tamper-resistant hardware, and encryption keys never leave the HSM boundary.

This level of protection is often required to meet regulatory and compliance mandates in financial services.

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform. It aggregates telemetry from Azure services, on-premises infrastructure, and third-party security tools, then analyzes that data to detect threats across the environment.

Think of Sentinel as a security analyst that never sleeps - continuously monitoring millions of events to identify patterns that indicate risk or compromise.

Sentinel looks for signals such as:

When Sentinel detects suspicious activity, it doesn’t just raise an alert - it can respond automatically through playbooks.

For example:

This automation significantly reduces response time, which is critical in banking environments where minutes can make the difference between containment and breach.

Beyond rule-based detection, Sentinel uses machine learning to establish baselines of normal behavior across users, applications, and systems.

If an application that typically executes 1,000 database queries per hour suddenly issues 100,000 queries, Sentinel flags this deviation as anomalous - even if no explicit rule has been triggered. This capability is particularly valuable for detecting previously unknown attack patterns or insider threats.

In this first part, we established the foundational architecture and security controls that underpin a production-grade banking website on Azure. We walked through how customer traffic enters at the global edge, is inspected and filtered through multiple WAF layers, reaches the application tier, and ultimately operates entirely within secure, private network boundaries.

The architecture outlined here is intentionally security-first. From edge protection and regional trust boundaries to private connectivity, identity enforcement, and centralized monitoring, every layer is designed to reduce attack surface while preserving performance and availability. This defense-in-depth approach is not optional in banking - it’s the baseline required to operate under regulatory scrutiny and maintain customer trust.

Importantly, this foundation is what enables everything that follows. Without strong ingress control, network isolation, and identity governance, higher-level services quickly become fragile and risky - regardless of how well they’re built.

In Part 2, we’ll move deeper into the platform and focus on how the system actually works:

Next: Part 2 - Business Logic, Data Management & Integration

If you found this useful, tap Subscribe at the bottom of the page to get future updates straight to your inbox.