DEV Community: Vishnu Prassad

Cloudwatch Custom Metrics With Embedded Metric Format

Vishnu Prassad — Mon, 30 Aug 2021 08:28:19 +0000

Introduction

Cloudwatch is an integral part of the AWS ecosystem. Every service in AWS reports to cloudwatch for the service logs, application logs, metrics, etc.

In this article let's discuss the cloudwatch custom metrics in detail.

Metrics help us with finding the performance of the AWS services and the applications we run using these services. It also allows us to visualize the data with graphs and dashboards and create alarms based on the data reported tho metrics. If you are new to cloudwatch and cloudwatch metrics you can learn the basic concepts here

Custom Metrics

By default, AWS provides free metrics for most of its services. Apart from its own service metrics, AWS allows us to publish custom metrics, which means we can send our application-specific metrics to cloudwatch metrics. for example, we can push the metrics for the duration of third-party api calls, or the count of status codes returned by an API, etc. Then we can create alarms, dashboards based on those metrics.

Now let's see how we can create custom metrics and put data points to them, There are three ways of creating custom cloudwatch metrics from your application.

AWS API's/SDK for cloudwatch metric
Metric Log Filters
Cloudwatch Embedded Metric Format

Let's see how we can create Custom metrics with the above three methods. For the demo purpose, let's assume we have an AWS lambda function that calls a weather API, and we want to create metrics around the API call duration and the count of status codes returned by the API endpoint.

AWS API's/SDK's

This method uses the AWS cloudwatch metrics SDK's putMetricData API to create the custom metrics. This method is pretty straightforward, but the problem with this method is that it will incur an additional API call and it can block other API calls in your application while putting metrics to cloudwatch. This could affect the latency of your application (for eg: REST APIs). Also, each putMetricData api call involves cost. AWS will charge $0.01 per 1000 requests.

Example

'use strict';

const axios = require('axios')
const AWS = require('aws-sdk')
const cloudwatch = new AWS.CloudWatch();


module.exports.handler = async (event) => {
  try {

    const startTime = new Date()
    const response = await axios.get('https://www.metaweather.com/api/location/2487956/2021/8/8')
    const apiStatusCode = response.status
    const endTime = new Date()

    console.log(apiStatusCode)

    const apiCallDuration = endTime - startTime

    const statusMetricParams = {
        MetricData: [ 
          {
            MetricName: 'status_code', 
            Dimensions: [
              {
                Name: 'status_code', 
                Value: `http_${apiStatusCode}` 
              },
            ],
            Timestamp: new Date(),
            Unit: 'Count',
            Value: 1,
          }
        ],
        Namespace: 'MetricFromSDK_1' 
    };

    await cloudwatch.putMetricData(statusMetricParams).promise();

    const durationMetricParams = {
        MetricData: [ 
            {
                MetricName: 'api_call_duration', 
                Dimensions: [
                    {
                    Name: 'api_name', 
                    Value: `location_api` 
                    },
                ],
                Timestamp: new Date(),
                Unit: 'Milliseconds',
                Value: apiCallDuration,
            }
        ],
        Namespace: 'MetricFromSDK_1' 
    };

    await cloudwatch.putMetricData(durationMetricParams).promise();

  } catch (error) {
    console.error('failed',error)
  }
};

Metric Log Filters

Metric log filters can search and filter data points needed to create metrics from Cloudwatch log groups. CloudWatch Logs uses these metric filters to turn log data into numerical CloudWatch metrics that you can graph or set an alarm on. When you create a metric from a log filter, you can also choose to assign dimensions and a unit to the metric. If you specify a unit, be sure to specify the correct one when you create the filter. Changing the unit for the filter later will have no effect.

With this method, the metrics are generated asynchronously. You don't need any additional API calls from the application to generate the metrics. You just need to log the metrics data in a JSON format in the application and create a metric filter for each metric on the applications cloudwatch log group which filters the metric data from the logs based on the filter expressions defined.

