Optimizing AWS EventBridge - Default vs. Custom Event Buses and Best Practices

Optimizing AWS EventBridge: Default vs. Custom Event Buses and Best Practices

Introduction

Amazon EventBridge is a powerful service for routing AWS events to different targets. But many users wonder: Should I use the default event bus or a custom one? Does having many rules cause issues? In this guide, we'll answer these questions and provide best practices for managing EventBridge efficiently.

---

1. Default vs. Custom Event Bus: Which One Should You Use?

✅ Default Event Bus (Best for AWS Services)

AWS automatically creates the default event bus in every region. Use it when you need to capture AWS service events, like EC2 state changes, S3 object creation, or Lambda executions.

🔹 Advantages of Default Event Bus:

✔ No setup required – AWS services send events to it automatically.
✔ Low latency – Designed for quick event processing.
✔ Less management overhead – No need to create custom buses.
✔ You are only billed when an event matches the rule.

📌 Terraform Example Using Default Event Bus

resource "aws_cloudwatch_event_rule" "this" {
  name        = "ec2-instance-state-change"
  description = "Capture EC2 instance state changes"
  event_pattern = jsonencode({
    source        = ["aws.ec2"]
    "detail-type" = ["EC2 Instance State-change Notification"]
    detail = {
      state         = ["pending", "running", "shutting-down", "stopping", "stopped", "terminated"]
      "instance-id" = ["i-0123456789abcdef0"]
    }
  })
}

📌 Default bus is used automatically—no extra configuration needed!

---

✅ Custom Event Bus (For Custom or Cross-Account Events)

Use a custom event bus when:

• You send custom events from applications.
• You forward events across AWS accounts.
• You want to isolate different applications.

📌 Terraform Example Using a Custom Event Bus

resource "aws_cloudwatch_event_bus" "custom_bus" {
  name = "my-custom-event-bus"
}

resource "aws_cloudwatch_event_rule" "this" {
  name          = "custom-app-event"
  description   = "Capture custom application events"
  event_bus_name = aws_cloudwatch_event_bus.custom_bus.name
  event_pattern = jsonencode({
    source        = ["custom.application"]
    "detail-type" = ["Custom Event"]
  })
}

📌 You must specify event_bus_name when using a custom bus.

---

2. Does Having Many Rules on the Default Event Bus Cause Issues?

🔹 Performance Considerations

✅ AWS EventBridge scales automatically – having many rules does not slow down event processing.
✅ Each rule processes events independently – so multiple rules won’t interfere with each other.

🔹 Cost Considerations

✔ Event rules do not incur a charge unless they match an event.
✔ If an event matches multiple rules, each rule is processed separately.

✅ Best Practices for Managing Many Rules

1️⃣ Use Specific Event Patterns

Bad (Too Broad, Matches Everything):

{
  "source": ["aws.ec2"]
}

Good (More Specific):

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": { "state": ["running"] }
}

2️⃣ Deduplicate Similar Rules

❌ Inefficient (Separate Rules for Each State):

resource "aws_cloudwatch_event_rule" "ec2_running" {
  name = "ec2-instance-running"
  event_pattern = jsonencode({ "detail": { "state": ["running"] } })
}
resource "aws_cloudwatch_event_rule" "ec2_stopped" {
  name = "ec2-instance-stopped"
  event_pattern = jsonencode({ "detail": { "state": ["stopped"] } })
}

✅ Efficient (Single Rule with Multiple States):

resource "aws_cloudwatch_event_rule" "ec2_state_change" {
  name = "ec2-instance-state-change"
  event_pattern = jsonencode({ "detail": { "state": ["running", "stopped", "terminated"] } })
}

✔ Fewer rules = Better management

---

3. How to Query EventBridge Events?

🔹 Query Events from the Last Hour

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=ec2.amazonaws.com \
  --start-time "$(date -u -d '1 hour ago' +'%Y-%m-%dT%H:%M:%SZ')" \
  --max-results 50

🔹 Simulate an Event to Test Matching

aws events put-events --entries '[
  {
    "Source": "aws.ec2",
    "DetailType": "EC2 Instance State-change Notification",
    "Detail": "{\"state\": \"running\", \"instance-id\": \"i-0123456789abcdef0\"}"
  }
]'

---

🚀 Final Thoughts: What Should You Use?

Use Case	Event Bus Type
AWS Service Events (EC2, S3, CloudTrail)	✅ Default Event Bus
Application-Specific Events	✅ Custom Event Bus
Cross-Account Event Forwarding	✅ Custom Event Bus
Simplicity & Auto-Scaling	✅ Default Event Bus

📌 For most AWS services (like EC2 instance state changes), the default event bus is the best option! 🚀

---

Let’s Discuss!

💬 What’s your experience with AWS EventBridge? Do you use a default or custom event bus? Drop a comment below! 👇