CloudCostChefs: Oversized App Service Plan Detector (with Max Usage)

Hunt down undercooked App Service Plans by slicing into CPU and memory usage stats—PowerShell style, no cloud guesswork required.

Spread the FinOps flavor!

Overview

Meet your FinOps sous-chef: the Oversized App Service Plan Detector. This PowerShell recipe sniff tests CPU and memory usage over time to spot App Service Plans that are overcooked—letting you downsize with confidence and trim Azure costs without sacrificing performance.

More than just the bland “here’s your average” scoop, this script serves up both Avg and Max usage—think of it as tasting the simmer and the sizzle. With that dual-metric flavor, you get the full recipe for right-sizing your App Service Plans without underseasoning for peak loads.

Download the Script

Ready to trim the fat? Grab the Oversized App Service Plan Detector script and start cooking up right-sizing wins today!

Download Script

Key Features

Dual Metric Analysis

Serves up both the smooth “steady simmer” averages and the “sizzle” of peak usage so you get the full flavor profile of your resource consumption.

Customizable Time Window

Let this tool simmer over 1–30 days of metrics so you capture every seasonal spike and slow simmer in your workload recipe.

Adjustable Thresholds

Dial in your own spice levels—set CPU and memory thresholds to match your org’s appetite for risk and performance zest.

Visual HTML Reports

Plates up a fully dressed HTML report with CloudCostChefs flair, so sharing and analysis is as tasty as it is effortless.

Cost Optimization Potential

App Service Plans can be one of the heftiest dishes on your Azure bill. Trimming just a couple of overcooked plans can save you a delicious chunk of monthly spend—no sacrifice to application flavor.

How It Works

The Oversized App Service Plan Detector is like a taste-test for your App Service Plans’ resource use over time—here’s the recipe it follows:

  1. Discovery: Identifies all App Service Plans in the specified Azure subscription
  2. Data Collection: Queries the Azure Monitor API to retrieve hourly CPU and memory metrics for each plan over the specified time period
  3. Analysis: Calculates both average and maximum utilization for each plan
  4. Identification: Flags plans as "underutilized" when both average CPU and memory usage fall below your specified thresholds
  5. Reporting: Generates both console output and an HTML report with the findings

Understanding the Metrics

The script collects and analyzes two key types of metrics:

  • Average Metrics: The arithmetic mean of all hourly-average data points over the analysis period. This represents typical utilization.
  • Maximum Metrics: The highest hourly average observed during the analysis period. This represents sustained peak usage, not momentary spikes.

Note: Because the script uses hourly averages, brief spikes (e.g., a one-minute spike to 70%) won't show up as "Max" unless they push that entire hour's average above other hours. This approach ensures the "Max" value represents sustained usage patterns rather than transient blips.

Hourly Granularity

The script uses hourly granularity for metrics to balance detail with API quota limitations. This provides sufficient resolution for most workload patterns while ensuring the script can analyze multiple App Service Plans without hitting API limits.

Prerequisites

Before you fire up the Oversized App Service Plan Detector, make sure your kitchen is stocked with these essentials:

  • PowerShell 5.1 or higher - The script is compatible with both Windows PowerShell and PowerShell Core
  • Az PowerShell Modules - Specifically, you'll need:
    • Az.Accounts - For Azure authentication
    • Az.Monitor - For accessing metrics data
  • Azure Subscription - Active subscription with App Service Plans to analyze
  • Appropriate Permissions - Reader access to the subscription and access to Azure Monitor metrics

Installing Required Modules

If you don't have the required Az modules installed, you can install them with:

Install-Module -Name Az.Accounts -Scope CurrentUser -Repository PSGallery -Force
Install-Module -Name Az.Monitor -Scope CurrentUser -Repository PSGallery -Force
Permission Requirements

The script requires the following Azure RBAC roles:

  • Reader - To list App Service Plans and their properties
  • Monitoring Reader - To access metrics data via the Azure Monitor API

Installation

Whipping up the Oversized App Service Plan Detector is a breeze:

  1. Download the script - Save the Find-OversizedAppServicePlans.ps1 file to your preferred location
  2. Verify execution policy - Ensure your PowerShell execution policy allows running the script
  3. Install required modules - Make sure the Az.Accounts and Az.Monitor modules are installed

