Azure PaaS Cost Optimization

I wanted to write a short blog post about cost optimization regarding Azure PaaS, and this is the result. This subject has been covered in many blogs and articles during the last few years. What I have found, is that this mostly relates to Reserved Instances, Hybrid Benefit or right-sizing of Virtual Machines. Optimizing your IaaS resources is of course important, but what if you don’t have or want VMs in Azure?

Some companies are leveraging Azure are working with a soft “non-VM” strategy, or PaaS first. This could mean that they don’t want any VMs in Azure at all, or that they try to avoid VMs in Azure whenever possible.

Whatever your strategy for this, there are optimizations to be made also for PaaS! I will try to list some of those that I have found both in blogs and by experience.

Microsoft has posted an overview of discounts for specific services here.

The shortlist:

Storage Account Blob Tiering
Storage Account Redundancy level
Right-Size App Service Plans and Consolidate apps
Optimize app performance
Reserved Instances for ASE
Right-Size and Scale SQL DBs
Reserved Instances for SQL DBs
Hybrid Benefit for SQL DBs
Resource Lifecycle Management
Optimize SQL Queries

Storage Accounts

Blob tiering

Microsoft recommends using Storage Account V2 for all new storage accounts, but you need to do an assessment before choosing this, as the cost will be different than for V1. Information on the different types here.

Choose tiering policy based on the usage of your blobs. Set the account-level tiering to hot for data access often, and cold if your data is not accessed often. Create a lifecycle management policy to automatically move data between tiers. This is easy to do, and free of charge for V2 (not available for V1).

Redundancy (LRS/GRS/GZRS/RA-GRS/ZRS)

Bear in mind what level of storage redundancy you choose when creating your storage account. Sometimes you need geo-redundancy, sometimes local redundancy is sufficient. Use the most suitable redundancy, as the pricing is different for these. LRS being the cheapest.

App Services

Right-size App Service Plans and Consolidate App Services

App Service Plans can, and should be, sized according to what you need. Keep a close eye on the metrics, and see if there are possibilities of reducing your assigned capacity, or even the tier. Some test sites may be suited for running on the free or shared tier. This can reduce your cost by a considerable amount if you have many app services. Some services may need to run in a PremiumV2. This will depend on your app and the usage.

Consolidate the apps that can run together, and keep in mind the networking requirements if you need to use Regional Vnet Integration.

Optimize App Service Performance

Your application is running as expected, you have resized the App Service Plan to fit the usage, and the users are happy. What now? Can we optimize further?

If the application is developed in-house, or you have access to the source code, you might be able to achieve more optimization. Use Application Insights to identify long running requests, or even exceptions you might have missed earlier. Removing these by optimizing the source code, and making the application more efficient, can enable you to choose a lower App Service Tier. It is not very likely to find a big win here, but fixing errors in the apps can also have other benefits 🙂

Reserved Instances App Service Environment (App Service Isolated Tier)

This is a possibility of reducing cost if you are already using the Isolated App Service tier of Azure App Service, often referred to an App Service Environment. This is a more pricey tier of App Service, but is a very relevant tier for many customers.

Keywords for when you should consider an ASE:

Very high scale.
Isolation and secure network access.
High memory utilization.

You could be leveraging Reserved Instances to save on infrastructure cost in your isolated App Service Environment. See information about this here.

SQL Databases

Right-size and scale

When you migrate an application to Azure, you will most likely overestimate how much resources you need. This is OK, as long as you do a capacity assessment after running normal operations for a little while.

Consider this example:

You move an application (app service with an SQL database) to Azure. The database is initially set to 600 Database Transaction Units (the “old way”, I know).

After a few weeks, you see that the peak usage is nowhere near the 600DTU limit. Maybe it uses 50% of the assigned DTUs. There will most likely be peaks during the day, and periods of inactivity during the night, if this service has interactive users.

This gives you the opportunity to both change pricing method to vCore Serverless, and start scaling your capacity! There are some scenarios and guidelines here. Use auto-pause if this is possible while still maintaining the user experience, but remember that this will lead to some initial database communications failing when re-activating. There is also some startup time to consider. Please this post for some considerations and caveats. There are price differences and details to look out for here, and you could actually end up with a more expensive database if you are not aware of the database usage.

If you have many SQL databases, you could also potentially benefit from consolidating these with Elastic Pools.

Reserved Instances

If you are leveraging Azure SQL Databases, and I hope you are – and you are using vCore pricing – you can purchase reserved instances and use these to reduce the compute cost. More information about this here.

Hybrid Benefit

If you are eligible for Hybrid Benefit in Azure, you can reduce your SQL Database License cost by activating the SQL Database Hybrid Benefit.

Bear in mind that this will not really reduce your total cost, but it will enable you to use existing eligible licenses in Azure. You will still need to pay for the license onpremises, but you don’t need to pay twice.

Optimize Queries

Have a look at the Query Performance Insights for your SQL Database, and you can often see queries consuming high amounts of resources. Have a look at these, and see if there is a possibility of optimizing them by changing queries, or reducing the execution count. A well written select statement can some times reduce your query execution time. Maybe you can also optimize the queries by adding missing indexes, or re-indexing some columns. Less resources required means you will save more if you have auto-scale enabled.

Resource Lifecycle Management

Keep a close eye on your Azure environment, and you should be able to spot idle resources. Cost Management & Billing is helpful in this matter, if your CSP plan allows it or you are using EA/PAYG. Here you can spot costly resources, but it is not always easy to see if the resources are in use. To see if resources are used, you can check the metrics for them, and even create Azure Monitor Workbooks to get a quick overview.

You should tag your resources with important information, as part of a more comprehensive Governance framework, and this should help you identify unused resources.

For example:

Lingering unused resources after finished projects
Inactive testing and development resources
That staging storage account with migration data which is no longer relevant

External sources:

Reduce development and testing cost with automation

Developers often have need of environments where they develop solutions. Very simplified, it’s their job to develop stuff, and make it work. To do this, they need development environments, and they can some times require massive amounts of resources. They are probably not using this environment 24/7.

Now, some developers like to convert coffee to code in the dark hours of the night. Some do it 9-5. Some do it 8-4. The point is that there are many hours of the day where development environments will likely be underutilized or even unused. With this in mind, we can leverage the powers of ARM Templates/Bash/PowerShell, or whatever method you have for deploying your infrastructure, and automate it. Remember – there could be resources that need to be static (IP-addresses, guids), and there could be resources that take a lot of time to establish (VPNs, Application Gateways). This must be taken into account when choosing the right timeframe for teardown, and if you even can do teardown in your situation.

The potential for reducing cost by automating and managing your dev/test environments can be significant, if you don’t have them under strict control at the moment. Remember to check in with the relevant developers/testers and make sure this is OK with them.

In conclusion

Many good tips can be found at Stackify and ShareGate. Netapp also has some good tips, and Microsoft provides Advisor recommendations in your own subscription.

There you have it. A few ways of reducing your Azure cost. How are you reducing your cost? Please comment if you have suggestions or comments! 🙂