v0.1.0 - Initial Release

This aws-cloudwatch-alarm-handler:v0.1.0 release is the initial version of this lambda. It takes a "CloudWatch alarm state change" event from an Amazon SNS topic, parses the Message field, validates the schema, generates a human-friendly notification for the alarm formatted in primitive markdown, and publishes the human-friendly string to a second SNS topic. The purpose of using markdown instead of HTML is because SNS subscribers receive unformatted text messages and emails, and markdown is more readable than HTML with no formatting.

If there is a runtime error, this lambda attempts to deliver a human-friendly notification to a third SNS topic. The purpose of this is to enable the bot maintainer to receive notifications on runtime errors that are separate from customer-facing notifications.

This is still a point release because I have yet to write test suites.

Architecture

The general idea in the nominal case is this:

CloudWatch => EventBridge => SNS topic 1 => CloudWatch formatting lambda (aws-cloudwatch-alarm-handler) => SNS topic 2 =>
Telegram notification lambda (telegram-bot), SMS, email, etc.

On a runtime error:

CloudWatch => EventBridge => SNS topic 1 => CloudWatch formatting lambda (aws-cloudwatch-alarm-handler) => SNS topic 3 =>
Telegram notification lambda (telegram-bot), SMS, email, etc.

Be sure not to create loops in your architecture. For example, it would have been awesome to deliver runtime errors in telegram-bot to SNS topic 3, but if SNS topic 3 uses telegram-bot to notify the bot maintainer, that creates the potential for an infinite loop.