AWS Cost Explorer is a genuinely useful tool. We want to say that clearly at the start, because this article is going to spend time on its limitations, and those limitations are real but bounded. If you're running a single AWS account with stable, predictable workloads and modest spend, Cost Explorer's built-in forecasting is probably sufficient. You don't need anything more complex.
The question this article answers is: when does Cost Explorer's forecasting stop being enough, and what specifically breaks down? We've worked through this with enough engineering teams to have a clear answer, and it's not "always use a custom model." It's more nuanced than that.
What AWS Cost Explorer's Forecasting Actually Does
Cost Explorer uses a linear regression model trained on your historical spend. Under the hood, it's fitting a straight-line trend to your last 12 months of billing data and projecting it forward. AWS also applies what they call "machine learning" to account for some seasonality, but in practice the model is conservative and doesn't handle sudden architecture changes or irregular seasonal events well.
The output is a month-end spend projection at the total account or service level. You can filter by service, region, linked account, usage type, and tag, which is genuinely useful for narrowing down where spend is coming from.
What it doesn't do:
- Per-team or per-project cost attribution (unless you have perfect tag coverage, which almost nobody does)
- Multi-cloud aggregation (if you also use GCP or Azure, Cost Explorer has nothing to say about those)
- Event-calendar-aware forecasting (upcoming product launches, planned migration windows, quarterly batch jobs)
- Anomaly alerting connected to the forecast (Cost Explorer Anomaly Detection is a separate product with its own limitations)
- Savings plan and Reserved Instance coverage forecasting as a function of your growth trajectory
The Linear Extrapolation Problem
The core issue with linear extrapolation is that it assumes your future looks like a smooth version of your past. That assumption fails in several common scenarios.
Deployment-driven spend changes. When your team ships a major new feature, cloud costs often step up in a non-linear way. A new caching layer, a new real-time processing pipeline, or an expanded data retention policy can each add a flat baseline cost that linear extrapolation from pre-launch data will systematically miss. The model is looking at the slope of your historical data, not the deployment calendar.
Savings plan renegotiation. If you purchased a Compute Savings Plan last year that covers 60% of your EC2 spend, and that plan is expiring next month, your on-demand costs are about to spike. Cost Explorer does show savings plan expiry, but its forecast doesn't automatically adjust for the expected cost increase when coverage lapses. You have to know to look for it.
Test environment sprawl during product development cycles. Teams often spin up large ephemeral environments during pre-launch periods and tear them down after release. This creates a sawtooth pattern in spend that's neither a trend nor a clean seasonal pattern. A linear model will average through the teeth and give you a forecast that's wrong in both directions depending on where you are in the cycle.
Where Cost Explorer Genuinely Shines
We're not making the case that Cost Explorer is a bad product. Its Rightsizing Recommendations are solid for EC2 and RDS, its tag-based filtering is faster to set up than most custom BI queries, and its integration with AWS Budgets for alerting works well for simple threshold monitoring.
For a team with under $30,000 per month in AWS spend, stable workloads, and no multi-cloud complexity, the native tooling plus AWS Budgets alerts covers most FinOps needs. The ROI on a third-party forecasting platform at that spend level is marginal unless you have specific anomaly detection or attribution requirements.
The tipping points we've observed where teams move beyond native tooling:
- Spend above $80,000-$100,000 per month, where a 10% forecast error represents a meaningful budget planning miss
- Multiple cloud platforms requiring unified attribution (even two cloud accounts adds friction to Cost Explorer's single-platform view)
- Team-level chargeback requirements, where finance needs to see per-team cost breakdowns and existing tag coverage is incomplete
- Irregular event-driven workloads where linear extrapolation is visibly wrong most of the time
What a Custom Forecast Model Adds (and What It Costs)
When we built Finopscraft's forecast engine, we made specific choices about what to add over a linear baseline.
Multi-period seasonality. We use STL decomposition (seasonal and trend decomposition using LOESS) before the ARIMA step, which handles multiple overlapping seasonal patterns: day-of-week effects, month-of-year effects, and event-driven spikes from the calendar layer. This is materially more accurate for teams with any kind of recurring workload variation.
Deployment signal integration. We ingest tag change events from AWS Config and deployment markers from your CI/CD webhook (optional). When we see a new service tagged env:production appear in billing data that wasn't there last week, we flag it as a potential step change in the baseline and ask whether to recalibrate the model from that point forward. This prevents the model from trying to smooth through what is actually a structural break.
Coverage-aware savings recommendations. We track your Savings Plans utilization and compute coverage rate alongside the spend forecast. If your forecast projects 20% growth over the next 3 months, we surface savings plan adjustment options with estimated savings at that projected spend level, not at today's level. This is the kind of forward-looking recommendation that static reporting tools don't do.
The cost of custom forecasting is mostly operational: you need to connect the data sources, tune the model for your workload patterns, and maintain the event calendar. If your team has one person who can spend 2-3 hours per month on FinOps, that's probably enough. If FinOps isn't on anyone's explicit job description, the maintenance overhead will erode the accuracy gains quickly.
The Build vs Buy Question
Some teams ask whether they should build their own forecasting model rather than use a third-party tool. This is worth thinking through carefully.
Building a decent ARIMA model on top of the Cost Explorer API is achievable in a few weeks for an engineer with time-series experience. The harder parts are the surrounding product: the alerting pipeline, the multi-cloud normalization layer, the team attribution logic, the event calendar interface, and the ongoing model retraining schedule. Those take months, not weeks, to get right.
We built Finopscraft because we went through exactly that journey ourselves and concluded that the surrounding product work is where teams consistently underestimate effort. The forecasting algorithm is table stakes. The reason it's useful is the operational layer around it.
Our honest recommendation: start with AWS Cost Explorer plus Budgets. When you hit one of the tipping points listed above, evaluate whether a purpose-built FinOps platform makes more sense than internal tooling. The question isn't "is Cost Explorer good enough in theory" but "how much engineering time are we spending compensating for its gaps."
Comparing Forecast Accuracy: A Practical Test
If you want to run a practical comparison on your own account, the methodology is straightforward. Take your last 12 months of billing data. Hold out the last 3 months as a test set. Train Cost Explorer's model on months 1-9 and compute forecast error on months 10-12. Do the same with whatever alternative model you're evaluating.
The metric to track is mean absolute percentage error (MAPE) at the service level, not just the total account level. A model can be accurate at total account level by having errors that cancel out across services, while being useless for per-service budget planning.
In our internal testing against a set of accounts with varying workload patterns, STL-ARIMA with deployment signals reduces MAPE at the service level by roughly 30-40% compared to linear extrapolation across accounts with any seasonal variation or irregular architecture changes. For flat, stable workloads, the improvement is close to zero and Cost Explorer's built-in model is fine.
That 30-40% improvement on the accounts where it matters is why we built the engine we built. Not because linear extrapolation is broken, but because it has a specific, identifiable failure mode that's worth fixing when your spend is large enough to justify it.