AWS EC2 ceiling explorer

Interactive companion

Which ceiling is lowest?

A Cloud Native Qumulo node on AWS inherits its performance ceilings from the EC2 instance underneath it. Pick a size and a workload shape, and this page ranks the two published AWS ceilings that actually apply.

Read this first

These are AWS's published limits for the seven EC2 families Qumulo supports on AWS — m6i, m7i, m6idn, i4i, i7i, i7ie and i3en — plus AWS's own EC2 On-Demand pricing. Qumulo recommends 2xlarge or larger for production, so smaller sizes are excluded; see the measure note below the controls. m6i and m7i have no local NVMe and are intended for AWS Local Zones and other locations without storage-optimized instances; both need Qumulo Core 7.4.3 or later. They are not Qumulo guidance and not a benchmark.

AWS ships new instance generations regularly and Qumulo's supported list moves with them. For the most recently supported instance families, sizes and configurations, refer to Qumulo's guide to deploying Cloud Native Qumulo on AWS with Terraform and the provider's supported instance types reference before you size anything.

Pick a size and a workload shape

Bare-metal sizes are excluded from every family: in each one checked, the .metal size matched the top virtualized size in vCPU, memory, network, EBS bandwidth and price exactly (or within a fraction of a cent), so it would only duplicate a row already here. Sizes below 2xlarge are excluded too — Qumulo does not recommend anything smaller for production deployments, so large and xlarge don't belong in a sizing tool.

