🚨 Still jumping between accounts for alerts? Fixed.

The Case for Centralized Alerting

If you use AWS, you use CloudWatch to some extent. Having it as a powerful monitoring tool is nice. As your organization grows, organizing alerts, logs, and metrics becomes harder.

You should have a global way of handling your alerts. It doesn't make sense that all of your developers need to think about where your alerts should arrive. You will end up with a mess of:

• Custom Apps in your IM messengers (Slack, Teams, etc.)
• Webhook Implementations
• Email Alerts

Platform teams should make it as simple as possible for developers to be able to create alerts. These alerts should be handled automatically and arrive at some common point where you can handle them. This is often an instant messaging service like Slack. Or it could also be a ticketing system such as Jira.

In this post, we will show you how to create such an architecture in a multi-account setup in AWS.

Architecture Overview

The architecture consists fully of serverless services.

We have three different sets of accounts:

1. Management Account
2. Member Accounts
3. Observability Account

All of these accounts are in an AWS Organization. This organization has different organizational units (OU).

For instance, we could have the following OUs:

• Production
• Development

The observability account could live in its own OU or directly in the root.

Typically, two app accounts exist. One in production and one in development.

...

🚀 Read the Full Tutorial →