---
title: "Global Data Center Hubs: From Metro Shortlist to Actual Site"
description: "Leviathan Systems — Technical content Published 2026-10-15; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/global-data-center-hubs-site-shortlist"
last-updated: "2026-10-20"
---

# Global Data Center Hubs: From Metro Shortlist to Actual Site

Leviathan Systems — Technical content
Published 2026-10-15; updated 2026-10-20.

A global data center shortlist should identify the actual facility and deployment conditions behind each metro name. Northern Virginia, Frankfurt, London, Tokyo, Singapore and São Paulo provide useful examples, but a hub label does not establish available GPU capacity, a suitable rack location or permission to perform field work. Compare the same evidence for each option before choosing a site.

## Define the job before choosing a hub

Start with the deployment being considered: customer-owned equipment in colocation, a provider-operated GPU service, or another arrangement with a defined owner for each layer. A market with a substantial colocation footprint does not automatically offer the GPU model, software stack or tenancy arrangement a cloud buyer needs. A cloud region name is also insufficient to release a physical installation package.

Write down the workloads, data dependencies, users and required delivery window. Identify which conditions are mandatory and who can accept a proposed exception. If the application owner requires a specific relationship to an existing system, preserve that requirement through the comparison instead of replacing it with a general statement that the metro is well connected.

This guide uses six operator-documented examples to show how to read a shortlist. They are selected examples across several regions, not a ranking of the largest markets, an exhaustive directory or a claim that Leviathan has teams stationed in them.

## Read six market examples at the right geographic level

Equinix's Washington, D.C. page lists sites in Ashburn and Manassas; its Frankfurt page distinguishes central and campus locations. Digital Realty's Tokyo listing includes Mitaka in Tokyo and Inzai in Chiba, while its Singapore listing separates Jurong East and Loyang facilities. Equinix's Brazil listing identifies SP2 in Barueri and SP3 in Santana de Parnaíba, in São Paulo state. These examples make the exact facility identifier more useful than a metro label alone.

London adds a different distinction: Colt DCS describes London 6, 7 and 8 at its Hayes campus as planned development. A planned building should remain a prospective option until its relevant phase and customer delivery conditions are confirmed. None of the sources below establishes an allocation for the reader's project.

