Tag: lambda

What are AWS Lambda Functions?

November 7th, 2023
Reading Time: 4 minutes
AWS Lambda is a serverless computing technology offered by Amazon Web Services (AWS). It allows you to run your code without the need to provision or manage servers. AWS Lambda functions are pieces of code that can be executed in response to certain events or triggers. These functions can be written in various programming languages such as Python, Node.js, Java and more.

The main advantage of using AWS Lambda functions is that you only pay for the actual compute time that your code consumes, rather than paying for servers that might remain idle. This helps in reducing costs and enables automatic scaling based on the demand of your applications.

Lambda functions can be triggered by various events, such as changes to data in an Amazon S3 bucket, updates to a DynamoDB table, API Gateway requests, scheduled AWS CloudWatch events, or custom events produced by other AWS services.

AWS Lambda functions are commonly used in serverless architectures, where different functions can be connected together to build complex applications without the need for managing underlying infrastructure. It provides a highly scalable, event-driven architecture that allows developers to focus on writing code and delivering business value without worrying about managing servers.

AWS Lambda functions support various programming languages such as:
1. Python: You can write Lambda functions using Python, which offers simplicity and flexibility for a wide range of use cases.
2. Node.js: Node.js is a popular JavaScript runtime that allows you to write server-side applications using JavaScript. It offers fast execution and easy integration with other AWS services.
3. Java: Lambda functions can be written in Java, providing the ability to leverage existing Java libraries and frameworks. Java is known for its performance and scalability.
4. C#: If you prefer using C# for your serverless applications, AWS Lambda supports it. You can write Lambda functions in C# using the .NET Core runtime.
5. Custom Runtimes: AWS Lambda also offers support for custom runtimes, which means you can run functions written in other programming languages not natively supported by Lambda. This feature allows you to bring your own runtime and use it to execute your code.
These language options give you the flexibility to choose the programming language that best suits your needs and preferences when developing AWS Lambda functions.

AWS Lambda functions and Amazon Elastic Container Service (ECS) are both powerful services provided by Amazon Web Services (AWS) for running and executing code, but they differ in key aspects.

AWS Lambda is a serverless computing service that allows you to run your code without the need to provision or manage servers. With Lambda, you can write functions in various programming languages, such as Python, Node.js, Java, C#, and more. Lambda functions are event-driven and can be automatically triggered by events, such as changes in data in an S3 bucket or updates to a DynamoDB table. The main advantage of Lambda is its ability to scale automatically and charge you only for the compute time that your code consumes. This enables you to focus on writing code and delivering business value without worrying about managing servers or infrastructure.

On the other hand, Amazon ECS is a container orchestration service that allows you to run and manage Docker containers. ECS provides a highly scalable and customizable way to deploy and manage your containerized applications. With ECS, you have more control over the underlying infrastructure and can easily manage the cluster, networking, and storage options. You can use ECS to run long-running applications, microservices, and batch workloads. It supports integrations with other AWS services, such as Elastic Load Balancing, Elastic Block Store, and IAM.

When deciding between Lambda functions and ECS, you should consider the following factors:
1. Event-driven vs. Long-running: Lambda functions are ideal for event-driven, short-lived tasks that require rapid scaling and quick response times. ECS is better suited for long-running applications or services that require more control over the infrastructure and the ability to manage containers directly.
2. Scaling and Cost: Lambda automatically scales based on the incoming events and charges you only for the compute time consumed. ECS allows you to manually scale the underlying infrastructure, and you pay for the resources provisioned, regardless of the container utilization.
3. Infrastructure Management: With Lambda, AWS takes care of managing server infrastructure, automatic scaling, and availability. ECS requires you to manage the underlying infrastructure, including the cluster, EC2 instances, load balancers, and scaling policies.
4. Code Flexibility: Lambda supports multiple programming languages and is well-suited for smaller functions. ECS allows you to run any code within a container as long as it is compatible with Docker.
In summary, AWS Lambda is a great choice for event-driven, short-lived tasks where automatic scaling and billing based on usage are important. Amazon ECS provides more flexibility and control over the infrastructure, making it suitable for long-running applications and services that require custom networking and storage configurations.

AWS Lambda be cost-effective for many use cases. One of the key advantages of using Lambda is that you only pay for the actual compute time that your code consumes, rather than paying for servers that might remain idle. This helps in reducing costs and enables automatic scaling based on the demand of your applications.

The pricing for AWS Lambda is based on the number of requests made to your functions and the duration of the execution. There is no charge for idle time, and you are only billed for the time your code takes to execute.

