5 Serverless Plugins Every Developer Should Know

  1. Caching — API Gateway
  2. Required Parameter Validation — API Gateway
  3. Documentation — API Gateway
  4. Pruning Lambda versions — Lambda
  5. Split Stacks — Serverless

API Gateway Caching
This improves performance and reduces the traffic sent to your back end. Cache settings allow you to control the way the cache key is built and the time-to-live (TTL) of the data stored for each method. API Gateway also exposes management APIs that help you invalidate the cache for each stage. Caching is available for REST APIs in API Gateway.


"serverless-api-gateway-caching": "^1.5.0"


enabled: true
clusterSize: '0.5'
ttlInSeconds: 300
apiGatewayIsShared: true
dataEncrypted: true
requireAuthorization: false
- serverless-api-gateway-caching

clusterSize — size of the cache cluster. Default = 0.5GB.
ttlInSeconds — time to live of the data stored in the API Gateway cache. Default = 300 seconds. Maximum = 3600 seconds.
dataEncrypted — encrypt the data being stored in the cache
perKeyInvalidation — handle the cache key invalidation
requireAuthorization — whether an authorization is required to invalidate the cache per cache key
true - authorization is required
false - authorization is not required
handleUnauthorizedRequests (if above property is true) — handle the unauthorized request to invalidate the cache
Ignore - ignores the request to invalidate the cache key.
IgnoreWithWarning - ignores the request to invalidate and adds a warning header in the response.
Fail - fails the request to invalidate the cache key with a 403 response status code.

Head to the below link to understand the plugin in detail:

Documentation & Request Validation — Parameter & Body
Request Validation
is to enable the validation of the request body and parameters in the APIGW. You can avoid doing the request validations in your Lambda functions by using this feature.

Define the RequestValidators in the resources block of your serverless.yml. You have the option to validate either the request body or the request parameters. I have defined three validators here with a combination of validating either body or parameters or both.


Type: "AWS::ApiGateway::RequestValidator"
Name: '${self:custom.appname}-req-body-validator'
RestApiId: !Ref ApiGatewayRestApi
ValidateRequestBody: true
ValidateRequestParameters: false
Type: "AWS::ApiGateway::RequestValidator"
Name: '${self:custom.appname}-req-parameter-validator'
RestApiId: !Ref ApiGatewayRestApi
ValidateRequestBody: false
ValidateRequestParameters: true
Type: "AWS::ApiGateway::RequestValidator"
Name: '${self:custom.appname}-req-body-parameter-validator'
RestApiId: !Ref ApiGatewayRestApi
ValidateRequestBody: true
ValidateRequestParameters: true
- serverless-reqvalidator-plugin
- serverless-aws-documentation


"serverless-reqvalidator-plugin": "^1.0.3"
"serverless-aws-documentation": "^1.1.0"

AWS Documentation plugin is also required here, as we have to define the request models to help with the request body validation.

Using the request validator:

handler: api/auth.login
name: login
description: api to login user
- http:
method: post
cors: true
path: auth/login
summary: User Login Request
description: User Login Request
requestModels: "application/json": "LoginReq"

Define your request model mentioning the properties and their types. Please note that the required properties are also defined as separate property of the schema.

name: LoginReq
contentType: "application/json"
"$schema": "http://json-schema.org/draft-04/schema#"
title: "Login Request"
type: object
- userName
- password
type: string
type: string

In your serverless.yml, declare the models under documentation within custom section.

models: ${file(models.yml):models}

Go to the following link to learn more:

Pruning Lambda Versions

AWS creates a new version of your lambda function each time that you publish the function. Each function version and layer version consumes storage. The default storage quota is 75GB. Though the quota can be increased, the storage of unnecessary function versions is not efficient. Imagine having a lambda function with 50 old versions, which is never going to be used in the future. It is better to maintain fewer function versions. So you can revert to an immediate old version in case the new function version deployed has issues. Now, if you go about deleting these 50 versions manually, you’re going to be at it for a while. Instead, you can let this prune plugin do its job.


automatic: true
includeLayers: true
number: 3
- serverless-prune-plugin


"serverless-prune-plugin": "^1.4.3"

You can mention the number of versions you want to keep. The rest of the old versions are automatically deleted. This plugin should be listed at the end of the plugin list. The pruning process happens at last after the stack is updated and the new versions are deployed.

Learn more about the plugin:

Split Stacks Plugin

AWS enforces a limit of 200 resources per CloudFormation stack. Unlike many AWS limits, this cannot be increased upon request. Fortunately, AWS is aware of the fact that many real-world applications will have CloudFormation stacks that need to contain more than 200 resources and provide a solution:

To specify more resources, separate your template into multiple templates by using, for example, nested stacks.

Since the Serverless Framework has a rich ecosystem of tools and plugins, it’s no surprise that an open-source plugin exists to do exactly that.

ENTER serverless-plugin-split-stacks. The plugin provides a number of strategies for splitting a stack.


nestedStackCount: 50
perGroupFunction: true
- serverless-plugin-split-stacks


"serverless-plugin-split-stacks": "1.9.3"

nestedStackCount: Controls the number of created nested stacks

To know more about the migration strategies, head to the link below:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store