Plataformas · Software · Provedores · Mercados
Start with the workload, not the venue
"Should we put this on colo or cloud?" Benchmark the workload first. The right answer depends on its latency budget, traffic pattern, venue access and recovery needs, not on a general preference for one hosting model.
Colocation puts your equipment in, or close to, a venue's data centre. You control the server, operating system, NICs and network configuration, then connect through cross-connects and carriers. Cloud rents compute and network services in a provider's region. It offers faster provisioning and managed components, but the underlying hardware and much of the network path are outside your control.
Separate the hot path from everything around it. Order routing, market data handling and risk checks may have tight and consistent latency requirements. Research, reporting, client portals, build systems and many risk jobs often value elasticity or managed services more. A workload can also change category as message rates, strategies or venues change.
Write down the required latency, throughput, availability and recovery objectives for each service. Trading Technology's infrastructure coverage can help frame the operational questions, but the decision should come from your own measurements.
Measure the path that matters
A server's reported processing time is not the same as order-to-acknowledgement latency. Measure from the point your strategy creates an order to the acknowledgement received from the venue, and separate application time from network time. Capture p50, p99 and p99.9, plus jitter and packet loss. A low average can hide a tail that creates rejects, stale quotes or inconsistent execution.
Record where each hop occurs: process, host, virtual switch, cloud network or top-of-rack switch, carrier, cross-connect and venue gateway. A cloud instance in the same city as an exchange is not automatically on the shortest path. Private connectivity may improve routing and predictability, but it does not remove the cloud host, virtual network or provider's routing decisions.
Run tests under realistic load and at the times that matter. Include bursts, market open, recovery after a disconnect and competing workloads.
Check clock synchronisation before comparing timestamps. PTP is common for tightly controlled trading environments; NTP may be adequate for less sensitive services, but its accuracy depends on configuration and network conditions.
- Measure from the application boundary, not just with a ping.
- Keep network and application timings separate.
- Record host CPU contention, NIC queue drops and retransmissions alongside latency.
- Compare the same message sizes, routes and traffic rates in each environment.
Price the whole operating model
Compare the cost of a production-ready service, not a cloud instance against a rack quote. Include hardware amortisation, power, cross-connects, transit, cloud egress, support, spare capacity and the engineering time needed to maintain each setup.
The figures below are typical market ranges in USD, not quotes. Geography, contract term, power density and provider pricing change them materially.
| Cost line | Colocation, typical market range | Cloud, typical market range | What changes the figure |
|---|---|---|---|
| Compute capacity | $500-$2,500 per server per month, amortised over 3-5 years | $700-$3,000 per month for 16-32 vCPU | CPU generation, memory, redundancy and reserved pricing |
| Rack or power allocation | $1,500-$5,000 per month for a cabinet or 1-2 kW allocation | Usually included in instance pricing | Facility, power density, cooling and contract commitment |
| Venue or private connectivity | $200-$800 per cross-connect per month, plus $500-$2,000 setup | $300-$2,000 per month for a private-connect port, plus circuit charges | Venue, port speed, carrier and route diversity |
| Network traffic | $500-$3,000 per month for 1-10 Gbps transit | $500-$1,200 per month for 10 TB outbound traffic | Commitment, destination, region and burst profile |
| Support and operations | $200-$1,500 per month for remote hands and support, excluding staff | $100-$2,000 per month for support plans, excluding staff | Response target, service tier and internal on-call cover |
Do not treat these rows as an exact like-for-like bill. Colocation usually needs an upfront server purchase and a plan for spares. Cloud costs can rise with egress, snapshots, logging, high availability and always-on overprovisioning.
Model normal load and a credible peak, then show the cost of a second site or zone. Staff time is often the largest omitted line: both models need people who understand releases, network behaviour, capacity and incident recovery.
Map failure domains before choosing
Colocation gives direct control over hardware and can offer a short, engineered path to a venue. It also leaves your team responsible for firmware, failed components, capacity planning and physical access processes. A rack in one facility is a single failure domain, even if its servers have redundant power supplies.
Cloud makes it easier to provision across availability zones and automate replacement. But zones are not a complete recovery plan.
Check whether the service depends on shared identity, DNS, control-plane APIs, routing, a single private circuit or a regional service. A cloud provider can maintain its infrastructure while your application remains unable to trade.
For either model, document how the system behaves when a venue connection drops, a host fails, a zone becomes unavailable or a deployment is rolled back. Test session recovery and order-state reconciliation.
Decide whether failover is automatic or operator-led, and define what happens to open orders during the transition. A hybrid design can spread risk, but adds routes, duplicated state and more places for configuration to diverge.
Run this one-week checklist
Choose one service with a clear owner and enough traffic to produce useful evidence. Keep production risk controlled: use a staging venue, a shadow path or approved low-volume testing where needed. Record the test conditions so the comparison can be repeated.
- Monday: Set a baseline. Capture order-to-ack latency, p50, p99 and p99.9, throughput, packet loss and CPU utilisation on the current path.
- Tuesday: Draw every hop and dependency. Mark the facility or region, carrier, cross-connect, private link, DNS, identity service and state store.
- Wednesday: Test under normal load and a representative burst. Check CPU steal or contention, NIC queues, retransmissions, application pauses and tail latency.
- Thursday: Exercise a controlled failure. Remove a host or route in a test environment, then time detection, recovery, session restoration and order-state checks.
- Friday: Build a monthly cost model for normal and peak capacity. Include hardware amortisation, circuits, egress, support, spares and staff time.
- Before the review: Put the evidence in one page. State the workload's limits, the measured differences, unresolved risks and the trigger for revisiting the decision.
Use the same workload and acceptance thresholds for both options. A benchmark that changes message size, route or failover behaviour between tests cannot support a reliable decision. For a broader view of provider and platform infrastructure, see Trading Technology's coverage.
Choose by boundary, not ideology
Colocation is a strong fit when the venue path, deterministic hardware behaviour or direct network control justifies the capital and operational load. Cloud is a strong fit when elasticity, managed services, rapid deployment or geographic reach matter more than controlling every hop. Many firms will have both, but each boundary should have a reason and a tested failure plan.
Do not move a latency-sensitive service because a cloud estimate looks cheaper, or keep hardware in a rack because it has always been there. Revisit the choice when message rates, venue locations, provider terms or staffing change. The useful decision is the one supported by measured performance and a complete operating cost, with a named owner for each dependency.
At the next team meeting, ask: which workload have we measured end to end, and what evidence would make us change where it runs?
Perguntas frequentes
Is colocation always faster than cloud for trading?
No. Colocation can shorten and simplify the path to a venue, but location, carrier routing, host configuration and application behaviour all affect latency. Measure end-to-end latency and its tail under representative load before deciding.
What should a broker include in a colocation cost comparison?
Include server purchase and amortisation, rack or power charges, cross-connects, transit, remote hands, spares and staff time. Compare the same availability and capacity requirements against cloud compute, connectivity, egress, support and recovery costs.
Can a cloud region near an exchange meet low-latency requirements?
It can, depending on the workload and network path. A nearby region does not guarantee a direct or predictable route, and virtualisation can introduce additional variability. Test the actual private or public connectivity path at realistic message rates.
Is a hybrid trading infrastructure a good compromise?
It can keep latency-sensitive components close to venues while using cloud for elastic or less time-critical services. It also adds network paths, duplicated state and operational complexity, so define ownership and test recovery across the boundary.
