Hello everyone,

In this article, I will guide you through how to receive notifications for operations or events occurring across various AWS services, such as the creation, deletion, or modification of resources like RDS, EC2, S3, ECR, ECS, etc. I’ll also cover how to reduce associated costs and improve manageability throughout the process. Or, for example, you can receive notifications when the security groups you created are modified and all security groups are changed to 0.0.0.0/0.

AWS services referenced in this guide:

  1. Amazon EventBridge
  2. AWS Organizations (Optional)
  3. AWS Cloudtrail
  4. Amazon SNS
  5. AWS Lambda
  6. AWS CloudFormation (Optional)

At its simplest, we’ll capture the logs sent to CloudTrail by defining a specific Rule within an EventBridge Bus.

If you want to act on an event that occurs in the same account, you can route those logs directly to the AWS service that should handle them.

When the goal is to gather events in a central account, such as an organization’s management account or a dedicated security hub, and then trigger actions, you can forward them across accounts to the appropriate EventBridge Bus.

In this guide, we’ll look at two common scenarios:

  1. Collecting and processing actions that happen within a single AWS account.
  2. Collecting and processing actions from all accounts linked to an AWS Organization.

Before starting on to the explanation, I will also share information about the services we will use. You will understand why I am explaining these services and their details. BUT if you already know these, click here for the steps! 🙂

1. AWS EventBridge:

Amazon EventBridge is a fully managed, serverless event bus that lets different AWS services and applications communicate through events. For example, when someone uploads a file to S3, updates a database, or signs in through the console, EventBridge can capture that activity and route it to the appropriate destination such as a Lambda function, an SQS queue, or a Step Functions workflow.

EventBridge is built around four key elements:

  • Event – Any change or operation in a system (e.g., “A file was added to S3”).
  • Event Bus – A logical channel that receives events and applies rules.
  • Rule – Defines which events to look for and which targets should respond.
  • Target – The AWS service or application that acts on the event (for example, Lambda, SQS, or SNS).

a. EventBridge Rules

Rules filter incoming events and forward only the ones that match specific criteria to their targets. This makes it possible to automate workflows and respond only to the events that matter.

b. EventBridge Buses

An Event Bus is the channel that carries events. There are three types:

  • Default bus – Collects events from AWS services in your account.
  • Custom bus – Created for events generated by your own applications.
  • Partner bus – Handles events coming from supported SaaS providers.

In the following sections, we’ll decide whether to use a custom or the default bus based on the requirements of our setup.

2. AWS Organizations:

AWS Organizations makes it easy to manage multiple AWS accounts from a single place.

With it, you can:

  • Create new AWS accounts and organize them into Organizational Units (OUs).
  • Simplify billing by combining charges across all accounts with Consolidated Billing.
  • Apply organization-wide rules through Service Control Policies (SCPs), which can restrict or allow actions beyond the permissions defined in individual accounts.

Service Control Policies (SCPs) act as guardrails for your organization. They specify which services and actions are available to certain accounts or OUs. SCPs are evaluated alongside, but separate from, IAM policies: even if an IAM policy grants access, the request won’t succeed unless the SCP also allows it. In effect, SCPs serve as a top-level filter, defining the absolute boundaries of what’s possible inside your AWS Organization.

3. AWS Cloudtrail:

In AWS, most actions you perform are automatically recorded by CloudTrail, which keeps API activity logs for 90 days by default. Every action you take -whether through the SDK, CDK, CLI, or the Management Console- is captured there. In short, CloudTrail is the service that collects and displays timestamped API logs across AWS, supporting auditing and governance requirements. It’s also compliant with PCI/DSS standards.

CloudTrail groups events into four main types:

  • Network activity events
    Record network operations performed on resources via VPC endpoints, providing insight into resource activity at the network layer.
  • Management events
    Track administrative operations on AWS resources, such as creating users or roles, updating security groups, or attaching IAM policies.
  • Data events
    Log interactions within or on top of a resource for example, reading or writing an S3 object or invoking a Lambda function.
  • Insights events
    Detect and report unusual account activity, spikes in errors, or other anomalous user behavior.

If you want to receive notifications about actions across all accounts in an AWS Organization, you’ll need to create a trail from the management account. This trail will automatically apply to all member accounts, though additional costs may apply. To keep expenses and storage low, you can configure the trail to monitor only “Write” actions, which reduces the size of the log files stored in your S3 bucket. Keep in mind that CloudTrail trails are region-specific, so you must create them separately in each AWS region you use.

