A Cloud Cost Comparison Is Only as Good as Its Evidence

A cloud cost comparison needs an evidence boundary first

A platform team is asked to compare two cloud options. The request sounds concrete: estimate the cost, identify the lower total, and recommend a direction. But the available material contains no workload profile, deployment region, availability requirement, storage volume, egress pattern, retention period, support plan, pricing unit, or dated price.

That is not yet a cost comparison. It is an evidence gap.

This matters because a polished total can hide unresolved decisions. A spreadsheet may calculate correctly while answering the wrong question. An architecture diagram may look complete while leaving recovery and operational ownership undefined. The responsible next step is not to add invented precision. It is to establish an evidence gate: the minimum information required before cost conclusions can influence an architecture decision.

The supplied Azure reference is a general developer landing page offering documentation, examples, and tutorials for building and managing applications on Azure (Azure documentation). The supplied AWS item points to an AWS contact page, despite being identified in the metadata as an AWS Blogs source (AWS contact page). Neither supplied item contains the workload-specific prices, limits, regional details, or plan information needed for a provider cost comparison.

Verified fact: the supplied evidence does not include comparable pricing data.

Interpretation: choosing a lower-cost provider from this material would be unsupported.

The useful engineering decision, therefore, is narrower: decide when a cloud cost comparison is sufficiently specified to review—and what to do when it is not.

Seven inputs define what is actually being compared

Before discussing cost, record these seven inputs:

1. Workload: What runs, for how long, and with what demand pattern?
2. Region: In which provider region or regions will resources run?
3. Availability: What interruption tolerance and deployment scope must the design address?
4. Storage: What data is stored, how it changes, and which access behavior matters?
5. Egress: Which data leaves a service, region, or provider boundary?
6. Retention: How long must application data, backups, logs, and other operational records remain?
7. Support: Which support plan or internal support assumption applies?

These are not values supplied by the sources. They are fields in the proposed decision method.

A comparison should mark each field as one of the following:

• Verified: supported by an authoritative source or an approved workload requirement.
• Assumption: selected for planning but not yet confirmed.
• Unknown: still missing and capable of changing the decision.
• Not applicable: deliberately excluded, with a reason.

This classification prevents assumptions from becoming invisible. It also gives budget owners a direct way to ask what a total includes without having to reverse-engineer a spreadsheet.

A useful gate is simple: do not rank options by cost while a material input remains unknown. “Material” should be defined by the review group rather than assumed universally. If an unknown could change architecture, reliability, recovery, or the cost ordering, resolve it or show separate scenarios.

Keep prices, calculations, estimates, and results separate

Cost discussions often use “price” and “cost” as if they were interchangeable. A review becomes clearer when four evidence types are kept apart.

Provider list price

A list price is a provider-published charge. Every captured price should include:

• provider;
• service or plan;
• billing unit;
• region, or an explicit statement that the plan is not regional;
• currency, when supplied;
• relevant tier or limit;
• source URL;
• source date.

No compliant list prices can be extracted from the supplied metadata. The Azure source is a broad developer documentation entry point, while the AWS source leads to contact information rather than a dated price sheet. That absence should be recorded, not filled with remembered figures.

Calculation

A calculation applies quantities to list prices. Keep the expression visible instead of publishing only a final total.

A reusable monthly structure is:

estimated monthly total =
  compute quantity × compute unit price
+ storage quantity × storage unit price
+ request quantity × request unit price
+ egress quantity × egress unit price
+ support charge
+ other explicitly scoped charges

Not every service uses every term, and this formula is not a statement about either supplied provider. It is a template. Each term should be included only when supported by the selected service and pricing source.

Estimate

An estimate is the result of applying assumptions to a calculation. It should carry the same workload, region, availability, storage, egress, retention, and support assumptions that produced it.

A range or multiple scenarios may be more honest than a single number when demand is uncertain. That is an editorial and decision-making principle, not a claim derived from the supplied provider pages.

Observed result

An observed result comes from an actual bill, usage export, or other approved record for a defined period. No observed results were supplied for this article. An estimate must not be presented as one.

Keeping these categories separate makes review comments precise. A reviewer can challenge a list price, quantity, formula, assumption, or observation without treating the whole model as a single opaque figure.

The evidence gate is also an architecture gate