The only downside I see with this method is the creation of metric filters on log groups every time you need to create a new metric. You can create them manually or use any IaC tool to generate them on demand.

Example

'use strict';

const axios = require('axios')

module.exports.handler = async (event) => {
  try {

    const startTime = new Date()
    const response = await axios.get('https://www.metaweather.com/api/location/2487956/2021/8/8')
    const apiStatusCode = response.status
    const endTime = new Date()

    const apiCallDuration = endTime - startTime

    console.log({ metricName: 'api_call_duration', metricValue: apiCallDuration })
    console.log({ metricName: 'status_code_count', metricValue: apiStatusCode})

    console.log({[`http_${apiStatusCode}`]: 1})

  } catch (error) {
    console.error(error)
  }
};

Once the logs are pushed to cloudwatch logs, the next step is to create a metric filter on the log from which we want to filter the data points to generate the metric.

Follow the below screenshots to see how to create a metric filter based on the logs that we generate from the code. Once the metric filter is created properly and the filter patterns match with the logs it will create a metric and start pushing data points to it on every new log.

Cloudwatch Embedded Metric Format

The CloudWatch embedded metric format is a JSON specification used to instruct CloudWatch Logs to automatically extract metric values embedded in structured log events. You can use CloudWatch to graph and create alarms on the extracted metric values.

This is my personal favorite method. This is an asynchronous process, which means it does not make any API call to generate metrics, and no metric filters are needed. All you have to do is log your metrics to cloudwatch in a specific JSON format as documented here. AWS will automatically parse these logs from cloudwatch log groups and generate the metrics for you.

There are two ways to use this method,

Directly log the metrics in JSON format as documented here

Using embedded metric NPM module from AWS (Examples available at the modules GitHub page here)

Below is an example of the first method.

'use strict';

const axios = require('axios')

module.exports.handler = async (event) => {
  try {

    const startTime = new Date()
    const response = await axios.get('https://www.metaweather.com/api/location/2487956/2021/8/')
    const apiStatusCode = response.status
    const endTime = new Date()

    console.log(apiStatusCode)

    const apiCallDuration = endTime - startTime

    // Create Metric For Status Code Count
    console.log(
      JSON.stringify({
        message: '[Embedded Metric]', // Identifier for metric logs in CW logs
        status_code_count: 1, // Metric Name and value
        status_code: `http_${apiStatusCode}`, // Diamension name and value
        _aws: {
          Timestamp: Date.now(),
          CloudWatchMetrics: [
            {
              Namespace: `demo_2`,
              Dimensions: [['status_code']],
              Metrics: [
                {
                  Name: 'status_code_count',
                  Unit: 'Count',
                },
              ],
            },
          ],
        },
      })
    )

    // Create Metric For API Call Duration
    console.log(
      JSON.stringify({
        message: '[Embedded Metric]', // Identifier for metric logs in CW logs
        api_call_duration: apiCallDuration, // Metric Name and value
        api_name: 'location_api', // Diamension name and value
        _aws: {
          Timestamp: Date.now(),
          CloudWatchMetrics: [
            {
              Namespace: `demo_2`,
              Dimensions: [['api_name']],
              Metrics: [
                {
                  Name: 'api_call_duration',
                  Unit: 'Milliseconds',
                },
              ],
            },
          ],
        },
      })
    )

  } catch (error) {
    console.error(error)
  }
};

Below are the screenshots of the custom metrics we created with the above methods,

Name Space

Dimension

Metric

Conclusion

We have discussed three methods above, First one is synchronous and the other two are asynchronous. I personally prefer the asynchronous method because the metric generation process will not block the other API calls in the application.

Cloudwatch custom metrics can be used in the following scenarios,

Third-Party integration metrics(API call duration, success or failed count of processes, etc)

Custom metrics around events/processes in the application

AWS Limits To Keep In Mind While Developing A Serverless Application

