IBM Cloud sells region choice through the physical limits of data centres and transit

Summary

• IBM Cloud publishes one of the more useful public location maps in the cloud market: full multizone regions, single-campus multizone regions, classic data-centre codes, universal zone names and PoP codes. That map lets a customer tie a region choice to physical data-centre groups rather than treating the region name as pure software.
• The same evidence stops short of the facts that decide a hard recovery case. Public documentation does not disclose exact facility ownership, site-level MW, current rack load, utility topology, dark-fibre routes, live backbone utilisation, Direct Link carrier diversity or free replacement capacity.
• IBM's own documents narrow some marketing claims. Hardware-dependent profiles are not available everywhere, classic virtual-server requests can hit insufficient capacity, bare-metal stock is dynamic by data centre, Direct Link is not automatically redundant, and VPC zonal resources do not move to another zone when a complete zone fails.
• IBM incident, migration and closure material makes the infrastructure point concrete. Grid outages, cooling-power failures, fires, facility-network disruptions and the planned CHE01 closure show that cloud geography is not just a compliance choice; it is a dependency on real buildings, operators, carriers, maintenance windows and data-movement capacity.

A region label is a physical selection

The most useful thing about IBM Cloud's location documentation is that it does not leave the customer with a purely abstract region list. It explains that IBM Cloud uses full multizone regions, single-campus multizone regions and classic data centres. The region names that appear in tools and console workflows therefore map to physical data-centre groupings. Dallas, Sao Paulo, Toronto, Washington DC, Frankfurt, London, Madrid, Sydney and Tokyo are not only sales geography. They are region choices whose VPC zones map to universal zone names, and those universal names identify underlying data-centre codes such as DAL10, FRA05, LON06, SYD04 or TOK05.

That makes IBM Cloud more auditable than a provider whose public map stops at a city label. A customer can see that a VPC resource in a logical zone is not floating in a nameless cloud. It is associated with an account-specific zone mapping and a physical location code. Classic infrastructure and Power Virtual Server resources are even more direct: the location is specified by data-centre code rather than by a region abstraction. IBM also lists 42 classic data-centre codes across North and South America, Europe and Asia Pacific. That inventory includes long-lived names such as DAL08, AMS03, FRA05, LON02, CHE01, SNG01 and TOK05.

The evidence, however, should be read for what it is. A data-centre code is not a street address, a power contract, a landlord disclosure, a carrier duct map or a stock report. It is a physical-location identifier inside IBM's cloud operating model. It can support a conclusion that the cloud product has a material place. It cannot by itself support a conclusion that the place has enough uncommitted servers, enough spare electrical headroom, two independent fibre entrances, independent fuel logistics or tested customer failover capacity.

This distinction matters because cloud buyers often buy a region as if it were a compliance and latency object, then discover during design or recovery that it is also an inventory object. If the customer needs a particular bare-metal profile, a GPU-equipped classic server, a Direct Link PoP, a local Object Storage class, or a replacement zone that can absorb a failed workload, the named region is only the first filter. The real question is whether the requested service, profile, circuit and recovery target are available in the physical slice of IBM Cloud that the account can use.

SoftLayer left a hosting estate, not an infinitely elastic pool

IBM Cloud's current infrastructure estate still carries the shape of a hosting business. The 2013 IBM Form 10-Q recorded IBM's acquisition of SoftLayer for $1.977 billion. IBM's historical SoftLayer acquisition FAQ described a dedicated and virtual infrastructure business with a Dallas base and a large customer footprint. That origin matters because SoftLayer was not born as a region-only hyperscale abstraction. It was a hosting platform built out of data centres, bare-metal inventory, VLANs, private networking, customer-specific servers and operational procedures around named facilities.

