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

Summary

• IBM Cloud has a verifiable operating footprint. Its current location register names nine metropolitan multizone regions, four single-campus multizone regions and 42 classic infrastructure data centres, while its documentation maps logical VPC zones to physical facilities and network points of presence.
• Region choice does not make capacity abstract. IBM says some hardware-dependent profiles are not available in every region, exposes bare-metal inventory by data centre, documents insufficient-capacity errors, and sells reservations that dedicate capacity in a chosen zone.
• Resilience remains an architectural purchase rather than an automatic property of an account. A single zonal server is not moved to another zone after a zone failure, Direct Link is not inherently redundant, single-campus zones can share dependencies, and regional disaster recovery remains substantially the customer's responsibility.
• Data locality is also service-specific. IBM says customer content for regional and zonal services is stored and processed in the selected region, but account metadata and global control functions can be handled elsewhere. Backups, support access, cross-region copies and exit procedures therefore belong in the locality decision, not after it.

A region name is a claim on machines in particular buildings

Cloud geography is often rendered as a clean menu of city names. IBM Cloud's public documentation makes that abstraction unusually easy to take apart. Its location register describes a region as an independent geographic territory containing one or more zones, usually named after a metropolitan area. It currently lists full multizone regions in Dallas, Washington, Sao Paulo, Toronto, Frankfurt, London, Madrid, Sydney and Tokyo. It separately lists single-campus multizone regions in Chennai, Montreal, Mumbai and Osaka.

The distinction between the two kinds of region is not cosmetic. IBM says a full multizone region uses three or more data centres across separate sites, with independent power, cooling and network connectivity, and with at least one mile between zones. A single-campus multizone region places three zones in different parts of one building or in buildings on one campus. Its power, cooling, network and physical-security dependencies may overlap. IBM says the two forms carry the same service-level commitment, but it also warns that a data-centre disaster can affect an entire single-campus region because the zones are more tightly related.

That creates a useful first rule for buyers: the region label identifies a market and latency area, not a uniform quantum of physical independence. Three zones in Frankfurt are not physically equivalent to three zones on one campus in Montreal. Even within the full-region category, IBM publishes only a minimum separation, not the distance, floodplain, utility, conduit or carrier detail for every pair of sites. A buyer can know that the zones are intended as independent failure domains without knowing every mechanism by which those domains might still correlate.

IBM's register goes further by exposing the translation between logical and physical names. A VPC customer sees a zone such as us-south-1, but the account receives a mapping to a universal physical designation such as us-south-dal10-a. IBM says that mapping is established when the first VPC resource is created in the region and is determined by IBM. Dallas currently has four universal locations associated with DAL10, DAL12, DAL13 and DAL14, although the ordinary account-facing region presents three numbered zones. A customer can inspect the assignment after creation and may ask a technical account manager for a change in rare cases, but IBM evaluates such requests individually.

This matters when an organisation mixes VPC, Power Virtual Server and classic infrastructure. VPC uses the account's logical-to-physical mapping; classic and Power resources can be ordered against specific data-centre codes. IBM explicitly advises creating VPC resources first, inspecting the universal zone, and then locating the other resources in the same physical facility when colocation is intended. The city name alone is too broad for that task.

The current classic register names 42 data centres: 19 in the Americas, 12 in Europe and 11 in Asia-Pacific. It includes six Dallas sites, four Washington sites, four London sites and three each in several other markets. This is strong evidence of a working global hosting estate, not a speculative map. It also shows why a single number for "IBM Cloud regions" is misleading. VPC regions, single-campus regions, classic buildings, Power locations and network points of presence are related but not interchangeable units.

IBM says a classic data centre can contain multiple pods, each made up of racks, servers, networks, storage and backup generators. Placing servers across pods can improve availability, but the company cautions that data centres do not themselves provide isolation from multizone arrangements in the same location. A pod is a smaller failure and capacity domain inside a building; a zone is the unit customers use to separate VPC resources; a region groups zones; and a global control function can still sit above all of them. The physical purchase begins only after those layers are separated.

SoftLayer left IBM a hosting estate, not an infinitely elastic pool

