Hidden Costs of Cloud-based Courseware

So, you’ve decided to migrate your on-prem virtual training environments to the cloud.

You know all about the benefits that the cloud has to offer over on-premise infrastructure, and are looking forward to reducing your capital expenditure, taking the burden off your IT team’s shoulders, and being able to scale your operations up or down instantly, according to your demand.

You carefully compare between commodity cloud providers, plan a budget according to detailed cloud pricing calculations and usage forecasts, and then migrate your environments to the chosen provider.

At the end of the month you get the bill from your commodity cloud provider and you’re shocked to see that your planning was off, and that the monthly bill exceeded the budget you planned by tens, if not hundreds of percent.

You’re not alone.

“Bill shock” is a common phenomenon among those new to the cloud. Why does it happen? How can it be avoided? What can be done to precisely forecast your budget? We will answer these questions in this article.

Data Transfer

Every bit and byte on the move, whether originating from your infrastructure or directed towards your infrastructure is metered by your cloud provider, and varying rates are applied.

Since it’s in the clear interest of your cloud provider that you transfer your data into the cloud, they won’t usually charge you for traffic you upload to the cloud.

In rare cases when they do, it will be a very small charge.

With AWS for example, data transferred onto your cloud infrastructure from the outside is free, as is most data transferred to your infrastructure from within AWS.

If using a public or elastic IPv4 address for intra-cloud data transfer, or if using an IPv6 address from a different VPC, then the rate is $0.01 per GB. All of these are essentially free, but complicate the tracking of data transfer costs.

Avoid “Bill Shock” – Talk to a Virtual Training Expert Today

The case is different for outbound traffic though.

Since your cloud provider is interested in keeping your data in the cloud, outbound traffic has significant cost implications.

The highest rates are charged for data transferred outside of your commodity cloud provider’s realm, for example, when pulling your data back to your on-prem resources or when serving content to your customers.

Lower rates are charged for intra-cloud data transfer originating from your cloud environment. AWS, for example, charges $0.09 per GB of data transferred from your environment to outside of AWS for the first 10TB transferred each month, after which the rates gradually drop as you transfer more data each month.

This may seem like a small fee, but in cases of technical training where masses of outbound traffic are created, for example when simulating disaster recovery, database backups, or cyber-attacks, to name a few, it accumulates and can become a very significant cost factor.

Unused IPv4 Addresses

IP addresses are a rare resource nowadays. The relatively new IPv6 standard is meant to solve this IP address congestion; however, most of the Internet still uses IPv4 addresses.

Commodity cloud providers offer an elastic IP address service, which dynamically assigns IP addresses to your virtual machines. This way, you can get IP addresses assigned to your cloud account, which you then need to associate with one of your machines.

In case of machine failure, you can reallocate that IP address to another operating instance, and keep your service uninterrupted and reachable from the Internet.

Elastic IP addresses are generally provided free of charge, but since they’re a scarce resource, commodity cloud providers aim to make sure they’re used efficiently and that users return IP addresses which are not used.

Therefore, they impose charges when they’re utilized inefficiently.

With Google Cloud Platform for example, IP addresses are free, but if an assigned address is not used, Google will charge you $0.01 per hour per unused address.

AWS, with a similar pricing model, also adds charges for reallocating assigned IP addresses between instances (beyond 100 monthly reallocations.

In contrast to the former two, Microsoft Azure doesn’t provide free IP addresses at all, and charges $0.004 per hour per IP address used, and the same hourly charge for assigned IP addresses, whether used or not.

Orphan Storage Volumes

Some virtual instances come with ephemeral storage, i.e. storage that is built into your instance, and vanishes as soon as you de-provision the instance.

In order to keep your data even after turning off a machine, you must use persistent storage devices which are attached to your instance.

This persistent block storage volume is essentially an “attachable/detachable” hard drive you can connect to a provisioned instance and disconnect when that instance is turned off.

When estimating a cost model for your infrastructure, the cost of this storage is sometimes overlooked.

The greater challenge is when detached storage volumes are “forgotten” and never re-attached. This can happen, for example, when shutting down a training environment by releasing its instances, but overlooking the release of their attached storage volumes.

The environment might then be brought back up with a new storage volume, leaving the older one on the shelf to accumulate costs.

In AWS for example, charges for AWS persistent block storage service (Elastic Block Storage or EBS) range from $0.05 per GB per month for simple magnetic storage volumes, up to $0.125 per GB per month for SSD storage with provisioned IOPS.

Even if storage volumes are accounted for in your calculation, there are additional charges, like $0.05 per million I/O requests in magnetic volumes, or $0.065 per provisioned IOPS per month.

Idle Instances

The final hidden cost factor is the most unpredictable one, as well as the most price-significant one.

It has nothing to do with the actual cost estimation of cloud resources, but rather with cloud usage behavioral patterns of your employees and IT staff.

Users who are accustomed to the on-prem mode of operation will, when getting a resource allocated to them, hold on to it, whether utilized or not. Traditional IT costing simply doesn’t account for poor utilization of on-prem resources.

Therefore, there is no incentive to return resources to the general pool. In the cloud, however, provisioned resources’ usage time is metered and charged for, regardless of whether they’re utilized or not.

This is similar to forgetting to turn off the lights when leaving the house or office — the electric company will still charge you for energy consumed, even if the light wasn’t actually used.

Dodge Cloud Sprawl with CloudShare’s Auto-Suspend Feature – Learn More

Forgetting to “turn off” your virtual lab environment means that it still accumulates costs for every hour that it’s available. For example, a 4-hour lab ending at 18:00, but not turned off until 10:00 the next day, accumulates 16 hours’ worth of “empty” charges, making that specific virtual lab cost five times (400%) more than what it should have originally cost.

Likewise, if a similar event occurs on a Friday, and you only realize your mistake after the weekend, you will accumulate 64 hours of “empty” charges, or 17 times (1600%) more than the virtual lab should have originally cost.

Summary

Building your virtual labs from scratch using commodity cloud infrastructure can lead to unexpected costs, sometimes doubling (and even tripling) your initial cost estimation.

This is due to “hidden,” or overlooked costs which lead to higher-than-expected cloud bills, as well as cloud sprawl, which is amplified when using cloud resources for short periods of time.

The high complexity creates difficulty in estimating the true cost of a virtual lab.

When considering migrating your virtual lab environments to the cloud, you should consider another option: specialty virtual training lab providers, such as CloudShare.

These provide you with clear pricing, sometimes as simple as GB-hours of RAM consumed, where all other cloud costs are already factored in.

Some of these providers understand the risk of cloud sprawl in short-running workloads and offer an auto-suspend option, sensing when your virtual lab environments are idle and automatically shutting them off.

Aside from the financial aspects, specialty virtual lab providers are focused on providing virtual labs for traditional on-premise applications.

Thus, they often enable complex environment architectures, which are at best extremely difficult, and more often impossible, to implement using commodity cloud providers.

Don’t Make Beginners’ Mistakes! Talk to a Virtual Training Expert – Today!