Quantum cloud access, colocation or ownership: which model fits?

Choose between quantum cloud access, colocation and ownership according to the control and continuity your workload requires and the operating responsibilities your organisation can sustain. Cloud access reduces local infrastructure work; dedicated hosting can provide additional control; ownership creates the widest responsibility for installation, maintenance and replacement. The choice depends on the application and contract.

Workload requirements and cloud access

Start with what the organisation expects to learn or deliver. Occasional experiments across several architectures favour flexibility, while a tightly coupled research programme may require predictable access to a particular machine. Define workload frequency, acceptable waiting time, data handling and the need to change hardware or control settings. A procurement justified only by a long-term quantum strategy leaves the immediate operating requirement unclear and makes apparently attractive offers difficult to compare.

Cloud access normally shifts physical operation to the provider while retaining work for the user. The buyer still prepares workloads, manages access, pays for relevant classical resources and evaluates results. Amazon Braket’s published pricing separates quantum execution and classical resources within hybrid jobs, illustrating why processor access is not the whole bill. This model is useful when demand is uncertain and the value lies in experimentation. Reserved capacity may change access predictability without transferring ownership or facilities responsibility.

Colocation and ownership responsibilities

Colocation places equipment in a hosting environment operated by another organisation. It can combine dedicated infrastructure with professional facilities and connectivity, but the term alone specifies little. Establish who owns the machine, who operates it, which staff can enter the installation and which party restores service. Private connectivity can meet a routing requirement without proving that all data, support access or processing remains within a particular jurisdiction. The contract must describe those boundaries explicitly.

Ownership becomes more plausible when direct control has demonstrable value and the host can sustain the associated obligations. The 2025 LRZ integration case involving a 20-qubit superconducting computer reports the importance of site surveys, scheduler-controlled recalibration, redundant infrastructure and user onboarding. Those findings describe one installation rather than every architecture. They nonetheless show why a purchase needs an operating plan as well as an equipment specification. Facilities, staffing and acceptance work can precede useful access by a material period.

Whole-life costs, utilisation and security

Compare costs over the same service period. For cloud, include execution, reservations, classical computing, integration and support. For hosted or owned equipment, include installation, facilities, maintenance, staffing, insurance where relevant, replacements and eventual removal. Keep cash expenditure separate from accounting depreciation. A machine’s estimated useful life may be shorter for one research programme than its physical life if the workload requires a capability it cannot acquire through an upgrade.

Utilisation should be measured against capacity that the buyer can actually use. Reserved hours are not accepted results; scheduled calibration and programme-specific restrictions reduce useful time. An illustrative £1 million annual ownership cost spread over 1,000 accepted workloads is £1,000 per workload, but over 250 it is £4,000. Those figures are arithmetic, not market benchmarks. They show why uncertain utilisation can dominate a comparison even when the equipment price is fixed.

Security responsibilities also survive outsourcing. AWS’s Braket documentation distinguishes provider responsibilities from the customer’s responsibility for its content and configuration. A buyer should make the corresponding allocation for each proposed model, including identity, permitted users, logs, data retention, remote maintenance and incident notification. Ownership can provide physical control while leaving dependence on external software, spare parts and specialist engineers. It is not automatically equivalent to operational independence.

A staged decision can preserve flexibility. Establish a bounded workload through remote access, test the constraints that justify dedicated capacity and require an operating and financial case before purchasing hardware. That sequence is not mandatory: some public research or infrastructure missions justify ownership for reasons other than short-term utilisation. The decision remains clearer when those objectives are stated separately from commercial workload economics, with the owner and funding of each responsibility recorded.