Platforms · Software · Providers · Markets
Devin Hartcastle
Colocation is not automatically faster than cloud.
Colocation means placing a firm's own servers in a data centre, often in a facility used by an exchange or its connectivity providers. Cloud means renting compute, storage and networking from a provider. Both can host market data handlers, order gateways, risk checks and internal services. The useful distinction is not physical versus virtual. It is how much control a team has over the route, hardware and failure domain, and what it pays to maintain that control.
A broker sending orders to a venue from its matching-engine-adjacent rack has a different job from a prop firm running research batches or a broker's client portal. A single platform can use both models. The right decision starts with the service's latency budget, traffic pattern and recovery requirement, not a blanket rule that every trading workload belongs in a cage.
What the two models actually provide
In a colocation facility, the operator rents space, power and cooling. The firm supplies or leases servers and connects them to networks using cross-connects, managed switches or a carrier.
If the facility hosts a venue's access point, a short physical route may be available. That does not mean a firm is connected directly to the matching engine: venue access, certification, network design and the precise hand-off point all matter.
In cloud, the provider operates the physical estate and exposes virtual machines, bare-metal instances, managed databases and network services. Teams can provision capacity in minutes and automate replacement.
They usually have less control over the underlying host, cabling and physical route. A private connection can avoid the public internet for part of the path, but it does not make the whole route deterministic or guarantee a latency figure.
The deployment label also hides important differences within each model. A well-engineered cloud path can outperform an overloaded or poorly routed colocation setup.
A dedicated server in a cloud provider's facility is not equivalent to an exchange cross-connect. Compare actual endpoints and traffic conditions. Trading Technology's infrastructure coverage can help teams keep those provider and platform distinctions in view.
Measure the path, not the sales description
Latency figures only mean something when the endpoints and method are stated. Measure from the application event that matters, such as receiving a market-data packet or submitting an order, to the corresponding event at the other end. Record round-trip time where relevant, but do not mistake a ping to a nearby router for order-to-acknowledgement performance. The application may add parsing, risk checks, queuing, encryption and scheduling delays.
The figures below are typical market ranges, not guarantees. They describe different paths, so they are useful for setting expectations, not for ranking providers without a like-for-like test.
| Setup and measured path | Typical round-trip latency | Common source of variation | What the figure excludes |
|---|---|---|---|
| Colocation, host to venue gateway in the same facility | 50 to 500 microseconds | Switch hops, NIC settings, cross-connect route and venue hand-off | Application processing and venue acknowledgement handling |
| Cloud, host to host within one availability zone | 100 to 500 microseconds | Virtualisation, host contention, network policy and packet size | Any route outside the cloud network |
| Cloud, private connection to a venue gateway in the same metro | 0.5 to 5 milliseconds | Provider hand-offs, carrier route and gateway location | Market-data processing or order risk checks |
| Cloud, public network to a venue endpoint in the same metro | 1 to 10 milliseconds | Internet routing, congestion and path changes | Application and venue processing |
Tail behaviour matters more than a good average. Collect median, 99th and 99.9th percentile latency, packet loss and jitter during the actual trading window. Separate inbound market data from outbound orders. Capture timestamps at the NIC or with a suitable hardware clock where precision justifies it, and verify clock synchronisation. Averages can conceal short bursts that fill queues, trigger stale-price controls or cause order timeouts.
Measure the complete order path under load, including the slowest part you control.
Control, resilience and operational work
Colocation offers tighter control over server models, NICs, kernel settings and network topology. That can matter for deterministic performance and hardware timestamping.
It also leaves the firm responsible for capacity planning, firmware, spares, remote hands, physical access and lifecycle replacement. A failed power supply or switch is still an operational event, even if the venue is next door.
Cloud makes it easier to create additional instances, isolate environments and automate rebuilds. It can simplify disaster recovery when capacity is available in a separate zone or region.
But an autoscaling group does not automatically make an order path resilient. Shared dependencies such as identity, DNS, secrets, market-data feeds and a single private circuit can remain common failure points. Cross-zone replication and duplicate traffic can also increase network charges.
Write down which failures each design can tolerate. Include at least:
- Loss of a server, rack, switch or power feed.
- Loss of a carrier, private circuit, cloud zone or region.
- Market-data gaps, stale data and duplicate or out-of-order messages.
- Risk-service failure, including whether the gateway fails closed or has a controlled fallback.
- Recovery time objective and recovery point objective for each service, not just the platform as a whole.
Test failover with realistic traffic and a clear authority for switching routes. Active-active order gateways need sequencing and duplicate-order controls; active-passive systems need a tested way to establish which side owns a session.
A second site that has never processed live-like load is not a recovery plan. Teams tracking platform and provider changes through Trading Technology should still validate the actual contract, topology and service limits with each supplier.
Compare total cost and workload fit
Colocation bills typically include rack space, committed power, cross-connects, bandwidth, hardware and support. Cloud bills include compute, storage, data transfer, private connectivity and operational tooling. Pricing varies by market, facility and commitment, but a small colocation footprint can run from a few thousand pounds per month before hardware and network costs.
Cloud workloads can range from hundreds to tens of thousands of pounds monthly as instance size, redundancy and outbound data grow. Treat these as typical market ranges, then price the specific design.
Compare a full year of service, including deployment and people costs. A cloud instance that looks cheap per hour may become expensive when it runs continuously across redundant zones and moves large market-data volumes. Colocation may have lower network latency but require longer procurement, hardware refreshes and on-site support. Include the cost of a second site, test environments, monitoring and the time engineers spend operating each model.
A practical placement exercise follows this order:
- List each service and its latency budget, data volume, burst rate and recovery objective.
- Draw the complete packet path, from feed or client connection through risk and gateway components to the venue.
- Measure the current path under peak load, with percentile latency, loss and jitter recorded at agreed points.
- Price two viable designs over 12 months, including circuits, cross-connects, egress, hardware, support and staffing.
- Run a failure test and a representative traffic test before moving a production order path.
Market-data normalisation, back-office reporting, test environments and research jobs often suit cloud because they scale or tolerate variable latency. Venue-facing gateways and latency-sensitive strategies may favour colocation where the route and access terms support the required budget. This is a starting point, not a rule: a service with a strict recovery requirement may need a second location regardless of its primary deployment.
Make the decision with service-level evidence
Keep the decision at service level. One firm may place its venue gateways in colocation, run risk calculations close to those gateways, and use cloud for client services, analytics and recovery capacity.
Another may have a cloud region close enough to its venue routes and a workload that does not justify operating physical hardware. The architecture should follow measured requirements and tested failure modes.
Before committing, make sure the design answers these questions:
- Where are the measurement endpoints, and do they include the application and venue hand-off?
- What happens to the 99th-percentile latency when the system reaches peak message rates?
- Which network, power, identity and data services are shared between primary and recovery paths?
- Can operations staff identify a bad route and switch safely without creating duplicate orders?
- Does the cost model include the second site, data transfer, hardware refresh and on-call work?
Do not accept a headline latency number without its endpoint, percentile, traffic load and test window. A few microseconds can matter to a specific strategy, while a millisecond may be immaterial to a slower workflow. Make the target explicit, measure it in production, and revisit it when routes, volumes or venue access change. Check your busiest route's 99th-percentile order-to-acknowledgement figure, and investigate if it is above 5 ms.
Frequently Asked Questions
Is colocation always faster than cloud for trading?
No. Colocation can offer a shorter, more controllable route to a venue, but actual performance depends on the hand-off, network design, hardware and application. Compare the same endpoints under representative load, including tail latency.
Can a broker run trading infrastructure in the cloud?
Yes. Cloud can suit services that need rapid provisioning, flexible capacity or geographic recovery. Venue-facing order paths still need measured latency, suitable connectivity and tested controls for shared dependencies and failover.
What latency should a trading team measure?
Measure the path that corresponds to the service requirement, such as market-data arrival to application processing or order submission to acknowledgement. Record median and tail percentiles, packet loss and jitter during peak traffic, and document the endpoints.
Is cloud cheaper than colocation for a broker?
It depends on utilisation, redundancy, network traffic, hardware and staffing. Compare a full-year design that includes circuits, data transfer, support, recovery capacity and on-call work, rather than comparing instance prices with rack rent alone.
