5 ms·
Seems like their problem was that they used S3 behind CloudFront. Do they not know that Cloudfront supports custom origins?
by Apreche 14y ago
Seems like their problem was that they used S3 behind CloudFront. Do they not know that Cloudfront supports custom origins?
- vikrum 14y agoYep, that was precisely our problem :) We wound up using a custom origin with Fastly. We made the switch off of Cloudfront since they don't support custom SSL domains and the Cloudfront dashboard left a lot to be desired.
- mayop100 14y agoAlso, the invalidation on Cloudfront is pretty painful.
- rrjamie 14y agoUsing S3 as an origin isn't a terrible idea, especially if you want very high availability for a low ops overhead. We use S3 behind Edgecast, and it works great. We also have a standby server and CDN in case we need to failover at the DNS level in the unlikely case either of those go down. This may be overkill for other sites, who probably should spend time planning for far more likely interruptions to availability (EC2 interruptions, etc). CloudFront invalidation is definitely a pain, since they have no global purge or prefix purge (/bar/foo/*). CloudFront also won't handle Content-Encoding negotiation for you, though it will Vary on it if you ask it to. We used CF in the past, and had a bunch of machinery to purge just those assets that changed. S3 is wonderful, but CloudFront is missing a few bits, despite having a great price at a low volume.