The modern IBM Cloud platform has layered VPC, managed services, Object Storage, Kubernetes, OpenShift and global platform services over that estate. Yet the classic data-centre list still exists, and some migration and lifecycle notices still refer to data-centre codes directly. The location document says classic data centres host power, cooling, compute, network and storage resources, and that they use a POD architecture. A POD is not a marketing adjective. It is a capacity unit made of racks, servers, networks, storage and backup generators. Adding a POD changes what can be sold.

Running out of a server, router, storage type or electrical envelope changes what can be provisioned.

That is why a history of expansion, such as IBM's Dallas DAL14 VPC expansion announcement, should not be read as an unlimited capacity proof. The announcement identifies an added Dallas availability-zone facility and explains why IBM wanted more Dallas capacity. It does not disclose installed megawatts, server counts, current utilisation, lease terms, equipment batches or customer commitments. It is useful evidence that IBM was adding a physical data-centre location to serve a region. It is not evidence that any later customer order can assume open stock in every Dallas profile.

The same is true in reverse for facilities that age out. IBM's CHE01 closure notice says operations in Chennai 01 will discontinue on 10 June 2027. The notice sets dates for end-of-market controls, new-deployment removal, a network-maintenance disruption window, migration-assistance cutoff and final PaaS and IaaS migration windows. A closure notice is a rare cloud document because it exposes an infrastructure truth usually hidden behind the console: cloud sites have lifecycles. They can be added, restricted, modernised, consolidated and closed. A customer that treated CHE01 as a durable placement now has to turn a location decision into a migration project.

Full MZRs and single-campus MZRs are different failure geography

IBM's published distinction between multizone regions and single-campus multizone regions is valuable because it keeps the region label from becoming too comfortable. A full MZR uses multiple zones across separate data-centre locations in a metro area. The location page describes zones as fault domains and says the full MZR model uses three or more data centres. It also says exact distances vary by region and gives a minimum separation for zones. That is useful geography. It says a Dallas or London region is not simply one room with three software labels.

Single-campus MZRs carry a different kind of truth. The same IBM documentation lists Chennai - Airtel, Montreal, Mumbai - Airtel and Osaka as single-campus MZRs. IBM says their zones are in different sections of the same building or multiple buildings on a campus, and that power, cooling, networking and physical-security dependencies can overlap. This is not a minor caveat. It changes the failure model. A customer that spreads resources across three zones inside a single-campus region may improve local availability against many equipment and maintenance faults, but the geography is not the same as three separated metro sites.

IBM's VPC high-availability and disaster-recovery guidance makes the difference sharper. It says a complete zone failure makes zonal resources unavailable in that zone and that virtual server instances in the affected zone are not moved automatically to another healthy zone. It also says a data-centre disaster in a single-campus MZR could affect the entire region because the zones are more tightly related, so services should use backup and recovery strategies to another MZR. Those lines are important because they push responsibility back from the map to the architecture. A customer cannot buy an MZR name and assume every resource has become regional.

The practical effect is simple. A regional service may distribute its data plane across zones and reroute requests inside the region. A zonal virtual server, subnet, gateway or volume remains tied to a zone. A single host failure can be handled differently from a whole-zone loss. A full regional disaster is different again. Each layer asks a different capacity question: is the remaining zone healthy, is the regional control plane available, is the target region stocked, have snapshots copied, can DNS and applications tolerate the failover, and has the customer tested the movement?

For procurement, this means the buyer should ask for the account's zone mapping before treating zone diversity as physical diversity. IBM says an account's logical zone mapping is established when the first VPC resource is created in a region. Two teams saying "zone 1" can be talking about an account-local logical identifier, not automatically the same universal data-centre code. The universal zone name is the stronger evidence. Without it, a resilience diagram can look more physically precise than it is.

Capacity is dynamic, not implied by a published code

IBM Cloud documents several ways in which a published location can still fail to satisfy a request. The service rollout policy separates core services from market-driven services and warns that hardware-dependent profiles and features are not available in every MZR. That is the first capacity boundary. A region may be open, core services may be present, and the console may still not offer a specialised profile, accelerator, storage option or managed service the customer wants.

