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:
That’s true if you’re familiar with programming and know how CloudFormation works. Adding a framework or abstraction layer requires certainly more skills from your end. This article is more suitable for people who want to deploy small projects quickly and don’t want to invest time to learn a framework.
That’s an option for sure! For more complicated projects my preference goes to CDK. But for smaller projects CloudFormation is fine enough, especially if you use the extensions I described in the article.
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