Cloud economics: fixed against variable costs, on-premises costs and economies of scale

Why this matters

Most conversations about moving to the cloud start with money, and most of them go wrong in the same place: someone compares the monthly AWS bill with the purchase price of a server and concludes the cloud is expensive. The server's price was never the whole cost. The building, the power, the cooling, the maintenance contracts and the people who keep it all running were simply sitting in other budgets. A manager who cannot name those costs cannot make a fair comparison, and a salesperson who cannot explain them cannot answer the objection.

The second reason is that the cloud changes when you pay, not only how much. A company that used to sign off a large hardware purchase every few years now receives a bill every month that rises and falls with use. That is a real advantage, and it also creates new work: someone has to watch the spending. A junior engineer who leaves test servers running over a weekend learns this quickly.

This lesson gives you the vocabulary for both halves: what an on-premises estate really costs, and what changes when those costs become variable. Lesson 5 continues the topic with licensing, rightsizing and automation.

The lesson

Aspects of cloud economics

Cloud economics is the study of what a workload costs to run, and how that changes when it moves to the cloud. It covers more than price lists. It includes who owns the hardware, when money is spent, how much capacity sits unused, how much staff time goes on routine maintenance, and how quickly a business can try something new.

Two pairs of terms recur throughout.

• Capital expenditure (CapEx) is money spent up front on physical assets that the company then owns, such as servers, storage arrays, network equipment or a new server room. The asset is usually depreciated, which means its cost is spread across its useful life in the accounts.
• Operational expenditure (OpEx) is the ongoing cost of running the business, paid as it is consumed. A monthly bill for Amazon EC2 hours, a charge for each AWS Lambda request, or a charge for each gigabyte stored in Amazon S3 each month is OpEx.
• A fixed cost stays the same however much you use what you bought. A variable cost rises and falls with usage.

Moving to AWS generally shifts spending from CapEx towards OpEx, and from fixed towards variable. AWS states its pricing model simply: pay as you go, for what you use, with no long-term commitment required for the default options. Commitment-based discounts exist, and lesson 23 covers them, but they are a choice rather than the starting point.

AWS often summarises the financial case for the cloud as a short list of advantages. Two of them belong to this lesson: trade fixed expense for variable expense, and benefit from massive economies of scale. Others, such as stopping guessing about capacity and no longer spending money to run and maintain data centres, appear below because they are about cost too.

Cost savings of moving to the cloud

The savings come from several places at once.

• No up-front hardware purchase. A start-up can launch without raising capital to buy servers. It pays monthly for what it runs.
• No hardware refresh cycle. On-premises servers reach the end of their supported life every few years and must be replaced, which is a repeated capital cost. On AWS, AWS owns and replaces the physical hardware.
• No paying for idle peak capacity. This is covered under fixed and variable costs below.
• Cheap experiments. A team can build a test environment for a new idea, run it for a few days and delete it. It pays only while the resources exist. On-premises, the same test would need hardware bought in advance, and the company would be left holding it if the idea failed.
• Staff time. AWS takes on the work of racking servers, replacing failed disks, running the building and guarding it. AWS calls this undifferentiated heavy lifting: work every company must do but that does not set any company apart. The staff are not removed; they move to work that serves the company's own customers.

Two cautions keep these claims honest. First, the company does not stop paying for compute. It pays for it differently. Second, AWS does not take over everything. On Amazon EC2 the customer still patches its own guest operating system and secures its own applications, under the shared responsibility model taught in lesson 6.

Fixed costs compared with variable costs

An on-premises data centre is mostly fixed cost. The building lease is paid whether the servers inside are busy or idle. The hardware was bought whether it is used or not. That forces a company to forecast demand before it buys, and a forecast has two ways to be wrong.

• Over-provisioning. The company sizes its servers for the busiest week of its year. For the rest of the year most of that capacity sits idle, and the company still pays for the hardware, the power and the space.
• Under-provisioning. The company sizes for average demand. When demand rises well above average, the servers cannot keep up, users see slow or failed service, and the business can lose sales and customers.

