Cost Estimation Tools

[eladb]

Some ideas around cost estimation:

1. Calculate fixed cost based on a CloudFormation template (aws cloudformation estimate-template-cost)
2. Auto-tag all resources in a construct/stack and use the pricing APIs to track variable cost as well, so users can add constructs that alarm if costs has gone too high or even auto-destroy?)

[ccfife]

perhaps a "what-if" switch in the CDK CLI that estimates the cost of the stack?

[pfeilbr]

I feel like this is the last concern/barrier to entry to address with CDK. You've demonstrated, provisioning, efficiency, and observability. The last "big"/"unknown" concern always lurking is cost. Do a best estimate default, but then allow a parameterized estimate based on traffic, rps, etc. I know ... easier said than done. The team has essentially uncovered all the unknowns in the other spaces, but cost to run could use some love :)

E.g. request to API Gateway endpoint, trace service usage (x-ray) (relevant CloudWatch metrics, etc.), understand cost of it, extrapolate to an estimate. This cost estimator is part of the deployed stack, always runs, and provides better cost estimates with time (aws [sagemaker|forecast] it based on usage data). As noted, pricing APIs include "forecasted" cost estimation based on usage. Use the same filtered by stack tags to constrain the estimates.

As a first step and convenience deploy option, you could just generate the billing report as part of the stack.

[vaneek]

IIRC there where some tools elsewhere in the AWS ecosystem to estimate costs based on cfn templates. I haven’t explored them lately and at the time thought they where deficient and not very usable in an everything-as-code setting.

My opinion is that the cost estimation should not be part of a framework or sdk but rather a service with a standard API. A framework such as CDK could then provide some CLI options or tools to call the service.

For example call an api and pass a cfn template and get back an estimate or budget report.

[gabrielenosso]

Just wanted to mention that in the https://github.com/aws/aws-cdk-rfcs there are 2 proposal for a Cost Estimation Tool / Cost Calculator.

Numbers 70 (this one) and 22.

[master-harvey]

We can tag all taggable resources in a stack using the tags prop in the Stack object constructor. You can then go to Cost Explorer in the console and filter by tag to track actual usage costs.

I haven't tried this yet but it looks like the CloudFormation CLI already has a way to get an estimate ahead of time: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/estimate-template-cost.html

[spoco2]

We're using CDK, we have a number of stacks we deploy, we're at early stages of our start up and only have testing data loads through the system so far.

Manually trying to work out the cost of this system as we scale load is hugely difficult and massively time consuming due to the multitude of ways that each part of the system has different cost models applied by AWS, and different pricing breakpoints based on usage volumes.

So, being able to point a tool at a CDK stack (or collection of stacks more realistically) and then have access to sliders/inputs to alter the volume through the system/time used etc. and get projected costs out would be massively useful.

5 years on since this was opened and other issues rolled into it, and still no viable tool is very disappointing.

"Go and use Cost Explorer in the console, it has forecasting" is a useless thing that gets said a lot around the traps, as that assumes you already have a system that has had production loads running against it, and then all it'll do is assume some growth against that.

Gives no ability to change volumes, usage, anything.

This all makes it very hard to estimate the cost of AWS expenditure for startups.

[ahammond]

We are looking for a way to put an estimated cost delta into our PRs. My take on this is that it might possibly be part of Cfn, but is almost certainly not part of CDK. If it's not part of Cfn, then it's probably some external integration which would be managed for PRs by projen.

[awsmjs]

Closing this ticket. We don't have the bandwidth to collaborate on design or implementation. We suggest experimentation for this feature first via a separate package or a fork if needed. If a successful implementation emerges, reopen the proposal with details on the functionality and how it can be implemented in the core library.

[ahammond]

Fair enough. Can you suggest who we should be talking to about this?