Skip to content
Notifications
Clear all

Anyone running Cloudflare One on ARM servers in production?

2 Posts
2 Users
0 Reactions
4 Views
(@cost_cutter_ray)
Estimable Member
Joined: 2 months ago
Posts: 113
Topic starter   [#2873]

Having conducted a significant number of cost optimization audits across hybrid and multi-cloud environments, I've observed a growing trend of organizations leveraging ARM-based infrastructure (AWS Graviton, Azure Ampere, Google Cloud Tau T2A) for its compelling price-performance ratio. This naturally leads to a critical architectural consideration for those implementing a Secure Access Service Edge (SASE) model: can the control plane and data plane of your SASE solution, specifically Cloudflare One, run natively on this modern, cost-efficient architecture?

My primary inquiry is focused on production deployments. I am seeking concrete data points from community members who have deployed Cloudflare One's components—specifically Cloudflare Tunnel (`cloudflared`), the WARP client endpoint, or any associated monitoring/management workloads—on ARM servers (64-bit ARMv8/AArch64) in a sustained production environment.

The key areas of interest for my analysis are:

* **Operational Stability:** Have you encountered any systemic issues with the core connectivity functions (tunnel stability, latency, packet loss) when running on ARM versus x86?
* **Performance Parity:** Are you observing equivalent or superior throughput and connection establishment times? Instrumented data comparing similar instance types (e.g., Graviton vs. Intel Xeon) would be invaluable.
* **Package & Dependency Management:** How seamless was the provisioning process? Are official, maintained ARM64 binaries/packages/Docker images available for all necessary components, or did you need to compile from source?
* **Cost Impact Analysis:** This is my core expertise. Have you quantified the TCO reduction? A typical breakdown I would model includes:
* Direct compute instance cost savings (often 20-40% lower for comparable ARM instances).
* Any ancillary cost changes (e.g., network egress patterns, load balancing costs).
* Operational overhead costs if the ARM deployment requires unique management scripts or monitoring configurations.

For context, a basic container deployment on ARM might look like this, but the devil is in the production-scale details:

```dockerfile
# Example Dockerfile snippet - is an official ARM64 image provided?
FROM cloudflare/cloudflared:latest
# Or must one use a multi-arch manifest or build explicitly?
```

I am particularly wary of hidden costs that can emerge from architectural compromises, such as the need to maintain a separate x86 fleet for certain unsupported functions, which can erode the raw instance savings. Any detailed workflow reports, performance comparisons, or pricing feedback from your production experience would significantly contribute to the community's understanding of where ARM stands within the Cloudflare One ecosystem today.

- cost_cutter_ray


Every dollar counts.


   
Quote
(@chloem)
Estimable Member
Joined: 1 week ago
Posts: 70
 

Great question. Your point about the price-performance ratio is exactly why we started looking at Graviton instances last year. We've been running `cloudflared` in a production, containerized environment on AWS Graviton3 for about 10 months now, specifically for tunneling to internal web apps.

On operational stability, we've seen zero difference from the x86 deployments. The tunnels come up and stay up. For performance parity, our metrics around latency and throughput are statistically identical for our use case, which involves moderate bandwidth.

The only real caveat we ran into wasn't with Cloudflare's software, but with some older internal monitoring agents that didn't have ARM builds. Once we swapped those out, it's been completely transparent. I'd be curious if anyone has pushed the WARP client on ARM endpoints at scale and noticed any quirks.



   
ReplyQuote