1

Is it possible to access the date of the metric from a math expression in a custom CloudWatch graph, to be used in a IF(...) condition?

Background: I've made a custom CloudWatch graph showing the cost of a lambda, by calculating it from two standard metrics for invocations and duration. The expression uses the pricing formula published by AWS, such as duration/1000*0.0000166667*0.50 + invocations*0.000002, to give the cost in $ per the summed duration and invocations over a period.

However, this formula depends on the memory allocated to the function, which in this example is 512 MB ("0.50" factor in the expression). On a given date, some functions were reconfigured to get more RAM, and I want to reflect this in the graphs by doing something like (if date > 2021-11-27 then 1.0 else 0.5) to get the multiplying factor for the cost calculation. Is this possible?

JHH
  • 8,567
  • 8
  • 47
  • 91

1 Answers1

1

Sure - check our the metric math docs. You can use EPOCH, which is the unix timestamp in seconds. There are also YEAR, MONTH, DATE, DAY, HOUR, MINUTE, but they're not that useful in this case.

duration/1000*0.0000166667 * IF(EPOCH(duration)>1637971200, 1.0, 0.5) + invocations*0.000002

1637971200 is the unix timestamp for 2021-11-27.

gshpychka
  • 8,523
  • 1
  • 11
  • 31
  • 1
    Thanks, didn't find EPOCH. However, this produces the following error: `Error in expression cost [Unsupported operand type(s) for >: '[Function, Scalar]']` – JHH Nov 30 '21 at 16:38
  • Oof, that was an error on my part. You have to pass a metric to the function, edited the answer. – gshpychka Nov 30 '21 at 16:40
  • 1
    Worked like a charm, thanks. And silly me for not finding that error (and for missing this to begin with, for some reason I find the CW graph spec a bit hard to follow). – JHH Dec 01 '21 at 07:59
  • FWIW, I ended up creating separate metrics like this: `foo_dur` (sum of duration over period) `foo_inv`(sum of invocations over period) `foo_ram: IF(EPOCH(foo_dur) > 1637921266, 1.0, 0.5)` `foo_cost: foo_dur/1000*0.0000166667 * foo_ram + foo_inv*0.000002` It would be kind of nice if there were built-in cost metrics from the start, as this approach depends on up-to-date pricing info as well as region, but it works... – JHH Dec 01 '21 at 08:02
  • 1
    If this is something you expect to rely on in the long-term, I would start writing metrics that contain the price and RAM, so you would always have the needed historical data. – gshpychka Dec 01 '21 at 09:36