What is a Reserved Instance and when does it make sense to commit to one?

An AWS Reserved Instance (RI) is a billing discount applied to EC2 On-Demand usage when you commit to using a specific instance type in a specific region for a one-year or three-year term. The discount ranges from 30–72% depending on the commitment term, payment option (no-upfront, partial-upfront, all-upfront), and instance flexibility (Standard RIs are fixed to a specific instance type; Convertible RIs allow swapping instance families in exchange for a smaller discount). Reserved Instances make economic sense when the workload is predictable and stable — specifically, when the same instance type will run at or near 100% utilization for the duration of the commitment. A baseline database server that runs 24/7 and never scales down is a strong RI candidate. An application tier that autoscales from 4 to 40 instances during business hours is not a candidate for all 40 instances — the 4-instance baseline is an RI candidate, the 36-instance burst is covered by On-Demand or Spot. The decision to commit to a Reserved Instance is irreversible for the commitment period: you pay for the reservation regardless of whether the instance runs. An RI that covers an instance that is later downsized, terminated, or migrated to a different instance type produces sunk cost for the remainder of the term. AWS Savings Plans (Compute Savings Plans and EC2 Instance Savings Plans) offer similar discounts with more flexibility — Compute Savings Plans apply discounts to any EC2 usage within a commitment amount per hour, regardless of instance type, family, or operating system, making them more appropriate for teams with variable or evolving instance mixes. The commitment model decision — RIs vs Savings Plans vs On-Demand vs Spot — should be documented in a cost optimization decision record with the sizing rationale, so that future engineers operating the same infrastructure know whether a given reserved commitment is deliberate (sized against a specific stable workload) or residual (covering a workload that no longer exists at the committed scale).

What is a resource tagging policy and why does it matter for cloud cost management?

A resource tagging policy is the set of rules that determines which metadata tags are applied to cloud resources, what the allowed values are for each tag, and how tagging compliance is enforced. Tags are the mechanism that enables cost attribution — the ability to answer 'how much does this service, team, customer, or environment cost?' from the cloud billing data. Without consistent tagging, the cloud bill shows aggregate spend by resource type (EC2, RDS, S3) and region, but cannot answer operational questions like 'how much does the analytics pipeline cost?' or 'what is the infrastructure cost per enterprise customer?'. A resource tagging policy specifies: the mandatory tags (every resource must carry these — typically service name, environment, team or cost center, and owner); the tag value governance (an allowed-values enum or a naming convention that prevents tag values like 'analytics', 'Analytics', 'ANALYTICS', and 'analytics-pipeline' from fragmenting the same cost category across four tag values); and the enforcement mechanism (AWS Config rules that flag untagged resources, AWS Organizations SCPs that prevent resource creation without required tags, or a CI/CD gate that fails Terraform plans with resources missing required tags). Tag coverage degrades over time without active enforcement. Resources created via the console by engineers who forgot to add tags, resources provisioned by third-party tools that don't forward the tagging policy, and resources created during incident response without time to check the tagging convention all accumulate as untagged spend. Untagged spend at 10% of the total bill is a rounding error; at 40% of the total bill it makes cost attribution meaningless. The cost optimization decision record must specify the enforcement mechanism and the consequence of non-compliance, not just the desired tag structure, because a tagging policy without enforcement produces the same outcome as no tagging policy.

What is cloud cost drift and how should teams detect it?

Cloud cost drift is the accumulation of spend on resources that were deliberately provisioned for a purpose that no longer exists, and on resource configurations that were correct when set but have become suboptimal as the workload has changed. Drift accumulates through several common mechanisms: resources provisioned for a project that was cancelled or completed but not deprovisioned (test RDS instances, S3 buckets used for a one-off data migration, load balancers for a deprecated service); configurations set to a high-cost default that was appropriate initially but has not been reviewed as the workload evolved (RDS automated backup retention at 35 days for development databases, cross-region S3 replication to a DR bucket for a DR plan that was replaced by a different strategy); and commitment mismatches where Reserved Instance coverage exceeds actual utilization because the workload scaled down after the RI was purchased. Detecting drift requires comparing the current resource inventory and configuration to the documented decisions that justified those resources and configurations. This comparison is only possible if the original decisions were documented. A team without a cost optimization decision record — or with only informal documentation — cannot distinguish deliberate spend (we have 35-day backup retention on the production database because the compliance requirement is 30 days plus a 5-day buffer) from drifted spend (we have 35-day backup retention on the development database because the Terraform module default was 35 and nobody changed it). The practical detection mechanism is a monthly drift audit that enumerates all resources over a cost threshold, retrieves their associated decision record or justification, and flags resources where the justification cannot be found or where the underlying need no longer exists. The audit requires a documented starting point — the decisions as they were made — to be effective. Without the starting point, the audit devolves into interviewing engineers to reconstruct reasoning that was never written down, which is exactly the dynamic that makes the first cost audit of a growing SaaS take 40 or more engineer-hours.