Cost cannot be separated cleanly from reliability. A cheaper-looking configuration may simply omit a required recovery path, monitoring signal, retained backup, or support arrangement. Conversely, additional components should not be added merely to make an architecture appear sophisticated.

The smallest reliable solution is the least complex option that satisfies the stated workload and operating requirements. “Smallest” does not automatically mean the fewest services, and “reliable” does not imply a universal topology. Both depend on the decision boundary.

Before comparing totals, ask:

• What failures are in scope?
• What happens when an application process stops?
• What happens when a selected dependency is unavailable?
• Which data must be recoverable?
• Who initiates and verifies recovery?
• Which signals indicate degradation or failure?
• Where do alerts go, and who owns the response?
• How long are logs, metrics, backups, and recovery records retained?
• Which parts of the response depend on provider support?

The supplied sources do not define answers to these questions. They must come from workload requirements and service-specific documentation collected during the review.

This is why a universal architecture diagram would be misleading here. There is no supported basis for selecting a database topology, orchestration layer, search cluster, network pattern, or multi-region design. The defensible artifact is a decision record showing which requirements are known and which evidence remains missing.

Failure modes of an unsupported comparison

An evidence-first review should explicitly guard against several process failures.

A generic page is treated as service evidence

A provider’s general developer portal may help locate documentation, but it does not by itself establish the price, limit, regional availability, or operational behavior of a selected service. The supplied Azure page is such a general entry point (Azure developer resources).

Recovery: identify the exact service and retrieve its official pricing, limits, regional, reliability, and support references before calculation.

A source label is trusted without checking its destination

The supplied AWS metadata calls the source “AWS Blogs,” but its canonical URL is a contact page (AWS contact resource). A reviewer should inspect what a source actually supports rather than infer authority from a label.

Recovery: record the canonical destination, source purpose, and retrieval date. Reject the source for claims it does not substantiate.

An estimate is reported as an observed outcome

This removes uncertainty from view and makes later reconciliation difficult.

Recovery: label every figure as list price, calculation, estimate, or observed result. Preserve the inputs beside it.

Reliability is added after the cost ranking

This can make the first comparison structurally unfair because one option may exclude required recovery or observability work.

Recovery: approve the reliability and operating boundary before ranking totals.

Complexity becomes a proxy for diligence

More components can create more assumptions, ownership boundaries, and recovery work. Complexity is justified only when it addresses an explicit requirement.

Recovery: for each component, record the requirement it satisfies and what would fail if it were removed.

A reusable review checklist

Use this compact checklist before accepting a cloud cost recommendation.

Decision scope

• The workload and demand pattern are stated.
• The compared services and plans are named precisely.
• Region and availability assumptions are explicit.
• Storage, egress, retention, and support are in scope or deliberately excluded.

Pricing evidence

• Every price has a provider and service or plan.
• Every price has a billing unit.
• Region or plan scope is recorded.
• Currency, tier, and relevant limits are recorded when supplied.
• The official source URL and source date are attached.

Cost model

• List prices are separate from quantities.
• Calculations are visible.
• Estimates are labeled and carry their assumptions.
• Observed results are identified by period and are not inferred.
• Unknowns that could change the ranking are visible.

Operations

• Failure modes are listed.
• Recovery ownership and verification are defined.
• Required observability signals and alert ownership are stated.
• Backup and operational-data retention are specified.
• Every architectural component maps to a requirement.

If this gate fails, the outcome need not be “stop all work.” The team can request missing evidence, compare only supported non-cost dimensions, or publish conditional scenarios. What it should not do is declare a cost winner from incomplete inputs.

The decision supported by the current evidence

The supplied material supports a limited but useful conclusion: there is not enough evidence to compare Azure and AWS pricing, service limits, regional options, or workload outcomes. It would also be unsupported to recommend one provider over the other.

The next reliable step is to complete the seven-input boundary, name the exact candidate services, and gather dated official evidence for pricing, limits, regions, reliability, and support. Only then should a calculation produce an estimate.

That discipline is not bureaucracy. It keeps product requirements, operational responsibility, and budget decisions attached to the same model—and it helps the team choose the smallest solution it can actually justify.

If you need a second pair of eyes on a cloud proposal, cost model, or operational readiness review, I can help turn its assumptions and evidence into a concise technical decision record.

Official sources

• Azure documentation — Get started for Azure developers
• AWS — Contact us