Because infrastructure as code standardises creation, not necessarily ownership, teardown, or approval. If teams do not encode cleanup, budget thresholds, and review gates, Terraform can reproduce inefficient patterns at scale. The bill then reflects governance gaps, not just technical configuration.
Why AWS bills keep climbing after infrastructure as code is in place
Infrastructure as code solves repeatability, but it does not automatically solve cost ownership. If the codebase can create resources faster than teams can review, tag, approve, or tear them down, spend will still grow. The cost problem often shifts from manual provisioning errors to automated governance gaps, especially when defaults are left unchanged.
IaC is excellent at making infrastructure consistent, which is useful for scale and reliability. The drawback is that consistency also reproduces waste consistently. An oversized instance, an always-on environment, or an orphaned data store can be recreated on every deploy unless the template or pipeline explicitly prevents it. In practice, the bill reflects what the workflow permits, not just what the code describes.
That is why cost control has to be built into the lifecycle, not bolted on after deployment. Cleanup logic, environment expiry, ownership metadata, and approval thresholds are part of the control plane for spend. Without them, the organisation gets deterministic provisioning of nondeterministic waste: the same unnecessary resources, created repeatedly, at machine speed.
Where automation hides the waste
Cloud spend often rises because IaC makes it easy to generate more environments than the organisation can govern. Developers spin up review stacks, test replicas, and temporary databases, then move on while those assets remain live. If teardown is optional, delayed, or dependent on a manual ticket, the resources outlive the need that created them.
This is not only a pricing issue, it is a governance issue. Ownership decides who is accountable for the running cost, approval decides whether the resource should exist, and lifecycle controls decide when it must end. When those decisions are missing from the pipeline, infrastructure as code becomes a scaling mechanism for unmanaged consumption rather than a control mechanism for it.
Network, storage, and compute choices can also amplify the effect. The same IaC pattern that provisions a small internal test service can accidentally stamp out public-facing load balancers, NAT gateways, logging pipelines, and attached volumes across every environment. The design may be technically correct, yet still expensive because the template encodes a production-shaped footprint where a smaller footprint would suffice.
What has to be encoded to make cost predictable
Cost predictability improves when IaC includes decision points, not just resource definitions. Budget thresholds, time-to-live rules, mandatory tags, environment labels, and exception handling should be part of the deployment path. Those controls make spend visible and enforceable before the cloud resource becomes a recurring line item.
Review gates matter because they stop the silent spread of expensive defaults. A pipeline that checks whether a resource has an owner, an expiry date, and a cost centre forces the team to answer the operational question at creation time: does this resource still need to exist, and if so, under what bounds? For cloud governance teams, CSA Cloud Controls Matrix is a useful reference point for linking cloud controls to IAM, audit, and operational discipline.
Lifecycle control also means designing for teardown as a first-class action. That includes scheduled expiry for ephemeral environments, automated retirement for unused stacks, and periodic recertification for long-lived services. When teams treat deletion as a control rather than an afterthought, they reduce the chance that short-lived work becomes permanent spend.
For cloud environment governance, the same principle applies to identity-bearing access paths. Cloud Workload Identity Guide is relevant when teams need to stop relying on standing access patterns that keep resources and credentials alive longer than intended.
Why cost control fails in practice, even with good templates
The most common failure is assuming that technical standardisation equals financial control. It does not. Standardising instance types, networks, and storage classes still allows every team to create too many of them, keep them too long, or use more expensive service tiers than the workload needs. Consistency without constraint simply produces consistent overspend.
Another failure is weak ownership. If nobody owns the running cost of a sandbox, proof-of-concept, or shared platform component, no one feels pressure to remove it. Over time, these forgotten assets accumulate in the background, especially in fast-moving teams where delivery velocity is rewarded more visibly than resource retirement.
That pattern is well documented in cloud abuse and misconfiguration cases. Exposed credentials and unmanaged cloud resources are attractive because once an environment exists, it can often be extended, reused, or left idle with little immediate friction. The operational lesson is that cloud cost growth and cloud exposure often come from the same root cause: poor control of the resource lifecycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | Cloud cost drift here is a cloud governance and ownership problem. |
| IAM — Identity and Access Management | Persistent cloud spend often follows standing access and weak lifecycle control. | |
| Recommendation — Define ownership, approval, and review controls for cloud spend and enforced teardown. Restrict standing access and tie resource creation to approved, accountable identities. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The issue is unmanaged operational and financial risk from automated cloud growth. |
| PR.PO-01 — Policies for policies, processes and procedures | Cost control needs policy-driven guardrails for resource creation and retention. | |
| Recommendation — Embed cost thresholds and lifecycle review into the cloud risk strategy. Require policy-backed tagging, expiry, and approval rules in deployment workflows. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | IaC standardises baselines, but the baseline must include cost-aware defaults. |
| Recommendation — Set cost-aware approved baselines for cloud resource templates. | ||
Practitioner Guidance
What to verify: Check whether each resource class has an owner, an expiry rule, and a deletion path. If a template can create something that nobody is obliged to review later, expect cost drift even when provisioning is fully automated.
Decision rule: If the resource is temporary, encode automatic teardown and refuse exceptions unless someone explicitly accepts the ongoing spend. If the resource is shared or persistent, require budget ownership and periodic recertification before it is promoted beyond its original use case.
What to measure: Track orphaned resources, aged non-production environments, and spend by unowned tag or missing owner field. Those are stronger signals of governance failure than raw monthly spend alone because they show where IaC is being used without lifecycle discipline.
Common mistake: Teams often fixate on right-sizing while leaving environment sprawl untouched. Rightsizing helps, but it does not solve the larger problem if test stacks, forgotten volumes, and idle services are still being recreated and retained by default.
Practitioner takeaway: Treat infrastructure as code as a provisioning control, not a cost-control control. Cost only becomes predictable when ownership, expiry, and approval are encoded with the same discipline as the resource definitions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org