The second boundary is real-time inventory. IBM's classic virtual-server troubleshooting page documents an insufficient-capacity error when the router or data centre lacks the resources to fulfil a request. IBM's suggested responses are operationally revealing: try a different router, avoid specifying a router, use a different data centre, request fewer instances, pick smaller sizes or change storage type. That is not a cloud-theory problem. It is a resource-location problem.

The requested server is not an abstract quantity of compute; it has to land on available infrastructure in a particular data centre and sometimes behind a particular router.

The third boundary is hardware locality. The same troubleshooting page limits GPU provisioning to named classic data centres. The exact list is a reminder that specialised hardware is not smeared evenly across the map. A customer designing for AI inference, graphics workloads or accelerator-backed recovery cannot treat every IBM Cloud region as equivalent. The same principle appears in IBM's bare-metal documentation. Bare-metal servers are dedicated physical machines, fast-provision stock is preconfigured, custom servers depend on complexity and quantity, and the provisioning flow exposes dynamic inventory by data centre.

IBM also describes stress testing that can add time, and some server enhancements vary by configuration.

This makes capacity more legible but also more fragile. A dynamic inventory display can help a buyer avoid fantasy planning, yet it changes continuously. A preconfigured server that is visible during design can be gone when a disaster exercise starts. A VPC reservation can hold dedicated zonal compute capacity, but it does not reserve every storage, network, backup, Object Storage, Direct Link, support or target-region dependency. A region with available virtual servers may not have the same bare-metal profile. A region with a usable server may not have the customer-facing private circuit in the right PoP.

The central engineering rule is that installed capacity, advertised capacity and usable capacity are different things. IBM publishes many location and service facts. It does not publish current free stock by site, rack power by POD, occupied load, reserved headroom, queue depth, spare routers or failure-condition recovery capacity. Customers who need a hard recovery guarantee have to create their own evidence: reservations, pre-provisioned warm capacity, tested automation, current inventory checks, support agreements and proof that the target zones can absorb the workload under stress.

Power and cooling sit below the cloud contract

IBM's resiliency documentation says data centres use multiple power feeds, fibre links, dedicated generators and battery backup. IBM's global data-centre marketing page describes N+1 power and cooling, security and optimisation of space, power, network and personnel. The corporate environmental disclosures add aggregate evidence about data-centre PUE, renewable-electricity procurement and the role of suppliers or landlords in electricity sourcing. Taken together, the public record makes one thing clear: IBM Cloud is not pretending that infrastructure lives above electricity.

Power, cooling and physical networks are part of the service boundary.

But the evidence is not site-level power diligence. It does not say how much utility power is allocated to FRA05, DAL14, SAO01, CHE01 or TOK05. It does not disclose fuel contracts, generator runtime, battery duration by hall, transformer redundancy, cooling plant design, water exposure, landlord obligations, maintenance windows, switchgear age or the load carried at the time of a heat wave or grid fault. Corporate aggregate PUE is useful for environmental reporting, but it cannot answer whether one customer can add twenty servers in one data centre or fail over a rack-heavy estate into another.

IBM's own high-availability guidance includes a small but important hardware caveat: some mature sites have 1U single-socket server chassis that might not accommodate a dual power feed. That detail should not be exaggerated into a general indictment of IBM Cloud. It is useful because it shows how old equipment and facility patterns can puncture a broad redundancy statement. A data centre can have multiple power feeds while a particular chassis or customer configuration still lacks dual-feed protection. Reliability lives at the lowest relevant layer.

Incident records make the point concrete. IBM Cloud's incident-report archive and status history have included location and service events involving grid outage, fire, Washington power outage, SAO01 cooling-power failure and facility network disruptions. Public status material does not provide every root cause or every remediation detail, so it should not be turned into a ranked risk model for each site. It does show that the failure paths IBM asks customers to design around are not theoretical. Power fails. Cooling can become the binding constraint.

A facility network can disrupt services even when a customer has not changed application code.

