Six Patterns for Connecting Amazon OpenSearch Service Logs to AWS DevOps Agent

This article uses generic service names and synthetic log examples. It contains no customer identifiers, production endpoints, account IDs, or credentials. AWS DevOps Agent documentation was checked on July 22, 2026. The latest entry on the What's new page was dated July 9, 2026. Recheck the current documentation and Region availability before implementation.

The integration question

Many teams already use Amazon OpenSearch Service as the searchable system of record for application and platform logs. They want AWS DevOps Agent to use that evidence during incident investigations without weakening access controls, duplicating unnecessary data, or presenting a likely cause as proven fact.

The first design decision is not which API to call. It is what investigation experience the team needs:

• Should an OpenSearch alert only start an investigation?
• Should AWS DevOps Agent perform interactive follow-up searches?
• Must OpenSearch remain the only searchable log store?
• Is a duplicate operational or archival copy acceptable?
• Does the team already operate a specialized investigation service or Grafana environment?
• Must the connection remain private?

As of July 22, 2026, Amazon OpenSearch Service is not listed as a built-in AWS DevOps Agent telemetry connector. AWS DevOps Agent does provide supported capabilities that can be composed into an integration: built-in CloudWatch and Amazon S3 telemetry access, custom MCP servers, remote A2A agents, generic webhooks, and a built-in Grafana integration.

This article compares those six patterns and explains when to use each one.

What logs can and cannot prove

Logs can often reveal:

• Application exceptions, stack traces, retry exhaustion, and failed operations
• Database, DNS, or upstream-service failures
• Authentication and authorization failures recorded by the application
• Slow requests, queue delays, and connection-pool exhaustion when those values are logged
• Error patterns that begin after a deployment or configuration change
• A failed transaction across services when shared request or trace identifiers exist

Logs alone might not prove:

• Silent data corruption where the application records success
• Missing evidence caused by a collector or routing failure
• CPU, memory, disk, or network saturation that the application does not log
• Configuration drift visible only in resource configuration or deployment records
• An upstream failure without shared identifiers or timestamp correlation
• Activity recorded only in an audit source such as AWS CloudTrail

A useful investigation must separate confirmed evidence, most likely cause, remaining uncertainty, and the next validation step. AWS DevOps Agent becomes more useful when log evidence is combined with metrics, traces, deployments, CloudTrail events, infrastructure relationships, and application context.

The six integration patterns

Decision table

Customer goal	Recommended pattern	Follow-up searches	Main trade-off
Fast proof of value	Enriched webhook	No direct follow-up against OpenSearch	Investigation is limited to the evidence supplied in the event
Most native AWS telemetry experience	CloudWatch Logs copy	Yes	Duplicates selected ingestion and storage
Keep OpenSearch as the only searchable log store	Read-only MCP server	Yes	Requires a customer-operated integration service
Delegate to a specialized log-analysis service	Remote A2A agent	Yes, through delegated investigation tasks	More infrastructure and currently limited to incident investigations
Analyze historical or archived evidence	Readable Amazon S3 copy	Limited to stored objects	Less current and less interactive
Reuse an existing Grafana environment	Grafana integration	Depends on supported exposed data	OpenSearch-backed query coverage must be validated

Primary recommendation

For a demonstration, start with an enriched webhook because it proves the incident flow with the smallest integration surface.

For production, choose CloudWatch Logs when a duplicate operational copy is acceptable. Choose MCP when OpenSearch must remain the only searchable log store and AWS DevOps Agent needs interactive follow-up searches.

Do not deploy every option. Select one primary interactive path and, if needed, one historical path. A common combination is MCP for current OpenSearch logs and Amazon S3 for archived logs.

Prepare the evidence before choosing a connector

Connection technology cannot compensate for inconsistent or sensitive log data. Complete these steps first:

