WARN max_connections from pt-variable-advisor - what to configure for DBaaS?
There is a difference between Threads_running and Threads_connected.  The former implies that many queries are simultaneously doing something.  The other are sleeping, waiting for the user (or app) to present another SQL statement to the server.

max_connections is a limit on Threads_connected.  (Max_used_connections is a "high-water-mark".)

A typical busy system will have only 1 in 7 'connected' threads actually running.  And Threads_connected is typically much less than max_connections.  (Like 20x)

But, in bad times, too many connections each doing some slow query, leads to MySQL stumbling over itself.  Throughput (queries/second) hits some maximum and may even go down; latency goes through the roof, and a panicky DBA will reboot the machine because he thinks it has crashed, not just gotten terribly tangled up.

The solution is to find the slow queries and figure out how to speed them up.  Or re-architect the app to be more efficient.  Or change the schema and indexes.  It is rarely to get bigger hardware or change the tunables.

In a well-managed MySQL server, I rarely see more than 2-3 cores in use.  Yet, thousands of queries/second can be performed even with very few cores active.

In DBaaS, you are at the mercy of the customers.  Any one of them can write a sloppy app that hogs connections, cores, I/O, network bandwidth, anything.

Consider limiting each user to 10 connections unless he explains what he needs to do and/or pays you more money.  With the extra money, you can isolate him in a separate VM.  I once estimated, in a shop with Apache and MySQL, that 10 threads would swamp Apache, to MaxChild needed to be much lower than the default.  (We had rather heavy pages.)  If you have control over web servers, limit how many threads they have.  That is stop the problem before it gets to MySQL.

By putting every user in his own VM, you consume extra resources, but you can prevent the excesses of one from harming the others.

I'll bet many of your clients use WordPress?  Here's one performance patch to the schema:  http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta