diff --git a/content/posts/cloudwatch-metric-filters.md b/content/posts/cloudwatch-metric-filters.md
new file mode 100644
index 0000000..a107cf0
--- /dev/null
+++ b/content/posts/cloudwatch-metric-filters.md
@@ -0,0 +1,54 @@
++++
+title = "Structed and passively collected metrics via AWS CloudWatch"
+date = "2022-11-12"
++++
+
+AWS is a vast and sprawling set of services. It can be hard to find the hidden
+gems like this one so I wanted to point this one out.
+
+Structured metrics are very helpful to monitoring the health and function of an
+software system.
+
+- Do you want to know how long a particular transaction typically takes?
+- How fast your database queries are?
+- How long external APIs take to respond?
+- Fire an alert when a particular function on the site happens too many times? Or too few times?
+
+...plus a million other things specific to whatever system you're working on.
+
+There are a lot of great tools for doing this and one that you might not know
+about is AWS CloudWatch Metric Filters. If you're already on AWS then you
+should consider these because it requires only that your application logs to CloudWatch.
+
+If you're on ECS then the
+[awslogs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html)
+log driver for Docker gets you that nearly for free. By "free" I mean that your
+application itself can have *zero* dependencies on AWS services and not require
+any AWS credentials or libraries to start pumping out metrics that you can
+visualize, alert on and record over time.
+
+The [AWS
+docs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+themselves offer the canonical reference for configuring these so I won't go
+into detail here.
+
+However, the gist is that for a log filter you define the following properties
+
+- A filter pattern for extracting a discrete metric value out of a log entry
+- A metric name to store the value in
+- An optional dimension for sub-classifying the value
+- And finally a log group to extract the metric values from
+
+After that you just run the application and as the logs roll in the metric
+values get pumped out. Then you can [define alarms for
+alerting](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)
+on them, [graph
+them](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html),
+[define autoscaling
+rules](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html#policy-creating-alarm-console)
+from them and more.
+
+To conclude - AWS is big and hairy. While there are benefits to staying
+platform agnostic, some AWS services don't require much or any coupling of your
+application code to take advantage of. Cloudwatch Metrics is one of those
+services and you can get a lot of value out of it with not much effort.