What is unit economics in the context of cloud infrastructure?

Unit economics in cloud infrastructure is the cost per meaningful unit of business output — cost per active customer, cost per API request processed, cost per GB of customer data stored, or cost per transaction completed. Unit economics translate aggregate cloud spend (a monthly dollar figure) into a metric that relates infrastructure cost to business value and that can be tracked over time as the product scales. A SaaS company spending $25,000/month on infrastructure with 400 paying customers has a cost per customer of $62.50/month. If the Pro plan is $9/month, the infrastructure cost alone exceeds the plan revenue before accounting for any other operating expenses — the unit economics are negative. The cost per customer metric makes this visible in a way that the aggregate bill does not. Unit economics also reveal scaling behavior: if cost per customer decreases as customer count grows, the infrastructure has positive economies of scale (shared fixed costs are spread across more customers). If cost per customer grows as customer count grows, the infrastructure has negative economies of scale — common in systems where each customer requires dedicated resources (a dedicated database per tenant, dedicated worker processes per customer) without the capacity being shared. The unit economics trend is the leading indicator of whether the product can be profitable at scale. A product where cost per customer is constant regardless of scale has a natural gross margin ceiling. A product where cost per customer trends toward zero as scale increases has improving margins. Documenting the unit economics metric and its current value in the cost optimization decision record gives future engineers a target: optimization decisions are justified by their impact on cost per customer, not by their impact on the aggregate bill.

The cloud cost optimization decision record: why the spending model you chose determines your unit economics ceiling and your cost visibility surface

July 10, 2026 · WhyChose

Cloud spending decisions are made by default. The AWS account is opened, the first EC2 instance is launched on-demand because that is the default, the first RDS instance is configured with 35-day automated backup retention because that is the maximum and the field had a value, the first S3 bucket gets cross-region replication enabled during a DR planning sprint because the intent was to replicate everything important. None of these configurations are wrong when they are set. Each has a justification: on-demand instances because the workload volume is unknown, high backup retention as a precautionary default, cross-region replication for a DR strategy that is actively being planned. The problem is that the justification is not written down anywhere, so when the underlying need disappears — the workload is now well-understood and a 1-year Reserved Instance would save 40%, the DR strategy was replaced by RDS Multi-AZ and the cross-region bucket is now replicating data to a region where no application exists — the cost keeps accumulating invisibly.

The cloud cost optimization decision is not a one-time event. It is a set of architectural choices that determine the spending model, the cost visibility surface, and the waste accumulation rate for the life of the infrastructure. The commitment model (on-demand, Reserved Instances, Savings Plans, Spot) determines the baseline cost and the flexibility to respond to workload changes. The resource tagging policy determines whether the bill can be attributed to teams, services, and customers — or whether it is an opaque aggregate that requires a multi-week investigation to decompose. The waste detection cadence determines how long unnecessary spend persists before being discovered and eliminated. The unit economics metric determines whether the team is optimizing toward a meaningful business target or toward minimizing the aggregate bill, which is a different and less useful goal. All four choices are made — explicitly or by default — at the start, and all four have consequences that compound as the infrastructure grows. The company that has never documented its cost optimization decisions finds itself spending 40 engineer-hours reconstructing them during every major cost audit, unable to distinguish deliberate spend from drift, and unable to hold the line against configurations that made sense once but have outlived their justification.

The cost optimization decision record is not a configuration audit spreadsheet. It is the document that explains why the spending model is what it is — which workloads are on Reserved Instances and why those workloads were judged stable enough to commit to, which resources are deliberately provisioned at higher cost for specific reasons, what the tagging policy is and how it is enforced, and what the trigger is for reviewing the commitment model as the workload evolves. It is the document that lets the next engineer answer the question "why are we paying for this?" without interviewing everyone who was present at the initial provisioning and hoping the reasoning is still in their memory.

Two things that happen when the decision is not written down

The audit incident: $14,200 per month of unnecessary spend that nobody knew was unnecessary

A 45-person B2B SaaS company had been running on AWS for three years when a new VP Engineering ran the team's first formal cost review. Before her arrival, cloud costs were tracked as a line item on the monthly P&L but never decomposed below the level of the AWS invoice total. The invoice had grown from $8,400/month in year one to $52,000/month at the time of her review, an increase that roughly tracked the company's customer and data volume growth. Nobody had questioned it because the trend was directionally expected — more customers, more infrastructure.

The cost review took three weeks and produced four findings that accounted for $14,200/month of spend that had no active justification. The first finding: 73% of EC2 instance cost — $18,900/month — was on-demand pricing despite stable workloads. The application tier, the worker tier, and the database proxy layer had been running at consistent utilization for 22 months with no significant changes in instance type or count. Converting the stable baseline (roughly 80% of the instance count) to 1-year Reserved Instances at the partial-upfront payment option would reduce that cost by $8,800/month. The original decision to use on-demand had been made in year one when workload volatility was genuinely uncertain, but the uncertainty had resolved 18 months earlier. No one had reviewed the commitment model since the initial decision.

