Same here, noticed a huge spike in bandwidth for my startup's shows hosted on CloudFront. 206 responses are flooding my logs and I moved everything off of CloudFront for my users to triage the cost. This breakdown explains it all: http://cl.ly/image/2H3u3u2O333g
Talk about a pain, not to mention the 10x bill from Amazon that came as a surprise.
You are correct and I should have wrote that note differently. I moved some high traffic files to some endpoints I have where bandwidth isn't a concern to change the formula a bit (primary) and the rest are back to using basic S3 for now. The bandwidth is still being consumed, however now it's easier on the wallet.
After looking more closely at the differences for pricing between S3/CloudFront I realize it's appears cheaper to be on CloudFront. I assumed wrong that CloudFront data-out was billed in addition to S3 because of the way it's notated on the usage page ("AWS Data Transfer (excluding Amazon CloudFront)"). To prove it I ran two reports on CF (left) and S3 (right): http://cl.ly/image/0q0y3u2X0g1a and you can tell where I made the change, as well data is only counted on the service in question and not on both.
Yeah, that's a bit confusing. Using Cloudfront with an S3 bucket is double billed, the first time. On a cache miss Cloudfront pulls the object from S3 and serves it to the client. S3 bills the regular data transfer out. Cloudfront then bills the regular data out to client rate.
On subsequent requests, cloudfront cache hits, you're only billed by Cloudfront. Cloudfront request + byte rates are cheaper than S3 in Us-east-1, IIRC. So on popular or high ttl objects it's cheaper to serve through Cloudfront. On low ttl or low rps, like a few requests per day, it's cheaper to use standalone s3.
The same origin + CDN vs CDN Hit math applies to EC2 as well. I do wish the billing was clearer in these scenarios.