---
title: "GPU Cloud or Colocation: Who Operates Each Layer?"
description: "Leviathan Systems — Technical content Published 2026-10-15; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/gpu-cloud-vs-colocation-ownership"
last-updated: "2026-10-20"
---

# GPU Cloud or Colocation: Who Operates Each Layer?

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

GPU cloud supplies access to provider-operated compute; colocation supplies facility space and agreed services for customer equipment. Compare both against the same useful workload, then assign hardware support, facility services, software maintenance, data recovery and acceptance. A provider infrastructure return or an installer completion record closes only its own layer.

## Separate the asset from the service you are buying

An offer for GPU instances concerns access to compute capacity under the provider's service. A colocation order concerns space and agreed facility services around equipment supplied by the customer. Equinix describes its colocation model as placing customer servers and associated hardware in provider facilities. That operator example helps distinguish the products; it does not define every managed-service arrangement.

The facility is an ongoing operating layer. Equinix's colocation explanation includes power and cooling among facility services, while its documentation lists physical interconnection and on-site support separately. Identify the ordered service boundary, its provider contact and the tenant's responsibilities. An installation handoff does not take over facility operation or establish that the required services are available.

An integrator may add equipment, software support or remote work to either arrangement. Put those additions on separate lines so the comparison includes the work actually being bought.

