For a more simple overview see at the bottom of this blog, that also includes a calculator.

Microsoft is changing how infrastructure works in F&O apps. In unified environments, elastic compute replaces fixed environment tiers with a shared-capacity model that automatically scales based on actual usage. Instead of choosing a Tier 2, Tier 3, or similar size up front, sandbox and production environments draw from a common Power Platform capacity model.

In practical terms, this means customers no longer plan around fixed infrastructure sizes in the same way. The AOS tier remains the core compute layer, but the number of AOS instances can increase as demand grows. Microsoft describes this as a model where compute scales with real workload rather than with a preselected environment tier.

Microsoft’s published reference points are important. Each AOS instance aligns with 650,000 Power Platform Requests, or PPRs. Sandbox and production environments have a minimum of two AOS instances, and an environment can scale up to 80 AOS in total, split across up to 40 interactive and 40 batch instances. Unified Developer Environments are the exception and stay fixed at one AOS.

Why this is simpler

The big shift is that capacity is no longer something you buy as a named infrastructure tier. Instead, capacity comes from a tenant-wide PPR entitlement. Microsoft defines that entitlement as 500,000 base PPRs, plus 5,000 PPRs for each assigned user license, with optional 50,000-PPR add-on packs when more headroom is needed.

That makes the model easier to explain to customers. The old question was, “Which environment tier do we need?” The new question is closer to, “How much workload do we expect, and how much shared capacity do we want available?” That is a simpler model operationally, but it also means customers need to think more about usage patterns across the tenant.

Cost follows workload

PPRs are not presented by Microsoft as a direct per-request price list, but Microsoft does sell 50,000-PPR add-on packs. That gives customers a practical reference point for understanding what extra headroom may cost, even though the exact commercial price can vary by region and agreement.

The important change is conceptual. Under the old model, customers often paid for fixed capacity whether they used it fully or not. Under elastic compute, idle baseline capacity becomes less of a planning problem, while heavy activity becomes much more visible. High concurrency, API bursts, Dataverse-driven traffic, and large batch workloads are now the things that matter most.

There is also no rollover concept here. Power Platform request limits are measured over a rolling 24-hour period, so unused request headroom is not something customers can bank and carry forward into a later spike. That reinforces the idea that this is a live consumption model rather than a stored monthly allowance.

The most important thing to understand: 5,000 and 40,000 are not the same number

This is where many people get confused. Microsoft uses one model for elastic-compute capacity and another for licensed-user request limits. For elastic compute, the number is 5,000 PPR per assigned user license, added to the tenant-wide base of 500,000. That number helps determine how far environments can scale.

Separately, Microsoft documents licensed-user Power Platform request limits. For paid Dynamics 365 Enterprise users, the documented request limit is 40,000 requests per user per 24 hours in the request-limits model. That number is relevant for request-limit behavior and throttling, but it should not be added into the elastic-compute AOS calculation. These are two different mechanisms answering two different questions.

A useful way to explain it is this. The 5,000 figure helps answer, “How much elastic-compute capacity does this license contribute to the tenant?” The 40,000 figure helps answer, “How many Power Platform requests can this licensed user make in a 24-hour period before request limits become relevant?” They are related, but they are not interchangeable.

Example: 100 Supply Chain Management users

Take a customer with 100 assigned Supply Chain Management users. For elastic compute, Microsoft’s formula gives 500,000 base PPR plus 100 × 5,000 PPR, which equals 1,000,000 PPR. Microsoft’s own example table maps that to 2 AOS of capacity.

So the way customers should think about this is not, “100 users means 4,000,000 PPR for scaling.” That would be mixing the user request-limit model with the environment capacity model. For elastic compute, the relevant number is the 1,000,000-PPR tenant entitlement, not the 40,000-per-user request-limit figure.

It is also important to remember that attach licenses do not create extra platform entitlements. Microsoft’s licensing guide states that attach licenses do not include additional platform entitlements and instead use the entitlements of the assigned base license. So customers should not assume that a base license plus an attach license doubles their elastic-compute accrual.

Multiple environments still matter

Even though sandbox and production now use the same elastic-compute model, customers still need to think at tenant level. Test, UAT, Golden, and other environments are no longer planned as isolated fixed tiers. They sit within the same overall capacity model, and operational demand across them can still matter when testing, refreshes, migrations, integrations, and batch processing happen in parallel.

This becomes especially relevant during implementation. At that stage, customers often have several active environments before the final production licensing position is fully established. If those environments need to scale during migration, test cycles, or parallel workload periods, extra 50,000-PPR add-on packs may need to be purchased temporarily until the final licensing model is in place.

What gets cheaper, and what gets harder

The part that likely becomes cheaper is unused infrastructure. Customers no longer have to overbuy fixed tiers just to be safe. Baseline environments and idle capacity become less wasteful, and sandbox-versus-production planning becomes simpler because both follow the same capacity model.

The part that can become more expensive is sustained activity. Heavy integrations, API traffic, Dataverse calls, and large batch workloads now translate more directly into visible capacity demand. The model is more efficient, but it also makes cost more sensitive to actual usage.

That also makes budgeting a bit harder. Under fixed tiers, infrastructure cost was easier to predict even if it was inefficient. Under elastic compute, customers may need to adjust PPR capacity over time, especially in projects with fluctuating demand or several active environments. The model is cleaner technically, but less static financially.

So if you don’t have more PPR capacity available and want to add a second sandbox environment, expect to buy 40 PPR add-on packs at approx 50 USD each = approx 2.000 USD/month.

And if you need additional DB capacity remember to pick up some Dataverse Database Capacity add-on at 40 USD/GB/Month.

A few important limits to keep in mind

Not all compute is fully covered by this model today. Components such as Commerce Scale Unit and eCommerce-related workloads are not clearly described as part of the same elastic-compute model in the public documentation, so customers should be careful not to assume full alignment there yet. This is still a moving area.

It is also worth noting that unified environments are managed through the Power Platform Admin Center, not through Lifecycle Services. Microsoft’s current documentation explicitly positions finance and operations unified environments as PPAC-managed with zero LCS footprint.

Final thoughts

Elastic compute is a meaningful shift for F&O. It replaces fixed tiers with a shared, PPR-driven capacity model, gives sandbox and production the same compute framework, and allows customers to add capacity without going through the old infrastructure process.

The simplest customer takeaway is this: stop thinking in tiers, start thinking in workload. If the workload is light, the model is simpler and often more efficient. If the workload is heavy or unpredictable, the model is still flexible, but it requires closer attention to capacity, integrations, and budgeting.

PS: AI helped with parts of this post, but I’m the author.

References :
Licencing information : https://www.microsoft.com/en-us/licensing/product-licensing/dynamics365
Microsoft documentation on elastic compute with F&O: https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/elastic-compute

And I got this from a friend (if he want’s to share his name, he can comment 🙂 ):