Lesson 010 · AWS Learning Path

AWS 010: CapEx, OpEx and pay-as-you-go

Anil Jalela · Published Jul 5, 2025 · 7 min read

The architecture problem

A company needs capacity for a three-year product:

• normal demand needs two application servers;
• a weekly four-hour event needs ten servers;
• future demand is uncertain;
• the finance team wants predictable cost;
• the engineering team wants rapid experimentation.

An architect must compare more than purchase price. Capacity, utilization, labor, facilities, licensing, support, data transfer, resilience, recovery, and the cost of change all affect the decision.

What you will be able to do

By the end of this lesson, you can:

1. explain capital expenditure and operating expenditure in practical terms;
2. explain consumption pricing without claiming cloud is always cheaper;
3. identify common AWS pricing dimensions;
4. calculate baseline and burst usage;
5. distinguish price, cost, value, and total cost of ownership;
6. identify when commitment and predictability can conflict with flexibility;
7. create a simple cloud-economics decision record.

CapEx and OpEx

Capital expenditure, CapEx

CapEx commonly refers to acquiring or improving a long-lived asset.

Examples can include:

• purchasing servers;
• purchasing storage systems;
• building or improving a data-center facility;
• acquiring network hardware.

The organization commits money before knowing exact future use. Accounting treatment, depreciation, taxes, and capitalization rules depend on jurisdiction and organizational policy. An architect supplies technical and usage evidence; qualified finance professionals determine accounting treatment.

Operating expenditure, OpEx

OpEx commonly refers to ongoing costs of operating the business.

Examples can include:

• monthly service consumption;
• support;
• electricity;
• connectivity;
• facilities operation;
• staff time;
• subscriptions.

Cloud can shift portions of infrastructure spending from large upfront purchases to variable service consumption. It does not turn every technology cost into one simple accounting category.

Pay-as-you-go is a pricing behavior

In a consumption model, charges track service-specific usage dimensions.

Possible dimensions include:

• time a compute resource runs;
• provisioned compute or database capacity;
• gigabyte-months of storage;
• number of requests;
• data processed;
• data transferred;
• throughput;
• messages;
• public IPv4 address time;
• software license or marketplace fees;
• support plan.

The unit differs by service. "Pay only for what you use" does not mean:

• every resource stops when the application is idle;
• every dependency is free;
• data transfer is always free;
• an unused provisioned resource has no cost;
• a budget automatically stops spending.

Price, cost, and value

Price

The provider's charge per pricing dimension.

Cost

The total expenditure created by architecture and operation.

Value

The business outcome produced for that cost.

Unit economics

Cost divided by a meaningful business unit:

cost per learner
cost per completed assessment
cost per order
cost per processed document
cost per active customer

A design with a lower monthly bill can still deliver worse value if it is unreliable, slow to change, or expensive to operate.

Total cost of ownership

An on-premises comparison can include:

• hardware purchase and refresh;
• spare capacity;
• facilities, power, and cooling;
• network circuits;
• software licenses;
• support contracts;
• backup and recovery environment;
• security tools;
• staff operation;
• procurement lead time;
• downtime and delayed delivery;
• decommissioning.

A cloud comparison can include:

• service consumption;
• support;
• data transfer;
• public addresses;
• logs and monitoring;
• backup and replication;
• licenses;
• connectivity;
• engineering and operations;
• migration;
• commitments;
• idle or orphaned resources.

Do not compare an on-premises server purchase with only one EC2 instance price. Compare the complete service outcome over the same period.

Practical calculation: baseline and burst demand

Use 730 hours as a planning approximation for an average month. Billing uses actual service rules and actual time, not this planning shortcut.

Fixed-capacity design

Ten servers run all month to cover the event peak:

10 servers x 730 hours = 7,300 server-hours per month

Elastic design

Two baseline servers run all month:

2 x 730 = 1,460 baseline server-hours

Eight additional servers run for four hours each week. Use 4.33 weeks per average month:

8 x 4 x 4.33 = 138.56 burst server-hours

Total:

1,460 + 138.56 = 1,598.56 server-hours per average month

Capacity-hour difference:

7,300 - 1,598.56 = 5,701.44 server-hours