Vishnu Prassad — Fri, 23 Oct 2020 09:56:09 +0000

Serverless is great, it helps companies to focus on product and application development without worrying much about the infrastructure and scaling. But there are some soft and hard limits for every AWS services which we need to keep in mind when we are developing a serverless application. These limits are meant to protect the customer as well as the provider against any unintentional use

In this article, we will talk about some of those limits and how to avoid them.

Deployment Limits

Lambda

50 MB: Function Deployment Package Size, 250 MB: Size of code/dependencies that you can zip into a deployment package (uncompressed .zip/.jar size)

There is a limit of 50MB on the package size of the code which we upload to lambda.

This limit is applied when we try to create or update a lambda function with the AWS CLI.

If you try to create the function from the AWS Web console it is limited to 10MB. We can avoid these limitations by uploading the ZIP file to S3 and create the function.

The total size of code/dependencies we can compress into the deployment package is limited to 250MB. In simple REST API cases, we may not hit these limits. But when we have to use binaries like FFMPEG or ML/AI libraries like scikit-learn or ntlk with lambda could hit this limit. these dependencies are high in size

Are these a soft limit? : NO

How to Avoid?

Use Serverless framework

By default serverless framework zip and deploys your code first to S3 and deploys it lambda via cloud formation.

Use WebPack

WebPack is a well-known tool serving to create bundles of assets (code and files). Webpack helps to reduce and optimize the packaging size by

- Include only the code used by your function
- Optimize your **npm** dependencies
- Use a single file for your source code

Optimizing and reducing the package size will also help to reduce the cold start of the functions.

75GB: Total Size Of All Deployment Packages That Can Be Uploaded Per Region

This limit is a region-wide soft limit. It can be increased by service Quota limit increase.

Most of the time people get hit by this limit is when they have a huge number of lambda functions and every time we update new code a new version of lambda is created. Each version has its own deployment package it will be counted towards this limit.

Is it a soft limit? : YES

How to avoid?
- Version your code and do not version functions. (Except for lambda@edge, For lambda@edge versioning is a must)
- Remove older or unused versions
- If you are updating the function via AWS CLI use --no-publish flag to not to create a new version on update.
- Keep only the latest version of the lambda function. Remove the older versions, and if we really needed to keep a specific older version of the function, add an ALIAS to those versions and remove all the unused versions.
512MB: Amount of data that be stored inside lambda instance during execution (/tmp)

If you want to download a file and store the /tmp directory to process it during the execution, this limit will be applied. You cannot store files into this directory only up to 512 MB, even if it is a single file or multiple files.

Is it a soft limit? : NO

How to avoid?
- Use ***the **Nodejs Stream* method to read and process and write files without loading the whole file into lambdas ****filesystem
6MB: Lambda payload limit

This means We cannot POST more than 6MB of data to Lambda through API Gateway. So if we build an image or video uploading API to upload files to S3, we are limited to this 6MB Limit.

Is it a soft limit? : NO

How to avoid?

There is a couple of workarounds to get rid of this limit.
- Use a pre-signed S3 URL.
  
  In this case,
  - The client makes an HTTP GET request to API Gateway, and the Lambda function generates and returns a
  - The client uploads the image to S3 directly, using the pre-signed S3 URL

Cloudformation

If you are using the serverless framework for deploying your application, as your application grows you may hit some of the cloudformation limits when you deploy as serverless framework uses cloudformation behind the scenes for deploying services.

A CloudFormation stack can have at most 500 resources

Let's take an example of a backend Application with multiple REST API's. This Application may have multiple Lambda functions, API Gateway Endpoints, Methods, Custom Domains, SNS Topics, DynamoDB, S3 Buckets, etc. When we deploy this application to AWS with cloudformation, it will create cloudformation resources for all the mentioned services in a single cloudformation stack. There will be multiple resources created per services(IAM roles, IAM Policies, Cloudwatch log groups). In the case of a single lambda function following resources will be created per each function,
- AWS::Lambda::Function
- AWS::Lambda::Version
- AWS::Logs::LogGroup
Plus additional resources will be added if we attach event-sources like API Gateway, SNS to the function