References: [E1](https://docs.equinix.com/colocation/), [E2](https://www.equinix.com/what-is-colocation)

## Cloud changes the physical boundary, not every operating responsibility

AWS's shared responsibility model, checked October 20, 2026, assigns protection of its underlying infrastructure to AWS. For EC2, the customer manages the guest operating system, customer-installed applications and security-group configuration. The division changes with the selected service; this EC2 example is not a description of every GPU cloud product.

For a buyer, the useful question is who handles each operational event. Who receives a hardware incident? Who patches the workload environment? Who restores application data? Name the applicable support process and internal owner rather than treating provider-operated hardware as a promise that the provider runs the entire application.

References: [A1](https://aws.amazon.com/compliance/shared-responsibility-model/)

## Use a layer-by-layer worksheet

Use the layers below to compare the operating package. The entries complete fictional offer assumptions for the same application W in the next section; they are not duties inferred from cloud or colocation labels. In a real comparison, replace them with the appointed team, agreed boundary and expected handoff from the actual offer. Keep an unassigned task visible.

Same workload W: assumed operating owners and the remaining gap
| Layer or event | Cloud self-managed compute offer C | Owned-equipment colocation offer K | Source |
| --- | --- | --- | --- |
| Hardware incident and support | Cloud provider handles its hardware within the selected support scope; customer Platform Team C escalates incidents and receives the infrastructure return. | Customer Asset Team K holds the OEM support relationship; separately authorized Hardware Maintainer K owns the scoped equipment work. | Planning analysis |
| Ongoing facility services and access | The provider's facility infrastructure remains within the compute-service boundary; Platform Team C uses the provider support route. | Facility Provider K supplies the specified power, cooling and access services at the agreed boundary. Platform Team K owns tenant escalation; Physical Installer K does not operate the facility. | Planning analysis |
| OS, runtime and customer application | Platform Team C maintains the selected OS, runtime and customer code in this explicitly self-managed offer. | Platform Team K maintains the selected OS, runtime and customer code; physical installation is a separate package. | Planning analysis |
| Network, storage and data movement | Platform Team C owns customer-side connectivity and storage interfaces; Data/Application Team C owns input/output data decisions. | Platform Team K owns tenant network/storage interfaces and the provider demarcation. The customer data owner retains input/output decisions; recovery is still unassigned below. | Planning analysis |
| Application and data recovery | Data/Application Team C is expressly assigned recovery and its handoff evidence to Application Owner X. | Initially unassigned. Neither the asset/OEM support relationship nor Physical Installer K's scope includes this responsibility. | Planning analysis |
| Narrow completion return | Provider infrastructure return goes to Platform Team C; it does not state that W or its data is recovered. | Physical Installer K returns agreed mounting, cabling, labeling and exception records; these do not state that W or its data is recovered. | Planning analysis |
| Workload acceptance | Application Owner X assesses W using model A, input D, output R and window T. | The same Application Owner X assesses the same requirement; the physical handoff is a separate decision. | Planning analysis |
Original comparison assumptions, not a provider support standard or allocation of contractual liability. Actual service scope and site rules must supply the real owners and boundaries.

## Compare two handoffs with the same requested workload

Consider one fictional inference application W. Both alternatives must use the same stipulated model artifact A and input population D to deliver the required output R within usable window T, under the same control needs. Application Owner X defines and assesses those acceptance criteria for both. Assume technical feasibility only to examine responsibility; no actual product suitability or result has been established.

At the start, offer C explicitly assigns application and data recovery to customer Data/Application Team C. Offer K leaves recovery unassigned, although it names an asset owner, a hardware maintainer and a physical installer. This is a comparison of two offers for W, not two different workload requests. The named teams and allocations in the worksheet are invented offer assumptions, not standard contractual duties.

In cloud offer C, the provider covers its hardware infrastructure within the selected service support scope. Customer Platform Team C owns incident escalation and OS, runtime and customer-code maintenance. The provider's facility infrastructure stays within the compute-service boundary. Data/Application Team C owns the separately stated recovery scope and the evidence to be returned to X; X still owns W's acceptance.

In owned-equipment offer K, customer Asset Team K holds the OEM support relationship and Hardware Maintainer K owns separately authorized equipment work. Platform Team K owns OS, runtime, customer-code and tenant network/storage interfaces. Facility Provider K supplies the ordered power, cooling and access services at the agreed boundary, with Platform Team K as the tenant escalation owner. Physical Installer K has a narrower mounting, cabling, labeling and record package. None of those named roles fills K's missing application/data-recovery assignment.

Now stipulate two narrow documentary states for the comparison: C has a provider return stating that the hardware-infrastructure service is restored; K has a physical completion record for the agreed installation. These are hypothetical inputs, not reports of an actual outage, repair or completed deployment. C's return goes to Platform Team C and its assigned recovery team. It does not establish that model A, the required data or application W is recovered, or that output R is available within T. K's record closes its stated physical scope, but supplies neither a recovery owner nor a recovery result. Even a separate hardware-support closure in K would leave that operating gap.

The next scope decision is therefore specific: ask the customer to appoint K's recovery owner and define the work and return expected from that team. Suppose it appoints Data/Application Team K, with responsibility for application/data recovery and a return identifying the applicable model/data state, remaining exceptions and evidence for X's review against W. That completes the responsibility allocation in this example. It does not perform recovery, prove readiness or accept W.

Both packages can now be assessed with recovery ownership visible, alongside their actual dependencies and costs. X would still need the relevant application evidence to decide whether A and D produced R within T. Appointing Team K removes an ownership gap; it establishes neither a recovery time nor a cloud-versus-colocation winner. The practical lesson is to buy or assign the missing operating work rather than treat a hardware or physical record as the workload result.

## Check the boundary when the product name is ambiguous

If an offer says dedicated GPU, bare metal or managed infrastructure, ask which property it describes: hardware allocation, administrative access, software support or an incident-handling service. Record the exact product or feature, its service-document reference and the responsible contact. The next two sections show why those labels can overlap or hide different operating interfaces.

For colocation, identify the tenant/provider demarcation and who may work on each side. Remote support or a service desk can be part of an offer, but the permitted task, resources and completion evidence still need to appear in its scope. A broad label cannot fill the recovery gap in offer K.

## Separate dedicated capacity from bare-metal access

AWS makes the allocation/access distinction concrete in documentation checked October 20, 2026. Its EC2 Dedicated Host guide describes a physical server dedicated for the customer's use, with visibility and control over instance placement. Its host-and-instance documentation describes bare-metal instances as having direct access to EC2 hardware and remaining part of the EC2 service. The first identifies a host allocation and placement relationship; the second identifies an instance access model. Neither describes a shipment of customer servers.

These properties can overlap: the AWS Dedicated Hosts FAQ explicitly discusses running bare-metal instances on Dedicated Hosts. That does not mean any instance can use any host configuration. For a GPU requirement, obtain the exact supported service/configuration and operating scope; these general EC2 descriptions establish neither GPU eligibility nor available capacity.

Fictional example EX-CL-22: an internal request says "dedicated server installation" and attaches an EC2 Dedicated Host product description. It supplies no customer equipment list or receiving facility. The useful response is to ask which result is being purchased: access to the specified EC2 service, or physical work on separately supplied equipment. A cloud host identifier cannot fill the missing server model, delivery and destination fields of an installation brief. This clarifies the request without deciding whether either service is suitable.

If the requester needs the EC2 service, the provider and platform team must resolve that product and operating scope. If a separate customer-equipment package is also intended, describe its facility, hardware, authorized tasks and physical handoff on its own terms. A programme can include both, but a shared label does not connect their orders or authorize field work.

References: [A5](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html), [A6](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/host-and-instance-features.html), [A7](https://aws.amazon.com/ec2/dedicated-hosts/faqs/)

Read two EC2 labels as different dimensions of the offer
| Documented EC2 concept | Narrow provider description | Buyer question still open | Source |
| --- | --- | --- | --- |
| Dedicated Host | A physical host with instance capacity dedicated for use and control over instance placement | Which exact host/service configuration and operating tasks does the offer include? | A5 |
| Bare-metal instance | Direct access to EC2 hardware while remaining an EC2 service instance | Which exact instance and software responsibilities does the customer need? | A6 |
Provider descriptions and original buyer questions. AWS's documented overlap means the rows are not mutually exclusive choices; neither supplies the exact GPU configuration, capacity or customer-equipment work package.

## Compare bare-metal GPU access with managed model hosting

Bare-metal compute and fully managed model hosting expose different operating interfaces. A compute offer can supply instance access, leaving the customer to maintain its environment. A hosting feature can accept a model artifact and expose an inference endpoint. Name that feature before comparing what the provider operates and what the customer must supply.

Oracle describes OCI bare-metal compute as dedicated physical-server access and lists BM.GPU.H100.8 among its bare-metal GPU shapes. This is a named cloud compute product, not customer-owned equipment delivered to a tenant cabinet. Confirm the actual image, instance/OS access and software responsibilities in the offer. A shape listing does not establish current capacity or physical access to a provider facility.

For the managed example, use SageMaker AI fully managed model hosting for real-time inference. AWS's real-time inference guide describes deploying a model to hosting services and obtaining an inference endpoint. The infrastructure-access answer in the FAQ's Deploy models section says AWS operates the compute, including health, patching and routine maintenance, without exposing that infrastructure for customer access. These pages were checked October 20, 2026; this comparison applies that answer to the named hosting path.

That is not a SageMaker-wide access rule. AWS separately documents customer access to SageMaker HyperPod cluster nodes and the ability to install and operate user-managed software there. HyperPod node access and a fully managed hosting endpoint are different feature boundaries. AWS's security guide also makes customer responsibilities dependent on the service, data and company requirements.

For the bare-metal offer, identify who maintains the OS image, driver/runtime environment, scheduler and customer code, and what support investigates. For the hosting offer, identify the supported model-artifact interface, customer-controlled configuration, data access and workload-validation owner. Keep GPU eligibility, actual capacity and application results open to the exact offering. The table compares operating boundaries, not equivalent configurations or performance results.

In either case, ask what platform support returns after an infrastructure incident and who owns any remaining application/data recovery. A provider-operated endpoint does not by itself establish that W produces R within T. Customer control, recovery and acceptance must be traced through the selected feature rather than inherited from its platform brand.

References: [O9](https://docs.oracle.com/en-us/iaas/Content/Compute/Concepts/computeoverview.htm), [O10](https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm), [A9](https://aws.amazon.com/sagemaker/ai/faqs/), [A10](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html), [A11](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html), [A12](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-run-jobs-slurm-access-nodes.html)

Read the operating boundary of the named compute and hosting examples
| Decision | OCI bare-metal compute example | SageMaker AI real-time model hosting example | Source |
| --- | --- | --- | --- |
| What is being obtained? | OCI lists BM.GPU.H100.8 as a bare-metal GPU shape; the product is compute-instance access. | The named fully managed hosting path supplies an inference endpoint for a deployed model. | O9, O10, A11 |
| Which interface matters? | Confirm instance/OS access and the supported environment in the offer. | Model/endpoint interface; the Deploy models FAQ describes provider-operated underlying compute without customer infrastructure access. | A9, A11 |
| What remains to assign? | Environment maintenance, workload/data decisions, incident participation, recovery and acceptance. | Customer data/configuration, application validation, support participation and remaining recovery scope. | A10 |
| What physical package follows? | A separate customer-equipment package needs its own site, equipment and permitted tasks. | The endpoint identifies no tenant cabinet installation; any separate equipment work needs its own scope. | Planning analysis |
Different service examples. The hosting access statement is feature-specific: AWS separately documents HyperPod node access and user-managed software. Actual offers must establish the requested controls and GPU eligibility.

## Decide between owned equipment and rented compute on comparable work

Buying servers and renting GPU time are not comparable until both alternatives describe the same useful workload outcome. Begin with the required model or application, data location and movement, usable capacity, timing, control needs and acceptance criteria. A nominal GPU count or advertised hourly rate cannot supply those requirements. If one option cannot meet the workload or required control boundary, a lower quoted unit price does not make it equivalent.

Then compare the complete operating package over a declared planning period. The owned-equipment case needs an equipment quotation, facility and network services, installation and integration scope, recurring operation/support, expected changes and an end-of-period disposition. The rental case needs the exact service and commitment, usable period, storage and transfer items, customer operating work and exit requirements. Keep existing committed costs, additional decision-dependent costs and uncertain items distinguishable.

In the W example, K's physical quote cannot stand in for a complete operating cost while its recovery role is unassigned. Once Team K's scope is defined, include that customer or separately purchased work in the comparison. C's expressly assigned customer recovery work also belongs in its package; an owner already on the team does not make the task disappear. The worksheet supplies comparable inputs, not prices or a break-even result. The related capacity-reservation versus savings-commitment guide addresses the separate distinction between a cloud capacity allocation and a pricing commitment.

Use sensitivity cases rather than treating forecast usage as guaranteed. A project may need a short development interval before a separately planned customer cluster is ready. Ask whether temporary compute can deliver that interval and whether its data/workflow can move to the later environment. A continuing private cluster raises a different question: whether required control, recurring work and credible usage justify the asset and operating obligations. These possible situations establish no rule that rental wins for short periods or ownership wins at scale.

The physical installer contributes only the defined installation and change scope: receiving interfaces, supplied equipment, rack/cable work, records and separately accepted outputs. That work can affect the asset option's readiness and cost boundary, but cannot establish model throughput, utilization or the customer's funding decision. If one programme combines owned equipment and rented compute, preserve both scopes and their interface.

- Define comparable useful output, workload conditions, time window, control requirements and acceptance owner before requesting cost inputs.
- For each alternative, identify the exact product/package, operating and recovery teams, expected handoffs and dependencies before it becomes usable.
- Separate one-time acquisition/installation/change inputs, recurring facility/service/support inputs and end-of-period or migration inputs. Do not silently treat an unknown as zero.
- Record quoted units, included/excluded items, planning period and the basis of each usage assumption. Review optimistic and constrained cases without presenting them as measured demand.
- Take financial reporting, depreciation, tax, funding and binding purchase/service terms to their actual qualified owners. This educational scope worksheet does not decide those matters.

## Take the next question to the right owner

If provider-operated compute is the intended purchase, resolve capacity, software, recovery and service questions with the selected provider and your appointed operating teams. If customer equipment will be installed, prepare its physical scope with the tenant, facility and installation owners while assigning the continuing operating work separately. In either case, retain Application Owner X's decision on the required workload result.

Leviathan can discuss agreed customer-side rack installation, cabling, labeling and physical handoff work. It does not offer GPU rental or cloud hosting, and that physical scope does not include facility power/cooling operation or application/data recovery. A useful installation inquiry identifies the facility, customer-supplied equipment, released plans, access authority, intended field-work window and physical receiving owner.

Use the colocation installation service and its project inquiry for that remaining physical package. Name any open provider dependency and the operating team that will receive the records so the inquiry follows from the comparison rather than leaving another responsibility unassigned.

References: [L1](https://www.leviathansystems.co/services/colocation-installation)

## Common planning questions

### Does GPU cloud mean the provider manages our application?

The product label does not establish that. The EC2 example leaves guest OS and customer applications with the customer; other services can differ.

### Can we treat a colo provider and an installer as one work package?

Identify the actual included tasks first. Ongoing facility power/cooling services, tenant operating duties and authorized physical installation can have different owners. In the W example, naming the installer and hardware maintainer still leaves recovery unassigned until Team K receives that scope.

### Does a bare-metal or dedicated label establish an equipment installation scope?

No. AWS describes host allocation and instance access, and documents bare-metal instances on Dedicated Hosts. Separately supplied customer equipment needs its own hardware, facility, permitted tasks and handoff definition.

### Does managed AI remove the need for a customer workload owner?

No. The fully managed SageMaker AI real-time hosting example supplies an endpoint; the customer still needs data/configuration, recovery and workload-validation owners. HyperPod separately documents node access and user-managed software, so a platform-wide access assumption is unsafe.

### Can the lowest GPU-hour price decide whether to buy servers or rent compute?

First establish comparable useful output, timing and control, then compare acquisition/service scope, recurring work, recovery ownership and exit assumptions over the same period. An unassigned task is an unknown input, not a saving.

## Primary sources

- [A1 — AWS shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/). Checked 2026-10-20. EC2-specific guest OS, customer applications and security-group duties alongside AWS infrastructure protection; other selected services divide responsibilities differently.
- [E1 — Equinix colocation documentation](https://docs.equinix.com/colocation/). Checked 2026-10-20. Named operator example of customer equipment in provider space, with interconnection and on-site services listed separately. The actual order establishes included services.
- [L1 — Leviathan colocation installation scope](https://www.leviathansystems.co/services/colocation-installation). Checked 2026-10-20. Agreed customer-side physical installation, cabling and records. Hosting, facility services and continuing software operations remain separate from the installation scope.
- [A5 — AWS EC2 Dedicated Hosts: allocation and placement concepts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html). Checked 2026-10-20. Dedicated physical-host use and instance-placement visibility/control. The selected configuration still needs its own GPU eligibility and capacity confirmation.
- [A6 — AWS host and instance features: bare-metal service context](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/host-and-instance-features.html). Checked 2026-10-20. Direct EC2 hardware access for bare-metal instances while remaining within the EC2 service. This is an instance-access distinction, not customer equipment delivery.
- [A7 — AWS Dedicated Hosts FAQ: bare-metal instance overlap](https://aws.amazon.com/ec2/dedicated-hosts/faqs/). Checked 2026-10-20. Explicit bare-metal-instance support on Dedicated Hosts establishes that the labels can overlap; it does not establish every host/instance combination.
- [O9 — Oracle OCI Compute overview: bare-metal instance boundary](https://docs.oracle.com/en-us/iaas/Content/Compute/Concepts/computeoverview.htm). Checked 2026-10-20. Bare-metal instance access to dedicated physical-server compute. Used to distinguish compute access from a customer-site equipment package.
- [O10 — Oracle OCI Compute Shapes: named bare-metal GPU example](https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm). Checked 2026-10-20. BM.GPU.H100.8 is listed among bare-metal GPU shapes. Product identity only; numerical specifications and current availability are not adopted.
- [A9 — Amazon SageMaker AI FAQ: managed workflow and infrastructure access](https://aws.amazon.com/sagemaker/ai/faqs/). Checked 2026-10-20. Deploy models section, infrastructure-access question: provider health/patch/maintenance work and no customer access to underlying compute. Applied to the named fully managed hosting comparison, not all SageMaker features.
- [A10 — Amazon SageMaker AI security: service-dependent responsibility](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html). Checked 2026-10-20. Customer security responsibilities depend on the selected service, data and organizational requirements; managed infrastructure does not assign every application duty.
- [E2 — Equinix: what colocation includes at the facility layer](https://www.equinix.com/what-is-colocation). Checked 2026-10-20. Power and cooling are named facility-service elements around tenant equipment. Used only to identify that ongoing layer; service limits and included responsibilities need the actual offer.
- [A11 — Amazon SageMaker AI real-time inference: fully managed model hosting](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html). Checked 2026-10-20. A deployed model is exposed through a fully managed inference endpoint. Identifies the hosting workflow; no latency, scaling, GPU-capacity or workload-result guarantee is adopted.
- [A12 — Amazon SageMaker HyperPod: cluster-node access and user-managed software](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-run-jobs-slurm-access-nodes.html). Checked 2026-10-20. Customer node access and user-managed software qualify any SageMaker-wide no-access reading. The article uses this feature distinction without providing node-access or software-operation instructions.

## Related Leviathan resources

- [GPU Cloud Availability: Quotas, Reservations and Capacity Windows](/articles/gpu-cloud-capacity-availability)
- [GPU Capacity Reservation or Savings Commitment?](/articles/gpu-cloud-capacity-reservation-versus-savings-commitment)
- [Global Data Center Hubs: From Metro Shortlist to Actual Site](/articles/global-data-center-hubs-site-shortlist)
- [Colocation Cross-Connects: Patching and Tenant Cabling](/articles/colocation-cross-connect-vs-tenant-cabling)
- [GPU Site Readiness: Inputs and Owners Before Equipment Arrives](/articles/site-readiness-before-gpus-arrive)
- [Colocation installation scope](/services/colocation-installation)
- [Google TPU or NVIDIA GPU: compare workload and delivery model](/articles/google-tpu-vs-nvidia-gpu)

## Planning customer equipment installation?

Share your facility, equipment, tenant/provider boundaries and authorized physical work. Leviathan can discuss that installation scope.

[Discuss the scope](/contact?service=colocation-installation&from=/articles/gpu-cloud-vs-colocation-ownership)