Cloud Economics, FinOps and Investment Decisions

Introduction

Cloud computing changes the economics of information technology. Traditional data-centre decisions usually require substantial capital expenditure before demand is known. Cloud services replace much of that commitment with metered, elastic operating expenditure. This shift can improve agility and reduce idle capacity, but it does not automatically reduce total cost. Poorly governed cloud environments can accumulate unused resources, excessive data-transfer charges, duplicated platforms, and commitments that no longer match demand.

Cloud economics is therefore concerned with more than price comparison. It examines how architectural choices, consumption patterns, financial controls, service quality, risk, and business value interact. FinOps provides the operating discipline for managing these interactions. It combines engineering, finance, procurement, security, and business ownership in a continuous cycle of visibility, optimisation, and accountability.

For postgraduate practitioners, the central question is not simply “How can cloud cost less?” It is: “Which combination of technology, commercial model, operating practice, and risk produces the greatest sustainable business value?”

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain major cloud pricing and purchasing models.
2. Compare cloud and on-premises economics using total cost of ownership.
3. Calculate basic return on investment, unit economics, and cost-allocation measures.
4. Design chargeback and showback arrangements.
5. Apply FinOps principles to visibility, allocation, optimisation, and forecasting.
6. Evaluate rightsizing, commitment planning, demand forecasting, and workload placement.
7. Balance cost with performance, resilience, security, compliance, and business value.
8. Critically assess the limitations and governance implications of cloud financial decisions.

1. The Economic Logic of Cloud Computing

1.1 Capital expenditure and operating expenditure

Capital expenditure (CapEx) is spending on assets expected to provide benefits over several accounting periods, such as servers, storage arrays, facilities, and network equipment. Operating expenditure (OpEx) is spending incurred in delivering ongoing services, including electricity, support, software subscriptions, and consumption-based cloud services. Accounting treatment varies by jurisdiction, contract, and policy; cloud consumption should not automatically be assumed to be OpEx in every legal or accounting context.

Cloud services often transform infrastructure into a variable-cost model. A customer may pay for compute time, provisioned storage, requests, database capacity, data transfer, and managed-service features. The benefit is that capacity can be acquired rapidly and released when no longer needed. The economic risk is that resources can remain active indefinitely because provisioning is easy and ownership is diffuse.

The relevant comparison is not “server purchase versus cloud invoice.” It is the cost and value of complete service delivery. This includes people, facilities, resilience, software licences, migration, governance, security, support, downtime, and the opportunity cost of delayed delivery.

1.2 Fixed, variable, and step costs

A cloud workload may contain several cost behaviours:

Understanding cost behaviour is essential for forecasting. A service may appear inexpensive at low volume but become costly after crossing a throughput, storage, or network threshold.

1.3 Elasticity and economic value

Elasticity has economic value when the ability to scale changes business outcomes. For example, an online retailer may accept a higher unit cost during a short promotional peak because additional capacity prevents lost sales. Conversely, a stable batch workload may be cheaper on predictable committed capacity.

Elasticity should therefore be evaluated through the value of avoided overprovisioning, faster delivery, and improved availability—not merely through the ability to create resources automatically.

2. Cloud Pricing and Purchasing Models

2.1 On-demand or pay-as-you-go pricing

On-demand pricing charges for actual or metered consumption without a long-term capacity commitment. It provides maximum flexibility and is appropriate for experimentation, irregular workloads, early-stage products, and uncertain demand. Its disadvantages are price exposure, difficulty in budgeting, and the possibility that idle resources continue generating charges.

2.2 Commitment-based discounts

Providers commonly offer discounts in exchange for a commitment to spend, capacity, or a defined service configuration for a period. Examples include reserved capacity, savings plans, committed-use discounts, and enterprise agreements. The economic benefit depends on utilisation.

A commitment should be evaluated against a baseline workload. If committed quantity is greater than actual eligible usage, the organisation may pay for unused commitment. If workload migration or technology substitution is likely, flexibility is valuable and a narrowly defined commitment may be hazardous.

2.3 Spot or interruptible capacity

Spot capacity uses surplus provider capacity at a discount but may be interrupted. It is suitable for fault-tolerant, checkpointed, or queue-based workloads such as batch analytics, rendering, testing, and some distributed processing. It is inappropriate for workloads that cannot tolerate interruption unless a reliable fallback exists.

