Here, I will attempt to bring to fore some common types of cloud models on offer and related points .

Reserved Instance (RI) Model: When an organization has done its homework with regards to the kind of workloads it wishes to place on the public Cloud, the associated resources (aka Capacity or Instance Type – configuration of VMs like CPU, Memory, Storage and Networking type) it would need to run them can be spelt out in a definitive way to the Cloud Provider (CP), the duration needed for this service and is willing to commit for this, then this RI Model will work best if the duration is long enough say between 1 to 3 years. Further, if the need is for a specific region only, planning and specifying could be a good thing as it may reduce cost. With a budget in mind, the organization could negotiate well with the CP and could expect good discounts as a result of this predetermined commitment – capacity and duration. However, one has to be clear that the commitment period once signed for, cannot be terminated early without some grief such as hefty fees. Further, in case the capacity is underutilized, there will be no discount and full fees will be charged. In case sometime in future, the same capacity becomes inadequate, there will be additional charge for overage or  increasing capacity which, at times during negotiations, are not looked at carefully and hence the ramifications not realized upfront clearly. This needs to be carefully read, understood and negotiated as well and doing this kind of changes often will be counterproductive to the organization for obvious reasons. Continuing further, changing combinations constituting instance type mid-stream will be problematic. Also the region type needs careful consideration for the term as it will come at a price if the footprint increases. Making substantial payment upfront for this results in good discounts, but a big reason for cloud adoption has been smooth even payments without much upfront costs. Occasionally a conversion option is provided if the organization wants to opt out of RI Model and opt for a different model, but the discounts will disappear quickly and could be lower had the organization had opted for it in the first place since the organization now is a captive client and loses on some of the initial bargaining power. 

Pay-As-You-Go (PAYG) Model: As the model name suggests, it is for those organizations who don’t prefer commitment. In this model, the organization prefers a very high degree of flexibility of  the capacity (combination constituting the instance). Hence the organization pays for only what is needed and the billing is often done on hourly or minutes basis. A possible use case could be when the organization is experimenting or involved in some very short term objectives for which it does not anticipate lasting long – say for an event and related computing needs. For this model, generally there are no upfront costs to bear and while billing is as per usage, it may be a bit higher – after all commitment phobia has a cost :-). Organisation must monitor closely the usage as while idle time will not increase the bill but why pay when idle. Further, and more importantly, if there is overage then the bill value is likely to escalate. Further, look at if there is a peak usage surcharge put by the Cloud Provider. Additionally, PAYG costs vary from one region to another. To conclude, PAYG is a very good option for a few use cases but the billing should be closely monitored.

Spot Instance (SI) Model: If PAYG model is where the client organization does not prefer commitment, the SI Model is the opposite where the Cloud Provider (CP) is free to withdraw and interrupt allotted VMs if required by it. This of course comes with discounts as interruptions are acceptable by the client. While the organization is given a discount for this kind of service, the cloud provider also gets to use pockets of spare capacity, thus a win-win for both. In this model, the organization chooses this model when their workloads are interruption tolerant and can recover gracefully. For example, batch processing jobs are designed to work with failures of service and hence can be a candidate. Further, big data analytics and machine learning workloads are also similarly designed as they can last a very long time to complete and are built to be fault tolerant. As the cloud providers would rather have committed users, the pricing, though discounted, also varies due to supply and demand situations. Further, there are quite a few creative pricing models in use such as bidding and thus requires closer scrutiny from this point of view.

Tiered Pricing Model: Recall when I clarified that a  resource or capacity is nothing but instance type which is a set of configuration of VMs such as CPU, Memory, Storage, Networking type and so on. For Tiered Pricing, the Cloud Provider incentives for more usage of higher configurations. As the usage increases, the Cloud Providers gives increasing discounts – thus the name tiered pricing. Obviously this then provides flexibility and customizations while giving some sense of certainty over the budget and the spend. In this model, understanding the pricing of different tiers needs to be looked at carefully yet again as each tier may have different SLAs including support & customer service, different levels of access & security, data storage & redundancy and so on. Hence understanding the relevant details for each of the tiers are imperative.

Per-User Pricing Model: As the model name suggests, this pricing is simply based on the number of users making use of cloud based services. This then  makes it very popular for Software as a Service (SaaS) providers due to its simplicity and transparency making the billing very easy and predictable. Also adding and removing users is usually a breeze. However, as you may know, all users are not equal and can be sliced and diced in multiple ways given the roles that may be assigned to them. Hence, it is quite possible the pricing could be role based with power users costing more than ordinary users. Further, it could be feature based as well for pricing. Additionally, there is a big difference between active users vs. registered users who might be dormant. These are some things to consider for an organization while going for this model. Finally, if the size of the user base increases, it might be prudent to go for other models.