We’re assuming you already know that Forecast predicts future values from historical time-series data. Here we go past that into the concepts that determine forecast quality and how a deployment actually behaves.

Three dataset types, not one

Forecast doesn’t work off a single flat table — it organizes input data into up to three distinct dataset types inside a Dataset Group. The target time series is the thing you’re actually trying to predict (daily units sold per store, for example) and is the only mandatory dataset. The related time series holds additional time-varying signals that might influence the target but aren’t themselves being forecast — price, promotion flags, weather, or web traffic — and critically, related time series values must be known (or forecastable) for the future dates you want predictions for, not just historically. The item metadata dataset holds static, non-time-varying attributes about each item — product category, brand, store region — that help the model generalize patterns across similar items, which matters enormously for items with sparse or short sales histories.

Quantile forecasts: P10, P50, P90

Forecast does not return a single predicted number for a future date — it returns a probabilistic forecast expressed as quantiles, most commonly P10, P50, and P90 (configurable). A P90 value of 500 units means the model estimates a 90% chance actual demand will be at or below 500 units; P50 is the median estimate; P10 represents a conservative low-end estimate. This isn’t a quirk of the API — it reflects that real-world demand is inherently uncertain, and different business decisions should use different quantiles: a retailer avoiding stockouts might plan inventory against P90, while a cost-conscious operation minimizing overstock might lean toward P50 or even P30.

You may likeAmazon RDS→

Predictors and AutoPredictor

A predictor is a trained forecasting model built from your dataset group. Historically, Forecast offered a menu of specific algorithms — DeepAR+ (a recurrent neural network approach good at learning across many related series), Prophet (a decomposable trend/seasonality model originally from Meta), ARIMA, ETS, NPTS, and CNN-QR — that you could select manually. AutoPredictor, Forecast’s newer and now-recommended training mode, instead automatically evaluates multiple algorithms against your specific data, selects (or ensembles) the best performer, and handles hyperparameter tuning without requiring you to understand the trade-offs between each algorithm yourself. AutoPredictor also adds capabilities the legacy algorithm-specific path didn’t have, including explainability reports and simplified retraining.

Forecast horizon and backtesting

The forecast horizon is how far into the future you’re asking Forecast to predict, expressed as a number of time steps at your data’s granularity (30 days, 12 weeks, and so on) — and accuracy reliably degrades as horizon length grows, since near-term predictions have less uncertainty to compound than far-future ones. Forecast evaluates the predictor’s quality using backtesting: it holds out the most recent portion of your historical data, trains as if that period hadn’t happened yet, generates predictions for it, and compares those predictions against the actual known values — producing accuracy metrics like weighted quantile loss (wQL) and root mean squared error (RMSE) without requiring you to wait for real future data to arrive before knowing whether the model is any good.

What-if analysis

Beyond generating a baseline forecast, Forecast supports what-if analysis — letting you modify a related time series value (raise a product’s price by 10%, remove a planned promotion) and see how the forecast would change, without retraining the underlying predictor. This is what turns Forecast from a passive prediction tool into something planners can use interactively to evaluate the demand impact of decisions they haven’t made yet.

Intermittent demand and cold-start items

Not every item has a smooth, continuous sales history. Intermittent demand — items that sell in occasional bursts with long stretches of zero sales in between, common for spare parts or slow-moving SKUs — breaks the assumptions of many classical statistical forecasting methods, which tend to either over-smooth the bursts away or over-react to noise. Forecast’s algorithm choices (particularly NPTS, designed specifically for sparse and intermittent data) and AutoPredictor’s automatic evaluation exist partly to handle this case without requiring the analyst to manually recognize intermittency and pick a specialized method themselves. A related situation is the cold-start problem — a genuinely new item with little or no sales history at all — which item metadata addresses by letting the model infer likely demand behavior from similar existing items rather than having nothing to learn from.

Explainability reports

AutoPredictor can generate an explainability report that attributes how much each input feature (a specific related time series, or an item metadata attribute) contributed to the forecast for a given item, expressed as relative impact scores. This matters for two practical reasons: it helps a data science team validate that the model is picking up genuinely meaningful signals rather than spurious correlations, and it gives business stakeholders a defensible answer to “why did the forecast go up this month” beyond “the model said so.”

Time zones, calendars, and holiday effects

