HTTPS requests are typically 1/3 more expensive than HTTP.
Bandwidth prices are different depending on which of 8 regions the traffic is served from. Oh, and the bandwidth pricing lowers depending on how much you use (anywhere from $0.085 per GB for <10TB to $0.020 per GB if you serve in excess of 5PB).
For this example (and it appears to hold true across the variations) I will show that requests less than 15KB needs to be aggressively cached, or would be cheaper to embed into a webpage as raw data.
Let's take a low usage HTTPS website in Europe. Bandwidth is charged at $0.085 per GB and $0.0120 per 10,000 HTTPS REQUESTS
$0.000001275 per 15KB of Bandwidth.
$0.0000012 per HTTPS REQUEST.
So, if you are only going to serve an image to someone once, it's cheaper to embed if it's less than 15KB rather than link to it and invoke another request.
In the case of this website, I have 4 small images for the social sites I want to link to. They are embedded in the html and take up a total of 2750 characters of base64 data.
To serve them to you costs me $0.00000023375 in bandwidth. If I had linked to them as images, it would have been twenty times the price at $0.0000048. You would have to view 20 pages on this site before it becomes the wrong choice. For me, I know from usage stats that the average visitor only views a few pages on craig.mayhew.io.
If my website was more popular, this ratio get's even more favourable. At the "over 5PB" pricing, I could serve you those same embedded images 85 times before I should turn them into cachable requests.