# Azure cost estimation review

## What people get wrong

- They treat the Azure pricing calculator as an invoice simulator. It is an estimation tool driven by selected configuration and usage quantities.
- They forget support plans, backups, monitoring data, private endpoints, NAT, egress, DR capacity, and nonproduction environments.
- They use 730-hour defaults for workloads that scale, sleep, burst, or run seasonally.
- They apply reservations or savings plans before proving stable utilization.
- They ignore negotiated pricing and agreement-specific data sources while presenting retail math as exact.

## Officially grounded service shape

Microsoft Learn describes the Azure pricing calculator as a way to turn anticipated usage into an estimated cost. Calculator pricing is sourced from Azure Retail Prices API data, while signed-in experiences can reflect negotiated agreement prices where access allows. Cost Management guidance frames estimation as part of a lifecycle: plan, gain visibility, assign accountability, optimize, and iterate.

## Non-negotiable design rules

1. Build estimates from architecture, not wishful monthly totals.
2. Label pricing basis: retail, negotiated, historical actual, or unknown.
3. Include all environments and shared services.
4. Include data transfer, logs, backups, security, support, and operational overhead where applicable.
5. Use scenarios: baseline, peak, failover/DR, and growth.
6. Treat discounts and commitments as conditional until utilization stability is proven.
7. Preserve uncertainty; do not collapse unknowns into false precision.

## Minimal safe implementation flow

1. Inventory every service, SKU, region, tier, quantity, and usage driver.
2. Map workload patterns: hours, requests, storage growth, retention, egress, and peak factors.
3. Add production, nonproduction, DR, shared, and observability cost lines.
4. Identify pricing source and whether negotiated rates are verified.
5. Create low/expected/peak scenarios and a separate commitment-discount scenario.
6. Compare estimate against budget and identify high-cost architectural decisions.
7. Document unknowns and evidence needed to improve confidence.

## High-risk assumptions to kill

- Calculator output is not invoice truth; it depends on selected configuration, usage quantities, pricing basis, and whether negotiated rates were actually available.
- A monthly total without architecture bill of materials hides the services most likely to blow the budget: logs, backups, bandwidth, DR, support, and shared networking.
- Retail pricing is not agreement pricing, and negotiated pricing should not be claimed unless authenticated evidence or sanctioned price sheets support it.
- Reservation or savings-plan scenarios are not savings unless stable utilization and commitment risk are proven.
- Nonproduction and failover environments are not free unless shutdown, scaling, retention, and capacity assumptions are explicitly modeled.

## Safe command/code verification targets

- Inspect estimate exports, calculator links, or IaC-derived bill-of-materials for named service configurations, regions, SKUs, quantities, and usage drivers.
- Check scripts or spreadsheets for hard-coded 730-hour assumptions, missing egress/log/backup/support lines, and unlabeled retail-versus-negotiated pricing.
- Verify scenarios include low, expected, peak, growth, DR/failover, and commitment-discount variants rather than one fake-precise number.
- Review any API-backed pricing lookup for currency, region, meter, date, and source labeling.
- Require estimate notes to list unknowns, owner decisions, and evidence needed before budget approval.

## Safe verification targets

- Calculator export or estimate link with named configurations.
- SKU, region, and quantity assumptions for each service.
- Usage drivers: hours, transactions, GB/month, retention, egress, replica count, and backup frequency.
- Pricing basis and date of rate evidence.
- Support plan, reservations, savings plans, hybrid benefit, and commitment utilization assumptions.
- Historical actuals if estimating an existing workload.

## When to push back

Push back on one-line monthly totals, retail rates presented as negotiated rates, missing DR/nonproduction/logging costs, discount claims with no utilization evidence, or estimates with no architecture bill of materials.

# MCP and evidence path for Azure cost estimation review

Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.

## Evidence ladder

1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.

## Rules

- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
- If current-state evidence was not sampled, say `not sampled`; do not imply it.
- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
- Prefer read-only evidence before mutation planning. Stop for approval before write operations.

## Final-answer evidence language

Use phrases like:

- "Based on Microsoft Learn documentation..."
- "Configured-environment evidence was not sampled in this review."
- "The following is an inference from the provided configuration, not proven live state."
- "This recommendation is mutation-ready only after explicit approval and rollback review."

# Official sources for Azure Cost Estimation Review

Use Microsoft Learn documentation through the user's configured documentation MCP before critiquing Azure estimates. Documentation and calculators support planning; they do not prove invoice truth, negotiated rates, future utilization, or missing architecture components.

## Primary Microsoft Learn sources

