Cloud foundations for banking: accounts, identity, network, evidence, residency and cost allocation, decided deliberately before the workloads arrive and make them permanent.
Six decisions sit underneath every cloud estate. Each one looks like configuration at the time and becomes structural the moment workloads depend on it, and most institutions make all six under pressure to get a first service live.
These are the foundation decisions. Each one determines something about every workload that lands afterwards, and the cost of changing them rises with every service deployed.
| The Decision | What It Determines for Every Workload | The Cost of Changing It Later |
|---|---|---|
| Account and Subscription Structure | Blast radius, cost visibility, access boundaries | Every workload moves, or it stays wrong. |
| Identity and Access Model | Who can do what, everywhere | A rebuild of every permission and role. |
| Network Topology | Latency, segmentation, what can reach the core | An outage window per connected system. |
| Logging and Evidence | Whether an audit question can be answered | Impossible. The logs do not exist. |
| Residency and Data Boundaries | Which workloads may run where | A migration, under regulatory attention. |
| Tagging and Cost Allocation | Whether anyone can see what a service costs | Retrospective tagging of a live estate. |
Ask what logging was configured for the first workload you put in cloud, and whether it is still retained.
This is the one foundation decision with no retrospective remedy. If the answer is that logging was turned on later, there is a period for which the institution cannot evidence who did what, and no amount of subsequent investment closes it. Every other question on this page has an expensive answer. This one has none.
The usual sequence is to get a workload live and formalise the foundation afterwards. By then the foundation is whatever was convenient for that workload, and every subsequent service inherits it.
We settle the six decisions first, with the functions that own them, and then land workloads in a defined order that puts the learning early and the risk late.
Step 1
Assess readiness across workloads, data, skills and obligations
Step 2
Discover workloads and their real dependencies
Step 3
Classify workloads by criticality, data sensitivity and constraint
Step 4
Establish the six foundation decisions with their owners
Step 5
Design the landing zone, including evidence from day one
Step 6
Design identity deliberately rather than extending what exists
Step 7
Design network topology and hybrid connectivity
Step 8
Set the recovery objective per workload with the business
Step 9
Automate the foundation as code, so it is reproducible
Step 10
Land a pilot workload that exercises the whole foundation
Step 11
Validate: resilience, evidence, cost allocation, access
Step 12
Transition to operations with ownership agreed per workload
Ask what the recovery objective is for your most important banking workload, and who agreed it. If the answer comes from a technology document rather than from the business, the objective is a description of the current architecture rather than a requirement it was built to meet. Those two things look identical on paper and behave very differently during an incident, and the difference only becomes visible on the day it matters.
Grouped by what each part is responsible for. The foundation group is where the decisions from section 2 become real, and it is the group worth getting right before the others start.
Cloud foundations
Landing zone design and build: account structure, identity, network, logging, residency boundaries and tagging
Foundation as code, so the landing zone is reproducible, reviewable and auditable rather than assembled by hand
Identity and access architecture, designed rather than extended, with privileged access treated as its own problem
Cloud security foundations: baseline controls, guardrails, encryption and key management options with their trade-offs stated
Evidence architecture: what is logged, where it goes, how long it is kept and how it is protected from alteration
Infrastructure and workload platforms
Cloud infrastructure modernisation for workloads that are moving, with the pattern chosen per workload
Container platforms and orchestration, where the workload justifies them rather than as a default
Infrastructure automation, so environments are provisioned consistently and can be rebuilt
Network and connectivity engineering, including the hybrid links that will persist for years
Environment structure across development, test and production, with the separation your controls require
Resilience
Recovery objectives per workload, agreed with the business and designed to rather than described
Disaster recovery modernisation, including the move from a documented plan to an executed one
Backup and restore architecture, with restore tested rather than backup monitored
Failure domain design, so redundancy is placed where the objective requires it
Degraded operation design for critical services, since full failure is rarely the only option
Hybrid and multi-cloud
Hybrid architecture, because the core and several other systems are not moving
Multi-cloud where there is a reason for it, with the operational cost of that choice stated plainly
Portability and exit considerations built into the design where your obligations require them
Connectivity to the systems that stay, per our Core Banking Integration page
Workloads do not place the same demands on a cloud foundation. Each of these tests a different part of it, which is also what makes the order of migration a design decision rather than a scheduling one.
Banking infrastructure transformation
Moving the general estate: internal systems, shared services, the long tail of servers nobody has looked at in years.
Digital banking infrastructure
Hosting the customer-facing channels, which are the most visible workloads in the institution.
Lending platform infrastructure
Workloads whose demand is uneven: campaign-driven volume, month end, rate-change surges.
Analytics and data workloads
Compute for analytical and modelling work, which is the most cost-elastic workload class in the estate.
Development and test environments
Non-production environments, which are usually the largest count of resources and the least governed.
Disaster recovery modernisation
Replacing a standby arrangement that has been paid for and rarely exercised.
Hybrid banking operations
The steady state: cloud workloads operating alongside systems that are not moving, for years.
Ask how many resources in your cloud estate have no identifiable owner. In most estates the number is large and nobody has produced it, because producing it requires tagging that was never enforced. It is also the number that determines whether the estate can be operated, secured or optimised at all, and every one of those three problems reduces to the same missing foundation decision.
We work across the major cloud platforms and within your existing provider arrangements. The architecture is chosen for your constraints rather than from a reference diagram, and every deployment model below carries an operating cost that should be stated before it is chosen.
Public cloud
The default for most workloads, where residency and obligation constraints permit. The operating cost is configuration discipline, because the platform will do whatever you tell it to.
Private and on premises
For workloads that cannot move, for reasons that are sometimes regulatory and more often dependency-related. Plan for this to persist.
Hybrid
The real steady state for a bank with a core that is not moving. The operating cost is connectivity, identity across both sides and two operational models.
Multi-cloud
Where there is a specific reason: a capability, a commercial position, or a concentration consideration your risk function has raised. The operating cost is paid every day, which is the sub-section below.
Cloud platforms: Amazon Web Services, Microsoft Azure and Google Cloud, with the choice driven by your existing arrangements, workload fit and obligations
Compute: virtual machines, containers and managed services, selected per workload rather than standardised on principle
Containers and Kubernetes, where the workload justifies the operating burden it transfers to you
Infrastructure as code for the foundation and for every environment, which is what makes the estate reproducible and reviewable
Networking: segmentation, private connectivity, and the hybrid links to systems that stay
Identity: integration with your existing enterprise identity, with privileged access designed separately
Encryption and key management, with the custody options and their consequences stated before one is chosen
Cloud controls work in two places. The foundation prevents: a misconfiguration that cannot be deployed is not an incident. Operations detect: something will drift anyway, and that belongs to our Cloud Operations & Optimization page. This page owns the preventive half.
Guardrails
Preventive policy in the foundation, so the unsafe configuration is refused.
Identity and access
Least privilege, privileged access separated, joiners and leavers handled.
Encryption and keys
In transit and at rest, with custody decided deliberately.
Residency boundaries
Enforced structurally rather than by instruction.
Shared responsibility
Your half engineered and evidenced, per section 3.
Third-party oversight
Evidence and audit access your risk function requires.
Operational resilience
Objectives per workload, and testing that is executed.
Auditability
Logging, retention and tamper resistance, from the first workload.
Modernize banking technology with scalable cloud infrastructure and resilient application platforms. From cloud and legacy application modernization to data migration, DevSecOps, and cloud operations, help banks improve platform reliability, strengthen security, optimize infrastructure costs, and support future growth.
Day-to-day operational monitoring, incident management and cost optimisation belong to our Cloud Operations & Optimization page. What belongs here is narrower and almost never measured: whether the foundation decisions are still being honoured as the estate grows.
Guardrail violations attempted and prevented, which is evidence the preventive controls are doing something rather than decorating the design
Untagged or unowned resources, as a count and a trend, because this is the measure that predicts whether the estate can be governed at all
Drift from the baseline configuration, particularly in accounts that were provisioned early
Resources deployed outside the landing zone, which is how a second shadow foundation begins
Evidence completeness: whether logging is enabled, flowing and retained for every account, with gaps raised rather than discovered
Privileged access grants outstanding, since standing privilege accumulates quietly and is the hardest thing to remove later
Residency exceptions, if your obligations require that boundary, reported rather than assumed
And resilience test results per workload, including the objective, the measured outcome and the findings
Infrastructure availability and workload performance against the stated objective
Capacity utilisation and headroom, with the trend that matters rather than the current number
Cloud spend by service and by owner, which is only possible if tagging was enforced
Security posture findings, triaged and aged rather than counted
Count the cloud accounts or subscriptions in your estate, then ask who owns each one. The count is usually higher than expected and the ownership list is usually incomplete. Every unowned account is spend nobody reviews, configuration nobody maintains and access nobody revokes, which makes it the single most useful inventory to produce before any further cloud work is commissioned.
Outcomes depend on your estate, your obligations and how much cloud already exists. These are the changes the work is aimed at.
Every workload lands on a foundation that was designed rather than inherited from the first project
Evidence exists from the first workload, so the audit question has an answer for every period
Resilience is a stated objective per workload, designed to and tested by execution
Cost is attributable to a service and an owner, which is the precondition for optimising it
Residency and data boundaries are enforced by structure rather than by instruction
Identity is designed rather than extended, with privileged access treated as its own problem
The foundation is code, so it is reproducible, reviewable and rebuildable
Hybrid is designed as the steady state it will be for years, not as a transitional inconvenience
And the estate can be governed, because every resource has an owner
Bring us your cloud estate as it is, including the parts that were not planned, and we will inventory it, state the six foundation decisions as they currently stand, and identify which of them are costing you something now rather than later.
CaliberFocus engineers banking cloud foundations by settling the six landing zone decisions before workloads make them permanent: account structure, identity, network, evidence, residency and cost allocation. We capture evidence from the first workload, set recovery objectives per workload with the business, enforce tagging at deployment, and build the foundation as code.
- Landing zone decisions made deliberately, with named owners
- Logging and evidence captured from the very first workload
- Resilience designed per workload and proven by executed recovery tests
- Foundation as code, with tagging and guardrails enforced at deployment
Security & Compliance
