Cloud computing is a key information technology service with high and growing revenue. Worldwide, end-user spending on public cloud services was projected to grow 23.1 percent, from $270 billion in 2020 to $332.3 billion in 2021, and it was forecast to increase to $397.5 billion in 2022.1 Furthermore, cloud services are projected to make up 14.2 percent of total information technology (IT) spending worldwide by 2024, up from 9.1 percent of spending in 2020.2 Like many high-tech goods and services, cloud computing has experienced strong revenue growth while also undergoing rapid technological improvement. This improvement, also known as quality change, needs to be accounted for when measuring the rate of price change over time.
The U.S. Bureau of Labor Statistics’ (BLS) Producer Price Index (PPI) tracks only “pure” price change, which is price change that excludes changes in quality. When a product or service does change, there are methods, known as quality adjustment (QA), which can account for this change.3
One of the QA methods is hedonic QA. This method uses a hedonic regression model to estimate and control for changes in quality in order to give a measure of pure price change.
For this article, we use data from three of the top cloud providers to develop a hedonic model for cloud computing services.4 We cover the following: (1) cloud computing industry, index, and technological background; (2) data and methodology for the hedonic models; (3) construction of the model; and (4) the results of the model with comparisons to existing methodology.
Industry and index background
The PPI program surveys establishments in data processing, hosting, and related services (North American Industry Classification System (NAICS) code 518210) that provide infrastructure or support for hosting or data processing purposes. The establishments are often third-party service providers for other businesses and governments who outsource their business processes, data, or computing services. These outsourced services are provided by equipment owned, operated, and held by the establishments within the data processing and cloud industry. This industry is highly concentrated, and the very large providers have the greatest influence over the market prices for cloud services.
In 2018, Amazon Web Services (AWS) led the cloud computing industry with ownership of nearly half of the infrastructure as a service (IaaS) market (47.8 percent). The other leaders in the industry were Microsoft (15.5 percent), Alibaba (7.7 percent), Google (4.0 percent), and IBM (1.8 percent).5 As leaders in the industry, their pricing structures are similar. AWS, Microsoft Azure, and Google all have customizable on-demand packaging as well as prestructured packages that are comparable. For these reasons we have chosen to build our data sample using these three service providers.
Traditionally, data and computing services and business processes have been completed onsite by the businesses using them. For instance, data management and payroll used servers and computers located in the same building where a business conducted its primary activities. However, with the emergence of the data processing service industry, businesses are now able to rent data storage space and computing power from offsite servers.
There are several major benefits to outsourcing these services. First, businesses no longer have to purchase and maintain complicated and expensive IT equipment. Another benefit is that the services provided are often sold in an on-demand, customizable fashion. As companies’ computing needs change, they can vary the capacity of data processing services they purchase, which can reduce costs. If the companies were to host data processing services in-house, they would need to have computing resources available to handle peak demand that would otherwise sit idle most of the time.
Within the PPI program’s structure, data processing, hosting, and related services is an aggregate index that contains lower level indexes. These lower level indexes are differentiated by the types of services provided: business process management services; data management, information transformation, and related services; hosting, application service provision (ASP), and other IT infrastructure provisioning services. Cloud computing is the provisioning of virtual computer infrastructure which is classified in the hosting, ASP, and other IT infrastructure provisioning services lower level index.
Cloud computing can be classified into three areas: software as a service, platform as a service, and infrastructure as a service. Software as a service (SaaS) is the most fully featured and easily accessible cloud computing package. With SaaS, there is no need for a customer to install, manage, or purchase software. The customer simply connects to the cloud provider and uses the software. As SaaS provides a finished product, SaaS products are not classified with the remaining services, but rather in software publishing (NAICS 511210). Platform as a service (PaaS) has a much broader structure compared with SaaS packages. As its title suggests, PaaS provides a platform on which developers can build and attach their own applications. These platforms are typically made up of an operating system (OS), a programming language and an environment for it, a database, and a web server. Finally, the service this article will focus on, infrastructure as a service (IaaS), is the most basic type of cloud computing. Each package is essentially a virtual version of a blank computer: microprocessor, memory, storage, etc. Furthermore, these packages often include access to a basic OS, such as a limited version of Linux, or the option to purchase access to a different OS, such as Windows.
We chose to focus on IaaS packages for the PPI’s QA model because, as the broadest service offering, IaaS is typically used as a base on which other services are built. For instance, SaaS and PaaS both use the computer resources that are offered through IaaS. By developing a model for IaaS, we are also able to describe many of the factors that affect the price for SaaS and PaaS.
BLS determines the current pricing method for IaaS in the PPI by both the service characteristics and transaction terms for each item. For IaaS, the main types of prices are fee-based transaction prices (average rates, standard rates, or prepaid rates) or estimated flat fees. Flat fees are more commonly seen in contracts with large firms. These contracts are negotiated on the basis of an average or expected sum of cloud usage per month. However, cloud usage is often so variable that the real value of these contracts is almost never the same from month to month. Fee-based transaction prices have become much more common in the cloud computing industry because the industry has shifted toward on-demand services to cater to small businesses, individual consumers, and large companies simultaneously. To control for variability of usage, we focus on per-hour pricing in IaaS packages as the dependent variable of our model.
The service characteristics of an IaaS package are the variable features in our model, and the combinations of these features determine the price, either as a contract or a sum-of-its-parts, fee-based transaction.6
The combination of characteristics that a customer may choose to purchase is highly customizable and designed to fit the needs of any customer, including independent users, small businesses, and large corporations. Although access to cloud services has become more convenient over time, this flexibility has made pricing more complicated. This complexity is why we have developed this model. Having a hedonic model will allow us to separate changes in the quality of the cloud service from changes in the price.
Several of these characteristics can be offered as stand-alone services or products that have substantial impact on IaaS pricing and quality. We include storage as a characteristic because cloud service providers typically provide a small amount of storage with IaaS. They also sell stand-alone storage, but we do not include that in our datasets or models. Microprocessor hardware is also included as a price-determining characteristic because the generation and model of a microprocessor can cause quality changes for cloud packages that may seem unchanged at face value. For instance, Diane Coyle and David Nguyen note the speed and changes in AWS packages between generations.7 In November 2017, AWS claimed the new IaaS Elastic Compute Cloud (EC2) M5 instances would provide a 14-percent performance improvement over the previous M4 generation instances without a change in price. The only change announced between the two generations was an upgrade to a more modern microprocessor.
There are also several characteristics that can have an impact on price that are not quantifiable using publicly available data and so are not a focus of this model. For example, prices often differ by region because a higher concentration of larger data distribution centers in an area as well as the proximity of data distribution centers to the consumer influence speed and performance of cloud services. This effect is referred to as latency. However, because cloud services are available to the consumer from anywhere, we have no way of knowing to what degree latency impacts overall instance performance. Likewise, there is no way for us to know how much consumers use these products over a certain timeframe, so we chose to focus on time-based fees, specifically per hour costs of each instance.
Methodology and development of PPI cloud services hedonic models
Hedonic regression models provide a way to quality adjust services. The basic form of the hedonic models is a linear regression with the natural logarithm of price per hour as the dependent variable and characteristics of the service as the explanatory variables. The explanatory variables represent the different attributes that the service comprises, and the coefficients on those variables (
) represent the cost of those attributes. The services are indexed by 
and each service 
has characteristics 
. Thus, the form of a hedonic model is:
where 
is the intercept term and 
is the error term.
Previous work in applying hedonics to cloud computing exists. In 2016, Liang Zhang constructed a dataset for AWS and estimated hedonic models for the 2009–15 period.8 Those models were assessed on both multiple periods (time dummy method) and single periods (adjacent period method) to estimate quality adjusted measures of price change for AWS cloud services. Mitropoulou et al. also applied hedonics to cloud computing.9 They assembled a dataset of 25 cloud service providers and estimated a hedonic model for a single period. Coyle and Nguyen computed AWS prices per EC2 Compute Unit (ECU) and compared them to a nominal price index per product class, using the EC2 “large” and “x.large” instances available in the United Kingdom from the first quarter of 2010 to the third quarter of 2018.10
For the models in this article, we use the time dummy hedonic method. This method takes equation (1) and adds a time index, t, and a time dummy 
that indicates whether a service is from the first period or the second period. In this case, the time dummy model is:
where 
is the coefficient associated with the time dummy.
The methodology we use is drawn from the methodology of David Byrne, Carol Corrado, and Daniel Sichel.11 We use time dummy hedonic models because they allow us to calculate price changes that occur from changes to several interrelated characteristics without having the proportions of overall sales dedicated to each instance variation. Revenue and sales information at the product level are not often released to the public.
Because we use time dummy models, the dataset consists of two or more periods of data. Specifically, we use overlapping two-quarter datasets. For example, the dataset for the first model consists of the second quarter and third quarter of 2017 and the dataset for the second model consists of the third quarter and fourth quarter of 2017.
With differences in characteristics being accounted for by the other explanatory variables, the time dummy variable gives the quality adjusted price change between the two quarters.12
The model is intended to be used to directly estimate quality adjusted price change. Typically, a producer price index comprises items that represent specific services and their associated prices. In this case, items represent the aggregation of services included in the dataset used in the model. The item prices are being used to show quality adjusted price change calculated from the model.
The dataset is assembled to back test QA models. It includes quarterly observations from the second quarter of 2017 through the second quarter of 2019 for three of the largest services in the industry: AWS, Google Cloud, and Microsoft Azure.
The selection of characteristics to include in the model is important because it helps determine the magnitude of the time dummy coefficient. One of the key drivers of quality change with cloud services is the microprocessor used in the servers. Microprocessors undergo continual quality changes, and these changes are responsible for improvements in a range of high-tech goods and services, from smartphones to artificial intelligence. Each cloud provider uses a limited number of microprocessor models in their servers. This limited number of models makes it difficult to have enough variation in microprocessor characteristics for the model to estimate significant coefficients.
AWS has a measure of the performance of the microprocessor used in their Elastic Compute Cloud (EC2) service called EC2 Compute Unit (ECU).13 Because ECU is available for all AWS cloud services and it is calculated by AWS itself, ECU is a credible gauge of microprocessor performance. Neither Microsoft Azure nor Google Cloud have a microprocessor measure like AWS’ ECU. Byrne, Corrado, and Sichel used AWS ECU in their models, and we emulate this approach.14
There are also third-party microprocessor benchmarks, such as the Standard Performance Evaluation Corporation central processing unit (CPU) and PassMark CPU benchmarks, but both of these only have results for a limited number of microprocessors used in cloud services. This limited number of results is too small to support a hedonic model.
Fortunately, characteristics information is available for all microprocessors. However, microprocessors are complicated devices, and selecting the characteristics to include in the model is challenging for two reasons.15 First, only a few different microprocessors are used by any one cloud service provider, which limits the number of microprocessor characteristics our model can support. As described by Steven Sawyer and Alvin So, the main characteristics of microprocessors are cores, threads, thermal design power (TDP), base frequency, turbo frequency, and cache.16
Second, cloud services are priced by virtual CPU (vCPU). Each vCPU corresponds to a microprocessor thread. Consequently, each vCPU only uses part of the microprocessor cache and accounts for part of the TDP. As such, for use in our models, the cache and TDP variables have to be multiplied by the proportion of threads used by each individual cloud computing service to the total threads in the microprocessor. For example, if a cloud computing service instance offers two vCPUs and the microprocessor used to provide the service has 10 threads, 8 MB of cache, and a TDP of 100 watts, then the cloud service uses 1.6 MB of cache and accounts for 20 watts of TDP. In this example, the remaining 8 threads, 6.4 MB of cache, and 80 watts of TDP would remain available to run other cloud computing service instances. Base and turbo frequency are the same throughout the microprocessor, and so they do not need to be adjusted.
In 2018, Sawyer and So used statistical learning techniques to select specifications for microprocessor hedonic models.17 These techniques, in turn, were taken from An Introduction to Statistical Learning.18 Because many of the price-determining characteristics for cloud computing services are the same as for microprocessors, we applied the same statistical learning techniques that Sawyer and So use for their hedonic model of microprocessors.
The technique starts with prescreening the data. Our dataset for AWS has seven variables (not including the time dummy variables). We start with calculating the residual sum of squares (RSS) for each single-regressor model. The single-regressor model with the lowest RSS is selected as a prescreened model. We then repeat the procedure for every two-regressor model. The two-regressor model with the lowest RSS is selected as a prescreened model. We continue this process, increasing the number of regressors by one each time, until we have seven prescreened models. To select the best model from the prescreened models, we use repeated k-fold cross validation.19
Repeated k-fold cross validation evaluates the performance of a model by the model’s ability to accurately predict the prices (the dependent variable of the model) in the dataset. With time dummy hedonics, we are most interested in the time dummy variable (an explanatory variable) because that variable determines the rate of price change. Though there is a seeming mismatch between what the statistical learning technique and time dummy hedonics focus on, the technique’s purpose is to prevent the selection of an overfitted model. As demonstrated in a previous article, the variables included in a model affect the magnitude of the time dummy.20 For this reason, we think it makes sense to use the previously mentioned statistical learning technique with time dummy hedonic models.
PPI cloud services hedonic models
Using the methodology detailed in the previous section, we developed cloud services hedonic models for the major producers in the industry. We first estimated models for AWS using ECU to represent microprocessor performance. The results are in tables 1 and 2. Please note that all the models in this article use the time dummy method, have the natural logarithm of price as the dependent variable, and use two adjacent quarters of data.
Only models that contained quarters with exiting or entering services had price change. However, we also run the statistical learning technique on the quarters with no exit or entry to show the stability of the service characteristic coefficients. The specific form of the model evaluated by the statistical learning technique is:
Table 1. AWS cloud services time dummy hedonic model of price using ECU, second quarter 2017 to second quarter 2018| Variable | Q2 2017–Q3 2017 | Q3 2017–Q4 2017 | Q4 2017–Q1 2018 | Q1 2018–Q2 2018 |
|---|
Quarter dummy | 0.0000 | 0.0000 | -0.0296 | 0.0000 |
|---|
Standard error | 0.0455 | 0.0455 | 0.0435 | 0.0372 |
|---|
Ln(vCPU) | -1.6094[1] | -1.6094[1] | [2] | [2] |
|---|
Standard error | 0.4586 | 0.4586 | [2] | [2] |
|---|
Ln(Memory) | 0.7051[1] | 0.7051[1] | 0.5379[1] | 0.5376[1] |
|---|
Standard error | 0.0792 | 0.0792 | 0.0446 | 0.0423 |
|---|
Ln(Storage) | 0.1401[1] | 0.1401[1] | 0.1608[1] | 0.1588[1] |
|---|
Standard error | 0.0224 | 0.0224 | 0.0229 | 0.0232 |
|---|
SSD | -1.1939[1] | -1.1939[1] | -1.2873[1] | -1.2506[1] |
|---|
Standard error | 0.1830 | 0.1830 | 0.1911 | 0.1931 |
|---|
Ln(ECU) | 1.9327[1] | 1.9327[1] | 0.4407[1] | 0.4454[1] |
|---|
Standard error | 0.4124 | 0.4124 | 0.0511 | 0.0468 |
|---|
Windows | 0.4676[1] | 0.4676[1] | 0.5047[1] | 0.5318[1] |
|---|
Standard error | 0.0455 | 0.0455 | 0.0415 | 0.0372 |
|---|
Observations | 128 | 128 | 152 | 176 |
|---|
Adjusted R-squared | 0.9650 | 0.9650 | 0.9659 | 0.9683 |
|---|
Table 2. AWS cloud services time dummy hedonic model using ECU, second quarter 2018 to 2019 second quarter| Variable | Q2 2018–Q3 2018 | Q3 2018–Q4 2018 | Q4 2018–Q1 2019 | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0000 | 0.0671 | 0.0000 | 0.0000 |
|---|
Standard error | 0.0372 | 0.0478 | 0.0479 | 0.0479 |
|---|
Ln(vCPU) | [2] | 1.0276[1] | 1.3102[1] | 1.3102[1] |
|---|
Standard error | [2] | 0.2099 | 0.1659 | 0.1659 |
|---|
Ln(Memory) | 0.5376[1] | 0.4427[1] | 0.452[1] | 0.452[1] |
|---|
Standard error | 0.0423 | 0.0436 | 0.0360 | 0.0360 |
|---|
Ln(Storage) | 0.1588[1] | 0.1086[1] | 0.0634[1] | 0.0634[1] |
|---|
Standard error | 0.0232 | 0.0238 | 0.0244 | 0.0244 |
|---|
SSD | -1.2506[1] | -0.8662[1] | -0.5449[1] | -0.5449[1] |
|---|
Standard error | 0.1931 | 0.1801 | 0.1687 | 0.1687 |
|---|
Ln(ECU) | 0.4454[1] | -0.5007[1] | -0.7908[1] | -0.7908[1] |
|---|
Standard error | 0.0468 | 0.2005 | 0.1709 | 0.1709 |
|---|
Windows | 0.5318[1] | 0.5183[1] | 0.5083[1] | 0.5083[1] |
|---|
Standard error | 0.0372 | 0.0457 | 0.0479 | 0.0479 |
|---|
Observations | 176 | 206 | 236 | 236 |
|---|
Adjusted R-squared | 0.9683 | 0.9466 | 0.9349 | 0.9349 |
|---|
Only the models for the fourth quarter of 2017 to the first quarter of 2018 and the third quarter of 2018 to the fourth quarter of 2018 had price changes. Some of the variables have counterintuitive signs on their coefficients in some of the models, such as those of the natural logarithm of ECU in the last three models.21 However, with time dummy models, we are mainly interested in the time dummy coefficient.
Even though few variables are being eliminated, there is still value in using the statistical learning specification algorithm. For instance, the natural logarithm of vCPU is not selected for three of the models, and this variable is one of the main price-determining characteristics. Without the statistical learning specification algorithm, we would have not known that omitting the natural logarithm of vCPU would produce better performance in those three models.
We also estimate models for AWS using microprocessor characteristics instead of ECU. The ECU models serve as a benchmark for the performance of the microprocessor characteristics models. This comparison will be useful for gauging the appropriateness of using microprocessor characteristics in the Microsoft Azure and Google Cloud models where an ECU-like variable is not available.
For the models using microprocessors characteristics, the vCPU variable is omitted because it is strongly correlated with cache and TDP. As explained previously, the amount of cache or TDP is proportional to the number of vCPUs. Because the base and turbo frequency variables are closely correlated and there are so few microprocessors in the data set, the model selection technique was done twice, once using base frequency and omitting turbo frequency and once using turbo frequency and omitting base frequency. The specific form of the model evaluated by the statistical learning technique is:
Table 3. AWS cloud services time dummy hedonic model using CPU characteristics with base frequency, second quarter 2017 to second quarter 2018| Variable | Q2 2017–Q3 2017 | Q3 2017–Q4 2017 | Q4 2017–Q1 2018 | Q1 2018–Q2 2018 |
|---|
Quarter dummy | 0.0000 | 0.0000 | -0.0358 | 0.0000 |
|---|
Standard error | 0.0338 | 0.0338 | 0.0368 | 0.0305 |
|---|
Ln(Memory) | 0.999[1] | 0.999[1] | 0.8248[1] | 0.8302[1] |
|---|
Standard error | 0.0690 | 0.0690 | 0.0597 | 0.0648 |
|---|
Ln(Storage) | 0.0521 | 0.0521 | 0.1595[1] | 0.1696[1] |
|---|
Standard error | 0.0285 | 0.0285 | 0.0237 | 0.0250 |
|---|
SSD | -0.5403[1] | -0.5403[1] | -1.3028[1] | -1.3855[1] |
|---|
Standard error | 0.2419 | 0.2419 | 0.1969 | 0.2135 |
|---|
Ln(Base frequency) | 1.5521[1] | 1.5521[1] | 2.7659[1] | 3.1469[1] |
|---|
Standard error | 0.3745 | 0.3745 | 0.2894 | 0.4642 |
|---|
Ln(Cache) | -2.503[1] | -2.503[1] | 0.1327[1] | 0.4323[1] |
|---|
Standard error | 0.3498 | 0.3498 | 0.0598 | 0.1015 |
|---|
Ln(TDP) | 2.4708[1] | 2.4708[1] | [2] | -0.3015[1] |
|---|
Standard error | 0.3265 | 0.3265 | [2] | 0.1429 |
|---|
Windows | 0.4676[1] | 0.4676[1] | 0.5047[1] | 0.5318[1] |
|---|
Standard error | 0.0338 | 0.0338 | 0.0345 | 0.0305 |
|---|
Observations | 128 | 128 | 152 | 176 |
|---|
Adjusted R-squared | 0.9807 | 0.9807 | 0.9764 | 0.9786 |
|---|
Table 4. AWS cloud services time dummy hedonic model using CPU characteristics with base frequency, second 2018 to second quarter 2019 | Variable | Q2 2018–Q3 2018 | Q3 2018–Q4 2018 | Q4 2018–Q1 2019 | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0000 | 0.0708 | 0.0000 | 0.0000 |
|---|
Standard error | 0.0305 | 0.0431 | 0.0456 | 0.0456 |
|---|
Ln(Memory) | 0.8302[1] | 0.7399[1] | 0.7052[1] | 0.7052[1] |
|---|
Standard error | 0.0648 | 0.0570 | 0.0542 | 0.0542 |
|---|
Ln(Storage) | 0.1696[1] | 0.1066[1] | 0.0598[1] | 0.0598[1] |
|---|
Standard error | 0.0250 | 0.0229 | 0.0231 | 0.0231 |
|---|
SSD | -1.3855[1] | -0.9008[1] | -0.5604[1] | -0.5604[1] |
|---|
Standard error | 0.2135 | 0.1753 | 0.1591 | 0.1591 |
|---|
Ln(Base frequency) | 3.1469[1] | 2.5898[1] | 2.1997[1] | 2.1997[1] |
|---|
Standard error | 0.4642 | 0.4648 | 0.4955 | 0.4955 |
|---|
Ln(Cache) | 0.4323[1] | 0.6801[1] | 0.7981[1] | 0.7981[1] |
|---|
Standard error | 0.1015 | 0.1401 | 0.1412 | 0.1412 |
|---|
Ln(TDP) | -0.3015[1] | -0.4262[1] | -0.4857[1] | -0.4857[1] |
|---|
Standard error | 0.1429 | 0.1717 | 0.1777 | 0.1777 |
|---|
Windows | 0.5318[1] | 0.5183[1] | 0.5083[1] | 0.5083[1] |
|---|
Standard error | 0.0305 | 0.0423 | 0.0456 | 0.0456 |
|---|
Observations | 176 | 206 | 236 | 236 |
|---|
Adjusted R-squared | 0.9786 | 0.9544 | 0.9411 | 0.9411 |
|---|
The statistical learning technique is selecting most of the variables for the models. These models are also showing price changes from the fourth quarter of 2017 to the first quarter of 2018 and the third quarter of 2018 to the fourth quarter of 2018, just as the ECU models do. The price changes are somewhat larger in the microprocessors characteristics models, but they are not drastically different.
For the microprocessors characteristics models using turbo frequency, the specific form of the model evaluated by the statistical learning technique is:
Table 5. AWS cloud services time dummy hedonic model using CPU characteristics with turbo frequency, second quarter 2017 to second quarter 2018| Variable | Q2 2017–Q3 2017 | Q3 2017–Q4 2017 | Q4 2017–Q1 2018 | Q1 2018–Q2 2018 |
|---|
Quarter dummy | 0.0000 | 0.0000 | -0.0422 | 0.0000 |
|---|
Standard error | 0.0349 | 0.0349 | 0.0430 | 0.0340 |
|---|
Ln(Memory) | 0.949[1] | 0.949[1] | 0.596[1] | 0.5655[1] |
|---|
Standard error | 0.0577 | 0.0577 | 0.0509 | 0.0438 |
|---|
Ln(Storage) | [2] | [2] | 0.1341[1] | 0.1391[1] |
|---|
Standard error | [2] | [2] | 0.0222 | 0.0227 |
|---|
SSD | -0.1351[1] | -0.1351[1] | -1.0837[1] | -1.1101[1] |
|---|
Standard error | 0.0499 | 0.0499 | 0.1859 | 0.1877 |
|---|
Ln(Turbo frequency) | [2] | [2] | [2] | [2] |
|---|
Standard error | [2] | [2] | [2] | [2] |
|---|
Ln(Cache) | -3.4095[1] | -3.4095[1] | -0.3434[1] | -0.1319 |
|---|
Standard error | 0.2746 | 0.2746 | 0.1356 | 0.0925 |
|---|
Ln(TDP) | 3.4404[1] | 3.4404[1] | 0.7166[1] | 0.5407[1] |
|---|
Standard error | 0.2275 | 0.2275 | 0.1059 | 0.0701 |
|---|
Windows | 0.4676[1] | 0.4676[1] | 0.5047[1] | 0.5318[1] |
|---|
Standard error | 0.0349 | 0.0349 | 0.0383 | 0.0340 |
|---|
Observations | 128 | 128 | 152 | 176 |
|---|
Adjusted R-squared | 0.9794 | 0.9794 | 0.9708 | 0.9735 |
|---|
Table 6. AWS cloud services time dummy hedonic model using CPU characteristics with turbo frequency, second quarter 2018 to second quarter 2019| Variable | Q2 2018–Q3 2018 | Q3 2018–Q4 2018 | Q4 2018–Q1 2019 | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0000 | 0.0830 | 0.0000 | 0.0000 |
|---|
Standard error | 0.0341 | 0.0453 | 0.0460 | 0.0460 |
|---|
Ln(Memory) | 0.5373[1] | 0.5516[1] | 0.5676[1] | 0.5676[1] |
|---|
Standard error | 0.0345 | 0.0317 | 0.0276 | 0.0276 |
|---|
Ln(Storage) | 0.1423[1] | 0.0516[1] | [2] | [2] |
|---|
Standard error | 0.0229 | 0.0220 | [2] | [2] |
|---|
SSD | -1.1375[1] | -0.4544[1] | -0.0936 | -0.0936 |
|---|
Standard error | 0.1888 | 0.1714 | 0.0514 | 0.0514 |
|---|
Ln(Turbo frequency) | [2] | -1.8409[1] | -1.9731[1] | -1.9731[1] |
|---|
Standard error | [2] | 0.6074 | 0.5748 | 0.5748 |
|---|
Ln(Cache) | [2] | -0.4847 | -0.3937 | -0.3937 |
|---|
Standard error | [2] | 0.2634 | 0.2882 | 0.2882 |
|---|
Ln(TDP) | 0.4381[1] | 0.944[1] | 0.8612[1] | 0.8612[1] |
|---|
Standard error | 0.0349 | 0.2557 | 0.2772 | 0.2772 |
|---|
Windows | 0.5318[1] | 0.5183[1] | 0.5083[1] | 0.5083[1] |
|---|
Standard error | 0.0341 | 0.0432 | 0.0460 | 0.0460 |
|---|
Observations | 176 | 206 | 236 | 236 |
|---|
Adjusted R-squared | 0.9733 | 0.9524 | 0.9401 | 0.9401 |
|---|
Like the characteristics models that have base frequency, the characteristics models with turbo frequency show price changes from the fourth quarter of 2017 to the first quarter of 2018 and the third quarter of 2018 to the fourth quarter of 2018. However, the characteristics models with turbo frequency show a larger deviance from the ECU models than the characteristics models with base frequency. Unlike base frequency, which was selected for all models, turbo frequency was only selected in three of the eight models. Overall, the characteristics models with base frequency show better performance than characteristics models using turbo frequency.
As of 2021, AWS no longer publishes ECU for its cloud computing services. Fortunately, as this article has shown, microprocessor characteristics can be used in place of ECU if BLS decides to use hedonic models for quality adjusting the PPI for hosting, ASP, and other IT infrastructure.
We use the same statistical learning technique to estimate models for Microsoft Azure separately for base frequency and turbo frequency. The models with base frequency take the same form as equation 4, and the models with turbo frequency take the same form as equation 5.
Table 7. Microsoft Azure cloud services time dummy hedonic model using CPU characteristics with base frequency, second quarter 2017 to second quarter 2018| Variable | Q2 2017–Q3 2017 | Q3 2017–Q4 2017 | Q4 2017–Q1 2018 | Q1 2018–Q2 2018 |
|---|
Quarter dummy | 0.0000 | -0.0079 | 0.0095 | 0.0000 |
|---|
Standard error | 0.0284 | 0.0279 | 0.0208 | 0.0197 |
|---|
Ln(Memory) | 0.4646[1] | 0.4885[1] | 0.4791[1] | 0.4315[1] |
|---|
Standard error | 0.0244 | 0.0245 | 0.0311 | 0.0155 |
|---|
Ln(Storage) | 0.1273[1] | 0.1162[1] | 0.1231[1] | 0.1508[1] |
|---|
Standard error | 0.0165 | 0.0165 | 0.0193 | 0.0115 |
|---|
SSD | 0.4903[1] | 0.5135[1] | 0.5155[1] | 0.4918[1] |
|---|
Standard error | 0.0252 | 0.0243 | 0.0259 | 0.0251 |
|---|
Ln(Base frequency) | [2] | -0.6297 | -0.9335[1] | -0.7991[1] |
|---|
Standard error | [2] | 0.3723 | 0.1297 | 0.1036 |
|---|
Ln(Cache) | 0.8013[1] | 0.5283[1] | 0.4003[1] | 0.4039[1] |
|---|
Standard error | 0.0610 | 0.1492 | 0.0262 | 0.0243 |
|---|
Ln(TDP) | -0.3721[1] | -0.1176 | [2] | [2] |
|---|
Standard error | 0.0664 | 0.1540 | [2] | [2] |
|---|
Windows | 0.4055[1] | 0.422[1] | 0.4436[1] | 0.4503[1] |
|---|
Standard error | 0.0293 | 0.0280 | 0.0240 | 0.0210 |
|---|
Observations | 136 | 148 | 150 | 140 |
|---|
Adjusted R-squared | 0.9866 | 0.9872 | 0.9893 | 0.9919 |
|---|
Table 8. Microsoft Azure cloud services time dummy hedonic model using CPU characteristics with base frequency, second quarter 2018 to second quarter 2019)| Variable | Q2 2018–Q3 2018 | Q3 2018–Q4 2018 | Q4 2018–Q1 2019 | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0295 | 0.0049 | -0.0018 | -0.0036 |
|---|
Standard error | 0.0238 | 0.0168 | 0.0155 | 0.0157 |
|---|
Ln(Memory) | 0.3166[1] | 0.2625[1] | 0.2631[1] | 0.2584[1] |
|---|
Standard error | 0.0225 | 0.0098 | 0.0095 | 0.0099 |
|---|
Ln(Storage) | 0.2569[1] | 0.3493[1] | 0.3487[1] | 0.3544[1] |
|---|
Standard error | 0.0213 | 0.0162 | 0.0170 | 0.0171 |
|---|
SSD | 0.2625[1] | 0.0785[1] | 0.0774[1] | 0.0674[1] |
|---|
Standard error | 0.0316 | 0.0138 | 0.0137 | 0.0144 |
|---|
Ln(Base frequency) | -2.9143[1] | -4.5942[1] | -4.7023[1] | -4.7626[1] |
|---|
Standard error | 0.3972 | 0.3076 | 0.3054 | 0.3081 |
|---|
Ln(Cache) | -0.6378[1] | -1.3068[1] | -1.3475[1] | -1.379[1] |
|---|
Standard error | 0.1618 | 0.0958 | 0.0933 | 0.0943 |
|---|
Ln(TDP) | 1.0623[1] | 1.7011[1] | 1.7406[1] | 1.7691[1] |
|---|
Standard error | 0.1607 | 0.0834 | 0.0779 | 0.0788 |
|---|
Windows | 0.4415[1] | 0.4508[1] | 0.4683[1] | 0.4701[1] |
|---|
Standard error | 0.0277 | 0.0170 | 0.0161 | 0.0164 |
|---|
Observations | 132 | 138 | 152 | 152 |
|---|
Adjusted R-squared | 0.9873 | 0.9951 | 0.9951 | 0.9949 |
|---|
Table 9. Microsoft Azure cloud services time dummy hedonic model using CPU characteristics with turbo frequency, second quarter 2017 to second quarter 2018| Variable | Q2 2017–Q3 2017 | Q3 2017–Q4 2017 | Q4 2017–Q1 2018 | Q1 2018–Q2 2018 |
|---|
Quarter dummy | 0.0000 | -0.0024 | 0.0050 | 0.0000 |
|---|
Standard error | 0.0284 | 0.0283 | 0.0204 | 0.0197 |
|---|
Ln(Memory) | 0.4646[1] | 0.4814[1] | 0.4659[1] | 0.4308[1] |
|---|
Standard error | 0.0244 | 0.0257 | 0.0274 | 0.0157 |
|---|
Ln(Storage) | 0.1273[1] | 0.1199[1] | 0.1307[1] | 0.1509[1] |
|---|
Standard error | 0.0165 | 0.0171 | 0.0171 | 0.0115 |
|---|
SSD | 0.4903[1] | 0.5057[1] | 0.5059[1] | 0.4894[1] |
|---|
Standard error | 0.0252 | 0.0242 | 0.0263 | 0.0261 |
|---|
Ln(Turbo frequency) | [2] | -1.276[1] | -1.1989[1] | -1.0693[1] |
|---|
Standard error | [2] | 0.4215 | 0.3074 | 0.2869 |
|---|
Ln(Cache) | 0.8013[1] | 0.6062[1] | 0.6136[1] | 0.5848[1] |
|---|
Standard error | 0.0610 | 0.0721 | 0.0556 | 0.0430 |
|---|
Ln(TDP) | -0.3721[1] | -0.1892[1] | -0.2075[1] | -0.1787[1] |
|---|
Standard error | 0.0664 | 0.0801 | 0.0670 | 0.0517 |
|---|
Windows | 0.4055[1] | 0.4231[1] | 0.4437[1] | 0.4507[1] |
|---|
Standard error | 0.0293 | 0.0275 | 0.0237 | 0.0209 |
|---|
Observations | 136 | 148 | 150 | 140 |
|---|
Adjusted R-squared | 0.9866 | 0.9873 | 0.9895 | 0.9919 |
|---|
Table 10. Microsoft Azure cloud services time dummy hedonic model using CPU characteristics with turbo frequency, second quarter 2018 to second quarter 2019| Variable | Q2 2018–Q3 2018 | Q3 2018–Q4 2018 | Q4 2018–Q1 2019 | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0383 | 0.0441 | -0.0018 | -0.0036 |
|---|
Standard error | 0.0240 | 0.0273 | 0.0269 | 0.0273 |
|---|
Ln(Memory) | 0.3266[1] | 0.2633[1] | 0.2633[1] | 0.2587[1] |
|---|
Standard error | 0.0223 | 0.0189 | 0.0203 | 0.0206 |
|---|
Ln(Storage) | 0.253[1] | 0.2806[1] | 0.2681[1] | 0.2726[1] |
|---|
Standard error | 0.0214 | 0.0239 | 0.0275 | 0.0279 |
|---|
SSD | 0.2515[1] | 0.1465[1] | 0.1569[1] | 0.1481[1] |
|---|
Standard error | 0.0295 | 0.0242 | 0.0265 | 0.0270 |
|---|
Ln(Turbo frequency) | -3.5819[1] | -1.515[1] | -0.9662[1] | -0.9857[1] |
|---|
Standard error | 0.3235 | 0.3951 | 0.2928 | 0.2934 |
|---|
Ln(Cache) | [2] | -0.2078[1] | -0.2266[1] | -0.2445[1] |
|---|
Standard error | [2] | 0.0742 | 0.0815 | 0.0826 |
|---|
Ln(TDP) | 0.4197[1] | 0.662[1] | 0.6913[1] | 0.7073[1] |
|---|
Standard error | 0.0273 | 0.0639 | 0.0653 | 0.0659 |
|---|
Windows | 0.4379[1] | 0.4052[1] | 0.4198[1] | 0.421[1] |
|---|
Standard error | 0.0269 | 0.0247 | 0.0247 | 0.0250 |
|---|
Observations | 132 | 138 | 152 | 152 |
|---|
Adjusted R-squared | 0.9871 | 0.9859 | 0.985 | 0.9846 |
|---|
Unlike AWS, there is no major difference between the models with base frequency and the models with turbo frequency. Both sets of models have similar time dummy variables, and the magnitude and sign of base frequency and turbo frequency are similar in the respective models.
For Google Cloud, all of the cloud services in a given region use the same microprocessors. We constructed our dataset from two different regions to provide a mix of microprocessors. From the second quarter of 2017 to the first quarter of 2019, there were no changes in products or prices. With this lack of change, there is no price change for a hedonic model to capture. In the second quarter of 2019, there was a change in the frequency of the microprocessors in one of the regions. We used the statistical learning algorithm with both frequency variables, but in both cases the frequency variables were not selected. Because we know exactly what changed with the cloud services, we estimated models with both frequency variables to see if they yielded any appreciable quality adjusted price change. There was a strong correlation between the region variables and the frequency variables, so we omitted the region variables. Likewise, cache and TDP were strongly correlated, so we omitted TDP. Below are results for the model using base frequency and turbo frequency. The base frequency models evaluated by the statistical learning technique take this form:
The turbo frequency models take this form:
Table 11. Google cloud services time dummy hedonic model using CPU characteristics with base frequency, first quarter 2019 to second quarter 2019)| Variable | Q1 2019–Q2 2019 |
|---|
Quarter dummy | -0.0011 |
|---|
Standard error | 0.0174 |
|---|
Ln(Memory) | 0.1850[1] |
|---|
Standard error | 0.0087 |
|---|
Ln(Base frequency) | -0.0413 |
|---|
Standard error | 0.3790 |
|---|
Ln(Cache) | 0.8172[1] |
|---|
Standard error | 0.0102 |
|---|
Windows | 0.5034[1] |
|---|
Standard error | 0.0142 |
|---|
Observations | 152 |
|---|
Adjusted R-squared | 0.9956 |
|---|
Table 12. Google cloud services time dummy hedonic model using CPU characteristics with turbo frequency, first quarter 2019 to second quarter 2019| Variable | Q1 2019–Q2 2019 |
|---|
Quarter dummy | 0.0003 |
|---|
Standard error | 0.0143 |
|---|
Ln(Memory) | 0.1850[1] |
|---|
Standard error | 0.0087 |
|---|
Ln(Turbo frequency) | -0.0133 |
|---|
Standard error | 0.0873 |
|---|
Ln(Cache) | 0.8172[1] |
|---|
Standard error | 0.0102 |
|---|
Windows | 0.5034[1] |
|---|
Standard error | 0.0142 |
|---|
Observations | 152 |
|---|
Adjusted R-squared | 0.9956 |
|---|
The models are remarkably similar except for the quarter dummy and frequency coefficients. This similarity suggests that the change in microprocessor frequency in the second quarter of 2019 caused negligible quality adjusted price change and it helps illustrate why the statistical learning algorithm did not select either frequency variable.
Conclusion
Our results show that a time dummy hedonic model can estimate quality adjusted price change for cloud computing services. One of the key drivers of quality change for cloud services is technological improvements in microprocessors. We demonstrate that models using microprocessor characteristics can produce similar results as models using AWS’s ECU measure. This result is important for validating the use of microprocessor characteristics in cloud services models.
We have also applied the statistical learning method used by Sawyer and So. This method of specification selection allows the models to change over time as cloud services change. It also makes our method of choosing a specification transparent to our data users which should bolster the perception of the cloud models. Because the statistical learning method consistently selected most variables, a future hedonic model for cloud services for use in the PPI may just use all variables without being overfit.
If, at a future time, BLS decides to implement a hedonic model for cloud services in the PPI, our work will offer another way to quality adjust prices in the PPI. What will ultimately determine the type of model we use is the data we receive from respondents, but this article validates the use of hedonics for cloud services. This validity is not only shown in the results of the models, but also in the process of collecting data, estimating the models, and interpreting the results. For production use in the PPI, having a viable process for developing a model is necessary for implementation as much as the performance of the model. With a hedonic model for cloud services, BLS will have another method available for PPI estimates that accounts for quality change in an industry that experiences rapid technological progress and has become crucial for the information technology sector.
United States Department of Labor
