Skip to main content

Serve and Process S3 Objects Request via CloudFront & Lambda@Edge.

Serve and Authenticate S3 Objects Request via CloudFront & Lambda@Edge:

Use Case :  Need to check if the Requester of a S3 object has the right permissions to access the requesting object.

Solution :
  1. Create s3 bucket and associate cloudFront distribution with it. 
  2. Create a lambda with your code.
  3. In lambda you can handle your object authentication request or check if the right person is accessing the right object.
  4. Add cloudfront event to the Lambda@Edge function. 
  5. Deploy Lambda@Edge function. 
  6. Select your CloudFront distribution and cloudFront event as Viewer Request (It caches request). Keep rest as default. 
  7. Now every request you make to your CloudFront will be monitored by Lambda function.

Ok now how did I do it :

CloudFront Lambda@Edge Architecture :

Lambda@Edge allows you to intelligently process HTTP requests at locations that are close (for latency purposes) to your users.

CloudFront provides events to be monitored whenever there is a request. It Monitors request via Lambda@Edge. You can do certern operations on request. Like modify, edit request headers, cookies. 
Here we are going to use Viewer Request event. Viewer Event it caches the request for lower latency where Origin Request does not.

Now first create a s3 bucket. I will call it as My-Fake-S3-Bucket.  I am adding one file photo.png with public access into the bucket.
Now, Let me create a CloudFront distribution for this bucket. 

I will keep object caching TTL as 0. For now

Now let it be up. Meanwhile Let’s jump to the Lambda function creation.. Create add IAM Role.. Pretty Basic huh.. Bla blah..
And we are here.. Whhhat a name! my-fake-function :-D 

Now let’s add some code.. (well, this is my requirement. Don't mind huh!) 

Now, We have deploy this to new version. And strange we can not use $LATEST lambda version for cloud front events. :-(

Click on actions and then publish new version.

 Add version description then hit Publish.

Now it's time to add trigger for our CloudFront for newly created version.

Remember Version of a lambda function is needed. Publish a version of a Lambda. Then create a trigger to CloudFront. Do not wait till distribution becomes available again. Nope it's not needed unless it says.

Voila.. You are now. Now every Request is monitored. 

Hit CloudFront url with header : authorization

You will be able to access the photo you have kept in in s3 bucket.

And without authorization header. You will end up on ;-)

That’s it!

If you have any insights, corrections or recommendations about above problem. Email me at

Thank you for taking some time to read my article. Appreciate It!

Happy Reading..


  1. Great Article
    Cloud Computing Projects

    Networking Projects

    Final Year Projects for CSE

    JavaScript Training in Chennai

    JavaScript Training in Chennai

    The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training


Post a Comment

Popular posts from this blog

Going deep into the Instagram’s feed ranking algorithm

Going deep into the Instagram’s feed ranking algorithm Ranking algorithms means feed posts showing up based on what Instagram thinks you want to see and not just the newest posts first. Let's check the Instagram’s giant feed handling –   They never revealed how the feed algorithm worked until they called upon a group of reporters to their San-Francisco office and pulled the curtains off from the Instagram feed ranking algorithm. They explained the reporters that there were three factors where an individual’s engagement to the app is taken care of, the three being: -

Auto Scaling DynamoDB

Those of you who have worked with the DynamoDB long enough, will be aware of the tricky scaling policies of DynamoDB. It allows user to explicitly set requests per second (units per second, but for simplicity we will just say request per second). User can do so for read as well as write operations. Anytime user can increase or decrease the provision capacity from DynamoDB web console and it will reflect immediately. Sounds all good....... Or not? What if you set provisioned capacity to 50 req per second but load on the server crosses 100 req per second? Requests gets throttled!! Mostly times out. What's worse? This can cause requests getting queued up in your web server. Which can potentially bring your entire server down. What if you set provisioned capacity to 1000 req per second but load on the server is only 100 req per second through out the day? You lose your hard earned money for remaining 900 req per second. What if you set it to 1000 req per sec and then realis