Stopping of App Services for Cost Saving Effort

NLE JB 50 Reputation points
2025-04-25T01:51:41.2166667+00:00

Hello,

We have an App Service in Azure in develop environment and we want to stop it since theres no current development going on. Currently we have 1 backend web app and 2 function apps under this app service plan.

We just want to just stop it and not delete it since it saves us some time on setting up if there will be development in the future plus settings, data and configuration will be retained.

My question is, If I stop these 3 apps will it also stop incurring cost?

Below image is our current App Service Plan:

User's image

Thank you.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
8,767 questions
0 comments No comments
{count} votes

Accepted answer
  1. Bhargavi Naragani 3,820 Reputation points Microsoft External Staff Moderator
    2025-05-07T05:28:06.15+00:00

    Hi @NLE JB,

    The “Always On” feature is only available on Basic and higher tiers (e.g., Standard, Premium). Since you're currently on the Premium v2 P1V2 plan, the setting is available, but not directly visible from the “Scale out” menu. To locate or disable it:

    1. Go to your App Service in the Azure portal.
    2. Navigate to Configuration => General settings.
    3. Under Platform settings, you will see Always On => you can disable it from there. https://learn.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal#configure-general-settings

    Before downgrading to a tier like Basic (B1), make sure this feature is disabled, as it's not supported in Free or Shared tiers.

    The “Manual” scale-out method is selected because Azure Functions are hosted under the App Service Plan, and automatic scaling is not supported in this setup. Since you're not relying on autoscaling or high throughput right now, maintaining manual scale with 1 instance is perfectly fine. Microsoft Docs – Scale App Service Plan

    Thanks for checking the VNet tab. Since you see “No results” under Virtual Network Integration, this means your App Service is not connected to any VNet currently. That gives you additional flexibility in downgrading without worrying about breaking any private network dependencies.

    Coming to Storage Usage, your file system usage is very low (1.58 GiB out of 250 GiB), which is a great sign. The Basic B1 plan offers 10 GB of disk space, which should be more than sufficient based on current usage trends.

    Based on everything you've shared, including no VNet integration, low storage, and not Always On dependency (pending confirmation), downgrading to the Basic B1 plan seems like a sensible and cost-effective decision.

    However, before proceeding, please ensure Always On” is disabled in the Configuration tab. Once confirmed, you can downgrade the App Service Plan from the Scale Up (App Service Plan) menu in the Azure portal.

    If the answer is helpful, please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.

    Let me know if you have any further Queries.

    User's image


2 additional answers

Sort by: Most helpful
  1. Marcin Policht 46,360 Reputation points MVP Moderator
    2025-04-25T02:00:23.6533333+00:00

    When you stop your Web App and Function Apps in an App Service Plan, here's what happens:

    • Web App + Function Apps: Stopping them stops the execution of the code and prevents incoming traffic.
    • Settings, configuration, files, and state are retained — so yes, it saves time when you want to start them again.

    Unfortunately stopping the apps does NOT stop App Service Plan billing.

    That's because the App Service Plan is what you're actually paying for — not the apps themselves.

    • The plan is essentially the underlying compute resources (VMs) that host your apps.
    • Whether your apps are running or stopped, the plan is still allocated and ready to host them, so you're still billed for it.

    To reduce the cost, consider the following:

    1. Scale down the App Service plan
      • If you're on a higher tier (like Standard, Premium, etc.), you can scale it down to a lower tier (like Free or Basic) to reduce cost.
      • Just be careful — the Free tier has limitations (like no custom domains, limited storage, etc.).
    2. Switch to Consumption Plan (for Function Apps)
      • If your Function Apps aren't actively used, consider moving them to the Consumption Plan, which charges only when the function runs.
      • Downside: Cold start time and limited resources.
    3. Export configuration and delete the plan
      • If you're truly idle for a long time, consider exporting the app settings and configurations, then deleting the plan.
      • You can recreate it later using ARM templates, Bicep, or Azure CLI/scripts.

    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin


  2. NLE JB 50 Reputation points
    2025-05-07T06:22:22.7433333+00:00

    @Bhargavi Naragani Thank you for your response.

    -I checked and confirmed there are currently slots deployed but I plan to delete them before downgrading.

    -I am not an expert in cloud so could you please help me find these settings: Custom Domains and SSL bindings.

    -I forgot to inform you regarding our current plan metrics:

    User's image

    -Current plan is premium with 3.5 GB memory and the metrics shows a high usage of memory. Since Basic B1 only has 1.75 GB of memory it looks like I will hit some problems by downgrading what do you think?

    -Additionally, if I stop all the web app and function app will the memory and other metrics go down?

    I apologize for the following queries, I am not an expert in this field and I am tasked to do these things.

    Thank you.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.