From business objective to sizing class

Planning capacity with no usage history

Industrial capacity planning usually starts from past consumption, measured with discovery tools or estimated from an inventory, and that path does not exist for a new workload. In two migrations planned the traditional way and followed for 90 days after cutover, executed CPU in the computing layer ended up 26% to 41% above plan, and memory 35% to 59% above.

Choosing instance types, replication, scaling and networking for every service is a combinatorial problem, and the thesis treats it as NP-hard. C2PF replaces the search for the optimal combination with an abstraction into classes, in the spirit of T-shirt sizes, tied to objectives the business can actually state. The class is the starting point of the plan and does not replace measurement after go-live.

Nine elements, from business domain to class

Each layer of the meta-model constrains the next. Click an element to see how the thesis defines it.

A B2C marketplace broken down to the service

The thesis example is a B2C marketplace platform connecting buyers and sellers. Four functional blocks group the services, and capacity is assessed at the service, not across the whole platform.

Source: thesis, figures 6 to 8. The highlighted service is the one used in the examples on this page.

What the service must deliver, in three types

In SRE language all three would be SLOs. C2PF separates them by type so each one can be tied to the capacity characteristics and layers that serve it. Every objective is measured by an indicator (SLI) and written as SLI ≤ target or as a range, over an evaluation window.

Source: thesis, figure 9. The thesis does not separate the SLO and RLO indicators in this example; a complete specification names each SLI.

Ten capacity characteristics, five layers

Processing, memory, storage and network are what capacity planning usually looks at. The thesis widens the set with nonfunctional characteristics, grouped into reliability and performance, because the architecture that will meet the objective depends on them.

Fifty attributes condensed into a name

Each class assigns a value to every pair of characteristic and layer, which gives 10 × 5 = 50 attributes per class and 150 values in the first generation. The thesis derived the values from the literature on nonfunctional requirements, from the averages of public cloud instance families and from a distribution across the three classes.

The second generation (c2pf2) keeps the three classes and adds xsmall and xlarge. It is an extension made in the derived papers, under the thesis naming convention, and is not part of the thesis.

Table 4 explorer

Faded rows hold the same value in all three classes, such as encryption. Acronyms: AZ, availability zone; ASG, auto scaling group; PITR, point-in-time recovery; TTL in seconds.

Scoring a candidate plan against the objectives

In the meta-model figure, SLO and R range from 0 to 1 and express degree of compliance, and P is a performance measure. The thesis fixes neither the range of P nor any constraint on the weights. The derived papers read the expression as the score of a candidate, with P also in [0, 1] and weights summing to 1, so the score is 1 exactly when every objective is met. For R they use the error-budget ratio, because 89.95% and 99.95% look close yet allow unavailability that differs by a factor of 200.

With equal weights the scores are 0.596, 0.634 and 1.000, and only c2pf1.large meets all three objectives. Choosing the least-cost class among those scoring 1 is a decision rule of the papers, not of the thesis.

What C2PF leaves on record

Each step produces an artifact that someone else can read, challenge and reproduce, and that record is what separates the plan from an estimate made in someone's head.

input = {
  slo: { success_rate: 99.5%, throughput: 3000 req/s },
  plo: { latency_p95: 150 ms, latency_p99: 400 ms, concurrency: 2000 },
  rlo: { availability_pct: 99.99%, rto_min: 2, rpo_min: 0 },
  demand: { app_ms: 8, queries: 2, read_share: 0.50, db_ms: 1.2 },
  overrides: { compliance: PCI-DSS, budget_cap: none,
               preferred_compute: containers }
}
→ κR = L · κS = XL (L envelope: 2,424 req/s) · κP = L → c2pf2.xlarge

Load the “PCI payments” example in the calculator to see the full plan and download the files.

What was observed and where the model stops

• ›Class values come from public cloud averages and the literature, and they age with instance families. The generation convention exists for that reason.
• ›The calculator applies the rules of the decision-oriented process model, an unpublished manuscript. Thresholds, 80% headroom and 100 requests per vCPU are design choices of that work, evaluated in simulation.
• ›With a critical RLO the rule tends to oversize, because it goes to large even when the service carries little load. The cost shown is an order of magnitude and does not replace the provider's pricing calculator.

1. C. D. C. Pereira, “Capacity Planning of Cloud Computing Workloads,” doctoral thesis, CESAR School, Recife, 2023. Revised edition with editorial note, 2026. doi:10.2139/ssrn.5754002.
2. C. D. C. Pereira, “C2PF: An Architecture-Aware Conceptual Framework for Cloud Capacity Planning,” unpublished manuscript, 2026.
3. C. D. C. Pereira, “From Objectives to Architecture: A Decision-Oriented Process Model for Instantiating the C2PF,” unpublished manuscript, 2026.
4. B. Beyer, C. Jones, J. Petoff and N. R. Murphy, Eds., Site Reliability Engineering. Sebastopol: O’Reilly, 2016.