The Armenian government has signed a memorandum of understanding with a major hyperscaler to accelerate cloud adoption across the public and private sectors. For most organisations this is straightforwardly good news. For regulated financial institutions it makes an existing question more urgent rather than answering it.
Public cloud is genuinely the right answer for many workloads. It is genuinely the wrong answer for some. The purpose of this piece is to make that a reasoned decision rather than a default in either direction.
The four factors that actually decide it
Most of the noise in this debate comes from arguing about the wrong variables. In practice, four things decide it for a bank or credit organisation.
1. Residency and legal control
The first question is not technical: where is customer data permitted to be processed and stored, and who can be compelled to hand it over?
Public cloud regions give you geographic placement. They do not give you legal isolation from the jurisdiction of the provider’s parent company. For institutions where the supervisory expectation is that customer data remains under domestic legal control, region selection does not fully resolve the question.
This is what “sovereign” means in practice: equipment your institution owns, sited where you choose, with a control plane that does not depend on a foreign provider. It is a statement about legal and operational control, not about a vendor.
Decides for private cloud when: residency or legal-control expectations apply to the data.
2. Auditability
Under continuous regulatory scrutiny, asserting a control is not enough. You have to be able to evidence it.
On owned infrastructure, the evidence chain is short. You control the hypervisor, the storage, the network and the logs, and you can show an auditor the whole path.
On public cloud, a substantial part of the control environment belongs to the provider. That is not inherently a problem: ISO/IEC 27017 exists precisely to address cloud control responsibilities, and provider attestation reports are widely accepted. But it introduces a shared responsibility boundary you have to explain, and some supervisors ask harder questions about it than others.
The honest summary: public cloud auditability is workable, and it is more explaining.
Decides for private cloud when: your supervisor is uncomfortable with third-party attestation in place of direct evidence.
3. Steady-state cost
This is where the intuition most often fails, in both directions.
Public cloud is cheaper for variable load. Its economics come from paying only for what you use, which is compelling when usage genuinely fluctuates.
Core banking workloads mostly do not fluctuate. They run continuously, at fairly predictable capacity, for years. For that profile, metered pricing frequently costs more over a hardware lifecycle than owning the hardware: and the gap widens with data egress charges, which hurt institutions moving data between environments for reporting and analytics.
The correct comparison is a full lifecycle model:
| Cost element | Private cloud | Public cloud |
|---|---|---|
| Compute | Capital, amortised over 5–7 years | Metered, continuous |
| Storage | Capital plus growth | Metered per GB-month |
| Data egress | None internally | Charged, often materially |
| Power, cooling, space | Yours | Included |
| Refresh cycle | Yours to plan and fund | Provider’s |
| Capacity headroom | You buy it in advance | Available on demand |
| Staff and expertise | Higher | Lower, but not zero |
Neither column is a winner in the abstract. Model it against your actual load profile, over the full refresh cycle, with egress included.
Decides for private cloud when: load is predictable, always-on, and data-heavy.
4. Exit and concentration risk
Regulators increasingly ask about concentration risk and exit plans. The question is direct: if this provider became unavailable or commercially unacceptable, what would you do, and how long would it take?
An answer built on provider-proprietary managed services is weak, because the migration is a rewrite. An answer built on portable abstractions (containers, Kubernetes, standard databases, infrastructure-as-code) is strong regardless of where the workload currently runs.
This argues less for private cloud specifically than for cloud-agnostic architecture, which is available in both models and is the single most under-valued decision in this whole debate.
Where public cloud clearly wins
Being honest about this matters, because a private cloud built for the wrong reason is an expensive way to become slower.
- Genuinely variable workloads: seasonal campaigns, event-driven peaks, batch analytics
- Disaster recovery targets: paying for standby capacity only when invoked is a strong fit
- Geographic reach: serving customers across regions without building in each
- Managed services you do not want to operate: some specialised services are not worth replicating
- Small institutions: below a certain scale, owning a platform cannot be justified against staff cost
The hybrid position, done deliberately
Most institutions end up hybrid. The distinction that matters is whether it was designed.
Designed hybrid looks like: regulated customer data and core predictable workloads on owned infrastructure; burst capacity, analytics and DR in public cloud; one identity system spanning both; explicit connectivity design; documented data-gravity decisions; and a written statement of what runs where and why.
Accidental hybrid looks like: two identity systems, unclear data location, networking that was extended rather than architected, egress costs nobody predicted, and no one able to say which environment a given dataset lives in.
The first is a strategy. The second is what happens when cloud adoption proceeds one project at a time.
A decision sequence
- Classify data by residency and legal-control requirement. This constrains everything else, so do it first.
- Profile workloads by variability. Predictable and always-on behaves economically differently from bursty.
- Model full lifecycle cost for each profile, including egress and refresh.
- Ask your supervisor what evidence they expect for cloud-processed data. Ask before designing, not after.
- Design for portability regardless of the answer: containers, Kubernetes, IaC.
- Then choose placement per workload, and write down why.
Steps 1 and 4 are the ones most often skipped, and they are the cheapest to do.
- Most often skipped
- steps 1 and 4
- Cheapest to do
- steps 1 and 4
- Portability first
- so the placement decision stays reversible
This diagram as text
- 1 · Classify data by residency and legal control — constrains everything after it
- 2 · Profile workloads by variability — always-on behaves differently from bursty
- 3 · Model full lifecycle cost — including egress and refresh
- 4 · Ask the supervisor what evidence they expect — before designing, not after
- 5 · Design for portability regardless of the answer — containers, Kubernetes, infrastructure as code
- Only now
- Private or on premises
- Public cloud
- Written down: why, per workload
Relationships
- 1 · Classify data by residency and legal control → 2 · Profile workloads by variability
- 1 · Classify data by residency and legal control → 3 · Model full lifecycle cost
- 2 · Profile workloads by variability → 4 · Ask the supervisor what evidence they expect
- 3 · Model full lifecycle cost → 4 · Ask the supervisor what evidence they expect
- 4 · Ask the supervisor what evidence they expect → 5 · Design for portability regardless of the answer
- 5 · Design for portability regardless of the answer → Private or on premises
- 5 · Design for portability regardless of the answer → Public cloud
- 5 · Design for portability regardless of the answer → Written down: why, per workload
What this means practically
For a typical Armenian bank or universal credit organisation, the pattern that survives scrutiny is usually: core regulated systems on sovereign private cloud, portable by construction, with public cloud used deliberately for burst, analytics and recovery.
That is a defensible position in front of a supervisor, it is economically sound for the load profile, and it does not trap you.
STP builds both sides of that picture: sovereign private cloud on equipment you own, hybrid and multicloud architecture, and the Kubernetes platform that makes workloads portable between them. We will also tell you when public cloud is the better answer for a given workload, because the alternative is selling you a platform you did not need.
Start a conversation if you want this worked through against your actual estate.