← Back to all announcements
★★☆☆☆ 07/05/2026

Amazon OpenSearch Service now supports VPC egress for private connectivity to resources in your VPC

Keep your OpenSearch data private by routing outbound connections directly through your VPC instead of the public internet.

View original announcement →

What's New

Amazon OpenSearch Service has introduced a VPC egress option that enables VPC-based OpenSearch domains to establish private outbound network connections to resources within a customer's VPC — including ML models, AWS services, and custom applications — without routing traffic over the public internet. This feature is configurable via the AWS Management Console, AWS CLI, and the CreateDomain and UpdateDomainConfig API operations. It is available globally across all AWS Regions where Amazon OpenSearch Service is offered.

How It Works

  • When VPC egress is enabled on an OpenSearch Service domain, the service provisions elastic network interfaces (ENIs) directly into the subnets associated with the domain.
  • These ENIs serve as the egress path for outbound traffic originating from the OpenSearch domain, routing it into the customer's VPC rather than through the public internet.
  • This means that any outbound calls — such as those made during ML inference pipelines, connector-based integrations with external services, or custom plugin callbacks — traverse the private VPC network fabric.
  • Customers can apply standard VPC constructs such as security groups, network ACLs, VPC endpoints, and route tables to control and inspect this egress traffic.
  • The feature can be toggled on or off dynamically using the UpdateDomainConfig API, allowing for flexible configuration without requiring domain recreation.

Why It's Important

  • Prior to this feature, OpenSearch Service domains deployed within a VPC could receive traffic privately, but outbound calls from the domain (e.g., to remote ML model endpoints or external data sources via connectors) could potentially traverse the public internet, introducing security and compliance risks.
  • VPC egress closes this gap by ensuring end-to-end private connectivity for both ingress and egress traffic, which is critical for organizations operating under strict data residency, regulatory, or zero-trust network security requirements.
  • This is particularly significant for AI/ML workloads where OpenSearch's neural search and semantic search capabilities rely on calling external model inference endpoints — now those calls can remain entirely within the private network boundary.

How It's Different

  • Previously, OpenSearch Service VPC domains were "VPC-ingress only" in practice — traffic into the domain was private, but outbound traffic from the domain to external resources (such as SageMaker inference endpoints, custom HTTP connectors, or third-party services) would exit through AWS-managed infrastructure without guaranteed private routing through the customer's VPC.
  • Customers had limited ability to apply their own network controls (security groups, NACLs, VPC flow logs) to this egress traffic.
  • The new VPC egress option fundamentally changes this by injecting ENIs into customer-managed subnets, giving customers full visibility and control over outbound traffic using native VPC tooling — a capability that was not previously available for OpenSearch Service domains.

When to Prefer It

  • VPC egress should be enabled whenever an OpenSearch domain needs to make outbound calls to resources that are accessible only within a private network, such as SageMaker endpoints deployed in a VPC, Amazon Bedrock VPC endpoints, internal microservices, or on-premises systems connected via AWS Direct Connect or VPN.
  • It is especially important in regulated industries (finance, healthcare, government) where data must not traverse the public internet and where network traffic must be auditable via VPC Flow Logs.
  • Teams building semantic search, RAG (Retrieval-Augmented Generation) pipelines, or ML-augmented search using OpenSearch's connector framework should enable VPC egress to ensure that model inference calls remain private.
  • If your OpenSearch domain operates in isolation without any outbound connectivity requirements, the feature is optional but still recommended as a defense-in-depth measure.

Availability

  • VPC egress for Amazon OpenSearch Service is generally available (GA) as of May 7, 2026, and is supported in all AWS Regions where Amazon OpenSearch Service is available.
  • The feature applies specifically to VPC-based OpenSearch domains; public-access domains are not applicable.
  • Configuration is supported through the AWS Console, AWS CLI, and the CreateDomain / UpdateDomainConfig API operations, allowing both new domain creation and updates to existing domains.
  • Customers should ensure that the subnets selected for the domain have sufficient available IP addresses to accommodate the additional ENIs provisioned by the service.
  • Refer to the AWS documentation on "Routing domain egress traffic through your VPC" for detailed setup guidance and subnet sizing considerations.

