Pricing is really bad
Your pricing model is beyond bad. Why do I have to choose between only two tiers, one being 10+ times more expensive than the other?!
Let's say I make 300.000 Maps transactions per month. In the S0 tier I'll pay US$ 25,00. If, however, I need 80 concurrent connections, than all of a sudden I need to pay US$ 1.500,00 (S1 tier). Fifteen hundred dollars! That's a SIXTY times increase in price just because I need more concurrent connections.
I think there should be a mid tier that includes free access and all (or at least most of) the features from S1. In that tier, "normal" transactions would be just a little more expensive than S0, but special features like "Hybrid Imaging" would be more expensive than S1. Or maybe you have to pay for extra concurrent connections (I don't know where that 10 times increase in price is coming from, of course, so yea).
After careful review we have determined that the scenario outlined is an edge case that does not align with the overwhelming majority of customer use cases. Note that in order to achieve the stated QPS of 80, the user would need to generate all 300,000 map tile transactions in a 16 hour period in a month. Where as the majority of customer scenarios generate all transactions within a 6 hour period of a business day which works out to 120+ hours in a month. As such, the described scenario is generating 7.5 times more requests per second for the stated volume of usage than nearly any other customer would.
I'm a bit confused as to why you need 80 queries per second for such a small volume of usage. I forgot to include 15 tiles per transactions in my previous calculations, however, taking that into consideration it would only take 16 hours to generate 300k map tile transactions at 80 qps and 25 hours at 50 qps. Assuming you use 80 qps, there would be 704 hours in the month where your application generates no usage but our platform would have to have machines on standby to support that 80 qps. Granted I understand that most companies generate the bulk of their usage during business hours, but still, at 80 qps, this would be less than an hour a business day. Are you certain your app requires 80 queries per second?
Note you can use multiple skus and have two keys. One S0 and one S1 (when needed). Thus giving you free limits on the core services. With this in mind, you would only need the S1 sku for the 30 additional queries per second, 3/8 of the requests. This would bring the total cost below $600.
Also worth noting that in addition to the free limits on the S0 sku, Azure also has free trials and if you are a msdn subscriber some subscriptions get additional free Azure credits.
For completeness, Google maps charges $5.60 per 1,000 dynamic map loads. A Google maps map load is roughly equivalent to 1 map tile transaction. Also, Google used to have a cap of 50 queries per second as well. Not sure if that is still the case, but it was never really documented. If you went above it the cost was $1,000 per additional qps needed a year. This was before their price increase.
Looking at live traffic data from years of use on one of our previous map platforms, less than 10% of accounts exceed 50 queries per second and most of those that do are generating millions of requests every day.
All that said, we are reviewing the pricing. Azure maps only had one sku until this month, so there is a good possibility others would be added in the future. This is good feedback for the finance team to investigate.
André Silva de Jesus commented
Just to clarify: as the last sentence in my suggestion says, I don't know where that 10 times increase in price is coming from. If it's from concurrent connections, then _that_ should be pricier in that new mid-tier. If it's from another feature (like Hybrid Aerial Imagery Service), than _that_ should be pricier. Anyway, my point is, as I've said before: I don't want to go from $25/mon to $1,500/mon just because I need Polygon from Search or because I need a few more than 50 concurrent connections for maybe only a few minutes.
We were considering switching from Google to Azure Maps but, for now, this pricing model is the worst I have ever seen.
André Silva de Jesus commented
Of course it costs more. That's plenty obvious. Have I asked anywhere in my suggestion for more QPS to cost the same? If you take the time to read my entire suggestion, you'll see that I have actually suggested creating a new tier, which price would sit between S0 and S1. As I said: I don't think it is reasonable to have two tiers which prices jump from twenty-five dollars to more than a thousand dollars _with the same usage_.
BESIDES, concurrent connections was just an example. I even thought about using something else as an example fearing that comments like that would pop up... Anyway. Remember that there are tons of other features that won't be available on S0 like Batch Geocoding, Polygon from Search or Route Range.
Supporting higher queries per second requires having more hardware in reserve which costs more. Note, with S0 you can make up to 50 queries per second, thus process 300,000 requests in just over an hour and a half.