When the application grows, the total number of resources will also increase. And when it hit the 500 limit the deployments will start failing.

Is it a soft limit? : NO

How to Avoid?
Use Cloudformation Nested Stacks to Reuse Common Template Patterns,

As your infrastructure grows, common patterns can emerge in which you declare the same components in each of your templates. You can separate out these common components and create dedicated templates for them. That way, you can mix and match different templates but use nested stacks to create a single, unified stack. The nested solutions may buy you little time to avoid this limit, but as the stack grows it will be hard to manage it.

Use serverless split stack plugin

This plugin migrates CloudFormation resources into nested stacks in order to work around the 200 resource limit. There are built-in migration strategies that can be turned on or off as well as defining your own custom migrations.

The recommended way is, Try to create your services(Multiple Micro Services) as small as you can. Keep an eye on no resources every time you deploy the stack, and when you think the stack may hit the limit, break some of its features into alternative service.

An IAM role policy can have up to 10,240 characters

This is one of the other limits we may hit when the stack grows. This happens when the whole application uses a single IAM role. By default serverless will include all the basic and custom IAM policies for all the functions used by the application into one single IAM role.

How to Avoid?
- Create individual IAM roles for each function in the cloudformation stack instead of a single large IAM role for the whole stack. Using per-function roles is a recommended best practice to achieve and maintain the least privilege setup for your Lambda functions.
With the serverless framework, there are a couple of good plugins that help to do this.

Summary

It is a good practice to know all the limits of all the AWS services that you are going to use when designing your infrastructure and develop the application. This will help us with the following,

Avoid redesigning the architecture in the future when we hit the limit
Design scalable and fault-tolerant serverless infrastructure by planning and implementing workarounds to avoid hitting the limits or calculating and increasing the soft limit of each service as per the requirement of the application

DynamoDB CheatSheet For NodeJS/JavaScript

Vishnu Prassad — Fri, 28 Aug 2020 11:56:49 +0000

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB lets you offload the administrative burdens of operating and scaling a distributed database so that you don't have to worry about hardware provisioning, setup, and configuration, replication, software patching, or cluster scaling. DynamoDB also offers encryption at rest, which eliminates the operational burden and complexity involved in protecting sensitive data.

This cheat sheet will cover the most commonly used scenarios of data operations in DynamoDB with AWS DynamoDB Document client for JavaScript/Nodejs. The DynamoDB Document Client is the easiest and most preferred way to interact with a DynamoDB database from a Nodejs or JavaScript application.

GETTING STARTED

Install

npm install aws-sdk

Configure

const AWS = require('aws-sdk')
const ddb = new AWS.DynamoDB.DocumentClient()

CREATE ITEM

Let's create a new item for the new user. This user will have one album and one image in the album.

async function createItem (buildInfo) {
  console.log('Creating new item')
  let params = {
    TableName: tableName,
    Item: {
      'userId': 'johnDoe',
      'createdAt': 1598362623,
      'updatedAt': 1598362623,
      'albums': {
         'album1': {
            'id': 'album-kjuijhs342',
            'createdAt': 1598362623,
            'updatedAt': 1598362623,
            'description': 'My First Album',
            'Title': 'Holidays',
            'images': {
               'img-1': {
                  'filename': 'johndoe/album1/e8TtkC5xyv4.jpg',
                  's3Url': 's3://photo-bucket/johndoe/album1/e8TtkC5xyv4.jpg',
                  'tags': ['nature', 'animals']
                }
            }
         }
      }
    }
  }
  try {
    await ddb.put(params).promise()
  } catch (error) {
    console.log(error)
  }
}

SCAN

Scan and returns all items in a table