4. Amazon SNS:

  • Amazon SNS (Simple Notification Service) is AWS’s fully managed publish/subscribe messaging and notification platform.
  • Endpoints that subscribe to a topic -such as email, SMS, Lambda, SQS, or HTTP/S webhooks- receive messages right away.
  • It’s designed for high scalability, low latency, and reliable delivery.
  • SNS is especially useful for application-to-application communication, event notifications, and push-based mobile alerts.

5. AWS Lambda:

AWS Lambda is Amazon’s serverless compute service.

  • You upload your code -written in Node.js, Python, Java, .NET, Go, Ruby, or other supported languages- and Lambda runs it only when it’s triggered (for example, by an S3 file upload, an API Gateway request, or an EventBridge event).
  • It scales automatically, creating as many instances as needed to handle incoming requests.
  • Pricing is based on how long your code runs and the resources it consumes, such as memory and CPU.

6. AWS Cloudformation:

AWS CloudFormation is a service that lets you define and manage AWS resources using the Infrastructure as Code approach.

  • You describe your resources -such as EC2, S3, IAM, RDS, Lambda or etc.- in a template file written in YAML or JSON.
  • Based on that template, CloudFormation automatically provisions, updates, and removes the resources as needed.
  • It’s an effective way to set up complex environments quickly, manage infrastructure changes safely, and put Infrastructure as Code into practice.

Setup Part:

a. Collecting and processing actions that happen within a single AWS account:

We’ll start with CloudTrail. As noted earlier, CloudTrail keeps the event history for 90 days by default. Because we’re going to act within the same account, there’s no need to create a dedicated trail. In this scenario, CloudTrail won’t introduce any additional cost.

Next, we move on to EventBridge Rules. Here we’ll create a rule to catch the actions we care about. In this case, we want notifications both when an EC2 instance changes state (e.g., a new instance is launched or an instance is started) and when there’s an issue in EKS with add-ons like CoreDNS, VPC CNI, or kube-proxy.

After confirming you’ve selected the active AWS Region you’re using, open the EventBridge service and go to the Rules section to create the rule.

Create a new rule with a clear name, just as shown above, and select the appropriate Event Pattern.

On the next page, decide what action should be taken when this event is captured. In our example, we’ll send an email notification through SNS.
If you prefer, you can forward the event to a Lambda function, parse its contents, and trigger other actions such as sending an email via SES, restarting or stopping an instance when you’re monitoring shutdown events, or handling spot instance interruptions by running a custom workflow.

Be sure to review the Event type section for each service so you understand exactly which events you’re targeting.

If you want to receive plain-text notifications through SNS, open the SNS service in a new browser tab (keep your current tab open) and create a topic and subscription similar to the example above.

After setting up the subscription, return to the EventBridge console, go to the Select Target(s) step, and click the refresh icon next to the Topic field. If the topic was created in the correct region, it should appear there. Click Next to finish creating the rule. Also note that once you create a subscription in SNS, an email confirmation will be sent to the address you specified. You’ll need to confirm that email before messages can be delivered.

When everything is set up, you’ll receive an email that looks like the one shown below:

If you’re not satisfied with the plain email format, you can choose Lambda in the Select Target(s) step within EventBridge. From there, have the Lambda function read and parse the message, then generate an HTML email template. You can send it using SES or connect to another mail server via the SMTP protocol. For example:

b. Collecting and processing actions from all accounts linked to an AWS Organization:

Since you manage your AWS environment with AWS Organizations and have multiple accounts, I’ll walk through the steps assuming you’re already familiar with many services and operations, without dwelling too much on the basics.

The benefit of AWS Organizations is that all member accounts can be administered from a single management account as noted earlier. In this setup, you should create CloudTrail trails from the Organizations management account. This aggregates activity from all member accounts into the management account, letting you view actions across the entire organization in one place. Note that this can incur additional charges. To keep costs down, if you only need to track changes, it’s sufficient to log only Write events. That approach also keeps the S3 log files smaller and reduces the number of captured API requests. You can also disable unused AWS Regions via SCPs in AWS Organizations, so you don’t need to create trails in those regions. And yes, CloudTrail trails are regional, so you must create them separately in each AWS Region you use.