The physical emphasis is partly inherited. IBM bought SoftLayer in 2013 and combined it with IBM SmartCloud. IBM's filing for that quarter records cash consideration of $1.977 billion. An IBM acquisition briefing described SoftLayer as a Dallas-based infrastructure provider serving 21,000 customers with dedicated servers, virtual servers and private clouds. The attraction was not merely software. It was an installed hosting system with customers, facilities, automation and a network.

That inheritance remains visible in the coexistence of classic infrastructure and VPC. Classic customers can still select a named data centre and order virtual or bare-metal servers against physical inventory. VPC presents more standardised zonal resources and software-defined networking. IBM now recommends VPC for many modern deployments, yet the classic estate and its operational assumptions remain important to existing customers, VMware deployments, hosting companies and applications built around SoftLayer-era networks.

The economics of that estate appear in IBM's own availability rules. The service rollout policy divides offerings into core and market-driven services. Core services, including VPC, Object Storage, Kubernetes, OpenShift, PostgreSQL and key management, are expected in every multizone region. Other services are deployed where customer demand justifies them. IBM says new core services should reach all multizone regions within 90 days of their first regional deployment and updates should follow within 30 days, but it expressly notes that hardware-dependent profiles and features are not available in every region.

This is the commercial logic behind the map. Opening a city does not mean installing every processor, accelerator, storage tier and appliance at unlimited depth. A provider has to decide how many racks to energise, which server generations to stock, how much network and storage headroom to reserve, and whether demand for a specialised service will repay local deployment and support. A service can be present in a region while a particular profile remains absent or scarce.

Dallas offers a concrete example of capacity following demand. IBM announced DAL14 as an additional VPC zone, describing it as the company's tenth Dallas data centre and the fourth availability-zone facility in that area. The announcement says the expansion adds capacity for VPC workloads and complements two network points of presence and other infrastructure in the market. The important word is capacity. A new zone is a capital and supply decision involving a building, electrical delivery, cooling, fibre, servers and operational coverage, not a new label added to a console.

IBM's company-wide environmental figures give a broad sense of the physical bill, although they must not be mistaken for IBM Cloud-only measurements. IBM reports that its data centres had a weighted average power usage effectiveness of 1.39 in 2025, that 85 per cent of their electricity came from renewable sources, and that 44 data centres were supplied with 100 per cent renewable electricity. The same energy disclosure says some renewable electricity arrives through landlords as well as direct power suppliers. It does not publish facility-by-facility Cloud consumption, contracted megawatts, grid constraints or backup-fuel duration. The aggregate establishes material operating effort; it cannot tell a Dallas customer which utility or landlord dependency sits beneath a particular zone.

Region choice therefore carries two prices. The visible price is the rate for compute, storage and traffic. The less visible price is the provider's decision to install enough suitable capacity in that location and the customer's decision to reserve or duplicate it. Low-latency local deployment, specialised hardware and deep spare inventory compete for the same racks and power. The map shows where IBM can sell; the order screen reveals what it can deliver now.

Installed capacity becomes usable only when the requested profile is free

IBM's bare-metal documentation is candid about inventory. Its server guide says customers can see which fast-provision servers are available in each data centre. If a selected server is unavailable, the ordering interface identifies other locations where that configuration exists. Fast-provision systems generally become configurable within 30 to 40 minutes, while broader bare-metal provisioning can take up to four hours. Optional extended hardware testing can add two hours, and IBM says critical test errors lead to component replacement before delivery.

This is installed capacity in its most literal form. A chassis has to be present, fitted with the right processor, memory and drives, connected to working network ports, pass stress tests and remain uncommitted. A data centre may be operational while a desired machine is unavailable. Moving to another building may solve the stock problem but change latency, fault separation, residency or cross-connect design.

Classic virtual servers expose the same constraint at a pooled level. IBM's capacity troubleshooting page documents an "insufficient capacity" error when a router or data centre lacks the resources to fulfil a request. Suggested responses include waiting, selecting another router or building, ordering fewer or smaller instances, spreading the request across data centres, or changing the storage type. The page also limits classic GPU provisioning to a named subset of facilities. Elasticity is real, but it is bounded by free hosts, network attachment, storage and a product catalogue tied to physical sites.

