What this prompt does
This prompt designs cost estimation into your IaC workflow so cloud spend is reviewed at PR time, not discovered on the monthly bill. You set [iac_tool] and [cloud_provider], give it your [current_spend] and [monthly_budget], and it builds an integration around [cost_tool]: PR comments showing cost deltas, policy enforcement via [policy_tool], right-sizing analysis from [monitoring_data], budget alerts, cost allocation tagging, and savings-plan recommendations.
The structure works because cost control fails when it is reactive. By estimating cost from plan output, posting it on every PR, and blocking changes that exceed [cost_threshold] without [approval_required] sign-off, the spend conversation happens while the change is still cheap to alter. The model also defines [cost_policies] to catch over-provisioning, generates [iac_tool] variable suggestions for under-used [rightsizing_targets], and recommends reservations for [reservation_candidates] — turning cost from an afterthought into a gate. Pricing is scoped to [pricing_regions] and adjusted for [discount_programs], so the numbers reflect what you actually pay rather than list price.
When to use it
- You want cloud cost visible on every PR before infrastructure changes merge
- Your bill keeps creeping up and nobody notices until the invoice lands
- You need policy guardrails like no xlarge instances in dev
- You want right-sizing recommendations grounded in real
[monitoring_data] - You need budget alerts at
[alert_thresholds]routed to the right stakeholders - You are evaluating reserved instances or savings plans and want a data-backed recommendation
- You need cost allocation by team and service for chargeback or showback
Example output
Expect a CI integration spec for [ci_platform] showing the [cost_tool] step and a sample PR comment with current monthly cost, the delta from this PR, and a per-resource-type breakdown. You also get a set of [cost_policies] as enforceable rules, a right-sizing analysis approach using [monitoring_data] over a lookback window, a budget-alert configuration at each of the [alert_thresholds], a tagging scheme using [cost_tags], and a savings-plan recommendation for [reservation_candidates] with projected savings. The cost-allocation section also describes a monthly breakdown report grouped by [breakdown_dimensions], so spend can be attributed back to the teams and services that incurred it.
Pro tips
- Feed real numbers into
[current_spend]and[monthly_budget]so the[cost_threshold]and alert math are grounded, not hypothetical - Account for
[discount_programs]like existing Reserved Instances or an EDP, or the estimates will overstate your true cost - Set
[cost_threshold]low enough to catch meaningful jumps but high enough that routine changes do not need[approval_required]sign-off every time - Make
[cost_policies]specific and enforceable; "no public IPv4 unless justified" is checkable, "keep costs reasonable" is not - Use at least 30 days of
[monitoring_data]for right-sizing so you do not down-size something that spikes weekly - Enforce
[cost_tags]from the start, since untagged resources make[breakdown_dimensions]reporting impossible to reconstruct later - Treat savings-plan recommendations for
[reservation_candidates]as a starting analysis — confirm the usage is genuinely stable before committing to a one-or-three-year term