2.4 Serverless and request-based pricing

Serverless services often charge by requests, execution time, data volume, or allocated resources. They can reduce idle capacity and operational labour, but high request rates, inefficient execution, excessive logging, and unpredictable traffic can create substantial cost. Architecture must consider both unit price and invocation behaviour.

2.5 Tiered, volume, and bundled pricing

Storage, data transfer, support, and software services may use tiers. The marginal price can decline with volume, but crossing tiers may also introduce minimums or higher service obligations. Bundled contracts can simplify procurement while reducing transparency. Procurement teams should analyse effective unit prices and the value of included services rather than relying only on headline discounts.

2.6 The effective unit price

For a service with total relevant cost C and output quantity Q, the average unit cost is:

C must include all costs within the chosen boundary, and Q must be a meaningful output measure. For example, Q may be successful orders, processed terabytes, active customers, or API transactions. A denominator such as “number of virtual machines” is often misleading because it does not represent business output.

3. Total Cost of Ownership and Investment Appraisal

3.1 TCO boundaries

Total cost of ownership is a structured estimate of all relevant costs over a defined analysis period. A simplified model is:

The terms must be defined consistently. Acquisition may include hardware, software, contracts, and implementation. Migration includes assessment, redesign, data transfer, testing, and temporary parallel operation. Operation includes compute, storage, network, facilities, labour, monitoring, backup, and security. Risk-related cost may include expected outage loss, compliance remediation, or exit cost. Residual value is included only when an asset retains recoverable value at the end of the period.

TCO is not a universal truth. It is a decision model dependent on assumptions, scope, period, discount rate, workload profile, and risk treatment.

3.2 Present value and discounting

When costs occur at different times, nominal totals can be misleading. The present value of a future cash flow is:

where PV_t is present value at time zero, CF_t is the cash flow at period t, r is the discount rate per period, and t is the number of periods. The formula assumes a consistent time period and rate and treats the cash flow as occurring at the end of the period. For multiple cash flows:

Here, n is the final period. A positive net present value indicates that discounted benefits exceed discounted costs relative to the chosen baseline.

3.3 Return on investment

A simple project ROI is:

Net benefit should be measured over an explicitly stated period and should include recurring benefits and costs. ROI is useful for communication but can be distorted by timing, risk, and accounting boundaries. NPV is usually more appropriate when comparing investments with different timing or duration.

3.4 Worked example: comparing alternatives

An organisation evaluates a three-year migration. Migration and implementation cost $120,000. Cloud operating cost is $18,000 per month, while the existing environment costs $25,000 per month. Additional annual cloud governance and security cost is $30,000. The analysis excludes tax, financing, and residual value.

Three-year cloud cost is:

• Migration: $120,000
• Cloud operations: 36 × $18,000 = $648,000
• Governance and security: 3 × $30,000 = $90,000
• Total cloud TCO: $858,000

The existing environment costs 36 × $25,000 = $900,000. The nominal saving is therefore $42,000, not $252,000, because migration and governance costs must be included. If migration enables additional annual business benefit of $80,000, total three-year benefit is $240,000. A simple benefit-based ROI is:

This calculation is not the correct investment comparison because it treats the entire cloud TCO as investment and ignores the baseline cost. Relative to continuing the existing environment, the incremental cost is $858,000 − $900,000 = −$42,000, meaning the cloud option saves $42,000. Including the additional business benefit, total incremental benefit is $282,000 over three years. The example demonstrates why the baseline and cost boundary must be stated before calculating ROI.

4. Unit Economics and Cost Transparency

4.1 From infrastructure cost to business value

Unit economics connects technical consumption to a business unit. Suitable units depend on the service:

• cost per active customer;
• cost per successful transaction;
• cost per order fulfilled;
• cost per minute of video delivered;
• cost per analytical terabyte processed;
• cost per model inference.

A useful unit metric is:

The unit definition must be stable, measurable, and resistant to manipulation. “Valid” may mean successful transactions rather than all attempted requests. Teams should also distinguish average cost from marginal cost. Average cost includes shared and fixed cost; marginal cost estimates the additional cost of one more unit.

4.2 Cost allocation

