AWS Lambda – the future of event driven automation

November 5, 2015 | Comments(0) |

Lambda is a compute service in Amazon Web Services, which triggers actions based on the events. Lambda is efficient and event driven which responses to events from either objects added or removed from S3, updating to DynamoDB tables, SNS, data in Kinesis Stream, Cloudwatch logs, In-App activity etc. Once our code is uploaded to Lambda, this service handles all the capacity, scaling, patching and administration of the infrastructure needed to run our code and also provides us with greater visibility of performance by publishing us with logs and metrics to Amazon CloudWatch.Lambda is cost- effective as it helps in running our code without any provisioning and managing servers with high availability.  AWS has been adding a lot of new features. AWS Lambda supports only 4 AWS regions, which include US-East (North Virginia), US-West (Oregon), EU-West (Ireland) and Asia Pacific (Tokyo). AWS provided support for writing Lambda functions in Node.js language and added Java Programming Language recently this year. New features are added in Lambda to help developers and other community people to make life much simpler and easy.

Recently, AWS Lambda function has brought in new features;

  • Functions can now be written in Python Programming Language.
  • Lambda functions now support Versioning and aliases.
  • It can also perform scheduled tasks (similar to cron jobs).
  • The execution time has been increased to 300sec (5 min).

Lambda is all about functions, so let’s take a look at each of these new features

Lambda functions support Python Programming Language:

As we know that AWS Lambda has support for writing functions in Node.js and Java, recently Python is added to that list which is very easy to learn and use. Python 2.7 comes with in-built access for AWS SDK for python. Python code must be zipped together with dependencies and uploaded to AWS Lambda using AWS CLI or using console.  

Lambda supports Versioning and Aliases:

Lambda now supports versioning, which helps to maintain multiple versions of our Lambda function code and helps to achieve the execution in different environments like PROD, DEV, TEST etc. Versioning also allows us to publish one or more versions of our Lambda function code helping in rollback to previous version if there is any error in current version. Each Lambda function version will have there own ARN. After publishing the version of our Lambda function code, the code of the corresponding version will become immutable i.e. the code cannot be changed. AWS Lambda supports aliases for each of our Lambda function versions. Its alias is a pointer, which points to specific Lambda version. Each alias has an ARN, which cannot point to another alias.

NOTE: Versions after publishing will become immutable, whereas alias are mutable and can be updated accordingly.

Example of alias in Lambda: Suppose the event source for Lambda is S3 Bucket and whenever we choose S3 bucket as event source, we need to perform few notification changes in S3 bucket:

  • We need to add the event source in the AWS S3 to know which Lambda function it has to invoke.
  • In notification configuration of our S3 bucket, we need to specify ARN of our Lambda function that S3 bucket has to invoke whenever new object is created or object is removed.

This will invoke the Lambda function whenever the object is created or removed for S3 bucket. But in this case, each time we publish our version we have to update in notification configuration of S3 bucket to invoke correct Lambda function version. Instead of specifying our Lambda function version ARN, we can specify our Lambda function alias ARN in notification configuration. (Example: PROD alias ARN) and we don’t need to update notification configuration in S3 events. If we promote new versions of our Lambda function, we need to add only PROD alias ARN of that corresponding version. Aliases which is pointing to one version can easily point to another updated version and helps us to easily roll back whenever any problems arises. We can refer to our Lambda functions using ARNs.

There will be two ARNs associated with initial version;

Qualified ARN: The function which is having version suffix is called as Qualified ARN

ex: arn:aws:lambda:aws-region:account-id:function:HelloWorld:$LATEST

UnQualified ARN: The function which is not having any version suffix is called UnQualified ARN

ex:  arn:aws:lambda:aws-region:account-id:function:HelloWorld

UnQualified ARN can be used in all the relevant operatoins but we will not able to create an alias and they will be having their own resource policies.

AWS Lambda now also supports Scheduled tasks (It will replace cron jobs):

AWS Lambda has come up with amazing feature, which will invoke our Lambda function code on regular and scheduled basis similar to cron jobs. For running cronjobs, we need to have one separate EC2 server running forever, which will cost that can be easily overcome by AWS Lambda scheduling feature . Our AWS Lambda function will be invoked only at particular scheduled time and we don’t need to take care of any EC2 server running, because Lambda will take care of provisioning and managing of servers. It is very  cost-effective as the pricing is applicable only for the amount of the time Lambda function code runs. We can specify a fixed data, which includes the number of minutes, hours or days or we may specify a cron expression (minutes: 0-59, hours: 0-23, days: 1-31, month: [1-12]or [JAN-DEC], days of week: [1-7]or[SUN-SAT], year:[1970-2199]).


Execution time for Lambda functions has increased:

AWS Lambda function’s execution time has increased from 1 min(60 sec) to 5 min(300 sec). Lambda functions can scale up to process large volumes of data , in such scenarios the execution time can be increased up to 300 sec.We can specify the required timeout while creating our Lambda function as shown. 2015-11-05 13-46-43



Leave a Reply