4 Strategies for Saving Costs on Your Journey to Cloud

Welcome to this part of our Cloud Deep Dive series about cloud cost-saving strategies! In a previous article on multi-cloud pricing, I shed light on the complexity of the multi-cloud market and comparison of different pricing models of major cloud providers like AWS, Microsoft Azure, or GCP. In addition to understanding the price model complexity, cloud cost-optimization is another critical aspect of maintaining an extensive cloud service portfolio.

The possibility of flexible resource booking and the elasticity of cloud architectures result in an increased potential for cost optimization compared to on-premises architectures[1]. While resource- and cost-optimization during operating a cloud infrastructure, i.e. after the transformation, have already been widely discussed and are supported by much tooling, cloud cost-optimization during the transformation is an underserved topic with huge cost-saving potential.

Organizations currently preparing for the cloud transformation, are in the middle of executing it or are just establishing their cloud strategy should already think about cloud cost-optimization since, in terms of TCO, only a perfectly cost-optimized cloud service portfolio can compete with an on-premises IT portfolio.

When should I start optimizing my cloud service portfolio?

The short answer is: immediately, it is never too early to start! However, you have to decide what is more important to you: optimize the costs of your cloud portfolio right from the start or migrate to the cloud as quickly as possible. No matter how you decide, you always have to find a trade-off between speed and cost.

Before we discuss the cloud cost saving strategies, I would like to briefly take a look at the typical cloud transformation process:

All major cloud providers like AWS, GCP, or AWS offer best-practices on how to perform the transformation. Global consulting firms and systems integrators aim to constantly optimize their practices and their processes.

Our experience has shown that every transformation has in a way unique characteristics. However, no matter which concept or best-practice is used, there are almost always five steps that are part of every cloud transformation. Each of these phases has unique options for saving costs that should be leveraged.

The Cloud Transformation process phases

The Discovery phase represents the first practical stage of a transformation journey. During discovery, all necessary data regarding the application portfolio and related IT infrastructure is collected to form the basis for cloud transformation decisions.

During the Assessment, the collected application landscape and infrastructure data are evaluated, and the cloud readiness for each application is determined. This phase is important to estimate the cloud compatibility of the application portfolio.

The five phases of the Cloud Transformation Process

Based on the Assessment results the Planning of the Target Architecture takes place. Every single application is classified, target architectures are modeled and a transformation roadmap is created. The applications to be migrated are typically divided into different migration-waves.

In the next step, the application is migrated to the cloud. During the Migration, mostly six different migration strategies are used. If you are interested in the different migration strategies, read my article about the 6 R’s Migration Strategies.

After the successful migration, the transformation process ends with the Operation & Optimization of the cloud product portfolio. After the transformation is before the transformation!

New products or, the potential for optimization can lead to new transformations - e.g. cloud-to-cloud migrations.

Cloud cost saving strategies along the journey to cloud you should know

When talking about cloud costs, underestimating ongoing cloud costs (OPEX) is a common reason why cloud transformations fall short from their financial expectations. Experience has shown that a simple rehosting strategy (also known as "lift-and-shift") without efficient right-sizing, leads to poor or even negative results in terms of optimizing TCOs. Refactoring can become even more expensive. But how can a cloud transformation be a success from a financial perspective?

Starting with cloud cost optimizations already before and during the transformation is needed to be able to reduce cloud-cost compared to on-premise cost. You should apply four key optimization strategies in the first four phases of the process. Here I am going to present these strategies that help you to optimize cloud costs at an early stage of the cloud transformation.

Strategy 1: Pre-transformation optimization through provider negotiations

This step may be taken for granted, but you should not forget to negotiate deals and discounts with your selected cloud providers. The competitors of long-term cloud leader AWS are constantly catching up, competition pushes prices downward and puts you in a better bargaining position. Providers from the APAC region are entering the market with cheap offers and force established providers to adjust their price levels. Thus, depending on your position, it should definitely be possible to get a discount here. Also, don’t forget that there are tools that help you compare prices between cloud providers.

Strategy 2: Assessment - Application disposition and retiring

A precise application assessment phase will reveal lots of information about each application in scope of your transformation effort.

Here you decide on the 6 R’s migration strategy for each application. One of the 6 R’s is “Retire”. Ideally, you can start saving money by identifying applications that can be retired. You can already reduce the effort and resources required for the assessment by taking these applications out of scope from the outset and marking them for near-term retirement.

