Colocation and cloud: a 30-day trading infrastructure plan

1 ms of avoidable round-trip latency can cost an execution strategy queue priority, even when the order reaches the venue. For a broker or prop firm, the cost of choosing the wrong infrastructure is broader: slower order handling, unstable tail latency, duplicated support work or a cloud bill that grows with traffic. A 30-day comparison should test the paths that carry orders and market data, not compare provider brochures.

The difference is control, not simply speed

Colocation puts your equipment in or near a venue's data centre. You control the server, operating system, network interface and much of the path to the exchange.

Cloud puts compute and networking under a provider's control, with capacity that can be provisioned quickly and shifted between regions. Dedicated cloud hosts and direct venue connections narrow the gap, but do not make every network hop or maintenance event predictable.

Use the table as a starting point, not a service-level guarantee. These are typical market ranges for application-to-venue network round trips. Actual results depend on venue access, route, hardware, packet size and measurement point.

Ranges are indicative market figures, not audited results or quotes. For infrastructure comparisons and terminology, see Trading Technology's infrastructure coverage. Compare like for like: a colo rack quote against a cloud estimate that includes data transfer, support, redundancy and software licences.

Days 1-5: establish a baseline

Choose one representative instrument, venue and order flow. Record the path from market-data receipt through strategy or broker logic, risk checks, order gateway and venue acknowledgement. Measure both directions where relevant. A ping from a server is not a substitute for application-level timestamps.

Use hardware timestamping and PTP where the network supports them. Check clock offset and drift, and keep software timestamps at each meaningful boundary. Capture p50, p99 and p99.9 latency, throughput, packet loss, reconnect time and order rejects. Run during busy market periods as well as quiet ones. Keep packet size, order rate and data feed consistent across environments.

• Map every dependency, including DNS, authentication, risk services, market data, persistence and monitoring.
• Record current capacity, CPU and NIC utilisation, queue depth, licence constraints and recovery objectives.
• Separate normal-session measurements from bursts, failovers and market-open conditions.

Agree what counts as a pass before testing. For example, set a p99 latency ceiling and a maximum recovery time based on the strategy or service, rather than selecting a winner after seeing the results. Include the operations team in that decision.

Days 6-12: test the colocation path

Use the intended production hardware and network design, or a representative setup with the same NIC, CPU generation and kernel configuration. Check the physical route, cross-connect hand-offs, port speed and any carrier or venue gateway between your rack and the exchange. For low-latency workloads, confirm whether the stack uses kernel bypass, such as DPDK or a vendor's user-space driver, and test the exact software build that will run in production.

Do not treat a short, clean test as proof of steady-state performance. Run sustained order and market-data loads, then test failover across switches, feeds and power paths.

Confirm that packet capture, telemetry and security controls do not add unacceptable overhead. Record the operational work too: hardware replacement, remote hands, access procedures, spare parts and time to restore a failed node.

Colocation usually brings tighter control over the physical path, but it transfers work to your team. A rack needs capacity planning, patching, asset records and a tested way to recover when a component fails. A second site can reduce concentration risk, but adds replication, routing and support costs.

Days 13-21: test the cloud path

Deploy the same application version and configuration in the intended cloud region. Pin the instance family, placement and network features; a general-purpose virtual machine is not a fair proxy for a tuned production host. Test a dedicated host or bare-metal option if offered. Measure the route to the actual venue edge, not just latency between two instances in one availability zone.

Run identical traffic replay and live shadow tests. Keep the cloud stack from sending duplicate live orders. Compare tail latency as well as averages, and include burst scaling, host maintenance, instance replacement and route changes.

Inspect packet loss, retransmits, CPU steal or throttling, storage stalls and network charges. Test direct connectivity where available, and verify that its cross-connect or gateway path is included in the design.

Cloud can suit development, analytics, client-facing services, disaster recovery and workloads with variable demand. It also offers fast provisioning and a useful route to geographic expansion. But a low average RTT does not guarantee stable tails. Virtual network paths, placement changes and shared infrastructure can introduce variation, while egress and always-on redundancy can make the monthly cost less elastic than expected.

For more on the systems brokers depend on, browse broker technology coverage. Keep the comparison grounded in your own traffic and provider terms.

Days 22-30: choose placement and rehearse the move

Assign each workload to the location that meets its latency, availability and operating requirements. Many firms use a split design: execution gateways and latency-sensitive market-data handlers near the venue; development, reporting and elastic analytics in cloud; and a separately tested recovery path.

Risk checks need special attention. Moving them away from order entry can add a network hop or create a failure dependency, so test the complete order path before changing placement.

Build the business case using a 12-month view. Include hardware depreciation, rack and cross-connect charges, staff time, cloud compute, storage, egress, support, licences and the cost of a second failure domain.

Compare the cost per million orders or per unit of market-data throughput. Check peak capacity, not only average utilisation, and include the cost of unused reserved capacity.

• Document the chosen topology, routing rules, ownership, alert thresholds and rollback trigger.
• Rehearse cutover with a small, controlled cohort, then check acknowledgements, rejects, sequence gaps and reconciliation.
• Keep the old path available until the new path has passed a defined observation period and recovery test.

Do not migrate every service at once. A broker may move reporting or a client API first, while a prop firm may shadow a market-data handler before changing order routing.

Set a named owner for each change and agree how operators will return traffic to the known-good path. This week, instrument one representative order path and record its p50, p99 and p99.9 latency at the venue edge.

#infraestrutura de broker #infraestrutura de trading #infraestrutura de dados de mercado #colocation de servidores de trading #infraestrutura de trading em nuvem #trading de baixa latência #recuperação de desastres #latência na nuvem