VPC capacity can be made more predictable through reservations. IBM offers one- or three-year commitments for a quantity and profile in a selected zone. It advertises discounts of up to 60 per cent for virtual servers and 55 per cent for bare metal, while dedicating the reserved capacity for the term. A bare-metal reservation holds capacity even before a server is provisioned. Reservation creation can still take time and can fail before capacity is dedicated.

The arrangement exposes the trade clearly. On-demand purchasing gives the customer flexibility but leaves immediate availability subject to the shared pool. A reservation reduces that uncertainty by paying for a committed claim on a specific profile and zone. It does not reserve every dependency around the server. Network bandwidth, storage, software, images, quotas, load balancers and recovery capacity have their own conditions. Nor does one reserved zone become a disaster-recovery site merely because the compute is guaranteed there.

Usable capacity also depends on generation and lifecycle. IBM says some mature facilities contain 1U single-socket servers without dual power feeds and advises customers who need power-supply redundancy to consider 2U chassis. Its current resiliency guidance says data centres have multiple power feeds, fibre links, generators and batteries, while still identifying this server-level exception. That is a useful warning against treating building redundancy as a property automatically inherited by every machine.

The distinction extends to software availability. All multizone regions carry a core set, but market-driven services can be absent, and a service's local data plane can depend on Object Storage, key management, databases, identity or network functions. A region may have ample general-purpose compute and still lack the exact hardware or managed service required by an application. Before calling a location viable, an operator has to test the whole bill of materials, including spare capacity for a failover day when many customers may be trying to provision at once.

IBM operates the cloud layer, while utilities, landlords and carriers remain underneath

IBM's shared-responsibility statement places facilities, physical networks, storage, hypervisors and physical servers under IBM's operational responsibility for public infrastructure services. Customers remain responsible for their data, applications and operating systems, while virtual servers, storage and networks are shared responsibilities. For disaster recovery, IBM provides the underlying services, but the customer must create resources in a second region and manage application and data recovery.

That responsibility statement is stronger than a promise to rent rack space. It says IBM is accountable to the customer for the physical layer beneath the public service. It does not establish that IBM owns every building, utility connection or metro fibre route. The public location list identifies Chennai and Mumbai regions with Airtel in their names, and IBM's energy reporting refers to renewable electricity obtained through landlords. IBM also describes Direct Link arrangements that require outside connectivity providers and customer-funded cross-connects. The estate therefore has several operator boundaries even when IBM remains the contractual cloud operator.

At the facility level, IBM advertises N+1 power and cooling and 24-hour physical security on its global data-centre page. Its deeper resilience document says sites use multiple feeds, dedicated generators and batteries. Those statements support the existence of engineered backup systems. They do not disclose utility substations, fuel contracts, runtime under load, generator test outcomes, water dependencies, switchgear manufacturers or whether two nominal feeds share an upstream grid element.

The public incident archive shows why those missing details matter. IBM retains analysis reports for major events for five years. Its incident index includes a utility-grid outage affecting FRA05 in July 2023, a fire affecting the Seoul 01 data centre in October 2022, a Washington power outage in April 2021, a cooling-infrastructure power failure at SAO01 in December 2020, and network disruptions tied to named facilities and pods. The titles alone do not establish present weakness or reveal every remedial action. They demonstrate that grid, fire, cooling, building network and pod failures are real categories in this estate, not remote hypotheticals.

A resilient purchase therefore has to be tested at several boundaries. Does a workload occupy one machine, multiple machines in one pod, multiple pods in one building, or separate zones? Are the selected zones on distinct sites or one campus? Do both sites depend on the same metro carrier corridor? Is the second copy of data in another zone, another region, or only on a redundant device in the same room? Does the recovery region have enough compatible compute and managed-service capacity? Each answer changes what the customer actually survives.

The limits of public disclosure should also be kept visible. IBM does not provide a site-by-site ownership register, utility diagram, generator runtime table, rack inventory or map of metro fibre conduits. Its zone design and incident history are substantial evidence, but they do not permit an outsider to verify physical diversity down to every lease, feeder and duct. Large regulated customers may be able to obtain dependency reports under confidentiality; IBM says such reports can be requested through compliance support. Public buyers should not silently assume the same detail exists in ordinary product pages.

The backbone is extensive, but the customer's private entrance starts as one path