Allocation assigns shared cost to consuming teams, products, or services. Common methods include direct allocation, proportional allocation, activity-based costing, and a hybrid model. Direct allocation is transparent when ownership is known. Proportional allocation is simple but can be arbitrary. Activity-based costing attempts to allocate according to resource drivers such as CPU-hours, storage volume, log ingestion, or support effort.

A mature allocation model uses a hierarchy:

1. Directly attribute identifiable resources.
2. Allocate shared platforms using measurable consumption drivers.
3. Allocate genuinely common overhead using an agreed policy.
4. Publish exceptions and review them periodically.

4.3 Chargeback and showback

Chargeback transfers an internal financial charge to the consuming cost centre. It creates stronger economic accountability but can encourage local optimisation, resistance to shared platforms, or avoidance of necessary resilience. Showback reports consumption and cost without transferring the accounting charge. It is useful when measurement is immature or when management wants transparency before introducing financial consequences.

A practical progression is to begin with showback, validate allocation data, introduce chargeback for controllable costs, and retain central funding for strategic shared capabilities such as security or enterprise identity.

5. FinOps as an Operating Model

FinOps is a cross-functional practice for maximising business value from technology expenditure. It is not merely a cost-cutting programme and not solely a finance function. Engineering controls technical consumption, finance provides financial discipline, procurement manages commercial terms, and product or business owners explain value and demand.

5.1 The FinOps lifecycle

A useful lifecycle has three recurring activities:

Inform. Create visibility through billing data, tagging, account structure, allocation, budgets, forecasts, and unit metrics.

Optimise. Reduce waste and improve efficiency through rightsizing, scheduling, architecture changes, storage lifecycle policies, rate optimisation, and workload placement.

Operate. Embed accountability in planning, product governance, engineering standards, procurement, and performance management. Set targets, assign owners, evaluate trade-offs, and monitor outcomes.

The lifecycle is continuous because demand, prices, architectures, and business priorities change.

5.2 FinOps roles and governance

Typical responsibilities include:

Governance should specify decision rights, escalation thresholds, tagging standards, commitment approval, exception handling, and evidence requirements. Cost governance is strongest when controls are automated and preventive—for example, policy-based restrictions on unapproved regions or oversized development resources.

6. Forecasting Demand and Cost

6.1 Forecasting principles

A cost forecast should begin with operational drivers rather than simply extrapolating last month’s invoice. Drivers may include users, transactions, data volume, retention period, batch frequency, geographic expansion, and service-level objectives.

A simple driver-based model is:

Driver_i is a measurable demand driver and Unit cost_i is the estimated cost per driver unit. The model assumes that prices and architecture remain stable over the forecast interval. It must be adjusted for tiers, commitments, seasonality, step costs, and planned changes.

6.2 Time-series and scenario forecasting

Historical time-series methods can identify trend and seasonality, but they may fail after a migration or major product change. Scenario forecasting is often more useful for strategic planning:

• Base case: expected demand and current architecture.
• High case: stronger growth, higher retention, or increased traffic.
• Low case: delayed adoption or reduced usage.
• Stress case: an unusual peak, regional failure, or price change.

Forecasts should report uncertainty, not only a single number. Variance analysis then compares actual cost with forecast and attributes differences to volume, price, mix, architecture, or timing.

6.3 Forecast accuracy

A common measure is mean absolute percentage error (MAPE):

n is the number of periods, and Actual_t must not be zero. MAPE can be misleading when actual values are close to zero; in such cases, mean absolute error or weighted measures may be preferable. Forecast accuracy should be evaluated by decision impact, not only by statistical score.

7. Rightsizing, Scheduling, and Commitment Planning

7.1 Rightsizing

Rightsizing matches provisioned capacity to observed demand and service requirements. Evidence should include CPU, memory, storage throughput, network throughput, latency, queue depth, and workload variability. CPU utilisation alone is insufficient: a database may be constrained by memory or I/O while CPU appears underused.

Rightsizing must preserve performance, resilience, security, and recovery objectives. A smaller instance that causes latency or outages is not an economic improvement. Changes should be tested, monitored, and reversible.

7.2 Scheduling and lifecycle management

Non-production resources often need not run continuously. Automated schedules can stop development environments outside working hours, subject to testing and operational requirements. Storage lifecycle policies can move infrequently accessed data to lower-cost tiers or delete data after an approved retention period. Deletion must respect legal holds, audit obligations, backup requirements, and recovery objectives.

