> My understanding is that you would not have to pay for end-user access > to S3 content if you're using Cloudfront. You'd pay for end-user > access to that content via Cloudfront, and you'd have to pay the > normal S3 upload and storage fees for your own access to your bucket. > > That said, I would not bet the farm on my understanding here, as I > haven't really looked that closely at Cloudfront yet.
Well, it's a good thing you kept the farm out of the chip pile. :) I went back and re-read all the CloudFront stuff. Here are the highlights: "Amazon CloudFront uses Amazon S3 as the origin server to store the original, definitive versions of your files. Normal fees will apply for Amazon S3 usage, including âorigin fetchesâ â data transferred from Amazon S3 to edge locations." and... "Copying objects to edge locations When Amazon CloudFront receives a request for an object it doesnât already have at an edge location, it makes a standard GET request back to Amazon S3. You incur the normal Amazon S3 charges for GET requests and for data transfer out; the charges appear in the Amazon S3 portion of your AWS statement." On the topic of caching: "...when space is needed at an edge location, the service will remove less popular objects in order to make room for more popular ones. This means that objects that arenât accessed frequently are less likely to remain in CloudFrontâs edge locationsâ caches. Thus, for less popular objects, delivery out of Amazon S3 (rather than from CloudFront) is the better choice. Amazon S3 will provide strong distribution performance for these objects, and serving them directly from Amazon S3 saves you the cost of continually copying less popular objects from Amazon S3 to the edge locations in CloudFront." So it looks like CloudFront works best for objects that are accessed a lot. (duh) However, an object that was accessed infrequently might incur you additional charges because it is continually being copied back to the edge location. Not to mention that would defeat the purpose of the edge location since the transfer would have to come from the S3 servers. What the docs DON'T tell me is what other objects mine have to "compete" with to stay cached at an edge location. If I was sharing an edge location with a LOT of frequently accessed files from other customers, my object would probably experience more evictions than at a sleepier location. > Well, I don't know if it solves that problem or not, but because this > service is aimed specifically at HTTP usage for end-users of a web > site, I wouldn't be too surprised if they had. Ok, ready for something funny? I dredged Google some more and reality turns out to be the opposite of that. In fact, CloudFront has NO SSL support. None. They encourage you to use S3 for all your HTTPS traffic. Heh --so much for their service aimed specifically at HTTP usage. :) http://developer.amazonwebservices.com/connect/thread.jspa?threadID=26488&start=15&tstart=0 What's worse is one site claimed that CloudFront allows you to use up to 10 CNAMEs per distribution where S3 only allows one per bucket. (I needed at least 2) Well I guess I'm darned if I use S3 and darned it I used CloudFront. lol http://www.bucketexplorer.com/documentation/cloudfront--amazon-s3-vs-amazon-cloudfront.html I like the Amazon Web Services, but they have had a continual string of pretty big gotcha's-- like lack of server affinity support (sticky sessions) in their EC2 cloud. At least it's very cheap to sign up for and experiment with since there are no upfront contracts! ~Brad ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:328572 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
