been working in this space too and your design constraints are solid. the JSON-only approach is the right call, parsing HCL directly introduces so many edge cases (modules, dynamic blocks, provider aliasing) that you trade away the determinism you're optimizing for. terraform's JSON output is already the normalized representation of what will actually run.

one thing i ended up doing differently: i built this as a github app that pulls live pricing from the AWS API instead of embedding it. means the estimates stay current without releases, but you lose the offline guarantee.

when i initially built it i started out with AWS CDK first since there wasn't really tooling for cost estimation there and i develop infra mainly with cdk, then added terraform support once the architecture was in place, turned out to be relatively straightforward once you have the pricing lookup layer abstracted.

i also came to the same conclusion on usage-driven costs btw—right now i only do baseline infra cost, not traffic or autoscaling. one idea i'm mulling over: let users drop a config file with approximate usage patterns and use that for estimates. not perfect but better than nothing for things like lambda invocations or data transfer. wrote up some of my learnings and the trade-offs here:

https://cloudburn.io/blog/cloudburn-lessons-learned