This does not prove the elastic design is cheaper. It shows why utilization matters. You must still price:

• selected compute;
• storage;
• load balancing;
• data transfer;
• public IPv4;
• logs;
• backup;
• database;
• support;
• engineering and risk.

Create the economics worksheet

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-010"

Create:

$HOME/nitwings-aws/evidence/aws-010/cloud-economics.md

Use:

# Cloud economics decision

## Demand
Baseline:
Peak:
Peak duration:
Growth uncertainty:

## Fixed-capacity usage
Calculation:

## Elastic usage
Baseline calculation:
Burst calculation:
Total:

## On-premises cost categories

## Cloud cost categories

## Business value
Speed:
Risk:
Availability:
Operations:

## Decision

## Assumptions that need validation

## Metric
Chosen cost-per-business-unit metric:

Reproduce the calculations and explain which assumptions might be wrong.

Use AWS Pricing Calculator safely

AWS Pricing Calculator is an estimate, not an invoice.

1. Open AWS Pricing Calculator.
2. Do not sign in if the public estimate workflow is sufficient.
3. Create a new estimate.
4. Add one simple compute-related service only for exploration.
5. Select your recorded course Region.
6. Inspect every pricing input.
7. Note which costs are included and which workload components are absent.
8. Save no secret or personal information in the estimate.
9. Record the estimate date because prices and service options change.

This early exercise is not an EC2 selection lab. Its purpose is to see how assumptions become pricing dimensions.

Evidence:

• Region;
• service;
• usage assumptions;
• purchase or consumption option;
• estimated monthly amount;
• excluded components;
• calculation date;
• statement that the estimate is not a bill or guarantee.

Variable use and commitment

Pay-as-you-go maximizes flexibility but is not the only AWS pricing pattern.

Later lessons cover:

• On-Demand consumption;
• Spot capacity;
• Savings Plans;
• Reserved Instances;
• Capacity Reservations;
• service-specific commitments and tiers.

General trade-off:

More flexibility <----------------------> More commitment
Often higher unit price                  Potential lower eligible unit price
Less usage obligation                    Greater forecast and governance need

A discount is not a saving if the commitment exceeds useful consumption.

Cloud Financial Management

Cost optimization is an ongoing engineering and management discipline.

It includes:

• financial ownership;
• cost allocation;
• usage visibility;
• budgets and anomaly response;
• selecting cost-effective resources;
• matching supply to demand;
• reviewing commitments;
• measuring unit economics;
• optimizing over time.

Architecture teams, product teams, operations, security, and finance all contribute.

Common misconceptions

Troubleshooting a surprising estimate

Check your understanding

1. What is the difference between price and cost?
2. Why is peak capacity often wasteful for variable demand?
3. Does an AWS estimate guarantee the bill?
4. Why can a commitment discount increase total waste?
5. Name five cost categories that a single compute price omits.

Expected answers

1. Price is a charge per unit; cost is the complete expenditure created by the architecture and operation.
2. Capacity sits unused outside the peak.
3. No.
4. The organization can commit to more eligible usage than it actually needs.
5. Any five valid categories such as storage, transfer, addresses, load balancing, logs, backup, database, support, licenses, operations, or recovery.

Architecture decision points

Before recommending a cost model:

• quantify baseline and variable demand;
• define availability and recovery;
• identify service pricing dimensions;
• include every dependency;
• value engineering and operational effort;
• identify uncertainty;
• measure a business unit;
• model on-demand and commitment options;
• define who reviews actual use;
• plan decommissioning.

Do not optimize cost by violating security, reliability, performance, or business requirements.

Completion gate

You pass AWS 010 when:

• the fixed and elastic calculations are correct;
• cloud-economics.md includes both on-premises and cloud cost categories;
• a pricing estimate records assumptions and exclusions;
• you can distinguish price, cost, value, TCO, and unit economics;
• you can explain why pay-as-you-go is not a cost guarantee;
• no AWS service resource was created.

Retain the worksheet for AWS 022 and later cost-optimization lessons.

Official sources

• AWS Well-Architected cost optimization design principles
• AWS Well-Architected cost optimization definition
• AWS overview: Six advantages of cloud computing
• AWS Pricing Calculator
• Guidance for Cloud Financial Management on AWS