In terms of bandwidth, I consider only the HTTP(S) part, and neglect DNS. I estimate the traffic at HTTP payload level, thereby neglecting the overhead added by lower layer encapsulations (probably TCP > IP > MPLS > Ethernet). Most importantly, I estimate downstream traffic only, i.e., I do not seek to estimate Google's internal traffic between datacenters.
Youtube -- around ~20Tb/s downstream capacity requiredWe can estimate Youtube average downstream traffic as: [downstream traffic for Youtube] = [number of minutes of videos watched on youtube / month] * [downstream data per minute a video watched]
Youtube statistics provide the data required for our calculations: "Over 6 billion hours of video are watched each month on YouTube".
The bitrate of a video depends on its resolution, codec, and encoding quality. Let's take a simple assumption: a 90 minutes movies weigths about 900MBytes. So let's take 10MBytes per minute as the average bitrate for youtube video.
This gives us:
[downstream traffic per month for Youtube] = 6 *10^9 * 60 * 10^7 Bytes / month
= 3.6 * 10^18 Bytes / month
= 2.9 * 10^19 Bits /month
Let's convert this to the average downstream capacity required by Google for Youtube: [average downstream bandwidth for Youtube] = [downstream traffic per month for Youtube] / [number of seconds in a month] = 2.9 * 10^19 / (30.5 * 24 * 60 *60) Bits/s = 11 Tb/s
Now let's calculate the capacity to handle peak hour, considering that the peak traffic is about twice the average traffic. [required downstream capacity per month for Youtube] = 2 * [average downstream bandwidth for Youtube] ~= 22 Tb/s
That's enormous !!
Let's do a sanity check on this figure. It's larger than what I expected to find actually. The reason for this is the bitrate of the videos. Most video are not HD, so they do not weight 10MBytes / minute. Maybe we should divide our estimate by 2. But that's not the point: I am looking for an estimate of the order of magnitude, not for the exact figure.