Even more, some have an empty region like Windows Server license cost which at least IMHO is not very consistent. And then you have resources which have a “global” region like IP addresses, which makes some sense but is a bit difficult to use, but because you need to know that this is the case.On a related topic, some (most?) resources are available only in consumption as there is no dedicated reservation pricing.Instead you have to get the virtual machine price and add the license to it. But you can’t query for reserved instances for prod. You can query for regular consumption (“prod” pay-as-you-go pricing), dev/test consumption and reserved instances for prod.You get first results very quickly but the following four topics had me struggling: Fortunately the Retail Rates Prices API was released in September 2020 which allows you to automate the queries. Using the Azure pricing calculator for a single of very view configurations is fine, but if you want to calculate a lot of configurations (in my case 8) in different variations (in my case 24) it becomes cumbersome very quick and if you need to make changes, it’s quite annoying and error prone, at least for me. The TL DR for part one: The Azure pricing REST API If you are only interested in the latter, you still might want to read the TL DR for the first part (see immediately below) and then skip to the second part. The second part will cover the implementation of my tool in Deno. Therefore this will be a two-part blog post with the first part about the Azure pricing API, technically not very interesting, but my lessons learned are maybe useful if you want to get started on it quickly. For an upcoming service offering I had to calculate the expected cost for the Azure services we are going to use and I wanted to give Deno a try for quite some time as well as developing in a VS Code dev container with WSL2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |