Why companies pay for this

Buy vs rent

Before the cloud, launching a web app meant buying servers: pay thousands up front, wait weeks for delivery, install them in a rented rack, hire someone to replace failed disks at 3 a.m. That up-front spending is called capital expenditure (capex).

The cloud converts it to operational expenditure (opex): no purchase, no waiting, pay a bill each month for exactly what you used, stop paying the moment you turn things off.

Renting is not always cheaper per unit. AWS charges a markup for the flexibility. The reason companies pay it is what the flexibility lets them do, which the next example puts in numbers.

Buying against renting over three years

This compares a $1,200 server, plus $30 a month for power and hosting, against a similar cloud server at $25 a month, over 36 months.

buy_total=$((1200 + 30 * 36))
rent_total=$((25 * 36))
echo "Buy and run your own server for 3 years: \$$buy_total"
echo "Rent a cloud server for 3 years: \$$rent_total"

Output

Buy and run your own server for 3 years: $2280
Rent a cloud server for 3 years: $900

Renting wins here, and it wins by a lot. The reason is that the $1,200 purchase price is paid whether or not the machine is ever busy, while the $30 monthly running cost turns out to be higher than the entire cloud bill.

Change the numbers and the answer changes with them. The exercise at the end of this lesson finds the crossover point for a more expensive server, and the result is very different.

Elasticity: the real reason

The bigger win is elasticity: changing how much you rent, minute by minute.

Imagine a ticket shop that needs 2 servers most days and 100 servers for one hour when a tour goes on sale. Buying means owning 100 servers that sit idle 99.9% of the time. Renting means paying for 100 servers for one hour, then going back to 2.

But the arithmetic flips for big, steady workloads. If you know you will run the same 500 servers flat-out for years, owning gets cheaper than renting, which is why a few large companies famously moved off the cloud. For a small or growing app, rent wins.

The strongest argument for a spiky workload

For a startup whose Saturday-night traffic is 10 times the rest of the week, the strongest argument is elasticity, renting extra servers only for the Saturday peak.

They can rent ten times the capacity for a few hours a week and pay only for those hours. Owning enough hardware for the peak would leave it idle six days out of seven, and that idle hardware still cost full price and still needs power, space, and someone to maintain it.

One tempting but false claim is worth naming: renting is not cheaper per unit. AWS charges a markup, and for a flat, predictable workload owning can win. Elasticity is what makes the markup worth paying, and a workload with a 10x weekly spike is the textbook case.

Finding the month where buying wins

An expensive server rents for $70 a month, or costs $1,200 up front plus $30 a month to run. This loop finds the first month in which buying has cost less in total.

month=1
while [ $((70 * month)) -le $((1200 + 30 * month)) ]; do
  month=$((month + 1))
done
echo "Buying becomes cheaper in month $month"

Output

Buying becomes cheaper in month 31

Reading the loop

• The rent total is 70 * month and the buy total is 1200 + 30 * month. The loop continues while rent is still less than or equal to buy, so it stops at the first month rent is strictly greater.
• In bash, numbers are compared with -le inside [ ] and computed inside $(( )). Using < there would redirect a file instead of comparing.
• Month 31 is two and a half years out, which is longer than many startups keep the same architecture. That is the practical lesson: a crossover point far in the future is a weak argument for buying, because the plan will have changed before you get there.