The second finding: four S3 buckets had cross-region replication enabled to a us-west-2 "DR bucket" that was receiving approximately 3.8 TB/month of replication traffic at $0.02/GB, plus storage costs for the replicated data. Total monthly cost: $2,340. The cross-region replication had been enabled in month four of operation during a sprint to implement a disaster recovery plan. The DR plan required a replica of the primary database and application state in a second region. Four months later, the team migrated to RDS Multi-AZ with a read replica in a second AZ, which satisfied the DR RPO requirement within us-east-1. The cross-region S3 replication was never disabled because the DR plan migration did not include a checklist of the infrastructure that the old DR strategy had created. The us-west-2 DR bucket now held 11.4 TB of replicated data from three years of replication, all of which was inaccessible — no application existed in us-west-2, no runbook referenced the bucket, and the IAM role that would be used to access it during a DR event had been deleted 14 months earlier during an IAM permission audit. The data was being replicated and stored with no one able to use it.

The third finding: twelve RDS instances — eight development environments and four staging environments — had automated backup retention set to 35 days. The maximum allowed by AWS, and the initial value that had been set in the Terraform module at project creation without modification. Development and staging databases were recreated from Terraform on each sprint cycle; the team never needed to restore a backup from a dev database. The 35-day retention on 12 non-production instances cost $1,840/month. Reducing retention to 7 days on development instances and 14 days on staging instances would cost $310/month — a reduction of $1,530/month. The retention values had never been reviewed because they were set in the Terraform module default and no one had flagged them as cost decisions requiring review.

The fourth finding: three EC2 instances had been in a stopped state for 8 months. Stopped EC2 instances do not incur compute charges, but the 2 TB EBS volumes attached to each instance were incurring $0.10/GB/month in gp3 storage charges. Three instances × 2 TB × $0.10 = $614/month for volumes attached to instances that had not been running since the previous year. The instances had been used for a performance testing project that concluded in the previous October. The engineer who ran the tests had stopped the instances with the intent to terminate them after reviewing the test results but had been pulled onto another project and never returned to the cleanup step. The instances were not in the Terraform state because they had been provisioned manually for the testing project. They did not appear in the team's standard infrastructure inventory because that inventory was derived from Terraform state. They were invisible to the regular infrastructure review process until the cost audit specifically enumerated all EC2 resources in the account, including stopped instances.

Total unnecessary spend identified: $14,200/month. Total time to identify: 65 engineer-hours across the three-week review — the VP Engineering's time plus two senior engineers who helped trace the history of the configurations. At the end of the audit, the VP Engineering prepared a remediation plan. Three months later, she ran a follow-up review to confirm that the remediations had been applied. The follow-up review took 25 hours because the team could not recall which specific instances had been converted to Reserved Instances and which had remained on-demand, which buckets had had replication disabled, and which RDS instances had had backup retention reduced. No document had been produced from the first audit that described the decisions made and the expected state after remediation. The 25-hour follow-up audit reproduced approximately 60% of the work of the original audit to establish the baseline that the original audit had established but not recorded.

The credit exhaustion incident: $8,400 in engineer time to discover undocumented service dependencies during a forced deprecation

A 28-person developer tools startup received $200,000 in AWS credits through an accelerator program at their Series A. The CTO made a deliberate decision at the time: no cost optimization work until credits were exhausted. The reasoning was sound — engineering time optimizing costs at $0 effective spend is engineering time not building product. The decision was Slack-communicated: "We've got $200k in AWS credits, plenty of runway. Let's not touch cost optimization until we have to." No one wrote down what "until we have to" meant specifically, what the exit criteria were, or what review process should happen when credits were approaching exhaustion.

The credits lasted 16 months instead of the projected 24 months because the product scaled faster than the estimate and the company added three infrastructure-heavy features in the first year. With two months of credits remaining, a developer running a routine billing dashboard check noticed the accelerated depletion rate and raised an alert. The CTO assembled a two-engineer team to run an emergency cost audit before the credits expired and the first real payment was due.

The audit identified 8 services that the product had pivoted away from in months 8 through 14 of the credit period. The product originally launched with a browser-based code execution environment as a core feature. That feature was replaced in month 8 by a GitHub Actions integration after user research showed engineers preferred not to switch context to a browser IDE. The browser execution feature required 3 services: a container orchestration service for spinning up execution environments, a file storage service for persisting user workspaces between sessions, and a session management service for maintaining active connections. All three continued running after month 8. They served zero user traffic — the product routing had been updated to direct all users to the GitHub Actions flow — but they were available, their infrastructure was provisioned, and their supporting services (load balancers, Redis clusters for session state) were running and accruing cost.

Additionally, 5 services from an early enterprise feature set (custom domain routing, SAML SSO integration, audit log export, team permission management, and usage analytics) had been built during months 4–7 and used by 3 enterprise pilot customers who churned before month 10. The features were not removed from the product roadmap — they remained in "to be relaunched for enterprise tier" status — so the services were kept running. Twelve months after the last pilot customer had stopped using them, the services were still active.

