Cloud finance or how to (u)manage costs in the cloud 

My recommendations in cloud finance are twofold: processthat are applicable to any environment, and Technicalthat focus primarily on Amazon Web Services (I am, after all, an AWS Principal Cloud Architect); but many can be adapted to any cloud environment. 

Cloud finance on a budget  

So what should you look at if you're starting to worry about cloud spending? Be sure to start with processes.  

The following diagram was created by Lukas Klášterský, Zdeněk Mach and their colleagues from the Governance team (who will be happy to help you not only in the area of cloud strategies). His main idea is budget, i.e. an estimate of the cost of operating the infrastructure over a given period. 

Budget as a key variable affecting your cloud finances 

In most cases, the budget is for a year, but is based on the expected monthly spend. It is created when designing an application, whether using AWS Pricing Calculator or Azure Pricing Calculator.  

Example of calculating the annual cost of an application 

In most cases, we advise customers to primarily consider the following at this stage "main" application componentsor those that will have a major impact on the overall price. The calculated price is then appropriate increase by about 10 %, which will cover the cost of various sub-services that are impossible to calculate accurately (or would take too much time). 

So in our example above, we have an annual budget $60 000 and the estimated spend $5 000 per month. That's a good start, because we have something to bounce back from. 

Use of budget (consumption) 

If you know how much you plan to spend each month, you should monitor your spending regularly. If you're spending more than you planned, you need to increase your budget (and vice versa - if you're spending less, you can decrease it). 

Higher budget consumption 

You probably did not take something into account when analyzing and designing the application, or there was a change at the infrastructure level, an additional server was added, you needed higher performance, etc. This is of course possible and legitimate, but it is important to know about it.  

A nice example is an application that was "barely paid for" when initially proposed, but was eventually implemented. During its lifetime, new features were implemented (cost impact), but the yield (or other benefit) of the application did not change.  

So you may find yourself in a situation where the application is no longer profitable, and it's time to "revalue" it, or even abolish it. However, if you don't control the budget on which the entire business case of the application is based, you are not able to find out.  

Lower budget consumption 

This situation is of course preferable. Business case application is "better than planned", which you can use to reallocate the budget in a different direction - to other applications, to develop new features, or anything else where you're overdrawing the budget.  

But again - you need to have the tools to work with and evaluate this information. Otherwise, it will always be just inaccurate estimates with a greater or lesser degree of inaccuracy. 

So how do we monitor the budget? 

Tools that monitor cloud finances 

AWS Budgets 

In an AWS environment, it is easiest to use AWS Budgetswith which you can easily define, what and how you want to monitor.  

If there is an overrun of the budget (either current costs or those expected at the end of the month), you will be notified of this situation instant notification. 

 Example of budget implementation using AWS Budgets 

Sample budget overrun warning 

The disadvantage of AWS Budgets is that it only reports the overdrawn budget, not the situation when you do not use the budget in a significant way. That's where the second tool comes in. 

AWS Costs Explorer 

AWS Costs Explorer will process detailed analysis of spending in the cloud.  

This brings us back to cloud financial processes, where you should have a clear definition of who uses AWS Costs Explorer and how often. I usually recommend that customers designate a responsible person to work with this tool at least on a quarterly basis (ideally on a monthly basis). 

AWS Costs Explorer is a powerful tool that allows you to filter and display the data you want in a variety of ways. Interested in looking through a specific application? You can filter based on of a specific tag. Interested in looking through the different sources used? Or for example through the environment? You can do all this in a relatively simple way. 

The output from the AWS Costs Explorer, which nicely shows that in December 2023 there is a significant increase in consumption of Relational Database Service (i.e. platform database) and Certificate Manager. 

So, we have a budget and we can follow it. Now comes the second part, the optimization or more technical part. 

How to optimise customs dutyud finance 

Let's take a look at five areas that can help you optimize your cloud environment. This is not a one-size-fits-all list. But some of the points will applicable in almost any environment. 

1) Pricing models 

The first area is the application of various pricing models. In AWS, we have basically two variants: Pay as you Go a Reservations. In principle, the with lower flexibility comes lower price. I don't want to go into great detail (the area of resource reservation is quite a complicated thing), but the basic division is into: 

