Cloud Economics and Serverless

Paying for what you use

Cloud economics rests on one sentence. Cloud computing uses a consumption-based model in which customers pay for the IT resources they use. Instead of buying and maintaining datacenter infrastructure, a customer can rent compute power and storage, then release those resources when they are no longer needed.

Compare the two ways of obtaining the same capacity:

This approach lets you avoid idle capacity costs when you release resources after demand falls.

Two abilities follow directly from that, and they are the ones scenarios are built on. A consumption-based model can avoid upfront hardware and datacenter costs. It also lets a customer add resources when demand rises and release resources when demand falls.

The financial effect follows actual resource use rather than a permanently installed capacity level. That is the difference worth carrying into the exam: spending tracks a curve of real usage, not a flat line drawn by a purchase order signed a year earlier.

A seasonal business shows it most clearly. Capacity goes up for the peak, comes down afterwards, and the bill follows the same shape.

Capital and operational expenditure

Traditional IT budgeting splits spending into two categories, and the cloud lands squarely in one of them.

Capital expenditure is upfront spending on physical infrastructure such as servers, network hardware, and datacenter space. Operational expenditure is ongoing spending on services over time.

Because cloud services are paid for as they are consumed, cloud computing is classified as an operational expense.

The test is when and for what, not who sends the invoice. An upfront purchase of physical infrastructure is capital expenditure even if it is financed over several years. A charge that accrues while a service is being used is operational expenditure even if it turns out to be large.

This is also why the classification does not change with size. A single virtual machine billed by the hour and an estate of thousands are both operational spending, because both follow consumption. And buying one server for a rack is capital spending, because the money went into physical infrastructure before anything ran on it.

The capacity-planning problem it solves

Traditional capacity planning requires an estimate of future resource needs, and an estimate can miss in either direction. Both misses cost money, but they cost it differently.

Overestimating creates spending on infrastructure that sits idle, while underestimating can cause degraded application performance.

The asymmetry is in the repair. Correcting an underestimate requires ordering, installing, and provisioning more hardware, power, and cooling, a sequence measured in weeks while the application keeps running slowly.

Cloud reduces the need to buy peak capacity in advance because resources can be adjusted as demand changes; teams still forecast demand, cost, quotas, and performance needs.

This is why "we sized it wrong" means something entirely different on each side. In a traditional datacenter it is a procurement project; in a consumption-based model it is an adjustment.

Pay-as-you-go pricing

Cloud providers use a pay-as-you-go pricing model. It is the commercial expression of everything above: you are billed for the services you consume rather than for a capacity level you declared in advance.

Paying for consumed services helps customers do three things:

• Manage operating costs, because spending follows the workload instead of a fixed asset.
• Use infrastructure more efficiently, because unused capacity can be released rather than absorbed.
• Scale when workload needs change, in either direction.

There is a matching obligation on the other side of the deal. The provider maintains the underlying power, cooling, hardware, and networking.

That is what the customer is really buying out of: not just the servers, but the facility around them and the work of keeping it running. A team that moves to pay-as-you-go stops budgeting for cooling capacity and starts budgeting for consumption.

Note the limit, because scenarios exploit it. Pay-as-you-go makes costs manageable and proportional; it does not make them disappear or remove the need to plan them.

Serverless execution with Azure Functions

A traditionally provisioned virtual machine or customer-managed container can remain allocated between events, so it keeps costing money while it sits idle. Serverless options, including Functions and serverless container platforms, can scale with event-driven demand.

Azure Functions is an event-driven, serverless compute option that does not require maintaining virtual machines or containers. On eligible consumption-based hosting plans, a function app can scale to zero while idle. Other hosting plans can keep instances allocated or always ready.

What counts as an event is specific. Common triggers include a REST request, a timer, or a message from another Azure service.

On event-driven hosting plans, Azure Functions also scales automatically according to demand. That makes it a reasonable fit when demand is variable rather than steady. A Dedicated plan uses manual scaling or autoscale instead.

On eligible consumption-based hosting plans, charges follow executions and resource consumption, and the app can scale to zero while idle. Premium and dedicated hosting can retain allocated or always-ready instances and use different billing models.

One behavioral detail completes the picture. Stateless behavior is the default: a function acts as though it restarts on every event. If one event adds a book to a shopping cart and the next event starts the checkout, a stateless function has already forgotten the book. When state is needed, Durable Functions passes context through the function to track prior activity, so the whole sequence is remembered.

When serverless is the right shape

Serverless is appropriate when the team wants to focus on code rather than the underlying platform or infrastructure, and the work responds to events.

Microsoft calls these common uses, not strict rules. Functions can also run continuously on a Premium plan. Look for two signals that usually appear together:

The contrast is what makes it examinable. A traditionally provisioned VM or customer-managed container can remain allocated between events. Serverless options, including Functions and serverless container platforms, can scale with event-driven demand.

The direction of the clue matters too.

Key takeaways

• Consumption-based cloud spending follows the resources used, so capacity can be rented and released instead of purchased and left idle.
• Capital expenditure is upfront infrastructure spending; operational expenditure is ongoing service spending, and cloud services paid for as they are consumed are an operating expense.
• Cloud capacity can be added as demand rises and released as demand falls, which removes the traditional planning risk: overestimating pays for idle infrastructure, and underestimating degrades performance until more hardware, power, and cooling are ordered, installed, and provisioned.
• Azure Functions runs code in response to events. On eligible consumption-based plans it can scale to zero while idle and charges follow executions and resource consumption; other plans can retain allocated capacity.