Elastic for MSSP: What is the impact of a new space on kibana?

Elastic Stack Kibana
1

Hello!

Our main goal:
As an MSSP, we want to create a multi-tenant subdivision for our customers.
Each customer has an internal IT team who wants access to their Elastic Security Space.

Useful information:

  • Elastic Stak 9.4.2
  • Elastic support recommended using namespaces to differentiate customers and creating spaces so they have access to logs-*customer_name* because this is better at the Space level.

My doubts and questions:

  • Every time I add a new Space, I create about 17 new small indexes on my cluster: .asset-criticality, .items, .kibana-data, .kibana-elastic, etc. Isn't this against best practices? "Better to have a few large indexes than many small ones."
  • Is there a way to calculate the impact a new Space has on Elastic? Or can anyone tell me the main things I need to consider?
  • Are there any MSPs with a multi-tenant approach that I can discuss?

Thank you very much.

This isn't a problem ticket. It's more of a discussion.

2

In part yes, but it is expected for those indices to grow overtime, but there are many internal and system indices that will be smaller, in newer versions those small indices has less impact than in previous versions if I'm not wrong.

I don't think so, in terms of those indices the main impact would be in the number of indices in the cluster which will increase, the main impact would be related to the queries being done in each index as with shared spaces one client can impact the entire cluster.

3

Hi Leandro!

Thanks for your reply.

Basically, I'm still not clear on the best approach for an MSP to create multi-tenant security on Elastic.

We initially thought about creating a single space, with single index split by field (organization.name) and dividing the views based on the roles assigned to users.
Doing what's described here (Multi-tenant with Fleet and one single policy with integrations), and avoiding namespaces, and following best practices to avoid creating many small indexes.
Then they recommended switching to spaces, switching to namespaces for customers who need access to a personal space.
But this approach introduces many small indexes that impact cluster performance.

I don't know if there are any similar companies, case studies, or articles, etc.
But it would be VERY helpful if there were some guidelines to understand the best way to do this.

Do you have any news on this?

4

Have you identified any impact caused by those small indices? I don't think you should worry about it unless you have any impact that is caused by it.

There is the recommendation to avoid have too many small indices as they result in too many small shards, but at the same time Elastic and Kibana creates a lot of system and internal indices that will be small in nature, this seems like a contradiction. I've questioned this in an old post that I cannot find and the response was that new versions (8+) deal way better with this cases than previous versions, so I would not worry unless this is already causing problems.

I think it really depends on what you want to offer and how you want to manage it, if you have different clients I would avoid having a single indice and use a field to do some document level security.

Also having a single index for different clients/organizations may impact in retention if there are different retentions requirements.

I would say that having a different namespace is a better approach because this is a hard separation of the data, they will be in different datastreams, using a field to do document level security in my opinion makes the management harder.

I'm not sure how MSSP are doing because I do not work on one or have contact with people that do, but in the past when I worked in a company that offered similar services, we had one cluster per client (infra + license costs were included in the contracts).

5

Noted.

Calculate? In what units do you expect an answer?

A similar question is how many is too many Spaces/Customers per cluster?

Though I don't question the accuracy of the claim, I am not convinced it's that important/noteworthy. I certainly dont speak for Elastic, but generic advice to avoid too many small indices is certainly valid in lots of cases, but the actual impact depends heavily on what the usage patterns of those indices? And it's clear that Elastic dont rigidly follow that specific advice themselves, but we can at least hope they know what they are doing!?

000s of tiny shards full of user data thats been actively ingested/aggregated/queried/updated is a lot different from say a tiny index that has some space-specific info that is close to static.

Ergo, I personally place close to zero weight on the "+1 space == +17 indices" observation.

This is how I would think about it too. I know in 2026 its maybe not cool to think that way, but knowing "customers" I'd personally sleep better knowing that customer A's service does not depend, as much as is achievable, on either customers B/C/D/E/... being sensible users, or me not missing something in optimizing the isolation of customers operationally / access and resource control / complex configuration / .... If that means I'm not a great fit for a MSSP style business, then I'm going to concede that quickly.