Azure Cost Optimizations: Logic App skipped triggers are billable

by Sandro Pereira | Feb 7, 2024 | BizTalk Community Blogs via Syndication

Azure Cost Optimizations is a very complex topic, and depending on the services you are using, it will require different skills and knowledge. Today, I’m going to speak about Logic App Consumption and skipped triggers.

Of course, when you think about optimizing Logic App Consumption costs, it is very important to understand all the cost calculations and how your flow design affects these costs. Once you understand those topics, you will be faced with different solutions to optimize the costs. Some of them require redesigning your workflows; others are a matter of monitoring, automation, and configuration.

But first, let’s add some context and provide a common example that I will assume that many customers will find it familiar:

• We have one or more systems sending messages to a Service Bus Topic or Queue;
• And we have a Logic App that is pulling messages each X amount of time;
• Process them and send them to other systems.

I found it very common to see the configuration of the Service Bus trigger and see that the polling interval is configured to be 30 seconds.

I ask you not to get me wrong. This configuration itself is not bad, and in many scenarios, it can be exactly what we want and need. But in some cases, it may be too aggressive.

The ideal scenario is to analyze the integration run history, speak to all parties involved, and adjust these values. When I was reviewing one of these cases in one of my clients, I noticed that every day, the pulling only occurred between 5:00 AM and 5:01 AM. Actually, in many cases, it took 9 seconds to process all the messages:

At first, I didn’t give it much importance, but when I checked the pulling configuration and the trigger history, I realized that every 30 seconds, there was a skipped trigger occurrence:

Why is this important?

As I mentioned in the beginning, it is essential to understand all the cost calculations inside Logic Apps correctly. For example:

• Per subscription, you will have the first 4,000 actions for free each day!
  • Notice that this is not 4000 per Logic App. This is the combination of all action executions of all Logic Apps within a subscription.
  • A good benefit of Logic Apps is that the action costs are quite cheap. For example, 600.000 action executions per day will cost you an average of $14,90 per month.
• On the other hand, despite not being too expensive, connection executions are a little bit more costly, and you don’t have free executions.

Another thing that you need to be aware of is that Azure Logic Apps meters all successful and unsuccessful actions as executions. However, Logic Apps don’t meter these actions:

• Actions that get skipped due to unmet conditions
• Actions that get skipped due to unmet conditions

However, it is important for you to be aware that skipped triggers are billable.

Now, you may be wondering: why should I care? That’s just a few dollars a month!

Let’s do a small exercise:

• Knowing that one day is 86400 seconds and you have one Logic App configured with the polling interval to be 30 seconds. That gives you a total of 2,880 trigger executions per day for that single Logic App.
  • That makes a total of $0.36 per month, $4.32 per year. That’s nothing, right?
  • Assuming that we have 4 environments: Development, test, QA, and Production, that makes a total of $17.28 per year. It’s still very decent.
  • But that could also be $0.48 per year if properly configured!
• Now, we know that we will have many of those scenarios, so let’s assume that we have 10 Logic Apps in this same situation.
  • 10 Logic Apps x 2,880 trigger executions each = 28800 trigger executions each per day, making a total of $3.60 per month, $43.20 per year.
  • Once again, assuming that we have 4 environments: Development, test, QA, and Production, that makes a total of $172.80 per year. Well, it is already some money. It is nothing really expensive, but it is not a few dollars anymore.
  • But what if I tell you that the total cost could also be $4.80 per year if properly configured? That’sThat’s a $168 saving each year in 10 Logic Apps.
• Now, if we go to more enterprise scenarios, where we find 100 Logic Apps doing this behavior, and trust me, it is a small number. Then you will have a different picture because:
  • 100 Logic Apps x 2,880 trigger executions each = 288000 trigger executions each per day, making a total of $36.00 per month, $432.00 per year.
  • If we assume the same number of environments, then that makes a total of $1,728.00 per year.
  • That can easily be $48.00 per year if properly configured! That’s a huge saving.

So, it can make a difference just by controlling the pulling strategy.

How can we improve this and optimize the costs?

Depending on the scenarios and requirements, you may find several approaches:

• The first and straightforward approach is to have a less aggressive pulling period, passing, for example, from every 30 seconds to every 10 minutes or more.
  • This doesn’t require any redesign of the solution, only a different configuration.

• The second approach, for example, is that instead of having the Service Bus trigger, modify it to a Recurrence trigger with a fixed interval and get the messages from the Service Bus.
  • In this case, the Logic App will run at 5:01, 5:02, 5:03, 5:04, 5:05, 5:06, 5:07, 5:08, 5:09, 5:10, 5:11, 5:12, 5:13, 5:14 every day and try to pull 25 messages.

