Cloud vs on‑prem split
Recent analysis argues the right answer isn't cloud or on‑prem, it's to place workloads by latency tier: keep exchange‑facing, sub‑millisecond work in colo/on‑prem and move elastic, experiment‑heavy services to cloud. The recommended pattern is explicit interfaces between the hot path and flexible systems so changes outside the critical path can't destabilize execution. (x.com)
The split is getting sharper: keep the trading “hot path” next to the exchange, and push elastic research, analytics, and support systems into the cloud. (aws.amazon.com) In market structure, “latency” means delay, measured in thousandths or millionths of a second, and firms still pay for colocation so their servers sit inside or beside exchange data centers. Nasdaq says its co-location service cuts round-trip latency by an average of two to five microseconds. (nasdaqtrader.com) The reason is mechanical: market data comes in, software decides, and an order goes back out, all inside a tiny time budget. Amazon Web Services wrote that much traditional equity activity happens within the first 1,000 microseconds after an order is placed, with much of it in the first 100 microseconds. (aws.amazon.com) That is why the architecture debate has shifted from “cloud or on-premises” to “which workload belongs where.” Amazon Web Services says exchanges and trading systems have different performance targets, and its Outposts hardware is meant for applications that must stay on-premises for low-latency or local-processing needs. (aws.amazon.com, aws.amazon.com) The cloud side of the split is not just back-office processing anymore. Google Cloud said in June 2024 that CME Group planned a private Google Cloud region and a co-location facility in Aurora, Illinois, to support futures and options trading with cloud-based ultra-low-latency networking and high-performance computing. (prnewswire.com) Nasdaq and Amazon Web Services made a similar case on April 24, 2025, when they unveiled a market-modernization blueprint that puts exchange, cloud, and trading participant infrastructure in a common location. Nasdaq’s own co-location materials say customers use cabinets inside its data center for proximity to its United States markets. (a-teaminsight.com, nasdaqtrader.com) The operating rule underneath those projects is separation. The execution loop that touches the exchange stays small and predictable, while model training, simulations, data science, surveillance, and other bursty jobs move to systems that can scale up and down on demand. (aws.amazon.com, cloud.google.com) That separation only works if the handoff is explicit. Google Cloud’s exchange work highlights low-latency messaging tools such as Aeron, and Amazon Web Services’ low-latency exchange design breaks functions into defined services so developers can change non-critical components without rewriting the matching or order-handling core. (cloud.google.com, aws.amazon.com) Cloud providers argue the gap is narrowing for some front-office jobs. Google Cloud cited testing with 28Stone that examined the full loop from market-data ingest to order transmit on C3 machines, while Amazon Web Services has argued cloud environments can deliver latency profiles comparable to on-premises systems for some exchange designs. (28stone.com, aws.amazon.com) But the exchanges themselves still sell proximity as a product. Intercontinental Exchange says its global network offers colocation in trading centers across the United States, Canada, and Europe, and the New York Stock Exchange maintains colocation operating policies for its liquidity centers. (ice.com, nyse.com) So the practical answer is not a winner-take-all platform. The fastest code stays where microseconds decide fills, and the rest moves to infrastructure built for scale, iteration, and change. (aws.amazon.com, prnewswire.com)
