Elastic, without running the cluster — Elastic Cloud is the managed platform: Hosted across 50+ regions on resource-based pricing, or Serverless on consumption with nothing to size.
Buy through TechBag
Same software. Better outcome — at a lower cost.
How it’s rated
Full scoreboard ↓Data residency & processing — answered by deployment
Self-managed
Stored AND processed by you
Runs on your own infrastructure, including fully air-gapped. Both questions answered by definition — the data never leaves.
Elastic Cloud
50+ regions — confirm both
If you choose managed, confirm storage AND processing location for your region in writing, as you would with any SaaS.
Elastic Cloud Hosted lists three Indian regions — AWS Mumbai, Google Cloud Mumbai and Azure Central India (Pune) — so you choose where the deployment’s data is stored. Processing location is a separate question: get it in writing. Where a mandate rules out any vendor-operated service, self-managed Elastic is the same software under your control.
Quick answer
This page covers Elastic Cloud — the managed way to run all of them. The other Elastic products:
Most product pages skip this. We start here — so you buy a capability, not a buzzword.
The Elastic Stack, run for you — Elasticsearch, Kibana and the Search, Observability and Security solutions on AWS, Azure or Google Cloud, with Elastic handling the cluster.
What moving to managed actually changes, dimension by dimension.
| Dimension | Self-managed Elastic | Elastic Cloud |
|---|---|---|
| Cluster operations | Your team: sizing, shards, failed nodes | Elastic runs them |
| Version upgrades | Planned, tested and often deferred | Handled; Kibana kept in step |
| Snapshots & HA | A regime you design and test | Managed across zones |
| Time to a cluster | Hardware or cloud build first | Minutes from the console |
| India residency | Wherever you put it | Mumbai (AWS, GCP) or Central India (Azure) |
| Air gap | Fully possible | Not possible — Elastic operates it |
| Licence | Free Basic under AGPL; paid tiers | One bill: resources plus tier |
| Best fit | Air-gap mandates; spare platform team | No spare ops capacity; India region needed |
Same software on both sides — the difference is who carries the operations, and whether an air gap is on the table.
Vendors love diagrams; buyers need to know what they’re actually operating. Here’s the whole platform, demystified.
The distributed search and analytics engine underneath everything Elastic sells. On Elastic Cloud you size it rather than build it — nodes, hot and warm tiers and storage are provisioned for you and scale on demand. It is the same Elasticsearch you would run yourself, which is why moving between managed and self-managed is a genuine option rather than a migration.
Dashboards, search, alerting and the workspaces for Observability and Security. Managed and upgraded in step with the cluster, so you are never running a Kibana that has drifted out of version alignment with Elasticsearch — a common and tedious failure mode in self-managed deployments.
The same deployment can carry any combination. This is Elastic's core commercial argument: one store and one agent rather than a log platform plus a separate SIEM plus a separate APM tool, each with a copy of your data. If you already run Elastic for logs, adding Security is a licence decision rather than a new platform.
Standard covers core search and analytics. Gold and Platinum add alerting, machine-learning anomaly detection and cross-cluster replication. Enterprise adds the advanced Security and orchestration capabilities. Read the tier boundaries carefully before sizing — teams routinely assume machine learning is included and discover it sits two tiers up.
AWS, Azure and Google Cloud, including Mumbai on AWS and GCP and Central India on Azure. For an Indian buyer with a residency obligation, a documented Indian region for the exact service you buy is the first thing to confirm with any managed platform.
Serverless projects remove capacity planning entirely and bill on usage. Attractive where load is spiky or unknown; less predictable where it is steady and well understood. Model both against your actual pattern rather than assuming serverless is automatically cheaper.
The same Elasticsearch and Kibana you could run yourself — Elastic operates the cluster, and you choose the cloud, the region and the tier.
What Elastic Cloud takes off your hands, and what it adds on top of the software you could run yourself — the operational pieces that decide whether managed is worth it.
Deploy a sized, production-ready Elastic Stack on AWS, Azure or Google Cloud without procuring hardware or building a cluster.
Add nodes, storage or hot-warm tiers as data grows, rather than re-architecting a cluster you sized eighteen months ago.
Deploy into Mumbai or Central India so an India-residency obligation is answered by where you put the cluster.
Elastic runs the upgrade path and keeps Elasticsearch and Kibana in version alignment — the tedious part of self-managing.
Managed high availability across zones, with automated snapshots, rather than a backup regime you design and test yourself.
License any combination on one deployment, so logs collected once serve operational monitoring and threat detection without a second copy.
Unsupervised anomaly detection on the higher tiers — genuinely useful, and genuinely not included at Standard.
Serverless scaling, and one of the solutions you can license on a deployment — from Elastic’s own channels.
How a serverless project scales up with no nodes to size.
One of the solutions you can license on an Elastic Cloud deployment.
Want a live, India-context walkthrough for your environment?
Book a guided demo →Why teams move to Elastic Cloud — and the three limits that should send you to self-managed instead.
This is the honest centre of the page, and it is unusual enough to state plainly: Elastic Cloud is not a different or better Elastic. It is the same Elasticsearch, the same Kibana and the same solutions, with the operational work moved to Elastic. So the question is never 'is Elastic Cloud better than Elastic' — it is whether running a distributed search cluster well is a job your team should be doing. For many teams it is not: cluster sizing, shard strategy, version upgrades and 2am node failures are real engineering, and doing them badly produces an expensive, slow platform that people stop trusting. For teams who already run Elasticsearch competently, self-managing is a legitimate and fully supported answer that costs less in licence terms.
Elastic Cloud can be deployed into Mumbai on AWS and Google Cloud, or Central India on Azure. That sounds mundane until you check the cloud-only platforms an Indian regulated buyer is shortlisting alongside it — India-region availability often varies by product, and for an IRDAI-regulated insurer or a bank under RBI localisation expectations a missing region is not a pricing disadvantage but a disqualification. Being able to choose where the cluster sits, and evidence it, is a structural advantage rather than a feature.
The strongest architectural argument for Elastic generally applies here too. Most organisations run a log platform for operations and a separate SIEM for security, which means collecting the same data twice, storing it twice and paying for it twice. On Elastic Cloud one deployment can carry Observability and Security against the same indices. If you already run Elastic for logs — and a great many engineering teams do — adding Security is a licence decision rather than a new platform, a new agent and a new rollout.
Elastic Cloud bills for the compute and storage your deployment actually consumes, not per gigabyte ingested under a licence meter. The distinction is real but should not be oversold: a noisy source still costs you, because it consumes resources. What changes is the shape of the relationship — you can tier data to cheaper storage, control retention per index and size the cluster to your actual pattern, so cost is something you engineer rather than something the licence dictates. Teams who have watched a per-GB SIEM invoice climb quarter after quarter find this materially easier to manage.
Three. First, no air gap — by definition, since Elastic operates it. If your mandate requires a disconnected deployment, Elastic Cloud is not a more expensive option, it is not an option, and you want self-managed Elastic instead. Second, the tier boundaries catch people out: machine-learning anomaly detection and cross-cluster replication are not in Standard, and teams routinely size a deployment assuming capability that sits two tiers up. Read the tier table before you model the cost. Third, consumption pricing is only predictable if your load is predictable — spiky ingestion produces a spiky bill, and the answer is retention and tiering policy set deliberately at the start rather than reviewed after the first surprising invoice.
This is the actual decision and everything else follows from it. If a mandate requires air-gapped operation, stop here — Elastic Cloud cannot serve you and self-managed Elastic is the same software under your control. If not, weigh your genuine spare platform-engineering capacity against the subscription rather than against a bare hosting bill.
Mumbai on AWS or Google Cloud, or Central India on Azure, if Indian residency binds you. Choose it because your obligation requires it and record why, rather than defaulting to whichever region the console offers first — this is the evidence an auditor will ask for later.
Map the features you actually intend to use to the tier that contains them, machine-learning anomaly detection especially. Sizing on Standard and discovering a needed capability sits at Platinum is the commonest and most avoidable costing error on this product.
Decide what stays hot, what moves to warm and what is deleted, per index, at the start. Consumption pricing rewards this and punishes its absence. Retrofitting a retention policy onto a cluster already carrying a year of undifferentiated data is far harder than setting one on day one.
Give someone ownership of the monthly consumption review. Not because the pricing is unfair but because it is responsive: it reflects what you are doing, and nobody notices a source that doubled in volume until it appears as money.
Modelled on Gartner Peer Insights structure. *Counts and breakdowns are illustrative pending verified review collection.
“We moved off a self-managed cluster after our one Elasticsearch expert resigned. That risk was the entire business case.”
“Mumbai region meant our residency question had a one-line answer. Two other vendors on the shortlist could not say the same.”
“Read the tier table properly. We sized on Standard and then discovered machine learning was two tiers up.”
“Consumption pricing is fair but it is not set-and-forget. Retention and tiering policy needs an owner or the bill drifts.”
Analyst firms bury this view behind paywalls, and G2 retired its Grid. So here’s TechBag’s synthesis of the ways to run Elastic, and the managed alternatives — tap any vendor to see why it sits where it does.
How much operational work each option removes vs how much control it leaves you.
Elastic runs the cluster; you still choose cloud, region and tier — no air gap.
Managed platforms compared on how much work they remove vs how directly they answer an India-residency question.
Operations removed; three documented Indian regions.
Positions are TechBag’s illustrative synthesis of public review-platform data and vendor documentation — not a reproduction of any analyst graphic. Verify before relying on it.
The four ways to run Elastic, side by side. The software is identical in every column — what changes is who operates it, where it can sit, and how the bill behaves.
| Dimension | Elastic Cloud | Self-managed Elastic | Elastic on your own cloud account | Elastic Serverless |
|---|---|---|---|---|
| Who operates the cluster | Elastic — sizing, upgrades, availability | You, entirely | You, on infrastructure you rent | Elastic, with no nodes to size at all |
| Licence cost | Consumption — compute and storage used | Basic tier is genuinely free (AGPL) | Subscription if you want commercial features | Usage-based, no provisioned capacity |
| True cost to compare | One bill: infrastructure AND operations | Infrastructure plus real engineering time | Cloud bill plus your engineering time | One bill, scales with what you do |
| Air-gapped deployment | Impossible — Elastic runs the control plane | Fully supported | Possible in a private/isolated network | Impossible by design |
| India data residency | Mumbai (AWS/GCP), Central India (Azure) | Wherever you put it — yours to prove | Your account, your region choice | Check region availability for serverless |
| Version upgrades | Handled, and kept in version alignment | Yours — the task teams most often defer | Yours | Invisible to you |
| Key-person risk | Low — the vendor holds the expertise | High — often exactly one person knows it | High, same reason | Lowest |
| Cost predictability | Responsive to load — needs a retention policy | Fixed infrastructure, fixed salary | Depends on your commitments | Most variable — spiky load, spiky bill |
| Best fit | No spare platform capacity; India region needed | Air-gap mandates, or real spare capacity at scale | Large committed cloud spend you already hold | Spiky or unknown load you cannot size |
Honest fit signals — because the fastest way to lose your trust is to pretend one product wins every scenario.
Elastic Cloud is the managed way to run the stack behind 20 SIEM & log management products TechBag carries. The SIEM & Log Management guide narrows them to a shortlist and shows the reasoning. →
Elastic Cloud Hosted bills on the resources you provision plus the tier — so the question that decides your bill is whether running the cluster yourself costs less than letting Elastic run it. The engine is free under AGPL; what is not free is your engineers’ time on shard strategy, index lifecycle, capacity and upgrades. Drag both sliders. Illustrative, at ₹12,000 per fully-loaded engineer-day and ~₹84/USD.
Engineer-days means real time on shard strategy, index lifecycle, capacity planning and version upgrades — not incident response. If you put 0, you are assuming the cluster runs itself, which is the assumption this calculator exists to question. Illustrative: your TechBag quote models your real tier and resources.
Elastic Cloud Hosted is priced on provisioned resources plus a tier (Standard, Gold, Platinum, Enterprise); Serverless is priced on usage — GB ingested and retained for Observability and Security, compute units for Search. Self-managed is shown for comparison: the engine is free under AGPL and you supply the operations. Figures are Elastic’s listed “as low as” entry rates and scale with what you use. TechBag scopes tier and deployment and quotes in INR with GST.
Best for on-prem and air-gapped
Best if you want it managed
Best for variable volume
Whatever the list prices above, TechBag negotiates a significantly better deal — with GST-compliant INR invoicing and local support. Ask us for your discounted quote.
Tell us your requirements and current tools — we’ll model it against what you spend today.
Take this into your next vendor call — including ours.
Does any mandate require air-gapped or on-premises operation? If so, Elastic Cloud is out — use self-managed.
Do we have genuine spare platform-engineering capacity to run a distributed cluster, counted honestly?
Which region will hold the deployment, and does that satisfy our residency obligation in writing?
Which tier contains the capabilities we actually intend to use — machine learning especially?
Are we licensing Search, Observability, Security or a combination, and on the same deployment?
What is our per-index retention and tiering policy, decided before we load data rather than after?
Do we already run Elasticsearch for logs, making Security a licence decision rather than a new platform?
Who owns the monthly consumption review, so a source that doubled in volume gets noticed?
Decide managed or self-managed, pick the region deliberately, and size the tier against the capabilities you will actually use — quoted in INR with GST.
Stats, ratings, review counts and pricing are illustrative and sourced from public materials; verify before purchase.