The network is one of IBM Cloud's best-documented physical systems. A physical infrastructure guide describes separate public and private networks, paired customer switches and routers inside data centres, and multiple carrier connections at data centres and network points of presence. It says traffic between facilities uses multiple 10 or 40 Gbps backbone connections. Individual VMware-oriented bare-metal hosts can receive redundant 10 or 25 Gbps connections into separate top-of-rack switches for both public and private networks.

IBM also says traffic between its data centres stays within its backbone and autonomous system rather than crossing other networks. The private connectivity description presents this backbone as a global system joining resources within zones, between zones and across regions. At the public edge, IBM's peering policy requires operational peers to maintain routing records and a 24-hour network contact.

There is independent corroboration, with limits. PeeringDB's public record for AS36351 identifies SoftLayer Technologies, an IBM company, also known as IBM Cloud. In July 2026 it reported 1 to 5 Tbps of traffic, about 1,800 IPv4 prefixes, 450 IPv6 prefixes and connections at exchanges in several continents. PeeringDB is operator-maintained rather than an audited capacity statement. It supports the existence and broad reach of the network; it cannot prove actual traffic, private backbone routes, congestion headroom or fibre diversity between any two IBM facilities.

IBM's own backbone claim is ambitious: its resilience page says diverse telecommunications providers are used wherever possible, dark-fibre providers connect edge sites to regional compute facilities, and edge sites have redundant links toward other regions. "Wherever possible" is an important qualifier. Route diversity depends on local market structure, building entrances and the upstream physical paths available. Two contracts can still share a duct, bridge, exchange building or long-haul cable.

The customer's entrance to that network has a separate design. Direct Link supplies a private Layer 3 connection from an outside network into IBM's private backbone, with speeds up to 10 Gbps. The service is useful for predictable latency, hybrid applications and bulk transfer, but IBM states that redundancy is not included automatically. A customer needs two connections on diverse cross-connect routers and must configure routing between them.

The Direct Link prerequisites are even plainer. IBM calls each connection an unprotected path. The customer pays the provider and cross-connect costs needed to reach IBM's point of presence, and must decide between two routers in one location or geographically separate locations. IBM will not host customer equipment in ordinary network points of presence. The customer or its carrier owns the route from its premises or colocation space to the IBM demarcation.

This means two order numbers are not sufficient evidence of physical diversity. IBM's Direct Link guidance requires separate cross-connect routers and customer-controlled BGP policy. It warns that equal-cost paths can terminate on the same router, preserving a single point of failure. For stronger protection, the buyer must verify carrier, building entrance, cross-connect router, point of presence and, where necessary, metro diversity.

The backbone can also become a dependency for locality and recovery. Local routing limits a Direct Link to the associated market; global routing opens access to other IBM regions. That can simplify a second-region design, but it places more recovery traffic on long-haul paths and requires the customer to understand which routes and controls become global. A private circuit is not equivalent to a physically independent recovery site, and a second region is not useful if both customer links fail in the same trench.

Multizone does not move a zonal server when its zone disappears

IBM's VPC high-availability guidance draws a crucial line between what the platform protects and what the customer must construct. The VPC control plane is distributed across zones and separated from the data plane. Existing resources can continue running through some control-plane failures even when customers cannot create or modify infrastructure. Most data-plane resources, however, are zonal. Subnets, public gateways, virtual endpoints and virtual servers live in particular failure domains.

If a complete zone fails, IBM says the virtual servers in that zone become unavailable and are not moved into a healthy zone. Resources in other zones continue, and regional services can remain available, but customer applications survive only if they were already distributed and able to fail over. A multizone region is therefore an opportunity to buy separation. It is not an automatic three-way copy of everything provisioned in one zone.

Host failure is narrower. Under the default VPC recovery policy, IBM can detect a failed host, move an affected virtual server to available hardware in the same zone and restart it. Ephemeral data is not restored, and unsaved writes can be missing. This protection also assumes suitable hardware remains available in that zone. It recovers a machine from a host fault; it does not recover the application from a zone or region fault.

Storage follows its own boundaries. Block volumes use redundant hardware, but IBM warns that a zonal disaster or multiple hardware failures can still make a volume unavailable. Snapshots are held in regional Object Storage and can create a volume in another zone. Cross-region snapshot copies can support a wider recovery, but restoration is not instant. IBM says a full copy of a 3 TB volume to another region can take up to 12.5 hours, and normal restoration can run with degraded performance while data is copied into the new volume.

