Amazon OpenSearch Serverless is an on-demand, auto-scaling configuration for Amazon OpenSearch Service. OpenSearch Serverless permits a broad set of use instances, corresponding to real-time utility monitoring, log analytics, and web site search. OpenSearch Serverless allows you to use OpenSearch with out having to fret about scaling and managing an OpenSearch cluster. A group may be accessed over the general public web or out of your VPC. As you begin accessing OpenSearch Serverless from completely different VPCs and accounts or from on premises, your connectivity patterns might change. On this submit, we cowl connectivity patterns and Area Title System (DNS) decision on your OpenSearch Serverless assortment—whether or not accessed over the web, inside the VPC, inside AWS, or out of your on-premises location.
Foundational ideas
The next foundational ideas will show you how to higher perceive OpenSearch Serverless and DNS decision.
Community entry coverage
The community entry coverage for OpenSearch Serverless determines whether or not the gathering may be accessed over the web or solely by means of OpenSearch Serverless managed VPC endpoints. A single coverage may be hooked up to a number of collections.
OpenSearch Serverless VPC endpoint
To entry OpenSearch Serverless collections and dashboards privately from a VPC with out utilizing an web gateway, you’ll be able to create a VPC interface endpoint. Once you create a VPC endpoint, it creates an elastic community interface (ENI) in every subnet that you just allow for the VPC endpoint. These are requester-managed ENIs that function the entry level for visitors destined for the OpenSearch Serverless assortment. Once you create an OpenSearch Serverless VPC endpoint, the non-public DNS title choice is enabled by default. Because of this OpenSearch Serverless additionally creates an Amazon Route 53 non-public hosted zone and associates that with the VPC the place the endpoint is created. This non-public hosted zone has a wildcard DNS document *.<area>.aoss.amazonaws.com pointing to the non-public DNS of the endpoint.
You create an OpenSearch Serverless VPC endpoint by way of the OpenSearch Serverless console or the OpenSearch Serverless API. You may’t create an OpenSearch Serverless VPC endpoint from the Amazon Digital Non-public Cloud (Amazon VPC) console, though as soon as created, you’ll be able to see them on the VPC console as effectively.
Amazon Route 53 Resolver
Let’s perceive what Amazon Route 53 Resolver does when an Amazon Elastic Compute Cloud (Amazon EC2) occasion queries a DNS title. DNS queries originating from the VPC go to the Route 53 Resolver on the VPC+2 IP handle. When a DNS question reaches the resolver, it checks if there are any Route 53 ahead guidelines. If it matches, then it forwards the question to the DNS server supplied by that rule. If the question stays unresolved, Route 53 Resolver proceeds to verify the non-public hosted zones related to the originating VPC. If it nonetheless stays unresolved, then it checks for VPC DNS, which helps to resolve EC2 DNS names. Lastly, if the question nonetheless isn’t resolved, Route 53 Resolver checks the general public DNS. The next diagram illustrates this order or operations.
Route 53 Resolver inbound endpoints
Workloads using assets each in a VPC and on premises must resolve DNS information hosted on-premises and assets hosted within the VPC. With Route 53 Resolver inbound endpoints, you’ll be able to resolve DNS queries to your VPC out of your on-premises community or one other VPC.
Within the following sections, we offer an outline of connectivity patterns and DNS decision.
Entry an OpenSearch Serverless assortment from Amazon EC2 (by way of web gateway)
The next determine demonstrates the connectivity sample to entry an OpenSearch Serverless assortment over the web. The gathering has an entry kind set to public, which permits licensed customers to hook up with the gathering over the web. An EC2 occasion inside the VPC can set up a connection to the gathering by way of the web gateway, and customers exterior the VPC may also entry this assortment over the web.
The workflow has the next steps, as indicated within the previous diagram:
A. The EC2 occasion performs a DNS lookup to Route 53 Resolver at a VPC+2 IP handle. Route 53 Resolver returns the general public IP addresses of the OpenSearch Serverless assortment.
B. The EC2 occasion sends a knowledge request by way of an web gateway to the OpenSearch Serverless assortment utilizing this public IP handle.
C. An exterior shopper resolves to the general public IP addresses of the OpenSearch Serverless assortment and reaches it by way of the web.
Now let’s carry out a dig command for the gathering or dashboard URL from the EC2 occasion, and we observe that it’s resolving to a public IP handle.
The next command makes use of an OpenSearch Serverless assortment:
The next command makes use of an OpenSearch dashboard:
Now that you’ve got applied an OpenSearch Serverless assortment with a community entry coverage as public, you can also make the identical assortment accessible privately inside the VPC. To attain this, full the next steps:
- Modify the community entry coverage of the gathering and alter the entry kind to VPC.
- Choose the choice Create VPC endpoints.
- Select the VPC and at the least two subnets the place you wish to have a VPC endpoint ENI for prime availability.
- Select Affirm to create the VPC endpoint.
- Lastly, choose the VPC endpoint and replace the coverage.
With the creation of the VPC endpoint, a Route 53 non-public hosted zone can be created inside your account and related along with your VPC. On this setup, a CNAME document *.us-east-1.aoss.amazonaws.com is created to direct to the Regional AWS PrivateLink endpoint, as depicted within the following screenshot.
As a result of non-public hosted zone related to the VPC, Route 53 Resolver provides choice to the non-public hosted zone to resolve any DNS question originating from the VPC. DNS requests for the OpenSearch Serverless assortment originating from the EC2 occasion get resolved utilizing this related non-public hosted zone and resolve to the non-public IP addresses of the VPC endpoint, which permits Amazon EC2 to hook up with the serverless assortment by way of VPC endpoints vs. the web gateway. We broaden on this within the following part.
Entry an OpenSearch Serverless assortment from Amazon EC2 (by way of interface VPC endpoints)
The next determine demonstrates the connectivity sample to entry an OpenSearch Serverless assortment privately from the VPC. The gathering has an entry kind set to VPC endpoint, proscribing entry solely from the assets inside the VPC by way of the VPC endpoint and stopping exterior customers from connecting. With the creation of the VPC endpoint, a non-public hosted zone can be related to this VPC. An EC2 occasion inside the VPC can set up a reference to the gathering utilizing the VPC endpoint, however assets exterior of the VPC don’t have entry to this assortment due to the community entry coverage.
The workflow consists of the next steps:
A. The EC2 occasion performs a DNS lookup to Route 53 Resolver at a VPC+2 IP handle. Route 53 Resolver returns the non-public IP addresses of the VPC endpoint as a result of there’s a non-public hosted zone related to the VPC containing a CNAME document.
B. The EC2 occasion sends a knowledge request by way of the VPC interface endpoint to the OpenSearch Serverless assortment.
C. An exterior shopper resolves to the general public IP addresses of the OpenSearch Serverless assortment however is unable to succeed in it as a result of the community coverage restricts to the VPC.
Now let’s carry out a dig command for the gathering or dashboard URL from the EC2 occasion, and we observe that it’s resolving to the non-public IP addresses belonging to the VPC endpoints.
Use the next code for an OpenSearch Serverless assortment:
Use the next code for an OpenSearch dashboard:
Entry an OpenSearch Serverless assortment from many VPCs (by way of interface VPC endpoints) with a VPC endpoint in every VPC
The next determine demonstrates the connectivity sample to make use of the identical VPC endpoint to hook up with a number of OpenSearch Serverless collections. On this situation, a VPC endpoint is created in every VPC to allow EC2 situations inside the VPCs to make the most of the VPC endpoint because the connectivity path to OpenSearch Serverless. A non-public hosted zone is auto generated for every endpoint and related to the corresponding VPC. Community insurance policies of OpenSearch Serverless collections are up to date to permit each VPC Endpoint-1 and VPC Endpoint-2, which permits the EC2 occasion in VPC-1 to entry each collections by way of VPC Endpoint-1 and EC2 situations in VPC-2 to entry each collections by way of VPC Endpoint-2.
The workflow consists of the next steps:
A. The EC2 occasion performs a DNS lookup to Route 53 Resolver at a VPC+2 IP handle. Route 53 Resolver returns the non-public IP addresses of the VPC endpoint (the EC2 occasion in VPC-1 will get the IP handle of VPC Endpoint-1 and the EC2 occasion in VPC-2 will get the IP handle of VPC Endpoint-2), as a result of there’s a non-public hosted zone related to every of the VPCs containing a CNAME document.
B. The EC2 occasion sends a knowledge request by way of the VPC interface endpoint to the OpenSearch Serverless assortment.
Entry an OpenSearch Serverless assortment from many VPCs (by way of interface VPC endpoints) with a VPC endpoint in a centralized VPC
Within the earlier connectivity sample, we had one endpoint in every VPC by means of which VPC assets accessed OpenSearch Serverless collections. Many organizations wish to keep management of those endpoints and hold these in a centralized VPC.
The next determine demonstrates the connectivity sample to make use of a centralized VPC endpoint to hook up with a number of OpenSearch Serverless collections from a number of VPCs. On this situation, a VPC interface endpoint is created in a centralized VPC. A non-public hosted zone is auto generated for this VPC endpoint and related to the centralized VPC, after which manually related with VPC-1 and VPC-2. The DNS question for OpenSearch Serverless collections from VPC-1 and VPC-2 will get resolved to the centralized VPC endpoint because of the non-public hosted zone affiliation. Community insurance policies for each collections permit entry from the centralized VPC endpoint solely. All three VPCs (centralized, VPC-1, and VPC-2) are related by way of AWS Transit Gateway and route tables have routes to direct visitors between VPC-1 and VPC-2 to the centralized VPC and vice versa.
The workflow consists of the next steps:
A. The EC2 occasion performs a DNS lookup to Route 53 Resolver at a VPC+2 IP handle. Route 53 Resolver returns the non-public IP addresses of the centralized VPC endpoint, as a result of there’s a non-public hosted zone related to every VPC containing a CNAME document.
B. The EC2 occasion sends a knowledge request to the Transit Gateway ENI in its personal VPC. The Transit Gateway route desk is checked and the information request is forwarded to the Transit Gateway ENI within the centralized VPC. The Transit Gateway ENI within the centralized VPC sends it to the OpenSearch Serverless assortment by way of the VPC interface endpoint.
Entry an OpenSearch Serverless assortment from on premises (by way of AWS Website-to-Website VPN or AWS Direct Join)
The next determine demonstrates the connectivity sample for accessing OpenSearch Serverless collections from on premises. You should utilize both AWS Direct Join or AWS Website-to-Website VPN to ascertain connectivity between on-premises and AWS assets. Within the following instance, Direct Join is used for the connectivity between AWS and on premises. An OpenSearch Serverless VPC endpoint is created within the VPC, and a non-public hosted zone is routinely generated and related to this VPC. The community coverage of the OpenSearch Serverless assortment is up to date to permit connectivity solely from the VPC endpoint.
To entry these OpenSearch Serverless collections privately from the on-premises surroundings, assets must resolve the OpenSearch Serverless assortment DNS to the OpenSearch Serverless VPC endpoint IP handle. By default, OpenSearch Serverless DNS resolves to the general public IP addresses and makes an attempt to entry OpenSearch Serverless by way of the web. To make sure that OpenSearch Serverless is accessed by way of the VPC endpoint from on premises, it’s essential to make sure that DNS queries are resolved to a VPC endpoint’s non-public IP handle. Assets contained in the VPC use Route 53 Resolver, obtainable at a VPC+2 IP handle, to resolve these queries to the VPC endpoint. Route 53 Resolver checks the related non-public hosted zone to resolve the question to the VPC endpoint. Nonetheless, the VPC+2 IP handle will not be accessible from on premises. To handle this, you’ll be able to make the most of the Route 53 Resolver inbound endpoint.
To attain this, you’ll be able to create an inbound endpoint in your VPC by following the steps outlined in Configuring inbound forwarding, after which replace the on-premises DNS server to ahead all of the DNS requests for *.<area>.aoss.amazonaws.com to the IP handle of the Route 53 Resolver inbound endpoint. When the on-premises shopper obtains the IP handle of the VPC endpoint, it will probably use Direct Join or Website-to-Website VPN to ascertain a non-public connection to the OpenSearch Serverless assortment.
The workflow accommodates the next steps:
A. The on-premises shopper sends a DNS lookup to the on-premises DNS resolver. The on-premises DNS resolver forwards this request to the Route 53 Resolver inbound endpoint. The Route 53 Resolver inbound endpoint sends a DNS lookup to Route 53 Resolver at a VPC+2 IP handle. Route 53 Resolver returns the non-public IP addresses of the VPC endpoint, as a result of there’s a non-public hosted zone related to this VPC containing a CNAME document.
B. The on-premises shopper sends a knowledge request to the OpenSearch Serverless assortment, which routes by way of Direct Join or Website-to-site VPN to the VPC interface endpoint and eventually to the OpenSearch Serverless assortment.
Conclusion
On this submit, we confirmed you varied connectivity patterns for OpenSearch Serverless. We lined using hybrid DNS and utilizing a Route 53 Resolver inbound endpoint to permit connectivity from on premises for OpenSearch Serverless. You may select from varied centralization fashions for reaching a number of OpenSearch Serverless collections inside the AWS Cloud or from on-premises places. Get began in the present day by connecting to OpenSearch Serverless from the assorted community patterns we mentioned.
Concerning the authors
Salman Ahmed is a Sr. Technical Account Supervisor in AWS Enterprise Assist. He enjoys working with Enterprise Assist clients to assist them with design, implementation and supporting cloud infrastructure. He additionally has a ardour for networking companies and with 12+ years of expertise, he leverages that to assist clients with adoption of AWS Transit Gateway, AWS Direct Join and varied different AWS networking companies.
Ankush Goyal is Enterprise Assist Lead in AWS Enterprise Assist who helps enterprise assist clients streamline their cloud operations on AWS. He’s a results-driven IT skilled with over 18 years of expertise.
Rohit Aswani is a Senior Specialist Options Architect focussed on Networking at AWS, the place he helps clients construct and design scalable, highly-available, safe, resilient and value efficient networks. He holds a MS in Telecommunication Programs Administration from Northeastern College, specializing in Pc Networking. In his spare time, Rohit enjoys mountain climbing, touring and exploring new espresso locations.
