This content is part of the Essential Guide: Optimize your public cloud cost management strategy
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Your cloud bill climbs due to these five overlooked costs

AWS, Google and Azure offer tools that help users estimate cloud costs. But overlooked services, usage spikes and outages can cause actual cloud bills to far exceed those estimates.

Compared to on-premises infrastructure, public cloud computing often reduces enterprise costs. But for many organizations, it's still difficult to make objective cost estimates for public cloud deployments.

Major public cloud providers, including Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform, have tools that allow users to predict monthly cloud costs. However, the use of these cloud cost estimators doesn't guarantee accurate results; they are only as precise as the information that users provide.

From unplanned usage spikes to outages, here are five potential factors that can skew your cost estimates and raise your cloud bill.

Costs of forgotten services

The biggest cause of inaccurate public cloud cost estimates is forgotten resources and services. This occurs when enterprises don't fully consider their workload's deployment requirements. It's simple to estimate the monthly cost of a particular AWS instance or Azure storage bucket, but workload needs generally extend far beyond a single, static instance.

Various resources and services -- such as compute, storage and networks -- form cloud infrastructure. These services show up on your cloud bill as regular monthly costs, such as per-hour or per-month charges for Amazon Elastic Compute Cloud instances and Amazon Simple Storage Service buckets. But organizations need to consider other costs, as well, such as those associated with data migration, API calls and more.

cloud infrastructure components
The components of a cloud infrastructure

In addition, resource and service costs vary by region, and data duplication efforts across those regions can drive up monthly total costs. Organizations must include these additional storage, management and other costs in the cloud cost estimator tool. If you're not certain about details, like usage, run the estimator several times and use several usage scenarios to bracket the estimate.

Costs versus growth considerations

Another cause of public cloud cost estimator inaccuracies is workload growth over time. Cloud supports dynamic, highly scalable environments, but the cost benefits for long-term, steady-state usage are questionable. In some cases, it's more cost-effective over the long-term to host your workload in a local data center.

Even the most cost-effective application in the public cloud has the potential to become more costly than it would in a local data center.

When a business' application is popular, its usage rises. The public cloud can then provide additional resources -- but those new resources increase overall costs. Many public cloud cost estimates don't consider the impact of these additional resources or services during times of growth. This means even the most cost-effective application in the public cloud has the potential to become more costly than it would in a local data center.

Remember to make estimates for future cloud usage levels. Develop comparative scenarios to calculate cloud costs against anticipated growth predictions. Also, consider how alternative usage models, such as reserved instances, could reduce your cloud bill.

Costs versus seasonal or periodic considerations

Organizations also overlook the cost of short-term or variable growth when estimating public cloud costs. Workloads that render periodic or regular services, such as accounting or scientific applications, experience sudden usage spikes that increase a cloud bill.

These short-term usage spikes are a challenge to address. Part of the issue lies in a workload's architecture in the public cloud. Operations staff responsible for the workload need to properly configure downward scalability. When a spike passes, the workload should release any excess cloud resources to conserve costs.

The other challenge is to predict when usage spikes will occur, how many additional resources they'll need and how long the additional demand will last. Perform conscientious monitoring and reporting so cloud administrators can spot trends in demand and corresponding costs. Alternative usage models, such as AWS spot instances, could also reduce the cost of temporary usage spikes.

Costs of outages or failures

Outages happen, and they create disruptions that can lead to revenue loss for cloud users. These failures can also negatively affect a business' reputation -- even for weeks or months after resolving the problem.

Although there is no line item in a public cloud cost estimator for outages, weigh the cost of potential disruption against your workload's operating costs. Some organizations find the potential cost of outages too great for a given workload, so will host it in a local data center.

In other cases, the potential cost of an outage drives architectural changes that enhance a workload's resiliency. For example, some organizations might determine that it's more cost-effective to deploy a mission-critical workload across two or more public cloud regions -- despite the additional resource costs -- than to risk a potential outage.

Costs of multicloud strategies

One of the best ways to ensure redundancy and cost-savings is to spread workload components across multiple public clouds. Unfortunately, this model isn't a reality yet for most organizations, and public cloud cost estimators don't factor in multicloud deployments.

Public cloud providers continue to compete for customers, and many of their offerings remain incompatible. Vendor lock-in is still a viable cloud business strategy; consider the lock-in risks of hybrid services, such as Azure Stack. This means that public cloud providers are reluctant to show their cost estimates alongside estimates from competing providers.

Organizations can still compare cost estimates between different providers , but this requires separate use of each provider's calculator. It's also difficult to achieve a complete comparison because of the differences between providers' pricing and services. But if you want reduce your cloud bill, these sorts of comparisons can help in the long term.

Next Steps

How to control cloud storage costs

Compare on-premises vs. cloud costs for applications

Azure migration tools assess which apps are ready for cloud

Dig Deeper on Cloud pricing and cost optimization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are the biggest surprises you've seen on a public cloud bill?

What about experience with the hidden costs related to the need of managing a cloud service providers ITSM/lifecycle capabilities when sure are not mature enough?

E.g. the cost of documenting ITSM/lifecycle processes of a CSP, where such are immature?

Can you clarify your idea a little bit? Are you talking about the challenges of managing cloud-based workloads and maintaining relevant documentation into the way that cloud workloads are deployed and managed from the enterprise-side?

Sorry I missed notification about your question to my question(s).

As one example is a CSP which has no documentation of e.g. the "Server procurement process", nor doesn't provide such documentation in the single point of On-demand self-service. I.e. the maturity level of the "server procurement process" is thus very low.

I wonder what the cost of managing such CSP or such poorly mature process of a CSP then comes up to.

That's such a tough thing to quantify - it can vary so much depending on process and its weaknesses. Attempting to define or clarify such processes before making a purchase commitment, or using the services of a cloud broker (even if it's a knowledgeable in-house expert) might help mitigate those kinds of risks.
Great article Stephen! Have you heard about PyraCloud? 
From marketing team when they use internet for streaming. 
While the costs that you mention are real, they also arise for owned infrastructure as well and are rarely properly accounted for. 

If the applications are designed for cloud, the incremental costs of outages are near-zero: you just redeploy, like any other release. If you're using the same processes as for owned infrastructure, then it will be the same painful experience.

One resource that is likely to be larger than expected is test resources: cloud architected applications have continuous delivery pipelines, so that all changes are regression tested automatically. Load generation for scale and performance testing can be significant. The flip-side in owned infrastructure is either a nasty surprise when performance is poor, or, more likely, a very large over-spend (I've seen examples of 50x the required resource purchase for owned infrastructure.)