Follow the CAPEX: Cloud Table Stakes 2018 Edition

By

After recently receiving a non-ironic lecture on Twitter that CAPEX investment is the best tell for cloud competitiveness, I’m starting to think Follow the CAPEX™ is building a following. Beyond the circular wisdom of Twitter, awareness is growing of the importance of CAPEX as both a leading indicator of the ability to compete at hyper-scale and also confirmation of customer success. Tech earnings press coverage now regularly highlights CAPEX investments.

Despite becoming perhaps uncomfortably mainstream, here are the CAPEX numbers and some commentary for 2018 (see previous 2016 and 2017 installments for the hyper-scale clouds as well as the hyper-scale clowns). There are no surprises, just up and ever further to the right.

The three hyper-scale public cloud companies – Amazon, Google, and Microsoft – spent over $68 billion on CAPEX between them in 2018. That is not all for cloud infrastructure (and maybe not even a majority of it), as those companies have other, material CAPEX spend, but it is directionally indicative. All three companies again registered all-time CAPEX highs this year. The combined total is on the order of 5% of total non-residential fixed investment in the US (one wonders whether hand-ringing about relatively disappointing fixed investment across the broader economy is attributable at least in part to the economies of scale of the public clouds).

image

In 2018, Amazon spent $27.6 billion, Google $25.1 billion, and Microsoft $15.8 billion on CAPEX (including capital and build-to-suit leases for both Amazon and Microsoft). Those are year-over-year increases of 19%, 91%, and 39% respectively (Google went nuts on CAPEX in 2018).

image

The three companies’ cumulative CAPEX spend since 2000 is over $270 billion, with over $116 billion of it in the last two years.

image

After being almost identical last year, we see a big spike in CAPEX as a percentage of revenue at Google to over 18%.

Amazon

Last year’s commentary on Amazon still applies:

The top line Amazon CAPEX number is pretty useless at this point for insights about AWS infrastructure spending. There are just so many other things consuming CAPEX – distribution centers, warehouse robots, grocery stores, cargo jets, office buildings, biospheres, a hyper-segmented line of talking alarm clocks, etc. – that AWS infrastructure is almost certainly a minority of the total company CAPEX.

image

This year I broke out both the capital leases and the build-to-suit leases in addition to the general CAPEX numbers. Historically, Amazon’s CAPEX numbers have overstated their CAPEX relative to their competitors because it has included capitalized software development costs. But Amazon has stopped this practice and now says this is “not significant”.

My theory has been the capital leases are the best proxy for AWS spending, as the lease term corresponds nicely with the useful life of servers. Amazon’s CFO on their most recent conference call lends some strong confirmation to this theory:

And then on capital, especially infrastructure capital, if you use the capital lease slide as maybe an indicator for what we have invested into our AWS business to support infrastructure and global expansion, that number grew 10% last year, when it had grown 69% in 2017.

We can compare the capital lease expenditures and AWS revenues, and the numbers line up reasonably well:

image

The build-to-suit leases are for buildings. These can include office space, warehouses and retail outlets, as well as datacenters. My guess is only a fraction of this expenditure goes towards data center buildings, but I have no hard data.

Google

image

Google obviously was offended when I wrote this about Amazon last year:

But at a company level, the spend is staggering and is now bigger than any US company I can find except AT&T (and Amazon should pass them this year assuming very low double digit CAPEX growth).

While Amazon did pass AT&T in CAPEX spend in 2018 (there evidently are real efficiencies to only building a fake 5G network as AT&T’s CAPEX actually declined in 2018), Google nearly doubled their CAPEX spend from 2017 to over $25 billion, and almost caught up to Amazon. They bought a huge piece of real estate in New York City, but that was still a mere $2.4 billion. Google’s incremental CAPEX spend in 2018 is about what cloud pretender Oracle has spent on CAPEX throughout their entire history.

Google’s three to four year cycle for CAPEX remains intact, which looks like another case of the useful life of servers showing up in the financials. Further validating this cycle, Google’s CFO said growth of CAPEX spend will “moderate quite significantly” in 2019.

Google’s CAPEX for its “other Bets” continues to plummet to the point of irrelevance, clocking in at a mere $181 million, down from almost $1.4 billion two years ago. That bodes poorly for the prospects of a space elevator from Google and their opportunity to atone for pioneering the all-seeing surveillance economy.

I think search, ads, and YouTube continue to dominate Google’s CAPEX spending. Google Cloud Platform uses a small portion of their common infrastructure and it is hard to find a material revenue bump for it given everything else in the same reporting segment (Android app purchases via the Play Store and their hardware business which can add revenue, if not margin, in big chunks). Thus, it is hard to believe GCP is growing its share of Google’s overall infrastructure.

Microsoft

image

Microsoft still has the cleanest CAPEX numbers from a cloud standpoint (i.e. most of their CAPEX is for cloud infrastructure), though their distractions are growing with new hardware products likely in capital-intensive stages (HoloLens, Xbox, Surface) and a major campus building project getting under way. They continue to grow their investment materially, with a focus on having the broadest global footprint.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Get Updates By Email

Discover more from Platformonomics

Subscribe now to keep reading and get access to the full archive.

Continue reading