1. Define scope. Select the applications, environments, index patterns, and incident types included in the first release.
2. Standardize fields. Use consistent fields for timestamp, service, environment, severity, message, error type, request ID, trace ID, duration, host, and deployment identifier.
3. Choose a reversible test incident. Use a known failure in a non-production environment, such as a dependency timeout.
4. Prepare the Agent Space. Connect the required AWS accounts and other telemetry sources.
5. Define an evidence contract. Require the queried time range, matching-record count, earliest failure, representative events, affected services, and correlation identifiers.
6. Use read-only access. The integration must not create, update, or delete OpenSearch documents, indexes, alerts, or production resources.
7. Bound every query. Restrict index patterns, time range, row count, aggregation size, request size, and request rate.
8. Protect sensitive data. Remove secrets, tokens, personal data, and regulated values before evidence is returned.

A practical structured-log schema includes:

Field	Purpose	Example
@timestamp	UTC event time	2026-07-21T14:03:15Z
service	Stable application or component name	checkout-api
environment	Deployment environment	test
level	Severity	ERROR
error_type	Stable error category	DatabaseTimeout
trace_id	Cross-service transaction identifier	trace-001
request_id	Request identifier	request-042
duration_ms	Measured duration	5120
deployment_id	Release or build identifier	release-2026-07-21.2

Pattern 1: Copy selected logs to CloudWatch Logs

Choose this pattern when the team wants AWS DevOps Agent to use a built-in AWS telemetry source and accepts a second copy of selected logs.

The CloudWatch integration uses the IAM roles configured for the Agent Space. No separate telemetry-provider registration is required.

Implementation outline:

1. Create log groups by application and environment with an approved retention period.
2. Configure the collector or ingestion layer to send the same selected events to OpenSearch and CloudWatch Logs.
3. Preserve timestamps, service names, trace IDs, request IDs, and deployment IDs in both destinations.
4. Generate one event and verify that both copies contain matching identifiers.
5. Grant the Agent Space role only the documented CloudWatch read permissions it requires.
6. Run a manual investigation for a bounded service and time window.
7. Add an approved alarm or incident trigger after the manual path is validated.
8. Review duplicate ingestion, retention, and data-governance implications before expanding scope.

Use this pattern when simplicity of the AWS DevOps Agent investigation path is more important than avoiding duplicate storage.

Pattern 2: Expose bounded OpenSearch searches through MCP

Choose MCP when OpenSearch must remain the primary searchable log store and AWS DevOps Agent needs interactive queries.

AWS DevOps Agent supports MCP servers that use Streamable HTTP transport and OAuth 2.0, API key, or AWS Signature Version 4 authentication. The MCP server is registered at the account level, then specific tools are allowlisted for each Agent Space.

Expose task-oriented tools rather than arbitrary query text:

Tool	Purpose	Required boundary
search_logs	Search by service, time range, severity, and approved text fields	Fixed index list, row limit, maximum time range
summarize_errors	Count and group errors in an incident window	Aggregation and field allowlists
find_by_trace_id	Reconstruct one transaction	Exact identifier and bounded results
compare_periods	Compare an incident period with a healthy period	Maximum interval and approved aggregations
get_log_samples	Return representative events	Redaction and sample limit

An MCP response should be compact and structured:

{
  "time_range": "2026-07-21T14:00:00Z/2026-07-21T14:15:00Z",
  "total_matching_logs": 187,
  "first_failure": "2026-07-21T14:03:15Z",
  "top_error_type": "DatabaseTimeout",
  "affected_services": ["checkout-api"],
  "trace_ids": ["trace-001", "trace-002"],
  "representative_events": [
    "Database connection timed out after 5000 ms"
  ]
}

Important controls:

• Do not accept arbitrary index names, unrestricted OpenSearch Query DSL, or unbounded raw-log retrieval.
• Use AWS Signature Version 4 between the MCP service and OpenSearch when appropriate.
• Allowlist only the read-only MCP tools required by the Agent Space.
• Treat log messages as untrusted data; they cannot change tool permissions or query boundaries.
• Record request identity, tool name, duration, result size, and error status without logging credentials or sensitive returned fields.

AWS DevOps Agent supports private connections for privately hosted MCP endpoints using supported non-SigV4 authentication designs. Private connections are not supported for MCP servers that use SigV4 authentication; those MCP endpoints must be publicly accessible. Select the endpoint authentication and network pattern together.

Pattern 3: Delegate OpenSearch analysis to a remote A2A agent

Choose a remote Agent-to-Agent (A2A) integration when the team already operates—or deliberately wants—a separate investigation service specialized in OpenSearch.

