AWS DevOps Agent Integration

Trigger AWS DevOps Agent investigations from Bronto monitor alerts and connect Bronto’s hosted MCP server for searchable log context.

​

Overview

The AWS DevOps Agent is an AI assistant for operating AWS workloads. Bronto integrates with it in two complementary directions:

• Alert delivery: Bronto sends a monitor alert to an AWS Agent Space webhook, which opens a DevOps Agent investigation automatically.
• Investigation context: AWS DevOps Agent calls Bronto’s hosted MCP server to search log datasets and use time-series and schema-discovery tools while it investigates.

You can use alert delivery on its own. Add the MCP connection when you also want the agent to query Bronto log data during an investigation. Metrics and traces are not stored in datasets or collections; view them in Bronto’s Metric Explorer and Explore Traces.

​

Trigger investigations from monitor alerts

When a Bronto monitor enters the alert state, Bronto can send the monitor, query, affected group, and current value to AWS DevOps Agent. AWS uses that event to open an investigation in the connected Agent Space.

Bronto sends alerts only. Warning and recovery state changes do not open investigations.

​

Prerequisites

• An Agent Space in AWS DevOps Agent.
• Permission to configure webhooks for the Agent Space and integrations in Bronto.
• A Bronto monitor that can be used to verify the connection. See Monitoring Overview & Threshold Monitors.

​

Connect Bronto to an Agent Space

1. Create an HMAC webhook in AWS

   In the AWS DevOps Agent console, select the Agent Space, open Capabilities, and find the Agent Space Webhook table. Add a webhook and choose HMAC authentication.

   Copy the webhook URL and signing secret that AWS displays. For the underlying AWS workflow, see Invoking DevOps Agent through Webhook.

   AWS displays the signing secret only when the webhook is created or rotated. Store it securely before leaving the page.

2. Open the AWS DevOps Agent integration in Bronto

   In Bronto, go to Settings > Integrations and select AWS DevOps Agent. Select Connect AWS DevOps Agent or the + button.

3. Enter the webhook credentials

   Paste the values from AWS into Webhook URL and Signing secret, then select Connect.

   Bronto signs each request with HMAC-SHA256 using the signing secret. The secret itself is never sent to AWS.

4. Verify the integration

   Use a safe test monitor and let it enter the alert state. Confirm that AWS DevOps Agent opens an investigation containing the monitor, query, group, and evaluated value.

To connect another Agent Space, return to the AWS DevOps Agent integration and select the + button.

​

Rotate the signing secret

AWS does not let you retrieve a signing secret after its initial display. If you lose it or need to replace it, rotate the HMAC webhook from the Agent Space’s Capabilities tab. AWS keeps the same webhook URL and generates a new signing secret. Update the Bronto integration immediately because the previous secret stops working after rotation.

​

Give investigations access to Bronto logs

Register Bronto’s hosted MCP server as a Capability Provider when the DevOps Agent should search your Bronto log datasets during an investigation. This connection supports OAuth with Dynamic Client Registration or a Bronto API key, and is separate from the alert webhook.

For the underlying AWS workflow, see the AWS documentation on connecting MCP servers.

​

Prerequisites

• A Bronto account with data being ingested. If you haven’t sent data yet, set up an agent first.
• A Bronto user permitted to sign in to the hosted MCP server, or a Bronto API key with the Agent Read Only role if you prefer API-key authentication. This role provides read access to telemetry data, monitors, and usage data. See Hosted MCP Server and API Key Roles.
• Access to the AWS DevOps Agent in your AWS account, with permission to register Capability Providers.
• The Bronto hosted MCP endpoint for your region — see Hosted MCP Server.

Region	Hosted MCP Endpoint URL
US	https://mcp.us.bronto.io/mcp
EU	https://mcp.eu.bronto.io/mcp

​

Register the Bronto MCP server

1. Open the Register MCP Server wizard

   In the AWS DevOps Agent console, open Capability Providers and start the Register MCP Server flow.

2. Step 1 — MCP server details

   Enter the server details:

   Field	Value
   Name	BrontoMCPServer (or any name you prefer)
   Endpoint URL	The hosted MCP endpoint for your region (see above)
   Description	Optional
   Enable Dynamic Client Registration	Select for OAuth; leave cleared for an API key

   Bronto’s hosted MCP server implements the Streamable HTTP transport, which is what the DevOps Agent requires.

   

   Click Next.

   If you enabled Dynamic Client Registration, AWS skips the manual authorization flow and configuration steps and redirects you directly to Bronto. Sign in using a login method your admin has enabled for MCP, approve the requested scopes, and follow the remaining prompts to finish registration. You do not need to create a client ID or client secret manually.

   If you are using an API key, continue to the next step.