Forecast accepts a configurable time zone and can incorporate holiday information covering many countries, which matters because holiday effects (a spike before a major shopping holiday, a dip on a public holiday itself) are often the single largest source of forecast error if left unmodeled. Rather than requiring every business to manually encode holiday dates as a related time series feature, Forecast can incorporate a selected country’s holiday calendar directly into training, letting the model learn holiday-specific demand shifts as a distinct, recognized pattern rather than lumping them in as unexplained noise around otherwise normal days.

Forecast’s pipeline runs as a sequence of managed stages, each producing an artifact the next stage consumes.

graph TD
    S3["S3: Target TS / Related TS / Item Metadata (CSV)"] --> DSG["Dataset Group"]
    DSG --> IMPORT["Dataset Import Job"]
    IMPORT --> TRAIN["Predictor Training
(AutoPredictor or algorithm-specific)"]
    TRAIN --> BT["Backtesting & Accuracy Metrics
(wQL, RMSE, MAPE)"]
    TRAIN --> EXPLAIN["Explainability Report"]
    BT --> FORECAST["Forecast Generation Job"]
    FORECAST --> QUERY["Query Forecast API
(per-item, per-quantile results)"]
    FORECAST --> EXPORT["Export to S3
(bulk CSV/Parquet)"]
    TRAIN --> WHATIF["What-If Analysis
(modify related TS, re-simulate)"]
        

It’s worth being explicit about the boundary between Forecast’s managed pipeline and the systems around it: Forecast does not ingest data directly from a transactional database or a point-of-sale system on its own. Every dataset import starts from files staged in Amazon S3 in a specific schema, which means an upstream extraction and formatting step — typically an AWS Glue job, a Lambda function, or a broader ETL pipeline — is a mandatory part of any production architecture, not an optional convenience layer.

Multiple dataset groups can coexist within a single AWS account, each representing an entirely independent forecasting problem — one for retail SKU demand, another for call-center staffing, a third for energy load — with no shared state or interaction between them beyond sharing the same account and billing. This isolation is useful architecturally because it means a schema change or retraining schedule for one forecasting domain never risks affecting another, but it also means there’s no built-in mechanism for one dataset group’s model to inform another’s, even if a genuine cross-domain relationship exists (energy load affecting a retailer’s climate-control equipment demand, for instance) — any such relationship must be modeled explicitly by including the relevant signal as a related time series within a single dataset group, not assumed to be picked up automatically across separate ones.

You may likeAmazon Timestream→

What actually happens between submitting historical data and receiving a set of future predictions?

When AutoPredictor training starts, Forecast first profiles the input data — checking granularity, the number of distinct items, history length, and how much missing data or intermittency (long stretches of zero demand) exists — and uses this profile to decide which candidate algorithms are even worth trying. Global algorithms like DeepAR+ and CNN-QR learn shared patterns across every item’s time series simultaneously, which tends to work well when you have many related items and at least a moderate amount of history per item, since the model can borrow statistical strength across items. Local algorithms like ETS and ARIMA fit a separate model per individual time series and tend to do well when items behave quite differently from one another and there’s ample history for each one individually. AutoPredictor trains several of these candidates internally, evaluates each via backtesting, and either selects the single best performer or blends multiple models into an ensemble weighted by their backtested accuracy.

Quantile forecasts are produced internally through a loss function specifically designed for probabilistic prediction (weighted quantile loss) rather than the ordinary mean-squared-error loss used for single-point regression — this is a structurally different training objective, which is part of why Forecast can’t simply be swapped out for a generic regression model and expect equivalent quantile behavior. During forecast generation, the trained model produces a distribution of plausible future values for each item and time step, from which the requested quantiles (P10/P50/P90 or custom values) are extracted.

Seasonality detection happens largely automatically within AutoPredictor’s candidate algorithms rather than requiring an analyst to manually specify a seasonal period up front. Algorithms like ETS and Prophet explicitly decompose a series into trend, seasonal, and residual components, while neural approaches like DeepAR+ and CNN-QR learn seasonal patterns implicitly through their training process across many series. This matters practically because it means multiple overlapping seasonal patterns — a weekly pattern nested inside an annual one, for instance, common in retail sales around holidays — can be captured without an analyst manually engineering seasonal indicator features the way an older, fully manual statistical forecasting workflow would have required.

Data in Forecast moves through a clear, versioned pipeline from raw CSV files to a queryable forecast.

sequenceDiagram
    participant S3 as Amazon S3
    participant DS as Dataset
    participant Pred as Predictor
    participant FC as Forecast
    participant App as Downstream App

    S3->>DS: CreateDatasetImportJob
    DS->>DS: Validate schema, timestamps, item IDs
    DS->>Pred: CreateAutoPredictor
    Pred->>Pred: Train candidates + backtest
    Pred-->>DS: Accuracy metrics + explainability
    Pred->>FC: CreateForecast (generation job)
    FC-->>App: QueryForecast (per item) or S3 export (bulk)
        

Three lifecycle stages are worth calling out specifically because they’re where most production issues concentrate:

It’s worth being explicit that retraining is not automatic: as new actual sales data accumulates, the underlying reality of demand drifts, but Forecast does not silently retrain a predictor in the background. Production deployments schedule periodic retraining (weekly or monthly, depending on how quickly the business’s demand patterns change) as a deliberate pipeline step, not a one-time setup activity.

Dataset import jobs are additive versions, not in-place overwrites, which has an important practical consequence: each import job creates a distinct, immutable snapshot of the data at that point in time, and a predictor is always trained against a specific import job’s data, not against “whatever the dataset currently contains.” This versioning gives production pipelines a clean way to reproduce exactly which data produced a given predictor months later — useful both for debugging an unexpected forecast and for satisfying any audit requirement that demands traceability from a business decision back to the data that informed it.

The deprecation trajectory adds a trade-off dimension unique to this particular service that doesn’t apply to most others discussed in comparable AWS reference material: even a technically excellent fit for a given forecasting problem carries platform-risk cost right now that a stable, actively developed service wouldn’t. Teams already running Forecast in production generally face a lower-urgency migration decision than teams evaluating it fresh, but both should factor the announced wind-down into any multi-year planning rather than treating today’s feature set as a permanent foundation.

Forecast’s scaling story is less about raw request throughput and more about how well its algorithms handle growing item counts and data volume.

Training time scales with both the number of distinct items and the length of history per item, and AutoPredictor’s evaluation of multiple candidate algorithms compounds this — training across tens of thousands of SKUs with years of daily history takes meaningfully longer than the same process for a few hundred items with a year of history. Forecast generation (applying an already-trained predictor to produce predictions) is comparatively fast once training is complete, since it doesn’t repeat the algorithm-selection and backtesting work.

Data granularity is a scalability lever worth choosing deliberately rather than defaulting to the finest grain available. Forecasting at hourly granularity across a year of history produces roughly 8,760 data points per item, while daily granularity over the same period produces about 365 — the finer granularity captures more nuance (intraday demand patterns) but multiplies training data volume and time correspondingly. Choosing granularity that matches the actual decision cadence the business needs (a weekly replenishment planning process rarely benefits from hourly forecasts) keeps both training time and downstream consumption manageable.

Item count and cardinality also interact with cost in a way worth planning for explicitly. Forecast pricing has historically been structured around data volume processed for training and the number of forecast data points generated, meaning a business forecasting a very large item catalog at fine granularity and a long horizon can see meaningfully higher costs than one forecasting a smaller catalog at coarser granularity — a consideration that should factor into the granularity and horizon decisions discussed above, not just accuracy alone.

Horizon length and accuracy trade off in a predictable, roughly monotonic way worth setting expectations around before a forecast reaches business stakeholders: predictions for tomorrow are inherently more reliable than predictions for six months from now, simply because more can change in the intervening period than any model, however well trained, could have anticipated at training time. Rather than presenting a long-horizon forecast with the same implied confidence as a short-horizon one, mature forecasting practices widen the effective uncertainty communicated to stakeholders as horizon length grows — which the quantile spread between P10 and P90 naturally does, since that spread typically widens noticeably further out in the horizon even without any explicit manual adjustment.

As a managed AWS service, the underlying training and inference infrastructure’s availability is AWS’s responsibility. Your reliability responsibilities concentrate on two areas instead: ensuring dataset imports consistently succeed on schedule, and ensuring forecasts are regenerated on a cadence that keeps predictions relevant to current reality.

Because retraining and forecast generation are explicit, scheduled jobs rather than continuous processes, reliability engineering here looks more like traditional batch-pipeline reliability (job scheduling, failure alerting, idempotent reruns) than like the always-on service reliability concerns of a synchronous API. A failed dataset import job that goes unnoticed simply means the next scheduled predictor training runs against outdated data — silently, with no obvious error surfaced to end users of the eventual forecast.

A related reliability concern specific to forecasting systems is model degradation detection — recognizing when a previously accurate predictor has quietly stopped reflecting reality, distinct from an outright pipeline failure. Because the symptoms (a widening gap between forecast and actuals) look identical to normal short-term forecast error at first glance, production systems typically need an explicit statistical trigger — for example, actual-versus-forecast error exceeding backtested error by some threshold over several consecutive periods — to reliably distinguish “the model needs retraining” from “this was just an unusually noisy week,” rather than relying on a human noticing the drift by eye.

Disaster recovery planning for a Forecast-dependent pipeline is, in practice, mostly about protecting the upstream data and the pipeline definitions rather than the trained predictor artifact itself, since a predictor can always be retrained from the underlying dataset if the historical data and training configuration are preserved. Teams that treat their S3-staged historical data and infrastructure-as-code training definitions as the actual source of truth — with the trained predictor as a reproducible derived artifact rather than an irreplaceable asset — recover far more gracefully from a regional issue than teams that would need to manually reconstruct months of carefully engineered related time series from scratch.

You may likeAWS KMS→

Security for Forecast centers on protecting the historical business data it trains on and controlling who can trigger training and access predictions.

Data sensitivity in forecasting deserves a specific caveat many teams overlook: even though target and related time series data is usually aggregate business metrics rather than personal data, item metadata occasionally includes attributes (a customer segment, a location tied to individual behavior) that edge closer to personal data depending on how granular the “item” being forecast actually is. Any dataset design that forecasts at an individual-customer level, rather than an aggregate SKU or store level, should be reviewed against the same data protection standards applied to any other system handling personal data, not assumed exempt simply because the output is “just a forecast.”

Audit and traceability requirements are worth designing for from the start in regulated industries. Because each dataset import job is an immutable, versioned snapshot and each predictor references a specific import job’s data, a well-instrumented Forecast deployment can answer “exactly what data produced this specific forecast that informed a specific business decision” months after the fact — a capability that matters in industries like energy or financial services where a regulator or internal auditor may eventually ask for exactly that chain of evidence.

Separation of duties extends naturally from the IAM pattern described above to the broader question of who is accountable for a forecast’s accuracy versus who is accountable for the business decision built on top of it. Because Forecast surfaces explicit accuracy metrics and confidence intervals rather than a single unqualified number, a mature organizational process distinguishes between “the model was reasonably accurate given the uncertainty it reported” and “the business chose to plan against an inappropriately aggressive quantile for that decision’s risk profile” — two very different root causes for the same eventual outcome of a forecast turning out to be wrong, each pointing to a different team’s process needing adjustment rather than automatically indicting the model itself.

You may likeAmazon Keyspaces→

Forecast integrates with AWS CloudTrail for logging management-plane API activity — who created a dataset import job, trained a predictor, or generated a forecast, and when. Training itself surfaces backtest accuracy metrics (wQL at multiple quantiles, RMSE, MAPE) directly as part of the predictor’s metadata, which should be the primary signal reviewed before trusting a newly trained predictor for a real business decision.

Beyond accuracy metrics, monitoring the freshness of both input data imports and generated forecasts — how long since the last successful import, how long since the last forecast generation — is the operational metric most directly tied to whether a business user’s dashboard is showing something still relevant to today’s decisions.

Logging accuracy metrics over successive retraining cycles, rather than only inspecting the most recent predictor’s score in isolation, turns a one-time evaluation into a trend line. A predictor whose backtested wQL steadily worsens across several retraining cycles is signaling something worth investigating — a genuine shift in underlying demand behavior, a data quality issue creeping into upstream extraction, or a related time series that has become less predictive than when it was first added — well before that degradation becomes visible as a business-impacting forecasting failure.

Alerting thresholds for forecasting pipelines benefit from being set relative to a predictor’s own backtested baseline rather than an arbitrary fixed number, since acceptable error varies enormously by domain — a 5% error might be excellent for a stable, high-volume product category and unacceptably loose for a safety-critical energy load forecast. Defining “alert-worthy” as a meaningful deviation from that specific predictor’s own established baseline, rather than a one-size-fits-all percentage, keeps monitoring meaningful across a portfolio of forecasting problems with very different natural volatility.

Forecast deployments are typically orchestrated as a scheduled pipeline rather than triggered ad hoc: a scheduled job (via Amazon EventBridge or AWS Step Functions) pulls fresh sales data into S3, triggers a new dataset import job, retrains the predictor (or reuses an existing one if retraining isn’t due yet), generates a fresh forecast, and either exports results to S3 for consumption by a BI tool like Amazon QuickSight or has downstream applications query results directly via the API.

Given the service’s winding-down status noted earlier, teams building new demand-forecasting capability today should evaluate this deployment pattern against the equivalent approach using Amazon SageMaker’s built-in forecasting algorithms or SageMaker Canvas, which AWS has positioned as Forecast’s forward path — the dataset design and quantile-forecasting concepts described throughout this guide carry over directly, even though the specific managed service changes.

Environment separation follows a similar shape to other managed ML services: a development dataset group and predictor let a data science team iterate on feature selection (which related time series and item metadata actually improve accuracy) without touching whatever predictor is currently serving production forecasts. Once a candidate predictor’s backtested accuracy clears an agreed threshold in development, the same dataset schema and training configuration is replicated against production data — typically via infrastructure-as-code definitions of the dataset group schema, which keeps the two environments structurally identical even though their underlying data differs.

Cost allocation across a portfolio of forecasting problems benefits from the same tagging discipline applied to any other AWS resource — tagging dataset groups and predictors by business unit or forecasting domain lets finance and platform teams attribute training and forecast-generation cost accurately, which matters more for Forecast than for many services because training cost scales directly with item count and history length, meaning cost can grow substantially as a business expands the item catalog or history window without an accompanying review of whether that expansion is actually improving forecast accuracy proportionally.

Change management around related time series deserves special process attention because it’s easy for a signal to quietly lose meaning without anyone noticing. A related time series representing a marketing promotion calendar, for instance, is only as good as the discipline behind keeping that calendar accurate and complete going forward — if the marketing team’s process for recording upcoming promotions changes or lapses, the related time series silently degrades from a genuinely predictive signal into stale or incomplete data, and the forecast’s accuracy degrades along with it without any obvious error appearing anywhere in the pipeline itself. Treating each related time series as an owned data product with its own accountable team, rather than a one-time integration set up once and forgotten, is what keeps this class of accuracy loss from creeping in unnoticed.

You may likeAmazon QLDB→

A pattern worth naming explicitly is hierarchical reconciliation — when forecasts exist at multiple levels of aggregation simultaneously (individual SKU, store, region, company-wide), ensuring the lower-level forecasts sum consistently to the higher-level ones prevents a confusing situation where a regional plan and the sum of its individual store plans disagree with each other. Forecast itself generates predictions at whatever level you train against; achieving reconciled hierarchical consistency typically requires an additional post-processing step, or training separate predictors at each level and applying a standard reconciliation technique (top-down, bottom-up, or a middle-out approach) rather than expecting the service to handle this automatically.

Ensemble weighting deserves a closer look because it’s easy to assume AutoPredictor simply picks one winning algorithm and discards the rest. In practice, when multiple candidate algorithms perform comparably well during backtesting but make different kinds of errors on different subsets of items, AutoPredictor can combine them into a weighted ensemble rather than choosing a single winner outright — capturing complementary strengths (one algorithm handling smooth, high-volume items well, another handling sparse, intermittent items better) that no single algorithm alone would achieve across the full item catalog. This is part of why AutoPredictor’s overall accuracy across a diverse item catalog often exceeds what any individually selected algorithm would produce on its own.

A related pattern worth adopting for teams migrating existing algorithm-specific predictors toward AutoPredictor is running both approaches in parallel against the same dataset for at least one full retraining cycle before fully cutting over. Comparing backtested accuracy side by side gives a concrete, data-driven basis for the migration decision rather than assuming the newer, more automated path is strictly better for every specific forecasting problem — for a narrow catalog of items with long, stable individual histories, a carefully chosen local algorithm occasionally still outperforms an ensemble tuned for broader generalization across a more varied item mix.