For a serious customer, the power question is not "does the provider claim redundancy?" It is "which part of my workload is tied to which physical code, which device has dual feeds, what site events has IBM recorded, what does my support plan give me during a power or cooling incident, and where can I restart if the affected zone or site is not coming back quickly?" IBM is responsible for the facilities, physical network, storage and hypervisors under its shared-responsibility model. The customer is still responsible for placing applications and data so those physical failures do not become business failures.

The backbone is extensive, but the private entrance is separate

IBM Cloud's network evidence is strong at the platform level. IBM describes data-centre-to-data-centre traffic as staying on its backbone and within its ASN for private connectivity. Its resiliency documentation describes dark-fibre providers connecting edge sites to regional compute facilities, redundant backbone connectivity to other regions, and peering with multiple providers directly and through local exchanges. PeeringDB's AS36351 record adds a market signal that SoftLayer/IBM Cloud has an international exchange footprint and a publicly visible network identity.

That is useful evidence for the existence of a serious cloud network. It is not a fibre-route map. PeeringDB is operator-maintained and not audited. IBM's backbone descriptions do not publish exact duct routes, dark-fibre providers, shared bridge crossings, repair contracts, utilisation, congestion, maintenance histories or simultaneous-failure exposure. A customer can reasonably infer that IBM Cloud operates a large backbone. The customer cannot infer that two paths in a design avoid the same metro trench, building meet-me room, long-haul provider, exchange outage or repair constraint.

The boundary is even clearer with IBM Cloud Direct Link. Direct Link is the private Layer 3 entrance from a customer's network to IBM Cloud. IBM's prerequisites page is unusually direct about the demarcation. The customer must arrange and pay for the path to the PoP, cross-connects and provider circuit. A single Direct Link service path is unprotected. Redundancy requires more than one connection, separate routers or geographically diverse PoPs, and customer routing configuration. IBM also says it will not colocate customer equipment in IBM network PoPs.

This means the resilience of a private cloud connection is jointly produced. IBM controls the service termination and the IBM-side cloud network. The customer and its carrier control the route to the PoP, the cross-connect order, the local loop, the router pair, BGP policy and the diversity of the long-haul path. IBM's Direct Link diversity guidance and FAQ can show the correct architecture pattern, but a diagram is not evidence that two circuits follow separate physical routes. Equal-cost paths can still collapse onto a common router or common outside plant if the implementation is poor.

The practical failure path is often ordinary. A customer buys two circuits, sees two BGP sessions, and calls the result redundant. Then a building meet-me room, carrier handoff, last-mile trench, route policy, billing suspension, router maintenance or mistaken VRF migration creates a single point of failure. IBM documentation even notes that Direct Link can be suspended for billing-related reasons. That is not a physical fibre cut, but it is still an infrastructure dependency: the private entrance can disappear because the administrative system that keeps it alive failed.

Control planes can stay up while recovery stays physical

IBM's VPC documentation separates control plane from data plane, and that separation is important. If a control plane has trouble, existing provisioned resources can continue to run. If a data plane in a zone fails, the regional or other-zone controls may still manage healthy zones. This is the kind of architecture that can make a cloud more resilient than a single hosting facility. It also creates a common misunderstanding: if the console is reachable and the control plane can create resources somewhere else, customers may assume the workload can be recovered without physical friction.

The VPC disaster-recovery guidance says otherwise. In a complete zone failure, zonal resources are down and virtual server instances in that failed zone are not moved automatically to a healthy zone. The customer must design for application high availability across zones or restore into an available location. For regional disaster recovery, IBM points to scripts, Terraform, Object Storage, Schematics and deployable architectures. The customer has to maintain an external source of truth for VPC configuration, preserve data copies and test the plan.

IBM can work to recover the underlying facilities, network devices, storage, servers, memory and hypervisors, but if IBM cannot restore the service instance, the customer must restore it through the designed recovery path.