AWS introduced remote A2A agent connections on June 12, 2026. The feature-specific documentation currently limits remote A2A agents to incident investigations.

The remote service must implement the A2A protocol, publish a valid agent card at an accessible HTTPS URL, and support one of the documented authentication methods. Its response should include confirmed evidence, earliest failure, recurring patterns, affected transactions, likely cause, remaining uncertainty, and recommended validation.

Use this pattern when delegated analysis is a product or platform capability of its own. Do not add an A2A service merely to wrap a small set of searches that a simpler MCP server can expose.

Pattern 4: Send an enriched webhook

Choose this pattern for the fastest proof of value.

For OpenSearch 2.3 or later, OpenSearch Notifications supports Amazon SNS notification channels. A Lambda function subscribed to the topic can search a bounded incident window, create a small evidence package, and call a generic Agent Space webhook.

On June 24, 2026, AWS DevOps Agent added a choice of HMAC or API key authentication for generic Agent Space webhooks. Use HMAC when payload integrity and replay protection are required. Store the signing secret or API key in AWS Secrets Manager and rotate it.

Example payload:

{
  "eventType": "incident",
  "incidentId": "checkout-timeout-20260721-1403",
  "action": "created",
  "priority": "HIGH",
  "title": "Checkout database timeouts",
  "timestamp": "2026-07-21T14:03:15Z",
  "service": "checkout-api",
  "data": {
    "timeRange": "2026-07-21T14:00:00Z/2026-07-21T14:15:00Z",
    "totalErrors": 187,
    "topErrorType": "DatabaseTimeout",
    "firstFailure": "2026-07-21T14:03:15Z",
    "traceIds": ["trace-001", "trace-002"],
    "evidence": ["Database connection timed out after 5000 ms"]
  }
}

This pattern can trigger a useful investigation, but it does not give AWS DevOps Agent direct follow-up access to OpenSearch. If the first investigation repeatedly needs additional searches, graduate to MCP, A2A, or CloudWatch Logs.

Pattern 5: Store a readable log copy in Amazon S3

Choose Amazon S3 for historical investigations, archived logs, or an existing data-retention design.

Store investigation evidence as a documented readable format, such as JSON Lines or compressed JSON Lines. An OpenSearch snapshot is a recovery artifact, not the readable log-object format expected by this pattern.

Use predictable prefixes such as:

s3://<approved-bucket>/logs/environment=<env>/service=<service>/year=<yyyy>/month=<mm>/day=<dd>/hour=<hh>/

The Agent Space role needs s3:ListBucket and s3:GetObject, scoped to only the approved bucket and prefixes. Apply encryption, block public access, retention controls, and access logging. Remove or mask sensitive fields before writing the objects.

This path is less interactive than MCP, but it works well for long-retention evidence and can complement an interactive current-log pattern.

Pattern 6: Use Grafana as a conditional integration layer

Choose this pattern only when the team already operates Grafana and a proof of value confirms that the required OpenSearch evidence is available through the supported Grafana functions.

AWS DevOps Agent's built-in Grafana integration can query metrics, dashboards, and alerting data. Its tools are read-only. Current documentation does not state that arbitrary OpenSearch-backed data-source queries are supported, so do not assume that every OpenSearch query visible in Grafana is available to an investigation.

Implementation outline:

1. Use Grafana 9.0 or later over HTTPS.
2. Create a service account with Viewer-level access.
3. Connect Grafana to the approved OpenSearch data and create the required dashboards and alerts.
4. Register Grafana as an AWS DevOps Agent capability provider.
5. Add the provider to the Agent Space.
6. Run a capability test that records which OpenSearch-backed dashboard and data-source operations are available.
7. Proceed only if those supported operations satisfy the evidence contract.

Self-managed Grafana can use webhook contact points to start investigations. Amazon Managed Grafana has current limitations for this trigger path: webhook contact points are not supported, and its service account tokens have a maximum expiration of 30 days. Use another trigger and implement token rotation when those limitations apply.

Define an evidence contract

Regardless of the pattern, require every log-analysis result to return:

