Module 04
Cloud and Disaggregated Architectures
What actually changes when the file system stops sitting on disks it owns: Cloud Native Qumulo on object storage, the managed-versus-self-managed split that decides who operates it, Stratus bringing the same separation on premises, and the cloud economics that decide whether any of it is a good idea.
- Advanced
- 40 min
- Reviewed Jul 27, 2026
- Next review Oct 27, 2026
AssumesModule 3 — Qumulo Core Architecture · Basic familiarity with cloud compute and object storage billing
Module 3 ended on a claim that sounds like marketing until you understand the block store: the same file system runs on a rack of servers and on cloud object storage without being rewritten. This module is where that gets specific.
The through-line: capacity and the compute that serves it stop being the same purchase. Everything else here — the cloud products, Stratus, the economics, the operational split — follows from that one separation.
The promise
By the end of this module you should be able to:
- Explain what disaggregation actually means at the storage layer, not as a buzzword.
- Draw how a write reaches durable storage in a cloud deployment.
- Tell a customer which Qumulo cloud offering they are actually being sold, and who operates it.
- Name the cloud cost lines that decide the business case, including the ones customers forget.
- Say where the cloud version is the wrong answer.
Key terms
Disaggregation — separating the durable storage layer from the compute that serves it, so each scales and fails independently. Persistent layer — where the data actually lives durably. Object storage, in the cloud. Cache tier — fast local media in front of the persistent layer, absorbing reads and buffering writes. Stateless compute — serving nodes holding no unique durable state, so losing one costs performance, not data. Write compaction — combining many small writes into fewer, larger object operations before they hit the persistent layer.
1. What disaggregation actually means
Cloud Native Qumulo on AWS is documented as a self-managed AWS VPC deployment that provisions EC2 instances and uses AWS infrastructure for a Qumulo file system, a design that allows the disaggregation of persistent storage from compute resources. Deployment is a two-step sequence: create persistent storage using S3 buckets, then deploy cluster compute and cache resources.
Scope AWS specifically. The two-step deployment order is the architecture made visible: capacity exists independently of, and outlives, the compute that serves it.
Read the deployment order in that claim again, because it is the architecture made visible. You create the S3 buckets first. You deploy compute second.
The capacity exists before the cluster does, and it outlives the cluster. That is the whole idea in one operational detail: the persistent layer is the durable thing, and compute is a serving tier you provision against it.
Qumulo states that Cloud Native Qumulo separates compute from capacity using a mirrored NVMe cache tier for fast writes paired with cloud object storage, with a caching layer that anticipates data access to deliver NVMe-class latency.
Scope Vendor description of the caching architecture. "NVMe-class latency" is a characterisation, not a measured figure, and applies to cache hits.
The cache tier is not a nicety here — it is load-bearing. Object storage has throughput that is fine and per-operation latency that is not. Putting a file system directly on it, with no cache, produces something technically correct and practically unusable for interactive workloads. The cache is what makes the economics of object storage survive contact with a user waiting on a file.
2. Same file system, honestly qualified
Qumulo's documentation states that Cloud Native Qumulo on AWS provides the same multi-protocol support, interfaces, and functionality as Qumulo on premises, including NFS, SMB, and S3 API access.
Scope Functional parity of protocols and interfaces. It is NOT a statement about performance parity, which depends entirely on instance selection, network, and object-tier behaviour.
This is a strong claim and it is worth using — but note precisely what it covers.
It covers protocols, interfaces, and functionality. SMB is SMB. Your identity integration works. Your applications do not know they moved. The operational model your team learned on premises transfers.
It does not cover performance. Nothing in that statement promises the cloud deployment performs like the on-premises one. Performance is a function of instance type, instance count, network, cache sizing, and how the object tier behaves under your access pattern.
3. The limits nobody puts on a slide
Qumulo documents operational limits for Cloud Native Qumulo on AWS, including a maximum cluster size of 24 nodes when deployed via CloudFormation, a requirement that gp3 volumes with custom IOPS and throughput settings complete EBS optimization before running high-performance workloads, and the fact that S3 buckets are subject to throttling prior to partition scale-up.
Scope These are the numbers that matter in a design review and they are the ones least likely to appear on a slide. The S3 partition-scale-up throttling behaviour in particular is a real early-life performance characteristic: a benchmark run immediately after deployment may not represent steady state.
Note Re-verify the 24-node CloudFormation limit before sizing. Documented limits change between releases far faster than architecture does.
Three things in there deserve unpacking, because they are the kind of detail that separates a design review that holds up from one that does not.
The 24-node CloudFormation ceiling is a deployment-method limit, not an architectural one. Know which you are quoting — Module 3 was emphatic about that distinction and it applies here directly.
gp3 EBS optimization must complete before high-performance work. Practically: do not benchmark a freshly deployed cluster and treat the result as steady state.
S3 throttling prior to partition scale-up is the subtle one. Object storage partitions scale in response to sustained request rates. A brand-new bucket has not scaled yet, so early request rates can be throttled in a way that resolves as the workload persists.
4. Which product is actually on the table
This is the section that saves deals, and it starts with a problem in the vendor’s own materials.
Qumulo's own public materials describe the Azure offering inconsistently. The Cloud Native Qumulo product page presents Azure as a fully managed SaaS experience integrated into the Azure portal, while the documentation portal separates Cloud Native Qumulo (self-managed on AWS, Azure, and GCP) from Azure Native Qumulo (Qumulo-managed) as distinct offerings.
Scope Observation about vendor documentation as of this date, not a claim about the products themselves. Both statements may be individually defensible; read together they are confusing.
Note HIGH FIELD VALUE. Managed versus self-managed is the single most important question in an Azure Qumulo conversation, because it determines who operates the platform, who is on call, and which cost centre pays. Establish which offering is actually on the table before designing anything, and do not resolve the ambiguity from a marketing page.
Public technical depth on Azure Native Qumulo is limited. The Azure Native administrator guide's landing page lists topics for performance characteristics, default limits, and supported configurations, but does not expose provisioning, billing, or scaling specifics at the index level, and this guide publishes no ANQ figures it could not read from a primary source.
Scope A statement about this guide's sourcing limits, not about the product.
Note Same discipline as competitor-verification-gaps. Pull ANQ limits and billing detail from the current administrator guide directly before any customer commitment.
The general shape, which is stable even while the naming is not:
| Self-managed | Vendor-managed | |
|---|---|---|
| Who runs it | Customer’s team | Qumulo |
| Resources live in | Customer’s own cloud account | Managed by the vendor |
| Control | Maximum | Traded for convenience |
| Right when | Team has cloud operational maturity and wants control | Customer wants file services, not a platform to run |
5. Stratus: the same idea, on premises
Qumulo describes Stratus as a disaggregated, shared-nothing design with two independent layers: Stratus Accelerators, stateless high-performance compute nodes that run the Qumulo file system and handle NFS, SMB, S3 and encryption; and Stratus DataCore, a shared durable storage foundation optimised for capacity and cost-efficiency.
Scope Vendor-published architecture description. The word that matters is "stateless" - it is what allows the compute layer to be scaled, replaced, or lost without implicating the durable layer, and it is the same separation CNQ achieves in the cloud, brought on premises.
Note what this is: the cloud architecture brought back on premises. Stateless compute over a durable shared capacity layer — the same separation as CNQ over S3, with the durable layer being something you own.
The word doing the work is stateless. Because the Accelerators hold no unique durable state, losing one costs throughput, not data, and scaling performance means adding serving capacity without touching the capacity layer at all.
Qumulo states that in Stratus each tenant has dedicated encryption keys and data is encrypted before reaching shared storage, so multi-tenant isolation is cryptographically enforced rather than administratively enforced.
Scope The distinction between cryptographic and administrative isolation is architecturally meaningful and worth explaining to a security buyer. It is also exactly the kind of claim a security team will want evidence for - key management, key custody, and rotation are the follow-up questions, and this guide does not have public answers to them.
6. The economics
Cloud file storage business cases fail in predictable places. Most of them are not the storage price.
The lines customers model: object storage capacity, compute instances.
The lines they forget:
- API request charges. Per-operation costs on the object tier. For metadata-heavy or small-file workloads this can be a startling share of the bill, and it scales with access patterns rather than capacity.
- Data transfer. Egress, cross-region, cross-AZ. Frequently the single largest surprise.
- The cache tier. Fast local media is not free and is sized for performance, not capacity.
- Idle compute. The serving tier costs money whether or not anyone is reading.
- Migration. Moving petabytes takes time, bandwidth, and staff attention.
- Operational staff. Especially under self-managed.
On its Cloud Native Qumulo page, Qumulo states NeuralCache achieves cache hit rates over 96%, up to 100x faster time-to-first-byte compared to native object storage, and can cut transaction fees by over 99% through write compaction before writes reach object storage. The same page states support for workloads requiring 1 TBps or more of sustained throughput.
Scope All four are vendor figures with no published methodology, workload definition, or measurement date. The 100x time-to-first-byte comparison is against raw object storage, which is a low bar by design - that is the entire reason a cache tier exists. The transaction-fee reduction is the most commercially interesting of the four because API request charges are a real and frequently underestimated line item in cloud file architectures, but it still requires the customer's own access pattern to mean anything.
Note NOTE THE TENSION with arch-cache-hit-rate-95, which cites ~95% from the technical architecture page as a global fleet figure. This page says "over 96%" for NeuralCache. Different scopes, different pages, similar-sounding numbers. Do not blend them into one claim, and do not present either as a prediction for a specific customer.
Lab — Tier 0, no product access required
Practice questions
1. A customer asks: “If it’s the same product, why would performance be different in the cloud?”
Answer. Because functional parity and performance parity are different claims. The protocols, interfaces, and functionality are the same, which is why applications and identity integration transfer unchanged. Performance depends on instance type and count, network, cache sizing, and how the object tier responds to the access pattern — none of which have on-premises equivalents that carry over.
Why this matters. Conceding this clearly, early, and unprompted is what makes the functional-parity claim credible. It is a genuinely strong claim and it survives scrutiny only when properly bounded.
2. A POC on a freshly deployed cloud cluster benchmarks poorly on day one. What are the two documented explanations you should check before concluding anything?
Answer. First, gp3 volumes with custom IOPS and throughput settings need EBS optimization to complete before high-performance workloads. Second, S3 buckets are subject to throttling prior to partition scale-up, so a new bucket has not yet scaled to the sustained request rate.
The field lesson. Both are documented, both are transient, and both sound like excuses if you raise them after a bad number. Build a warm-up period into the POC plan and get it agreed in writing before anyone runs a benchmark.
3. A customer on Azure says “we’re looking at the managed Qumulo service.” What do you establish before designing anything?
Answer. Exactly which offering they mean, because Qumulo’s own public materials are inconsistent on this point — the CNQ product page describes Azure as a fully managed portal-integrated experience, while the documentation portal treats self-managed CNQ and Qumulo-managed ANQ as distinct offerings. Establish who operates it, who is on call, how it is purchased, and whose subscription holds the underlying resources.
Why this is question three and not question thirty. Managed versus self-managed determines the operational model, the support relationship, and the cost centre. It is not a detail to resolve later; every design decision downstream depends on it.
4. Explain the difference between administrative and cryptographic tenant isolation, and why a security architect cares.
Answer. Administrative isolation means the system is configured such that tenants cannot access each other’s data — correctness depends on that configuration remaining correct indefinitely. Cryptographic isolation means each tenant’s data is encrypted with dedicated keys before reaching shared storage, so access to the underlying storage does not yield readable data.
The second removes a whole class of misconfiguration and insider-access risk rather than mitigating it. Security architects care because it changes what has to be true for the guarantee to hold.
The honest follow-up. Key custody, rotation, and compromise handling are the next questions, and this guide has no public answers for them. Say that rather than improvising.
Summary
- Disaggregation means the durable layer and the serving layer are separate purchases with separate lifecycles. The two-step deployment order is that idea made concrete.
- The cache tier is load-bearing, not a nicety — object economics need it to be usable.
- Functional parity is documented and strong. Performance parity is not claimed and should not be implied.
- Documented limits (24-node CloudFormation ceiling, EBS optimization, S3 partition throttling) belong in your design review, not discovered in a POC.
- Qumulo’s own Azure naming is currently inconsistent. Establish which offering is on the table before designing.
- Stratus is the same separation on premises: stateless Accelerators over a durable DataCore.
- Cryptographic isolation is a real architectural distinction — and key management is the follow-up you cannot answer from public sources.
- Business cases break on data movement and per-operation charges, not on capacity price.
Field checklist
- I can draw the two-box picture and say the two sentences.
- I say “functional parity, not performance parity” without being asked.
- I know which Azure offering is in scope, in writing.
- My POC plan has a documented warm-up period.
- My TCO model includes egress and API request charges.
- I can make the honest case for staying on premises.
Sources and currency
Every claim on this page resolves to the source ledger. CNQ architecture and limits come from Qumulo’s Cloud Native AWS Administrator Guide; the caching, NeuralCache, and Stratus material from Qumulo’s product pages, labelled as vendor claims.
Azure Native Qumulo is deliberately thin here. Its public technical depth was
limited at the time of the source pass, and this guide publishes no ANQ figures it
could not read from a primary source — see anq-public-depth-gap in the ledger.
Cloud limits and pricing move faster than anything else in this curriculum;
re-verify against current documentation before any customer commitment. Reviewed
27 July 2026.