Amazon OpenSearch can now keep agent traces nested—but the optimized engine is not a vector-search replacement

Amazon OpenSearch Service has added agent-trace support to its optimized log-analytics engine, giving operators a single place to follow an agent session, identify a slow or failed step and inspect the related logs. The important architectural detail is not just that traces are searchable: on OpenSearch 3.7, span events, span links, prompts and tool calls retain their nested structure rather than being flattened during ingestion. AWS announcement

What changed

The optimized engine now accepts OpenTelemetry traces and maps logs and traces into object, nested and flat-object fields, including multi-value arrays. AWS also says hot-tier records can be updated, deleted or upserted by document ID, so late or incorrect telemetry can be corrected without rebuilding the whole analytical view. Operators can investigate the result through Discover Traces, application performance monitoring, service maps, and dedicated agent-trace and session views. AWS announcement

That makes the launch useful for analytics agents whose failures cross several tool calls. Preserving a tool call and its attributes as a nested object lets an operator query a field inside the call while retaining its relationship to the surrounding span. It is a better fit for session reconstruction than a pipeline that first flattens every attribute into unrelated columns. This is an architectural implication of AWS’s documented nested-field behavior, not a published claim that tracing improves an agent’s answer quality. AWS announcement

The engine boundary matters

AWS’s documentation is unusually explicit about when not to choose this engine. The optimized mode is intended for append-heavy log, trace and finding analytics using PPL or SQL, particularly at multi-terabyte scale. It combines Parquet columnar storage for analytics with a Lucene index for full-text search, routing analytical operations through DataFusion while retaining search predicates for incident investigation. AWS optimized-engine documentation

By contrast, AWS recommends the general-purpose engine for relevance ranking, Painless scripting, geo queries, vector or semantic search, and workloads with frequent in-place updates. Teams should therefore treat the new trace support as an observability store for agent execution—not as a reason to move an agent’s retrieval index onto the optimized mode. The two engines solve adjacent but different problems. AWS optimized-engine documentation

The feature requires OpenSearch 3.7 and is available at no additional charge in 12 listed regions across the US, Canada, Asia-Pacific and Europe. Existing pipelines can send telemetry through OpenSearch Ingestion; AWS says the optimized engine otherwise uses the same console, APIs, security model and networking configuration as the general-purpose engine. AWS announcement AWS optimized-engine documentation