Use this information to better understand how Elasticsearch Service instance configurations (for example
azure.data.highio.l32sv2) relate to the underlying cloud provider hardware that we use when you create your deployment.
Deployments use a range of virtualized hardware resources from a cloud provider, such as Amazon EC2 (AWS), Google Compute Platform (GCP) or Microsoft Azure. Instance configurations enable the products and features of the Elastic Stack to run on suitable resources that support their intended purpose. For example, if you have a logging use case that benefits from large amounts of slower but more cost-efficient storage space, you can use large spindle drives rather than more expensive SSD storage. Each instance configuration provides a combination of CPU resources, memory, and storage, all of which you can scale from small to very large.
All instances, regardless of the region or provider, are set to UTC timezone.
Understanding an instance configuration nameedit
Azure and AWSedit
How to read an Elasticsearch Service instance configuration name, such as
- The cloud provider the underlying hardware belongs to.
The products or features of the Elastic Stack:
- Elasticsearch master, ml, and data nodes
- Kibana instances
- Application performance monitoring (APM) server instances
- And more …
- Optional: The hardware characteristics, such as optimization for I/O, storage, compute, or memory.
- The short name for the instance type, or a number identifying a custom machine type.
Instance configurations are an Elasticsearch Service abstraction of virtualized resources from the provider, but you might recognize the underlying hardware they build on in the instance configuration name. We use instance types on AWS and Azure, and custom machine types on GCP. Elasticsearch Service instance configurations are not the same AWS instance types.
For GCP instance configurations, we are introducing a new naming convention that will soon be rolled out to Azure and AWS.