Cloud Hosting Costs: How to Monitor Them When Scaling Your Infrastructure


Cloud Hosting Costs: How to Monitor Them When Scaling Your Infrastructure

While there are plenty of reasons to move your software solutions to the cloud (digital transformation being just one of them), an important aspect that can often prove challenging to customers is the industry’s apparent failure to come up with a simple, unified pricing system — a problem which regrettably leaves many customers in the dark. This cloud expense limbo, so to speak, means clients may be unaware of the actual extent of their cloud hosting costs, being met with unexpected charges only weeks after completing their move.

In reality, however, without adequate preparation, migrating to the cloud may be even more expensive than your current on-premise infrastructure.

So to help shed some light on this subject, today, Software Planet are presenting readers with a few invaluable suggestions to ensure our customers make the switch without a single fuss or hitch.

What are the main costs of cloud hosting?

When examining cloud hosting services, it is crucial to have a fact-based and well-rounded current understanding of the scale of your existing day-to-day IT operations. For this reason, we recommend performing an audit of your in-house infrastructure, as this not only should reveal a detailed breakdown of your local expenses but also how these costs will be likely to change when migrating to a cloud environment.

On that note, by the way, in order to generate the most accurate results, you will have to take account of both indirect and direct expenses:

Direct cloud hosting expenses:

As the name implies, so-called direct expenses should be the easiest costs to calculate, as they will always hit you directly on your business’ balance sheet. These encompass both hardware and software expenditures, in addition to your local operational upkeep.

In theory, therefore, to find them, all you have to do is pull up relevant records and invoices: local servers, software licences, maintenance contracts, supplies and materials. At the same time, however, remember to tally up the cost of labour to maintain your database — as well as internet, servers, required staffing and rent.

Indirect cloud hosting expenses:

Though somewhat more complicated to work out, as each and every company will have their own individual circumstances, indirect expenses are just as vital as their straightforward counterparts. Of these, however, the most important factor to bear in mind is the disruption of operations that is caused by server downtime.

So to calculate how long your company can afford to stay offline — and how much money it will probably take to get everything back up and running — you will have to examine log files and consult with employees and customers.

If you are then able to convert that data into a significant loss of revenue, then this too, of course, should be included in your final tally.

Are there tools available to predict cloud hosting costs?

Once all these details have been appropriately gathered, you can easily make use of one of various online calculators to understand your potential cloud expenses and compare them with the status quo. Check them out in our list below!

Cloud server hosting costs: what are some ballpark figures?

But before going down that potentially pricey route, make sure you have explored whatever free options may be available to you. Some cloud providers, for instance, offer so-called “free tiers,” which are totally complimentary packages of services provided on either a temporary or permanent basis — see Amazon and IBM’s free tiers for more information.

Just remember: most businesses will be unable to rely on this freebie forever, as they are likely to exceed their provider’s set limitations.

Cloud providers compared 

For a more comprehensive understanding, in the following presentation, you will find an infrastructure analysis that we conducted for one of our clients. It consists of a cost comparison between our customer’s existing infrastructure and the various alternative options that were available to them at the time:

What are some of the hidden costs of cloud adoption?

Of course, it is never just as simple as a single magical calculation. Because transparency policies can vary widely between cloud providers, there is a number of hidden expenses that cloud adopters should be made aware of. So with this in mind, in the list below, we have gathered some classic examples pertaining to Amazon AWS specifically:

  1. While all incoming traffic is free, any outgoing data will usually be chargeable. These fees do vary considerably depending on your selected location, so before you settle on a specific region, evaluate how much outgoing traffic your solution is likely to generate and compare your provider’s pricing policy for the available alternative regions.
  2. This factor should also be taken into account when deploying with multi-regional architectures. Although cloud service providers do not normally charge for data transfers held within the same region, they will often bill for cross-regional data exchanges, so make sure that you are prepared for any possible financial implications.
  3. Data transfers within the same region between Amazon SQS and Amazon EC2 should actually be entirely free ($0.00 per GB), but the same between servers that are located in different regions — e.g from US East (Ohio) to UK (London) — will be charged on both sides of the transfer at Internet Data Transfer rates. 
  4. Something similar occurs with the so-called hybrid cloud model, in which your infrastructure elements’ hosting role is divided between two providers. Though as long as they are limited to the same cloud environment, a number of these components will generally be free of charge (i.e. they will only interact with elements from within the same cloud environment), the minute you decide to move one of your components, or replace them with other elements from the other cloud provider, the rest of your elements will no longer be available for free, and you will have to pay for each request or any other incoming traffic. Take Amazon Simple Email service as an example: as long as your main application is hosted by EC2 (which is also an Amazon service), you will receive a monthly allotment of 62,000 free emails.
  5. You should also be aware of I/O Credits and Burst Performance, as as soon as you go over your available I/O Credits, you can expect your disk performance to grind nearly to a halt. Like always with these things, extra credit will require extra money.
  6. So long as your EC2 instance is up and running and you have used the Elastic IP service to assign it to an external IP, you will not be met with any additional charges. However, if you fail to assign it to an IP address or choose to stop the instance altogether, Amazon will then charge you for holding onto the IP for you. So stay vigilant!
  7. Similarly, if you no longer require a service, be sure to suspend it. Otherwise, your cloud provider might end up charging you for it anyway! Amazon Elastic Load Balancers (ELBs), for example, may be paired with Free Tier instances for free, but if you stop these instances and leave ELBs assigned to no servers, you will also be billed for maintaining idle ELBs.
  8. And finally, sometimes, the devil really is in the details. Just take a look at the pricing charts for Amazon S3, one of the company’s leading cloud storage services:
  • Though the Standard tier comes in at $0.023 per GB of stored data, their Standard-Infrequent Access (SIA) tier is considerably cheaper, at $0.0125 per GB.
  • In the second case, files are accessible with the same speed and parameters as what is found in the Standard package. The main difference, however, is that with SIA charges, you will also have to pay for a data retrieval fee. What’s more, depending on your tariff, a number of data return requests might also be charged differently.
