Forecasting on AWS

I estimated 25 seconds. I measured 39.17.

Work
Distributed forecasting on Step Functions
Role
Architecture and build
Period
2025
  • AWS
  • Step Functions
  • CDK
  • Time series

The brief

The forecasting job ran serially and took 52 minutes against a platform ceiling of 15. It had to be split without losing traceability or blowing up the observability bill. I designed the state machine, deployed it with CDK, and measured every decision before leaving it in.

How it is built

The serial version took 52 minutes against a platform ceiling of 15, so I split it with a Map state over Step Functions, 6 Lambdas, S3 and DynamoDB, deployed with CDK. I set max_concurrency=8 because the account quota was 10, not because 8 was optimal.

I tried gradient boosting expecting it to win. AR(1) won. For metrics I chose DynamoDB over CloudWatch because at that cardinality CloudWatch cost 44 USD a month.

One caveat

My estimate was off by 57%. I leave it written down because the gap between estimating and measuring is the work.

Measured, source unpublished: Step Functions execution trace52 → 15minutesSerial against the platform ceiling
Measured, source unpublished: CloudWatch logs around the change1.78 mssnapshotOutside the handler. Inside: 707.5 ms
Unverified: validation notebook0.1476AR(1)Expanding walk-forward. Boosting: 0.1711

Where it breaks

Measured, source unpublished: the state size calculation

It breaks at 510 products

Where and why

514 bytes per Map element against the 256 KB Step Functions state ceiling. Past that number the Map has to be paginated or the payload moved to S3.