Doesn't this mean that you have reduced/removed the scalability or CDN features of S3? Since all requests now go through the nginx server. You are effectively using S3 to store the files, then piping them through this nginx server.
@cbess CloudFrount CDN is not feature of S3! CloudFront can use S3 just as origin.
For some reason CDN is not an option for certain business purposes, such data privacy, specific geo-location (if should not be replicated to another regions).
@mikhailov Correct, S3 is not a CDN. However, my point was that you reduce the scalability by having all traffic diverge to your server. Meaning, you take on the entire load of S3 traffic, thereby sidestepping its ability to scale requests. Aren't you taking the hit for bandwidth and CPU load to serve through nginx? Nginx has to serve and buffer the request to the client. Thanks for the clarification.
@cbess this solution is not for everybody, but for specific requirements. Please re-read the post again. Sure, proxy doubles the traffic and use CPU, in terms of scalability it solves by using array of Nginx servers.
@mikhailov Thanks for the post. Can you also please guide us as to how to write a custom proxy module for nginx instead of using the configuration. We need to do a check in database before proxy-ing to s3 for some security reasons. We do not want to serve all requests and rules are written in a database. So if a rule with the request does not match we throw a 404.
Thanks for this, I used it with XSendfile which makes this even more awesome! If you have never used XSendfile (or X-Accel-Redirect as nginx calls it) it is worth a look. You can use it with proxy pass, so it makes it ideal for a setup like this.
Great article. One minor point - When you say "High SLA" I think you mean "High Redundancy" (S3 actually has NO SLA (Service level agreement) - It could down for a week and you'd have no legal recourse)