Amazon S3 Standard Infrequent Access


  • Take some time to familiarise yourself with the S3 One-Zone Infrequent Access case above. Again, it is certainly cheaper ($0.01 per GB), but this option may also be significantly less reliable, as all data will be stored within a single availability zone. By contrast, any other option will keep your data in at least 3 zones at the same time. These zones are physically distant, across an entire AWS Region, which serves to greatly increase the resilience of your applications.
  • And beware of other nuances of “Infrequent Access” tariffs!
  1. Files smaller than 128KB will be charged as 128KB.
  2. The file storage period cannot be shorter than 30 days. For this reason, even if you delete your files, you will still have to pay for them as if they were kept online for 30 days.

This extreme complexity in billing models appears to be an unwanted side effect of the added flexibility of services. Still, to avoid any backlash, cloud providers do still attempt to educate their customers by enumerating pitfalls in a number of online resources. See Amazon’s Avoiding Unexpected Charges for more on this critical subject.

What about the Google Cloud Platform?

Very similarly, when it comes to hidden expenses, Google is also not immune to challenges:

  1. Choose your storage solution wisely. In Kubeflow, for instance, your storage service will automatically be set to Filestore. This includes 1TB SSD at a minimum price point of $205 a month. Yet it is important to note here that if your project requires significantly less storage — around 10 GB, for instance — by switching over to Google Cloud Storage, you could actually end up saving up to $200 per month! The opposite is true if your project is fairly large, however, as there is likely a need for frequent access in addition to rapid scaling. That being the case, in spite of any additional expenses, the default Filestore service would indeed be your project’s best bet.
  2. Don’t go over your logging allowance. Although logs can often prove incredibly useful, as you are able to check your system’s status at any given point in time, eventually, with enough time and usage, they can also be significantly expensive. This is worth pointing out because customers are provided with 50GB of free logging allowance, so without a doubt — if at all possible — it is advisable to stay within this limit. In order to do this, be sure to adjust your logging rules so that they cover only essential information. At the same time, remember to disable logging for sources which you are certain you’ll never need. You can do this by utilising the Logs Router sink rule, which is a great way to solve many log source problems. In addition, make sure you check out your system’s Logs Dashboard as well, as it will surely give you invaluable information.
  3. Make the most of custom virtual machines. If your project has a scalable architecture and you are looking to keep down expenses, it is useful to calculate the total resources that your application pods are expected to use. Next, by making use of this critical data, you can create a custom VM template that will benefit your particular node pool.
Hidden Cloud Costs - VM configuration
  1. Customise your Cloud Services. By default, there could be plenty of redundant features or other enabled requested resources. So in order to reduce your billing, it is important to eliminate this waste. As an example, you could achieve this by customising your settings for public IPs, default machine types, or even disk space in your project’s Cloud DataFlow.
  2. Don’t pay for unused resources. Keeping hold of unused resources is yet another way to rack up expenses. Thankfully, however, by simply disabling the staging environment overnight and at the weekend — along with scheduling downtime for development — you can effectively minimise this risk.
Hidden Cloud Costs - Scheduled downtime

At SPG, we have seen firsthand that by following these simple guidelines, you can reduce your overall expenses by as much as 60 percent.

Can I switch between cloud providers?

When it comes to cloud expenses, that’s really all there is to it! 

If, however, for whatever reason at all, you’re already on the cloud and would now like to switch providers, keep in mind that in spite of what some cloud players may say, it is not always possible to ensure compatibility. This tends to be the case when making use of exclusive features, so if your business falls into this category, your software may require changes before initiating the migration process. 

In addition, make sure that you are well aware of the so-called “vendor lock-in” trap, which you will find in various products such as DynamoDBAWS CodeStar, and AWS Elastic Container Service.

Why should I move to another cloud provider?

Lastly, if up until now, you had never really contemplated venturing beyond your existing cloud provider, some reasons for considering a switch could be any or all of the following:

  • Your client’s systems or third-party partners are tightly linked to a particular vendor, so moving your infrastructure to the same cloud environment could potentially improve interoperability.
  • You could get a better deal with another cloud service provider. As with every other market player, cloud providers are always striving to increase their client base. So keep an eye out for any offers, as sometimes — if you are lucky — they may just justify the actual cost of moving.
  • Not all cloud providers are created equal. If a particular provider has something unique to offer that will also, in turn, help your business to thrive, this could turn out to be a very worthwhile trade-off indeed: your loyalty in exchange for a substantial technological advantage. 

How can I get started with cloud migration?

By taking stock of your current operations and preparing your company with the right amount of research, you can escape the cloud hosting cost limbo and avoid any ungodly bills.

Request a Consultation

Related Stories

March 16, 2021

How To Build a Scalable Mobile App Infrastructure

When looking to build a scalable mobile app infrastructure, there a number of important things that you should always bear in mind.

AWS costs optimisation Cover Image
illustration for article on Amazon Elastic Block Store types