On the request path, an EMF line costs a JSON.stringify and a write to stdout [15]. That really is cheaper than the signed round trip the article is comparing against, which it says adds network hops and milliseconds to every inference [2]. The work changes owner rather than disappearing: the log agent ships the bytes, CloudWatch ingests them, and the extraction happens downstream [3].
The article prices three of the consequences of that move and skips one. It tells you Logs Insights scans the entire log volume at $0.005 per GB [11], that log groups never expire unless you set retention [12], and that 1-second resolution runs about three times the cost of 1-minute [13]. What it does not price is ingesting the extra bytes, which is where per-request line count lands. Take 300 requests per second, inside the article's own "hundreds per second" figure [17]: one line per request is 25.92 million lines a day [20]. Scanning a terabyte of that in Insights is $5.12 per query [21], and you will run more than one, because logs are where you go when a metric looks wrong.
Now read the example block against the spec printed above it. The CloudWatchMetrics array declares a single MetricName, InferenceLatency [6]. The prose immediately below calls InferenceLatency, TokenCount and Success the measurements [7]. Extraction follows the declaration, so as printed you get one metric and two ordinary log fields, and Success is a boolean rather than a number in any case [22]. Copy the block expecting three series and you get one, with nothing raised to tell you why [8]. The author's mitigation for that class of error is a unit test on the JSON, which is the correct instinct applied to a very quiet failure [9].
The final section attributes diagnostics_channel to Node.js 22 and imports createChannel from it [18][19]. Check both against the exports in your own runtime before you make the formatter depend on them; the excerpt stops mid-file [19]. The pattern holds regardless, because the reason to broadcast on a channel is to keep the formatter out of the inference call.
In my context I would take EMF for the standing series that the source enumerates per request, latency, token count and error, and keep PutMetricData for the handful of numbers that must exist when the log pipeline is the thing that broke [17]. For the "zero overhead" claim to transfer to your service, three things have to be true: you were already emitting one structured line per request, you set a retention policy instead of accepting the default [12], and you stop querying Insights for numbers you have already extracted [11]. Add a log line purely to carry a metric and you have moved the charge from the metrics line item to the logs line item, which is often worth doing and is not the same as removing it [16].