7.3 Commitment planning

Commitment planning compares expected eligible baseline demand with commitment options. A simplified utilisation ratio is:

The ratio is meaningful only when numerator and denominator use the same unit and eligibility rules. A commitment should normally be based on stable baseline demand, while variable peaks remain on flexible pricing. Decision analysis should include discount, flexibility, cancellation risk, technology change, and opportunity cost.

7.4 Data transfer and architecture economics

Data transfer can materially affect distributed architectures. Repeated movement between regions, availability zones, providers, or managed services may create both financial and performance costs. Architecture reviews should ask where data is stored, where it is processed, how often it moves, and whether copies are necessary. A cheaper compute service may be uneconomic if it requires expensive data movement.

8. Balancing Cost, Performance, Risk, and Value

Cost optimisation is a constrained optimisation problem. A useful conceptual objective is:

subject to performance, availability, security, compliance, capacity, and architectural constraints. Expected risk cost can be represented as probability multiplied by impact, although this is only an approximation:

The estimate should identify the event, time horizon, affected assets, and impact categories. It should not be used to justify reducing controls when probability and impact are poorly understood.

A low-cost design may be unacceptable if it violates data residency, recovery-point objectives, or contractual service levels. Conversely, excessive redundancy may destroy product viability. Decisions should document the trade-off, owner, evidence, and review date.

9. Case Study: Illustrative E-Commerce Platform

Background

The following is an illustrative case. Northstar Retail operates an online platform in one cloud region. Its monthly invoice has increased from $90,000 to $155,000 in nine months, while order volume has grown by only 35%. The platform includes Kubernetes clusters, a managed relational database, object storage, observability tools, and a data-analytics pipeline.

Problem

Leadership assumes that growth is the sole cause of increased cost. Engineering reports that the platform is already highly optimised, while finance cannot attribute shared costs to products. The organisation is considering a three-year provider commitment.

Analysis

A FinOps assessment finds:

• 22% of compute resources are idle or substantially oversized.
• Development clusters run continuously despite being used mainly on weekdays.
• Log retention is uniform even though compliance requires different periods by data class.
• Data is copied across regions for convenience rather than a documented recovery requirement.
• The analytics pipeline runs on on-demand capacity despite being checkpointable.
• Product teams receive only a total invoice and therefore cannot relate cost to orders.

The team establishes a cost baseline and separates fixed, variable, shared, and one-time costs. It defines cost per completed order as the primary product metric and excludes failed test orders from the denominator. It also documents availability, recovery, and latency requirements before making changes.

Approach and solution

The organisation takes five actions:

1. Visibility: resource ownership tags, account hierarchy, daily dashboards, and product-level allocation are introduced.
2. Rightsizing: compute and database capacity are adjusted using four weeks of performance data and tested against peak traffic.
3. Scheduling: non-production resources are stopped outside approved windows.
4. Architecture: analytics jobs move to interruptible capacity with checkpointing; unnecessary cross-region transfers are removed.
5. Commitment: only the stable production baseline is committed; uncertain growth remains flexible.

Showback is used for two months. After allocation accuracy exceeds the agreed threshold, controllable costs are charged to product cost centres, while security and identity remain centrally funded.

Outcome

After three months, monthly cost falls to $118,000 despite continued order growth. Cost per completed order declines by 29%. Availability and latency remain within targets. The commitment covers 62% of eligible baseline usage rather than the original proposal of 90%, reducing the risk of paying for unused capacity. The organisation also discovers that observability cost is now a significant unit-cost driver and begins a separate log-quality initiative.

Learning points

The case demonstrates that cloud economics is not equivalent to indiscriminate reduction. Savings came from improved measurement, demand matching, architecture, and accountability. The most important decision was not selecting the largest discount; it was defining the business unit, constraints, ownership, and baseline before optimisation.

10. Challenges, Ethics, and Governance

10.1 Measurement limitations

Billing data may be delayed, inconsistent, or difficult to map to products. Tags can be missing or copied incorrectly. Shared services create allocation disputes. Unit metrics can encourage harmful behaviour if teams reduce cost by degrading reliability or transferring cost elsewhere.

10.2 Organisational incentives

Chargeback can produce beneficial accountability but may cause teams to avoid shared security controls, duplicate platforms, or defer necessary maintenance. Governance should reward total business value, not isolated invoice reduction. Product leaders should be accountable for cost and service outcomes together.

