Elastic Cloud Value Calculator: Understand the business value of Elastic Cloud

As your Elastic usage increases and your use cases expand, it's important to know the benefits and cost savings that you can achieve by running Elasticsearch as a service. But since every Elasticsearch implementation can vary by use case and deployment model, it can be complicated to tackle on your own. So with that in mind, we are excited to share the Elastic Cloud Value Calculator.

With this calculator, you can easily estimate cost savings and increases in productivity based on infrastructure needs, efficiency factors, potential risks, and more. Then, based on your results, you'll know how Elastic Cloud creates potential efficiencies for you, or help you determine if you're already on the right track. The calculator just does the hard part of handling the variables of your specific situation.

One point before we get into the details. In developing this tool we have partnered with DecisionLink, who has many years of experience in developing web calculators and value models. We are grateful for their expertise in defining the assumptions with us below.

Let's take a look at the logic and assumptions built into this tool. On to the math!

Reduce IT infrastructure and storage costs

Cost savings usually start here, as it’s quite frequently the biggest bucket of potential value. Some of the factors the calculator takes into account are:

  • What instance types (and their respective costs) are you running Elastic on?
  • What do those instances cost annually?
  • If you aren't on Elastic Cloud, are you using reserve or on-demand pricing?
  • If you're running Elasticsearch in your own data center, what is the three-year amortized value of the hardware?

The first situation we filter for is whether you are running Elastic in your own data center or running it self-managed on a cloud provider. Each situation has its own infrastructure cost implications, which we break down below.

Self-hosted in your own data center

Reduce self-hosted server costs:

# of nodes * annual cost per server (server purchase / 3 years) * 100% reduction of future server cost

Note: For self-hosted servers, we assume a 1:1 ratio of server to node. If you are using larger machines that can handle multiple nodes, you’ll need to divide the annual cost of a server by the number of nodes you are running on each server in order to get the appropriate cost comparison.

Reduce server maintenance cost:

# of nodes * 20% of annual server cost for maintenance & support * 100% reduction of future server maintenance cost

Note: Maintenance of a server depends largely on the type of server and how old it is. Newer servers generally require less maintenance and support vs older ones (3+ years).

Reduce data center overhead cost (heating, cooling, electric):

# of nodes * 25% of annual server cost for infrastructure overhead * 100% reduction of future server maintenance cost

For an overview of power usage associated with servers see this ZD net article on the topic.

Self-hosted on another cloud provider

Reduce cost of cloud services:

# of nodes * annual cost per cloud virtual machine * 100% reduction of future cloud virtual machine cost

Reduce cost of data transfer and storage (DTS):

# of nodes * 20% of annual cloud virtual machine cost DTS * 100% reduction of DTS cost

General benefits applied in both situations

Reduce software licensing costs:

# of nodes * 10% annual cost per server or cloud virtual machine * 100% reduction of future server license cost

Note: Assumptions here depend on whether you are using open source Linux, a RedHat distribution of the same, or something else for your server OS. Also, please keep in mind that this will be much higher if you are already paying for an Elastic licensed tier of software (Gold, Platinum, Enterprise) so you will need to take that into account and increase this amount if you are comparing self-managed to Elastic Cloud.

Reduce overprovisioning cost of hardware

We run into overprovisioned hardware on a regular basis. Whether you overestimated or are just planning for worst-case scenarios, Elastic Cloud can help you get your sizing right, regardless of the risks you need to mitigate. In addition, we just launched a new autoscaling capability that will remove the need for you to ever have to worry about rightsizing your Elastic environment again when you use Elastic Cloud.

Reduce overprovisioning cost of hardware:

# of nodes * annual cost per server or cloud virtual machine * 22.5% reduction of future overprovisioning costs

Note: We see ranges of overprovisioning usually between 15-30% of the total infrastructure required.

Reduce unnecessary data duplication cost

For the large community out there who are running Elastic self-managed on our free and open or Basic tiers, many will twist their deployment in order to reduce risk of exposure of data to the wrong audience. Often, the logical way to do this is to duplicate a portion of the data in your current Elastic cluster and put that portion of data in a new, isolated cluster for a specific audience. However, this effort can be reduced or eliminated by taking advantage of security and access controls, easily configured with Elastic Cloud.