Setting Execution Policy

If needed, you can set the execution policy to allow running the script:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Security Note

Always review scripts before running them, especially when changing execution policies. The Oversized App Service Plan Detector is designed to be read-only and doesn't modify any Azure resources.

Usage

Basic Usage

To get cooking, just run the script as-is (no extra spices). It will:

  • Use your current Azure context (subscription)
  • Analyze usage over the last 7 days
  • Flag plans with average CPU < 10% AND average memory < 10% as underutilized
  • Save the report as "AppServicePlan-UsageReport.html" in the current directory
  • Open the report in your default browser
.\Find-OversizedAppServicePlans.ps1

Advanced Usage

This script comes with a spice rack of parameters so you can fine-tune the flavor:

ParameterDescriptionDefaultExample
-SubscriptionIdTarget Azure Subscription IDCurrent context-SubscriptionId "abcdef12-3456-7890-abcd-ef1234567890"
-DaysNumber of days to analyze (1-30)7-Days 14
-CpuThresholdCPU% below which a plan is considered underutilized10-CpuThreshold 5
-MemThresholdPercentMemory% below which a plan is considered underutilized10-MemThresholdPercent 5
-OutputPathCustom file path for the HTML reportAppServicePlan-UsageReport.html-OutputPath "C:\Reports\AppServiceUsage.html"

Example Commands

Example 1: Analyze a specific subscription with default settings

.\Find-OversizedAppServicePlans.ps1 -SubscriptionId "abcdef12-3456-7890-abcd-ef1234567890"

Example 2: Analyze the last 14 days with tighter thresholds

.\Find-OversizedAppServicePlans.ps1 -Days 14 -CpuThreshold 5 -MemThresholdPercent 5

Example 3: Comprehensive custom analysis

