=Paper=
{{Paper
|id=Vol-3397/sci3
|storemode=property
|title=Cross-provider Cloud Cost Calculation
|pdfUrl=https://ceur-ws.org/Vol-3397/sci3.pdf
|volume=Vol-3397
|authors=Christian Plewnia,Horst Lichter
|dblpUrl=https://dblp.org/rec/conf/emisa/PlewniaL23
}}
==Cross-provider Cloud Cost Calculation==
https://ceur-ws.org/Vol-3397/sci3.pdf
Cross-provider Cloud Cost Calculation
Christian Plewnia1 , Horst Lichter1
1
RWTH Aachen University, Aachen, Germany
Abstract
Cloud computing grants flexible access to resources such as servers and storage to create compute
infrastructures while only paying for what is used. Due to the complexity of usage-based pricing models,
it is not feasible to obtain cost estimates for larger infrastructures manually. However, the available cost
calculation tools mostly support calculations for one provider and are not open to importing existing
infrastructure models, which makes cost estimations for large infrastructures of enterprises tedious. In
this paper, we present a first version of a cross-provider cloud cost calculation model as a step towards
enabling cost estimations across providers without requiring knowledge of the providers’ pricing models.
Keywords
cloud computing, cost modeling, infrastructure as a service
1. Motivation & Related Work
Enterprises have widely adopted the use of Infrastructure as a Service (IaaS) cloud computing:
in 2021, 81% of Europe’s large businesses used IaaS [1]. One of the benefits of cloud computing
is the flexibility to obtain computing resources, such as virtual machines (VMs) and storage, on
demand without upfront cost, i.e., customers only pay for the time and extent of the resource
usage. However, the usage-based pricing makes cost estimations for new cloud infrastructures,
changes to existing infrastructures, and changes in cloud providers’ prices difficult. This is
especially true for large infrastructures of enterprises, a problem that was already addressed in
2011 by a cross-provider cost modeling tool that enabled the cost calculation for infrastructures
modeled as UML deployment diagram [2]. Unfortunately, this tool is no longer accessible and
the cloud providers’ pricing models advanced since then; where this tool reportedly calculated
the costs for all providers and services as products of usage and price, nowadays the calculations
involve more than a simple product and differ per provider and service. To help with cost
calculations, cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google
Cloud Platform (GCP) offer calculators [3, 4, 5] that allow users to get a cost estimate, but only
for the respective provider. There is also a cross-provider cost calculator, which is limited to a
few providers and services without any possibility of extension [6]. All calculators require the
user to model the infrastructure via its user interface; they neither allow importing existing
infrastructure models nor can be accessed via an Application Programming Interface (API).
13th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA) 2023, May 11–12,
2023, Stockholm, Sweden
Envelope-Open plewnia@swc.rwth-aachen.de (C. Plewnia); lichter@swc.rwth-aachen.de (H. Lichter)
GLOBE https://swc.rwth-aachen.de (C. Plewnia); https://swc.rwth-aachen.de (H. Lichter)
Orcid 0000-0003-0221-9842 (C. Plewnia); 0000-0002-3440-1238 (H. Lichter)
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
With this paper, we aim to revive the idea of a cross-provider model that can calculate a cost
estimate for a given infrastructure and choice of cloud providers. For this, we first describe
the selection of cloud providers and services, which served as a reference for the development
of our model (section 2). Then, we present the first version of the model, which can consider
VMs and block storage; this includes a notation for the infrastructure and the information on
the cloud providers required for the cost calculation (section 3). In section 4, we discuss the
plausibility of the cost calculations and the current limitations.
2. Reference for the Model Construction
To construct the cost calculation model, we need to study cloud providers. With this being initial
work in this direction, we decided to focus on a small set of IaaS providers. We find it to be
reasonable to start with the cloud providers that have the highest market share. The only market
share information that we are aware of is from ranking reports by analysts such as Gartner
[7], providing revenue and market share for 2021, and Acceleration Economy Network [8],
providing revenue for 2022. While the rankings are inconsistent with respect to the considered
providers, the rankings have in common that AWS [3], Azure [4], and GCP [5] are among the
top five cloud providers. According to Gartner, these three covered 67.1% of 2021’s market share.
We decided to use these three providers as reference.
Another dimension relevant to our construction is the considered type of cloud service. By
type, we understand services that are offered by cloud providers in a largely similar way. For
example, AWS, Azure, and GCP all offer servers and block storage. We focus on servers and
block storage as they are part of the infrastructure required for many software applications. For
the model construction, we consider server offers from Elastic Compute Cloud (EC2) (AWS),
Compute (Azure), and Compute Engine (GCP) as well as block storage offers from Elastic Block
Storage (EBS) (AWS), Disk Storage (Azure), and Persistent Disk (GCP).
3. Cross-provider Cost Calculation Model (CCCM)
The idea of the cross-provider cost calculation is for its users to be able to give it a description
of an infrastructure and for it to return estimated cost, without the users needing to know the
pricing mechanisms of the cloud providers. Since costs are incurred over time, we have to
consider what time interval to calculate the costs for. In this context, billing periods must be
considered as some effects, such as maximum cost per billing period, depend on this. The billing
periods for AWS, Azure, and GCP correspond to calendar months. Since costs are accounted for
by cloud providers separately per billing period, we subsequently consider only time intervals
no longer than one billing period. Note that cost calculations for longer time intervals can still
be achieved by summing up the cost per billing period.
Example Infrastructure To illustrate the CCCM and the choices we made for its construction,
we define an example infrastructure for February 2023 with two resources, a VM as a server
(𝑟vm ) with additional block storage (𝑟bs ) as the server’s storage:
Offer details (as of March 17th 2023) Resource cost calculation
a
Off. BI Component Price Res. Component cost (compCost) resourceCost
𝑜vm 60s/1s Instance time $0.1536/h 𝑟vm 28d ⋅ 24h ⋅ $0.1536 = $103.22 $103.22
𝑜bs 60s/1s Storage size $0.0952/GiB-month 𝑟bs = $89.69
(19d ⋅ 1TiB + 9d ⋅ 2TiB) ⋅ $0.0952/(GiB ⋅ 28d)
I/O operations $0.006/IOPS-month1 28d ⋅ 500IOPS ⋅ $0.006/(IOPS ⋅ 28d) = $3.00
Throughput $0.048/MiB/s-month2 28d ⋅ 0MiB/s ⋅ $0.048/(MiB/s ⋅ 28d) = $0.00 $92.69
a: billing increment (first-time interval/following intervals); 1: only charged for the provisioned amount exceeding 3,000 IOPS, 2:
only charged for the provisioned amount exceeding 125 MiB/s
Table 1
Details for AWS offers EC2 t4g.xlarge (=𝑜vm ) and EBS gp3 (=𝑜bs ) and the cost calculation for 𝑟vm and 𝑟bs .
𝑟vm A VM with 4 vCPU (logical CPUs) and 16 GB memory.
𝑟bs A block storage with initially 1 TiB of disk space, which is later increased to 2 TiB
on February 20th 00:00. We further expect to require 3,500 IO operations/s (IOPS) and a
throughput of 125 MB/s – numbers we could have obtained by benchmarking the software
application we intend to deploy.
Total Cost Formally speaking, we define an infrastructure to be a set of resources 𝑅 with 𝑅
being a subset of the domain of all possible resources R, i.e., 𝑅 ⊆ R. In the example, we define
𝑅 = {𝑟vm , 𝑟bs }. We then can calculate the cost for a set of resources 𝑅 with
totalCost(𝑅) ∶ ℙ (R) → M = ∑𝑟∈𝑅 resourceCost(𝑟), (1)
where ℙ denotes the power set and M is the domain of monetary cost.
Offers To calculate the cost for a resource 𝑟, we need to decide on an offer that provides
this resource. For the example, we choose for 𝑟vm the AWS EC2 VM type t4g.xlarge (=𝑜vm ),
which matches the needs for vCPU and memory, and for 𝑟bs we choose AWS EBS gp3 (=𝑜bs ),
which provides the required storage. We encode this choice in assignedOffer(𝑟) ∶ R → O, e.g.,
assignedOffer(𝑟vm ) = 𝑜vm and assignedOffer(𝑟bs ) = 𝑜bs . Table 1 shows the offers and how the
cost for 𝑟vm and 𝑟bs are calculated. The table also shows that both offers define a minimum
usage time of 60s and after that charge for 1s increments — details we consider later.
Usage The cost calculation of a resource also requires us to provide the relevant usage
parameters, e.g., the time we intend to use 𝑟vm as well as the storage, IOPS, and throughput
for 𝑟bs . We identify each usage parameter by the respective resource’s component. We define a
component 𝑐 to be an element of the domain of all components C, i.e., 𝑐 ∈ C. In our example,
we have the components 𝑐time , 𝑐stor , 𝑐iops , and 𝑐tp (throughput). The complete picture of all
components for the reference set is given in table 2.
The usage parameter for a component is a time series of usage values. The time series allows
us to consider changes in the usage, such as the increase in disk storage of 𝑟bs . We define a usage
to be 𝑢𝑐 = (𝑢𝑐,1 ; … ; 𝑢𝑐,𝑚 ) ∶ U with 𝑐 ∈ C and U being a variable-length tuple of real numbers
(ℝ × ⋯ × ℝ). For the usage encoding to be unambiguous, we specify the time resolution and
Block storage
Server AWS Azure GCP
Component AWS Azure GCP gp2 gp3 io1 io2 SHa SSb PSc Ud Std. SSD Bal. Ext.
Instance time 𝑐time 31 32 -
vCPU 𝑐vcpu - - 3
Memory 𝑐mem - - 3
Storage size 𝑐stor 31 31 31 31 3 3 3 3 3 3 3 3
I/O operations 𝑐iops - 31,2 31 31 3 33 3 3 - - - 3
Throughput 𝑐tp - 31,2 - - - - 3 3 - - - -
a: Std. HDD, b: Std. SSD, c: Premium SSD v2, d: Ultra; 1: defines a minUsage𝑐,𝑜 , 2: defines an adjust𝑐,𝑜 , 3: defines a maxCost𝑐,𝑜
Table 2
Overview of the components for servers and block storage for AWS, Azure, and GCP.
unit of usage. For the time resolution we use 1s, which is the smallest billing increment we
have observed across the cloud providers; thus, the length of 𝑢𝑐 for any 𝑐 ∈ C for February 2023
is |𝑢𝑐 | = 2,419,200 (28 d in seconds). For the unit of one usage value 𝑢𝑐,𝑡 , we use the smallest
common base unit for the respective component, e.g., 1s for instance time, 1 GiB for storage
sizes, and 1 IOPS for IO operations. Thus, each value 𝑢𝑐,𝑡 encodes the usage quantity in the
second 𝑡 of the current billing period. For example, the usage of block storage size 𝑐stor for 𝑟bs is
𝑢𝑐stor = (1024 × 1,641,600; 2048 × 777,600) (in GiB), where 𝑎 × 𝑏 means to repeat the value 𝑎 for 𝑏
many times in the tuple; in this example, the series of 1024 corresponds to the 1 TiB required
from February 1st until February 20th 00:00 (in seconds: 19d ⋅ 24h ⋅ 60m ⋅ 60s = 1,641,600) and
the later series of 2048 corresponds to the 2 TiB required until the end of the month (in seconds:
9d ⋅ 24h ⋅ 60m ⋅ 60s = 777,600). Another example is the usage 𝑢𝑐time = (1 × 2,246,400) for 𝑟vm ,
where each usage value 𝑢𝑐time ,𝑡 = 1 encodes a one second usage of the VM in second 𝑡.
To organize the encoding of the usage parameters per resource and component, we define the
function resourceUsage ∶ R → (C → U). It provides for a resource 𝑟 a mapping of the applicable
components to the respective usage time series. We denote this intermediate mapping returned
by resourceUsage as function compUsage ∶ C → U. For example, the aforementioned usage of
block storage size 𝑐size for 𝑟bs can be accessed with (resourceUsage(𝑟bs ))(𝑐stor ) = 𝑢𝑐stor .
Resource & Component Cost We can now calculate the cost for a resource with
resourceCost(𝑟) ∶ R → M = offerCost(assignedOffer(𝑟), resourceUsage(𝑟)). (2)
We can then calculate the cost for an offer by summing up the component cost with
offerCost(𝑜, compUsage) ∶ O × (C → U) → M = ∑𝑐∈comp(𝑜) compCost(𝑐, 𝑜, compUsage(𝑐)) and (3)
compCost(𝑐, 𝑜, 𝑢) ∶ C × O × U → M = min (cost(𝑐, 𝑜, 𝑢), maxCost𝑐,𝑜 ) , (4)
where min(…) optionally allows limiting the cost of a component per billing period to a value
defined for the combination of the offer 𝑜 and component 𝑐. Azure uses this for Standard SSD
block storage’s IOPS component, where a maximum price is given that is lower than summing
up the hourly price for a month. The final piece of the cost calculation is
|𝑢|
cost(𝑐, 𝑜, 𝑢) ∶ C × O × U → M = max (∑𝑖=1 adjust𝑐,𝑜 (𝑢𝑖 ), minUsage𝑐,𝑜 ) ⋅ pricePerUnit𝑐,𝑜 , (5)
defined by user defined once per coud provider
0..* assignedOffer 1..* adjust 1
Infrastructure Resource CloudProvider CostCalculationDetails «abstract»
totalCost() 1..* resourceCost() pricePerUnit : Cost AdjustStrategy
compUsage 0..* minUsage: Float adjust(Float): Float
0..* 1..*
1 maxCost: Cost
Usage Component Offer Legend
0..* 0..* compCost(usage)
values: Float[] id offerCost(usages) class association
:
class
Figure 1: UML class diagram providing an overview of the CCCM.
where adjust𝑐,𝑜 (𝑢) ∶ ℝ → ℝ is a function for adjusting the usage values. It is defined per
combination of offer 𝑜 ∈ O and component 𝑐 ∈ C and by default is an identity function
adjust𝑐,𝑜 (𝑢) = 𝑢. A different definition of the adjustment function allows to accommodate for
free quotas, e.g., the free 3,000 IOPS for 𝑜bs and 𝑐iops , i.e., adjust𝑐,𝑜 (𝑢) = max(𝑢 − 3000, 0). The
minUsage𝑐,𝑜 is a constant defined per combination of offer 𝑜 ∈ O and component 𝑐 ∈ C with a
default minUsage𝑐,𝑜 = 0. It enables the definition of a minimum usage, e.g., minUsage𝑐,𝑜 = 60 s
for the instance time of offer. The constant pricePerUnit𝑐,𝑜 defines for each combination of offer
𝑜 ∈ O and component 𝑐 ∈ C the price per usage unit.
Overview Figure 1 shows a UML class diagram of the CCCM. The class and attribute names
correspond to the previous descriptions. A key benefit of the CCCM is that the parts for the
cloud provider only need to be modeled once. A user interested in calculating the cost of
an infrastructure then can focus on modeling the set of resources 𝑅, the assignment of each
resource to an offer via assignedOffer, and the usage resourceUsage.
4. Discussion
For the CCCM to be of use, its calculated cost must be plausible, i.e., they must be equal to
or sufficiently close to what the cloud providers would calculate. We realized the CCCM as
a prototype in Python and implemented software tests to check for the plausibility of the
calculated cost. As an initial effort to a systematic testing approach, we implemented at least
one test case per combination of cloud provider and service type in our reference set. We
obtained the expected cost using the cloud providers’ own cost calculators.
We further conducted a small industry case study in which we assessed the cost of a potential
cloud migration for multiple scenarios. The base scenario was a migration of an existing
software application to a cloud infrastructure. Further scenarios were created to investigate
the cloud infrastructure costs in case of a redesign of the application toward a microservice
architecture. We provide more information on this case study as supplemental material1 .
The CCCM currently has multiple limitations that can lead to inaccurate cost calculations.
The calculated cost for VMs from GCP is higher than it should be if a VM is used for more than
25% of a month, because the model does not yet provide a mechanism to consider the sustained
use discount applied by GCP; this discount lowers the hourly cost over the course of a month
1
see git repository https://github.com/swc-rwth/cross-provider-cloud-cost-model-paper
for continuously used VM vCPUs and memory. The CCCM also does not consider discounts
from savings plan contracts. Further, server data transfer costs are not considered.
5. Conclusion & Future Work
We presented the Cross-provider Cost Calculation Model (CCCM), which enables a user to get
the costs for a cloud infrastructure without requiring the user to know the cloud providers’
pricing models, as long as someone modeled the providers’ pricing models once. Compared to
an early approach in this direction [2], the CCCM considers the advancements in the providers’
pricing models and it works for the current pricing models of the providers AWS, Azure, and
GCP for the service types servers and block storage and presumably also for other providers
and service types. However, as discussed in section 4, this first version of the CCCM still has
considerable limitations that may cause the calculated costs to be inaccurate in certain cases.
We make two suggestions for future work. First, to overcome the aforementioned limitations,
to stay up to date with possible changes to pricing models, and to enable others to use the cost
calculation model, we suggest a continuous open-source development for the cost calculation
model. This would also allow to establish a library of modeled offers from cloud providers.
Second, in the presented version of the model, the user has to define what resource is fulfilled by
what cloud service offer, which can be difficult given the number of cloud providers and services
on the market. This work can partially be automated by an optimization approach for finding
the best matching offers with respect to an optimization objective for given requirements. The
optimization objective can, for example, be to minimize cost. The requirements would express
constraints to the acceptable offers and can cover technical aspects, e.g., a VM with at least
4 vCPU and 16 GB memory, but also other aspects, e.g., the chosen provider must have certain
security certifications. Thus, a user would have to model resources, their requirements, and
their usage. We currently work on conceptual and technical solutions for these suggestions.
References
[1] Cloud computing - statistics on the use by enterprises, Technical Report, Eurostat, 2022.
[2] A. Khajeh-Hosseini, I. Sommerville, J. Bogaerts, P. Teregowda, Decision Support tools for
Cloud Migration in the Enterprise, in: 4th International Conference on Cloud Computing,
2011, pp. 541–548. doi:10.1109/CLOUD.2011.59 .
[3] Amazon Web Services Pricing Calculator, 2023. URL: https://calculator.aws/.
[4] Azure Pricing Calculator, 2023. URL: https://azure.microsoft.com/pricing/calculator/.
[5] Google Cloud Pricing Calculator, 2023. URL: https://cloud.google.com/products/calculator.
[6] Cloud Computing Comparison Engine, 2023. URL: https://www.cloudorado.com/.
[7] Gartner Inc., Gartner Says Worldwide IaaS Public Cloud Services Market Grew 41.4% in 2021,
2022. URL: https://www.gartner.com/en/newsroom/press-releases/2022-06-02-gartner-says-
worldwide-iaas-public-cloud-services-market-grew-41-percent-in-2021.
[8] Acceleration Economy LLC, The World’s Top Cloud Vendors, 2022. URL: https://
accelerationeconomy.com/cloud-wars-top-10/.
All online references last accessed March 19th 2023.