10.3 Ethical and regulatory considerations

Cost decisions must not undermine privacy, accessibility, safety, or legal compliance. Reducing monitoring may impair incident detection. Moving data to a cheaper region may violate residency obligations. Retaining data solely because storage is inexpensive may increase privacy risk. Automated optimisation should include policy guardrails, approval paths, and human review for high-impact systems.

10.4 Environmental implications

Cloud financial optimisation and environmental sustainability can reinforce each other through efficient utilisation, workload scheduling, and reduced data movement. They are not identical goals: a region with lower monetary price may have different energy characteristics, and running workloads at off-peak times may affect both cost and carbon intensity. Organisations should avoid claiming environmental benefit without an appropriate measurement boundary.

11. Contemporary Developments and Best Practice

AI workloads introduce distinctive economic issues: accelerator scarcity, high memory requirements, long training runs, inference volume, model storage, and data-transfer costs. A model’s cost should be related to useful outputs such as accurate predictions, resolved cases, or revenue-generating interactions—not merely GPU hours. AI-assisted FinOps can classify anomalies and forecast demand, but automated recommendations require validation because unusual usage may represent legitimate business activity.

Recommended practice includes:

• establish a documented cost-allocation and tagging standard;
• measure cost by product and meaningful business unit;
• separate baseline, variable, shared, and exceptional costs;
• forecast from demand drivers and publish scenarios;
• automate detection of idle, orphaned, and oversized resources;
• evaluate performance and reliability before approving savings;
• commit only stable demand and review commitments regularly;
• include migration, exit, compliance, and risk costs in investment analysis;
• use budgets as early-warning controls rather than blunt shutdown mechanisms;
• maintain an auditable record of assumptions, approvals, and outcomes.

Chapter Summary

Cloud economics evaluates technology choices through cost behaviour, business value, risk, and constraints. Pay-as-you-go pricing provides flexibility, while commitments can reduce cost for stable demand but introduce utilisation and obsolescence risk. Total cost of ownership must include acquisition, migration, operation, support, governance, risk, and—where applicable—residual value. Discounting is required when cash flows occur at different times, and ROI is meaningful only when its baseline and benefit boundary are explicit.

Unit economics connects cloud consumption to outcomes such as orders, customers, or analytical work. Showback improves transparency; chargeback adds financial accountability but must be designed to avoid harmful local optimisation. FinOps integrates finance, engineering, procurement, security, and product management through the recurring activities of informing, optimising, and operating.

Demand forecasting should use operational drivers, scenarios, and explicit uncertainty. Rightsizing, scheduling, lifecycle management, data-transfer reduction, and selective commitment planning can improve efficiency without sacrificing service objectives. The strategic objective is not the lowest invoice; it is sustainable business value under performance, resilience, security, compliance, and ethical constraints.

Key Terms

Cloud economics: Analysis of cloud-related cost, value, incentives, and risk.

FinOps: Cross-functional operating practice for maximising business value from technology expenditure.

Capital expenditure: Spending on assets expected to provide benefits over multiple periods.

Operating expenditure: Ongoing spending required to operate or consume a service.

Total cost of ownership: All relevant costs of acquiring, operating, governing, and retiring an asset or service.

Present value: Current value of a future cash flow after discounting.

Net present value: Present value of benefits and costs relative to an investment baseline.

Return on investment: Benefit relative to investment, expressed as a ratio or percentage.

Unit economics: Relationship between cost and a meaningful business unit.

Marginal cost: Additional cost caused by producing one more unit of output.

Showback: Reporting consumption and cost without internal financial transfer.

Chargeback: Assigning internal financial charges to consuming units.

Rightsizing: Matching provisioned capacity to actual demand and service requirements.

Commitment: Contractual or commercial agreement to consume or spend at a defined level.

Elasticity: Ability to adjust capacity in response to changing demand.

Cost allocation: Assignment of direct and shared costs to owners or consumers.

Demand driver: Operational variable that explains or predicts consumption.

Expected loss: Estimated probability of an adverse event multiplied by its impact.

Cost baseline: Defined reference level used for comparison and variance analysis.

Unit cost: Cost divided by a consistently defined output quantity.

Review Questions

Short Answer Questions