The cost of the 8 services: $4,800/month. On credits this was invisible; as real spend, $4,800/month was 15% of the company's post-credit infrastructure projection. The two engineers began deprecation planning. The expected timeline was 6 weeks: 1 week to audit dependencies, 4 weeks to route around each deprecated service and deploy the changes, 1 week of parallel running before shutdown. The actual timeline was 11 weeks. The audit week surfaced that two of the 8 deprecated services were still being called by other services that the team believed were independent. The file storage service (for the deprecated browser execution feature) was being used as a general-purpose temporary file store by the user upload pipeline — a use that had been added as a "quick solution" by an engineer who knew the file storage service existed and that it had the right APIs. The session management service was being polled by the analytics service for active session counts, used to populate a real-time user count dashboard that the team watched internally during launches. Neither dependency had been documented anywhere. Both had been added as local engineering decisions without going through the service dependency tracking that the company's architectural governance process nominally required for cross-service integrations. Deprecating the file storage service required migrating the user upload pipeline to S3 (4 weeks of engineering), and deprecating the session management service required building an alternative active-user metric from the application logs (2 weeks). The 11-week elapsed time cost $4,800/month × 2.75 months = $13,200 in infrastructure that should have been shut down, plus approximately $8,400 in engineer time to discover, route around, and validate the removal of the undocumented dependencies.

The CTO's original decision — defer cost optimization during the credit period — was correct. The missing piece was the exit criteria: a formal pre-credit-exhaustion audit scheduled 90 days before projected credit depletion, following a documented service inventory and dependency map. Without the inventory, the exit from the credit period was not planned — it was reactive. Without the dependency map, the deprecation of the pivoted-away services was not a scheduled 6-week project — it was an 11-week investigation. Both documents were missing because no cost optimization decision record had been written at the time the credit-deferral decision was made, and no checkpoint had been established to create one before the exit criteria were met.

Three structural properties that are set at cost optimization decision time

The commitment model and the waste floor

The commitment model — the selection among on-demand pricing, Reserved Instances, Savings Plans, and Spot instances — is the most consequential unit cost decision in cloud infrastructure, and the one most frequently made by default rather than by analysis. On-demand pricing is the default because it requires no commitment and no forecast. Its cost is also 40–70% higher than the equivalent Reserved Instance or Savings Plan for workloads that run continuously at stable scale. The waste floor of an on-demand commitment model is zero — you only pay for what you run — but the unit cost ceiling is the highest available. The waste floor of a committed model is the commitment cost minus the actual utilization: a 1-year RI for an instance that runs at 40% utilization for the last 4 months of the term (because the workload scaled down) wastes 60% of the committed cost for those 4 months. The commitment model decision is a bet on future workload stability.

The decision must specify separately for each major workload category: database tier (typically the most stable — RDS instances rarely change size by more than one step in a year, making 1-year RIs a strong commitment candidate), application tier (often variable, requiring a baseline RI commitment plus on-demand for burst capacity), worker tier (depends heavily on job volume, often amenable to Savings Plans that cover the baseline and on-demand for spikes), and development/staging environments (on-demand or no commitment — the waste from over-committing dev environments exceeds any savings from commitment, and dev environments are frequently scaled down or destroyed between sprints). Each tier's commitment level should be documented with the utilization evidence that justified it: "production database tier committed to 1-year Standard RIs at partial-upfront in March 2025 based on 94% average utilization over the preceding 12 months with no changes to instance type or count during that period; commitment reviewed annually in March." Without this documentation, the commitment model cannot be maintained — the engineer who renews the RIs 12 months later does not know whether the underlying utilization evidence still supports the same commitment level, and defaults to renewing at the same level because the alternative (re-doing the utilization analysis) requires effort and the deadline is approaching.

AWS Savings Plans offer an important alternative for teams with variable instance mix. A Compute Savings Plan commits to a dollar-per-hour spend floor (e.g., $0.50/hour) and applies a discount to all EC2, Lambda, and Fargate usage up to that committed amount, regardless of instance type, family, region, or operating system. This flexibility makes Savings Plans more appropriate than Standard RIs for teams that change instance families frequently (migrating from m5 to m6i, or from EC2 to Graviton/ARM instances), because Standard RIs are locked to a specific instance family and cannot be applied to a different family. The commitment model decision record should document which workloads use RIs (stable, single-instance-family workloads), which use Savings Plans (variable or multi-family workloads), and which remain on-demand (burst, development, or workloads with high change probability). This connects to the capacity planning decision record: the commitment model and the capacity planning model are interdependent — the reserved capacity commitment assumes a specific capacity baseline, and the capacity planning baseline determines what that commitment should be. If the capacity planning review identifies that the baseline should be downsized, the commitment model must also be reviewed to avoid paying for reserved capacity that exceeds the new baseline.

