Is this actually the case if we have one beat.Client instance per input/prospector instead of one beat.Client per harvester?
Nice catch. I'd say my comment is somewhat wrong. The way filebeat currently works, the limit is not per harvester, but per input.
One input configuration can create an unknown number of harvesters. As users can not configure the number of harvesters, I'd say it would make sense for filebeat inputs to always apply the limit/policy to the complete input, such that the 500eps would be a shared bandwidth limitation for all harvester created per input. Enforcing this semantics also reduces the per Beat implementation details/abstractions leaking into configs.