3. Step 2 — Authorization Flow (API key only)

   Select API Key to authenticate with a static Bronto API key.

   

   Click Next.

4. Step 3 — Authorization Configuration (API key only)

   Enter the API-key configuration that Bronto expects:

   Field	Value
   API Key Name	BrontoAPIKey (display name only)
   API Key Header	X-BRONTO-API-KEY
   API Key Value	Your Bronto API key

   

   The header name must be X-BRONTO-API-KEY — Bronto’s MCP server reads the API key from this header and will reject requests sent under any other header name.

   Click Next.

5. Step 4 — Review and submit (API key only)

   Confirm the MCP server details and authorization configuration, then click Add.

   

​

Select MCP server tools

After registration, the DevOps Agent prompts you to choose which Bronto tools it is allowed to call. The Bronto hosted MCP server exposes a set of read-only tools that cover log schema discovery, log search, time-series analysis over log data, and saved searches. These dataset tools do not query metrics or traces.

The recommended setup is to enable all Bronto tools. They are all read-only and cooperative — for example, the agent typically uses get_datasets and get_keys to discover the right dataset and schema before issuing a search_logs or timeseries query.

For full descriptions of each tool, see Hosted MCP Server — Capabilities.

As shown in the AWS UI, only enable MCP tools that are read-only. All Bronto tools listed here are read-only — they query log data and metadata without modifying anything in your Bronto account.

Click Save to finish.

​

Verify the connection

Open an Agent Space in the AWS DevOps Agent console and ask a question that requires Bronto data, for example:

List the datasets I have in Bronto.

The agent should call get_datasets against the Bronto MCP server and return the datasets in your account.

Once that works, you can move on to investigation-style prompts — searching recent error logs or comparing time windows. See Hosted MCP Server — Example Prompts for inspiration.

​

Example use cases

Once the Bronto Capability Provider is attached to an Agent Space, the DevOps Agent can combine AWS service state with Bronto telemetry in a single investigation. A few common workflows:

​

Root-cause a service incident with log context

When a service is misbehaving — elevated errors, failing health checks, customer reports, or a triggered alert — the agent can identify the affected resource in AWS and then call search_logs against the Bronto dataset for that service to surface the errors driving the incident. That includes stack traces, request IDs, and downstream-dependency failures that aren’t visible from AWS service state alone.

​

Investigate latency regressions in access logs

Ask the agent to compare request-duration fields in your log datasets with a baseline window using timeseries, then drill into the slowest log events with search_logs. Use Bronto’s Explore Traces page when the investigation requires span-level trace data.

​

Correlate deployments with error spikes

Point the agent at a recent ECS, EKS, or Lambda deployment and ask whether errors increased after the rollout. The agent uses AWS to identify the deploy window and Bronto to count and sample errors before and after — giving you a quick verdict on whether to roll back.

​

Diagnose noisy or failing AWS Lambda functions

For a specific Lambda function, the agent can fetch recent invocations from AWS and then call search_logs with the function name as a filter to summarise the dominant error patterns. Useful when a function is silently retrying, timing out, or hitting a downstream rate limit.

​

Investigate elevated 5xx responses behind ALB or API Gateway

Combine AWS ALB or API Gateway metrics with Bronto access logs to find the host, path, and upstream service driving a 5xx spike. The agent can use get_keys to discover the right fields in your dataset before grouping and filtering — without you having to remember the schema.

​

Follow a request through correlated logs

When you have a request ID, trace ID, or user ID from an AWS support case, ask the agent to find related log events in Bronto. The agent searches log datasets to assemble a timeline from correlated logs. To inspect the spans in a distributed trace, open Explore Traces in Bronto.

​

Troubleshooting

A monitor alert does not open an investigation. Confirm that the monitor entered the alert state, not warning or recovery. Check that the Bronto integration shows as connected and that its webhook URL belongs to the intended Agent Space.

AWS rejects the webhook signature. Confirm that Bronto has the current HMAC signing secret for the Agent Space webhook. If the secret was lost or rotated, rotate it in AWS and update the Bronto integration with the newly generated value.

Dynamic registration or OAuth sign-in fails. Confirm that Enable Dynamic Client Registration is selected. Also check that hosted MCP is enabled, your login method is allowed for MCP, and the endpoint matches your Bronto region.

API-key authentication fails. Double-check that the API Key Header is exactly X-BRONTO-API-KEY and that the API key is valid and has the Agent Read Only role. Also confirm you registered the endpoint for the correct region (US vs EU) — a mismatched region returns an authentication error.

The agent does not call Bronto tools. Confirm the tools were enabled on the Select MCP server tools step, and that the Bronto Capability Provider is attached to the Agent Space where you are prompting from.