Notification is a common requirement in cloud infrastructure management, having robust tools at your disposal is crucial. One such powerful tool is c7n-mailer, a versatile solution for handling notifications and alerts.
As part of the Cloud Custodian ecosystem, the Mailer module focuses on efficient communication and reporting for cloud resource policies and events. It takes in messages from a message queue, transforms them using Jinja templates, and then delivers them to various destinations according to configuraton of the message. It supports email, Slack, DataDog, SendGrid, and other communication channels. The adoption of Jira as a destination is still pending; please refer to PR cloud-custodian/cloud-custodian#8695.
Here's a simple YAML configuration snippet to give you an idea:
queue_url: https://sqs.us-ease-1.amazonaws.com/123456789012/notification-queue
from_address: [email protected]
slack_token: <token that encrypted with a KMS key>
lambda_name: cloud-custodian-mailer
role: arn:aws:iam::123456789012:role/CloudCustodianMailer
region: us-ease-1
lambda_schedule: rate(5 minutes)source: tools/mailer/cloud-dev.yml
Now, let's address some common questions that often arise when working with c7n-mailer.
1. Why not use SQS push mode for prompt message delivery?
This is a valid inquiry, and the answer lies in the trade-offs. While SQS push mode delivers messages promptly, c7n-mailer operates in pull mode by default. The rationale behind this decision is rooted in the fact that notifications generated by c7n-mailer are typically intended for human intervention. In scenarios where immediate action is not imperative, the slight delay introduced by pull mode (a matter of minutes) is inconsequential.
Additionally, pull mode offers performance benefits and is development-friendly. Resources such as Jira connections and KMS decryption within the mailer can be efficiently reused without constant re-initialization. This approach proves advantageous in scenarios where the mailer needs to handle a large number of notifications. When developing policies with notifications, we often need to run the mailer locally to check if the notifications are correct. While push mode may not work, pull mode can be employed.
Once more, it's important to emphasize that we are not tethered to an architecture conceived five years ago. While the push mode with batch processing holds potential as a potentially superior option, the current default configuration is performing admirably. At present, the benefits gained from customization do not outweigh the effectiveness of the existing setup.
2. Why not use Secret Manager instead of encrypting with a KMS key?
I agree using Secret Manager could be a smarter move. That way, I skip the hassle of making a KMS key and dealing with another tool to encrypt the secret, like tools/kms_encrypt.py.
In conclusion, while c7n-mailer may adhere to certain architectural decisions made in the past, it remains a robust and adaptable tool for managing cloud notifications. The key lies in understanding the rationale behind these decisions and weighing them against your specific use case.