Besides the lifecycle and technical assessment, business aspects should be examined. That might be your chance to review your application portfolio for redundancies. Analyzing which of your applications provides what business capabilities may reveal applications that redundantly provide functions. You should, therefore, use this phase to optimize your portfolio or at least, if not possible due to time constraints, descope non-relevant applications from your application transformation portfolio. It will save you a lot of money, even if the assessment can be a time-consuming task.

Strategy 3: Assessment - Migrating with business case (only)

Part of the assessment phase is conducting a business case analysis and the estimation of the cloud cost-benefit ratio for all applications. The cloud business case analysis provides insight into whether it is financially sound to operate an application in the cloud. Furthermore, some applications lead to massive costs during the transformation (due to e.g. the need for a refactoring). Basically, it has to be weighed whether the migration can be justified from a financial perspective taking into account operational and transformation costs.

The driver to “cloudify” an application should always be the advantage that results from a cloud deployment in balance with potentially increasing costs in the cloud. A cloud-deployed application does not necessarily need to be cheaper than the on-premises version. Surcharges may be allowed if the benefits in the cloud justify them. Applications that provide notably higher business value in the cloud or are pillars for future market growth can be migrated also with a low or even negative business case. In summary, you have to ensure for every application that the migration results in a financial or functional benefit.

Strategy 4: Target architecture planning

Perhaps the most rational way to save cloud costs can be achieved through well-founded planning of the Cloud Target Architecture. With regards to your target architecture, four areas should be examined in detail:

1. Early-stage Right-Sizing
2. Use-case-specific product instances
3. Reserved instances
4. Combine cloud providers

1. Early-stage Right-Sizing

Expiring leases at data centers have sometimes been a reason for hasty transformation projects. When migrating with strict time constraints the fastest way to the cloud is, at least in the case of fully virtualized applications, a lift-and-shift migration of virtual machines.

However, profound assessments should also take into account load factors. Time constraints during the transformation can impede detailed analysis. Instead, VMs are migrated with similar technical configurations as their on-premises predecessors, which leads to disproportionately high monthly ongoing-costs.

If the load factors of virtual machines can be monitored during the assessment, the cloud VM configurations should be adjusted accordingly. As required, larger or smaller cloud instances can be assigned. You should apply tools that can identify the right-sized instances for all key cloud providers at scale.

Simple one-to-one replacements may save you some time but not costs. If speed is not of the absolute essence, one should consider to right-size instances already before they are moved to the cloud.

2. Use-case-specific product instances

Cloud providers offer a variety of use-case-specific instance types that allow us to save costs if used properly.

A key example are burstable virtual machine instances, such as offered by AWS : The monitoring of load factors during the assessment allows us to identify performance bottlenecks and peaks in utilization. Burstable virtual machines provide a guaranteed CPU performance and offer the ability to burst to high levels of CPU utilization for transient loads. Such instances are useful for applications that have a moderate CPU utilization over most of the time but require high-level CPU power to cover short peak utilizations.

For such applications and workloads, you should consider replacing large VMs with smaller and cheaper but burstable instances. They allow instant vertical scaling and are suitable to meet the requirements at reasonable prices.

Another option is using low-cost spot instances. With spot instances, providers sell unused computing resources. These instances do not guarantee high-availability but can be acquired at a significantly lower price. Indeed, spot instances are not suitable for business-sensitive tasks - but using these instances for testing, development, or fault-tolerant workloads saves costs.

3. Reserved instances

Carefully planning the target architecture allows better flexibility when choosing the price model that enables cost saving. Based on carefully planning the target architecture, you already know what services you will use over the next few years. Most cloud providers reduce their prices if you commit to a service for one or more years. This way, you can opt for so-called reserved instances.

Cost saving of up to 50%, could be the reward if you make the effort to thoroughly assess the uptime demand of your applications and choose reserved instances.

4. Combine cloud providers

Did you choose MS Azure since your organization has always relied on Microsoft? Are you using AWS only because you trust their market leadership? Maybe, you should reconsider your decision and benefit from the opportunities of a multi-cloud approach!

Each provider has its strengths and weaknesses and optimizes other areas or offers. If the functionalities do not differ, at least the prices or price models do. Since no provider has the perfect solution for each problem, your approach should be "Best-of-Breed”. Always choose the best or cheapest products from each provider and combine them in your portfolio. However, do not forget to ensure technical compatibility and consider the aspects of complexity and inter-cloud communication costs as well as lag!

This way, you will benefit from the outstanding capabilities of different providers, the diversity of price models and therefore save costs. At the same time, you can increase the reliability of your portfolio by dividing the risk between different providers.

I hope my four strategies can give you some new food for thought on how you can save costs already during the initial phases of your cloud transformation.