ailon's DevBlog: Development related stuff in my life

More on Cloud Storage/CDN pricing

2/21/2012 3:26:02 PM

I’ve blogged about my attempts to understand the cost structure of serving (publicly over HTTP) large amounts of small files from Azure Blob Storage (or CDN for that matter). It was more complicated than it had to be and I’m still not sure I understand the reasoning behind it, but at least the answer was clear – you pay for both bandwidth and transactions if you serve files publicly from Azure Blob Storage.

Last week I had a pleasure to attend TechDays Belgium and I just couldn’t miss an opportunity to communicate my feedback on this issue to Scott Guthrie himself. I’ve also talked about it with Windows Azure MVPs Maarten Balliauw and Panagiotis Kefalidis. The funny part about this – they all start their responses with …

… but transactions are dirt-cheap!

Even though my beef/confusion is with pricing structure rather than actual costs, let’s get this “cheap” argument out of the way. Suppose you serve 100 millions of ~7kb files out of your blob storage per month. This could be design elements of your site, your CSS or JavaScript files or small banner ads (in my case). CDN would probably be a more appropriate solution for these scenarios, but the pricing structure and costs (more on this later) are identical so it doesn’t matter in this context.

Let’s see… We serve 100 million 7kb requests. That’s roughly 700GB of bandwidth. Since the pricing for North American and European bandwidth differs from rest of the world, let’s assume that 500GB goes to NA/EU and 200gb elsewhere. By entering this data into Azure pricing calculator we get this:


Transactions would cost us approximately as much as bandwidth. So no, transactions are not dirt-cheap. At least not in all scenarios.

But it’s not about the price - it’s about pricing structure

It took me a while, but now I understand how these things are priced. What I don’t understand is why? The most often repeated selling point of all the cloud services is “Pay for what you use”. So forgive me if I want to understand what I use when I’m billed for transactions. I understand that storage space costs something, I understand that bandwidth costs something, but I don’t understand where is the cost of “transaction”. It looks just like a HTTP request to me and for some odd reason I don’t get billed for HTTP requests to my web roles, huh? Does it cost Microsoft twice as much to serve 700gb in 7kb files than 700gb in 700kb files?


Don’t get me wrong, I’m not saying that there’s no cost associated with so called transactions. I’m just saying that it’s not communicated well enough.

What about CDN?

It was suggested by Maarten and Panagiotis that there are no transaction costs for CDN. I was pretty sure that we’ve researched that option and there was a transaction cost too, but who am I to argue with 2 Azure MVPs ;) Back home I’ve checked that I was right and that there is a very good reason why they thought otherwise. Here’s how the CDN portion of advanced pricing calculator looks:


Yep. No slider for transactions. When you hover the “?” you start getting some hints:


And only when you click the “Learn more” link it becomes crystal clear:


So, WTF do you want, Alan!?

Well, when I’m sold into “pay for what you use” model I want to actually understand what I use. And as I mentioned above it’s not very clear to me in this case. To be honest, I think the only reason why this pricing structure exists is because it was just copied from Amazon S3 in the early days:


and for CDN:


Except Amazon calls transaction “requests” which is way more clear in my opinion. Other CDN providers like CacheFly or MaxCDN/NetDNA don’t charge for transactions/requests (at least at the first glance).

So, most of all I’d like to see the transaction/request costs go away even if it doesn’t make the service cheaper overall. I don’t care how big margins on the bandwidth prices are as long as the end price is competitive. I would understand that I “pay for what I use”. Unfortunately this would skew the total costs for different scenarios dramatically. So I don’t expect it to change in a foreseeable future.

At the very least I would like to see this cost structure explained clearly. I figured it out but it took me some time and from conversations I had on twitter it’s pretty clear to me that everyone except those who are deep into Azure (MVPs, MS people) couldn’t answer my question by just looking at the site.

Here’s my feedback on what could and should be improved (if changing the pricing structure is not a feasible option):

  1. Explain what “transaction” is and why it is billed. Why are public HTTP requests to the Blob storage billed and HTTP requests to the Web Role are not? (I think “request” is a much better word saving a lot of explaining.)
  2. Mention public HTTP blob serving scenario explicitly. Billing in public HTTP blob serving scenario is confusing in the current state of things. Use of the word “transaction” clearly doesn’t help.
  3. Include a transaction cost slider in the CDN portion of the advanced pricing calculator. It’s really confusing currently and looks like a hidden cost. Even Azure MVPs were fooled by it. It’s obvious that mere mortals would be too.

So, this is what I think. I know it looks like a rant, but I just want to make the product better and provide feedback from the average customer’s point of view. This cost structure makes Azure and Amazon CDN (and storage) services unattractive to projects serving large quantities of small files and I’m just not sure that there’s a good reason for Microsoft and Amazon to shut these customers out.