async function scan() {
  let params = {
    TableName: tableName
  }

  try {
    let x = await ddb.scan(params).promise()
    console.log(x)
  } catch (error) {
    console.error(error)
  }
}

GET ITEM

Get a single item from the table

async function getItem() {
  var params = {
    TableName: tableName,
    Key: {
      'userId': 'johnDoe'
    }
  }

  try {
    let res = await ddb.get(params).promise()
    console.log(res)
  } catch (error) {
    console.error(error)
  }

}

GET ONLY SOME DATA FROM AN ITEM

this will return only the tags from img1 and img2 in the result.

async function getSome() {
  var params = {
    TableName: tableName,
    ProjectionExpression: `albums.album1.images.#imageName1.tags, albums.album1.images.#imageName2.tags`,
    ExpressionAttributeNames: {
      '#imageName1': 'img-1',
      '#imageName2': 'img-2'
    },
    Key: {
      'userId': 'johnDoe',
    }
  }

  try {
    let result = await ddb.get(params).promise()
    console.log(JSON.stringify(result))
  } catch (error) {
    console.error(error)
  }
}

DELETE ITEM

deletes a single item from the table

async function deleteItem () {
  let params = {
    TableName: tableName,
     Key: {
       userId: 'johnDoe',
     }
  }

  try {
    await ddb.delete(params).promise()
  } catch (error) {
    console.error(error)
  }
}

QUERY

Query an item from a table

async function query () {
  let params = {
    TableName: tableName,
    KeyConditionExpression: 'userId = :id ',
    ExpressionAttributeValues: { ':id': 'johnDoe' }
  }

  try {
    let result = await ddb.query(params).promise()
    console.log(result)
  } catch (error) {
    console.error(error)
  }
}

UPDATE A TOP-LEVEL ATTRIBUTE

Let's update the updatedAt key

async function updateItem () {
  const params = {
    TableName: tableName,
    Key: {
      userId: 'johnDoe'
    },
    UpdateExpression: 'set updatedAt = :newUpdatedAt',
    ExpressionAttributeValues: {
      ':newUpdatedAt': 1598367687
    },
    ReturnValues: 'UPDATED_NEW'
  }

  try {
    await ddb.update(params).promise()
  } catch (error) {
    console.error(error)
  }
}

UPDATE A NESTED ATTRIBUTE

Here we will add a new attribute(size) to img-1 of album1

async function updateNestedAttribute() {
  let params = {
    TableName: tableName,
    Key: {
      userId: 'johnDoe'
    },
    UpdateExpression: `set albums.album1.images.#img.size  = :newImage`,
    ConditionExpression: `attribute_not_exists(albums.album1.images.#img.size)`, // only creates if size attribute doestnt exists
    ExpressionAttributeNames: {
      '#img': 'img-1'
    },
    ExpressionAttributeValues: {
      ':newImage': 2048
    }
  }

  try {
    await ddb.update(params).promise()
  } catch (error) {
    console.error(error)
  }
}

Note:
If an attribute name begins with a number or contains a space, a special character, or a reserved word, then you must use an expression attribute name to replace that attribute's name in the expression. In the above example, img-2 attribute has - in its name. So if we set the update expression to set albums.album1.images.image-2 = :newImage it will throw an error.

APPEND TO A NESTED OBJECT

Here we will add a new image to album1

async function appendToAnObject () {

  let newImage = {
    'filename': 'johndoe/album1/food-826349.jpg',
    's3Url': 's3://photo-bucket/johndoe/album1/food-826349.jpg',
    'tags': ['burger', 'food']
  }

  let params = {
    TableName: tableName,
    Key: {
      userId: 'johnDoe'
    },
    UpdateExpression: `set albums.album1.images.#image  = :newImage`,
    ExpressionAttributeNames: {
      '#image': 'img-2'
    },
    ExpressionAttributeValues: {
      ':newImage': newImage
    }
  }

  try {
    await ddb.update(params).promise()
  } catch (error) {
    console.error(error)
  }
}