1. Incident summary
2. Queried time range
3. Total matching records, or an explicit statement that the count is unavailable
4. Earliest observed failure
5. Affected services and transactions
6. Representative timestamps, messages, request IDs, and trace IDs
7. Most likely cause
8. Supporting deployments, configuration changes, or dependencies
9. Remaining uncertainty
10. Recommended validation and mitigation steps

This structure makes the result auditable and prevents a plausible narrative from being mistaken for confirmed root cause.

Deliver in three phases

Phase 1: Prove the incident flow

• Use a non-production index and a known, reversible failure.
• Implement one OpenSearch monitor and one enriched webhook path.
• Confirm that one event starts one AWS DevOps Agent investigation.
• Review whether the supplied evidence is sufficient.
• Record which additional searches or telemetry sources the investigation needs.

Phase 2: Select the production access pattern

• Choose CloudWatch Logs when duplicate operational storage is acceptable.
• Choose MCP when OpenSearch remains the primary searchable store and interactive searches are required.
• Choose A2A for a separately owned specialized investigation service.
• Add Amazon S3 when historical evidence or long retention is required.
• Use Grafana only after validating its supported OpenSearch-backed evidence path.

Phase 3: Improve investigation quality

• Add metrics, traces, deployment events, CloudTrail evidence, and topology context.
• Improve log schema consistency and correlation identifiers.
• Add repeatable incident scenarios and regression tests.
• Measure time to first useful finding, evidence completeness, unsupported cases, and incorrect conclusions.

Security and operating controls

Control	Implementation guidance
Read-only access	Permit only the search, describe, list, and read operations required by the selected pattern
Index scope	Use a fixed set of approved index patterns; reject arbitrary index selection
Field scope	Return only fields needed for investigation and remove secrets or sensitive values
Query limits	Enforce maximum time range, row count, aggregation buckets, request size, and request rate
Endpoint protection	Use HTTPS and a supported authentication method; store credentials in AWS Secrets Manager
Network path	Prefer private connectivity where the selected authentication design supports it
Untrusted log content	Treat messages as data only; log text cannot modify permissions, tools, or query limits
Audit trail	Record configuration changes, authentication events, query metadata, failures, and result sizes
Retention	Align OpenSearch, CloudWatch Logs, and Amazon S3 retention with policy
Change control	Test integration changes and known failure scenarios in non-production before production use

Start read-only in non-production. Do not use the first implementation to make production changes, delete OpenSearch data, or disable safety controls.

Acceptance criteria

A production candidate should pass all of these checks:

• The integration cannot modify OpenSearch documents, indexes, alerts, or production resources.
• The investigation uses the correct service, environment, and bounded time window.
• It reports the matching-record count or states when that count is unavailable.
• It cites representative timestamps, messages, request IDs, and trace IDs.
• It separates confirmed evidence from the likely cause.
• It identifies when logs are insufficient and names the next source to inspect.
• Sensitive fields are removed before evidence is returned.
• Out-of-scope indexes, long time ranges, and excessive result requests are rejected.
• Registration, authentication, integration queries, and investigation activity are auditable.

Include a missing-log scenario in testing. A trustworthy investigation should recognize insufficient evidence rather than inventing a root cause.

Summary

There is no single correct way to connect Amazon OpenSearch Service logs to AWS DevOps Agent.

Use an enriched webhook to prove the incident flow quickly. Use CloudWatch Logs for a built-in AWS telemetry path when duplicate storage is acceptable. Use a read-only MCP server when OpenSearch must remain the only searchable store and the agent needs interactive follow-up searches. Use a remote A2A agent for a separately owned investigation service, Amazon S3 for historical evidence, and Grafana only after testing the supported OpenSearch-backed query path.

Whichever option you select, the most important design controls are the same: structured evidence, bounded read-only access, field redaction, auditability, reversible non-production tests, and an explicit distinction between confirmed facts and a likely cause.

References

• AWS DevOps Agent, What's new
• AWS DevOps Agent, Connecting telemetry sources
• AWS DevOps Agent, Connecting MCP servers
• AWS DevOps Agent, Connecting remote A2A agents
• AWS DevOps Agent, Invoking DevOps Agent through a webhook
• AWS DevOps Agent, Connecting Grafana
• Amazon OpenSearch Service, Configuring alerts
• Amazon OpenSearch Service, Monitoring data