DynamoDB tables can be provisioned with up to 400 WCU or 400 RCUs, but you can’t provision both simultaneously.
Let’s see how moto and localstack can spin up a local DynamoDB instance for testing your AWS application code.
Here’s a Python example using boto3 to interact with a local DynamoDB.
import boto3
from botocore.exceptions import ClientError
# Configure boto3 to use LocalStack's DynamoDB endpoint
# Replace 'http://localhost:4566' if your LocalStack endpoint is different
dynamodb = boto3.resource('dynamodb', endpoint_url='http://localhost:4566')
table_name = 'MyLocalTable'
primary_key = 'id'
try:
# Create a table
table = dynamodb.create_table(
TableName=table_name,
KeySchema=[
{
'AttributeName': primary_key,
'KeyType': 'HASH' # Partition key
}
],
AttributeDefinitions=[
{
'AttributeName': primary_key,
'AttributeType': 'S' # String type
}
],
ProvisionedThroughput={
'ReadCapacityUnits': 5,
'WriteCapacityUnits': 5
}
)
print(f"Table '{table_name}' created successfully.")
# Wait for the table to be active
table.meta.client.get_waiter('table_exists').wait(TableName=table_name)
# Put an item
item = {primary_key: 'user123', 'name': 'Alice', 'email': 'alice@example.com'}
response = table.put_item(Item=item)
print(f"Item put successfully: {response}")
# Get an item
response = table.get_item(Key={primary_key: 'user123'})
print(f"Item retrieved: {response.get('Item')}")
except ClientError as e:
print(f"Error interacting with DynamoDB: {e.response['Error']['Message']}")
To run this, you’ll need moto and localstack set up. localstack provides a mock AWS environment locally, and moto is a Python library that mocks AWS services for testing.
First, install the necessary Python packages:
pip install boto3 moto
Next, start localstack. The simplest way is via Docker:
docker run -d -p 4566:4566 --name localstack localstack/localstack
Once localstack is running, you can execute the Python script above. The endpoint_url='http://localhost:4566' in boto3.resource tells your AWS SDK to talk to the local localstack instance instead of the actual AWS cloud.
The core problem moto and localstack solve is the cost and complexity of hitting real AWS services during development and testing. You get near-instantaneous feedback, zero charges, and the ability to isolate your tests from external network issues or service degradations. It’s like having a miniature AWS cloud on your laptop.
Internally, moto intercepts boto3 calls. When it sees an endpoint_url pointing to a local address, it knows to use its in-memory or file-backed mocks instead of sending requests over the network. localstack goes a step further by emulating multiple AWS services, including DynamoDB, often via Docker containers, providing a more comprehensive local AWS experience.
For DynamoDB, localstack’s mock will create an in-memory representation of your tables and data. When you create_table, it registers the table schema. When you put_item, it stores the item in its internal data structure. get_item then retrieves it from there. The ProvisionedThroughput settings are largely ignored by moto and localstack for basic operations, as they simulate a local, unrestricted environment.
The botocore.exceptions.ClientError is your main tool for debugging issues when interacting with the mocked service. If your script fails, this exception will tell you what the mock service thinks went wrong, often mirroring real AWS error messages.
A crucial detail often overlooked is how moto handles different versions of AWS services or specific API parameters. While it’s excellent for most common use cases, complex features like global tables, DynamoDB Streams, or specific IAM policies might not be perfectly emulated. Always verify critical, advanced functionalities against a real AWS environment if your application relies heavily on them.
The next step after mastering local DynamoDB testing is exploring how to mock other AWS services like S3 or Lambda in conjunction with your DynamoDB tests.