The Intricacies of Azure Blob Storage Pricing

1/16/2012 6:50:42 PM

We are in the process of designing new major features for AdDuplex. So we were discussing some implementation/architecture choices for a future release. Part of the implementation we were planning to pursue included serving of content directly from public container in Azure Blob Storage over HTTP.

Since Azure (as most of the Cloud solutions) is a “pay for what you need/use” type of arrangement we had to look at pricing for Windows Azure Blob Storage and decide if our proposed implementation was the best choice from the cost effectiveness perspective.

The price for the blob storage consists of 3 components: storage space, bandwidth/traffic and transactions. Space pricing is clear, bandwidth pricing is clear, but what is transaction??

The explanation next to the transaction slider in the pricing calculator doesn’t help much:

You pay based on the average amount of data you store during a billing cycle and the number of read/write transactions you make to it during that period.

Again: what’s the definition of transaction in this context? Browsing the Windows Azure site doesn’t help much.

The most comprehensive resource on the web (at least the one I was able to find) explaining Azure Storage billing in detail is this blog post by Brad Calder from 1.5 years ago. Let’s see if it helps.

We finally have some definition of transaction:

Transactions – the number of requests performed against your storage account

Judging by this succinct definition we may conclude that we should consider each request to a PDF we’ve posted publicly to the blob storage as a transaction. OK, but let’s read further (emphasis mine)

Each individual Blob, Table and Queue REST request to the storage service is considered as a potential transaction for billing. Applications can then control their transaction costs by controlling how often and how many requests they send to the storage service.

OK, so if I place a PDF into blob storage and it is accessible publicly as and then it’s picked up by and linked from there, there’s no way I can control “how many requests I send to the storage service”. So I would guess this case should not be a subject to transaction billing.

Then we have this:

Each and every REST call to Windows Azure Blobs, Tables and Queues counts as 1 transaction (whether that transaction is counted towards billing is determined by the billing classification discussed later in this posting)

Again, there’s no definition what is considered a “REST call” here, but GET request over HTTP is probably a “REST call”, right? So, by this point I got totally confused and I decided to let the twitter enlighten me. After some back-and-forth Neil Mackenzie (Azure MVP) concluded:


OK, I believe Neil, but how am I supposed to know that someone accessing my public file is “A single GetBlob request to the blob services”? Still, at this point, I was convinced that each such request is basically billed twice: once for the bandwidth and the second time for transaction. But just to make sure I decided to make an official support request to clarify this once and for all and I got this answer:

As discussed over the call every single request coming to our blob is considered as a transaction. Hence we count this transaction as a storage transaction and this component will be shown in the invoice.

So, there you have it. I’m not sure if the concept is logically flawed or just a structured way to charge you more, but I’m sure it has to be explained in simpler terms and definitely cover this simple public blob scenario.

Don’t get me wrong, I understand that if there’s a cost associated with each transaction someone has to pay for it. It’s perfectly clear with bandwidth or storage. You can argue about the prices, but it’s pretty obvious it costs something. But with these “transactions”… I don’t know. I need more clarity.

What do you think? Is this a logical billing structure? Do you understand where’s the per-transaction cost to Microsoft that is then passed to you in this scenario? Should you be charged a transaction fee for each request of a public image on your site? Honestly, it doesn’t make much sense to me.


How to transfer your Azure site to another subscription

7/14/2011 6:43:15 PM

Microsoft is pushing Azure and I, as many other developers, get access to it through different programs. Some of them are better than others, some expire, etc. So I had a need to transfer all of my used Azure services and data from one subscription to another.

I mentally approached this as some sort of IT admin task and was planning migration strategies but then it hit me that it could be just a switch on the Microsoft’s side specifying which subscription “owns” particular services. This turned to be true but wasn’t easy to discover so I decided to document the process for future reference.

  1. Go to Azure support site
  2. Click on “Billing Support
  3. Select support topic “Transfer Subscription
  4. Select sub-topic “Transfer Azure data to different subscription
  5. Click “Continue
  6. Select contact method “Web form” (unless you want to call) and click “Continue
  7. Now you will have to fill out the details form with your Live ID, contact information, etc. The key part here is specifying your source and destination subscription IDs in the appropriate field
    These can be found in the Windows Azure Portal. Click on the “Hosted Services, Storage Accounts & CDN”, click on “Subscriptions” (or Hosted Services will do too). Now select a subscription (the top item in the tree view) and in the properties on the right you will find “Subscription ID” field in the form of GUID. That’s what you need.

Now you just submit the form and wait. A “Support Professional” will be assigned to your request and will handle everything from there. All in all it took less than 2 days (including some questions I had) to completely move my web roles, storage accounts and SQL Azure databases without any noticeable downtime. Much easier than I anticipated.


Copyright © 2003 - 2018 Alan Mendelevich
Powered by BlogEngine.NET