AWS EventBridge API Destinations

Route AWS service events directly to Bronto using Amazon EventBridge API Destinations, with no Lambda function required for forwarding or transformation.

​

When to Use EventBridge

EventBridge API Destinations are a good fit when you want to:

• Forward AWS service events into Bronto without writing or maintaining a Lambda function
• Ingest audit and compliance data such as CloudTrail events, GuardDuty findings, or AWS Config change notifications
• React to ECS task state changes, EC2 instance events, or other AWS operational events in near real-time

For application logs or traces from running workloads, use ADOT, FireLens, or the CloudWatch Log Forwarder instead.

---

​

Supported AWS Services

EventBridge API Destinations work with any AWS service that publishes to the default event bus:

Service	Log / event type
AWS CloudTrail	Management and data event audit records
Amazon GuardDuty	Security threat findings
Amazon DynamoDB	Table and item API calls (via CloudTrail)
AWS Config	Resource configuration change events
Amazon ECS	Task and container state changes
Amazon EC2	Instance state change notifications
AWS Health	Service health and scheduled maintenance events
AWS Step Functions	State machine execution events
AWS WAF	Configuration API calls (via CloudTrail). For request and rule-match logs, use WAF logging instead

Any other AWS service that publishes events to EventBridge can be captured by adding the appropriate rule pattern. See the AWS documentation on EventBridge event sources for the full list.

---

​

Setup

EventBridge API Destinations POST matched events to Bronto as JSON, with retries handled by EventBridge. You create a Connection for the API key, an API Destination for the Bronto endpoint, and a Rule for the events to send.

​

Step 1 — Create an EventBridge Connection

The connection stores your Bronto API key as a custom authorisation header.

In the AWS Console, go to EventBridge → API Destinations → Connections → Create connection:

Field	Value
Connection name	bronto-connection
Authorization type	API Key
API key name	x-bronto-api-key
API key value	<YOUR_API_KEY>

Via AWS CLI:

aws events create-connection \
  --name bronto-connection \
  --authorization-type API_KEY \
  --auth-parameters '{
    "ApiKeyAuthParameters": {
      "ApiKeyName": "x-bronto-api-key",
      "ApiKeyValue": "<YOUR_API_KEY>"
    }
  }'

​

Step 2 — Create an API Destination

In EventBridge → API Destinations → Create API destination:

Field	Value
Name	bronto-destination
API destination endpoint	https://ingestion.eu.bronto.io (EU) or https://ingestion.us.bronto.io (US). Use the base endpoint, not /v1/logs, which accepts only OTLP
HTTP method	POST
Connection	bronto-connection (from Step 1)
Invocation rate limit per second	Set based on your expected event volume

Create the API destination once the connection shows the Authorized state.

​

Step 3 — Create an EventBridge Rule

Create a rule on the default event bus that matches the events you want to forward and targets the API Destination.

Example: forward all CloudTrail API call events:

{
  "detail-type": ["AWS API Call via CloudTrail"]
}

To limit it to specific services, add a source list such as ["aws.dynamodb", "aws.iam"]. The source is the originating service, not aws.cloudtrail.

CloudTrail events need an active trail. A rule in the default ENABLED state receives write events only; set the rule state to ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS to also receive read-only events.

Example: forward GuardDuty findings:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

Set the rule target to the bronto-destination API Destination, with an IAM role that allows events:InvokeApiDestination (the console can create one). Add an SQS dead-letter queue to the target to keep events that still fail after retries.

---

​

Data Organization

EventBridge Connections support custom HTTP headers via InvocationHttpParameters. Use these to set Bronto’s recommended headers — see Data Organization for how datasets, collections, and tags work.

Header	Description
x-bronto-dataset	Dataset to ingest into
x-bronto-collection	Collection name
x-bronto-tags	Comma-separated tags to attach to events

Add them when creating or updating the Connection:

aws events update-connection \
  --name bronto-connection \
  --auth-parameters '{
    "ApiKeyAuthParameters": {
      "ApiKeyName": "x-bronto-api-key",
      "ApiKeyValue": "<YOUR_API_KEY>"
    },
    "InvocationHttpParameters": {
      "HeaderParameters": [
        { "Key": "x-bronto-dataset", "Value": "<YOUR_DATASET_NAME>", "IsValueSecret": false },
        { "Key": "x-bronto-collection", "Value": "<YOUR_COLLECTION_NAME>", "IsValueSecret": false },
        { "Key": "x-bronto-tags", "Value": "env=prod,source=eventbridge", "IsValueSecret": false }
      ]
    }
  }'

To send different rules to different datasets, set x-bronto-dataset as a Header Parameter on each rule’s target instead of on the connection.

---

​

Cost Notes

• No Lambda compute cost. AWS service events on the default event bus are free to ingest.
• You pay per API Destination invocation (each 64 KB chunk counts as one) plus data transfer.

---

For assistance, contact [e-mail].