Quickstart: Create an Azure Search service in the portal
Azure Search is a standalone resource used to plug in a search experience in custom apps. Although Azure Search integrates easily with other Azure services, you can also use it as a standalone component, or integrate it with apps on network servers, or with software running on other cloud platforms.
In this article, learn how to create an Azure Search resource in the Azure portal.
Subscribe (free or paid)
Open a free Azure account and use free credits to try out paid Azure services. After credits are used up, keep the account and continue to use free Azure services, such as Websites. Your credit card is never charged unless you explicitly change your settings and ask to be charged.
Alternatively, activate MSDN subscriber benefits. An MSDN subscription gives you credits every month you can use for paid Azure services.
Find Azure Search
- Sign in to the Azure portal.
- Click the plus sign ("+ Create Resource") in the top-left corner.
- Use the search bar to find "Azure Search" or navigate to the resource through Web > Azure Search.
Select a subscription
If you have more than one subscription, choose one that also has data or file storage services. Azure Search can autodetect Azure Table and Blob storage, SQL Database, and Azure Cosmos DB for indexing via indexers, but only for services under the same subscription.
Set a resource group
A resource group is required and is useful for managing resources all-up, including cost management. A resource group can consist of one service, or multiple services used together. For example, if you are using Azure Search to index an Azure Cosmos DB database, you could make both services part of the same resource group for management purposes.
If you aren't combining resources into a single group, or if existing resource groups are filled with resources used in unrelated solutions, create a new resource group just for your Azure Search resource.
As you use the service, you can track current and projected costs all-up (as shown in the screenshot) or scroll down to view charges for individual resources.
Deleting a resource group also deletes the services within it. For prototype projects utilizing multiple services, putting all of them in the same resource group makes cleanup easier after the project is over.
Name the service
In Instance Details, provide a service name in the URL field. The name is part of the URL endpoint against which API calls are issued:
https://your-service-name.search.windows.net. For example, if you want the endpoint to be
https://myservice.search.windows.net, you would enter
Service name requirements:
- It must be unique within the search.windows.net namespace
- 2 and 60 characters in length
- Use lowercase letters, digits, or dashes ("-")
- Avoid dashes ("-") in the first 2 characters or as the last single character
- No consecutive dashes ("--") anywhere
If you think you'll be using multiple services, we recommend including the region (or location) in the service name as a naming convention. Services within the same region can exchange data at no charge, so if Azure Search is in West US, and you have other services also in West US, a name like
mysearchservice-westus can save you a trip to the properties page when deciding how to combine or attach resources.
Choose a location
As an Azure service, Azure Search can be hosted in datacenters around the world. The list of supported regions can be found in the pricing page.
You can minimize or avoid bandwidth charges by choosing the same location for multiple services. For example, if you are indexing data provided by another Azure service (Azure storage, Azure Cosmos DB, Azure SQL Database), creating your Azure Search service in the same region avoids bandwidth charges (there are no charges for outbound data when services are in the same region).
Additionally, if you are using cognitive search AI enrichments, create your service in the same region as your Cognitive Services resource. Co-location of Azure Search and Cognitive Services in the same region is a requirement for AI enrichment.
Central India is currently unavailable for new services. For services already in Central India, you can scale up with no restrictions, and your service is fully supported in that region. The restriction on this region is temporary and limited to new services only. We will remove this note when the restriction no longer applies.
Choose a pricing tier (SKU)
Azure Search is currently offered in multiple pricing tiers: Free, Basic, or Standard. Each tier has its own capacity and limits. See Choose a pricing tier or SKU for guidance.
Basic and Standard are the most common choices for production workloads, but most customers start with the Free service. Key differences among tiers is partition size and speed, and limits on the number of objects you can create.
Remember that a pricing tier cannot be changed once the service is created. If you need a higher or lower tier later, you have to re-create the service.
Create your service
After you've provided the necessary inputs, go ahead and create the service.
Your service is deployed within minutes, which you can monitor through Azure notifications. Consider pinning the service to your dashboard for easy access in the future.
Get a key and URL endpoint
Unless you are using the portal, programmatic access to your new service requires that you provide the URL endpoint and an authentication api-key.
In the service overview page, locate and copy the URL endpoint on the right side of the page.
In the left navigation pane, select Keys and then copy either one of the admin keys (they are equivalent). Admin api-keys are required for creating, updating, and deleting objects on your service.
An endpoint and key are not needed for portal-based tasks. The portal is already linked to your Azure Search resource with admin rights. For a portal walkthrough, start with Quickstart: Create an Azure Search index in the portal.
Scale your service
After your service is provisioned, you can scale it to meet your needs. If you chose the Standard tier for your Azure Search service, you can scale your service in two dimensions: replicas and partitions. Had you chosen the Basic tier, you can only add replicas. If you provisioned the free service, scale is not available.
Partitions allow your service to store and search through more documents.
Replicas allow your service to handle a higher load of search queries.
Adding resources increases your monthly bill. The pricing calculator can help you understand the billing ramifications of adding resources. Remember that you can adjust resources based on load. For example, you might increase resources to create a full initial index, and then reduce resources later to a level more appropriate for incremental indexing.
A service must have 2 replicas for read-only SLA and 3 replicas for read/write SLA.
- Go to your search service page in the Azure portal.
- In the left-navigation pane, select Settings > Scale.
- Use the slidebar to add resources of either type.
Per-partition storage and speed increases at higher tiers. For more information, see capacity and limits.
When to add a second service
Most customers use just one service provisioned at a tier providing the right balance of resources. One service can host multiple indexes, subject to the maximum limits of the tier you select, with each index isolated from another. In Azure Search, requests can only be directed to one index, minimizing the chance of accidental or intentional data retrieval from other indexes in the same service.
Although most customers use just one service, service redundancy might be necessary if operational requirements include the following:
- Disaster recovery (data center outage). Azure Search does not provide instant failover in the event of an outage. For recommendations and guidance, see Service administration.
- Your investigation of multi-tenancy modeling has determined that additional services is the optimal design. For more information, see Design for multi-tenancy.
- For globally deployed applications, you might require an instance of Azure Search in multiple regions to minimize latency of your application’s international traffic.
In Azure Search, you cannot segregate indexing and querying operations; thus, you would never create multiple services for segregated workloads. An index is always queried on the service in which it was created (you cannot create an index in one service and copy it to another).
A second service is not required for high availability. High availability for queries is achieved when you use 2 or more replicas in the same service. Replica updates are sequential, which means at least one is operational when a service update is rolled out. For more information about uptime, see Service Level Agreements.
After provisioning an Azure Search service, you can continue in the portal to create your first index.