The cost of Lambda functions can vary depending on factors such as the number of requests, the amount of memory allocated to the function, and the execution time. AWS offers a pricing calculator that can help you estimate your costs based on your specific requirements.

It’s important to note that while Lambda functions can be cost-effective for certain workloads, they may not be the most cost-efficient solution for all use cases. If you have long-running or consistently high-traffic workloads, other compute services like

March 29, 2023Mocking AWS SSM with Jest and TypeScript
February 14, 2023How to use Handlebars in an AWS Lambda function
January 29, 2023How to write to S3 bucket from Lambda function
January 29, 2023Mock AWS SDK with Jest in TypeScript
January 29, 2023Handlebars and AWS Lambda example
February 14, 2022AWS AppFlow error conflict executing request connector profile is associated with one or more flows

How to write to S3 bucket from Lambda function

January 29th, 2023

Reading Time: 2 minutes

AWS Lambda functions are a great way to automate certain tasks and processes in the cloud. They can be triggered by events, such as a file upload to an S3 bucket or a message sent to an SNS topic, allowing you to execute some code in response.

In this post, we’ll show you how to write data to an S3 bucket from a Lambda function. This can be useful for a variety of tasks, such as archiving log files or uploading data to a data lake.

S3 (Simple Storage Service) is Amazon’s cloud storage solution that allows you to store and access data from anywhere in the world. Writing to an S3 bucket from a Lambda function is a simple way to store and access data in the cloud.

In this post, I’ll walk you through how to write to an S3 bucket from a Lambda function. We’ll use the AWS SDK for Node.js to access S3.

Take this example as a starting point. This is not a production-ready code, probably some tweaks for permissions will be necessary to meet your requirements.

AWS resources we need

Lambda Function
S3 Bucket
Lambda Role
Bucket Policy

The Lambda function

const AWS = require("aws-sdk");
const s3 = new AWS.S3({
    region: "us-east-1",
});
let response;

exports.lambdaHandler = async (event, context) => {
    try {
        console.log(event);
        const params = {
            Bucket: process.env.MY_BUCKET,
            Key: 'test-file.txt',
            Body: "test content"
        }
        console.log('writing to s3', params);
        const result =  await s3.putObject(params).promise();
        console.log(result);

        response = {
            'statusCode': 200,
        }
    } catch (err) {
        console.log(err);
        return err;
    }

    return response
};

The SAM template

For the sake of simplicity, we are going to use Principal: “*” which makes your bucket 100% public!

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  Sample SAM Template for Lambda and S3
Parameters:
  Environment:
    Type: String
    Description: Environment name. Example, staging