• Reserved Instances (either standard or convertible), 
• EC2 Instance Savings Plan, 
• Compute Saving Plan. 

Basic comparison of different pricing models in AWS 

It would take a separate article to discuss which method is more suitable. I consider it important to be able to distinguish between what is appropriate to operate in PAYG mode and where it makes sense to reserve resources (by any type of reservation).  

You will find examples of resources in your environment that you know you will be running for at least another year - these are suitable for booking. 

2) Perceived vs. real needs  

The second area I recommend focusing on is the question, what you really need vs. what you think you need. 

You need 4 CPUs and 16 GB of RAM. Why? "Because that's what we always do," is the typical wrong answer.  

In the cloud, you have to run what you actually need. Your disk is not supposed to be 500 GB because "you don't want to deal with that". Your disk should be the size (with a reasonable margin) that you need. Even your server is supposed to be as big as you need it to be.  

Of course, this is connected with the need for monitoringbecause if you don't know the real use of existing resources, you can't even know whether you need them or not. 

So monitor your sources and adjust them accordingly. The unwritten rule says: "If you don't know how much, you'd better have less." Increasing resources is easy, decreasing (in some cases) resources is a bit more difficult. 

3) Operation of non-productive environments 

I daresay that some of the non-productive environments may not run at all, or it is enough if they are available during working hours. 

A nice illustration is Pay as you Go model. If you run a 24×7 environment, that's an average of 720 hours per month. If you run the same environment only during the 7 a.m. to 7 p.m. workweek, it's only 240 hours per month on average. That's a nice example of saving 66 %.  

The reality is that most environments may not even be available during the day, but only if necessary.  

So how to automate the "switching on" and "switching off" of the environment? A quick solution may be to use AWS Step Functionswhere you can quickly drag & drop a workflow to turn the environment on or off.  

It might look like this: 

• Always at 19:00 Amazon EventBridge sends a signal to start the workflow. 
• Edit Amazon Managed Streaming for Apache Kafka to 0 running brokers (effectively turning it off). 
• Set up the individual services running in Amazon Elastic Conatiner Service to 0 replicas, meaning no container running. 
• Shut down Amazon EC2 servers. 
• We suspend the individual databases running in Amazon Relational Database Service. 

Using AWS Step Functions to control the operation of a non-production environment 

4) Technical review of services and infrastructure 

Review of services and infrastructure is recommended at least once a year or in the event of a major application change. The purpose of the review is to evaluate the state of the used components, or to replace them with others (which were not available or could not be used at the time of the application implementation).  

One of the things that we recommend to go along with this process is a more comprehensive AWS Well-Architected reviewthat will expose your app's weaknesses. 

Example 1: In its initial version, the application supported storing data only locally to Amazon Elastic Block Store. However, the new version already supports saving to Amazon S3 bucket. EBS is much more expensive than S3. 

Example 2: The application did not support scaling at the beginning and you had two large EC2 instances running continuously. But today it is possible to dynamically scale the number of EC2 instances according to the real load. 

Example 3: AWS has come up with a new service or an updated version of an existing service. A nice example is T2 vs. T3a instances. If you are creating a new EC2, T2 instances are still the "default". It's just that the new T3a instances have higher performance and lower cost, so maybe it makes sense to change all T2 instances to T3a. The savings of 20 % is not entirely discardable. (This is true for all instance types, of course. AWS is continually introducing new lines and it is worth keeping an eye on this.) 

Example of savings when changing T2 instances to T3a 

It's exactly the same when using Elastic Block Store (EBS). gp2 is still the default, but gp3 (both generic SSDs) delivers higher performance and lower price. The result is again saving 20 %. 

Example of savings when switching from gp2 to gp3 SSDs 

5) Every decision matters  

In AWS, you pay always and for everything. And some of your decisions can have a significant impact on the price. 

It is therefore most advisable to be aware of these things. Or consult us. We would be happy to help youwhatever we can do to helpwhether it's infrastructure upgrades, optimizations or application migrations.  

And if you're interested in Azure details, contact a colleague Jakub Procházkawhose team will oversee your cloud finances in an Azure environment. Alternatively, you can read his articles on a similar topic in the meantime: 

• FINOPS - money first 
• Tame costs in the cloud: subscriptions, billing, services