Source: helpnetsecurity.com (original announcement, September 2019)
Overview
Elastic — the company behind Elasticsearch and the Elastic Stack — announced the launch of Elasticsearch Service on Microsoft Azure. The move gives DevOps and platform engineering teams who have standardized on Azure a fully managed, officially supported path to run Elasticsearch and Kibana without managing the underlying infrastructure themselves.
Prior to this launch, Azure-based organizations had to self-manage Elasticsearch clusters on Azure VMs or use third-party offerings. The new service, hosted on Elastic Cloud, is operated directly by Elastic — meaning users get the same team that builds the software also supporting and operating it.
Key Capabilities at Launch
Elasticsearch Service on Azure launched as a public beta accessible to all existing Elasticsearch Service customers and new trial users. Highlights at launch included:
- One-click deployment of hosted Elasticsearch and Kibana directly from the Elastic Cloud console
- Access to the full Elastic Stack feature set: Elastic APM, SIEM, Maps, Canvas, and machine learning
- Single-click upgrades to new Elasticsearch releases with zero downtime
- Automatic security patches applied by Elastic’s operations team
- A free 14-day trial for new users
- Existing Elasticsearch Service customers could add Azure deployments within their existing accounts
At beta launch, the service was available in two Azure regions: East US 2 (Virginia) and West Europe (Netherlands). Elastic indicated plans to expand regions and move the service to general availability later in 2019, at which point mission-critical support tiers would also be added.
Deepening the Elastic and Microsoft Collaboration
This launch built on an existing partnership between Elastic and Microsoft. The two companies had previously collaborated on an Azure Resource Manager (ARM) template for the Elastic Stack, which many teams were already using to deploy self-managed clusters on Azure VMs.
Elastic’s broader Microsoft ecosystem support includes:
- .NET clients for Elasticsearch
- Winlogbeat for collecting Windows OS event logs and shipping them to Elasticsearch
- Azure Active Directory integration for securing Elasticsearch clusters
- .NET support in Elastic APM for application performance monitoring of .NET workloads
Shay Banon, founder and CEO of Elastic, commented: “The developer and open source focus that both companies share have made this integration a very natural fit. Microsoft’s commitment to choice is evident in their developer experience on Microsoft Azure, and mirrors our own.”
Scott Guthrie, EVP of Cloud + AI at Microsoft, added: “As customers adopt cloud services, having a solution for their most important needs such as search, logging, observability, and security of their critical applications, will be a key advantage. The focus on developer choice and managed services that both Microsoft and Elastic share benefit our mutual customers.”
Four Optimized Deployment Templates for Azure
Elastic’s engineering teams worked with Microsoft to benchmark and select optimal Azure VM types for common Elasticsearch workload profiles. The result was four deployment templates, each targeting a different performance and cost profile:
- High I/O: Designed for search-heavy or general-purpose use cases. Runs on L-series VMs equipped with local NVMe SSDs optimized for high read/write throughput.
- Hot/Warm: A tiered architecture suited to logging and time-series workloads. Combines NVMe SSD for the “hot” tier (fast, recent data) with HDD storage offering a 1:100 RAM-to-disk ratio for cost-effective long-term retention in the “warm” tier.
- High CPU: Targets compute-intensive workloads such as ingest pipelines, scripting, and aggregation-heavy queries. Provides double the CPU allocation relative to comparable memory.
- High Memory: A cost-effective option for search use cases that operate on lower data volumes but require larger JVM heaps and in-memory indices.
Choosing the right template at deployment time can significantly affect both performance and cloud spend, so understanding the expected query and ingestion patterns before deploying is worthwhile.
Beta Pricing Promotions
During the beta period, Elastic offered a promotional window in which data transfer costs (ingress, egress, and inter-node traffic) and snapshot storage costs (storage size and API requests) were waived. This made the beta period a low-risk time for teams to evaluate the service for production workloads before committing to full pricing.
Why This Matters for DevOps Teams
For DevOps and SRE teams already operating in Azure, the managed Elasticsearch Service eliminates significant operational overhead: cluster sizing, version upgrades, certificate management, snapshot scheduling, and monitoring of the Elasticsearch process itself all become Elastic’s responsibility rather than yours.
Teams that had been running Elasticsearch on self-managed Azure VMs — whether via the ARM template or custom Terraform configurations — gained a supported migration path to a fully managed topology without leaving the Azure ecosystem or switching cloud providers.
The addition of Azure also gave multi-cloud organizations the flexibility to co-locate Elasticsearch workloads on the same cloud provider as other Azure-native services (Azure Kubernetes Service, Azure Monitor, Azure Active Directory, etc.), reducing cross-cloud data transfer costs and latency.