Last month I noticed a large increase of my Azure bill due to outgoing bandwidth. I used 1800GB of outgoing data vs ~200GB in previous periods. After some research I found that this was caused by the Azure Front Door service that I enabled last month and I was not aware of the additional indirect costs associated with the service.
I'll provide my analysis of the "issue" below to hopefully perevent others from making the mistake I made.
Azure Front Door allows for quick failover between groups (so called "pools") of web applications based on the health of the applications in the pool. A typical failover scenario would be between different regions. If one region has an issue, you failover to the other region.
The mechanism by which Front Door determines the health of an application is by sending a HTTP request where a 200 OK result is considered healthy.
The moment you enable Azure Front Door on your backend, it starts checking the health of your backend application and you potentially start paying so I performed some analysis and these are my findings:
[Range 4 hours, granularity 1 minute]
08:05 Started the webapp.
08:30 Enabled Front Door Service with default settings (Interval=30sec, Sample size=4, Successful samples required=2). Notice the immediate growth in number of requests from 0 to ~140 per minute.
09:03 Decreased the health probe interval from 30sec to 15sec. Notice the immediate growth in requests.
09:40 Quadrupled the body size of the health probe endpoint from 30KB to 119KB. Notice the immediate growth in bandwidth.
09:55 Reduced the body size of the health probe endpoint to 0KB. Notice the immediate drop in bandwidth.
10:08 Increased the health probe interval from 15sec to 90sec. Notice the immediate drop in requests.
It seems like the bandwidth is charged as outgoing bandwidth of the App Service (or whatever endpoint service is used) on top of the bandwidth of the Front Door service. I think this is because the Azure Front Door is a global service and therefore not region bound. These "hidden" charges are not mentioned on the pricing page
This default landing page of an Azure Function App is 126KB:
Takeaways
By default, Azure Front Door seems to visit your endpoint 140 times per minute and generates 20MB of traffic per minute (with a 30KB body). That is 27GB, or, EUR 1,90 per day (EU/US regions).
Don't use the default function app landing page as your health probe endpoint (or any large home page). I'm not sure about the best practices but I would think a custom endpoint that actually does some health checking and returns an empty body would be best.
Choose your interval wisely. Double the interval = double the bandwidth costs.
Set AzureWebJobsDisableHomepage to true in your app service config to remove the landing page from /, this saves on response size which saves on egress cost.
Related
I have set up an application gateway in almost five different regions in Azure and every time Azure take around 15-20 mins to complete the setup.
Whereas AWS will do it in a couple of minutes, why Azure requires such a long time?
You should try using Application Gateway V2, its a lot faster to create. updates are almost instantaneous (well, at least compared to V1). But I believe V1 is using windows VM's underneath, so it creates a set of vms for you, then it configures them. Each update would be a "sliding window" update, with 1 vm being recreated at a time.
As far as I know.
Application Gateway is a layer 7 load balancer which, as far as I understand, is a Windows VM (or collection of Windows VMs, depending on selected size) under the covers, which take some time to come up and be configured. In my experience, this time is usually around 15-30 minutes, depending on region and local time of day, capacity, etc.
Azure Load balancers on the other hand are layer 4 load balancers, which typically take in the order of 1-2 minutes to come up.
So, yes talking about the load balancer if you say it normally takes less than a minute to get deployed. But coming onto the Application gateway yeah it takes 15-20 minutes every time the reason being:
Configuration Settings: Microsoft has the set of the vacant load balancers ready at their backend and when they receive a request to deploy a particular load balancer in any region, they just assign it an IP as requested by the user and it gets deployed within a minute. But coming onto the Application gateway, azure need to start deploying the load balancer [App Gateway in this case] from the scratch, need to attach it to the VNET so deployed and making it ready for the backend pools IP Address configuration and all, which basically take time about [15-20 minutes]. Now, Azure has brought up the V2 of the Application Gateway, a lot faster to create usually 5 minutes. And also talking about updates they are also really quick and instantaneous.
Subscriptions: Secondly, the reason that it takes time is subscription. Suppose, you have the MSDN, free subscription in your Azure account. And another individual sitting at any different place is using the enterprise applications subscription [basically a pay as you go] in his azure account. Now, both of you raise a request to deploy an Application gateway in the same region at the same time then, Microsoft will give the person request with the enterprise subscription the higher priority than your free subscription request. Which is another reason that it results in a delay. As I am using the enterprise edition so it takes 2 minutes for a VM to deploy which gets deployed in 5-6 minutes if using the free subscription!
Thanks!
I have ASMX webservice with 1 MSSQL Database and a Single Table.
I have currently deployed it to Azure in the App Service
I have upgraded from Free Trial to Pay Per Use Plan.
I'm really confused with the App Service Plan
The ASMX Service is called by a Desktop application and it only has a few methods,just to fetch and return data from database.At max 100 users will be using it and may be a maximum of 1000 method calls may be made.
What does 60 minutes/day mean? The webservice can function for only 60 minutes?
I'm really confused.Please advice
Think of the minutes listed similar to a consumption plan on Azure Functions. When your website is responding to requests, it active and your "on the clock." When the site has been idle for a while, it will effectively go to sleep and you are "off the clock." Free and shared tiers are not "Always On". If your compute minute usage exceeds the quota (60 or 240 minutes), then Azure will return a 403 message to the browser and your site is unavailable until the quota resets for the next day. Free and Shared plans are really not designed for production. If you think you can squeeze your 1000 method calls into those time limits, great...it may be a cheaper solution. But you should expect the possibility of a 403 being returned and your request not being fulfilled. If your desktop app is important and really needs this service, you are probably better off paying for Basic (B1).
I have an app service plan which is hosting 2 Web APIs, the issue I am facing is that I am unable to view details such as: CPU Usage, Memory Percentage, Requests, Average Response time etc.
These can be found under the Overview tab for both App Service and App Service Plan but no data is being recorded, even if I retrieve data for the whole week rather than the last hour only.
I have also confirmed that I am hitting the correct App hosted on the correct Plan. Have I missed anything? Do I need to enable something?
I have also generated around 20k requests in the last few hours so I expect something to show up.
I'm a bit confused by Azure price calculator. In particular it doesn't explain the bandwidth pricing.
I'm considering Azure for a restful api that is going to use blobs for most data storage together with a sql server database for a subset that is easier to manage with a relational approach.
In this application a lot of data will enter the system through the ReST api, but a small fraction will be exposed to the clients (mainly as summary reports). Still the total bandwidth required should be in the order of 50 GiB/mo.
In the Azure's pricing page related to data transfer I see the pricing is only related to outgoing data, but I cannot figure how this relates to a ReST api that will be hosted in Azure App Service.
I mean, it could just mean that I'm going to pay for the bandwidth consumed by HTTPS responses (and not by HTTPS requests), but it seems a bit hard to estimate what this pricing is going to be.
Within a given region, there are no transfer costs at all. You mentioned using App Service, blobs, and SQL Database. As long as those services are within a single region, there are zero bandwidth costs as data flows between them and any other service within that region.
Bandwidth is billed specifically for outbound transfer. So, essentially you're metered for all data leaving a given region.
If you look at the page Data Transfers Pricing Details
Data Transfers refer to data moving in and out of Azure data centres other than those explicitly covered by the Content Delivery Network or ExpressRoute pricing.
Inbound data transfers
(i.e. data going into Azure data centres): Free
Outbound data transfer prices are set at a sliding scale depending on location and bandwidth used.
inbound traffic is free so the data coming in can be removed from the equation. Outbound is not free, and you saw the pricing page.
Data transfer is everything that is going out from every operation you execute.
And it is hard to estimate the traffic pricing - i would recommend to register the Azure trial and test it for a month and see how it is going. Because your data is not only what is returned, there is a lot of payloads coming with that.
But if you estimate 10 GB/month of outbound traffic, then it will start from $0.087 per GB starting from fifth GB (because first 5 are free). There are different regions described at the pricing page as well, so you should apply the pricing according to the region where your website is.
is it possible to turn off an azure media services end-point when idle, and turn it on again by demand (either by ways of configuration or programmatically?)
the purpose of this being saving costs on the end-point when not used.
There are several billing meters which apply for azure media services See https://azure.microsoft.com/en-us/pricing/details/media-services/ for all details.
Main price components:
Storage - you are paying based on how many space consumed by your assets. You can delete assets which are you no longer planning to use to avoid extra charges.
Encoding without reserved units - usage charges based on size of processed data. Your are not paying if system is in idle state.
Encoding with reserved Units - Same as #2 plus you are paying for allocation of resources.Reserved units help you to encode multiple jobs in a same time. Use portal to increase/decrease number of reserved units or REST/API, Client SDK to configure this parameter - https://msdn.microsoft.com/en-US/library/azure/dn859236.aspx#update_EncodingReservedUnitType
Live channels - For all live channel types, billing is based on the amount of time the channel is in running state and not based on the incoming and processed data. You can stop or delete channel to avoid incurring charges. See https://msdn.microsoft.com/en-us/library/azure/dn783458.aspx#stop_channels
Streaming units - Provides dedicated bandwidth capacity for both on-demand and live streaming. Pricing per unit. You can start/stop/scale streaming endpoint through portal or rest api - see https://msdn.microsoft.com/en-us/library/azure/dn783468.aspx
Content Protection - charges based on licences/keys issued through a service.