Resources:
  MyLambda:
    Type: AWS::Serverless::Function
    DependsOn:
      - "MyBucket"
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Environment:
        Variables:
          MY_BUCKET:
            Ref: "MyBucket"
      Role:
        Fn::GetAtt:
          - "MyLambdaRole"
          - "Arn"
    Tags:
      Name: !Sub "${Environment}-my-test-lambda"

  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "${Environment}-my-test-bucket"

  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      PolicyDocument:
        Id: BucketPolicy
        Version: 2012-10-17
        Statement:
          - Sid: AccessAll
            Action: s3:*
            Effect: Allow
            # Beware: this makes your bucket public!
            Principal: "*"
            Resource: !Join
              - ''
              - - 'arn:aws:s3:::'
                - !Ref MyBucket
                - /*
      Bucket: !Ref MyBucket

  MyLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Action: "sts:AssumeRole"
            Principal:
              Service:
                - "lambda.amazonaws.com"
        Version: "2012-10-17"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: MyLambdaPolicy
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action: "s3:*"
                Resource:
                  - Fn::GetAtt:
                      - "MyBucket"
                      - "Arn"
            Version: "2012-10-17"

As a good practice, always receive the environment as a parameter. This way, all your resources will be easier to identify.

Deploy

Build our lambda and template. This will check also the syntax of your template

$ sam build

Only for the first time run and follow the steps:

$ sam deploy --guided

The second time and so on you can execute:

$ sam deploy --no-confirm-changeset

Clean up your test AWS resources. Delete unused lambdas, buckets, etc to keep your account organized and the most important: no extra costs

Resources

Handlebars and AWS Lambda example

January 29th, 2023
Reading Time: 2 minutes
In today’s post, we’ll explore how to use Handlebars with AWS Lambda, and how this can help you build dynamic and customizable web applications.

Firstly, let’s take a quick look at what Handlebars is. It’s a popular templating engine that allows you to define dynamic templates using a simple syntax. Handlebars templates are flexible, and allow you to inject data into your web applications based on user input, real-time data, and more.

So, how can we use Handlebars with AWS Lambda? The flexibility of Lambda allows us to define and execute serverless functions based on events such as HTTP requests, user interactions, and more. By building a Handlebars template within a Lambda function, you can dynamically generate HTML pages based on user input or other parameters.

Here’s an example of how you can use Handlebars with AWS Lambda in a Node.js environment:
```
const handlebars = require('handlebars');
const {promises: {readFile}} = require("fs");

let templateSource;

const renderToString = async (data) => {
    if(!templateSource) templateSource = await readFile('./views/content.hbs', {encoding:'utf8', flag:'r'})
    const template = handlebars.compile(templateSource);
    return template(data);
}

let response;
let html;
const lambdaLoadedDate = new Date().toISOString();

exports.lambdaHandler = async (event, context) => {
    try {
        const now = new Date().toISOString();
        html = await renderToString({title: 'im the title', now: now, lambda_date: lambdaLoadedDate});
        response = {
            statusCode: 200,
            headers: {
                'Content-Type': 'text/html',
            },
            body: html
        }
    } catch (err) {
        console.log(err);
        return err;
    }

    return response
};
```
Handlebars is an easy-to-use templating language that helps you create rich and dynamic websites. With its intuitive syntax and powerful features, it’s a great choice for quickly and easily building powerful web applications.

Combining Handlebars with AWS Lambda can make your life even easier. AWS Lambda is a serverless compute service that can run code without needing to provision or manage servers. By using Handlebars alongside AWS Lambda, you can quickly create websites or applications without having to write a lot of code.

How to trigger a Lambda Function from S3

July 27th, 2021

Reading Time: 2 minutes

If your application requires you to be able to trigger a Lambda function from S3, it is possible to do so using the Amazon Simple Storage Service (Amazon S3). With Amazon S3, you can set up an event notification on an Amazon S3 bucket that will send a notification to an AWS Lambda function when an object is created or deleted. In this post, we will walk through the steps to trigger a Lambda function from S3.

Sometimes we need to let a Lambda know when a new file was created in an S3 bucket. That’s can be the case when we have a data lake and we want to process those files. But beware, when we talk about a data lake, we mean a huge amount of data so we shouldn’t start processing immediately a file is written since our capacity can be limited. In that case, we should use a queue mechanism but that is out of the scope of this post so Let’s concentrate on our specific problem: trigger a Lambda from S3.

We could do this from the console using point and click but as a good practice, let’s automate this provisioning with Cloudformation. This way we will be able to move our code across different accounts and deal with environments easily.

The Cloudformation approach can be slow at the beginning but once you get familiar with it, you will accelerate your dev process. Another big advantage of Cloudfromation is versioning. Since our output is a yml file, it can be easily add it to a github repo. Thus, tracking changes becomes a piece of cake. However, you may resolve your problem first from the console and then translate it to Cloudformation

Let’s do it step by step, building small pieces of Cloudformation components, deploy them and then put all together in one file.

Have in mind this is not a production-ready solution. Probably you will have to make your own customizations so take this as a starting point.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  lambda-s3-trigger

  Sample SAM Template for lambda-s3-trigger

Globals:
  Function:
    Timeout: 3

Parameters:
  Environment:
    Type: String
    Description: Environment name. Example, staging, dev, prod, etc.

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Role:
        Fn::GetAtt:
          - "MyRole"
          - "Arn"
    Tags:
      Name: !Sub "${Environment}-my-function"


  MyRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: AccessToS3Notifications
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action:
                  - 's3:GetBucketNotification'
                  - 's3:PutBucketNotification'
                  - "s3:GetObject"
                Resource: !Sub 'arn:aws:s3:::${AWS::AccountId}-${Environment}-my-bucket'

  MyBucket:
    Type: AWS::S3::Bucket
    DependsOn:
      - MyFunction
    Properties:
      # the bucket name has the account as a prefix since it has to be unique globally at AWS level
      BucketName: !Sub "${AWS::AccountId}-${Environment}-my-bucket"
      NotificationConfiguration:
        LambdaConfigurations:
          - Event: 's3:ObjectCreated:*'
            Function: !GetAtt MyFunction.Arn

  PermissionForEventsToInvokeLambda:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt MyFunction.Arn
      Action: "lambda:InvokeFunction"
      Principal: "s3.amazonaws.com"
      SourceAccount: !Ref 'AWS::AccountId'

Build and deploy:

$ sam build
$ sam deploy --guided