| Source | Review implication |
| --- | --- |
| [Estimate costs with the Azure pricing calculator](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/pricing-calculator) | Use for calculator mechanics, product configuration, usage quantities, pricing plans, exports, and negotiated-price caveats. |
| [Plan to manage Azure costs](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/plan-manage-costs) | Use for estimation before adding services, price sheets, portal estimates, and planning limitations. |
| [How to optimize your cloud investment with Cost Management](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-best-practices) | Use for planning, visibility, accountability, exports, budgets, APIs, and optimization lifecycle. |
| [Plan your Azure environment for cost estimation](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/estimate-total-cost-of-ownership) | Use for architecture-driven estimates, operational costs, and reevaluation when projections deviate. |
| [Azure Retail Prices API](https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices) | Use for programmatic retail pricing source; distinguish from negotiated billing rates. |
| [Azure reservations](https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/save-compute-costs-reservations) | Use when estimates include one-year or three-year commitments. |
| [Azure savings plans for compute](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/savings-plan-overview) | Use when estimates include hourly compute commitments. |

## Source-grounding rules

- Do not present calculator estimates as invoices.
- Do not assume negotiated pricing unless the user provides safe proof or a configured read-only evidence sample verifies it.
- Do not hide support, bandwidth, logging, backup, security, DR, NAT, private endpoint, or operational labor omissions.
- Keep usage assumptions explicit and challenge one-month flat 730-hour defaults when workload patterns differ.

# Safety checklist for Azure Cost Estimation Review

## Non-negotiable gates

- Never ask for billing account identifiers, enrollment numbers, invoices, tenant identifiers, subscription identifiers, customer names, or screenshots containing sensitive billing data.
- Do not claim exact future spend from calculator or retail API data.
- Do not apply savings plans, reservations, or hybrid benefits unless utilization stability and eligibility are proven.
- Do not ignore data transfer, support, logs, backups, monitoring, security services, private networking, and DR replicas.
- Require explicit uncertainty labels for usage growth, regional price changes, negotiated rates, commitment coverage, and utilization.

## High-risk assumptions to kill

- "The calculator total is the budget." It is an estimate from configuration and usage assumptions.
- "Retail price is our price." Negotiated and agreement-specific rates may differ.
- "Reservations always save money." They can waste money if usage, region, or SKU changes.
- "Nonproduction costs are negligible." Logs, databases, NAT, endpoints, and always-on plans can dominate.
- "One architecture scenario is enough." Estimates need baseline, peak, DR, and growth cases.

## Evidence labels

- `docs_only`: pricing/estimation guidance only.
- `estimate_review`: calculator export or architecture estimate reviewed.
- `usage_informed`: historical usage or measured load informed the estimate.
- `rate_verified`: negotiated or agreement-specific rate evidence was safely verified.
- `commitment_ready`: utilization stability and commitment coverage are proven enough to consider reservations or savings plans.

## Minimum safe evidence

- Architecture bill of materials, regions, SKUs, tiers, quantities, hours, storage, data transfer, logs, backup, and support assumptions.
- Environment split: production, staging, dev/test, DR, and shared services.
- Workload pattern: baseline, peak, growth, seasonality, and shutdown assumptions.
- Pricing basis: retail, calculator, price sheet, negotiated, or unknown.
- Commitment assumptions: reservation, savings plan, hybrid benefit, term, scope, and utilization proof.

# Workflow and output contract for Azure Cost Estimation Review

## Minimal safe workflow

1. Classify estimate type: greenfield, migration, expansion, DR, nonproduction, or optimization scenario.
2. Ground the review with Microsoft Learn through the user's configured documentation MCP.
3. Build the bill-of-materials table and mark missing services.
4. Challenge assumptions: region, SKU, hours, storage growth, network egress, logs, backups, support, security, and operations.
5. Separate pricing basis: retail calculator, negotiated rate, price sheet, historical actuals, or user estimate.
6. Produce scenario ranges: minimum viable, expected, peak, DR/failover, and growth.
7. Return confidence level and required evidence for stronger precision.

## Output contract

```markdown
## Verdict
<credible estimate | conditional estimate | unreliable estimate | docs-only advisory>

## Evidence level
- Documentation: <sources used>
- Pricing/usage evidence: <estimate_review|usage_informed|rate_verified|not provided>

## Estimate risks
1. <risk> — Evidence: <docs_only|estimate_review|usage_informed|inference>

## Missing cost lines
- <omitted service or assumption>

## Confidence range
- Low / expected / peak: <if evidence supports it>

## Safe next actions
- <specific estimate improvement>
```

## Pushback triggers

Push back on single-number estimates, hidden assumptions, missing operational costs, unsupported discounts, no growth case, or calculator totals represented as committed budget truth.