Real cost of developing a project in Azure

Recently I've moved one of my side projects fully to the cloud. In this short post I'd like to show you what is the real cost of developing a fairly small yet multi-dimensional project and how Azure gives me and my client flexibility to select what is really needed in this particular moment.

The project

I won't go into details here. Just to make a long story short - we're gathering data from many electronic devices and then provide reports based on different time intervals, places and custom properties to the clients. There's also a need to handle the old legacy system and migrate data from the old database to the new one.

Azure components

Mentioned project is built using following elements:

  • Storage account
  • Function App
  • 2x Web App
  • SQL database
  • Azure B2C
  • Application Insights

worth mentioning here is the fact, that by default we're using free tiers for Web Apps and SQL server.

Taking into consideration all above our monthly cost of developing this project is 1,50 EUR on average.


Because we're using free tiers, we have to be aware of limits - like available CPU minutes per day - but on the other hand, there's no problem to scale up when needed. This is what really made us into cloud - if only small features are being developed, free tier is more than enough. If we're during a strenuous period of developing new features, we can just go to the portal and change a tier.

Additionally we have to be aware, that on production we won't be able to use free versions of Azure components because of lacking features and much higher traffic. On the other hand, saving money in such way instead of paying much more money for resources we won't be able to utilize is a much smarter decision.

Detailed cost

There're two resources which make the most of our cost: Storage account and Function App. This is because they're the "hot path" in the system - one of the functions fetches data from FTP and pushes each record to a queues. Other functions take data from queues and perform some transformations, store data and push it further. When I checked my Billing page, the cost looks like this:

  • Storage account 0,62 EUR
  • Function App 0,55 EUR
  • B2C 0,09EUR
  • The rest of resources 0 EUR

We didn't need more power this month so we could keep the lowest cost possible.


Carefully designed cloud solution could really lower monthly cost of developing a project. On the other hand I've seen many examples, where developing a product in the cloud was much more expensive than an old-fashioned VM(or even a production environment also hosted somewhere in Azure!). Pay attention to resources used, selected tiers and their utilization and you won't be surprised when you see a bill at the end of a month.

Considering appropriate app service plan for your Azure Functions

As we all(or most of us) know, Azure Functions can be hosted using either a regular app service plan or a consumption plan. We can quickly summarize pros and cons of both:

App service plan:

  • fixed cost(+)
  • easy to scale(+)
  • ability to run 64-bit applications(+)
  • can reuse other app service plans(+)
  • fixed cost(--)
  • some triggers need Always On enabled(-)

Consumption plan

  • pay-as-you-go(++)
  • no need to have Always On for e.g. TimerTrigger(+)
  • somehow more difficult to scale(-)
  • if not designed carefully, the cost may exceed our expectations seriously(-)

All right - but what really should I consider when it comes to choosing the correct plan for my application?


In the current world scalability is something, what should be really considered when designing an application and choosing technologies for it. Let's consider a following example - you're designing an e-commerce application, which has to handle really big traffic spikes from time to time(imagine Black Friday or any other black something). The specifics of traffic on your website could be described as:

  • stable and low traffic for the most of a week
  • an increase during weekend
  • occasional huge spikes during special events 

Now let's relate this to our service plans. What is better for us in such scenario?

Well, the problem with consumption plan is the fact, that it needs a running start. You can't expect, that if your application is hit by a huge traffic spike, it'll scale out immediately. What is more, you don't have a possibility to scale up - you're limited to the resources allocated for you for your instance of the consumption plan. You have to consider one more thing - execution of functions is not throttled in any way by default so you may face a situation, where under a heavy load your function utilize too much CPU/memory at once. You can control throttling by following three properties:

  • maxOutstandingRequests
  • maxConcurrentRequests
  • dynamicThrottlesEnabled

which are described here. The one thing you have to remember when using throttling is the possibility, that your client may get HTTP 429 Too Busy responses. Whether it's a problem, only you can decide.

When using s regular app service plan those traffic spikes are much easier to handle. Since you can have scaling rules, you don't care when scaling out happens - it just does when it hits CPU/memory threshold(or other metric if autoscale is enabled). Additionally you can preprovision extra resources if you know when a traffic spike will happen - this way you're prepared.


When designing cloud solutions, the cost is one of the most important factors. If you choose components poorly or overdesign them, the bill at the end of a month won't make you happy for sure. This is the second thing directly related to service plans, which affects our choice when it comes to select what is the best.

Pay-as-you-go model in consumption plan is something, what really make functions interesting. When designed carefully, you can run them for almost free each month(or pay only a few USD/EUR after the free quota is exceeded). The problem is when you keep your functions "red" - in such scenario, it may be easier and cheaper to use a regular app service plan, which ensures the constant cost of this component and won't surprise you after a busy weekend(how is that I have to pay extra 500$ this month?).

Of course with a regular app service plan you lose flexibility and have to remember to scale your application down(or at least have something to automate this). The compromise here depends on your current needs and how the model of your business looks like. However it's still better to discuss it now and be aware of your possibilities rather than discovering them when functions start to respond with HTTP 503 status.