Colocation vs cloud: the risk controls that matter

At 17:42 on Friday, an operations lead is looking at a dashboard after a bad week. Order acknowledgements slowed during a market burst, a cloud failover left a feed consumer behind, and the incident review cannot establish which configuration was active. The first question is whether the firm needs colocation or cloud. The more useful question is which risks the design can measure, contain and explain.

Latency is a property of the path

Colocation puts equipment in or near an exchange facility, usually with a cross-connect to a venue network. It removes some public-network hops and gives teams control over servers, network cards, kernel settings and packet paths. It does not make every order fast. Gateway queues, application locks, feed handling, clock quality and venue-side throttling can dominate the result.

Cloud infrastructure replaces some physical control with provider-managed compute, networking and availability zones. A workload in the same metropolitan area as a venue may still travel through a private connection, a provider edge, virtual switches and shared network components. Regions and instance types differ. A cloud service's availability commitment is not a promise of a particular order round-trip time.

The figures below are typical market planning ranges, not service commitments. They describe network latency only, not application processing or exchange matching.

Actual results depend on venue, route, provider, workload and measurement method. Compare like with like: use the same endpoints, packet sizes, load and clock source, then inspect median, p99 and worst observed intervals.

These ranges are useful for screening architectures, not for signing off a strategy. A risk limit based on average latency can conceal a p99 tail that causes stale quotes or rejects. Instrument the full order path, including application timestamps and venue responses. If the firm needs a dependable comparison method, Trading Technology's infrastructure coverage can help frame the vendor and platform questions, but acceptance tests still need to use the firm's own workload.

Risk moves with the control boundary

With colocation, the firm owns more of the physical and technical stack. That includes hardware lifecycle, firmware, operating-system patching, access to racks, cabling records, capacity planning and replacement parts. The facility operator controls building access, power and cooling; the exchange or connectivity provider controls other parts of the route. A short cable path does not remove those dependencies. It makes the boundary more specific.

In cloud, the provider operates physical facilities and much of the underlying network. The firm still owns its identity policies, workload configuration, data handling, application security, recovery design and monitoring. Responsibility varies by service. A managed database, virtual machine and container platform do not expose the same controls or evidence. Treating the provider's assurance report as proof that a trading workload is controlled leaves gaps in the firm's own configuration and operating procedures.

For regulated firms, outsourcing and resilience assessments should capture the actual service chain, not only the primary provider's name. Requirements vary by jurisdiction and business, but the evidence usually needs to cover service criticality, access, data location, incident notification, subcontracting, audit rights and an exit plan. Maintain a record of the service, owner, data types, recovery objectives and material dependencies. Check whether those records match what runs in production.

For either model, make these controls explicit:

• Access: record privileged access, approval, session activity and emergency changes. Reconcile physical access records with logical identities where the deployment allows it.
• Change: version network, firewall and host configuration. Tie production changes to approvals and retain a way to identify the active version during an incident.
• Data: classify market, client and order data; set retention and deletion rules; and verify where backups and diagnostic copies reside.
• Evidence: keep time-synchronised logs for order routing, market data, deployments and failovers. Set retention periods to meet legal, regulatory and internal investigation needs.

Colocation can reduce dependence on virtual networking while increasing reliance on facility staff, hardware suppliers and physical procedures. Cloud can standardise deployment and provide managed services while increasing dependence on provider control planes, identity services and regional connectivity. Neither model is inherently easier to audit. The useful test is whether the firm can show who changed what, when it changed and what service was affected.

Test the failure, then collect the evidence

Resilience claims need to be tested against the failure modes that matter to trading, not a generic infrastructure checklist. A warm standby that restores a web tier may be irrelevant if a market data normaliser cannot recover sequence state. A second rack is not independent if it shares the same power feed or network path. A second cloud zone is not a recovery plan if both deployments depend on one identity provider or one control-plane operation.

Use a repeatable process before committing a critical workload to either model:

1. Map the service: draw the order and market data paths, including gateways, connectivity, DNS, time sources, identity, storage and operational consoles. Mark which parts are operated by the firm, the venue and each supplier.
2. Set measurable objectives: define acceptable order-path latency and tail behaviour, recovery time, recovery point, message loss and maximum stale-data interval. Set separate targets for normal operation and degraded mode.
3. Measure under realistic load: replay market bursts and order peaks, including reconnects and retries. Record p50, p99 and p99.9 latency where the volume supports a meaningful tail measure, plus drops, rejects and queue depth.
4. Inject failures: remove a network path, restart a host, revoke a credential or disable a zone. Test planned and unplanned recovery, and check for duplicate orders, sequence gaps, split brain and stale sessions.
5. Preserve proof: retain test plans, timestamps, telemetry, approvals, exceptions and remediation owners. Re-run after material changes to routing, provider services, trading applications or recovery procedures.

Recovery figures should be treated as design targets, not universal properties of either model. Typical market planning ranges for a well-prepared warm failover can run from tens of seconds to several minutes; a cold rebuild can take tens of minutes or longer.

Hardware replacement, venue permissions, route configuration and data replay can extend the outage. Measure the complete service restoration, including the first valid market data and the first safely accepted order.

Cloud automation can shorten deployment time, but automation can also reproduce a bad configuration quickly across regions. Colocation can provide stable, tightly controlled paths, but manual hardware work and facility access can slow recovery. In both cases, runbooks need decision points for stopping automated retries, draining queues and confirming trading state before reopening order flow.

Choose by workload and prove the exit

Latency-sensitive gateways and strategies with strict venue proximity requirements may justify colocation. Workloads with bursty demand, heavy research compute or a preference for managed services may fit cloud, provided their network and service dependencies meet the stated objectives.

Many firms use both. A hybrid design can separate execution from analytics, but it creates operational seams: duplicated controls, different telemetry, configuration drift and a more complicated incident timeline.

Do not size the design for an average session. Model the busiest market periods, recovery traffic and concurrent deployments.

In cloud, test quotas, instance availability and network throughput at the required scale, rather than assuming capacity can be created instantly. In colocation, account for rack power, port capacity, spare hardware and lead times for cross-connects. Keep a capacity margin based on measured peak load and credible growth, then test what happens when that margin is exhausted.

Exit planning is part of resilience and third-party risk. A cloud exit may require data export, replacement services, identity changes and a controlled route cutover. A colocation exit may involve equipment removal, new facility access, connectivity orders and venue testing. For either, identify dependencies that cannot move quickly, set a realistic sequence and preserve configuration in portable, reviewable form. Test at least the critical parts of the plan, such as restoring market data and proving order controls on the alternate path.

Operations teams comparing vendors should ask for the exact measurement boundary behind latency claims, service-specific recovery evidence, incident notification terms, subcontractor visibility and access to logs. They should also ask what happens during a provider control-plane outage, a venue-side disconnection and a firm-side credential compromise.

The answers need owners and test dates, not just contract language. More coverage of platform and provider choices is available through Trading Technology, but the risk assessment remains specific to the firm's architecture and obligations.

The mistake most readers will still make is treating colocation or cloud as the control, instead of proving the end-to-end service path and its failure behaviour.

#trading infrastructure #market data infrastructure #trading system latency #exchange colocation #disaster recovery #cloud risk management #operational resilience #cloud compliance