Amazon just sent out the following annoucement

Announcement: Announcing Combined AWS Data Transfer Pricing 

Dear Amazon EC2 Customer,  

Starting April 1, 2010, your Data Transfer Out pricing tier for a given Region will be based on your total Data Transfer Out usage within that region for Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon SimpleDB, Amazon Relational Database Service (Amazon RDS), Amazon Virtual Private Cloud (Amazon VPC), and Amazon Simple Queue Service (Amazon SQS). Until now, usage tiers have been calculated individually for each service, based on data transfer related to that service. Because AWS is now aggregating your total Data Transfer Out usage across multiple services, you can reach higher usage tiers and lower pricing more quickly. In addition, you’ll benefit from a complimentary tier which provides your first GB of outbound transfer in each Region each month at no charge. 

The tiered pricing for Data Transfer Out is as follows for each Region: 

First 1 GB of data transferred out per month is free

Remainder of first 10 TB per Month: $0.15 per GB

Next 40 TB per Month: $0.11 per GB

Next 100 TB per Month: $0.09 per GB

Over 150 TB per Month: $0.08 per GB

As you may know, all inbound data transfer is free of charge until June 30, 2010. All data transfer usage (both inbound and outbound) for participating Amazon Web Services now appears in aggregate in its own section of your AWS account activity page and monthly bill. As a bonus, you’ll notice that your first GB of outbound data transfer in each Region is now included free of charge. 

As always, thank you for your support. 

Sincerely, 

The Amazon EC2 Team

That’s great for users for the Amazon Web Services, but it also means that I have to change some of my algorithm. When I do price calculation I use the cumulated Data Transfer of a given service to check for price tier change, but only within that service. Now I will have to  check across all services. The problem is that I calculate one service at a time so I currently only have the cumulate data transfer when all services are loaded. So I guess I now need to make it a two-pass algorithm….Pass 1: load all usage entries for all services…Pass 2: calculate Data Transfer Out pricing for each region. The other problem is that it also takes into account the Virtual Price Clouds which I don’t aggregate currently…

This tells me two things.  First I should release a first version that doesn’t do any price calculation, but just shows the usage types. I think showing the pricing is essential as it allows to compare two services that have different usage types which is great to compare services of different nature. Secondly, I need to work on my pricing engine and adapt it to this recent change and make sure I can really calculate the prices of each of the service. 

What’s fun with creating a product is that there are many ups and downs during the development cycle and there are many doubts along the way and many questions. I choose this product because I like using Amazon Web Services and my tool will be a great way to visualize the usage. In the doubts category…I think Amazon may at anytime provide a similar tool or change something in their data format or pa, which could make my effort void. But that’s what also makes product development fun. 

So today I shall first add support for High-Memory EC2 Instances, then I will consider making one version that just shows aggregated usage data and not any pricing. 

11:05am Ok, Added the High-Memory EC2 instances. In fact m2.2xlarge and m2.4xlarge was already there and only the low end m2.xlarge was added.

Change in strategy!

I spent a lot of energy in getting the pricing right and I am not there yet. I still think it’s doable but I need more time and more user input on different usage scenarios. Also I really don’t know the interest there is out there for the tool I’m building. You may ask why I didn’t figure that out before? Well, good question…next. But seriously, I was ready to spend a few weeks of development time to get a great product and then figure that question out. Now it seems that it will take me way longer to reach that point, so I may as well change my strategy…Here goes the new thinking. I should be able to provide a nice utility that allows to visualize the usage reports without providing the price calculation. I think the price calculator will be crucial and key to ask for a higher price for the product, but even without the price calculation the tool will be useful. So the new strategy is to provide a low cost version that doesn’t have any price calculation built-in. This will allow me to figure out the interest people would have in buying such a product as well gather good feedback on what users really want.

Now let’s think about not showing pricing…see if that would still be useful. I have three main screens for a period: 1) Billing Period Summary 2) Dashboard 3) Breakdown. The summary screen wouldn’t make sense without any pricing. Maybe a few details regarding usage could replace it. For the Dashboard the first four diagram show pricing information  (price by service, cumulated price by service, by day of week, by hour of day). We could maybe replace that with facts such as number of instances, zone information, data transfer. For the Breakdown the total tab shows the same summary that on billing period summary. So that needs to be replace. The ‘Total’ tab was breaking down which service costs the most, without price calculation we cannot show that information. So it looks like I will move some of the information from the dash board to the period tab just as summary information of that period.

Then each service may get a custom way of visualizing it’s usage data. For example for EC2 it would be great to show what type of boxes (windows/linux/small/large/…) was used each day. And for SQS we could show a stacked chart grouping each type of requests per day. In fact, that’s going to make the application way more compelling. All right! 

But first I will start using the Swiz framework to clean up some of the code before my refactoring. To configure it I just follow these 4 simple steps, but I won’t bore you with the technical details on this blog…I’ll bore you just with my “thoughts” while I code this application.

09:15pm Not yet complete with the port to Swiz. Now I’m pretty excited about this new direction, besides the fact that I should have started there!

That’s all for today.