DynamoDB On-Demand Scaling vs Provisioned with Auto-Scaling [The Ultimate Comparison]

Introduction

There are multiple ways to provision your DynamoDB tables. Originally the only method was manually provisioning throughput of your tables. However, this method was not very flexible to scale up and down depending on usage or demand. A sudden spike meant that your table wouldn't have the throughput to handle requests and errors would occur. The only solution to this was to manually build your own custom solution to call the AWS APIs to scale your tables. For a fully managed database, this created additional work for you.

Fast forward to June 2017, and AWS announced Provisioned with Auto-Scaling. Provisioned with Auto-Scaling allowed you to specify a target utilization, minimum and maximum provisioned capacity, and AWS would work to achieve the target utilization by scaling your table throughput up and down as needed. This was great at handling increases to database load overtime, however extremely rapid spikes in load could still occur faster than the table could scale.

This issue was addressed by AWS in November 2018 at AWS re:Invent 2018 with the introduction of On-Demand Scaling. I like to refer to this as DynamoDB Serverless. With On-Demand Scaling you don't need to think about provisioning throughput. Instead your table will scale all behind the scenes automatically. Extreme spikes in load can occur and be handled seamlessly by AWS. This also brings a change in the cost structure for DynamoDB. With On-Demand Scaling, instead of paying for a provisioned throughput, you pay per read or write request.

Provisioned with Auto-Scaling

How it works

Provisioned with Auto-Scaling takes in a few option for both read capacity and write capacity in order to optimize your table:

• Target utilization - This is a percentage that DynamoDB will aim for your consumed table capacity to be this % of your total table capacity. For example, if you set this to 70%, and you are making 70 requests worth of provisioned capacity, your table will aim be set to 100 provisioned capacity.
• Minimum provisioned capacity - This is the minimum provisioned capacity that your table will allow. DynamoDB will not scale your table provisioned capacity below this value.
• Maximum provisioned capacity - This is the maximum provisioned capacity that your table will allow. DynamoDB will not scale your table provisioned capacity above this value.

These values apply to both the read capacity and the write capacity. You can also choose to set the write capacity to match the read capacity.

Remember, the table capacity acts as horizontal scaling. However instead of horizontally scaling servers, AWS abstracts the concept of database servers behind the concept of capacity, where you are determining the number of database requests as opposed to database servers. Behind the scenes, the behavior is the same as scaling database servers.

Behind the scenes DynamoDB publishes the consumed table capacity to CloudWatch. If the consumed capacity exceeds the policy for a specific length of time, CloudWatch will trigger an alarm. This alarm will invoke the Application Auto Scaling to evaluate the scaling policy and issue an UpdateTable request to DynamoDB to adjust the throughput.

Limitations

There are a few limitations of this system. It is important to understand however that some of these limitations are not a result of Auto-Scaling, but limitations with DynamoDB table capacity in general. However, those limitations can occur more frequently when using Auto-Scaling.

First, only 4 decreases to your tables capacity are allowed per day. However, if there was no decrease in the past hour, an additional decrease is allowed. This means for highly variable traffic, you might run into a case where you are paying for a higher capacity than you actually need, which can be inefficient.

Additionally, Auto-Scaling does not prevent you from manually modifying throughput. These manual adjustments don't affect existing alarms related to Auto-Scaling either. Personally, I don't recommend this because it leads to situations where you are fighting with the Auto-Scaling software. But it is good to know that it is possible, and that it doesn't affect the alarms related to Auto-Scaling.

Finally, it is important to note that scaling actions don't happen instantly. It can take a little bit of time for the new scaling capacity to be provisioned and usable. This means if you receive a massive sudden influx of requests, it can take a little bit of time for your capacity to scale up to meet that increased demand. This means Auto-Scaling is best for situations where traffic will scale gradually and not incur sudden spikes of traffic. For most applications this is fine, traffic normally spikes during the middle of the day, and tampers off overnight. But it is important to understand that Auto-Scaling and changes to provisioned capacity is not instantaneous.

On-Demand Scaling

How it works

On-Demand Scaling is an entirely different system for provisioning table capacity. This new system is almost identical to serverless systems like AWS Lambda and AWS API Gateway. The responsibility for thinking about how many servers/capacity to provision is shifted from you to AWS.

This changes the payment structure of how you pay for DynamoDB. Instead of paying for a provisioned throughput, you pay per request made to your table. You can use the Dynobase DynamoDB Pricing Calculator to learn more about this.

In order to enable this in JavaScript you can do something like the following:

await dynamodb.createTable({
  TableName: "my-table",
  BillingMode: "PAY_PER_REQUEST",
  AttributeDefinitions: [
    {
      AttributeName: "Artist",
      AttributeType: "S",
    },
    {
      AttributeName: "SongTitle",
      AttributeType: "S",
    },
  ],
  KeySchema: [
    {
      AttributeName: "Artist",
      KeyType: "HASH",
    },
    {
      AttributeName: "SongTitle",
      KeyType: "RANGE",
    },
  ],
})
await dynamodb.createTable({
  TableName: "my-table",
  BillingMode: "PAY_PER_REQUEST",
  AttributeDefinitions: [
    {
      AttributeName: "Artist",
      AttributeType: "S",
    },
    {
      AttributeName: "SongTitle",
      AttributeType: "S",
    },
  ],
  KeySchema: [
    {
      AttributeName: "Artist",
      KeyType: "HASH",
    },
    {
      AttributeName: "SongTitle",
      KeyType: "RANGE",
    },
  ],
})

The important part here is setting the BillingMode to PAY_PER_REQUEST.

You can also set BillingMode to PAY_PER_REQUEST when running an updateTable command:

await dynamodb.updateTable({
  TableName: "my-table",
  BillingMode: "PAY_PER_REQUEST",
})
await dynamodb.updateTable({
  TableName: "my-table",
  BillingMode: "PAY_PER_REQUEST",
})

Of course you can also do all of these actions within the AWS Console as well.

When moving to On-Demand Scaling or to Provisioned Capacity, all of your data will stay intact. There is no need to migrate or delete your data. Everything is handled behind the scenes seamlessly for you.

Limitations

Probably the biggest limitation of On-Demand Scaling is the fact that you can only go from Provisioned Capacity to On-Demand Scaling once per day. This is a one direction limit, so theoretically you can go from On-Demand Scaling to Provisioned Capacity as many times as you'd like.

Additionally, DynamoDB throughput default quotas still apply. By default this is, 40k read request units and 40k write request units. However you can easily request service a quota increase by contacting AWS support.

Finally, all indexes will use On-Demand Scaling as well. You are unable to mix and match between On-Demand Scaling and Provisioned Capacity for the table and that tables indexes.

Which to use?

Here are a few reasons you might consider Provisioned with Auto-Scaling vs On-Demand Scaling.

Remember for Provisioned with Auto-Scaling you are basically paying for throughput 24/7. Whereas for On-Demand Scaling you pay per request. This means for applications still in development or low traffic applications, it might be more economical to use On-Demand Scaling and not worry about provisioning throughput. However, at scale, this can quickly shift once you have a more consistent usage pattern.