The Azure Cost Metrics Project is what I’m calling my effort to better understand Azure costs by setting a budget, building common Azure solutions such as web apps, virtual machines and platform databases (to name a few) and tracking real-world costs, or as close as I can get to them.
This time, we’re taking a look at the sources of runtime costs generated by an Azure web app.
The method:
1.) Use the Azure Pricing Calculator to estimate runtime costs
2.) Build the solution and observe actual runtime costs using the Azure Cost Management, Cost Analysis tool
3.) Compare the estimated runtime cost with the actual
How it worked out
Pricing Calculator Estimate
I started with the Azure Pricing Calculator (APC) as a baseline point of comparison.
According to the APC, the configurable cost estimate elements are:
- Region
- Operating System (i.e., the OS environment the runtime stack will run on; .Net would require Windows, Python can use Linux, PHP can use either, to name a few options)
- Tier (options are ‘Free, Shared, Basic, Standard, Premium V2, Premium V3 and Isolated)
- SSL Connections (options are Server Name Indication (SNI) SSL, which, according to the Pricing Calculator, does not add cost at any level of connections and IP SSL which generates charges per connection – for example, 1000 estimated SNI SSL connections per month are calculated as zero charges while 1000 IP SSL connections per month generate over 38,000 USD)
Observed Runtime Costs
I built a web app that used North Europe as the region, Windows as the environment, the standard tier and SNI SSL as the connection default. I also built a log analytics workspace to gather performance data for Azure Application Insights.
The web app ran for about seven days, during which I explored the runtime cost sources using the Azure Cost Management Cost Analysis tool. The Cost Analysis showed:
Three main metrics:
1.) The app service plan and tier (mine was S1)
2.) Log Analytics workspace
3.) The web app service
Actual Costs and Billing Meters:
- The app service plan (S1)’s run rate was approx. 2.02 USD per day (with zero usage). There was some plus minus fluctuation but the average was 2.02
- The meter for billing in log analytics is data ingestion ( no log analytics data from the pricing calculator)
- data transfer out bandwidth (based on the use of Application Insights
- App Service Plan tier (for example, F1)
What did we learn?
As is true for everything deployed on Azure, your architectural choices have a direct impact on runtime costs. In the case of an Azure web app, the daily runtime cost of the app itself can be considered stable and largely predictable (depending on the tier you choose). To contain costs, it’s important to avoid over-provisioning – in this case, by choosing a more robust service tier than required.
Bandwidth generated by monitoring (for log analytics and Azure Application Insights) is treated as a separate cost meter and should be considered. It’s also important to choose the right SSL connection type (from a cost, and probably also architectural efficiency point of view, SNI is preferable to IP, which creates individual SSL connections, each of which generates a seperate billing meter)
Azure FinOps 