Capturing DynamoDB Usage Metrics

Pricing for on-demand DynamoDB tables is complicated enough that modelling your solution’s capacity unit consumption is not realistic. Instead, it’s more practical to perform simulations of your solution’s usage and then measure the capacity units actually used. This is an approach that we’ll demonstrate in this lab, capturing CloudWatch metrics from the command line.

Defining a Usage Scenario

The first step with this approach is to translate a business scenario to individual API requests. For this, we’ll look at an imagined “vehicle sale” scenario for the ConnectedCar solution. Let’s say that a customer is at a dealership buying a new vehicle, and a staff member at the dealership, using an administrative application, performs the following Admin API requests:

• Get Customers
• Create Customer
• Get Customer
• Create Vehicle
• Get Vehicle
• Create Registration
• Get Registration

In a nutshell, the staff person will search the system for an existing customer record. Then they’ll create new customer, vehicle and registration records. In navigating around the application, retrievals will also be performed on each of these three entities.

Running the Simulation

Step 1: run the get-db-metrics.zsh script in the terminal

Before running the tests to simulate the scenario, you should make sure that there are no consumed capacity units for your DynamoDB tables and indexes for the past hour. To do this, open the “aws-connectedcar-common” repository in VS Code, open the terminal and change to the “/scripts/cloudwatch/zsh” folder. Then run the “get-db-metrics.zsh” script, which should show zeros for all the tables and indexes, for both read and write capacity units, as shown below:

Now you should be ready to run the “Admin_API” performance test collection in Postman.

Step 2: import the performance version of the Admin_API collection into your performance workspace

Start by switching to your other “ConnectedCar” workspace in Postman that has the performance-oriented test collections. Then import the “admin.postman_collection.json” file from the “/postman/performance” folder in the common repository. Once imported, you should see the folders and tests that are a subset of those found in the equivalent functional “Admin_API” test collection, as shown below:

Step 3: set the global variables in your performance workspace in Postman

Like you’ve done before for the functional tests, you’ll need to get the API ID and the API key for the Admin API, either from the console, or by running the “get-outputs.zsh” and “get-attributes.zsh” scripts. You’ll then need to set these variables in the global variables editor tab, entering values for both the initial and current values, as shown below:

Step 4: run the Admin_API collection in your performance workspace in Postman

You should now be ready to run the tests for the simulation. Click on the “Admin_API” collection, and click the “Run” button. On the Runner tab that’s then displayed, click the orange “Run Admin_API” button, on the lower right. The completed tests should look like this in Postman:

Capturing the Capacity Unit Metrics

Having run the simulation, you’re now ready to capture the usage metrics.

Step 5: run the get-db-metrics.zsh script in the terminal again

Go back to the terminal in VS Code and, as you did before, run the “get-db-metrics.zsh” script. After running this script, you should see output like what’s shown below:

Step 6: calculate the monthly cost for the business scenario

If you take the raw data from the script shown above and drop it into Excel for some text-to-columns and summing magic, you get the data shown below:

Table metrics for ConsumedReadCapacityUnits for the past hour

Index metrics for ConsumedReadCapacityUnits for the past hour

Table metrics for ConsumedWriteCapacityUnits for the past hour

Index metrics for ConsumedWriteCapacityUnits for the past hour

If we pick 50,000 as the number of new monthly vehicle sales for our scenario, then multiplied out, these are the monthly costs:

• Monthly read cost = 50,000 * 495.5 /1,000,000 * $0.25 = $6.19
• Monthly write cost = 50,000 * 4 / 1,000,000 * $1.25 = $0.25

To summarize these numbers: the reading and writing of items in DynamoDB is very inexpensive. What costs the most in this scenario is the table scan for the Get Customers call. The figure shown here is for scanning about 25,000 customer items, but this cost would obviously grow in line with the size of this table.