Cloud Native Qumulo (CNQ) runs the same distributed file system as every other Qumulo deployment, but it's built for a cloud-native shape: a compute instance with a thin flash-cache tier that fronts a durable object store where the data actually resides. The cache layer provides fast read and write access to the object store — Amazon S3, Azure Storage, or Google Cloud Storage, depending on where you run — which persists the actual data, indefinitely, at whatever scale your dataset grows to.
Compute and capacity scale independently of each other, which is the whole point: you size the nodes in your CNQ cluster for the performance you need today rather than the amount of data you'll eventually have. The ability to dynamically reconfigure your compute nodes down the road for more (or less) throughput as your workloads evolve eliminates the risk of over- or under-provisioning at the time of deployment.
That architecture is consistent across clouds, meaning that the file system is the same wherever you run it. What sits underneath it is broadly similar, but since each cloud platform differs in the details, the process of sizing CNQ for your workload varies according to the platform you’ll run it on.
One platform, three approaches
Each hyperscaler publishes ceilings for network bandwidth, attached-disk throughput, and local NVMe performance, in its own terms and for its own families of instances. Once you're sizing a node, what matters is how those ceilings relate to each other on the hosting cloud provider.
Object storage
Amazon S3, Azure Storage and Google Cloud Storage each publish their own throughput and request limits, and their own rules for how that traffic counts against an instance's bandwidth. The sizing guidance for AWS won’t apply to Azure or Google Cloud, and vice-versa. Each hyperscaler’s performance calculations need to factor in that platform’s published maximums in order to properly size each CNQ node for the target workload.
Instance types
The compute nodes themselves also vary by cloud: whether a size has local NVMe at all, how many disks it attaches and at what tier, and whether the write cache lands on that local NVMe or on network-attached block storage are all defined per cloud, per family and per generation, sometimes within a single provider's own instance-type page. Some instance types fall outside of CNQ’s requirements, and the ones that are supported each come with performance and throughput considerations that must be factored in.
Network and disk – throughput and accounting
Every cloud has its own rules for how network and disk traffic are metered: guaranteed baselines and burst allowances, whether inbound and outbound traffic share a budget, and whether disk traffic counts against the same bandwidth ceiling as client traffic. Those rules decide which published number a sustained write hits first, and how many times it draws on it.
Why This Needs to Be Interactive
Combine those three factors into a single cloud compute instance, with CPU, memory, locally attached storage, and network connectivity, and the differences become critical in gauging the level of performance you can reasonably expect. At that point, a single static sizing table stops being useful.
The ceiling that actually binds for a given workload depends on which cloud you're running on, which instance family (and which generation) you choose, whether your workload is primarily streaming writes, streaming reads, mixed random small reads and writes, etc. The answer changes as you adjust any of those axes. A PDF can't branch like that. When sizing CNQ for a real-life workload, a customer needs an interactive tool that can consider the specific, real-life capabilities of the customer’s choice of compute instances on the customer’s choice of cloud platform, then analyze the shape of the workload and then show where the ceiling is for that instance type.
Introducing v1.0: The Ceiling Explorers
That's what we built — separate interactive sizing tools for AWS, Azure, and Google Cloud. Each lets you pick a supported instance size and a workload shape — a large sequential write, a cached read, a small-file-heavy pattern, and read-heavy working sets that are larger than the provisioned cache — and ranks the published ceilings that actually apply, flagging the limiting factor that binds and showing how far the runner-up sits above it. Where a cloud publishes a range rather than a single number — a guaranteed floor and a burst ceiling, or a platform maximum against what our own provisioning actually reaches — the tools show the upper and lower limits and clearly state which one the ranking uses and why.
How We Built Them
Each tool started from Qumulo's own architecture: what is actually attached at the time of deployment and how it interacts with the provider’s own cloud primitives. We then checked, size by size, against that provider's own published specification pages.
Where a cloud's own published figures disagree with each other (it happens), we rank against the smaller, verifiable number rather than the larger, harder-to-verify one. As cloud providers ship new instance generations and revise what they publish, and as the list of sizes Qumulo supports moves with them, the tools get updated to match.
What These Tools Are — and Are Not
A few things worth adding before you click ahead to the tools:
These are published ceilings, not benchmarks. Nothing on any of these pages was tested by us as part of this process. A ceiling tells you what you cannot exceed; it doesn't guarantee that that’s what your workload will actually get.
Where we show a range instead of a single number, that's deliberate, not a hedge. Cloud providers themselves often publish a guaranteed floor and a burst ceiling, or a platform maximum that differs from what's actually provisioned. Workload variability, protocol overhead, and cluster-mirroring traffic mean your actual throughput will land somewhere in that range rather than at a fixed point.
Every figure is per node, not per cluster. This one is important: A Cloud Native Qumulo deployment is always more than one node – typically a minimum of three, in fact – and net cluster throughput isn't simply a per-node ceiling multiplied by node count — inter-node traffic and any underlying subscription-level limits can shade the numbers in ways that the tool can’t identify.
These reflect a point-in-time read of constantly moving specifications. Cloud providers ship new instance generations and revise published limits regularly, and the list of instances our own deployment tooling supports moves with them. Treat these tools as a current best read, not a permanent one, and confirm against live documentation before locking in a size for a large deployment.
One tool per cloud. The three tools follow the same method, but each considers only its own cloud's published limits. They aren't built to compare clouds against each other, so don't read figures across tools.
This is v1.0. Both the tools themselves and the caveats outlined here will continue to evolve as cloud providers update their services and as we add or remove instance types from our supported Terraform configuration guides (available here for AWS, here for Azure, and here for Google Cloud). If you're sizing a deployment and something here doesn't match what you're seeing, we want to hear about it.
Explore
AWS Explorer
Azure Explorer
Google Cloud Explorer