Picture this: Bare-metal servers colocated inside or directly adjacent to an exchange’s data center, running on dedicated (non-shared) hardware with kernel-bypass networking, which best suits low-latency trading applications. Nice, isn’t it?
Standard multi-tenant public cloud virtual machines typically introduce too much latency and jitter for competitive execution, since they share physical resources and route through infrastructure that was never designed for microsecond-level consistency.
This distinction matters more every year. Roughly 89% of global trading volume is now driven by algorithms, and the high-frequency trading market is projected to grow from $10.36 billion in 2024 to $16.03 billion by 2030, putting sustained pressure on exchanges to rebuild around speed.
Why standard cloud VMs fall short for trading applications
Standard cloud VMs fall short since they’re built for flexibility, not deterministic timing. Virtualized instances run on a hypervisor. They share physical CPU cycles with other tenants. This contention creates jitter that no amount of code optimization can fix.
Routing makes this worse. Trading over the public internet, even within the same cloud availability zone, typically incurs 1 millisecond or more of latency. Single-digit microseconds decide the outcome in algorithmic trading. A connection that is a thousand times slower is completely disqualifying.
What counts as low latency in a trading context
Low-latency trading is measured in two ways, and mixing them up leads to poor infrastructure decisions. Wire-to-wire latency measures the total time a packet spends in the network. Tick-to-trade latency measures only the internal processing time between the receipt of market data and the generation of an order.
Top firms achieve single-digit microsecond wire-to-wire latency. Institutional systems usually run between 200 and 500 microseconds. They hit these speeds using kernel bypass and purpose-built hardware. At the absolute edge, internal tick-to-trade logic must execute in under 800 nanoseconds with FPGA acceleration.
Why proximity to the exchange matters more than raw compute power
Proximity matters more than compute power because light itself takes measurable time to travel, and at microsecond scales, physical distance becomes the dominant factor. Firms have documented cutting latency by 40% simply by using dedicated microwave links between financial hubs such as London and New York, rather than standard fiber routing.
The effect is dramatic even at a local scale. One documented case saw latency drop from 25 milliseconds to 2.5 milliseconds, a 10x improvement, purely from moving off shared cloud infrastructure onto bare metal positioned near the exchange. As one infrastructure specialist put it, for trading firms the architecture often doesn’t need to change. The location does.
Rack placement inside a facility matters too, not just which building. In data centers like Equinix’s LD4, a major London financial hub, firms compete intensely for specific rack space, because a few kilometers are enough to meaningfully slow execution, while a few meters within the same facility barely register. Distance matters, but only down to a point where physics genuinely takes over from optimization.
If your trading stack currently runs in general-purpose cloud regions, it’s worth evaluating dedicated, high-performance infrastructure located closer to the exchanges you actually trade on before assuming the code is where your latency problem lies.
How bare metal differs from virtualized cloud for trading workloads
Bare metal differs from virtualized cloud by removing the hypervisor entirely, giving a trading application dedicated, uncontended access to CPU, memory, and network hardware. That predictability is the entire point: a virtualized instance can perform well on average and still spike unpredictably under load, which is exactly the kind of inconsistency a trading strategy can’t absorb.
Bare-metal setups also allow low-level tuning that shared cloud instances don’t support. Modern processors default to power-saving sleep states that introduce microsecond wake-up delays when a core receives a new signal.
Competitive trading infrastructure forces the CPU into a permanently active state instead, trading power efficiency for consistent response time, since a processor that’s asleep even briefly can cost more time than the entire rest of the execution path combined.
What is stock exchanges of India doing to cut latency
India’s National Stock Exchange is currently rolling out an architecture upgrade targeting nanosecond-level latency, roughly a 1,000x speed increase over its previous system, alongside a target of 100 million transactions per second. To support that, NSE is expanding its colocation infrastructure from over 2,000 racks to around 4,500, providing trading firms with space to install servers directly in the exchange’s data center.
This matters for infrastructure decisions today, not just for firms already colocated. As India’s exchange infrastructure speeds up, the gap between a colocated, bare-metal setup and a standard cloud deployment widens further, making the choice of infrastructure more consequential than it was a few years ago.
For firms building or scaling trading infrastructure in India, working with a provider that understands low-latency, India-based infrastructure requirements matters more as this gap continues to widen.
Five infrastructure choices that reduce trading latency
A handful of concrete decisions separate competitive trading infrastructure from infrastructure that merely works. None of them require rebuilding a trading stack from scratch, just the right priorities at the hardware and network layer:
- Choose bare metal over virtualized or shared instances, removing hypervisor overhead and resource contention entirely
- Prioritize colocation or exchange-adjacent placement over standard cloud regions, since physical distance directly adds latency
- Use kernel bypass networking to skip the standard operating system network stack for order-entry and feed-handling paths
- Disable CPU power-saving states, forcing processors to stay fully active instead of sleeping between signals
- Add FPGA or SmartNIC acceleration for the most latency-sensitive processing, where budget and strategy justify the added complexity
Does public cloud still have a role in a trading stack
Public cloud still has a real role, just not in the execution path itself. Standard cloud infrastructure remains well suited for risk management, compliance reporting, backtesting, and analytics, workloads that benefit from cloud flexibility and don’t depend on microsecond timing to function correctly.
The mistake is treating the entire trading stack as one infrastructure decision. Execution needs bare metal and proximity. Everything around execution can reasonably run on standard cloud infrastructure without any competitive disadvantage.
Conclusion
Low-latency trading infrastructure isn’t really a cloud-versus-bare-metal debate anymore; it’s a question of which parts of your stack actually need microsecond consistency and which don’t. Execution belongs on dedicated, exchange-adjacent hardware. Everything else- risk checks, compliance, analytics, backtesting- can run on standard cloud infrastructure without giving up any real advantage.
Getting that split right matters more each year as exchanges themselves keep getting faster. A trading stack built entirely on standard cloud infrastructure isn’t just slower today; it’s falling further behind with every latency upgrade the exchanges make, whether or not the firm running it notices the gap widening.
Frequently Asked Questions
What’s the difference between wire-to-wire and tick-to-trade latency?
Wire-to-wire measures total time a packet spends in the network. Tick-to-trade measures only the internal processing time between receiving data and generating an order, which is the number FPGA acceleration is specifically built to reduce.
Can a public cloud VM ever be fast enough for HFT?
For the highest-frequency strategies, generally not. Public cloud VMs typically run at 1 millisecond or slower even within the same availability zone, compared to single-digit microseconds for colocated bare metal.
Why is colocation still growing in 2026?
Because algorithmic trading now drives the large majority of volume, and colocation remains the most reliable way to minimize the physical distance between a trading system and an exchange’s matching engine. The data center colocation market as a whole is growing at roughly 12.7% annually, and financial services firms chasing execution speed are a meaningful part of that demand.
How is India’s NSE reducing trading latency?
NSE is rolling out a new architecture targeting nanosecond-level latency and 100 million transactions per second, while expanding colocation capacity from over 2,000 racks to around 4,500 to accommodate demand.
Is bare metal always better than cloud for trading?
For the execution path specifically, yes. For supporting functions such as compliance, analytics, and backtesting, standard cloud infrastructure works well and offers the flexibility that bare-metal doesn’t provide.
