When optimizing cloud costs for large enterprise environments, it’s common to focus on compute-intensive cloud resources, such as virtual machines, clusters, and container-based workloads, as they are usually the primary cost driver and top contributor to monthly cloud invoices. Luckily for us, there are already plenty of well-known approaches, straight guidelines, and easy-to-use tools from Microsoft and other third-party vendors that can save money on those workloads.
On the contrary, optimizing costs for PaaS services is an entirely different story, as there are a lot of service-specific nuances you should be aware of that can impact your resource costs. So, today, let’s explore how we can optimize our cloud spending on Azure App Service, which is one of the most used PaaS services in the Azure cloud.
App Service plans consolidation
The first service-specific cost nuance for Azure App Service is that App service resources don’t incur costs independently. In other words, you don’t pay for your App Service resources. You pay for App Service plans that host them. When an App Service represents your application, an App Service plan provides you with actual infrastructure resources to run them.
You can think of App Service plans as an abstraction for web server farms managed by Microsoft. With that abstraction, you don’t need to manage virtual machines, configure web servers, do the networking, scaling, patching, etc. You just need to pay for the compute and storage resources you consume. That is a very simplified explanation of App Service plans, and they are much more under the hood, but those details are not so important in the context of our topic
Understanding that concept is essential, as separating the application part from the infrastructure allows you to host many App Services on a single App Service plan. You can be surprised that many engineers don’t know about that. Plus, the Azure portal, by default, suggests you provision a new App Service plan each time when you create a new App Service, and that’s what most people do. The result is that you have an environment with a handful of underutilized App Service plans costing you lots of money, each hosting a single or very few apps.
In many cases, you can reduce your spending on App Service applications tenfold by consolidating them on a single App Service plan per environment or application group. Apart from that, you can discover that hosting a dozen apps on a single more ‘expensive’ App Service Premium tier is cheaper than having a dozen Basic or Standard service plan instances.
However, when consolidating multiple apps on a single App Service plan, you must understand that high load or errors in one application can impact the performance of other applications sharing the same App Service plan. So, it’s important to implement appropriate monitoring and autoscaling to mitigate the impact of such events.
Rightsizing and autoscaling
Rightsizing and autoscaling are probably the second most common topic for reducing your cloud spent on Azure App Services. As with Azure VM, overprovisioned resources for App Service plans are what you can see when you check their actual utilization. The usual argument is that we need some space capacity just in case there is a surge in requests. For some reason, many think resource scaling is only about adding CPU and memory to the existing resources. The horizontal scaling, when you load balance your traffic between multiple nodes and add or remove additional nodes when needed, is still overlooked. If you don’t use it, you simply don’t leverage the full flexibility of the cloud when you can pay only for what you consume.
Rightsizing and autoscaling work hand in hand. You can set up your scale-out rules for App Service and pay for additional resources only when you need them, which might significantly impact your App Service costs. Adding additional instances happens pretty fast, as Azure data centers usually have some pools of ready-to-use instances for that purpose. The only exclusion from that is the Isolated tier (aks App Service Environments), where scaling might take longer. So, if using them, please check if autoscaling speed is appropriate for your needs. If their scaling is too slow for you, you can consider moving to the Premium tier, as it now has many features that were available only on App Service Environments previously, and it might fully fit your requirements.
Deployment slots vs. separate environments
Another place to look into for optimizing your App Service costs is reconsidering your application development and testing approach. It is common to create separate environments for application development and running the same application in production. Despite the benefits of that approach, it comes with additional costs, as you need to have twice as many cloud resources for it. Regarding App Service, it means that you usually have two separate App Service plans to pay for – one for production and one for development purposes.
What you can (and probably should) do is leverage App Service deployment slots, which are available starting from the Standard tier. Basically, they allow you to create and manage separate hosting containers for your development, testing and production versions of your application. Those containers are hosted on the same App Service plan, effectively reducing the need for additional plans. What is more, with App Service deployment slots, it’s much easier to push new application versions to production by performing slot swaps. Plus, you can implement A/B testing and split incoming traffic between production and staging slots to live-test your changes on a smaller scope.
As with consolidating multiple applications, App Service deployment slots share resources of the same App Service plan. So, please keep that in mind if you need to perform some load testing for your application. It might make sense to deploy a separate environment for that purpose and decommission it when you are done with your tests.
Network isolation and pricing tiers
This one is somewhat connected to rightsizing, as network isolation and private networking were previously achievable only on the Isolated tier when you deployed your app service environments into your Azure virtual networks. Those days are long gone; you can isolate your App Service environment on the network level even when running on the Basic tier. Azure App Service virtual network integration and Azure Private Link allow you to lock down network access to your App Service instances and services they depend on for work. The virtual network integration allows your App Services to communicate with other services deployed in your Azure Virtual network without using their public endpoints. Private endpoints provide private connectivity to your App Services from your private virtual network, so the inbound traffic to them never leaves your network.
For example, you can completely turn off the public endpoint on App Service and make it available only via a private endpoint, so it’s accessible from your private network only. If you need to securely publish your application for public access without exposing your App Service public endpoint, you can do it with Azure Front Door Premium, which can connect to it via private endpoints. Alternatively, you can configure access restrictions for your App Service public endpoint so it’s only accessible to your Azure Front Door Standard instance and not for direct access.
With all that being said, you might reconsider using more expensive Isolated and Premium tiers in favor of more affordable Standard and Basic ones, knowing that you can achieve comparable network isolation and protection for your App Services. Plus, implementing traffic offloading with such services as Azure Front Door might allow you to scale down your App Service plans, as few requests will be hitting them.
Reservations and Savings Plans for App Service
If the previous recommendations required some changes in your App Service deployments, this one is the most effortless. Suppose you know that you are likely to run your App Service instances as they are for a year or more. In that case, you can look into purchasing Azure Reservations if it’s a stable workload in a specific Azure region or Azure Savings plans if you need more flexibility in your service and region choice. Your savings from those commitments will vary depending on your App Service plan sizes and the length of the commitments. For maximum savings, it’s worth trying to refactor your App Service deployment according to the previously mentioned tactics first, then consider using reservation or savings plans for your already optimized environment.
The downside of that optimization is that it applies only to Premium v3 and Isolated v2 App Service plan tiers. However, as mentioned at the beginning of this article, it’s often possible to hit a cost reduction combo if you consolidate your multiple App Services on a few Premium v3 App Service plans and apply reservation or savings plans to them.
How to optimize Azure App Service costs with Turbo360
After going through all those optimization tactics for Azure App Service mentioned above, you might be thinking about implementing them in your practical scenarios. Depending on your specific use case of that cloud service and the scale of your infrastructure, you usually have the following options:
With small-scale App Service deployments, you can spend a few hours examining your configuration and optimizing it according to your constraints.
In large-scale scenarios, such as enterprise deployments with hundreds or thousands of App Service instances or managed service providers (MSP) managing hundreds of client environments, performing such cost optimizations manually is usually impractical and unfeasible.
For the latter option, it might make sense to look for third-party solutions like Turbo360 or similar that allow you to significantly reduce the time spent analyzing your cost optimization options and implementing them at scale.
For example, Turbo360’s Cost Analyzer can enhance your Azure App Service cost optimization strategy. It provides insights and optimization recommendations that native cloud tools often lack. The Cost Analyzer features go beyond basic cost metrics to provide granular insights into resource utilization, including identifying the exact needs of your Azure App Service. With rightsizing recommendations that include upgrade, downgrade, idle, and no change options, you can allocate your App Service resources more efficiently, avoiding their overprovisioning and underutilization.
Plus, Turbo360 allows you to create optimization schedules to scale resources down during non-peak hours and up during high load by automating scaling based on real-time resource demand and business requirements.
According to the insights from their existing client base, implementing such scaling schedules can reduce App Service costs by up to 65% for non-production environments.
Moreover, the Cost Analyzer’s monitoring feature allows you to set a predefined budget so that you do not exceed your spending and incur any surprise costs.
Frankly speaking, you can optimize your App Service (and any other cloud service) costs without using any third-party tools. However, you should understand that it might take a lot of time and effort to implement and monitor for new optimization opportunities on your own, using cloud-native tooling only. That’s why you might want to evaluate ready-to-use solutions like Turbo360 (it has a 15-day free trial) for Azure App Service optimization so that you can free up your time for more impactful and profitable work.
In conclusion
To sum up, optimizing costs for your App Service deployments is a creative task. It might even seem counter-effective when upgrading to higher service tiers and adding more cloud services to reduce overall operational expenses. Apart from that, you shouldn’t just blindly sacrifice your reliability, security and observability requirements to save a handful of coins. Azure cost optimization is not something you do in full isolation from other aspects of managing your applications and services. Moreover, it’s not something you do once and for all. Having good FinOps processes and tools to monitor and assess changes in your cloud expenses is equally important to one-time optimization, as changes are almost inevitable in the cloud, which can drive your cloud bill up as well as down.