The commitment renewal trigger must also be documented. A Reserved Instance or Savings Plan that is renewed automatically without review will accumulate commitment-workload mismatches over time. The renewal trigger should be a utilization review 90 days before the commitment expiry — enough time to run the analysis, make the renewal decision, and if necessary purchase a different commitment level rather than defaulting to renewal. The 90-day lead time is the minimum; 120 days is better for teams that need to run a capacity planning cycle to inform the commitment level. Document the trigger, the utilization threshold that justifies maintaining the current commitment (e.g., "renew at the same level if utilization ≥ 80%; downsize if utilization is 60–80%; let expire and re-evaluate on-demand if utilization is < 60%"), and who is responsible for executing the review.

The cost attribution surface and the unit economics visibility

Cost attribution is the ability to answer "how much does this service, team, customer, or environment cost?" from the cloud billing data. Without attribution, the monthly cloud bill is an opaque aggregate — $52,000 in AWS charges — that cannot be meaningfully decomposed for optimization decisions, engineering team accountability, or product-level margin analysis. Attribution requires consistent, enforced resource tagging: every resource carries metadata that connects it to the service, team, environment, and cost center it belongs to. Without enforcement, tag coverage degrades to the point where attribution becomes unreliable, because the untagged fraction of spend is unknown and may be distributed across services in a way that distorts the per-service cost figures.

The tagging policy decision must address four things: the mandatory tag set (the minimum tags every resource must carry), the tag value governance (enforced enum values or naming conventions that prevent the same cost category from splitting across multiple tag values like "backend", "Backend", "backend-api", and "api"), the enforcement mechanism (policy-based enforcement via AWS Config or Organizations SCPs that prevent resource creation without required tags, or CI/CD enforcement via Terraform plan gates), and the exception process (what happens when a resource cannot be tagged with the mandatory set — emergency console-provisioned resources, resources created by vendor tools). A tagging policy without an enforcement mechanism is a guideline, and guidelines produce 60–70% compliance at best. A 30% untagged spend fraction makes cost attribution unreliable for the services that are hardest to attribute — typically the ones that are most over-provisioned, because the engineers who provisioned them didn't follow the tagging convention and also may not have followed the capacity planning convention.

Unit economics — cost per paying customer, cost per API call, cost per GB processed — translates the tagged spend data into a metric that connects infrastructure cost to business value. The unit economics metric is specific to the product model: for a SaaS with per-seat pricing, cost per active seat is the relevant metric; for an API business with per-request pricing, cost per 1000 requests is the relevant metric; for a storage product, cost per GB of customer data stored is the relevant metric. The unit economics metric makes two things visible that the aggregate bill cannot. First, the scaling curve: does infrastructure cost per unit decrease as volume grows (positive economies of scale — fixed costs amortized across more units) or increase (negative economies of scale — variable costs growing faster than revenue)? A product where cost per customer grows as customer count grows has a structural margin problem that will not improve at scale; a product where cost per customer decreases as customer count grows has a margin improvement story that investors and operators find compelling. Second, the optimization impact: a Reserved Instance conversion that saves $8,800/month on a base of 400 customers reduces cost per customer by $22/month. If the Pro plan is $9/month, the infrastructure unit economics remain negative even after the optimization, and the optimization did not change the fundamental economics — it reduced the magnitude of the problem but did not solve it. This connects to the build-vs-buy decision record: the build-vs-buy decision for infrastructure components directly affects unit economics — building a custom caching layer might reduce database cost per customer by $5/month while adding $15/month in engineering maintenance cost per customer at the team's headcount; buying a managed service might cost $8/month per customer with no maintenance overhead. The unit economics impact of build-vs-buy decisions can only be measured if the tagging policy provides per-service cost attribution and the unit economics metric is tracked over time.

The cost attribution decision record must specify the unit economics metric(s) for the product, the data sources for calculating them (which cost explorer tags map to which business units, how to join the infrastructure cost data to the customer count or request volume data), and the review cadence at which unit economics are checked against the plan. A unit economics metric that is never reviewed is data collected and ignored; a metric that is reviewed monthly with a target trend provides the optimization compass that individual cost decisions can be oriented around. This connects to the data pipeline decision record: calculating unit economics from cloud billing data requires a pipeline that joins cost explorer data (exported to S3 or queried via the Cost Explorer API) with customer or usage data from the application database, enriches it with the resource tagging hierarchy, and aggregates to the unit economics metric on a schedule. This pipeline is itself a cost center (compute, storage, query costs) and should be designed accordingly — a daily unit economics update is sufficient for most planning purposes and far cheaper to compute than a real-time unit economics dashboard.

The waste detection cadence and the drift accumulation rate

