none
How to enforce a maximum transaction limit in a timespan, e. g. max. 1000 requests per month? RRS feed

  • Question

  • Hello,

    I have a Logic App which provides a HTTP endpoint ('When a HTTP request is received' trigger) and consumes a Microsoft Azure API internally. Afterwards the result of the consumed Azure API is returned. I want to realize a maximum of transactions my HTTP endpoint will allow in a specific timespan, e. g. a month. If this limit can't be realized on Logic App level (before the workflow is triggered to reduce unnecessary traffic), I would like to implement this limit at least somehow in the workflow itself.

    Example scenario:

    The Logic APP shouldn't trigger if a threshold of 1,000 transactions were exceeded within the current month. The idea behind this is to prevent the Logic App to cause high costs by exceeding some Azure API limits.

    What I tried/solutions which won't help me:

    1. It looks like there is no global variables available in Microsoft Flow/Microsoft Logic Apps. Thus I would have to write and to read a block blob storage with a date and counter. This is quite ugly but would work.

    2. Maybe this could be realized with Azure's API Management Services but this is a huge requirement for such a basic task.

    3. I don't want to add some kind of proxy or server in front of it to make a third party request count the forwarded HTTP requests (like some cheap hosted VPS with a webserver and a HTML form which redirects the calls to the Logic App in the PHP backend). It should be a Azure solution, preferred within Logic Apps due to additional costs implied by buying another Azure API/service.


    Can you think of a good solution for this basic scenario? Thank you!

    Best Regards,

    Sunday, September 8, 2019 1:41 PM

Answers

  • This is a perfect use case for the Consumption Tier of Azure API Management. It gives you a host of functionality apart from just rate limiting like caching (external redis required), oauth, etc.

    Consumption Tier supports a subset of features as documented but offers a consumption-based (per million requests) pricing model. Also, it comes with a monthly free grant of 1 million requests.

    The Logic App only alternative would be like you've mentioned. You could have a separate logic app to implement the rate limit functionality which could in turn call your actual logic app for easier maintenance.
    Monday, September 9, 2019 5:06 AM
    Moderator

All replies

  • This is a perfect use case for the Consumption Tier of Azure API Management. It gives you a host of functionality apart from just rate limiting like caching (external redis required), oauth, etc.

    Consumption Tier supports a subset of features as documented but offers a consumption-based (per million requests) pricing model. Also, it comes with a monthly free grant of 1 million requests.

    The Logic App only alternative would be like you've mentioned. You could have a separate logic app to implement the rate limit functionality which could in turn call your actual logic app for easier maintenance.
    Monday, September 9, 2019 5:06 AM
    Moderator
  • Thank you for your reply @Pramod! Sorry for getting back to you so lately. I had personal reasons for that and it took me some time to find the options you talk about.

    I checked the docs and I found this: https://docs.microsoft.com/en-us/azure/api-management/api-management-sample-flexible-throttling

    NOTE: The rate-limit-by-key and quota-by-key policies are not available when in the Consumption tier of Azure API Management.

    Is there any other way with the consumption tier of Azure API Management?
    Tuesday, September 17, 2019 11:16 AM
  • No worries at all.

    While those policies aren't available, you should still be able to use rate-limit and quota policies which are scoped to a subscription by default.

    Subscriptions have undergone major changes for the Consumption Tier and is documented. Previously, subscriptions were tied to a product but now they could simply be for all or a single API as required.

    Tuesday, September 17, 2019 5:52 PM
    Moderator