OpenSearch semantic enrichment reached VPC domains on 17 August 2026 with an authorization step AWS did not announce

Summary. On 17 August 2026 AWS extended automatic semantic enrichment in Amazon OpenSearch Service to VPC-enabled domains across 11 Regions, and told customers that "no changes to existing VPC configurations are required." The service guide says otherwise: on a VPC domain, every create-index, update-index, get-index and delete-index call fails with AccessDeniedException until you authorize the principal features.opensearchservice.amazonaws.com through the AuthorizeVpcEndpointAccess API. The feature bills at $0.24 per Semantic Search OCU-hour in US East (N. Virginia) and $0.29 in Asia Pacific (Mumbai), processes only the first 8,192 tokens of an English document and 512 tokens of a multilingual one, and throttles indexing inference at 200 TPS.

That gap between the announcement and the guide is the whole story for anyone planning a migration window this quarter.

What actually shipped on 17 August 2026

Automatic semantic enrichment is not new. What changed on 17 August is that it now works on domains that sit inside a VPC rather than only on public-access domains. AWS lists 11 Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, Spain, Stockholm). The Price List API carries a SemanticSearchOCU product in exactly those 11 Regions and nowhere else, which is a useful independent confirmation that the Region list in the announcement is the real one.

The feature replaces lexical matching with a service-managed pre-trained sparse model. AWS runs it in document-only mode, so encoding happens at ingestion and search queries are only tokenized. The guide publishes its own benchmark numbers: on English content, a 20% relevance improvement over lexical search and a p90 search latency of 24 ms against BM25's 26 ms. On multilingual content the relevance improvement is 105%, but p90 latency moves the other way, from 26 ms to 36 ms — a 38.4% increase. Those figures came from MS MARCO passages averaging 334 characters, scored as ndcg@10 on BEIR for English and MIRACL for multilingual.

The authorization call the announcement leaves out

A VPC domain is not publicly reachable. AWS provisions the ML model, ingest pipeline and search pipeline for semantic enrichment from a managed service that lives outside your VPC, so that service needs a way in. The guide is explicit: "you must authorize this managed service to access your domain before you create or manage a semantic enrichment index."

The call is one line:

aws opensearch authorize-vpc-endpoint-access \
  --domain-name {domain-name} \
  --service "features.opensearchservice.amazonaws.com" \
  --region {region}

Skip it and the guide says the failure looks like this:

An error occurred (AccessDeniedException) when calling the GetIndex operation:
This operation is not authorized for VPC domain. Please authorize
'features.opensearchservice.amazonaws.com' through the AuthorizeVpcEndpointAccess API.

You authorize once per domain, and public-access domains do not need it at all. It is a small step. The problem is that it is invisible from the announcement, so a team that reads only the What's New page and schedules a change window will burn the window on an access-denied loop.

The console goes blind on VPC domains

The second surprise is operational rather than technical. AWS documents that for VPC domains "the index list can't be displayed in the console due to VPC network restrictions." Because you cannot see your indexes, you also cannot update a semantic enrichment index from the console. The guide sends you to OpenSearch Dashboards for viewing and to the update-index API for changes.

That matters for run-book design. On a public-access domain a search engineer can inspect and adjust enrichment fields in the AWS console. On a VPC domain the same work is CLI-only or Dashboards-only, and any internal procedure written against the console screens will not survive the move.

The guide contradicts itself on existing indexes

The introduction to the feature says: "To enable it for an existing index, you need to recreate the index with automatic semantic enrichment enabled for text fields."

Four sections later, under "Update an existing index," the same page says you can "add new semantic enrichment fields, enable or disable semantic enrichment on existing fields, or add non-semantic text fields" through update-index, and that the service then sets up the required ML model, ingest pipeline and search pipeline automatically.

Both statements are live on the same page. The reconciliation appears in the fine print, and it is the part that costs money: "Existing documents are not backfilled. To populate the semantic enrichment field on existing documents, you must re-index." So the mapping change is cheap, and the data is not. A separate note adds that index settings cannot be updated at all — include a settings block in an update-index request and it returns a validation error, and changing settings still means delete and recreate.

Plan the re-index, not the schema edit. The real cost is usually the migration, not the API call.

What it costs

Billing is by OpenSearch Compute Unit consumed during sparse vector generation at indexing time only. AWS states there are no additional Semantic Search OCU charges during search operations or for data storage, and publishes the conversion: one Semantic Search OCU processes 11.1 million tokens of English content, so 2.4 billion tokens needs roughly 216 OCU-hours, and 10 GB of data costs about $51 at the US East rate.

Region	Price per Semantic Search OCU-hour	Cost of 216 OCU-hours (10 GB example)
US East (N. Virginia), US East (Ohio), US West (Oregon)	$0.24	$51.84
Europe (Stockholm)	$0.25	$54.00
Europe (Spain)	$0.26	$56.16
EU (Ireland)	$0.27	$58.32
Asia Pacific (Mumbai)	$0.29	$62.64
EU (Frankfurt)	$0.30	$64.80
Asia Pacific (Singapore, Sydney, Tokyo)	$0.31	$66.96

Rates read from the AWS Price List API AmazonES offer file, version 20260709090858, published 9 July 2026. Mumbai runs 20.8% above N. Virginia; Tokyo, Singapore and Sydney run 29.2% above. For an Indian team indexing a large catalogue, that is a real number: the same 2.4 billion tokens costs about ₹5,500 more in Mumbai than in Ohio at ₹88 to the dollar, before any consideration of where the data is allowed to sit under the Digital Personal Data Protection Act 2023.

Monitor consumption with the CloudWatch metric SemanticSearchOCU.

The limits that decide whether it works for you

Constraint	Value	Why it bites
English token cap	First 8,192 tokens per document	Long articles need chunking or the tail is never encoded
Multilingual token cap	First 512 tokens per document	Sixteen times smaller; Hindi, Arabic and Japanese corpora are truncated hard
Indexing inference throttle	200 TPS, soft limit	Bulk backfills queue; raise it with AWS Support before a migration
Minimum engine version	2.19 or later, plus latest service software	An un-patched 2.19 domain is not eligible
Query rewrite coverage	`match` only; `multi_match` unsupported	Applications built on `multi_match` get no semantic behaviour
Derived Source	Not compatible	Storage-optimised domains must choose one or the other

The 512-token multilingual cap is the one most likely to be missed. AWS lists Arabic, Bengali, Chinese, Finnish, French, Hindi, Indonesian, Japanese, Korean, Persian, Russian, Spanish, Swahili and Telugu alongside English, and the relevance gain on multilingual content is the largest number on the page at 105%. It applies to the first 512 tokens of each document and nothing after that.

On query rewriting, the feature converts match queries to neural sparse queries without application changes, including match clauses nested inside bool, boosting, constant_score, dis_max, function_score and hybrid compound queries. multi_match is not rewritten. A search layer that leans on multi_match will index at OCU cost and then query lexically, paying for enrichment it never uses.

The 12 August 2026 permissions fork

There is one more dated split worth checking before you file a ticket. Domains created on or after 12 August 2026 ship with a predefined fine-grained access control role, automatic_semantic_enrichment_full_access, and you map your user or backend role to it. Domains created before that date do not have the role, and an administrator must grant the individual permissions by hand: indices:admin/create, indices:admin/mapping/put, cluster:admin/opensearch/ml/create_connector, cluster:admin/opensearch/ml/register_model, cluster:admin/ingest/pipeline/put and cluster:admin/search/pipeline/put for index creation, with indices:admin/settings/update and the two pipeline get permissions added for updates.

Most production domains predate 12 August 2026, so most teams are on the manual path.

India-specific considerations

Asia Pacific (Mumbai) is in the launch set, which means a semantic search index can stay inside India rather than moving text to Ohio for encoding. For any application handling personal data under the Digital Personal Data Protection Act 2023, that is the point of using a VPC domain in the first place, and it is worth confirming that the encoding stays in-Region before enabling the feature on a customer-facing corpus. The premium for keeping it in Mumbai is $0.05 per OCU-hour over N. Virginia.

What is still unknown

AWS has not published whether the sparse model version is pinned per domain or rolled forward by the service, which matters because a model change alters stored sparse vectors and therefore ranking. The guide also does not state the index size increase from semantic enrichment in percentage terms — it only warns that enrichment "significantly increases index size" and advises against it for log analysis. Until AWS quantifies that, storage impact has to be measured on your own corpus in a development domain.

FAQ

Do I need to change my VPC configuration to use automatic semantic enrichment?

The What's New post says no changes to existing VPC configurations are required. The service guide adds a step the announcement omits: you must authorize the principal features.opensearchservice.amazonaws.com through the AuthorizeVpcEndpointAccess API once per domain, or every semantic enrichment index operation fails with AccessDeniedException.

What does automatic semantic enrichment cost?

AWS bills OpenSearch Compute Units consumed during sparse vector generation at indexing time only, with no charge for search operations or storage. One Semantic Search OCU processes 11.1 million tokens of English content. The rate is $0.24 per OCU-hour in US East (N. Virginia) and $0.29 in Asia Pacific (Mumbai).

Can I enable semantic enrichment on an index that already has data?

You can add a semantic enrichment field to an existing index with the update-index API, and the service creates the model and pipelines for you. Existing documents are not backfilled, so populating the new field on old data requires a re-index. Index settings cannot be changed by update-index at all.

How much text does the model actually read?

The sparse model processes the first 8,192 tokens of each English document. For multilingual documents the limit is 512 tokens. AWS recommends chunking long documents so the whole body is encoded, because anything past those caps is never turned into sparse vectors and never becomes searchable semantically.

Which OpenSearch version do I need?

Domains must run OpenSearch version 2.19 or later. Domains on 2.19 specifically also need the latest service software version update applied. AWS lists availability in 11 Regions: three in the United States, four in Asia Pacific and four in Europe, covering both public-access and VPC-enabled domains.

Will my existing queries pick up semantic search automatically?

Match queries are rewritten to neural sparse queries without application changes, including match clauses nested inside bool, boosting, constant_score, dis_max, function_score and hybrid compound queries. Multi_match queries are not supported and are not rewritten, so applications built on multi_match keep behaving lexically while still paying indexing cost.

Does the multilingual model perform better than lexical search?

AWS reports a 105% relevance improvement on multilingual content against lexical search, measured as average ndcg@10 on MIRACL. The trade is latency: p90 search latency rises from 26 ms for BM25 to 36 ms, an increase of 38.4%. English content shows a 20% relevance gain and slightly lower latency at 24 ms.

What changed for domains created before 12 August 2026?

Domains created on or after 12 August 2026 include a predefined fine-grained access control role named automatic_semantic_enrichment_full_access. Older domains do not, so an administrator must grant the individual cluster and index permissions manually, including ml/create_connector, ml/register_model and both the ingest and search pipeline put permissions.

How eCorpIT can help

Search migrations fail on the parts that are not in the announcement: the re-index window, the permissions fork, and the Region where the encoding happens. eCorpIT's senior engineering teams run OpenSearch and vector-search workloads for Indian and global customers, and we size the OCU cost and the re-index before anything is switched on. If you are weighing this against a dedicated vector store, our comparison of DynamoDB vector search against pgvector and OpenSearch covers the cost model, and the pgvector versus dedicated vector database decision covers the architecture. For a wider view of AWS spend, see our guide to cloud FinOps for Indian teams. Talk to us through /contact-us/.