Bare metal has fewer automatic protections. IBM says local disks on VPC bare-metal servers do not support its snapshot mechanism, leaving backup and restoration to the customer. Classic bare-metal documentation similarly says IBM does not perform backups of customer devices; an account user has to initiate scheduled or one-time backups. A dedicated machine removes noisy-neighbour sharing at the processor, but it makes hardware replacement, local storage and recovery preparation more visible.

The public incident archive also contains failures that crossed a simple physical boundary. It lists failures accessing and managing cloud services across multiple regions in June 2025, availability issues for clients in all regions in June 2022, a console outage in October 2023 and a VPC Private DNS event in June 2021. These reports do not mean every running workload failed. They show that management, naming and shared service dependencies can have a different blast radius from a rack or zone.

IBM's general resilience document acknowledges the structure. Global services handle identities, accounts, billing, catalogues and support functions across the estate. Some service control functions, including classic infrastructure management, IP address management, DNS, Transit Gateway, Direct Link and Object Storage provisioning, have global components. IBM designs these for redundant operation, but an event affecting their hosting regions can impair management operations elsewhere. Existing data planes may keep serving traffic while new servers, route changes or recovery actions are blocked.

That is the hard test of a recovery architecture: not whether the primary application keeps serving ordinary requests, but whether administrators can authenticate, allocate addresses, provision capacity, change DNS, attach storage and open a support case during the same event. A warm second site reduces dependence on emergency provisioning. A cold plan that assumes every control function and profile will be available after a broad incident carries more execution risk.

Support, billing and lifecycle decisions are infrastructure dependencies too

When hardware, routing or control functions fail, recovery depends on people with access to the relevant systems. IBM offers several support levels, and their differences are operationally significant. Its support severity table defines Severity 1 as a down service or inoperable business-critical function. Premium support has an initial-response objective of less than 15 minutes; Advanced aims for one hour; Basic has no initial-response objective. IBM stresses that these are goals rather than guarantees and that the customer must make technical staff available for continuous work on a Severity 1 case.

Billing, invoice and sales cases are excluded from those response objectives. That detail matters because billing can affect the service layer. IBM's Direct Link troubleshooting page says a private connection can enter suspended status because of a missed payment and directs the customer to support. Its VPC documentation says suspended virtual servers and bare-metal systems are powered off and cannot be used or modified when a resource is suspended for terms violations. These are different situations, but both show that account administration can reach into network and compute availability.

IBM publishes service-level objectives for high-availability configurations, including 99.999 per cent for VPC and 99.9999 per cent for the cloud network. The SLO page explicitly says an objective is not a warranty and does not trigger credits. The separate service-level agreement explanation describes credits against charges when a covered service misses its contractual availability target. Neither an objective nor a credit repairs lost revenue or reconstructs data. Buyers need to inspect the applicable service description, required topology, exclusions and claim procedure rather than convert a percentage into assumed application uptime.

Lifecycle decisions can be just as physical as outages. IBM says some older data centres cannot be upgraded and must close. Its current modernisation notice schedules CHE01 in Chennai to cease operations on 10 June 2027. New provisioning becomes progressively restricted, platform services have an earlier migration deadline, and IBM warns that no extension is available. The company points customers toward newer Chennai and Mumbai multizone regions.

This is not evidence that IBM Cloud is retreating from India. It is evidence that a data-centre code is not permanent. Building power density, network design, equipment age, landlord terms and upgrade feasibility eventually change the economic answer. IBM can add DAL14 in a growing market while closing a Chennai site that it says is unsuitable for modernisation. Customers bear the application work required to follow those estate decisions.

The operating relationship is therefore broader than uptime. It includes support entitlement, accurate billing contacts, purchase-order and card continuity, renewal of reserved commitments, awareness of end-of-service notices, and enough lead time to rebuild elsewhere. A cloud administrator who cannot see invoices, approve capacity or receive service notices can become a single point of failure even when every server is healthy.

Recovery is a capacity and data-movement exercise, not a checkbox