1. Distinguish capital expenditure from operating expenditure in a cloud context.
2. Why can a cloud migration reduce infrastructure cost but fail to reduce total cost of ownership?
3. What is the difference between showback and chargeback?
4. State two risks associated with excessive commitment purchasing.
5. Why is CPU utilisation alone insufficient for rightsizing?

Long Answer Questions

1. Explain the FinOps inform–optimise–operate lifecycle and describe the responsibilities of finance, engineering, procurement, and product teams.
2. Discuss how unit economics can improve cloud investment decisions, using suitable examples of business units.
3. Compare on-demand, commitment-based, and interruptible pricing models, including appropriate workload characteristics for each.
4. Explain how governance can balance cost optimisation with reliability, security, compliance, and performance.
5. Develop a TCO framework for comparing an on-premises service with a cloud-hosted alternative.

Analytical / Application Questions

1. A workload has a stable baseline of 400 compute units per month and seasonal peaks reaching 700 units. Design a commitment strategy and identify the assumptions that should be validated before purchase.
2. A product’s monthly allocated cloud cost is $48,000 and it completes 120,000 valid orders. Calculate its average cost per order and explain two limitations of this metric.
3. A team forecasts monthly cost of $100,000 but actual cost is $115,000. Analyse possible volume, price, mix, architecture, and timing causes, and propose a variance-investigation process.

Multiple Choice Questions with Answers

Question 1

Which statement best describes FinOps?

A. A procurement process for obtaining the largest possible cloud discount

B. A cross-functional practice for maximising business value from technology expenditure

C. A technical method for automatically resizing every virtual machine

D. An accounting rule that classifies all cloud services as operating expenditure

Correct Answer: B. A cross-functional practice for maximising business value from technology expenditure

Question 2

Which cost is most likely to be a step-fixed cost?

A. An API request charge

B. Object storage charged per gigabyte

C. Adding a database node after a capacity threshold is crossed

D. A variable data-transfer fee

Correct Answer: C. Adding a database node after a capacity threshold is crossed

Question 3

A service costs $30,000 and produces 60,000 valid transactions. What is its average cost per transaction?

A. $0.05

B. $0.50

C. $2.00

D. $5.00

Correct Answer: A. $0.05

Question 4

What is the principal risk of basing a long-term commitment on peak rather than baseline demand?

A. The workload becomes impossible to monitor

B. The organisation may pay for unused committed capacity

C. On-demand prices automatically increase

D. Data residency requirements disappear

Correct Answer: B. The organisation may pay for unused committed capacity

Question 5

Which activity belongs primarily to the FinOps “Inform” phase?

A. Deleting all development environments

B. Negotiating a hardware resale contract

C. Creating allocation reports and cost forecasts

D. Replacing a database with a serverless service

Correct Answer: C. Creating allocation reports and cost forecasts

Question 6

A company has cloud TCO of $858,000 over three years and an on-premises baseline of $900,000. What is the nominal saving before considering other benefits?

A. $42,000

B. $58,000

C. $242,000

D. $1,758,000

Correct Answer: A. $42,000

Question 7

Which workload is generally most suitable for interruptible or spot capacity?

A. A non-checkpointed payment authorisation service

B. A batch analytics job that can resume after interruption

C. A regulated database with no fallback capacity

D. A primary identity service with strict availability requirements

Correct Answer: B. A batch analytics job that can resume after interruption

Question 8

Why should a business denominator be used in unit economics?

A. It eliminates all shared costs automatically

B. It relates technology spending to an outcome or activity meaningful to the business

C. It guarantees that costs decline every month

D. It prevents any need for forecasting

Correct Answer: B. It relates technology spending to an outcome or activity meaningful to the business

Question 9

Which factor should be considered before rightsizing a database?

A. Only the colour of the management dashboard

B. CPU utilisation alone

C. Memory, storage throughput, latency, resilience, and recovery requirements

D. Only the provider’s marketing discount

Correct Answer: C. Memory, storage throughput, latency, resilience, and recovery requirements

Question 10

What does showback provide?

A. Visibility into consumption and cost without necessarily transferring an internal financial charge

B. A guarantee that all cloud services are free at low usage

C. A replacement for security governance

D. A commitment to purchase maximum capacity

Correct Answer: A. Visibility into consumption and cost without necessarily transferring an internal financial charge