This is where capacity and recovery become the same problem. A snapshot that exists only in the failed region is not a remote recovery asset. A configuration file that has never been applied in another region is not a tested failover. A zone-level load balancer does not save a workload that was not built to scale horizontally. A bare-metal server with local disks is a different recovery problem from a virtual server with remote block snapshots. IBM's bare-metal recovery documentation says IBM does not automatically back up customer devices. The customer has to choose and manage a backup and recovery approach.

IBM's block-storage snapshot documentation adds the physical dimension to recovery. Snapshots and cross-regional copies are useful, but remote copies take time and incur transfer and storage costs. IBM's example for a full 3 TB remote copy reaches hours rather than seconds. Fast-restore clones can help, but they require enabling and paying for zone-local readiness. None of that is a weakness by itself. It is how data movement works. The risk comes when the buyer treats snapshot existence as if it were already restored compute in another region.

Object Storage carries a similar lesson. IBM's Object Storage FAQ distinguishes cross-region, regional and single-site resilience and says changing bucket location requires creating a new bucket and moving data. The bucket-movement guide discusses copying, integrity checking, endpoint choice, compute placement and configuration that must be recreated. A bucket can be globally reachable while its resilience class and physical location still matter. Moving it during a stressed event is not the same as having chosen the right class before the event.

Residency narrows location, not every operating dependency

IBM Cloud's residency material gives customers a reason to care about region selection beyond latency. For regional and zonal services, IBM says customer content is stored and processed in the selected region, subject to the applicable service behaviour and terms. The EU-supported account setting provides another layer: ordinary support can be routed to EU teams for eligible services, while time-limited outside-EU specialist access can still occur in reviewed unresolved cases. IBM's own explanatory material distinguishes data residency from data sovereignty, meaning physical location and legal authority are related but not identical.

This is useful because it stops a common shortcut. A customer cannot simply ask whether the data is in Frankfurt, London, Madrid or Toronto and declare the operational risk closed. The region controls a large part of the physical placement, but the service may still rely on global platform functions for identity, billing, catalog, support, usage metering, public IP management, DNS, Direct Link control, Object Storage provisioning or other management tasks.

IBM's resiliency documentation says global platform services and some global control-plane services can create cross-region operational impacts even when a workload is in another region.

That does not mean local data commitments are meaningless. It means the dependency map has two layers. The bytes may be stored and processed in a selected region for the chosen service. The ability to create resources, authenticate users, change DNS, attach a Direct Link, view billing, open support cases, create buckets or provision new capacity may still involve regional or global control-plane services. During normal operation the distinction may be invisible. During an incident it can decide whether the workload keeps serving, whether administrators can change it, and whether the customer can stand up a replacement quickly.

Regulatory and commercial terms add another infrastructure consequence. IBM's terms guidance discusses EU Data Act reduced egress charges and French SREN waiver procedures. Those are legal and pricing mechanisms, not fibre routes. Still, they affect recovery economics. Moving data out of a provider or between regions is partly a network problem and partly a contractual problem. A customer that needs sovereign or portable operations should not only verify where data rests; it should test how data moves, what configuration must change, what identities are needed, which support teams can act, and what charges or waivers apply.

For IBM Cloud, the fair conclusion is narrow. The public record supports region-level locality for many services and a documented support-locality feature for eligible EU accounts. It does not support a blanket statement that every operational dependency, specialist access path, control-plane action, data movement or recovery support activity remains inside the chosen geography. The buyer has to examine the exact services in use.

Incidents turn architecture into evidence

Cloud architecture documents describe what should happen. Incident records show which parts of the system have actually been stressed. IBM Cloud's incident reports and status history are therefore important not because they make IBM look uniquely fragile, but because they expose the ordinary infrastructure classes that matter in every cloud: grid power, fire, cooling power, facility networking, access to services and multi-region management paths.

