APAC cloud concentration and the shared-region problem

The APAC financial sector's migration to public cloud has been rapid and uneven. Singapore, Hong Kong, Sydney, Tokyo and Mumbai now host dense concentrations of regulated workloads on a small number of hyperscaler regions operated by the three largest providers. The benefits are well understood. The systemic exposure is less often discussed in those terms, but it is now an explicit supervisory concern in most major APAC jurisdictions.

The Bank for International Settlements and the Financial Stability Board have both highlighted concentration in cloud and other critical third-party services as a financial stability question, and APAC regulators have aligned their domestic expectations accordingly. MAS, HKMA, APRA, the JFSA, the FSC of Korea and the RBI have all issued or strengthened guidance on cloud and outsourcing risk over recent years, with a common thread on critical service providers, exit and stressed-exit planning, and the resilience of shared infrastructure that underpins many institutions at once.

Real-world events have made the question concrete. AWS, Azure and Google Cloud have each experienced incidents over the past several years that affected services across multiple customers in a single region or across a control plane shared between regions. None of those incidents alone reached the threshold of a systemic event, but each demonstrated that the failure modes are real and that the customer-side response is meaningfully constrained by what the provider does and discloses.

Two patterns have emerged in regulator expectations. The first is a clear move from cloud due diligence as a procurement activity to cloud risk management as a continuous capability, with named ownership, ongoing monitoring of provider control attestations and a credible plan for what happens if the provider's posture changes. The second is increasing pressure to demonstrate that exit and stressed-exit options are real rather than theoretical, including the time and cost of moving a critical workload to an alternative provider or back in-house under pressure.

The fourth-party question is becoming sharper. Many regulated firms depend on software and platform providers that themselves run on hyperscaler infrastructure. A regional failure that affects multiple software vendors simultaneously can produce a cascade in which the regulated firm's exposure is greater than the sum of its direct relationships. Mapping those dependencies is genuinely difficult, but the supervisory expectation is that institutions know which providers sit between them and the underlying cloud, and which of those concentrations matter.

Cross-border data and operations add a further dimension. Several jurisdictions, including India and Indonesia, have data localisation or residency expectations that constrain how cloud is deployed for regulated workloads. Reconciling those constraints with multi-region resilience designs requires careful architecture and clear regulatory dialogue, and it is one of the recurring issues in supervisory engagement on cloud strategies that span APAC.

For institutions setting cloud resilience priorities for the year, a few principles tend to apply. Make the actual region and zone topology of critical workloads visible to senior management. Test failover and exit under realistic constraints, not on paper. Maintain a current view of fourth-party dependencies for critical software providers. And approach cloud risk as a continuing dialogue with the provider, not as an annual due diligence checkpoint.