APPEND TO A LIST

Here we will add a couple of tags to one of the image. Tags are stored as an array

async function appendToList() {

  let params = {
    TableName: tableName,
    Key: {
      userId: 'johnDoe'
    },
    UpdateExpression: 'SET albums.album1.images.#image1.tags = list_append(albums.album1.images.#image1.tags, :newTags)',
    ExpressionAttributeNames: {
      '#image1': 'img-1'
    },
    ExpressionAttributeValues: {
      ':newTags': ['burger', 'pizza']
    }
  }

  try {
    await ddb.update(params).promise()
  } catch (error) {
    console.error(error)
  }
}

URL redirects with AWS S3 and Cloudfront

Vishnu Prassad — Sun, 15 Dec 2019 08:57:20 +0000

Hosting a static website with S3 is awesome! It is Faster, Cheaper, Zero maintenance.

In this article, we will see how to do URL redirects on a website hosted with AWS S3 and Cloudfront.

There was a scenario which I was faced once in my company, One of our websites had deleted some old content and replaced it with new content and URL. And when people who google search for that particular content they get the old URL which doest exists.

To fix this issue the approach we had was to do add a temporary redirect for that old URL to the new one until it gets updated at google search.

The Fix

AWS S3 Static hosting provides an option to add redirection rules to the website hosted in a particular bucket. https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html

In this particular case, the URL's we are going to use will be these,

https://example.com/content/old-content

and we will be redirecting this to

https://example.com/content/new/content

To add the rules,

Click on your bucket
Go to properties and click on static website hosting
Under the redirection rules filed, put the following code

Redirect Rule,

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>content/old-content/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HostName>example.com</HostName>
<ReplaceKeyPrefixWith>content/new/content</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Please note, The HostName(Line 7*)* part is important if your S3 website is configured with Cloudfront. Else during redirect, the domain name will be replaced with the S3 website endpoint.

That's it. Now any requests coming to the old URL will be automatically redirected to the new one

Automating Deployment Of Lambda Functions Using Serverless Framework, AWS CodePipeline

Vishnu Prassad — Mon, 18 Nov 2019 02:56:21 +0000

TL;DR

In this guide we will set up a very simple REST API endpoint with the serverless framework, AWS Lambda, and API Gateway and deploy it to AWS Lambda with Github, AWS Codepipeline, Codebuild

1. Install the Serverless Framework

npm install serverless -g

2. Create a project

serverless create --template aws-nodejs --path serverless-nodejs-api

This will create two files handler.js and serveless.yml

'use strict';

module.exports.api = async event => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!'
      },
      null,
      2
    ),
  };
};

Update your serverless.yml to add an API Gateway endpoint.

service: serverless-nodejs-api

provider:
  name: aws
  runtime: nodejs10.x
  stage: dev

functions:
  getMsg:
    handler: handler.api
    events:
      - http: GET /

Now we have our serverless API code ready.

You can deploy this to AWS manually by running sls deploy --stage dev

This will deploy the lambda function and create an API gateway endpoint for the function.

Once deployed, the output will print the newly created API gateway endpoint. test the function by calling the API endpoint. Something like this,

Service Information
service: serverless-nodejs-api
stage: dev
region: us-east-1
stack: serverless-nodejs-api-dev
resources: 9
api keys:
  None
endpoints:
  GET - https://xxxxx.execute-api.us-east-1.amazonaws.com/dev
functions:
  api: serverless-nodejs-api-dev-getMsg
layers:
  None

test the function by calling the API endpoint.

curl https://xxxxx.execute-api.us-east-1.amazonaws.com/dev

{
  "message": "Go Serverless v1.0! Your function executed successfully!"
}

Now let's automate the deployment process with Github, AWS Codepipeline

Let's consider this code as production-ready and push the code to the GitHub repo master branch.