Reduce data duplication cost with access controls:

[# of nodes * % of nodes duplicated (30% assumed without access controls)] * annual duplication cost per node (both infra and human capital costs) * 30% reduction of future duplication costs

Note: We assume only 30% reduction in cost here in order to be conservative and to take into account the probability of this happening in all situations. If this is occurring in your situation, you should consider this improvement factor to be 100%.

Subscription-level features

Lastly, there are powerful features in our Enterprise tier that you only have access to as an Elastic customer, such as searchable snapshots and data tiers. The cold data tier enables you to run a single node of Elastic with the replica stored in durable object storage (Amazon S3, Azure Blob Storage, or Google Cloud Storage) to reduce replication cost. So you can still search the cold node, with snappy responsiveness, but with the backup being an ultra low-cost alternative. And that’s just the beginning. We’re currently working on a searchable frozen tier that sits entirely within object storage with an even more compelling cost profile.

Reduce hardware cost with data tiering (not applied within model, but worth considering):

# of nodes in warm data tier (assumes 50% of total nodes) * annual cost per server or cloud virtual machine * 50% reduction of future infrastructure costs through use of data tiers

IT efficiency

Running and administering the Elastic Stack can take time and personnel. Deployments often start small, with little administrative overhead. But as adoption increases, so does the implementation size, and so do the demands (and expectations) of your users. We are always working to make the administration easier from within Kibana, but there is a lot to keep in mind: shards, replicas, scaling, upgrading, security, compliance, capacity, and more. These are things that aren't necessarily considered the first time a cluster is spun up.

Generally speaking, a 25-node cluster of Elastic for logging or observability will require about 50% of a person’s time to manage and orchestrate, based on anecdotal evidence and discussions with the many folks here at Elastic who have done the work. So to apply some logic to that, if 50 nodes = 1 DevOps full-time employee (FTE), then 1 node = 0.02 FTEs.

But with Elastic Cloud, we frequently see 70% of that operational overhead removed from our administrators’ daily lives. Now you only need to take up a smaller fraction of someone's time per node, as Elastic Cloud takes care of many of the details. The ratio becomes 200 nodes to 1 FTE.

If you want a better view into how we can divide and conquer the work together, have a look through our responsibility matrix. The main responsibilities Elastic Cloud helps to make much easier include:

  1. Reducing overall DevOps automation required through predefined APIs and protocols. This broader category accounts for the lion’s share of the automation benefits to administrative teams.

    Reduce IT staff through Elastic Cloud orchestration:
    # of FTEs for running Elastic self managed on a node basis * $100,000 FTE * 70% reduction in FTE time required to manage Elastic
  1. Reducing time to manage upgrades by 95%.

    Reduce time to manage upgrades:
    Number of upgrades per year (assume 2X as a starting point) * $3,200 per upgrade (64 hours) * 95% reduction in time for managing upgrades
  1. Reducing risk of managing critical vulnerability incidents and associated costs to near zero.

    Reduce risk of critical vulnerability incidents:
    # of critical vulnerabilities per year (assumes 4) * $4,000 per critical vulnerability engineering time (80 hours) * 10% reduction in critical vulnerability incidents

Revenue and employee disruption risk

This value category is potentially the largest, depending on your situation. Let’s talk about what it means to your business to run a highly stable, scalable, and resilient service with Elastic central to your architecture.

Employee disruption risk reduction

This is the most common and important area of downstream user risk reduction. There are two big questions you need to consider here:

  1. How many people at your company are using Elastic today (in some form) based on your implementation?
  2. What is the cost of employees not having access to your Elastic implementation?

If it’s a security- or observability-related application, this could mean that your end users lack support when there is an urgent security or downtime risk-related incident that needs to be addressed. Ask yourself:

  • What is the cost per minute of disruption and downtime?
  • Will a single failure cause a domino effect of failures?
  • If there's an outage, will the observability solution also fail?

And maybe most importantly: How forgiving will stakeholders be when preventable infrastructure issues cause business outages?

Improve end-user productivity through reduced risk of disruptions:

# of employee end users of the solution * $100,000 per FTE * 1% improvement in end user productivity

Note: This improvement factor assumption means that your end users would experience 1% less downtime due to solution disruption. We generally see higher downtime for internal employee-facing applications, and as a result chose this improvement factor. Keep in mind that your uptime improvement should be based on your current uptime service-level agreement (SLA).

Revenue and service risk

This calculation takes into account the risks associated with a customer-facing service you are running on Elastic. What is the risk of an outage associated with that service? Is there potential revenue at risk, and if so, how much?

These are all good things to have a handle on, and we've made some simple assumptions for you if you choose this situation. Keep in mind that we generally apply this situation, conservatively, towards consumer-facing search use cases. For example, what would it mean if you are a retailer and your search stops working, and what is the cost of that possible outage? These are all risks that need to be considered and mitigated.

Reduce risk of lost revenue due to unplanned downtime:

Annual number of downtime hours (assume 44, or 99.5% uptime) * $25,000 per downtime hour * 90% reduction in downtime hours

Note: This improvement factor assumes an increase from 99.5% uptime to 99.95% uptime, an improvement of 90% as a starting point.

Reduced risk of SLA violation

This particular calculation is equally specific as the last one. The assumption is that you have embedded search or a related intelligence use case into a business customer-facing application. What’s the risk of your application experiencing instability that we can help you mitigate? And if your service-related search or lookup capability is down, will your end users claim they are experiencing an SLA violation? Anyone who's worked on a support contract knows how important these considerations are.

Reduce risk of SLA violation:

Annual SLA penalty events (we assume 1 to start) * [# of customers impacted by an SLA penalty event * average annual revenue per business customer * % of business customer revenue refunded due to penalty event (15% seeded)] * 20% reduction SLA penalty risk

Security, risk, and compliance

For these calculations, we don’t expose any inputs. Generally, this is an acknowledgement of the risk associated with running Elastic without the right security and compliance protocols in place. There is a very good reason to include these benefit calculations, even if your individual risk is marginally low. One must accept the fact that, without the right security setup — which comes standard with Elastic Cloud — Elastic users incur risk of collecting data and exposing that data. Sure, it can be cool to “move fast and break things,” but it isn’t sustainable in the long term when you take into account security and compliance concerns.

Reduce cost of creating compliant solutions:

Number of compliant solutions required (assumes 1) * cost per compliance solution (assumes $25,000) * 100% reduction in cost of creating and maintaining a compliance solution

Reduce risk of data breach through use of access controls:

[Risk of data breach in scope 1.2% (24% risk of data breach caused by human error: IBM research) * 5% chance of data breach associated with Elastic (vs other datastores)] * average cost per data breach (used industry benchmark from IBM of $8.1M) * 95% reduction in risk of data breach through use of access controls

Reduce risk of downtime for regulated services:

Downtime instances leading to regulatory violations (assumes 1) * average fine for regulated services (assumes $10,000) * 90% reduction in downtime

These assumptions are similar to the reduced risk of downtime noted in the revenue and employee disruption risk section above.

Find out how much you can save or gain

Now that you know how all these calculations work, we encourage you to try the Elastic Cloud Value Calculator yourself. When you download the output file from our value calculator, keep in mind that we include not only the one-year benefit results, but also the three-year results. We also assume 10% year-over-year growth with these value calculations. Generally speaking, our users and customers see quite a bit more growth than this annually, so we believe this is a conservative estimate of your growth potential.

Finally, a few parting thoughts:

  • Experiment with the calculator. Play around with the factors and numbers to develop a more custom business case tailored to your needs.
  • Take the numbers further. There are downstream impacts from the benefit calculations that you can explore outside of the calculator. Some of these are specific to your needs and can't be added to a standardized tool.
  • Help us make the calculator better. Give us feedback on how to improve it to represent the value you accrue with your use of Elastic Cloud. If at any point you have feedback on this tool, please email