Estimate Billing

Known limitations: Cost inference from billing SKU details (tighter ranges), historical trend projection, and AWS Cost Calculator integration are not yet supported.

Pricing Mode

Without source configuration (CPU, memory, disk, scaling), billing-only estimates use GCP-cost-ratio projections (Step 2 below) rather than precise per-resource AWS pricing lookups. The pricing cache and MCP API are not directly used for per-service calculations — instead, GCP actual spend is scaled by service-type multipliers.

Overall accuracy: ±30-40% due to the lack of configuration detail.

Overview

When only billing data was available for design, cost estimates carry wider ranges. Without source configuration, we cannot calculate precise AWS costs. Instead, we produce low/mid/high estimates per service based on typical AWS pricing for the mapped service type.

Input: $MIGRATION_DIR/aws-design-billing.json, $MIGRATION_DIR/billing-profile.json, $MIGRATION_DIR/preferences.json Output: $MIGRATION_DIR/estimation-billing.json

Prerequisites

Read from $MIGRATION_DIR/:

From aws-design-billing.json:

• services[] — GCP services with AWS mappings and confidence levels
• metadata.design_source — must be "billing_only"

From billing-profile.json:

• services[] — GCP services with monthly costs and SKUs
• summary.total_monthly_spend — Total GCP spend (this is the baseline)

From preferences.json:

• design_constraints — User preferences for optimization approach

Step 1: Establish GCP Baseline from Billing

Use billing-profile.json as the authoritative GCP cost baseline:

This is actual spend data — higher confidence than inferred costs.

CUD-Aware Baseline Adjustment

If billing-profile.json contains commitments.has_active_cuds == true:

1. Use list price as baseline: The services[].monthly_cost values already reflect list price (commitment fee rows are excluded). Use these directly — do not subtract CUD credits from the baseline.
2. Exclude commitment fees from workload costs: Commitment fee rows (e.g., “Commitment v1: E2 Cpu”) are billing artifacts, not workload costs. They are already excluded from services[] by the discover phase.
3. Note the customer’s effective discount: Record commitments.effective_discount_percent for the comparison narrative. The customer currently pays this percentage below list price on GCP.

If commitments.has_active_cuds == false or the commitments section is absent, proceed with total_monthly_spend as-is.

Step 2: Generate AWS Cost Ranges

For each service in aws-design-billing.json, produce low/mid/high estimates:

Range Calculation

Since we lack source configuration, apply percentage-based ranges around the GCP cost:

Adjust Ranges by Service Type

Some service types have tighter ranges than others:

Adjust by SKU Hints

If aws-design-billing.json has sku_hints from SKU analysis, tighten the range:

• SKU indicates specific instance size -> reduce range to ±15%
• SKU indicates storage class -> reduce range to ±10%
• No SKU hints available -> use full range

Step 3: Total Cost Projection

Commitment-to-Commitment Comparison (if CUDs detected)

If billing-profile.json has commitments.has_active_cuds == true, add a commitment context note:

This ensures the customer understands that their current GCP discount has an AWS equivalent, and the comparison is apples-to-apples.

Step 4: Human One-Time Migration Costs (Out of Scope)

Do not present human labor, professional services, engineering, training, discovery/design effort, or similar people-time work as one-time migration costs or budget categories.

Populate migration_cost_considerations.categories as an empty array []. Use migration_cost_considerations.note to state that human and professional-services one-time migration costs are intentionally excluded. You may still recommend IaC discovery in recommendation.next_steps or unknowns as a precision improvement — without framing it as a cost line item.

Vendor fees: If you discuss GCP egress in narrative, describe it only as vendor/network charges when grounded in billing-profile.json (do not invent dollar amounts). Do not mix human effort into “one-time cost” lists.

Step 5: Document Unknowns

List what would narrow the cost ranges:

Step 6: Generate Output

Write estimation-billing.json.

estimation-billing.json schema

Output Validation Checklist

• metadata.estimate_source is "billing_only"
• accuracy_confidence is "±30-40%" (never tighter for billing-only)
• gcp_baseline matches billing-profile.json totals
• Every service has low/mid/high estimates
• unknowns array is populated with resolution steps
• recommendation.confidence is "low" (billing-only never produces high confidence)
• No reference to Terraform-based configurations
• All unknowns documented with impact and resolution
• All cost values are numbers, not strings
• migration_cost_considerations.categories is [] — no human one-time migration costs presented
• Output is valid JSON

Completion Handoff Gate (Fail Closed)

Before returning control to estimate.md, require:

• estimation-billing.json exists and passes the Output Validation Checklist above.

If this gate fails: STOP and output: “estimate-billing did not produce a valid estimation-billing.json; do not complete Phase 4.”

Present Summary

After writing estimation-billing.json, present a concise summary to the user:

1. Pricing source and accuracy: State that estimates are billing-only projections with ±30-40% accuracy due to lack of infrastructure configuration. Example: “Billing-only estimates, accuracy ±30-40%. Provide Terraform files to narrow to ±10-15%.”
2. GCP baseline from billing data (total monthly spend)
3. Estimated monthly AWS cost ranges: low / mid / high per service
4. Total projection: best case / expected / worst case vs GCP (labeled as estimated monthly costs)
5. Key unknowns that would narrow the estimates
6. Recommendation: run IaC discovery for tighter estimates (±10-15% vs ±30-40%) — as a precision step, not as a human cost estimate

Cost labeling rule: All dollar figures presented to the user MUST be labeled as “estimated monthly costs” or prefixed with “Est.” — never present raw dollar amounts as if they are exact.

Keep it under 20 lines. The user can ask for details or re-read estimation-billing.json at any time.

Generate Phase Integration

The Generate phase uses estimation-billing.json:

• Uses wide cost ranges for conservative timeline planning
• Recommends IaC discovery as a prerequisite step
• Documents unknowns as prerequisites per generation step
• Do not surface human one-time migration costs from this artifact — migration_cost_considerations.categories remains empty in user-facing docs

Source

• references/phases/estimate/estimate-billing.md(opens in a new tab)
• Raw file(opens in a new tab)
• aws/agent-toolkit-for-aws(opens in a new tab)