• The third approach can be having the non-production environments disabled at all time and enabled when needed. Something that doesn’t happen often. Normally, all environments are running.
• The fourth approach, and one of the most elegant approaches, is to set up a trigger condition. These conditions act as gatekeepers, allowing your Logic App to fire only when specific criteria are met.
  • On the trigger, click on the three dots (…) and then select the Settings option.
  • In the Settings for  panel, go down to the Trigger Conditions section and add your condition.
  • @and(greaterOrEquals(formatDateTime(utcNow(), 'HH:mm'), '15:00'), less(formatDateTime(utcNow(), 'HH:mm'), '16:00'))

How can Serverless360 help you save costs in these scenarios?

Among many other features available in Serverless360 to analyze and optimize the costs of your applications, Serveless360 brings you a feature to configure and automate the time of life of specific resources like the Logic Apps. In this particular configuration case, I’m saying that the Logic App will only be enabled daily from 8 PM to 9 PM – a total of 7 hours weekly.

The tool also provides me a total estimated savings of this particular configuration: 95.83% of savings! For me, this is absolutely awesome! And I’m not in charge of controlling costs for my customers, only helping them find ways to optimize their costs and hoping to allow them to save some money.

I hope you enjoy this cost reduction tip, and stay tuned for more content.

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira

Azure Cost Optimizations: Push vs Pull may significantly impact the final solution cost

by Sandro Pereira | Feb 5, 2024 | BizTalk Community Blogs via Syndication

It is really important for companies to have implemented strategies and policies defined before starting to implement integration solutions on Azure or give decision design power to external consultant companies, such as:

• Which services are part of the middleware solution in Azure?
• What are they for, and when can we use them?
• How can we handle requirement exceptions?
• Naming conventions, CI/CD, and tag policies
• And so on.

I’m about to tell a real story about how I saved more than 20K a year for one of my clients and why those reasons above are so important. I should have asked for a bonus since they have already saved more than 100K because of me.

One of my clients decided to do a POC on Azure Integration using Logic Apps and Service Bus, and during that period, I was busy working on a critical application for that client. So, they decided not to initially involve me and delegated this POC to another partner. The requirements were quite simple:

• They would like to have an async process to integrate HR information between the two systems.
• They would want to use a no-code, low-code approach using Azure Integration Services as much as possible.

And they did it! They actually implemented a very good solution, looking only at the technical implementation. They decided to design a push implementation that allowed an almost real-time integration.

Once my client contacted me to help them deploy it to production, I only knew that this was a POC and, if everything went well, would be used in production as a real solution. So, if they were asking me to help them deploy to production, that meant at that point that:

• Everything worked well and as expected.
• The requirements were accomplished.
• And they already accepted that solution.

However, I asked if I could do a minor assessment of the solution, mainly to understand how the pieces were built and how we could deploy them to production, and since I was doing it, validate if everything was according to best practices.

And after analyzing the solution, I became curious, so I went to my client and asked the following questions:

• Is this a mission-critical application?
  • Client: No, this is not a mission-critical application.
• Do you need almost real-time integration?
  • Client: No. Even if they are not integrated today, they will be resent tomorrow or in the next synchronization.
• On average, how many messages do you send per day?
  • Typically, close to 100 or less.
• Are they big messages (more than 256 KB)?
  • No, they are small.

Of course, I already expected this type of response and had my homework done. Tools like Serverless360 are used to analyze the cost of the application, and the Azure Calculator is used to predict the costs. I had a rough estimation of how much this solution would cost my client monthly and yearly.

I know they are a big company, but I asked the most obviously logical question in this situation:

• Do you know how much this solution costs to you?
  • Client: Not really, but I know that we have already exceeded the planned budget. Do you know how much?

They were shocked when I told them: ~$677 per month.

But that was worse because they have four environments: DEV, TEST, QA, and PROD, so they need to multiply that by 4, meaning ~2.7K per month, which means close to 32.5K per year! To process 100 messages per day on a non-critical application!

Is there a better approach?

Well, I don’t say that there is a better approach. An approach is good when it will fulfill the technical and financial expectations. In many cases, the previous approach will be the better approach. Especially if you already have Service Bus premium in your organization and several applications are using that.

Now, if you are starting your journey with Azure or want to control the cost, you should opt for a significantly cheaper approach that also fulfills all the technical requirements.

So, how can we reduce the costs of this solution by 99%?

Yes, you are reading correctly. Actually, it is more than 99% since by the time we end refactoring, the estimated monthly cost was $2.68 (don’t forget we had four environments) or $128.64 per year!

Basically, the only drastic difference in the design of the solution was to transform it into a pull architecture.

• Because we only needed a queue, we have downgraded our Service Bus from Premium to Basic.
• We removed the Event Grid from the equation since it requires Service Bus Premium.
• And finally, we change the trigger of the Logic App to pull messages from the Service Bus queue each X minutes.

All the requirements were accomplished with this new architecture. The costs were surprisingly cheap, which motivated the client, who was already concerned about Azure costs, to adopt more cloud integration solutions.

The solution is still running in production without any changes or improvements.

I hope you enjoy this cost reduction tip, and stay tuned for more content.

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira