App Service

Factors Affecting Cost

• SKU / Hosting choices

• Dependencies

• Features required

• Efficiency of your code

Things to think about

Is an App Service the right choice

The question if an app service is the right choice for hosting your app is the first key thing you should think about.  Obviously this decision is affected by more things than just the cost for hosting, but the choice you make will affect the price you pay.

Different types of app that you may host on an App Service may have slightly different requirements but in general an app you might host on an App Service could potentially also be hosted on:

• AKS

• Container Apps

• Static Web Apps

The cost considerations for these are different and ensuring you have considered the longer term cost sustainability and growth potential for your application into that fundamental decision is a good idea.

Shared or Dedicated Plans

Assuming you have chosen to use an App Service Plan then there is a question about how your organization will utilize app service plans.  In many organizations you are likely to be building more than 1 app so the question is about how you will choose to place the apps on the plans.

In some cases you may choose to share an App Service plan across multiple applications or teams and in other cases you may choose to have dedicated plans for apps and teams.

The more you can effectively share resources then the more cost efficient you are likely to be but there is no one size fits all answer here.  There will be some applications which need specific features or performance requirements and will 100% want to be hosted on dedicated app service plans and there will be others that are good candidates for sharing.

How many apps on my plan

As a follow up point to consider after you have decided to share an app service plan across multiple apps.  The next question is how many apps do you want to have on your plan.

Again it depends, there are multiple factors to consider here.

You will need to think about the load profiles of your applications and how they will scale up and scale out to consider the best placement for cost efficiency.  You also need to trade this off with other factors, in particular performance.

Which O/S do I need

When setting up an App Service Plan there is a choice of O/S that you would like to use.  The price is different based on your choice.  Ensure to check the requirements of your application to decide which is the right choice, and if you have the ability to use both O/S, then you will find the Linux app service plans are generally cheaper.

Which SKU should I pick

There are many choices of SKU available to App Service and within the choices there are sizes.  Premium, Basic, Standard, Free, etc.  In reality its quite confusing to know which is the best one to pick.

In general there is quite a lot of flexibility to change between the SKU, for example changing from basic to standard.  You do need to be aware that choosing certain features can limit that flexibility.  For example choosing network integration would limit your ability to change from a premium to basic sku.

One of the good things about the SKU choice is that there is a good chance you will be able to try different ones out during your project lifecycle to find the one that is the best fit when optimizing your performance.

In addition to the normal App Service Plans, there is also the App Service Environment, which provides you with isolated and dedicated infrastructure for your app.  There are a number of feature benefits of the App Service Environment but there is a cost for that.  You should consider things beyond just the simple billing line item cost when making the SKU decision, as there is also a complexity/simplification factor that comes into the total cost of ownership.

Do I need advanced networking features

Your choice of vnet integration and private endpoint usage will influence some of the decisions you will make on the SKU you choose.  

I remember a project where the customer was running an application for a long time that was running at a pretty low cost, and then they decided that new features allowed them to connect a bunch of the application resources to a vnet which had previously not been 100% possible.  Their solution had previously ticked all of the boxes on their security audits and had been successfully penetration tested multiple times.  They decided to proceed with adding resources to a private network, which had a much bigger scope than just the application, and the result was the SKU choice for their App Service needed to change, increasing the costs quite significantly.

In this case there is an argument that the application is now more secure because parts of it are private which were public before but at the same time if the application is compromised then there is a network line of sight to resources that the application didnt have network line of sight to previously.

I am not saying one is better than the other here; it's another “it depends” question, but my point is that when you change things like this in your architecture, there is often a noticeable cost impact from the change, and you should look at your trade-off between security and cost.  Do we get enough additional security and risk mitigation to justify the cost?  You will have 2 stakeholders here, the security person will say yes, and the bill payer will say I don’t understand why I need to pay for this.  As a solution architect, you need to manage this relationship to balance the trade-off between the requirements.

Scale up vs Scale out

Scale up vs Scale out is an interesting factor to think about.  In general the price increase for a hop from one size to the next is about double.  There are a few small variations on this on certain sizes but its a good general rule.  At a high level this should mean there is little difference between 1 bigger node vs 2 smaller nodes.  In reality it can be more complex than that.

You need to think about the performance and run characteristics of your application here.  Some of the things I would be thinking about include:

1) If my application is running on a medium node and its base line performance is using a lot of resources then I can have scenarios where scaling out to two medium nodes might need me to scale to three nodes sooner than when my 1 x large node would become resource constrained

2) If we go past a simple scaling scenario and start thinking things like the fact that if I go past the capacity of 1 large node and 2 medium nodes, then 3 medium nodes will be cheaper than 2 large nodes and so on.  We need to consider how our app will scale and how that will affect cost.

Dynamic Scaling

