npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

serverless-plugin-dynamodb-autoscaling

v3.1.1

Published

Auto configure autoscaling for preconfigured Dynamodb tables

Downloads

608

Readme

Build status Tests coverage npm version

serverless-plugin-dynamodb-autoscaling

Autoscaling configuration for DynamoDB tables

  • Convention over configuration approach - Automatically discovers preconfigured tables and accompanies them with dedicated scaling resources. Configuration can be fine tuned addressing specific tables or indexes, or switched to white list approach
  • Resources savvy - Existing project's IAM role is reused for handling scaling target resources. It's only mandatory ScalableTarget and ScalingPolicy resources that are added to CloudFormation stack

Installation

npm install serverless-plugin-dynamodb-autoscaling

Configuration

Activate plugin in serverless.yml

plugins:
  - serverless-plugin-dynamodb-autoscaling

In most cases it's all you need to have autoscaling resources configured. Still if you need to fine tune configuration for some reason see tables and IAM role configuration. Additionally if you approach any errors during CloudFormation deployment, refer to troubleshooting

Tables configuration

By default autoscaling configuration is automatically applied to all preconfigured DynamoDB tables and all its eventual global secondary indexes.

Still, we can exclude individual tables or tweak their configuration via configuration withinserverless.yml config:

resources:
  Resources:
    SomeTable1:
      Properties:
        TableName: foo
    SomeTable2:
      Properties:
        TableName: bar
    SomeTable3:
      Properties:
        TableName:
          Fn::Sub: ${AWS::Region}-test
custom:
  dynamodbAutoscaling:
    tablesConfig:
      # Disable autoscaling for table referenced by "SomeTable1" resource name
      SomeTable1: false

      # Disable autoscaling just for indexes of "SomeTable2" table
      SomeTable2:
        indexes: false

      # Tweak minCapacity setting for all tables of which resource names start with SomeTable
      # (glob patterns can be used)
      SomeTable*:
        minCapacity: 10

      SomeTable4:
        # Tweak maxCapacity setting for table referenced by "SomeTable4" (just table)
        table:
          maxCapacity: 300
        # Tweak targetUsage setting for SomeTable4 indexes
        indexes:
          targetUsage: 0.5

      SomeTable5:
        indexes:
          # Do not autoscale index 'foo'
          foo: false

      SomeTable6:
        indexes:
          # Do not autoscale any indexes but 'someIndex1' and 'someIndex2'
          "*": false
          someIndex1: true
          someIndex2:
            # Tweaking any of the configuration option will also whitelist the index
            minCapacity: 100
White list approach

If you prefer white list instead of black list approach you can handle configuration as below

custom:
  dynamodbAutoscaling:
    tablesConfig:
      # Disable autoscaling for all
      "*": false

      # but enable for table referenced by resource name "SomeTable1"
      SomeTable1: true
Configurable settings:

ScalingPolicy chaining

By default ScalingPolicy resources are chained via DependsOn property, so they're deployed sequentially and not in parallel. It's to avoid reaching eventual CloudWatch rate limits.

Still it has a downside of slowing down the deployment. If number of tables in your stack is not large, or you've lifted rate limits on AWS side, then you can safely turn off that option to ensure more robust deployments:

custom:
  dynamodbAutoscaling:
    chainScalingPolicies: false

IAM role configuration

By default existing lambda IAM role is reused (if recognized) or new dedicated IAM role is created. Still it's possible to handle IAM configuration outside of this plugin, for that just pass ARN of externally configured IAM role via iamRoleArn setting:

custom:
  dynamodbAutoscaling:
    iamRoleArn: "arn-of-iam-role-to-handle-tables"

Troubleshooting

Eventual IAM policy update race condition issue

If at first deployment you're faced with one of the following errors:

  • Unable to assume IAM role
  • Role is missing the following permissions
  • The security token included in the request is invalid

It can be result of a race condition issue described as following by AWS team:

It's a known situation and confirmed by the internal team that manages CloudFormation that the propagation of IAM policies and resources might take longer than CloudFormation to launch the dependent resources. This race condition happens now and then, and unfortunately CloudFormation team is not able to determine programmatically when a role is effectively available in a region.

To workaround it, the stack with just IAM polices update (and no autoscaling resources yet) needs to be deployed first, and then further deployment may carry the autoscaling resources update (unfortunately just relying on DependsOn brings no rescue)

To make handling of that case easier this plugin enables the IAM only deployment via iamOnly option, you may refer to this option as one-time mean

custom:
  dynamodbAutoscaling:
    iamOnly: true

Tests

npm test