The Azure Well-Architected Performance Efficiency Pillar: Designing for Load You Don't Have Yet
The Azure Well-Architected performance efficiency pillar finds no autoscale, no baseline, and premium tiers used where standard suffices. For cloud architects designing for real demand.
Marc Dekeyser |
The Azure Well-Architected Performance Efficiency Pillar: Designing for Load You Don’t Have Yet
The Azure Well-Architected performance efficiency pillar measures whether a workload can meet demand as it changes — scaling up under load and back down when the load passes — without either falling over or paying for headroom it never uses. The finding that appears in nearly every assessment is the same contradiction: capacity is fixed, autoscale is not configured, and there is no performance baseline to scale against.
Performance efficiency is the mirror image of cost optimization. Cost optimization finds the over-provisioning. Performance efficiency finds the under-provisioning and the static provisioning — workloads pinned to a fixed size because someone guessed once and the guess was never connected to measured demand. Both pillars surface the same root cause from opposite directions: capacity decisions made without data.
Key takeaways
- The most common performance finding is no autoscale configured. Workloads run at a fixed instance count, sized for an average that is wrong for both the peak and the trough.
- No performance baseline exists in most environments. Without one, you cannot tell whether the system is fast enough, and you cannot detect when it degrades.
- Premium service tiers are frequently used where Standard would meet the actual throughput — the inverse waste, paying for performance headroom the workload never touches.
- Data and caching strategy is the most overlooked lever. The application scales; the database it depends on does not, and no cache sits between them.
- Performance efficiency and cost optimization are the same conversation. Right-sizing to actual demand resolves both.
What do the performance efficiency design principles require?
The Azure Well-Architected performance efficiency pillar requires that capacity tracks demand through measurement and elasticity, not through a fixed allocation chosen at design time. The Microsoft Azure Well-Architected Framework frames performance as something you negotiate against data continuously, which is precisely what most environments do not do.
The principles: negotiate realistic performance targets so you know what “fast enough” means. Meet capacity requirements through elasticity rather than static over-provisioning. Achieve and sustain performance by baselining, testing, and monitoring against the targets. Make informed trade-offs — the right service tier, the right scaling model, the right place to spend.
The gap between these principles and the running environment produces the findings. A workload deployed at a fixed three instances because that felt safe. No load test ever run to know what three instances can serve. No baseline captured, so no way to know whether response times have degraded since launch. The capacity is a guess that calcified into a fact.
Why is no autoscale configured the most common finding?
No autoscale is the most common finding because static capacity is the default and configuring autoscale requires defining the rules nobody got around to writing. A workload deployed at a fixed instance count works fine the day it ships. It only reveals its inadequacy under a load spike or during a quiet period — and by then nobody is watching the capacity.
Azure gives you the scaling mechanisms; the assessment finds them unused.
App Service without autoscale. An App Service plan on the Standard or Premium tier supports autoscale rules — scale out when CPU or memory crosses a threshold, scale in when it falls. The common finding is a fixed instance count with no rules defined. The plan is sized for a peak, so it over-pays at the trough, or sized for the average, so it degrades at the peak. Either way the elasticity Azure offers is switched off.
Virtual Machine Scale Sets at fixed capacity. A VM Scale Set exists specifically to scale instance count automatically. The assessment finds scale sets pinned to a static instance count with autoscale profiles undefined — using the construct for management convenience while ignoring the capability that justifies it.
AKS without cluster autoscaler or HPA. An Azure Kubernetes Service cluster has two scaling layers: the Horizontal Pod Autoscaler scales pods against CPU or custom metrics, and the cluster autoscaler scales the node count. The finding is frequently that neither is configured — a fixed node pool running a fixed pod count, sized by hand.
The remediation is rarely complex. It is defining the scale rules and the bounds. What is missing is not capability — it is the configuration, and the baseline that would tell you where to set the thresholds.
What does it mean to have no performance baseline?
Having no performance baseline means you have no recorded answer to “how fast is this system when it is healthy?” — so you cannot prove it is meeting its target, and you cannot detect when it starts to drift away from it. This is the quiet finding, because nothing visibly breaks. The system is simply un-measured.
A performance baseline is a captured record of the workload’s behaviour under known load: response time at the median and the tail percentiles, throughput, resource utilisation at each tier. It is the reference against which everything else is judged. Without it, “the application feels slow” is unfalsifiable, autoscale thresholds are set by guesswork, and capacity planning is superstition.
The assessment looks for evidence that load testing has happened — Azure Load Testing runs, results captured, targets defined — and for Application Insights configured to track the performance signals continuously. The common finding is neither. The application is instrumented at defaults, which is the same observability gap the operational excellence pillar surfaces, viewed through the performance lens. You cannot tune what you have not measured, and you cannot prove a regulator-relevant performance commitment you never baselined.
Where do premium tiers get used where standard suffices?
Premium tiers get used where Standard suffices because Premium feels like the responsible choice and nobody measured whether the workload needed it. This is the performance pillar surfacing cost waste — the same finding as the cost optimization pillar, reached from the question “does this workload actually use the tier it is paying for?”
The pattern recurs across services:
| Service | Premium chosen | What the workload actually needs |
|---|---|---|
| Azure SQL Database | Business Critical tier | General Purpose, where the IOPS and latency suffice |
| Azure Cache for Redis | Premium tier | Standard, where the throughput and size fit |
| App Service | Premium v3 plan | Standard, where the autoscale ceiling is never reached |
| Storage | Premium SSD on a low-IOPS workload | Standard SSD, matched to actual throughput |
| Application Gateway | WAF_v2 at high capacity units | Right-sized capacity against real request volume |
The point is not that Premium is wrong. Premium tiers exist for workloads that need their guarantees — the latency floor of Business Critical, the clustering and persistence of Premium Redis. The finding is the tier chosen without measuring whether the workload reaches for what it provides. Choosing a tier is a trade-off the performance pillar asks you to make on evidence. Most are made on instinct, and instinct rounds up.
How does data and caching strategy affect performance efficiency?
Data and caching strategy affects performance efficiency more than compute scaling does, because the compute tier usually scales and the data tier usually does not — so the database becomes the ceiling the moment the application scales into it. This is the most overlooked lever in the pillar, and the one with the largest impact when it is missing.
The failure mode is structural. The application tier autoscales beautifully. Under load it spins up more instances, all of which hammer the same Azure SQL Database, which cannot scale horizontally the way the stateless application tier can. Throughput collapses at the data tier while the compute tier sits comfortably. More application instances make it worse, not better.
The levers the assessment looks for:
No caching layer. Azure Cache for Redis in front of the database absorbs read load that would otherwise hit the data tier on every request. The common finding is no cache at all — every read goes to the database, including reads for data that changes hourly. A cache is frequently the single highest-impact performance change available, and it is absent.
No read replicas. Azure SQL Database read scale-out and read replicas offload read-heavy queries from the primary. Workloads that are 90% reads frequently route everything to the primary because the replica was never configured.
No content delivery for static assets. Static content served from the application or storage directly, with no Azure Front Door or CDN in front, putting load on origins that should never see it.
Scaling compute against an un-cached, un-replicated database is scaling the wrong tier — and no autoscale rule fixes a structural bottleneck.
What evidence does a performance-efficient configuration produce?
A performance-efficient configuration produces evidence as defined performance targets, captured baselines, autoscale rules with sensible bounds, service tiers matched to measured demand, and a data tier with caching and read scale-out where the load justifies it. This evidence is what turns “it performs well” from an assertion into a demonstrated, repeatable property.
The evidence is also operational maturity. A baseline implies load testing was run. Autoscale rules imply the demand pattern was understood. Tier choices backed by utilisation data imply the trade-offs were made deliberately. A performance-efficient environment is, almost by definition, a measured one — and the measurement is the evidence.
Platform Architecture Authority reads the running estate through Azure Resource Graph and correlates provisioned tiers and scaling configuration against Azure Monitor utilisation, surfacing the static-capacity workloads, the over-tiered services, and the un-cached data dependencies. It generates the remediation — the autoscale profiles, the tier changes, the caching topology — as infrastructure-as-code you review and apply. It is read-only. A cloud architect still decides which workloads genuinely warrant Premium guarantees and where elasticity matters more than a fixed floor; the platform makes the current configuration visible so the design decision is made against measured demand rather than the instinct to round up.
FAQ
What is the difference between scaling up and scaling out? Scaling up (vertical) means a bigger instance — more vCPUs or memory on the same resource. Scaling out (horizontal) means more instances sharing the load. The performance efficiency pillar favours scaling out with autoscale for stateless tiers, because it adds elasticity and removes single points of failure, where scaling up has a hard ceiling.
Why does the data tier limit performance more than compute? The application tier is usually stateless and scales horizontally — add instances, add capacity. A relational database holds state and cannot be scaled horizontally the same way, so it becomes the bottleneck when the application scales into it. Caching and read replicas relieve the data tier; adding more application instances does not.
How is performance efficiency different from cost optimization? They are two views of the same question: does capacity match demand? Cost optimization finds capacity exceeding demand (over-provisioning). Performance efficiency finds capacity failing to track demand (no autoscale, no baseline) and, in the tier findings, the same over-provisioning. Right-sizing to measured demand satisfies both pillars at once.
Designing for load you do not have yet is not over-engineering. It is configuring the elasticity and capturing the baseline now, so that when the load arrives the system scales to meet it instead of teaching you what you should have measured.
