Introduction to AWS Lambda

Introduction and Aim
The purpose of this lab is to gain a basic understanding of AWS Lambda through creating and ‘deploying a lambda function in an event driven environment’. -As stated in the QwikLabs lab script.
The labscript states that ‘Lambda is a compute service that runs code in response to events and automatically manages the compute resources, making it easy to build applications that respond quickly to new information.’ Lambda is serverless.



  • Create an AWS Lambda S3 event function
  • Configure an Amazon S3 bucket
  • Upload a file to an Amazon S3 bucket
  • Monitor AWS Lambda S3 functions through Amazon CloudWatch


Configure an Amazon S3 bucket as the Lambda event source
The first step in configuring an Amazon S3 is to determine the region the lab is running in. In my case, it’s Sydney. Under S3 services, the bucket I’ve created is called ql-lambda, and is set in my current region.

Create an S3 function
On the AWS console, Lambda is located in the Services. In the Lambda console, the ‘Get Started Now’ button is pushed, followed by the ‘New Function’ button.
Lambda The QwikLab instructions for creating the function are as follows:

Select Bluprint: S3-get-object
Configure Triggers: Set  bucket name to bucket that has just been created
Set Event Type to ‘Object Created (All)’
Enable Checkbox: Enable Trigger
InkedConfigure Triggers_LI

–> Next
Configure Function:
Name: S3Function
Description: S3 Function for Lambda
Runtime: Node.js
-There were two available .js nodes, so I chose Node.js 4.3
Configure part 1Handler: Leave as index.handler
Role: Choose an existing role
Existing Role: lambda-role
-As I’m not doing this through QwikLabs, there wasn’t an existing role called lambda-role. Instead, I  created a new role called lambda role. The lambda role contained two policies; Simple Microservice Permission, and S3 Object Read-Only Permission. I chose those two policies as they seemed to best fit the role required for this lab.
Configure part 2 (handler and role)
–> Advanced Settings
Memory (MB): 128
Timeout (s): 5

The final section involves the Review section, and then the function can be created.


Upload a file to an Amazon S3 bucket to trigger a Lambda event.
The next step is to upload a file to the S3 bucket in order to trigger a call to the Lambda function.
The file uploaded to the bucket, for the purpose of this test, contains only lowercase lettering with no spaces.
Bucket with Upload

In the Lambda functions page, the function itself can be clicked and then the ‘Monitoring’ tab can be opened. This will provide four graphs: Invocation count, Invocation duration, Invocation errors, and Throttled invocations.
Monitoring in Lambda
Below is a screenshot of the QwikLabs script, which explains what each graph measures.
Graph Explanation

All of this information can be viewed in CloudWatch. This can be accessed by clicking on the ‘View logs in CloudWatch’ button, which is located above the graphs. In the logs section of CloudWatch, the first log stream contains information on ‘Start Request’, ‘End Request’, and ‘Report Request’ of the associated lambda event.
cw log info


The information recorded when a Lambda event is triggered appears to be very informative for an overview of financial transactions. This sort of service implemented into a business may help keep track of business expenditure from staff.