They surely have an enormous AWS bill from doing all the segment matching jiggery pokery. The statement they put out even mentioned wanting to cut back on backend processing costs. Maybe they've scaled it back too far.
I helped a friend with something similar years ago. They had a compute intensive problem that they offloaded to the cloud and were racking up significant bills for. They poured thousands of person hours into minimising this, they rebuilt their compute package so it could be run on AWS, Azure and GCE clouds and then wrote huge amounts of support scripting to optimise the usage based on cheap servers available with spot pricing, etc, trying to make sure it was as cheap as possible (e.g. suddenly a chunk of Azure opens up much cheaper than the existing AWS hosts so switch new work units over to Azure, etc). The layers of abstraction they'd had to implement to do this were quite impressive.
When I looked at it I asked them if they'd looked at optimising the actual code they were running. Blank faces. Nope. "It's as efficient as we think we can make it." Within a couple of hours we'd found a few ways to make it 25% more efficient. This alone saved more than they'd managed to save by server pricing optimisation. In a couple of days we'd made it ~80% more efficient than it was previously.
One bit of code they had relied upon finding the standard deviation of a large set of numbers that came from their computed figures (small set of inputs to the compute engine, big calculations generating huge amounts of data that was then boiled down to a few small numbers, small output back). Because they didn't know any better they'd assumed that you can only compute the SD of a series of numbers with two passes through the numbers - one to find the mean and then a second pass to compute the SD based on that mean. A little bit of maths showed that you can compute the SD of a dataset with one pass through it (computing two different values along the way and then performing a simple calculation at the end). Just that simple thing was responsible for a huge chunk of the eventual savings.
Who knows how well optimised Strava's code is, but spending $$$$ on more AWS is sadly often a lot easier to justify than spending $$ on a thorough code review.
([EDIT] I also introduced them (not Strava) to the concept of a hybrid system where you have a certain amount of processing capacity in house and then use the cloud for peak/burst/overflow capacity. No-one likes to run servers in house but we showed that we could take the typical baseline load (somewhere below 50%) and run it for a fraction of the cost of the cloud providers with some relatively cheap commodity hardware stuck in the server room of their office even assuming the hardware would be complete toast and thrown away after just 2 years. It was also architected so that turning off their office based processing power would just mean that it all defaulted back to the original case of running in AWS/Azure/GCE so they weren't done over by localised network issues, power failures, office moves or someone accidentally hitting the BRS.)
