Regional base price selection (Step Functions)

Similarly to #77, we should use the correct regional price of Step Functions based on where the state machine is executed (which might be different from the input function’s region!).

Each state transition costs $0.000025 in almost every region, with some exceptions:

• default: $0.025
• eu-south-1: $0.02625
• us-west-1: $0.0279
• af-south-1: $0.02975
• ap-east-1: $0.0275
• ap-south-1: $0.0285
• ap-northeast-2: $0.0271
• eu-south-1: $0.02625
• eu-west-3: $0.0297
• me-south-1: $0.0275
• sa-east-1: $0.0375
• us-gov-east-1: $0.03
• us-gov-west-1: $0.03

The state machine execution cost is computed here:

module.exports.stepFunctionsCost = (nPower) => +(0.000025 * (6 + nPower)).toFixed(5);

The formula to compute the # of state transitions is: 6 + COUNT(POWERVALUES), therefore the Step Functions cost will be REGIONAL_COST * NUMBER_OF_TRANSITIONS.

[alexcasalboni]

Mmm I think I’d rather count on the SAR versioning to make sure each version is stable and to easily identify bugs or price changes over time (wrt of hoping that everything works correctly during the deployment phase). Also, i don’t think it makes sense to complicate everything with scripts, custom resources, or other tricks to fetch the most updated data on-deploy.

The main reason is that I don’t expect these prices to change every week/month/year. So I think it’s more than enough if we plan to have a daily/weekly crawler that checks if prices have changed and opens a PR here. But definitely not required for this issue, imho.

For now I’d stick to a static file or env variable with the current prices.

[alexcasalboni]

Yes, AWS_REGION should work great.

From the documentation: “The AWS Region where the Lambda function is executed.”

For clarify: its value might be different from the region where the input Lambda function is running, but that’s ok. Lambda Power Tuning works with functions in any region, but you still need to deploy the state machine in a region 😃