Cloud cost waste accumulates continuously. Resources are provisioned for projects that complete without cleanup, configurations are set to high-cost defaults that are never reviewed, and commitment coverage drifts out of alignment with actual utilization as workloads evolve. The drift accumulation rate — the speed at which waste accumulates per month of unreviewed infrastructure — is a function of team size, deployment frequency, and the proportion of infrastructure changes that include a cleanup step for previously existing resources. Teams that deploy frequently and have mature infrastructure-as-code discipline accumulate waste more slowly because Terraform plans make the full resource delta visible at each deployment, and it is easier to add a cleanup step at deployment time than to schedule a separate cleanup process. Teams that provision via the console and do not use infrastructure-as-code accumulate waste faster because there is no consolidated view of what exists and what each resource's current purpose is.

The waste detection policy specifies the cadence, scope, and output format for reviewing existing infrastructure against documented justifications. A useful waste detection policy has two components: a continuous detection layer and a periodic audit layer. The continuous detection layer uses automated tooling (AWS Cost Anomaly Detection, Datadog Cost Management, Spot.io, or equivalent) to flag cost anomalies — spend increases above a threshold percentage week-over-week — and sends alerts when anomalies are detected. Anomaly detection catches acute cost events: a new service deployed without Reserved Instance coverage that immediately adds $3,000/month to the EC2 bill, or a debug logging level accidentally left enabled in production that triples CloudWatch Logs ingestion cost. Anomaly detection does not catch chronic drift — the cross-region replication that is draining $2,340/month for 14 months is not an anomaly because it has been at the same cost level throughout and does not deviate from recent historical spend. Chronic drift requires a periodic audit.

The periodic audit — typically monthly or quarterly depending on team size and spend level — enumerates resources above a cost threshold and compares each against a documented justification. The audit output is a list of resources where: (a) the justification was found and is still valid — no action needed; (b) the justification was found but the underlying need no longer exists — deprecation action required; (c) no justification was found — owner identification required, followed by justification or deprecation. The audit is only as effective as the documented justifications it can check against. An infrastructure with no decision records for cost-significant resources cannot have an effective periodic audit — the audit degrades into an investigation, requiring the same research effort every quarter to reconstruct reasoning that should have been written down once. This connects to the disaster recovery decision record: DR infrastructure (cross-region database replicas, S3 replication buckets, standby compute capacity) is a significant cost line that often lacks a clear justification after the DR plan has been revised. The DR decision record specifies what infrastructure is required for each DR tier; the cost optimization audit checks whether the existing DR infrastructure matches the DR decision record, and flags DR infrastructure that is not covered by an active DR plan tier. The cross-region S3 bucket in the first story existed because the initial DR plan specified S3 replication; it persisted because neither the DR plan revision nor the cost optimization process had the other as a dependency.

The drift accumulation rate also connects to the rate at which engineers who know the original justification for a resource leave the team. A three-year-old resource provisioned by an engineer who left 18 months ago has no living institutional memory of its purpose. If the resource was not documented, the cost optimization audit must treat it as having no known justification and spend time reconstructing its purpose — which often means reading CloudWatch access logs, tracing which applications call the resource's API, and guessing from the resource name and configuration what it might be for. This is the same dynamic described in the new-CTO onboarding problem and the decisions never written down essay: the undocumented infrastructure decision is not a problem while the people who made it are present; it becomes a problem when they leave or when someone new needs to evaluate whether the resource is still justified. Cloud cost optimization surfacing as a recurring quarterly investigation rather than a verified decision baseline is a specific manifestation of the same pattern.

Five sections the cloud cost optimization decision record should address

1. Commitment model selection and sizing rationale per workload tier

Document the commitment model for each major workload tier: the production application tier, the database tier, the worker or batch processing tier, the data pipeline tier, and the development/staging environments. For each tier, document the current commitment type (on-demand, Standard RI, Convertible RI, Compute Savings Plan, Spot), the sizing basis (the utilization evidence that justified the commitment level — a specific utilization time series, the number of instances that run at baseline, the variance in instance count over the preceding 12 months), the commitment amount (how many instances or how many dollars per hour of Savings Plan commitment), the expiration date, and the renewal trigger and review owner.

The sizing rationale is the most important element to document because it is the only element that allows future engineers to evaluate whether the commitment is still appropriate. "We have 12 m6i.2xlarge RIs for the application tier because our production application tier has run at 10–14 instances continuously for 18 months with no instance type changes, and the 12 RI baseline covers our P10 instance count with 2 instances of headroom, leaving burst above 12 instances to on-demand" is a commitment that a future engineer can evaluate by checking current utilization against the documented baseline. "We have 12 RIs for the application tier" is not. The renewal trigger documentation should be specific: "Review 90 days before expiry (December 15, 2026). Renew at same level if 12-month average utilization ≥ 80% of the committed count. Downsize by 20% if utilization is 60–80%. Let expire and remain on-demand for one quarter if utilization is < 60% (then re-evaluate)." The owner identification — who is responsible for executing the review — prevents the renewal from being missed because everyone assumed someone else was monitoring the expiration date. This connects to the platform engineering decision record: at sufficient team size, the commitment model review is owned by the platform team as part of the infrastructure reliability and cost charter; smaller teams should designate a specific role (typically the most senior infrastructure engineer) rather than leaving ownership implicit.