EC2 family
Size
Workload shape
 

    Network against the EBS-optimized path — floor-to-ceiling ranges, across the family

    Both columns show each size's full published range — guaranteed floor to "Up to" burst ceiling — converted to megabytes per second so they can be compared at all. Ranking is on the floor, not the ceiling: that reflects how Qumulo actually provisions CNQ's write cache; see the limits below. The last column answers for the workload shape selected above, so it changes when that does.

    Scroll the table sideways to see every column.

    Size vCPU Network MB/s (floor–ceiling, per node) EBS MB/s (floor–ceiling, per node) EBS floor as % of network floor Lowest published ceiling
    Mandatory caveat. This ratio is our arithmetic on AWS's published figures, not an AWS or Qumulo benchmark. AWS's own docs note that EBS performance is bounded by whichever is smaller — the instance's own limit, or the combined performance of the volumes actually attached — so reaching even the guaranteed EBS figure shown here requires enough attached gp3 volumes provisioned with enough combined IOPS and throughput to fill it. AWS documents EBS-optimized bandwidth as a "dedicated" allowance, separate from network bandwidth — its own docs never describe the two as sharing one physical NIC. Treat this as a planning heuristic for sizing, never as a performance model.

    The network curve across sizes

    Each family draws two curves — a solid, marked line at the guaranteed floor (the figure this page actually ranks against) and a faint, unmarked line above it at the published burst ceiling, so the real range per size is visible, not just its top. Sizing against the faint ceiling line would overstate what a node can sustain; see the limits below. The horizontal axis is vCPU count on a logarithmic scale, so equal steps are equal doublings — which is what makes a flat stretch look flat.

    Scroll the chart sideways to see the full range, or read the figures in the table below it.

      The faint upper line per family (burst ceiling) has no markers or end labels of its own, so it stays legible as range context rather than a second thing to track.

      Show the plotted figures as a table

      Scroll the table sideways to see every family.

      The EBS-optimized curve across sizes

      The same floor-to-ceiling treatment as the network chart above, for EBS-optimized bandwidth: a solid, marked line at the guaranteed floor (the figure this page actually ranks against) and a faint, unmarked line above it at the published burst ceiling. Where AWS publishes a single flat figure for a size, the two lines coincide. The chart shows megabytes per second, converted from the megabits per second AWS publishes. The horizontal axis is vCPU count on a logarithmic scale, so equal steps are equal doublings.

      Scroll the chart sideways to see the full range, or read the figures in the table below it.

        Show the plotted figures as a table

        Scroll the table sideways to see every family.

        What this page cannot tell you

        • Every ranked ceiling here uses AWS's guaranteed bandwidth, not the "Up to" burst maximum. CNQ's write cache is provisioned against the guaranteed figure. On i4i.4xlarge, for example, a real deployment yields roughly 1,000 MB/s of write-cache throughput inclusive of mirroring, below either published ceiling alone. AWS documents network and EBS-optimized bandwidth as dedicated, separate allowances — its own docs never describe the two as sharing one physical NIC.
        • These are published AWS ceilings, not measured Cloud Native Qumulo results. Nothing on this page was benchmarked, by AWS, by Qumulo, or by us. A ceiling tells you what you cannot exceed. It does not tell you what you will get. Beyond that gap, client protocol write operations don't map one-to-one with the transactions that reach Qumulo's write cache — the filesystem scheduler can combine multiple queued writes into a single internal transaction, improving efficiency under sustained write load. Write-cache mirroring is not a fixed pairing between two nodes — Qumulo mirrors write-cache data across the cluster so majority quorum holds and the data survives, a durability/quorum mechanism rather than a data-placement one. That means a write can generate backend network traffic to more than one node, beyond what a single node's published ceilings describe.
        • Every figure on this page — every card, chart and table — is per node, not cluster-aggregate. A Cloud Native Qumulo cluster is always more than one node, so cluster capacity is not simply this page's per-node ceiling multiplied by node count. Network comes closest to a clean multiplication — AWS gives it independently to inbound and outbound traffic rather than pooling it with EBS — but write-cache mirroring rides the cluster for majority quorum rather than a fixed pairing between two nodes, already covered above, so a single write can still generate backend network traffic to more than one node's allowance. Size a node with this page; size a cluster with Qumulo.
        • A single-threaded or single-connection client will not see cluster-aggregate throughput. Cloud Native Qumulo is a distributed file system: reaching the aggregate performance a multi-node cluster is capable of requires concurrent operations — multiple threads, multiple connections, or multiple clients — spread across the cluster. A single client issuing serial, single-threaded I/O is bound by what one node (and one connection) can do, not by the cluster's combined ceilings. Size for the concurrency your workload actually generates, not just its total bytes or operations.
        • No public source maps Cloud Native Qumulo operations per second to core count. Cores do protocol handling, metadata work and data-protection math. How far that dial turns for your workload is something you have to measure, not read off a page.
        • Local instance-store NVMe is the read cache. The write cache is always EBS — never ephemeral NVMe. The write cache is always provisioned as small, fixed-size gp3 EBS volumes, even on an i4i instance with terabytes of local NVMe sitting right there — that NVMe capacity serves reads instead. The Local NVMe card below is shown for reference only and is never ranked against the network or EBS ceilings.
        • AWS meters network bandwidth per direction, independently and simultaneously. An instance's published figure applies in full to inbound and outbound traffic at the same time. But multi-flow traffic through an internet gateway is capped at 50% of that figure (or 5 Gbps flat, for instances under 32 vCPU), and any single TCP flow is capped at 5 Gbps regardless of instance size, unless it's inside a cluster placement group (up to 10 Gbps) or using ENA Express between instances in the same Availability Zone (up to 25 Gbps, but never more than the instance's own published network allowance — a 12.5 Gbps-baseline instance still tops out at 12.5 Gbps for a single flow even with ENA Express enabled) — the two are not equivalent. This page assumes S3 traffic reached through the VPC S3 gateway endpoint that Qumulo's deployment requires does not take the internet-gateway-limited path — gateway endpoints exist specifically to keep that traffic off it — but no single AWS or Qumulo source states that outcome for CNQ by name. Independent directions doesn't mean uncontended, though: Cloud Native Qumulo mirrors writes across the cluster so majority quorum holds, over this same NIC, concurrently with client and S3 traffic — the ceiling above is shared across all of it, not reserved per traffic type.
        • Sizes at 4xlarge and smaller, in most of these families, publish "Up to" bandwidth backed by a burst-credit system, not a flat guarantee. AWS gives separate credit buckets for inbound and outbound traffic. AWS's own documentation states these instances "can support maximum performance for 30 minutes at least once every 24 hours," after which they revert to their published baseline figure. As of September 2025 AWS removed burst-duration limits on i7i sizes larger than 4xlarge (the same announcement also covered i8g, not supported by Qumulo and so not on this page) — with no duration cap, the published maximum on those sizes is sustainable indefinitely, so this page ranks them as dedicated rather than burstable. This page ranks the guaranteed/baseline figure for every size either way — burstable or dedicated — never the "Up to" maximum, which is shown for reference only; for these particular i7i sizes, that guaranteed figure and the sustainable maximum are now the same number.
        • AWS does not publish local-NVMe throughput in MB/s for any family here. Four of the seven families (i3en, i4i, i7i, i7ie) publish random-read and random-write IOPS at a 4 KB block size, queue-depth-saturated — a different workload shape from the sequential MB/s figures behind the network and EBS ceilings, so this page never converts one into the other or ranks them together. The other three families (m6idn, m6i, m7i) publish no local-NVMe performance figure at all — m6i and m7i have no local NVMe to begin with.
        • Where AWS's own published pages disagree with each other, this page uses the smaller, verifiable figure. AWS's instance-types pages and its detailed specifications pages don't always match each other exactly. Wherever AWS's own numbers do genuinely conflict, this page ranks against the smaller, verifiable figure rather than the larger, harder-to-verify one — the conservative reading, per this page's own floor-don't-round-up rule.
        • Reaching the published EBS figure requires enough attached volumes to sum to it — and even then, mirroring and protocol overhead eat into it. AWS's own worked example is for r6i.16xlarge, not a generic instance, and uses gp2 volumes, not gp3: it needs at least five gp2 volumes provisioned at 16,000 IOPS each to reach 80,000 IOPS — or, since September 2025, a single gp3 volume alone, now that gp3's own per-volume ceiling rose to 80,000 IOPS. Qumulo confirms one concrete data point on i4i.4xlarge: roughly 1,000 MB/s of write-cache throughput for the write workload, inclusive of mirroring traffic to other nodes and protocol overhead. That's a single confirmed example, not a general formula; nothing public says how CNQ sizes EBS volume count and provisioning across every instance type and deployment.
        • Every price here is EC2 compute only. It is the lease on the machine. Persistent S3 storage, EBS volume costs and egress are billed separately and are not in these figures.
        • Prices move, and these are list rates. Every price here is US East (N. Virginia), Linux, On-Demand, pulled from AWS's official EC2 pricing feed on 19-Oct-2026. Monthly figures are hourly multiplied by 730 — our arithmetic, not an AWS-published figure. Reserved Instances, Savings Plans and negotiated agreements land materially lower.