The Cloud Budget Buster Gotcha’s; A Primer on Cloud Cost and Complexity Creep, Part III
Companies may think that if they account for all their compute, network, and storage costs as well as the overhead associated with managing the virtual private cloud that they create in the cloud service provider’s cloud that they will have this cloud thing licked. Unfortunately, companies must still account for other budget busters in the cloud that are more difficult to anticipate and forecast than these items. In this third and final installment of three on controlling cloud costs and complexity, I examine how “forgotten” services that remain running in the cloud can incur unexpected costs as well as how prolonged DR tests and/or recoveries can quickly bust a company’s cloud budget.
The Budget Buster Gotchas
Even when companies properly forecast the costs and complexities associated with their VPC management overhead, storage usage, data transfer rates out, and how many, how often, what types of VMs that they need to spin up in the cloud to recover applications, other costs can still blindside them.
For instance, VMs that they spin up may need public IP addresses. The good news is there is no cost associated with those public IP addresses while the VMs are running. The gotcha occurs when companies shut down the VM and do not release the public IP addresses back to AWS for AWS to re-use. If they fail to release the public IP addresses, they continue to pay for this allocated but unused public IP address. While the cost that each public IP address incurs is nominal, (about two cents per hour per public IP address,) these incremental costs incurred by oversights like this can be difficult to detect and correct.
Another even bigger potential budget buster is the cost of a test or real DR event. In either of these scenarios, companies will need to utilize new cloud compute, database, storage, networking, and potentially many other resources in the cloud for which they do not currently pay when they only store backup data in the cloud.
Adding insult to injury, they must recover and run their production data on elastic block storage (EBS) which costs more per GB than the cost of the object storage on which they store their backup data. The number of VMs coupled with the length of time that they run in the cloud and the amount of elastic block storage they use can contribute to send cloud costs for these DR events into the stratosphere.
These difficult to detect charges can mount over time while the periodic test or real DR can result in unexpected, eye-popping numbers. Combined they can result in companies spending much more money per month than they budgeted unless they actively monitor, audit, and understand their AWS billing statement for services usage.
Most companies will likely have neither the time nor the expertise for this type of ongoing, detailed billing analysis. Further, they may also not necessarily take the time at the outset to forecast how much a test or real DR exercise in the cloud will ultimately cost or even know how to accurately forecast for these two types of DR events.