PS: We can create multiple pipelines per brach for eg: Master -> Prod, Development -> Staging/Dev Environment

3. Setup Codepipeline

3.1 Set Pipeline name and Create IAM Role

3.2 Add source stage

In this stage, Connect to your Github account and choose your repo and branch
Set the detection method

3.3 Add build stage

In this step, we have to create a Codebuild project, where we configure our build and deploy environment and commands.

Click on the Create Project button, it will take you to the Codebuild setup page.

Set the project name here

Choose your runtime and image for the build environment

Choose an IAM role for the project - This part is important

This role must have enough permissions for the serverless framework to deploy the function and its resources to AWS as follows,

Create an S3 bucket for your function deployments
Upload your function zip files to that S3 bucket
Submit a CloudFormation template
Create the log groups for your Lambda functions
Create a REST API in API Gateway

You can use the below awesome NPM modules to create a narrow IAM policy template that will cover many Serverless use cases.

npm install -g yo generator-serverless-policy

then on your serverless app directory

$ yo serverless-policy
? Your Serverless service name test-service
? You can specify a specific stage, if you like: dev
? You can specify a specific region, if you like: us-west-1
? Does your service rely on DynamoDB? Yes
? Is your service going to be using S3 buckets? Yes
app name test-service
app stage dev
app region us-west-1
Writing to test-service-dev-us-west-1-policy.json

After you finish creating the codebuild project go to its IAM role and append the policy with the rules created by the above template.

You can find the IAM policy we used for this guide here,
https://github.com/imewish/serverless-nodejs-api/blob/master/codebuild-IAM-policy.json

Define Build Spec.

You can find it here. https://github.com/imewish/serverless-nodejs-api/blob/master/buildspec.yml

Here we will define the commands to set up the serverless framework and deploy commands to AWS.

On install phase

Set nodejs 10 as runtime

Install serverless framework
On Build Phase

Install npm packages

Deploy to lambda with sls deploy --stage dev/prod

NB: You can also run your tests here if you have test cases written for your lambda functions.

Enable Cloudwatch logs so that we can tail our build process logs.

Then click on Continue to Codepipeline this will take us back to Codepipeline Setup.

4. Deploy Stage

This stage is optional.

Since the serverless framework already put the deployment artifacts to an S3 bucket we can skip this part. But if you want to store it to a different bucket you can set up like this.

Click Next and then review all the setup then Create the pipeline.

That's it!. Now you can test this by going to the newly created pipeline and click on Release Change

DEV Community: Vishnu Prassad

Cloudwatch Custom Metrics With Embedded Metric Format

Introduction

Custom Metrics

AWS API's/SDK's

Metric Log Filters

Cloudwatch Embedded Metric Format

Name Space

Dimension

Metric

Conclusion

AWS Limits To Keep In Mind While Developing A Serverless Application

Deployment Limits

Lambda

Are these a soft limit? : NO

How to Avoid?

Is it a soft limit? : YES

How to avoid?

Is it a soft limit? : NO

How to avoid?

Is it a soft limit? : NO

How to avoid?

Cloudformation

Is it a soft limit? : NO

How to Avoid?

How to Avoid?

Summary

DynamoDB CheatSheet For NodeJS/JavaScript

GETTING STARTED

Install

Configure

CREATE ITEM

SCAN

GET ITEM

GET ONLY SOME DATA FROM AN ITEM

DELETE ITEM

QUERY

UPDATE A TOP-LEVEL ATTRIBUTE

UPDATE A NESTED ATTRIBUTE

APPEND TO A NESTED OBJECT

APPEND TO A LIST

URL redirects with AWS S3 and Cloudfront

Automating Deployment Of Lambda Functions Using Serverless Framework, AWS CodePipeline

TL;DR

1. Install the Serverless Framework

2. Create a project

3. Setup Codepipeline

3.1 Set Pipeline name and Create IAM Role

3.2 Add source stage

3.3 Add build stage

4. Deploy Stage