Sunday, October 7, 2018

AWS pricing model

Many organizations have adopted cloud services as an inherent part of their IT infrastructure.  With the cloud infrastructure, the upfront capital cost is not needed. One can hire services on a need basis. However, one still has to be careful about the cost that gets incurred as part of hosting the IT infrastructure on the cloud. Every second service is up and running, it makes the dollar meter to rotate.

Among the major cloud providers, AWS is one of the preferred once. In this blog, we will look into a higher-level model of understanding the various parameters that affect pricing. We will not look into individual services but will build a higher-level model. Not all the parameters will be valid on all kinds of services but this will help in understanding the costing model of AWS against individual services.

Configuration type 
What kind of configurations of the service one is putting into service drives the cost. For example, in EC2 or RDS service, if one is using micro or a medium instance. In the case of Lambda, it is the memory that one is allocating for the lambda to run. Using the minimum configuration may not be the right thing to do always. For example. in the case of lambda, a low memory may result in the lambda to run longer. In the case of EC2, if an application is hosted on it the user experience may not be good. So choose your configuration carefully.

There is also flexibility in terms of how one demands the instance. If one knows that a certain server is required for 24x7 for the whole year, better to reserve that upfront. The price reduces. Spot instances can also be asked for which are much cheaper but go through bidding. 

The other parameter that impacts pricing is the duration of a run. How long the service is up. It's better to shut down a service when the task is done. For example, an application that is not needed to be up 24x7 and is hosted on an EC2 can be shut down when not needed. Lambdas runtime duration depends on how long the lambda invocation takes. IoT charges on the minute of connection times.

Number of executions
The charge is applied based on the number of executions. Lambda is also charged with the number of executions. IoT is charged for the number of executions in terms of the number of rules fired. S3 is charged based on the number of gets, puts, post, etc.

Data transfer
The charge might be done based on both inbound and outbound data transfer. Some services don't charge for input transfer. The details vary based on the type of service. Usually, the charge is based on GB of data transfer. 

Storage is charged based on the amount of data and usually in GB. Size your service carefully for the same. Even if you are not using storage and if you have provisioned it, the charge will apply. For example, the default setting for cloud watch logs is to retain them infinitely and with time the storage need will keep on increasing. It is prudent to retain the logs to a point that serves the business audit needs. 

Monitoring Level
AWS provides basic monitoring on the services however if one wants enhanced monitoring but that means more dollars.

Provisioned capacity 
For some services once can buy provisioned capacity upfront. This helps in making the applications to run smoothly and handle spikes but also means more cost.

The different parameters above will help in understanding the cost model better. A combination of the above is used to charge for a service. For example, the lambdas are charged for duration and number of executions. If you can think of more parameters that can help to understand the cost model better, please do drop a note in the comment area.

AWS provides a cost calculator also which can help in estimating the costs. The calculator is hosted at

Image reference: Pixabay

1 comment:

  1. Good introductory is very complex topic. Look forward for more from you on this. There are many tools also available, and special purpose start ups have been spawned to improve RoI on AWS...such as CloudCheker...