To create trails, in your management account, search for CloudTrail, click Trails on the left, and choose Create to start the process. On the creation page, select “Enable for all accounts in my organization.”

After completing this step, go back to the EventBridge service in your management account and click on Event Bus. This is where you’ll gather events coming from your other accounts that are routed through EventBridge.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowSpecificAccountsToPutEvents",
    "Effect": "Allow",
    "Principal": {
      "AWS": ["arn:aws:iam::LINKEDACCOUNTID1:root", "arn:aws:iam::LINKEDACCOUNTID2:root", "arn:aws:iam::LINKEDACCOUNTID3:root", "arn:aws:iam::LINKEDACCOUNTID4:root"]
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:YOURREGIOINID:ORGACCOUNTID:event-bus/YOUREVENTBUSNAME"
  }]
}

Now add a rule to the Event Bus we just created.
For example, this time let’s receive a notification whenever an Amazon Redshift cluster is created.

In the next step, you can either select SNS to receive plain-text notifications, or send the event to a Lambda function, parse the payload, and email yourself an HTML template via SES as outlined earlier.

There’s one important detail:
For the EventBridge execution role you create, you must allow EventBridge to assume the role (trust policy) and grant it permission to either publish to SNS or invoke your Lambda function. In other words, the role’s Trusted Relationship should allow EventBridge, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TrustEventBridgeService",
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "YOURORGANIZATIONACCOUNTID"
                },
                "StringLike": {
                    "aws:SourceArn": [
                        "arn:aws:events:YOURREGION:YOURORGANIZATIONACCOUNTID:rule/YOUREVENTBRIDGEBUSNAME/YOUREVENTNAME"
                    ]
                }
            }
        }
    ]
}

With this step, we wrap up the configuration in the management account.
Now move on to the member accounts and create the same EventBridge rule there but with one key difference: instead of handling the events locally, configure the rule to forward any captured events to the EventBridge bus in the management account.

The role you’ll use here should have the following Trust Relationship, and its policy should be set as shown below:

  • Trust Relationship:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "YOURLINKEDACCOUNTID"
                },
                "StringLike": {
                    "aws:SourceArn": [
                        "arn:aws:events:eu-central-1:YOURLINKEDACCOUNTID:rule/YOUREVENTBRIDGENAME"
                    ]
                }
            }
        }
    ]
}
  • IAM Policy:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:PutEvents"
            ],
            "Resource": [
                "arn:aws:events:eu-central-1:YOURORGANIZATIONACCOUNTID:event-bus/YOUREVENTBRIDGEBUSNAME"
            ]
        }
    ]
}

Your AWS Organization may include more than 100 accounts. To help you understand the logic behind this setup, I’ve explained how to configure it through the console. However, you can also use CloudFormation StackSets from the management account to deploy the EventBridge rule and IAM role directly to your member accounts.

If you want to prevent even users with AdministratorAccess in those accounts from modifying this configuration, you can create a Service Control Policy (SCP) in AWS Organizations. To do this, go to your management account, open Organizations, and under Policies, choose Service Control Policies.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Deny",
			"Action": [
				"events:DeleteRule",
				"events:DisableRule",
				"events:PutTargets",
				"events:PutRule",
				"events:DescribeRule",
				"events:RemoveTargets"
			],
			"Resource": [
				"arn:aws:events:*:*:rule/EVENTRULENAME"
			]
		},
		{
			"Effect": "Deny",
			"Action": [
				"cloudtrail:DeleteTrail",
				"cloudtrail:StopLogging",
				"cloudtrail:UpdateEventDataStore"
			],
			"Resource": [
				"arn:aws:cloudtrail:*:*:trail/CLOUDTRAILNAME"
			]
		},
		{
			"Effect": "Deny",
			"Action": [
				"iam:DeleteRole",
				"iam:UpdateRole",
				"iam:UpdateRoleDescription",
				"iam:AttachRolePolicy",
				"iam:DeletePolicy",
				"iam:DeletePolicyVersion",
				"iam:DeleteRolePolicy",
				"iam:PutRolePolicy",
				"iam:GetPolicy",
				"iam:GetRolePolicy",
				"iam:CreatePolicyVersion"
			],
			"Resource": [
				"arn:aws:iam::*:role/service-role/IAMROLENAME",
				"arn:aws:iam::*:policy/service-role/IAMPOLICYNAME"
			]
		}
	]
}

I hope these article help save you time.

References: