Building Search Infrastructure with Next-Gen OpenSearch Serverless — Custom Construction, Migration, and Operation Support 2026

In AWS Releases Next Generation of Amazon OpenSearch Serverless (2026-06-08), InfoQ covered how the next generation of Amazon OpenSearch Serverless has reached general availability (GA), delivering resource provisioning approximately 20 times faster than before thanks to a redesigned architecture. OpenSearch Serverless offers OpenSearch—a search and analytics engine—in a serverless format usable without worrying about cluster capacity management, scaling, or patching, and this revamp further reinforces its ability to spin up rapidly whenever needed. Through purpose-specific collections, it covers everything from full-text site search and time-series analysis of logs and observability data to vector search powering RAG and semantic search.

In the field of custom system development, teams have repeatedly suffered setbacks where they "set up in-house Elasticsearch / OpenSearch clusters for search features, only to take on capacity planning, scaling, patch tracking, and incident handling, letting operational burdens pile up." From our position supporting infrastructure in custom development, we view this not as a matter of "whether we can use the latest managed service," but as a design challenge of "whether we can shed the burden of in-house cluster operations, choose collections suited to the use case, and hand off infrastructure—including Japanese full-text search and vector search—in a state ready for migration and ongoing maintenance." Connecting with the infrastructure selection criteria covered in Cloudflare vs AWS Infrastructure Selection (GH Media) and the configuration codification policies covered in IaC Standardization with CDK / Terraform (GH Media), this article outlines our "search infrastructure (OpenSearch Serverless) construction and migration support" as a custom development package.

Why shift search infrastructure to serverless now

In short, "operating clusters in-house" and "delivering a reliable search experience" are two entirely different things. Even in custom development, "shifting operational overhead to managed services, selecting purpose-specific collections, and designing the migration for handover" has become a baseline requirement for quality. Provisioning that is approximately 20 times faster in the next-generation edition simplifies standing up staging environments and tracking temporary demand spikes, fundamentally lowering the barrier to owning search infrastructure.

What you can do with OpenSearch Serverless

1. Full-text search collections (site search / product search)

This is the standard collection used for high-speed full-text searching of documents, such as site search or product catalog search. For projects handling Japanese text, designing morphological analysis via Japanese analyzers such as kuromoji alongside a synonym dictionary to absorb wording variations dictates search accuracy. Below is an example of a minimal search query.

{
  "query": {
    "match": {
      "body": {
        "query": "受託 検索基盤",
        "analyzer": "kuromoji"
      }
    }
  }
}

2. Time-series and log analytics collections

This collection is designed to ingest time-series data—such as application logs, access logs, and metrics—and analyze it on observability dashboards. Used as a foundation for operational monitoring and incident investigation, it scales automatically with fluctuating log volumes without capacity concerns. For designs combined with SRE operations, please also read Slack ChatOps × AI Infrastructure Operations (GH Media).

3. Vector search collections (semantic search / RAG)

This collection stores embedding vectors and serves as the search layer for semantic search based on semantic proximity and RAG, where generative AI references internal documents. While it can surface "results close to intent" that keyword matching misses, choosing embedding models and designing indexes are prerequisites, making it an ironclad rule to adopt it only for projects that genuinely require it.

Five phases of "search infrastructure (OpenSearch Serverless) construction and migration support" provided in custom development

Phase 1: Requirements & current search inventory (1–2 weeks)

• Auditing existing search and log analytics methods (DB LIKE queries / in-house clusters / external SaaS)
• Organizing target data volume, update frequency, and expected queries
• Reviewing Japanese language requirements (morphological analysis, synonyms) and security requirements
• Deliverables: Current search inventory sheet + serverless suitability report

Phase 2: Design (1–2 weeks)

• Categorizing collection types (full-text search / time-series logs / vector)
• Determining index design, analyzers/synonym dictionaries, and access control/encryption policies
• Estimating costs based on OCU billing and designing budget cap policies
• Deliverables: Architecture design document + index design document + cost estimate

Phase 3: Implementation & migration (2–4 weeks)

• Building collections and data access policies via IaC
• Designing reindexing for existing data and executing migration with minimal downtime
• Implementing application-side search clients and switching connections
• Deliverables: Constructed search infrastructure + migration runbook + configuration code

Phase 4: Verification & handover (1–2 weeks)

• Verifying search precision (Japanese/synonyms), latency, and behavior under load
• Confirming configurations for access control, encryption, and audit logging
• Deliverables: Verification report + operation/maintenance runbook

Phase 5: Continuous maintenance (ongoing)

• Regular monitoring of OCU usage and costs
• Improving synonym dictionaries, analyzers, and indexes
• Additional implementation of new search requirements and vector search

Standard configuration sets for custom development

Which projects need this and which do not

When search requirements are modest, such as internal search for static sites, solutions like Pagefind that generate search indexes at build time may be fully sufficient. For perspectives on display performance and search UX, Core Web Vitals Improvement Guide (GH Media) is also a helpful reference.

Six clauses to include in custom development contracts

Client ROI estimates (assuming migration from in-house cluster operations)

Even an assessment alone (from 400,000 yen) provides value by visualizing how much operational overhead and cost can be reduced by moving current search to serverless. The maintenance costs of in-house clusters typically take a steady toll over several years in the form of capacity pinches and patch tracking.

Five common pitfalls to avoid

Pitfall 1: Failing to configure Japanese analyzers

Default analysis will fail to deliver acceptable Japanese search accuracy. Incorporate morphological analysis such as kuromoji and synonym dictionaries during the design stage.

Pitfall 2: Naive OCU billing estimates

Operating pay-as-you-go billing without monitoring will cause costs to balloon. Design OCU limits and usage monitoring from the very start.

Pitfall 3: Insufficient reindexing planning

Underestimating data rebuilding during migration will prolong downtime. Design reindexing strategies and cutover procedures in advance.

Pitfall 4: Overlooking access control and encryption configurations

Postponing data access policies and encryption introduces data breach risks. Finalize access control, encryption, and audit logging during initial setup.

Pitfall 5: Excessive reliance on vector search

Vectorizing all records without clear requirements only increases cost and complexity. Scope adoption strictly to where semantic search is genuinely required.

90-day action plan

Conclusion — from operating clusters to handing off infrastructure

With the next generation of OpenSearch Serverless reaching GA and provisioning approximately 20 times faster than before, the model for maintaining search infrastructure is shifting from "operating in-house clusters" to "spinning up and using serverless environments quickly." From our position supporting infrastructure in custom development, our "search infrastructure (OpenSearch Serverless) construction and migration support"—where we shift operational overhead to managed services, select purpose-specific collections, and deliver the system complete with Japanese analysis and migration—is our primary service for delivering results that cut operational hours and improve search experiences. If you also want to standardize configuration codification, please read IaC Standardization with CDK / Terraform (GH Media).

If you are looking to break away from in-house cluster operations, improve site search accuracy, or build search infrastructure for RAG and log analytics, please feel free to reach out via our contact form.

Sources

• AWS Releases Next Generation of Amazon OpenSearch Serverless（InfoQ 2026-06-08）
• Cloudflare vs AWS Infrastructure Selection (GH Media)
• IaC Standardization with CDK / Terraform (GH Media)
• Slack ChatOps × AI Infrastructure Operations (GH Media)
• Core Web Vitals Improvement Guide (GH Media)