References: [E1](https://www.equinix.com/data-centers/americas-colocation/united-states-colocation/washington-dc-data-centers), [E2](https://www.equinix.com/data-centers/europe-colocation/germany-colocation/frankfurt-data-centers), [D1](https://www.digitalrealty.com/data-centers/asia-pacific/tokyo), [D2](https://www.digitalrealty.com/data-centers/asia-pacific/singapore), [E3](https://docs.equinix.com/colocation/availability/), [C1](https://www.coltdatacentres.net/en-GB/our-locations/data-centre-locations-europe/london-6-7-8)

Six primary-source market examples and the next evidence question
| Market example | Specific operator evidence | Question for the shortlist | Source |
| --- | --- | --- | --- |
| Northern Virginia / Washington, D.C., United States | Equinix identifies DC13 in Ashburn and DC14 in Manassas. | Which building and municipality are in the actual offer and delivery plan? | E1 |
| Frankfurt, Germany | Equinix lists FR7 in central Frankfurt and FR13 on its North-East campus. | Which site, campus connections and facility conditions apply to this option? | E2 |
| London, United Kingdom | Colt DCS identifies London 6, 7 and 8 as planned Hayes campus development. | Is the option an existing allocation or a proposed future phase, and who confirms the usable delivery window? | C1 |
| Tokyo metro, Japan | Digital Realty lists HND10 in Mitaka and NRT10 in Inzai, Chiba. | Have the actual endpoints, site address and access logistics been assessed rather than inferred from Tokyo branding? | D1 |
| Singapore | Digital Realty lists SIN10 in Jurong East and SIN11/SIN12 in Loyang. | Which facility and connection endpoints are included in the proposal? | D2 |
| São Paulo metro, Brazil | Equinix's Brazil list identifies SP2 in Barueri and SP3 in Santana de Parnaíba. | Does the local delivery package use the actual municipality, facility and authorized receiving process? | E3 |
Original selection worksheet based on operator pages checked October 15, 2026. No available capacity, GPU suitability, price, certification, latency or service coverage is inferred from a listing.

## Make hard constraints visible before scoring preferences

A weighted score can hide a fundamental mismatch. Keep mandatory conditions visible before comparing preferences such as convenience or expansion options. An unconfirmed requirement should remain open; it should not receive a neutral score that makes the option look equivalent to a confirmed one.

Use a compact evidence record for each candidate facility. Describe the required condition, the evidence received, its date and applicable scope, and the person who can accept it. A provider's general capability statement and a customer-specific approved proposal answer different questions. Neither should be silently substituted for the other.

Original facility-shortlist evidence record
| Constraint | Evidence to obtain | Responsible owner to identify | Source |
| --- | --- | --- | --- |
| Workload and data location | Application requirements and any company-approved location constraints | Application, data and appropriate legal/security owners | Planning analysis |
| Equipment and physical fit | Exact delivered system, approved location and applicable facility/OEM interface records | Configuration, facility and qualified technical owners | Planning analysis |
| Capacity and timing | The actual proposed allocation, applicable phase, dependencies and delivery conditions | Customer and provider commercial/delivery owners | Planning analysis |
| Network relationships | Named source/destination endpoints, proposed services and acceptance responsibility | Network and provider owners | Planning analysis |
| Local execution | Confirmed receiving, access, authorized work and accountable resources | Customer, facility and approved local delivery owners | Planning analysis |
| Handoff | Required records, formats, open-item treatment and accepting team | Project and operations owners | Planning analysis |
Original documentary planning fields. This is not a facility certification, network design, legal assessment or installation procedure.

## Compare power at the customer delivery boundary

A campus power headline and the power offered to one customer describe different boundaries. The first may describe a development or an aggregate facility; it does not identify the load allocated to a specific cabinet, deployment or equipment configuration. A useful site comparison keeps the proposed customer allocation and its applicable phase, unit and conditions beside the original campus statement. Do not rank an option as adequate merely because its larger number belongs to a larger boundary.

Equinix provides a concrete terminology example. Its colocation documentation describes a deployment-wide customer-load limit called a Draw Cap, measured in kVA, and separately describes the circuits delivering power to cabinets. This distinguishes an agreed load boundary from physical supply infrastructure. The site's actual provider offer and applicable conditions must identify both. Redundant circuit labels are not permission to add their ratings and call the result the customer's permitted load. This is a named provider example, not a rule for every contract or an electrical design for this project.

Keep the original unit with each requirement and return. A kW equipment requirement and a kVA offer are not the same field with different spelling. The responsible equipment and electrical/facility owners must supply the applicable comparison basis; the buyer should not invent a power factor or conversion to close the gap. Likewise, a power-supply rating, actual equipment demand, contractual allocation and measured operating value have different meanings. Retain the meaning, configuration, equipment state and source rather than substituting one for another.

For each candidate, obtain a return against the same identified equipment set, installation phase and required window. Ask the provider and qualified technical owners to identify the applicable customer power allocation, supply/interface documentation, unresolved facility conditions and their separate dispositions. Keep cooling and physical delivery dependencies visible even when a power answer is returned. A confirmed commercial allocation would not, by itself, approve the actual electrical connection, equipment placement or completed installation.

References: [P1](https://docs.equinix.com/colocation/about/colo-power/)

Read power evidence at the boundary it actually describes
| Evidence in a site comparison | Meaning to retain | Comparison still required | Source |
| --- | --- | --- | --- |
| Campus or development headline | Named facility/phase, published boundary and original unit. | Actual customer allocation, usable phase and applicable delivery conditions. | Planning analysis |
| Customer load allocation | Exact deployment/cabinet scope, stated unit and conditions in the actual provider return. | Same equipment requirement and approved comparison basis; no invented conversion. | P1 |
| Physical supply interface | Applicable circuit/interface records for the identified site and deployment. | Qualified facility/equipment disposition; a circuit label alone is not a customer load approval. | P1 |
| Equipment demand or rating | Exact system/configuration/state and the meaning of the cited value. | Whether that value is the right basis for the actual customer allocation and facility assessment. | Planning analysis |
Original buyer comparison. No power values, conversion, protection/circuit selection, electrical work, capacity result or site approval is supplied.

## Separate present sites from future capacity

Use separate fields for the facility's described status and the status of the capacity being offered. An operating campus can have an expansion that is still planned. A future phase can also appear in the same operator portfolio as operating buildings. Keep the phase identifier beside every quoted delivery statement.

Digital Realty's August 24, 2026 announcement describes a provisional capacity allocation for a new Jurong Island development. That announcement is different evidence from the operator's Singapore facility listing. It is not proof that the new development can accept a customer's equipment now. The same distinction applies to Colt's planned Hayes buildings.

When sources disagree or an older announcement gives a different target, retain the discrepancy and ask the responsible provider for the current applicable position. Do not choose the most convenient date or add a planned quantity to a figure for operating supply. The decision record needs the condition that actually governs the proposed deployment.

References: [D3](https://investor.digitalrealty.com/news-releases/news-release-details/digital-realty-selected-develop-50-megawatts-new-data-center), [D2](https://www.digitalrealty.com/data-centers/asia-pacific/singapore), [C1](https://www.coltdatacentres.net/en-GB/our-locations/data-centre-locations-europe/london-6-7-8)

## Connect the capacity claim to the specific installation

A metro total, campus headline and proposed customer allocation are different quantities. Even a correctly quoted power figure does not identify the approved rack positions, supported equipment arrangement or service access for a particular installation. Keep the original unit, measurement boundary, phase and source attached to every number that enters the project record.

For a physical deployment, carry the exact system configuration into the facility review. A change from one enclosure to another can affect interfaces and access even when the GPU family name stays the same. Return unresolved compatibility questions to the responsible OEM and facility owners rather than assuming that a market described as suitable for AI has approved every GPU server.

For provider-operated compute, ask a separate availability question about the requested service, location and time window. A physical-building listing is not an account quota, a reservation or a promise of usable GPU instances. Keep that procurement path separate from an installation brief for customer-owned equipment.

## Compare network endpoints rather than city reputation

Describe the relationships the deployment needs: the existing data location, the application users, the receiving environment and the relevant provider endpoints. Then identify the proposed connection at the actual candidate building. A cloud logo on a metro page does not, on its own, describe the route, ordered service or customer acceptance conditions.

Keep requirements and observations separate. A statement that a workload needs a particular network outcome is not evidence that a candidate meets it. Ask the network owner to define the applicable evidence and acceptance conditions; this article supplies no universal latency threshold or test method.

The geographic examples above also matter to logistics. A project record saying only Tokyo or São Paulo can conceal a different municipality or campus from the one the team expects. Use the provider's exact site identifier throughout the endpoint, receiving and access records so the project is discussing one location consistently.

## Trace the fiber offer through the customer handoff

Fiber available in the metro is not a complete connection description. Name the actual source and destination facilities, service type, physical demarcation points and the customer equipment endpoints. Then identify which party supplies each intervening segment and which proposed phase and service window the return covers. A provider's presence in the building or an attractive network map cannot fill an unnamed endpoint or establish permission for work on provider-controlled infrastructure.

Equinix's Cross Connect documentation describes delivery through an approved demarcation point and distinguishes patching from that point to the customer's equipment. Its Fiber Connect documentation separately states that its published measurements are panel-to-panel and exclude the customer cage-to-panel connection. These examples show why a service description and an entire equipment-to-equipment path can cover different scopes. They do not prescribe a customer cabling method, make another provider use the same boundary or prove that any service is currently available.

Carry the complete intended relationship into the physical deployment brief. An ordered provider segment, customer-side patching, equipment interface and network/service acceptance need their own named scope and accountable return. Keep any unassigned segment explicit rather than treating an installed panel or a received cross-connect ticket as completion of every downstream task. A defined pair of endpoints also does not establish path diversity, latency, supported optics, configured service or workload performance.

Fictional EX-SITE149 compares options A and B for one identified equipment set and required deployment window. The four records below deliberately use different evidence boundaries. They do not score, select or approve either site. Each unresolved field goes back to the owner who can supply the actual basis; the next comparison uses those returned facts with the same equipment, phase and window. Only afterward can the appointed parties decide the facility and the separately authorized installation package.

References: [X1](https://docs.equinix.com/cross-connect/installation/xc-demarcations/), [X2](https://docs.equinix.com/cross-connect/fc-fiber-connect/)

EX-SITE149: four comparison records do not amount to an approved site
| Candidate and record | Evidence described in the fictional return | Unresolved boundary and owner return | Source |
| --- | --- | --- | --- |
| A / power | A customer allocation is identified with its stated unit and deployment scope. | Equipment demand/comparison basis is missing; provider and qualified equipment/facility owners must reconcile the actual basis. | Planning analysis |
| A / fiber | Two provider panels are identified for the quoted service segment. | The customer-side equipment connection is unassigned; customer/provider delivery owners must define the complete scope. | Planning analysis |
| B / power | A campus development statement is supplied. | No customer allocation or applicable delivery phase is supplied; the provider must return that specific proposal. | Planning analysis |
| B / fiber | The requested source and destination are identified. | No confirmed service window for the proposed phase is supplied; network/provider delivery owners must resolve that dependency. | Planning analysis |
Wholly fictional four-record comparison across two sites, with four open returns. No measurements, actual offer, accepted power, connected fiber, ranked winner or installation permission.

## Work through a shortlist discrepancy

Consider a hypothetical two-option review. Option A has a proposed location in an operating building, but the customer's network dependency is unresolved. Option B has an attractive future expansion description, but no project-specific allocation or accepted delivery window. Neither is ready for a final commitment merely because the broader metro is established.

The coordinator records a named network owner and required evidence for Option A, and a provider delivery owner for Option B. The next review evaluates the answers rather than refreshing a generic market score. If the provider changes a building, phase or configuration, the affected evidence is reviewed again. A previous decision about another location does not automatically transfer.

This example is an original planning scenario, not a description of an actual Leviathan customer. It illustrates a useful output from market research: a short list of decisions that can be closed, with the source and owner required for each one.

## Turn the selected site into a local release package

Once a location is selected, preserve the same facility identity in the equipment list, drawings, connection records and installation scope. Identify the receiving and access process, customer-furnished materials, approved workfront, expected work window and accepting owner. A site's selection does not itself authorize an installer to perform every task within it.

For an international program, keep the local document language, original measurement units and dated time-zone reference visible. Assign country-specific commercial, entry/work authorization, shipping, insurance and regulated-work questions to the responsible company and qualified local owners. A shared global template helps retain information, but cannot establish those permissions.

Leviathan's confirmed public description supports U.S. projects subject to scope, site requirements and team availability. International field coverage and local authority must be established separately before being offered. This guide describes market and project planning; it does not announce foreign offices, stationed teams, a hosting service or new electrical, cooling or commissioning capabilities. Identify the appointed equipment/material supplier and delivery responsibilities; a global market guide does not establish country-specific delivery or operating authority.

References: [L1](https://www.leviathansystems.co/about)

## Keep the shortlist useful as information changes

Record a checked date and source for each fact, and keep the provider's original terminology with it. When a proposal changes, review the affected facility, phase, equipment or connection evidence instead of treating the entire metro record as current by default. Preserve both the unresolved question and its final disposition so another reviewer can understand why the choice changed.

The useful result is a defensible facility comparison and a clear next action. It need not contain every data center in a country or award a universal best-hub label. Start a physical-scope discussion with the exact site, system list, available drawings and the work being requested; retain separate owners for decisions outside that package.

## Common planning questions

### Which is the best global data center hub for a GPU deployment?

There is no winner established here. Compare the specific facility, equipment/service model, data and network requirements, proposed capacity phase and delivery conditions. The six examples illustrate the evidence to obtain rather than rank markets.

### Does a listing prove a facility has available GPU capacity?

No. Identify the exact provider offer, requested deployment and time window. A site page, future development announcement and project-specific allocation are different evidence.

### Does Tokyo, London or São Paulo always identify one municipality or building?

No. Commercial metro labels can cover multiple locations. Preserve the actual provider site identifier, address and local project authority in the decision record.

### Does this guide mean Leviathan has an installation team in every market listed?

No. The examples are educational. International delivery capability and local authorization must be established separately for the actual country and engagement.

### Can redundant power circuits or a campus megawatt headline establish the customer load allocation?

No. Retain the actual customer allocation, its unit, deployment/phase and conditions separately from supply-interface records or aggregate development figures. Have the responsible provider and qualified technical owners reconcile the applicable equipment basis; this guide supplies no electrical conversion or capacity approval.

### Does a panel-to-panel fiber service include the full path to customer equipment?

Use the actual service boundary. The cited Equinix example excludes the cage-to-panel connection from its published measurements, and its demarcation documentation distinguishes customer-side patching. Identify every segment and responsible owner; do not infer a complete configured or accepted equipment-to-equipment service.

## Primary sources

- [E1 — Equinix Washington, D.C. data center locations](https://www.equinix.com/data-centers/americas-colocation/united-states-colocation/washington-dc-data-centers). Checked 2026-10-15. DC13 Ashburn and DC14 Manassas examples only. No rankings, capacity allocation, performance or provider SLA adopted.
- [E2 — Equinix Frankfurt data center locations](https://www.equinix.com/data-centers/europe-colocation/germany-colocation/frankfurt-data-centers). Checked 2026-10-15. FR7 central Frankfurt and FR13 North-East campus identifiers only; no general AI suitability or customer-specific availability inferred.
- [D1 — Digital Realty Tokyo metro facilities](https://www.digitalrealty.com/data-centers/asia-pacific/tokyo). Checked 2026-10-15. HND10 Mitaka and NRT10 Inzai/Chiba location examples. Aggregate statistics, performance and certifications are not adopted.
- [D2 — Digital Realty Singapore metro facilities](https://www.digitalrealty.com/data-centers/asia-pacific/singapore). Checked 2026-10-15. SIN10 Jurong East and SIN11/SIN12 Loyang identifiers only; no current available allocation or interconnection acceptance inferred.
- [D3 — Digital Realty Singapore Jurong Island development announcement, August 24, 2026](https://investor.digitalrealty.com/news-releases/news-release-details/digital-realty-selected-develop-50-megawatts-new-data-center). Checked 2026-10-15. Provisional allocation and new development status as described in this dated announcement; not operating customer capacity or an offer.
- [E3 — Equinix colocation location and coverage listing: Brazil](https://docs.equinix.com/colocation/availability/). Checked 2026-10-15. SP2 Barueri and SP3 Santana de Parnaíba location identifiers only. The listing is not available-to-order capacity and no operational coverage promise is adopted.
- [C1 — Colt DCS London 6, 7 and 8 planned Hayes campus development](https://www.coltdatacentres.net/en-GB/our-locations/data-centre-locations-europe/london-6-7-8). Checked 2026-10-15. Planned development classification only. No numerical capacity or delivery target adopted; older announcement and current location-page targets differ and require provider confirmation if used.
- [L1 — Leviathan company location and operating description](https://www.leviathansystems.co/about). Checked 2026-10-15. Fresh production-origin HTML read October15,2026 confirms U.S. projects subject to scope,site requirements and team availability. Historical web-crawler text was not used. No international operating capability inferred.
- [P1 — Equinix colocation power: customer-load and supply boundaries](https://docs.equinix.com/colocation/about/colo-power/). Checked 2026-10-19. Named deployment Draw Cap/kVA and distinct cabinet-circuit/customer-load meanings only. No numeric circuit tables, conversion, design, contract interpretation or actual capacity/availability adopted.
- [X1 — Equinix Cross Connect demarcations](https://docs.equinix.com/cross-connect/installation/xc-demarcations/). Checked 2026-10-19. Approved delivery demarcation and separate customer-equipment patching scope only. No dimensions, installation arrangement, method, fee, individual access entitlement or universal provider rule.
- [X2 — Equinix Fiber Connect: measurement boundary](https://docs.equinix.com/cross-connect/fc-fiber-connect/). Checked 2026-10-19. Panel-to-panel published measurement scope excludes cage-to-panel connection. No numeric distance/loss/latency, SLA, availability, leased-service recommendation or testing procedure adopted.

## Related Leviathan resources

- [Read the megawatts behind a site-capacity claim](/articles/data-center-power-capacity-claims)
- [GPU cloud or colocation: who operates each layer?](/articles/gpu-cloud-vs-colocation-ownership)
- [GPU cloud availability: quotas, reservations and capacity windows](/articles/gpu-cloud-capacity-availability)
- [Control the template and exceptions in a multi-site rollout](/articles/multi-site-gpu-rollout-coordination)
- [Colocation installation scope](/services/colocation-installation)

## Discuss a defined physical installation package

Share the actual country and facility, equipment list, available drawings and permitted work so the scope and delivery availability can be assessed.

[Discuss the scope](/contact?service=colocation-installation&from=/articles/global-data-center-hubs-site-shortlist)