Selecting a cloud configuration involves two separate challenges.

The first is finding the best option in a very large field of candidates. The second is deciding whether each candidate can actually handle the workload.

The first challenge gets most of the attention. Cloud providers offer hundreds of instance types, along with different disk types, storage sizes, network tiers, processors, and accelerators. Finding the right combination clearly requires more than comparing a few instance sizes.

But the second challenge is harder—and easier to overlook.

Before an optimizer can recommend a configuration, it needs a way to decide whether that configuration will deliver acceptable performance. That decision is the feasibility test. If the test is wrong, searching more configurations does not improve the result. It simply produces the wrong answer with greater confidence.

Search Depends on the Feasibility Test

In Cost Optimization Is Easy — Until Performance Matters, we described configuration selection as a search across a multidimensional space.

A candidate might include an instance family and size, several attached volumes, a storage type, a network tier, and perhaps one or more GPUs. Each combination represents a different point in the search space.

Every candidate must answer the same question:

Will this configuration deliver the performance the workload requires?

A common approach is to compare observed resource demand with published limits. If CPU demand is below the available CPU, memory fits, and storage demand is below the provisioned IOPS, the configuration passes.

That sounds reasonable. In practice, it misses several things that matter.

Instance and Storage Limits Are Coupled

Compute and storage are often sized separately.

The instance is selected based on CPU and memory. The volumes are selected based on capacity, throughput, and IOPS. Both decisions may look correct on their own, yet the combined configuration can still fail.

That is because an instance places aggregate limits on the performance of its attached volumes. A volume may be capable of delivering more IOPS or throughput than the instance can drive.

Example: AWS m5.large with an io2 volume

Consider an AWS m5.large with an io2 volume provisioned for 10,000 IOPS.

• 10,000 IOPS provisioned and billed on the volume

• 3,600 instance aggregate EBS baseline (16 KiB I/O)

• ~64% of provisioned IOPS inaccessible under sustained demand

The volume is provisioned—and billed—to deliver 10,000 IOPS. But for 16 KiB operations, the instance has an aggregate EBS baseline of 3,600 IOPS and a maximum of 18,750 IOPS. AWS documents maximum performance for 30 minutes at least once every 24 hours, after which the instance returns to its baseline.

For sustained demand, that means roughly 64% of the volume’s provisioned IOPS may be inaccessible through the instance.

The volume itself is not unhealthy. Ordinary dashboards may not show an obvious infrastructure fault. The bottleneck becomes clear only when the instance’s EBS limits and exceeded-limit metrics are examined alongside the volume metrics.

The same problem can appear after a seemingly safe rightsizing decision. An instance may be downsized because its CPU utilization is low, but the smaller instance may also have a lower EBS ceiling. If storage demand was already close to that ceiling, application latency can rise even though the application and its volumes have not changed.

Configurations also drift over time. Volumes are expanded, instance families change, and workloads grow. Each individual change can make sense while quietly breaking a compute-and-storage pairing that previously worked.

A feasibility test that evaluates the instance and its volumes independently can therefore approve a configuration that does not work as a whole.

Fitting Is Not the Same as Performing

Suppose the instance and storage limits are modeled correctly.

Two candidates remain. One would run the workload at 78% of effective capacity. The other would run it at 92%. Both are technically below 100%, and the second option costs less.

A basic capacity test would approve both.

The problem is that performance does not decline in a straight line as utilization increases. Queueing delay rises sharply as a resource approaches saturation.

In a simple M/M/1 queueing model with a fixed service rate, expected time spent waiting in the queue scales with ρ/(1−ρ), where ρ is utilization:

Moving from 78% to 92% increases the queueing-delay factor by more than three times.

The model is intentionally simple. Production workloads do not have perfectly regular arrival patterns or service times. Traffic arrives in bursts, requests take different amounts of time, and several resources may become constrained at once.

But the underlying lesson holds: a resource can remain below its published capacity and still deliver unacceptable latency.

This is different from the shared-infrastructure contention discussed in How to Reduce Cloud Costs Without Reducing Performance. Contention can hurt performance even at moderate utilization. The effect here does not require contention at all. It comes from operating too close to the resource’s own saturation point.