.\Find-OversizedAppServicePlans.ps1 `
  -SubscriptionId "abcdef12-3456-7890-abcd-ef1234567890" `
  -Days 30 `
  -CpuThreshold 15 `
  -MemThresholdPercent 20 `
  -OutputPath "MonthlyAppServiceAnalysis.html"
First-Time Usage

When running the script for the first time, you'll be prompted to authenticate with Azure if you're not already logged in. The script will store your authentication token for subsequent runs within the same PowerShell session.

Understanding the Report

The Oversized App Service Plan Detector serves up two courses: a console table and a CloudCostChefs-styled HTML report.

Console Output

The console output is your quick taste-test, showing:

  • Analysis Parameters - Subscription, time window, and thresholds used
  • Tabular Results - A formatted table showing all App Service Plans with their metrics
  • Summary Statistics - Total plans scanned and number of underutilized plans
  • Underutilized Plans - A focused list of just the plans flagged as underutilized

HTML Report

The HTML report is your chef’s table—richly detailed, visually appealing, and perfect for sharing with the whole kitchen brigade:

Header Section

  • Report title with CloudCostChefs branding
  • Subscription name
  • Analysis period with dates
  • Threshold settings used

Summary Box

  • Subscription details
  • Time range analyzed
  • CPU and memory thresholds
  • Count of total and underutilized plans

Results Table

  • Resource Group and Plan Name
  • Location and SKU Tier
  • Average and Maximum CPU percentages
  • Average and Maximum Memory percentages
  • Underutilization flags

Footer

  • Generation timestamp
  • Data source information
  • CloudCostChefs branding
Understanding the Metrics

When tasting the report, savor both the steady simmer (average metrics) and the sizzling peaks (max metrics) to get the full flavor of your usage.:

  • Low average, low maximum: Strong candidates for downsizing
  • Low average, high maximum: Intermittent usage patterns; consider reserved instances or auto-scaling
  • High average, high maximum: Well-utilized plans; maintain current sizing

Customization Options

The Oversized App Service Plan Detector is great out of the box, but feel free to tweak the spices (parameters) to match your unique FinOps recipe.

Adjusting Analysis Thresholds

Dial up or down the CPU and memory thresholds to suit your team’s flavor profile—whether you like things mild (safe) or extra spicy (performance-hungry):

  • Conservative approach (default): CPU < 10%, Memory < 10%
  • Aggressive approach: CPU < 20%, Memory < 20%
  • Balanced approach: CPU < 15%, Memory < 15%

Example for a more aggressive analysis:

.\Find-OversizedAppServicePlans.ps1 -CpuThreshold 20 -MemThresholdPercent 20

Modifying the Analysis Period

Adjust the analysis period to account for different workload patterns:

  • Weekly patterns (default): -Days 7
  • Monthly patterns: -Days 30
  • Bi-weekly patterns: -Days 14

For applications with monthly processing cycles:

.\Find-OversizedAppServicePlans.ps1 -Days 30

Customizing the HTML Template

Feel free to tweak the HTML template—add extra ingredients or garnish—so the report looks just how your kitchen (team) likes it:

# Find the HTML template section (starts with $html = @")
                   # Modify the CSS styles or HTML structure as needed
                   # For example, to change the background color:

                   body {
                       font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
                       margin: 0; padding: 40px; background-color: #f0f0f0; /* Changed color */
                   }
Maintaining Script Functionality

When you tweak the recipe, don’t tamper with the core metric-gathering steps—stick to adjusting the thresholds, cooking time, HTML garnish, or plating style.

Automation

For regular monitoring of App Service Plan utilization, you can automate the Oversized App Service Plan Detector using various methods:

Windows Task Scheduler

Set up a scheduled task to run the script on a regular basis:

  1. Open Task Scheduler and create a new Basic Task
  2. Set it to run weekly or monthly
  3. Action: Start a program
  4. Program/script: powershell.exe
  5. Arguments: -ExecutionPolicy Bypass -File "C:\Path\To\Find-OversizedAppServicePlans.ps1" -OutputPath "C:\Reports\$(Get-Date -Format 'yyyy-MM-dd')-AppServiceUsage.html"

Azure Automation

For a cloud-native approach, use Azure Automation:

  1. Create an Azure Automation account
  2. Import the Az.Accounts and Az.Monitor modules
  3. Create a RunAs account or use Managed Identity
  4. Upload the script as a runbook (modify for automation context)
  5. Create a schedule to run weekly or monthly
  6. Configure output to save to Azure Storage or send via email
Email Integration

For automated runs, you can modify the script to email the results to your team:

# Add this at the end of the script
                   $emailParams = @{
                       From       = "reports@yourcompany.com"
                       To         = "team@yourcompany.com"
                       Subject    = "App Service Plan Usage Report - $(Get-Date -Format 'yyyy-MM-dd')"
                       Body       = "Please find attached the latest App Service Plan usage report."
                       SmtpServer = "smtp.yourcompany.com"
                       Attachment = $OutputPath
                   }
                   Send-MailMessage @emailParams

Troubleshooting

Hit a snag in the kitchen with the Detector? Here are common recipe missteps and how to fix them:

IssuePossible CauseSolution
No metrics data availableNew App Service Plan or metrics not enabledEnsure the plan has been active for the analysis period; check diagnostic settings
Authentication ErrorSession expired or insufficient permissionsRun Connect-AzAccount manually first, or check your RBAC permissions
API Request FailedNetwork issues or API throttlingCheck network connectivity, wait a few minutes and try again with a shorter time period
Script Execution Policy ErrorRestrictive PowerShell execution policyRun Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Missing Module ErrorRequired Az modules not installedInstall the Az.Accounts and Az.Monitor modules
Debugging Tips

For more detailed troubleshooting:

  • Run the script with the -Verbose parameter for additional output
  • Check the Azure Activity Log for any API-related issues
  • Try running with a smaller -Days value to reduce the amount of data being processed

Next Steps

Now that you’ve spotted the undercooked App Service Plans, here’s how to trim the fat and spice up your Azure cost savings:

Implement Right-Sizing

Downsize identified App Service Plans to more appropriate tiers based on actual usage patterns.

Learn about right-sizing strategies →

Set Up Regular Monitoring

Automate this script to run regularly and track utilization patterns over time.

Learn about continuous optimization →
Building a FinOps Practice

The Oversized App Service Plan Detector is just one recipe in your FinOps cookbook. For a full-course feast of cloud cost mastery, dive into our complete FinOps implementation guide.

Share This Guide

If this recipe hit the spot, pass it along to your cloud crew and the wider kitchen!

Was this documentation helpful?

Have suggestions for improving this document? Contact us.