Cloudfront

This blog post was inspired by a question on stackoverflow. The user experienced intermittent HTTP 500 error codes from CloudFront. They seemed confident, that their setup was correct, so I was intrigued. The user had deployed a static website to S3 and was using CloudFront in a continuous deployment configuration. That’s a setup, where you have two distributions - production and staging. In such a setup, you can test configuration changes in the staging distribution and divert a fraction of production traffic to it in order to to see how it behaves. Once you’re satisfied with your configuration changes in the staging environment, you promote them to the production distribution and serve all traffic from there. ...

Lambda@Edge allows you to run your own business logic as part of the CloudFront request flow. You can intercept all requests that arrive at CloudFront, all connections to the origin and the responses from the origin and to the client. Lambda@Edge functions come with a series of constraints that make them different from regular Lambda functions, but also a lot of commonalities. One of these is the concurrency quota, which you should check before a production deployment. ...

Lambda@Edge functions are executed in multiple regions around the world, but which ones exactly? In this post we’ll find out together, which will enable us to pre-create log groups and other resources for them.