AWS Observability Made Easy: Dive Into Cross-Account Monitoring Today!


  • βŒ› Reading time: 6.3 minutes
  • πŸŽ“ Main Learning: Observability Aggregation with OAM
  • πŸ‘¨πŸ½β€πŸ’» GitHub Code
  • πŸ“ Blog Post

Hey Reader πŸ‘‹πŸ½

Ever tried setting up an AWS Landing Zone? If you have, you know it's not easy. AWS recommends using a separate account just for monitoring all your log data.

We're here to introduce the AWS Observability Access Manager (OAM), designed to make this task easier.

Previously, we couldn't use OAM effectively due to a major limitation, but that's changed.

Interested in diving straight into coding? Visit our repo to deploy your setup using Terraform or CDK.

Why Use Multiple Accounts?

Using several AWS accounts helps to isolate applications, manage finances better, and use resources more efficiently.

A multi-account setup could look like this:

But, it's challenging to oversee operations across these accounts. That's where a dedicated monitoring account comes in, gathering all logs, traces, and metrics in one place.

Aggregating Log Data

Manually aggregating logs across accounts and regions can get complicated. Our own Eduardo Rabelo has an amazing blog post on different strategies for Cross-Account and Cross-Region Log Aggregation.

One common approach is to build a manual solution with Kinesis to ingest all logs. See this architecture:

This can be very error-prone and development-intensive.

OAM offers a simpler solution, allowing you to view all application components in one place, analyzing data across accounts.

What is the Observability Access Manager (OAM)?

The Observability Access Manager (OAM) is a tool and set of APIs built by AWS. It helps you set up a dedicated monitoring account in a multi-account environment.

OAM allows you to monitor all the components of your applications from a centralized view.

It creates cross-account observability to search, analyze, and correlate data stored in CloudWatch.

We want to get observability over data such as:

  • CloudWatch Logs
  • CloudWatch Metrics
  • X-Ray Traces

from multiple accounts into one dedicated Monitoring account. This tool is a managed solution of what we wanted to build in the first step.

Sinks Point to the Monitoring Account and Links Send Application Data

​

OAM uses three main components:

  • Sink: The monitoring account destination.
  • Link: Connects your application's account to the monitoring account.
  • Sink Policy: Allows connections from source accounts to the monitoring account.

We see three AWS accounts in the previous picture:

  1. Source Account A
  2. Source Account B
  3. Monitoring Account

Imagine both your Source accounts are running two different applications, such as a REST API in A and User Authentication in B.

One user request touches the authentication account and creates logs. It also touches the REST API and creates logs. We need to have one central place to correlate the logs. This is possible with a monitoring account.

OAM helps us with that. You can create a single Sink in us-east-1 in the Monitoring account. You create a Link in the AWS accounts running workloads where logs, metrics, traces, and insights are generated.

The Limit That Made Us Not Working with OAM in the Past

Before, OAM had a one-sink-per-account limit, making it difficult to monitor applications across multiple regions.

Imagine having our account structure again like in the following image:

​

In this setup, we have two regions (us-east-1 and ap-southeast-2). But since we could only create one sink per account we can only aggregate all logs from us-east-1.

This doesn't help us when our actual application is scattered across regions, which it often is.

​Steve Weldon (thanks!) found out that it is actually possible to create multiple sinks per account. That means we can achieve the following setup:

​

The official quota still states that only one Sink per account is possible, so we're eagerly awaiting some feedback from AWS:

​

Deploying Your Setup!

We don't come without code 😎

​Eduardo Rabelo built the whole flow in CDK (SST/ION) and Terraform. Check out the GitHub repository for that.

This repository assumes that you use AWS Organizations and know how to handle the trust relationship of the role OrganizationAccountAccessRole.

If you need help with that, please comment or DM us in our Discord server πŸ˜‰

After you have all three accounts, you can supply the account IDs after you hit terraform apply.

Logs from Both Accounts

We've deployed a Lambda function in both source accounts to see it in action. We've executed the Lambda a few times to generate some Logs.

We see both Log Groups from both accounts (OAM-Source and OAM-Source-2). The logs are arriving in near-real-time. The same thing is happening with Metrics:

​

Summary

OAM simplifies setting up cross-account observability, saving you the trouble and cost of manual solutions.

Struggling with CloudWatch? We're working on a CloudWatch Book, aiming for a Q2 release.

Tobi & Sandro

our goal is to simplify AWS & Cloud Learning for everybody. You don't need expensive certifications to build on AWS!

Dr.-Otto-Bâßner-Weg 7a, Ottobrunn, Bavaria 85521 Β· Unsubscribe Β· Preferences​

AWS for the Real World

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

βŒ› Reading time: 14 minutes πŸŽ“ Main Learning: Feature Flags with AWS AppConfig πŸ‘Ύ GitHub Repository ✍️ Read the Full Post Online πŸ”— Hey Reader πŸ‘‹πŸ½ There's no other field where it's so common to have "a small side-project" like in the software industry. Even though it's possible to build things as quickly as ever before due to cloud providers, tools, platforms, and AI, many indie founders (and also large enterprises) tend to fall into the same trap: they tend to build features that users do not...

βŒ› Reading time: 17 minutes πŸŽ“ Main Learning: Observability at Scale with Open-Source πŸ‘Ύ GitHub Repository ✍️ Read the Full Post Online πŸ”— Hey Reader πŸ‘‹πŸ½ Welcome to this edition of the AWS Fundamentals newsletter! In this issue, we're focusing on observability with open-source tools on AWS. As most of you already know, we can use Amazon CloudWatch and X-Ray to monitor our application from every angle. But what if we want to hybrid setup where we run certain parts of our ecosystem outside of AWS?...

βŒ› Reading time: 9 minutes πŸŽ“ Main Learning: Polling or WebSockets: Choosing with Amazon API Gateway πŸ‘Ύ GitHub Repository ✍️ Read the Full Post Online πŸ”— Hey Reader πŸ‘‹πŸ½ What would you use for quick and regular data updates inside your web app? Or let's phrase it another way: how would you choose between Polling and WebSockets? πŸ’­ Understanding the nuances between these two communication methods is important, as they both come with their own advantages, gotchas, and side effects that are not very...