IBM recommends distributing scalable applications across zones behind load balancers and using another region for disaster recovery. It provides cross-region snapshot copies, file replication, Object Storage, infrastructure definitions and APIs. But its VPC guidance assigns the regional recovery action to the customer: create resources in an available location, restore data and redirect the application. It advises customers to keep configuration outside the failed region, practise the steps and consider pre-provisioning resources to ensure availability.

Pre-provisioning deserves emphasis. A regional incident can create correlated demand for the same server profiles in the recovery market. An untested plan may discover that quotas are too low, a profile is unavailable, a key service is absent, a Direct Link reaches only the local market, or a snapshot copy is still moving. Paying for warm capacity appears inefficient during normal operation because its value is the ability not to compete for stock during an abnormal one.

Object Storage illustrates how a single product name can contain different physical resilience. IBM says data is encrypted, erasure-coded and dispersed across three locations, but the distance between those locations depends on the chosen class. Its bucket guidance distinguishes cross-region storage spread across metropolitan areas, regional storage spread across a single metro, and single-data-centre storage spread across devices in one site. The customer chooses the location and resilience when creating the bucket.

The bucket cannot simply be retagged into another place. IBM says changing location requires creating a new bucket and moving the data. Its copy guide uses the open S3-compatible rclone utility, but warns that bucket settings and object metadata are not all copied automatically. Encryption, retention, archive behaviour, access policy and other features must be recreated and verified. Private endpoints can avoid some network egress charges when the transfer runs on IBM infrastructure.

Block storage is similarly bounded. A cross-region snapshot is an independent copy once stable, but the first transfer is full, larger copies take longer, and charges apply for transfer and destination storage. The snapshot documentation says only one copy of a particular snapshot can exist in each region. A consistency group cannot be copied as a group, so a multi-volume application's write consistency and recovery order require separate attention.

Classic-to-VPC movement adds architectural work. IBM's migration guide describes rebuilding equivalent infrastructure in VPC, remapping VLANs to zone-specific subnets, recreating security, attaching new storage, moving data and updating DNS. A profile change requires stopping and starting a VPC server. This is a controlled rebuild, not a live relabelling of the old machine.

For the data itself, IBM estimates that copying 1,000 GB with rsync can take from 2.5 hours to more than 12 hours, and millions of small files can take days. Its classic data migration guidance attributes the range to file count, disk performance, network capacity and usage. During final cutover, an application may need a write freeze, incremental synchronisation and a rollback decision. The larger the state, the more the migration becomes a bandwidth and business-continuity project.

Leaving IBM Cloud also varies by service. Object Storage provides an S3-compatible export surface and documents data portability, but IBM assigns customers responsibility for alternative infrastructure, application changes, configuration conversion and transfer execution. Bare-metal operating systems and open application stacks can be portable in principle while still depending on IP addresses, appliance licences, network assumptions or IBM-specific services.

IBM's current terms add jurisdiction-specific relief. Its Cloud terms page says EU clients planning to move data out can receive reduced egress charges under the EU Data Act, while clients in France can request an egress-charge waiver under the French SREN law. Those rights can reduce one cost of exit; they do not reduce data volume, application coupling, validation time or the need for a target platform.

The practical portability test is therefore an actual restore outside the primary account and, for critical systems, outside the provider. Can the organisation recreate identity, keys, DNS, network policy, machine images, databases and monitoring from material it controls? How long does the largest stateful transfer take? Which features disappear at the destination? A successful file download proves possession of bytes. It does not prove service recovery.

Local data does not make every operational dependency local

IBM's data-residency guidance says customer content supplied to regional and zonal services is stored and processed locally in the selected region. It also says encrypted backups can remain in that location. This is a meaningful commitment for organisations choosing a country or metropolitan area for regulated or latency-sensitive data.

The same page distinguishes customer content from account metadata. Business contacts, usage information and other client metadata can be stored and processed where regional or global control planes operate. The global resilience documentation places account management, identity, billing, catalogues and support functions above individual regions. A region selection therefore answers where a service's content runs only to the extent defined for that service. It does not mean every log, credential exchange, support record or administrative action remains inside the same border.

Support access is another layer. IBM lets an account owner enable EU Supported service, which routes tickets to European support teams and limits service delivery to that region in the ordinary case. IBM still says teams outside the EU may be contacted when the European team cannot resolve a case, subject to EU review, time-limited access and privacy controls. The setting improves operational locality; it is not an absolute assertion that no expertise outside Europe can ever participate.

