"Dont forget that QoS is necessary IF you dont have enough bandwidth."
BTW, not always true and sometimes QoS is even useful when there's enough bandwidth.
"If one application requires 1 Mbps and you have 100 application like that, you dont need to multiply by 100."
Often true, but finding the "correct" allocation amount can be "tricky", when this isn't done. Further, sometimes/often you really do need to "guarantee" max flow rate times max flow usage is available.
QoS, might be used to provide the "guarantee" yet still allow other traffic to use the moment-by-moment unused bandwidth for other purposes.
Addendum
Since @Flavio Miranda mentions video as a consideration, let's explore video demands and/or QoS, as a good example of why I note correct bandwidth allocations can be "tricky" and also how QoS can sometimes help.
Assume we have a (digital) video signal, uncompressed, and at a constant bit rate of 1 Mbps. How much bandwidth do we need to transmit it from point A to point B? We'll need 1 Mbps.
Further assume we now encode our 1 Mbps video signal using MPEG4, creating an average 250 Kbps bandwidth consumption. How much bandwidth do we need to transmit it from point A to point B? We'll need 250 Kbps, right? Probably not enough, as "average" consumption that's 100% of available, often creates almost an infinite queue. I.e. we'll need excess bandwidth to avoid queuing, but how much? Well, if you still have 1 Mbps of available bandwidth, there should be the need for no queuing. I.e. We'll want something in the range of 250 Kbps to 1 Mbps, but exactly where?
As a very rough rule, consider up to 1/3 average utilization has very little need to queue, 1/3 to 2/3 some queuing, and 2/3 and up, much queuing. (NB: the queuing need increases, non-linearly, as usage percentage increases.) Usually, if we have 3x to 2x the available bandwidth to average utilization, we have little to minimal queuing.
So, for our (average) 250 Kbps video stream, we should make available to it, 500 to 750 Kbps.
Are we done? No, because there are two main "kinds" of video. First is streaming video, the second is real-time video.
For streaming video, clients tend to "buffer" a few seconds of video. This means, such video tolerate some queuing. I.e. for such traffic, again for our 250 Kbps stream, 500 Kbps, or even a tad less, might be just fine. We do, though, need to insure there's sufficient buffer/queue space to not drop packets (NB: as bandwidth is decreased, more buffer/queue space will be needed).
For real-time video, clients do not buffer video. This means such video cannot tolerate much, if any, queuing. I.e. for such traffic, again for our 250 Kbps stream, 750 Kbps, or even a tad more, might be just fine. 1 Mbps, though, guarantees no need to queue at all.
The forgoing addresses just one video stream bandwidth's need. If there are other concurrent traffic flows, are bandwidth allocations different from just x times number of flows? Or, if the other traffic is "different", does that effect x times number of flows?
Yes and no to both. More like video flows create a "tighter" overall average bandwidth consumption, which appears to allow decreasing overall bandwidth allocation, but increases the likely hood of a "perfect storm", i.e. all your video flows "crash" at the same time. This, though, will be less often than how one or few flows would be impacted. (Unsure of the math, but suspect overall average, per flow "crash", might work out to be about the same. I.e. less often occurrence with many flows, but a "crash" with many flows, crashes many flows per crash.)
The impact of other traffic types, without any QoS, often makes it impossible to guarantee any service level without physically setting aside bandwidth. I.e. we might need to dedicate a link, or "channel" it's bandwidth, to guarantee our video has the bandwidth its needs to function as desired.
With QoS, we can guarantee bandwidth, you need not lock up all the time. For example, on a 2 Mbps link, we can guarantee our video, for example, 1 Mbps, but as it averages 250 Kbps, we have 1.750 Mbps, on average, available for other traffic use. (An example of where QoS can be of benefit even when it appears we have sufficient bandwidth.)
