Elastic SaaS pricing is extensively documented. However, when researching the associated concepts, the abundance of information can sometimes lead to confusion. This note aims to provide a clear understanding of Elastic SaaS pricing.
Elastic SaaS encompasses four key billing concepts:
Consumption-based billing
Resource-based billing
Elastic Consumption Unit (ECU)
Credits
Let's delve into the specifics of these concepts. Consumption-based billing diverges from subscription-based billing, which might entail a fixed daily allowance of X Gbps or X EPS. Consumption-based billing offers distinct advantages: you only pay for what you actively use, and expanding doesn't necessitate purchasing new licenses.
Resources, encompassing RAM, CPU, and Disk, correspond to your usage and contribute to consumption. Elastic employs various computing resources, each measured differently. Elasticsearch Service Billing hinges on your actual usage across three dimensions:
Deployment capacity - Measured in GB per hour
Data Transfer - Measured in GB transferred
Storage - Snapshot storage GB per month
To consolidate consumption across all utilized resources, they are amalgamated into an "Elastic Consumption Unit" (ECU). Each ECU is monetarily equivalent to $1. Customers acquire credits in the form of ECUs. These ECUs can be procured at a discount, but they come with an expiration date. Does it remind you of an annual subscription-based model (humorously reminiscent, isn't it?).
The diagram below illustrates the acquisition of ECUs into a collective pool. On the first day of each month, the resources consumed in the preceding month are converted into ECUs, which are then deducted from the organization's ECU pool.
Elastic utilizes JSON-based files to store data within structures referred to as "indices." An index is created for a single unit of data or multiple units, known as "indices." Concerning log collection in Elastic, a distinct file within an index represents a single log. For instance, an index containing 10,000 logs would comprise 10,000 individual files, one for each log. The index serves as the largest data unit in Elasticsearch, comparable to a relational database's concept of a database. To optimize data management, information within an index is distributed across shards, which are small components forming the whole.
As Elastic doesn't impose charges for inbound data transfer, a significant expense revolves around "deployment capacity," denoting the ability to store all indexed log data. The cost of storing this log data hinges on the volume stored and the underlying computing resources employed for storage. These resources directly impact query performance for log data. Consequently, Elastic has developed distinct storage tiers, each with cost and performance implications. The Elasticsearch storage tiers include:
Hot
Warm
Cold
Frozen
In an ideal scenario devoid of financial constraints, all data would be stored in the pricier hot tier. However, customers need to conduct a cost-benefit assessment. For instance, they might ascertain that most actively queried data is less than 48 hours old. Occasionally, they might need to search data from a few days ago or even several weeks back, but speed isn't crucial for these infrequent queries. In this scenario, data could be retained in the hot tier for 48 hours, then moved to the warm tier for 5 days, followed by migration to the cold tier for 3 weeks, and eventually to the frozen tier. This data management sequence is termed the "index lifecycle" and is managed through the application of an index lifecycle policy within Elastic.
Elastic has an online pricing calculator, https://cloud.elastic.co/pricing , to help you run scenerios for the amount of data and index life cycle to calculate costs.
References
Commenti