A capacity test tells you whether demand fits. It does not tell you whether the workload will perform well at that level of utilization.

That requires a model of how latency, throughput, and queueing behavior change as load increases.

The Requirement Comes From Imperfect Data

Every feasibility test compares a candidate configuration against a workload requirement.

The difficulty is that the requirement is not directly given. It has to be estimated from historical telemetry—and that telemetry is rarely a perfect record of demand.

Choosing the right percentile

Sizing to average demand leaves too little capacity for peaks. Sizing to the largest observed sample can mean provisioning for a single unusual interval.

Every percentile between those extremes represents a different tradeoff. It determines how often historical demand would have exceeded the selected capacity.

That choice should reflect the workload’s performance requirements and tolerance for risk. In many environments, however, it is simply inherited from a dashboard query or a tool’s default setting.

The result looks precise, but the underlying business decision was never actually made.

Recovering censored demand

Historical utilization can also hide how much capacity the workload wanted.

For many constrained resources, completed work flattens at the service limit. Once the resource is saturated, the metric shows what the system delivered—not how much demand was waiting behind it.

A volume capped at its IOPS limit, for example, never shows more completed I/O than the limit allows, no matter how much I/O the application is requesting. The unmet demand shows up elsewhere: in queue depth, I/O wait, throttling indicators, or application latency.

If a sizing model looks only at completed consumption, it can conclude that the existing limit was sufficient. It may then recommend another configuration with the same constraint—or an even smaller one.

The workloads most likely to be underestimated are therefore the workloads that are already constrained.

Modeling bursts over time

Burstable resources create the opposite problem.

EBS bandwidth on some instance sizes, gp2 volume credits, and CPU credits on burstable instance families all behave like forms of stored capacity. A workload can exceed the baseline for a period and remain healthy as long as its bursts fit within the resource’s accrual and depletion behavior.

Peak demand alone does not tell you whether such a configuration is feasible.

A test that compares the peak directly with baseline capacity may reject a configuration that could comfortably support the workload. That false negative pushes the recommendation toward a larger and more expensive resource.

Burst feasibility depends on duration, frequency, credit balance, and recovery time—not simply on the highest observed value.

Requirement-estimation errors can therefore go in both directions. Underestimated demand approves configurations that will throttle. Overly conservative peak-based sizing rejects configurations that would have worked.

Why Feasibility Errors Persist

When a feasibility mistake reaches production, the symptom is usually visible.

Latency rises. Tail performance regresses. Queues grow. An incident is opened.

The original configuration decision is much harder to see.

Tracing a p99 regression back to an instance that cannot drive its provisioned storage requires several kinds of information to be brought together: workload telemetry, resource limits, configuration history, and the reasoning behind the recommendation.

That correlation is not often part of the optimization process.

Without it, the lesson from the incident becomes broad and defensive: resizing is risky, smaller configurations are dangerous, and more headroom is safer.

Given a feasibility test that cannot be explained or audited, that reaction is understandable. It is also one of the reasons over-provisioning persists. Teams compensate for uncertainty by buying margin, and cost tools later identify that margin as waste.

A better system needs a feedback loop. Recommendations should record what demand was estimated, which limits were evaluated, how much headroom remained, and why the configuration was expected to meet the performance requirement.

When performance changes after a move, the outcome can then be compared with the original model. That is how the feasibility test improves instead of simply becoming less trusted.

What a Reliable Feasibility Test Must Do

Configuration selection requires both a search procedure and a reliable way to evaluate every candidate found during that search.

The feasibility test must:

• Model the effective limits of the complete configuration, including interactions between instances and attached storage.

• Distinguish sustained capacity from burst capacity and evaluate demand over time.

• Estimate workload requirements at an explicit, intentional percentile.

• Recognize when observed consumption has been capped by an existing constraint.

• Evaluate expected performance at projected utilization, rather than asking only whether demand is below a published limit.

• Record the estimates and limits behind each recommendation, so that a later performance problem can be traced to the decision that caused it.

Searching the full configuration space is necessary. It is not sufficient. The quality of the answer is set by the quality of the test.