🚨 Still jumping between accounts for alerts? Fixed.

AWS FOR THE REAL WORLD

⏱️

Reading time: 6 minutes

🎯

Main Learning: Build a central alerting approach with CloudWatch, Lambda, EventBridge, and CDK across your AWS Organization.

📝

Blog Post

💻

GitHub Repository

🎬

Watch on YouTube

Hey Reader 👋🏽

Welcome to the first issue after re:Invent.

For everybody who was out there, I hope you came home safe & healthy. I heard re:Invent cold is a thing like Oktoberfest cold in Munich 🍻

📰 This Week in AWS

⏸️AWS Lambda Durable Functions

Lambda launched Durable Functions! We're pretty hyped on them. We love Step Functions (especially the visual part). But ASL (the language you write SFNs in) can actually be quite a burden. Doing it all in your favorite programming language is great!

💰Database Savings Plans

FINALLY, we've got some database saving plans. We'll have a dedicated post on them soon!

🖥️Lambda Managed Instances

Ever needed your Lambda function with some specific compute requirements? Now you can set them up with Lambda Managed Instances.

We'll have dedicated launch newsletters and posts on them as well!

In this week's deep dive, we'll talk about CloudWatch Central Alerting. I (Sandro) just built something similar for a client and published a YouTube video + an example CDK implementation!

Now let's learn something and build centralized alerting in this week's deep dive 🤓

📚 This Week's Deep Dive

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:

Management Account
Member Accounts
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 →

Summary

That's it for this week's newsletter!

Tobi & I are traveling to Berlin this week for a client's AWS workshop and some co-working. I'm sure we'll grab a mulled wine at a Christmas market 🍷 (if you're in Berlin, hit us up!)

Have a great pre-Christmas/post-re:Invent time – and talk to you soon ❄️

AWS for the Real World