App Service Plans
How App Service plan recommendations are sized, which plans are covered, what the plan toggles do and how to read the plan card. Recommendations apply to plans, not to individual apps. Select a plan on the Recommendations Page to open its card.
8 Sections
What's Analyzed
Dedicated App Service plans on Basic, Standard, Premium v2, Premium v3 (including memory-optimized mv3) and Premium v4 (including mv4), Windows or Linux, that host at least one app. Sizing uses the plan-level CpuPercentage and MemoryPercentage metrics, averaged across all instances, plus hourly CPU.
Not analyzed:
- Free and Shared plans (they have no plan metrics), Consumption and Flex Consumption, Elastic Premium, Workflow Standard and Premium v1.
- Isolated v2 and App Service Environment plans, because a plan can't leave its environment.
- Windows container plans and Spot plans.
- Plans with no apps, which are in Orphaned Resources.
Fit Rules
CPU is sized on an effective P95: the higher of the daily-average P95 and the hourly P95 (hourly needs at least 24 hours of data). Memory uses the higher of the daily-average P95 and the P95 of daily maximums. Both must fit within the aggressiveness ceiling:
- CPU scales with instance count. The plan's total CPU demand (effective P95 × vCPU × instances) must fit the target's total vCPU across its instances.
- Memory is per instance. Per-instance memory use must fit the target's per-instance memory.
Memory doesn't shrink with fewer instances
Every app runs on every instance. A plan can scale in on CPU but still need the same instance size for memory.
CPU fit compares vCPU counts, because Microsoft publishes no per-core performance figure for App Service. Moves to older hardware carry a warning for that reason. Monthly cost is the hourly list price × 730 hours × instance count, at the plan's OS price.
What Can Change
Size change (always on)
A different size in the same tier, for example P2v3 to P1v3. Takes seconds and needs no redeploy.
Scale-in (default on)
Fewer instances, never below 1. Never below 2 for zone-redundant plans, or below the highest per-app worker count when per-app scaling is on. Never offered when autoscale rules or automatic scaling manage the instance count. Recommendations never add instances.
Cheaper tier (default off)
Premium to Standard or Basic, Standard to Basic, or Premium v3 to Premium v2.
Newer generation (default off)
A higher tier that still costs less: Basic to Standard, Standard to Premium v2, Premium v2 to Premium v3 or v4, or Premium v3 to Premium v4.
Plan changes can restart apps
Changing a plan's size or instance count can restart the apps on it.
Newer tiers may need a new plan
A newer-generation tier may not be available in the plan's deployment unit. If the tier isn't offered in the portal, the move needs a new plan and a redeploy.
Feature Checks
A target is never recommended if it can't keep what the plan uses today: the deployment slot count the apps use, autoscale rules, per-app scaling, zone redundancy, automatic scaling, IP SSL, and the plan's instance count within the tier maximum.
Targets that pass can still carry warnings on the card:
- Single instance: running on one instance removes instance redundancy, so a platform restart or instance failure takes the apps offline until it recovers.
- Older hardware: Basic, Standard and Premium v2 run on older hardware than Premium v3 and v4, so per-core performance may be lower.
- Lower limits on a cheaper tier: plan storage, hybrid connections and custom scheduled backups.
- Newer generation availability: the tier may not be available in the plan's deployment unit.
- Autoscale or automatic scaling: the platform manages the instance count, so a smaller SKU can lead it to add instances, reducing the savings. Shown on every recommendation for such plans.
App Service Toggles
These three toggles live in the App Service Plans section of Toggle Options. A same-tier size change is always considered and has no toggle.
- Allow scale-in (fewer instances)
- Default on. Includes targets that run the plan on fewer instances, within the scale-in floors above.
- Allow cheaper tiers
- Default off. Includes moves to a cheaper tier, checked against the features the plan uses.
- Allow newer generations
- Default off. Includes moves to a newer, higher tier that still costs less.
Reading the Plan Card
The card title follows what the pick changes: Plan Size Down, Plan Scale-In, Plan Resize and Scale-In, Cheaper Tier or Newer Generation Recommendation. Alongside the badges, rationale and estimated savings described in How Sizing Works, it shows:
- Slot badge
- The toggle combination behind the pick: Size Change, Scale-In, Tier Change, Newer Generation, a combination such as Scale-In + Tier Change, or All Levers.
- Current and Recommended
- The plan as SKU × instances (for example P1v3 × 2), tier, OS, per-instance vCPU and memory (GiB), and monthly cost for all instances.
- Utilization Evidence
- CPU and memory statistics, including the effective P95 and the projected utilization on the target.
- Apps on this plan
- Name, kind and deployment slots for each app. Up to 50 apps are listed.
- Confidence Analysis
- The three shared factors.
The panel header has View Performance, which opens the plan's CPU and memory charts, and View in Explorer.
Commitment Coverage
StratoLens reads the last 7 days of the plan's own cost data to see whether its usage was covered by a reservation or a savings plan; a reservation takes precedence. Covered plans still get recommendations, and the card tells you what happens to the commitment:
- Reservation
- An amber warning: resizing or scaling in leaves reserved capacity unused, unless another plan with the same SKU in the region uses it.
- Savings plan
- An info note: the commitment moves to other eligible usage.
- Not covered
- Nothing is shown.
Reserved capacity can go unused
For a plan covered by a reservation, resizing or scaling in can leave reserved capacity unused. Check Commitment Coverage before acting.
Realized savings are recorded when the plan's SKU or instance count changes. On plans managed by autoscale or automatic scaling, instance-count changes are treated as platform scaling, not as savings.
Troubleshooting
My App Service plan isn't listed
Answer
Check that it's a covered plan: dedicated Basic, Standard or Premium v2, v3 or v4 with at least one app, outside an App Service Environment, and not a Windows container or Spot plan. Then check the Minimum Savings threshold and the App Service Plans minimum data window.
No scale-in options for my plan
Answer
The plan uses autoscale rules or automatic scaling, or it's already at its floor: 1 instance, 2 for zone-redundant plans, or the highest per-app worker count.
The recommendation keeps the tier even though a cheaper tier exists
Answer
Turn on Allow cheaper tiers. The cheaper tier is still rejected if it can't keep a feature the plan uses, such as slot count, zone redundancy, IP SSL or the instance limit.
Commitment coverage could not be checked
Answer
StratoLens has no cost data for this plan yet. Check that cost collection is running for the subscription.