Resilience can pull in the opposite direction from strict locality. A regional Object Storage bucket spreads data within one metropolitan area. A cross-region class or remote snapshot increases geographic separation but places data in additional locations. Copying a Frankfurt workload to London crosses the EU boundary; copying it to Madrid may remain inside the EU but introduces a second national jurisdiction and different network paths. A company has to choose a recovery geography that satisfies both hazard separation and legal rules.

Single-campus regions sharpen the issue. An Osaka or Montreal deployment may satisfy national residency and offer three zones, yet IBM warns that campus dependencies can overlap and a data-centre disaster can affect the region. A second multizone region may improve disaster tolerance, but the available destination, service catalogue and legal treatment need to be checked. Residency is a boundary condition on resilience, not a substitute for it.

The physical operator boundary matters as well. A cloud provider can commit to local processing while using a landlord's building, a local utility, outside fibre providers and global corporate support. Data sovereignty involves legal authority and operational control in addition to storage location. IBM itself explains the distinction on its data sovereignty page: residency concerns where data is physically held, while sovereignty concerns the laws that apply. Customers should read service-specific terms and obtain appropriate advice for their obligations rather than infer sovereignty from a city name.

An effective locality record should identify the physical region, service scope, backup location, control-plane exceptions, support setting, encryption-key location, staff access rules and recovery destination. It should also be revisited when IBM changes a service's regional availability or closes a data centre. Geography is not a field selected once at purchase; it is a continuing property of the architecture and contract.

What IBM Cloud proves, and what a serious buyer should still verify

The operating evidence for IBM Cloud is strong. The company publishes current facility codes, VPC-to-building mappings, network points of presence, physical network design, inventory behaviour, capacity errors, reservations, resilience boundaries, migrations, closure dates and major incident reports. Its PeeringDB record and long-lived autonomous system independently support an active internet footprint. This is far beyond a thin website or a collection of untested announcements.

Strong evidence does not make every claim complete. IBM's public pages do not identify facility owner, utility topology, fuel duration, installed megawatts, rack occupancy, free inventory, metro fibre ducts or carrier contracts for each zone. They do not publish a current capacity margin for recovery events. Even the physical distance between full-region zones is given only as a minimum. The broad architecture is visible; the site-by-site concentration risk is not.

For a production deployment, five confirmations would materially improve the purchase. First, map every logical zone in the account to its universal physical location and distinguish full multizone from single-campus regions. Second, confirm that the required compute, accelerators, storage, managed services and quotas are available in both primary and recovery locations, with reservations where shortage would be unacceptable. Third, document Direct Link carrier, router, point-of-presence and physical-route diversity rather than counting circuits.

Fourth, measure recovery. Copy realistic data, restore it, provision replacement capacity, rotate keys, update DNS and record the result under the support plan actually purchased. Include a scenario in which the console or a global control function is unavailable while existing workloads continue. Fifth, document the exit path, including configuration that must be recreated, addresses that change, transfer throughput, egress treatment and the contractual notice period for closure or service withdrawal.

These tests identify who is affected by each failure. A single host fault may interrupt one virtual server until restart. A zone event affects every unreplicated resource there. A campus event can threaten all three zones of a single-campus region. A metro carrier cut can isolate customer premises even while IBM's cloud remains healthy. A global identity or management incident can block administrators across regions. A billing suspension can disable a private connection. A closure can force every remaining customer in one building to migrate on a fixed timetable.

IBM Cloud's value is not that these dependencies disappear. It is that a large portion of them is exposed as selectable infrastructure and operated under a substantial service organisation. The customer's job is to buy enough separation, reserve enough capacity and preserve enough independent state to survive the dependencies IBM does not absorb.

That is why region choice is the right centre of the IBM Cloud proposition, but only when read physically. Dallas is not a coloured dot. It is a set of named buildings, account-specific zone mappings, pods, stocked servers, power systems and metro links. Frankfurt is not a sovereignty guarantee. It is a location commitment with support, metadata and recovery qualifications. Direct Link is not redundancy. It is one private path until a second path, separate router and working routing policy make it more.

The map is credible. The responsibility hidden inside each dot is the product.