What can go wrong without one
Cloud costs move fast, and the consequences of a poor or missing forecast tend to surface at the worst possible moments. Over-commitment from a stale baseline. A company commits to three years of Reserved Instances based on current EC2 spend. Six months later, the engineering team migrates a core service to containers. The RI coverage no longer matches the workload — and the company is locked into paying for capacity it no longer uses. AWS does offer a Reserved Instance Marketplace where unused commitments can be listed for sale, but it is not a reliable exit: listings may take weeks or months to sell, there is no guarantee of a buyer, and selling typically means accepting a discount on the remaining value. For most companies, an unwanted multi-year commitment is effectively a sunk cost. Under-commitment from excessive caution. Without a forecast grounded in business growth, the risk of over-committing feels high and commitments are sized conservatively. A year later the business has grown 40%, on-demand rates have applied to most of that growth, and the difference — hundreds of thousands of dollars — was simply left on the table. Finance and Engineering out of sync. Engineering completes a major infrastructure migration that reduces costs by 30%. Finance, unaware it was happening, had already signed off on a budget based on the old spend level. When the bill comes in lower, it looks like a planning failure rather than an engineering win — and the savings aren’t captured in next year’s targets. Commitment proposals built on the wrong signal. Without a forecast that reflects real business context, any commitment recommendation is sized against what has already happened — not where the business is actually going.How AWS-native recommendations compare
AWS offers its own commitment recommendations — Savings Plans and Reserved Instance suggestions surfaced directly in the AWS console. These are useful as a starting point, but they are built entirely on your historical usage patterns. AWS looks backward. That works reasonably well for workloads that are stable and mature — infrastructure that runs at roughly the same level month after month. It breaks down quickly for businesses that are growing, changing, or planning ahead. AWS has no visibility into your business plan. It cannot know that you are launching in a new market next quarter, that you are planning to migrate off EC2 in Q3, or that an engineering initiative will reduce your RDS spend by 40% over the next six months. It cannot distinguish between production workloads that scale with revenue and non-production environments that should stay flat. Every commitment proposal it surfaces is a backward-looking guess applied to a forward-looking question. The practical consequences:- Growing businesses routinely get under-commitment recommendations because recent usage is lower than future usage will be — AWS has no way to account for planned growth.
- Businesses with planned infrastructure changes get proposals that ignore those changes entirely, creating commitment mismatches that only surface after the workload moves.
- Finance and engineering are not in the picture at all. The recommendation comes from a usage graph, not from the people who understand where the business is going.
What good forecasting enables
Commitments sized to your actual trajectory — without the risk paralysis. Most companies under-commit, or avoid committing altogether, because the downside of getting it wrong feels too large to absorb. The risk analysis, the sizing decisions, the exposure if conditions shift — Cloud Capital takes that on. Your job is to keep the forecast current: maintain your business metrics, keep engineering initiatives up to date, and reflect your real business structure in your Cost Layers. Cloud Capital does the rest, and the Guaranteed Savings Rate is what you get in return — maximum savings, with the risk carried by Cloud Capital, not your finance team. A Guaranteed Savings Rate that holds. The GSR is a certainty your finance team can count on in a world where almost everything else about cloud costs is variable. It is not a target or an estimate — it is a rate Cloud Capital calculates based on your forecast and stands behind. Your business metrics and engineering initiatives are the inputs that make that calculation precise. Even if conditions change — growth accelerates, a migration completes ahead of schedule, a new product launches — the GSR holds. That stability is what makes it useful as a planning number. No surprises at budget time. A live forecast that incorporates your business metrics means finance teams see cost changes coming before they hit the bill. A product launch, a new market expansion, a planned migration — all of these affect cloud spend, and all of them can be modelled in advance. Engineering initiatives that are financially visible. When planned infrastructure changes are captured as Engineering Initiatives, finance sees the cost impact before it materialises. Migrations, deprecations, and new service launches become part of the financial plan rather than surprises in the next invoice. A shared model for two teams that need to work together. Cloud spend sits at the intersection of Engineering decisions and Finance accountability. A well-structured forecast gives both teams a common reference point — the same numbers, the same assumptions, the same model. That alignment is what makes budget conversations productive instead of contentious, and it is what enables Cloud Capital to do its best work on your behalf.How a forecast is built
Cloud Capital’s forecast is built from four inputs, applied in sequence. Each layer adds signal that makes the overall model more accurate and the resulting savings more optimised.1. Cost Layers — your business structure
Cost Layers are how you map your cloud infrastructure to the categories your finance team actually uses. Production vs. Non-Production at the minimum — COGS vs. OpEx in financial terms. Sub-layers beneath them reflect products, teams, regions, or service families wherever that granularity matters. The Cost Layer structure is the skeleton of your forecast. Everything else — metrics, projections, initiatives — operates within it. A flat, undifferentiated structure produces a flat, undifferentiated forecast. Granularity here pays dividends across every downstream use.2. Business Metrics — your growth signal
Business Metrics are external datasets — customer count, active users, revenue, transactions — that correlate with your cloud spend. When a business metric is connected to a Cost Layer, Cloud Capital uses the relationship between historical metric values and historical cost to project how costs will move as the metric changes. This is the step that connects your cloud forecast to your business plan. Instead of extrapolating from a cost trend, Cloud Capital projects from the thing that actually drives the cost: how many customers you expect to serve, how much revenue you are forecasting, how fast your user base is growing. Finance already has this data. Connecting it to the forecast means both teams are working from the same assumptions — and Cloud Capital has the signal it needs to size commitments against your real future.3. Projection Types — your methodology per layer
Every Cost Layer has a projection type that controls how its future spend is calculated. The four options — Trend, Fixed Percentage, Flat, and Metric-Auto — are not one-size-fits-all. Production workloads tied to customer growth should use Metric-Auto. Fixed infrastructure with no expected change should use Flat. A planned expansion at a known rate should use Fixed Percentage. Choosing the right methodology per layer is where the forecast moves from plausible to precise. A single projection applied to everything is better than nothing — but it will always be wrong for most layers.4. Engineering Initiatives — your planned changes
Engineering Initiatives capture the changes your engineering team already knows are coming: service migrations, product deprecations, new deployments, right-sizing projects. These have real cost implications that a pure extrapolation of past spend will miss entirely — and they are precisely the information AWS-native tools have no access to. Initiatives let engineering teams quantify their plans in financial terms, and let finance teams see those plans before they hit the bill. A permanent reduction modelled as an Initiative becomes a saving in the forecast — not a surprise in retrospect. It also becomes an input to the GSR calculation, allowing Cloud Capital to size commitments with confidence that accounts for what is about to change.Who does what
A good forecast is a collaboration. The two teams that need to be in sync are Finance and Engineering — and the forecast is the shared artefact that keeps them that way. Finance defines the structure. Cost Layers should reflect how finance thinks about cloud spend — which costs are COGS, which are OpEx, which product lines or business units matter for reporting. Business Metrics come from finance: the growth assumptions and operating plans that are already being used for budgeting. Engineering populates the detail. Resource mapping assigns actual AWS spend to the Cost Layer structure finance has defined. Engineering Initiatives capture forward-looking changes that only the engineering team knows about. Without this input, the forecast is accurate for the past and blind to the future. Cloud Capital optimises from the result — and facilitates the conversation. The commitment proposals, GSR calculations, and savings analyses Cloud Capital produces are all downstream of the forecast. But Cloud Capital’s role is not just to run the numbers. The application itself — and the weekly, monthly, and quarterly reviews with your Cloud Capital team — are the mechanism through which Finance and Engineering inputs are brought together, kept current, and acted on. Those reviews are not just reporting sessions; they are the cadence that keeps the forecast alive and the savings compounding. When the forecast is complete and current, Cloud Capital can propose the right commitments, at the right size, at the right time, and stand fully behind the savings rate it guarantees.The Guaranteed Savings Rate Cloud Capital offers is calculated from your forecast. The more accurately your forecast reflects your real business trajectory — through solid Cost Layer structure, connected business metrics, and up-to-date engineering initiatives — the more precisely that rate can be calculated and the more fully Cloud Capital can stand behind it. Keeping your forecast current is the single most impactful thing you can do to maximise your savings.
Where to start
Cost Layers
Map your cloud spend to your business structure. The foundation everything else is built on.
Business Metrics
Connect your growth data to your forecast so costs move with your business plan.
Projection Types
Choose the right forecasting methodology for each Cost Layer.
Engineering Initiatives
Model planned infrastructure changes before they hit the bill.