Tags

Servicesopensearch
Typenew-feature
Conceptssearch
Use Casesenterprise
GeographyGlobal

AI Radar AWS

AWS AI/ML news — curated, researched, explained

An automated intelligence platform that curates, researches, and analyzes AWS AI/ML/GenAI announcements daily. Every report is backed by real research — the system reads linked blog posts and documentation to provide accurate, in-depth analysis.

How Each Report Is Generated

  1. Collection — Daily monitoring of the AWS "What's New" RSS feed
  2. Filtering — AI-powered relevance detection for AI/ML/GenAI topics
  3. Taxonomy Tagging — LLM-based classification across 6 dimensions
  4. Importance Scoring — Point-based system with tag bonuses (1-5 stars)
  5. Research Phase — Follows links to blog posts and documentation
  6. Report Generation — Claude Sonnet produces structured 6-section analysis
  7. Visual Summary — Claude Opus generates Mermaid diagrams for key items
  8. Publishing — Static website rebuilt and deployed via CloudFront

Features

  • Faceted filtering by service, type, concept, and more
  • Multi-dimensional taxonomy with 80+ tags across 6 dimensions
  • Geographic availability badges (Global, APJ, EMEA, AMER) with filtering
  • Timeline visualization of announcement volume
  • PDF export for offline reading
  • Mermaid visual summaries for key announcements
  • Daily automated updates — no manual curation
What makes this different: Each report involves a dedicated research phase where the system reads linked blog posts and AWS documentation pages. This produces analysis that goes beyond the original announcement text.

Technology

Built with Python, AWS Lambda, Amazon Bedrock (Claude Sonnet 4.6, Opus 4.6, Haiku 4.5), S3, CloudFront, WAF, EventBridge, and CDK.

Open Source

This project is open source. Fork it, customize it for your needs, and deploy your own instance.
📦 github.com/bbonik/ai-radar-aws

How Importance Scoring Works

Each announcement receives a point score based on multiple factors. The total score maps to a 1-5 star rating:

1★ < 2 pts 2★ ≥ 2 pts 3★ ≥ 3.5 pts 4★ ≥ 5 pts 5★ ≥ 6.5 pts

Point Breakdown

FactorPointsWhen
Core AI service (Bedrock, AgentCore, SageMaker AI)+4Service named in title
Key AI service (SageMaker, Kiro, QuickSight)+2Service named in title
Other AI-related service+1Default
Blog post link+3Link to aws.amazon.com/blogs/
GitHub samples link+2Link to github.com/aws*
Documentation link+1Link to docs.aws.amazon.com/
New model+1.5Tagged as "new-model"
New service+1Tagged as "new-service"
New feature+0.5Tagged as "new-feature"
Anthropic / OpenAI provider+2Provider explicitly mentioned
Instance / notebook announcement-2Hardware/capacity, not feature
Performance / pricing / security-0.5Incremental updates
Region expansion to APJ+1Expands to Asia Pacific
Region expansion (non-APJ only)-1.5Only expands to other regions

Geographic Relevance Badges

Each announcement card shows a small badge indicating whether the feature is available in your region:

🌐 Global Available in all regions
🌏 APJ Asia Pacific
🌍 EMEA Europe / Middle East / Africa
🌎 AMER Americas (US, Canada, South America)
No badge Geography unknown
How geography is detected: The system detects ALL geographies mentioned in each announcement. If the text mentions specific regions (Tokyo, Frankfurt, Oregon, etc.), the corresponding geography badges are shown. If it says "all regions" or is a new feature with no region specified, it gets the Global badge. Geography is also filterable — click a geo chip to see only announcements available in that region.