Submitted on https://feedback.azure.com/forums/34192–general-feedback/suggestions/40962238-global-router-solution-for-billing-sensitive-api-u on 7/21/2020 We are looking for a Global Router Solution for Billing-Sensitive API Use Cases and we worked with multiple parts of Azure support (namely Front Door, Azure API Management or APIM, as well as Networking) to check whether our use case is supported.
We found out, working with multiple support teams that such use case is not really supported right now and we were strongly encouraged to submit this idea as soon as possible on this feedback forum for potential review by the global community and the respective Microsoft teams. (Initially submitted on this forum, as of 7/21/2020)
In current model as of July 21, 2020. rules blocked by WAF in Azure Front Door charge the inbound rate even if the WAF rule blocked it. This is because the request is passing through Azure Front Door + WAF as one single unit for the purposes of billing. This is similar to how Azure CDN and all other global Layer 7 routing solutions Azure has currently works and bills when they are at the global level. This is confirmed by Azure Support as of 7/21/2020.
Either by changes or features in Azure Front Door, or via another way, this idea submission requests the implementation of a global router functionality that does not charge for inbound traffic that is blocked at the "edge" or perhaps a better term with be the "rules" level. In other words, functionality to support rules that if/when they define a block or deny state, that inbound ingress (especially) is not charged, and preferably not the egress either if possible for the blocked traffic triggered in this way (perhaps with option of a mode whether to respond to the connection, which would incur a small charge, or not respond at all, which would incur no charge. This idea submission is focused more on just the version that would not respond to the connection at all, as existing functionality in current products already processes and bills all requests and returns responses already all the time as-is â€“ however, this nuance is mentioned in case it could still be relevant for this kind of functionality to offer the option of the two at that level of the rule ).
Also, we would prefer not charge by how many times the rule was triggered per period, instead we would rather prefer to pay for each definition of these kinds of rules themselves on a per rule per hour basis or something like that (however, hopefully a reasonable pricing either way).
The preferred way of blocking this kind of traffic would be to have the option to simply hang the connection and not return a response if possible (sort of like NSG’s can do at the Virtual Network level, except to apply this at the top global level somehow), since existing functionality already can block and return a response e.g. APIM policy, even to some extent Front Door rules, etc. It is desired that this specific kind of "blocking" actually be somewhat similar to perhaps the way NSG’s block traffic on Virtual Networks (for example) that don’t match an NSG allow rule or that matched an NSG deny rule – the infrastructure just doesn’t return any response at all and there is nothing that processes the request directly when the rule doesn’t match. This is for purposes of only high level illustration and this specific example may or may not be based on exact specific working models of current Azure products, and we do not necessarily imply a specific implementation methodology in this idea submission, this specific paragraph would be intended more as a general conceptual reference and there could be likely more than one approach here.
Front Door provides rate limiting by IP, however there is only a short amount of time the IP can be throttled before it can simply send the request again. Also, what if there are some use cases where there are different users all from same IP, or even let’s suppose from another part of Azure infrastructure that has fixed IP’s? In that case throttling would not be appropriate at all. Even if everyone had different unique IP’s, the throttling is only of max limited duration, and different IP’s could continue to send very large payloads and even if blocked by WAF and throttled by Azure Front Door, even at the throttled rate if they kept sending large payloads even just from one throttled IP, it could cause the bill to skyrocket just for traffic that was simply blocked by WAF at the end.
Azure API Management does not charge by request. So one could argue we could consider using that. In fact, we would consider to use that over Front Door just because APIM doesn’t charge by ingress payload of the request, and provides some other benefits such as being specifically tailored for making API’s – so it would be a better fit for use cases we are thinking of subject to this very idea. However, the requests blocked by APIM would still be processed by APIM. In some use cases, this could affect other users of the APIM. For some use cases we’d have to crudely scale up the APIM instance to an amount so high that it would account for this rogue usage. Although APIM might provide some more advanced throttling mechanisms than Azure Front Door that could work for us, even APIM throttled requests might still have to be processed in order to return a too many requests status – this processing itself might be undesirable in some use cases. We can confirm working with APIM team (7/21/2020) that there is currently no workaround to attempt to bypass the APIM processing layer in any way, shape or form or with any kind of temporary workaround that would be along the lines of this idea submission, because all requests sent to APIM are processed to APIM. To be clear, we do not refer to requests routed through the backend through APIM, we mean requests sent to APIM endpoint itself. While we won’t be billed for payload size of ingress when using APIM like with Front Door, and while the backend will not always get all requests if we have the policies structured in specific way, no matter what, all the requests sent to APIM, even those blocked by an APIM policy, must always be processed by APIM and could affect all other users of that APIM. Moreover, Azure API Management (APIM) is not at the global layer – this introduces limitations (no matter how big the APIM instance is scaled out to and no matter how many regions) that would not apply at a global router level like Front Door. So even if the features we wanted were possible at APIM layer, there would be the global routing part missing. On top of that, APIM in and of itself does not currently support any way to avoid processing some APIM requests based on rules and not others.
One might argue we could place Front Door with WAF in front of the APIM to achieve our goals. However, Front Door’s matching engine is not so much a good fit as APIM for the use cases subject to this idea submission, and we would probably need APIM’s level of matching at the Front Door level. Moreover as of 7/21/2020, all requests, even those blocked by WAF at Front Door, will be billed at not only the per-million-request rate for the request itself, but even billed at the ingress per GB rate (currently around $0.01 or so as of this writing 7/21/2020) regardless of the fact that it was blocked by WAF and never routed through to the backend pools assigned to Azure Front Door. This is because WAF + Azure Front Door is currently treated as one single unit for purposes of billing under the hood, and therefore no workaround exists within Front Door either for this. As a side-note, Azure CDN and similar global routing offerings are working in a similar manner for billing purposes, so they also cannot be considered as an attempt to temporarily get around inbound billing as they work in similar way and are even less of a good fit for that specific use case – Front Door and APIM are the closest and it’s almost as if they were merged somehow or in some way they might form the basis of such a functionality that might fit our use cases in this idea submission.
To be able to make more informed, predictable strategy about cost in terms of specific, billing-sensitive use cases such as public API’s and even to some extent, semi-public and private API’s where this may be more important than in other API use cases (i.e. ones where current, already existing functionality is good enough), and within such billing-sensitive use cases to be able to avoid as much as possible any undesired, unpredictable results like unexpected billing for blocked traffic, we would like to request the implementation of a global router solution similar to the elements above that combine Front Door + APIM which would have the ability to cause inbound traffic not to be billed. This in summary might be something like just APIM itself having a global layer like Front Door does but using APIM instead as the engine – plus an NSG-like-for VM’s-except-at-the-global-layer blocking option somewhere which would cause requests not to be processed but not bill them either, so not quite like WAF works right now with Front Door, a bit different from that. However, the aforementioned statements are for conceptual reference only and any actual specific implementation methodology is not necessarily indicated in this idea submission.
Thanks for considering this idea.
By the way:
To be clear and complete, if you are wondering why did we not mention Traffic Manager here or consider Traffic Manager instead of Front Door? Well, while Azure Traffic Manager could be considered a global routing solution at the DNS level, it does not have a rules engine that matches by specific things like paths, etc. In fact as of 7/21/2020, the Azure Traffic Manager routing methods are Priority, Weighted, Performance, Geographic, Multivalue, and Subnet – Traffic Manager does not match by things like specific paths, or API keys, or anything like that. Azure Front Door and APIM both provide a particular kind of rules engine which is for different use case than Traffic Manager and is intended for use cases like routing to different backends based on specific conditions being matched like path, API key, and more. Where Traffic Manager actually might be more appropriate for something like the use cases subject to this idea submission, might possibly be as one or more of the backend endpoints to something like this global router solution (as one of many potential approaches), however Traffic Manager by itself does not match by things like API key, by specific paths, etc.