Azure Environment Design: Stop Paying Production Prices for Dev

"We want our Development, Test, QA, Pre-Production, and Production environments to be identical."

I hear a version of this every time I sit down with a customer on environment design. On the surface it sounds sensible, after all, we've all heard the phrase "if it works in Dev, it should work in Prod." But that phrase gets misread constantly. It doesn't mean every environment needs the same Azure SKU. It means the same architecture, deployed consistently.

Microsoft's Cloud Adoption Framework (CAF) and Well-Architected Framework (WAF) actually back this up directly. CAF recommends separating production and non-production environments and explicitly points customers toward Azure Dev/Test pricing to bring non-production costs down.

Architectural consistency and cost consistency are not the same thing

This is the mistake I see most often: teams assume "production-like" means "production-priced." It doesn't.

Architectural consistency means:

• The same deployment model
• The same infrastructure-as-code templates
• The same networking patterns
• The same application architecture
• The same operational processes

Cost consistency means deploying the exact same SKU in every environment, regardless of whether it's actually needed. That second one is where I've watched budgets quietly get destroyed.

Microsoft's own cloud-native guidance says non-production environments should closely mirror production configuration, but in the same breath it recommends cost controls and appropriate service tiers for development workloads. "Appropriate" is doing a lot of work in that sentence, and it's the word most teams skip past.

Let's talk about API Management

Azure API Management is the clearest example I keep coming back to. Most organisations run Premium in Production because they genuinely need it:

• Higher scale requirements
• Enterprise networking (VNet injection, private endpoints)
• Premium resiliency capabilities
• Production-grade SLAs

All valid reasons. But ask the follow-up question: does your Development environment need any of that? If your developers are building APIs, testing integrations, validating deployments, and running CI/CD pipelines, the answer is almost always no, and the Developer SKU is entirely sufficient.

Here's the number that usually gets the room's attention: APIM Premium in UK South runs around $2,800 USD a month, per unit. The Developer SKU is around $48. Same architecture, same deployment process, same APIs,  a ~98% cost difference for capability your Dev environment was never using.

One caveat worth being upfront about: Developer tier carries no SLA, and Microsoft is explicit that it isn't suitable for production use. That's not a hidden catch, it's the trade-off you're accepting in exchange for the cost saving, and it's exactly why this is a Dev/Test decision, not a Production one.

I've walked into estates where five non-production environments were all quietly running Premium APIM, because nobody had revisited a decision made three years earlier. That's north of $150k a year spent on enterprise networking and SLA guarantees that not one of those environments used.

When non-production genuinely should match production

There are real exceptions, and they're driven by what you're testing, not by habit:

• Performance testing — validating throughput, latency, or scalability needs production-sized infrastructure.
• Resilience testing — failover and high-availability testing needs an environment that closely resembles Production.
• Pre-Production validation — before major releases, a staging environment that mirrors Production closely is a legitimate safety net.

If the requirement is driven by a testing objective, production-equivalent SKUs make sense. If it's driven by "that's just what we've always deployed," it's worth a second look.

A practical pattern

This lines up with both CAF's Dev/Test guidance and the WAF cost optimisation pillar, it isn't a shortcut, it's the framework working as intended.

The question every architect should ask

Stop asking "how do we make every environment identical?" Start asking "how do we make sure every environment fulfils its purpose at the right cost?"

That's a completely different conversation, and usually a much shorter one, because the answer tends to be obvious once you ask it properly.

Cloud gives you the ability to right-size for what each environment actually needs to do, instead of defaulting to one-size-fits-all. So next time you're reviewing an Azure estate and see Premium SKUs deployed everywhere, pause and ask why. You might find that architectural consistency, held alongside the right service tier per environment, gets you the exact same engineering outcome, for a fraction of the bill.

If you're reviewing your own estate this week, start with one question: which non-prod environment is running a Premium SKU it's never actually used?