2. Resource tagging policy and cost attribution hierarchy

Document the mandatory tag set with the purpose of each tag and the allowed values or naming convention. A useful mandatory tag set for most SaaS companies includes: service (the application or microservice that owns this resource — matched to the service catalog), environment (production, staging, development, testing — an enforced enum), team (the engineering team responsible for the resource — matched to the team registry), and cost-center (the accounting cost center for billing allocation — typically matches team or product area). Optional but valuable: project (for temporary resources created for a specific initiative — includes an expected deprecation date, useful for identifying resources that were provisioned for a completed project and never cleaned up) and owner (the individual or on-call rotation responsible for the resource — enables reaching a human when an unrecognized resource appears in the audit).

Document the enforcement mechanism with specificity: which mechanism prevents resource creation without required tags (AWS Config rule with remediation action, AWS Organizations SCP with Deny on CreateResource for resources without mandatory tags, or Terraform plan gate that fails on missing tags), which mechanism flags existing resources that become untagged (AWS Config rule with daily evaluation, tag compliance report in Cost Explorer, or weekly tagging compliance dashboard), and what the remediation SLA is for untagged resources (24 hours for resources above $100/month cost threshold, 7 days for resources below that threshold). Document the exception process: resources provisioned during incident response may lack tags due to time pressure; the exception process requires tagging the resource within 24 hours of incident resolution and adding a project tag documenting the incident reference. Tag exceptions that are not time-bounded (resources that "can't be tagged for technical reasons") are almost always technical debt from a provisioning tool that doesn't support the tagging API — document the tool as a known gap and the remediation plan.

Document the cost attribution reporting hierarchy: which reports are generated from the tagged data (per-service monthly cost, per-environment cost, per-team cost), at what cadence they are generated (weekly for operational review, monthly for P&L allocation), and who consumes each report. The cost attribution hierarchy should map to the organizational structure — a per-team cost report that no team lead reviews is data collected and ignored. This connects to the data retention decision record: cloud billing data retained in Cost Explorer for the standard 12-month window enables monthly trend analysis but does not provide the 36-month historical data needed to analyze multi-year scaling curves and commitment model changes. If unit economics trend analysis over the company's full operating history is a business requirement, the billing data should be exported to S3 and archived in a long-retention tier, with the retention policy and query access documented in the data retention decision record.

3. Waste detection policy and drift trigger criteria

Document the two-layer waste detection approach: continuous anomaly detection and periodic audit. For continuous detection, document the anomaly detection tool and configuration: the percentage threshold that triggers an alert (e.g., week-over-week spend increase ≥ 20% in any cost category with a 7-day spend above $500), the notification channel (PagerDuty for anomalies above $5,000/week, Slack for anomalies $1,000–$5,000/week, email digest for anomalies below $1,000/week), and the expected response time (acknowledged within 4 hours for large anomalies, within 48 hours for small anomalies). Anomaly detection without a defined response time and owner produces alerts that are read and dismissed without investigation.

For the periodic audit, document the audit cadence (monthly for teams spending above $20,000/month, quarterly for teams spending below), the resource scope (all resources with a monthly cost above a threshold, typically $100/month), the audit procedure (enumerate resources from Cost Explorer or AWS resource inventory, check each against the documented justification in the cost optimization decision record or Terraform state comments, flag resources where the justification is absent or stale), and the output format (a list of resources with status: justified, stale-justification, or unknown, with action items for stale and unknown resources). Document the criteria that define a justification as "stale": the underlying project or feature is no longer in the product, the DR plan or backup policy that required the resource has been replaced, or the utilization evidence that justified the resource size shows the resource is consistently over-provisioned by more than 50%.

Document the deprecation authorization process for resources identified as waste: who can authorize the deprecation of a production resource (typically requires the owning team lead plus infrastructure lead sign-off), the required pre-deprecation steps (confirming no active traffic or dependencies, verifying the resource is not referenced in any active runbook or DR plan, creating a backup of stateful resources before deletion), and the retention period for deletion audit records (which engineer authorized and executed each deletion, for compliance and incident investigation purposes). This prevents the dynamic where waste is identified but deprecation is blocked indefinitely because no one has authority to act on it. This connects to the container orchestration decision record: Kubernetes cluster cost is one of the most common sources of cloud waste that is invisible to standard cost audits — idle namespace resources (deployments with zero replicas, PersistentVolumeClaims not bound to any pod, load balancers with no backend pods) do not appear in application metrics but do appear in cloud billing; the periodic audit must include cluster-level resource inventory for teams running Kubernetes.

4. Reserved capacity commitment sizing and renewal cadence