The source pass found incidents including a FRA05 grid outage, a Seoul fire, a Washington power outage, a SAO01 cooling-power failure and facility network disruptions. Public incident listings do not provide all the details needed to rank every site. They can be limited by retention period, summarisation and post-incident language. But they are still stronger evidence than a generic resilience statement. A grid outage in a named data-centre code is evidence that the cloud service depends on the local grid, switchgear, backup systems and recovery sequence.

A cooling-power failure is evidence that compute availability can become a heat-removal problem. A fire or facility-network event is evidence that physical access, safety systems and local networking can become service dependencies.

The customer-level lesson is to map incidents to architecture. If a workload was designed across three zones in a full MZR, a single-zone facility event should not create the same failure as a single-server design. If it was built in one zone with one Direct Link and one local backup, the same event may become a service interruption, a data-recovery exercise and a support escalation. IBM's SLO and SLA documents can frame credits and objectives, but credits do not move data, rebuild servers or reopen a circuit. They allocate commercial remedy after the fact.

Incident evidence should also change how customers read "wherever possible" in backbone diversity language. IBM says it uses diverse providers and redundant connectivity in its network. That is useful, but the operator's own documentation does not prove every customer path or every local edge condition. Real resilience requires matching the architecture layer to the failure layer. A backbone with provider diversity does not save a customer if the only private entrance is one unprotected Direct Link. Three zones do not save a workload if all state was on one zonal volume and no tested restore exists.

A global platform service can remain active while a specific regional profile is out of stock.

The point is not to demand impossible certainty. It is to avoid substituting the provider's design intent for the customer's evidence package. IBM gives enough public material for a good diligence process: location codes, zone mappings, failure-domain guidance, Direct Link boundaries, capacity-error behaviour, migration steps and incidents. The buyer should use those facts to test its own dependency chain.

Closure notices make migration a capacity problem

The CHE01 closure notice is a particularly useful document because it shows infrastructure modernisation from the customer side. IBM says CHE01 will cease operations on 10 June 2027 and sets a schedule that began with an end-of-market announcement in June 2026. It limits provisioning, removes new deployment for all accounts at a later milestone, schedules a network-maintenance window in April 2027, closes the migration-assistance request window, and then ends PaaS and IaaS migration windows before final discontinuation. IBM also says no extension period is available.

That schedule changes the meaning of capacity in Chennai. Before the closure, CHE01 was a data-centre code in the IBM Cloud inventory. During the closure process, it becomes a shrinking service boundary. Existing accounts may be allowed for a period, new provisioning is restricted or removed, network maintenance creates a planned disruption, and customers must choose target locations. IBM says newer Chennai and Mumbai locations offer a more comprehensive technology stack and improved connectivity across MZR operations. That may be good for long-term architecture. It does not make the migration automatic.

Moving out of a cloud data centre is a chain of small physical and logical tasks. The customer has to identify resources, map old architecture to new architecture, move data, build replacement VPC resources or classic alternatives, adjust DNS, change application endpoints, schedule downtime or replication windows, validate performance, rework backups, and update support and runbooks. IBM's classic-to-VPC migration documentation describes rebuilding and cutover rather than flipping a facility label. Its data-migration material shows that volume and file count affect transfer time.

Object Storage movement requires new buckets and configuration. Block snapshot copies can take hours for large volumes.

The capacity question then has two sides. The departing site needs enough remaining stability to run until the customer leaves. The target region needs enough available capacity, matching profiles, network access, storage features and support readiness to accept the workload. Public IBM documents do not show how much target capacity is reserved for CHE01 migrations or how individual customers are prioritised. That information may exist in account-specific communications, but it is not in the public evidence.

For infrastructure analysis, CHE01 proves a broader point: cloud providers can retire geography. A customer that selected a site for latency, residency, price, hardware profile or private connectivity may have to reselect under a schedule not set by the customer. The strongest mitigation is not faith that a region will remain forever. It is portable architecture, tested data movement, early inventory checks, and contracts that make support and target capacity visible before the deadline becomes an outage.