AWS describes the cure as stopping guessing about capacity. With elastic, usage-based capacity, a retailer can add instances for its peak season and release them afterwards, and its compute costs fall when it releases them. The costs follow demand instead of a forecast.

Variable cost has its own discipline, and scenario questions often turn on it. Usage-based pricing charges for what runs, not for what is useful. An On-Demand EC2 instance is billed for the time it runs, whether it serves any traffic or none. AWS does not stop idle instances on the customer's behalf; the customer must stop them, or automate stopping them. So a move from fixed to variable costs creates a new task for the finance team: monitoring spending that changes each month, for example with budgets and alerts. The tools for that, including AWS Budgets and AWS Cost Explorer, are covered in lesson 24.

When a question describes a company that wants to avoid spending capital up front and pay only for what it uses each month, the phrase it is reaching for is trading fixed expense for variable expense.

Costs associated with on-premises environments

To compare on-premises and cloud costs fairly, list everything the on-premises estate needs for as long as it runs, not only what it cost to buy. A full list usually includes:

• Hardware: servers, storage, network devices, and the spares kept for failures.
• Facilities: the building or the leased floor space, power, cooling, fire suppression and physical cabling.
• Physical security: guards, access control, cameras and the staff who run them.
• Maintenance contracts for the hardware, and the time to install, rack and repair it.
• The replacement cycle, as hardware ages out of support.
• Software licences for the operating systems, databases and tools that run on the hardware.
• People: the staff who operate, patch and monitor all of the above.

The full figure across the life of the hardware is often called the total cost of ownership (TCO). A budget built only from purchase prices understates it, and power, cooling and floor space are the items most often left out.

After a full move to AWS, some of these costs disappear for the company because AWS carries them for its own data centres: hardware maintenance contracts, the building, physical security, and the hardware refresh. Others remain in a new form. Software licences may still be needed, and lesson 5 explains the options. Staff are still needed for the parts the customer secures and operates.

Be careful with distractors that list AWS charges as on-premises costs. Per-request Lambda charges, Amazon S3 storage charges, EC2 instance hours and fees for data transferred out of AWS are cloud costs, so they never belong in an estimate of what an on-premises estate costs. On data transfer, AWS generally does not charge for data coming in to AWS, and does charge for data going out; check the pricing page of each service for the current terms. To estimate the cloud side of the comparison, use the AWS Pricing Calculator rather than remembered figures, because prices change.

Economies of scale and the savings they bring

Economies of scale is the general principle that unit costs fall as volume rises. AWS buys hardware, power and network capacity at a scale no single company can match, and it runs its data centres with the efficiency that scale allows. Because it aggregates the usage of a very large number of customers, its costs per unit are lower, and AWS passes that on in the form of lower pay-as-you-go prices. AWS has reduced its prices many times over its history for this reason.

The benefit reaches every customer, whatever its size. A small company cannot negotiate the hardware discounts a large enterprise receives, but on AWS it gets the same pay-as-you-go prices as any other customer, and those prices already reflect AWS's purchasing power. That is the clearest sign in a scenario question that the answer is economies of scale.

Know what economies of scale do not mean:

• They do not mean a fixed monthly price whatever you consume. AWS pricing follows usage.
• They do not mean free dedicated hardware. Dedicated options exist, and they cost more.
• They do not mean only large customers get a lower price, or that a contract is needed to get any discount.

Economies of scale explain why AWS prices are low. Trading fixed for variable expense explains when and how a customer pays. Many questions place both in the options, and the stem tells you which: purchasing power points to economies of scale; avoiding up-front spending points to variable expense.

What the exam is really asking

Questions on this topic are usually short scenarios with one telling phrase. "No capital up front" or "pay only for what it uses" points to variable expense. "Cannot negotiate discounts" or "lower prices because of aggregated usage" points to economies of scale. "Sized for the peak" points to idle capacity, and "sized for the average" to lost customers when demand spikes. A list of building, power, cooling and guards is the on-premises side of the ledger, and anything with an AWS service name in it is not.