Document the commitment sizing methodology as a reproducible procedure: (1) retrieve the 12-month utilization time series for the resource type and tier from CloudWatch metrics or Cost Explorer EC2 instance usage reports; (2) calculate the P10 utilization (the count below which actual utilization falls only 10% of the time — this is the safe committed baseline); (3) subtract 10–20% as a buffer for unexpected downscaling; (4) the result is the RI or Savings Plan commitment amount; (5) on-demand covers everything above the committed baseline. The P10 utilization basis (rather than average or P50) is the conservative choice that prevents over-commitment in volatile workloads while still capturing the majority of savings on stable workloads.

Document the renewal schedule explicitly as a calendar event or infrastructure task, not as a mental note. A commitment that expires and reverts to on-demand without notice because the renewal review was missed is a common source of sudden cost increases — the team notices the invoice is $8,000 higher than last month and cannot immediately explain why (it is not a cost anomaly in the anomaly detection sense, because the increase happened on a specific date rather than gradually). The renewal calendar event should trigger the utilization review procedure 90 days before expiration, with a decision documented before 30 days before expiration (to provide time to purchase the renewal or decide against it). The renewal decision — renew, downsize, let expire — should be written to the cost optimization decision record as an update to the commitment documentation, so the history of commitment sizing decisions is preserved and auditable.

Document the Spot instance policy if Spot instances are used for any workload. Spot instances are 60–90% cheaper than on-demand for the same instance type, but they can be interrupted with 2-minute notice when AWS reclaims the capacity. The Spot interruption handling requirement — checkpointing, graceful shutdown hooks, workload restart capability — must be documented as an application requirement for any service or worker that uses Spot instances. A Spot interruption that terminates a long-running batch job without checkpointing wastes the job's entire elapsed compute time. The Spot instance policy should specify which workloads are eligible (stateless workers, idempotent batch jobs, fault-tolerant distributed workloads — not stateful services, not jobs without checkpoint capability), the interruption handling mechanism, and the fallback behavior when Spot capacity is unavailable (typically a fallback to on-demand for the specific instance type or a different Spot pool). This connects to the background job infrastructure decision record: the job infrastructure's retry and checkpoint mechanism is the prerequisite for Spot eligibility — jobs that cannot tolerate interruption cannot run on Spot, and the cost savings from Spot are unavailable until the job infrastructure has the required fault tolerance.

5. Cost optimization review cadence and decision audit trail

Document the recurring cost optimization review as a scheduled process with specified inputs, outputs, and decision owners. The monthly operational review (appropriate for teams spending above $10,000/month) should cover: the month's spend vs. the month's budget with variance analysis (which categories are above and below plan), the unit economics metric for the month vs. the prior quarter trend, any anomalies detected during the month and their resolutions, and any commitment renewals due in the next 90 days. The output is a written summary — not a verbal review — that records what was reviewed, what was within expected bounds, and what actions were taken for variances. This written summary is the ongoing component of the cost optimization decision record: it accumulates the month-by-month history of cost decisions and their outcomes, enabling future engineers to trace the evolution of the spending model rather than reconstructing it from billing data.

The quarterly strategic review (appropriate regardless of spend level) covers the commitment model alignment (is the current RI/Savings Plan coverage appropriate given the past 90 days of utilization?), the unit economics trend (is cost per customer trending in the right direction?), the tagging compliance rate (what percentage of spend is attributed and what percentage is untagged?), and upcoming infrastructure changes that will affect cost in the next quarter (new services being launched, workloads being scaled up, services being deprecated). The quarterly review is the point at which the cost optimization decision record itself is reviewed for accuracy — decisions that have been made since the last quarterly review are added, and decisions that are no longer accurate are updated or removed.

The decision audit trail — the history of who decided what, when, and why — is what makes the cost optimization process maintainable across engineering team changes. The VP Engineering in the first story spent 65 hours reconstructing decisions that the team had made over three years because those decisions existed only in the memory of the engineers who had made them, not in any document. A monthly 30-minute written summary and a quarterly cost decision review would have produced the documentation needed to make the periodic audit a 10-hour verification exercise rather than a 65-hour investigation. The WhyChose extractor can recover cost optimization decisions from ChatGPT or Claude conversations: the Slack thread where the CTO said "don't worry about cost until credits run out" was a decision that a WhyChose extraction would surface, along with the reasoning and the follow-up actions that were discussed. The thread that analyzed which EC2 instances to convert to Reserved Instances, or the conversation where the S3 cross-region replication strategy was designed, contains the reasoning that should have been formalized into the decision record. The decisions never written down essay covers why infrastructure decisions are particularly likely to be missing from documentation: they are made under time pressure, by engineers whose goal is to resolve an operational problem rather than to document architectural choices, and they produce configurations that are correct when set and invisible until something reveals that the underlying justification has evaporated.

The ADR template provides the structure for documenting the cost optimization decisions: the commitment model selection as the decision, the utilization evidence and cost projections as the rationale, the renewal trigger as the consequences and monitoring, and the waste detection policy as the operational section. A cost optimization ADR is not a compliance document — it is the operational baseline that makes every future cost audit start from a known state rather than a blank page.