What a serious buyer should verify

IBM Cloud gives a buyer a better starting point than many providers because the public documents expose the mechanics. The diligence should therefore be concrete. First, the buyer should ask which universal zone names its account maps to, not just which logical zone labels appear in Terraform or the console. If a workload mixes VPC, classic infrastructure and Power Virtual Server, the data-centre codes matter because co-location, latency and failure correlation depend on the physical mapping.

Second, the buyer should separate region availability from product availability. The service rollout policy and troubleshooting pages make clear that not every service, profile, GPU, bare-metal configuration or market-driven feature is present in every region. If a workload depends on a hardware profile, the customer should verify stock and alternatives in the primary region and the recovery region. If the recovery plan assumes fresh provisioning after a disaster, it should be tested under realistic quota, inventory and support conditions.

If the workload cannot wait for fresh stock, pre-provisioning or reservation is not optional comfort; it is part of the design.

Third, the buyer should treat private connectivity as its own system. Direct Link resilience needs at least two connections, separate IBM-side routers or diverse PoPs, separate carrier routes where possible, customer BGP policy, and proof that the outside plant does not converge before reaching IBM. Two sessions are not two ducts. Two providers are not automatically two physical routes. A circuit order, LOA/CFA, cross-connect, router, route policy and carrier path all have to be checked.

Fourth, the buyer should place data recovery next to compute recovery. VPC snapshots, Object Storage replication, bucket copies, file-share replication and bare-metal backup products solve different problems. A snapshot in another region is more useful after it is stable. A fast-restore clone is more useful if it exists before the incident. A bucket in the wrong resilience class can require a copy under pressure. Bare-metal local disks need customer-managed backup. DNS and application state must be included, not treated as afterthoughts.

Fifth, the buyer should connect residency and operations. If the decision is driven by EU, French, financial, healthcare or public-sector requirements, the customer should verify selected service terms, support locality, specialist access rules, global control-plane dependencies, egress obligations and incident procedures. Physical data location narrows risk. It does not eliminate every jurisdictional, support or management dependency.

Finally, the buyer should read incident records not as public-relations noise but as a test list. Power outage, cooling-power failure, fire, facility-network disruption, control-plane degradation, capacity exhaustion, migration deadline, billing suspension and private-circuit failure should each have a runbook. If the customer cannot say what happens in each case, the region choice has not yet become an operating design.

The useful conclusion is narrower than the sales map

IBM Cloud's public evidence supports a strong but bounded conclusion. IBM operates a real global cloud infrastructure estate with named multizone regions, single-campus regions, classic data-centre codes, public zone mappings, private and public network services, a visible backbone identity, documented recovery features, incident reporting and lifecycle notices. A customer can use that evidence to make a region decision with more physical awareness than a simple country or city label would provide.

The evidence does not support the stronger claim that a selected IBM Cloud region automatically provides the customer's needed capacity, physical path diversity or recovery outcome. Capacity is profile-specific and changes over time. Some services are market-driven. Specialised hardware is local. Bare-metal stock is dynamic. Classic virtual-server provisioning can fail because a router or data centre lacks resources. Direct Link is a separate path into the cloud and is not redundant without deliberate duplicate engineering. Zonal VPC resources do not move themselves after a complete zone failure.

Single-campus MZRs carry tighter physical correlation. Data residency does not make every control-plane, support or legal dependency local.

That is not a reason to dismiss IBM Cloud. It is the reason to price it correctly. IBM's documentation gives buyers enough facts to ask specific questions instead of buying a cloud-region slogan. Which physical data-centre codes are involved? Which profiles are stocked? Which zones are mapped to the account? Which power and network incidents have affected similar sites? Which Direct Link paths are truly diverse? Which data copies are already stable elsewhere? Which resources are reserved? Which support tier responds to the kind of outage that actually threatens the workload? Which legacy sites are approaching closure?

The answer to those questions is the infrastructure product the customer is really buying. The region name is only the front door.