If we follow on from the point above about scale up vs scale out, in general scale out will be better than scale up from a cost perspective.  The main reason for this with App Service is that scale out can be driven automatically with rules and by elastic scaling.  This means that scale-out can also support scale-in.

You can not configure out-of-the-box rules to automatically scale your app service up and down based on load or other parameters, but you can do this for scale-out.

If our above scenario where we have our single instance of a medium node for App Service, we can burst out to 4 nodes during a busy time and then burst back down to a single node because load dies off.  This minimizes wasted compute power which is good for cost.

Availability Zones

Availability Zones are a great feature to improve the availability of your application within a region.  To do this, you can pretty much flip a switch when setting up your App Service Plan, and it will set up nodes to run across data centers within a region.  The trade-off here is that you will already have 3 active nodes running on your app to achieve this.  You will be paying for these 3 nodes.

The first question is if you need availability zones or not.  This will depend on the non-functional requirements of your application.

If you do need availability zones then you now have the benefit that you have ticked boxes for scale out at the same time as improving availability of your application for the same cost.  You dont need 3 nodes in each data centre within the region.

DR environments

When it comes to cross region DR for App Service then you may choose to have an App Service Plan in 2 different Azure regions and then use something like frontdoor or traffic manager to route traffic across them.

You are likely to also have Availability Zones enabled in this scenario so before you start you are already running 6 nodes on App Service which you will be paying for.

The first question here is “Do I really need this DR environment”.  If you check your non-functional requirements and Recovery Time objective, you may be able to meet your requirements with a good devops process.

If you need to have a DR environment, the next question is if you can make your application active/active vs active/passive.  If we can have the compute we are paying for actually be used then we are reducing waste.

There are a number of wider considerations come into play here about the DR scenario for other resources your app needs such as the database which will also affect your approach.

From a purely cost management perspective the principal is:

1) Make sure we actually need it

2) If we do need it, how can we make sure we are using it so we minimize waste

Discounts & Offers

There are a number of discounts and offers which can be utilized with App Service such as:

• Reserved Instances

• Free Tiers

• Savings Plans

• Dev/Test subscriptions

All of the above can reduce the costs for your App Service costs.

Dependencies

While not directly billed as a line item for the App Service Plan, the app you have running will potentially have dependencies which will have an associated cost with them on your Azure Bill.  A good example of this is my web app might utilize an App Insights / Log Analytics instance which will have associated Azure Monitor costs.

If my app is not configured to effectively use these dependencies then the cost for them may be more than expected which will increase the total cost of my solution.

Common Optimizations

Is your code optimized

One of the key things to check is the performance of your code.  If your code is inefficient then it will perform poorly and this will have a direct impact on cost.  If you need scale the app service plan because the code smells.

Ensure you are following good development practices and performance testing to optimize this.

Configuration for App Insights use

I touched on this earlier in this page, but you need to configure your App Insights config effectively.  Do you use sampling, do you use appropriate log levels.  One of the most common cost frustrations for customers is that their log costs were more than they planned for because they log everything and dont use it.

Dynamic Scaling Rules

In Azure App Service, you can configure dynamic rules to scale your App Service out and in based on usage.  This is one of the things you should definitely ensure you are using effectively.

How can Turbo360 help

In this section, we will look at some of the ways Turbo360 can help.

Visualizing Spend

When it comes to visualizing cost, it is often challenging for your project team to get a clear view of their Azure consumption during the project lifecycle.  In Turbo360, we are trying to encourage a DevFinOps mindset where the team can get visibility into the costs early in the lifecycle so they can use that information to make informed decisions where cost impact is factored into the decisions.

Using the graphs in Turbo360 you can look at App Service Costs holistically across the organization or create smaller scopes to look at individual applications or projects.

Rightsizing

Turbo360 will help you to see Azure Advisor recommendations within the context of the application you are managing costs for to ensure you dont miss them.  It will also provide its own recommendations which often go beyond Azure Advisor.  You also have control over the recommendation rules if you want to change them.

Turbo360 rightsizing will help you find the key areas where you can potentially save money through rightsizing.

Reservations

Many customers miss opportunities to reserve App Service instances.  Turbo360 will help you see which App Services could potentially benefit from a reservation.  

Scheduled Resizing of App Service Plan

Turbo360 has a scheduler feature which allows you to automatically scale up and down an App Service Plan.  This is good for environments such as non-production or applications with time based usage patterns where you can automate scaling up and down to meet the needs of users while reducing costs.

You can achieve these automation without needing a DevOps expert to script loads of stuff.  Just a couple of clicks and its up and running.

Clean up waste

Turbo360 has other recommendations which will help you identify waste where you have app services which no longer have apps deployed on them so you can delete these resources.

Useful Resources

• How to Optimize Azure App Service Costs Like a Pro?