Distributed Denial Of Service in Django with Dynamodb

A Distributed Denial of Service (DDoS) scenario involving Django and Amazon DynamoDB typically arises from application-level amplification rather than infrastructure-layer attacks on AWS itself. In this combination, Django serves as the API or web layer, and DynamoDB is the backend datastore. The risk occurs when a single incoming request triggers many repeated or poorly optimized queries to DynamoDB, consuming backend read/write capacity and increasing latency for legitimate users.

One common pattern is unbounded or inefficient queries using DynamoDB’s query or scan operations without proper filtering or pagination. For example, if a Django view calls scan on a large table on every request, DynamoDB consumes significant read capacity units (RCUs), which can throttle the table for other applications and increase response times. In a DDoS context, an attacker can send many requests that each invoke expensive scans or queries, effectively saturating the provisioned throughput and causing denial of service for legitimate traffic.

Another amplification vector is the lack of server-side rate limiting or request validation before DynamoDB operations. Without per-endpoint throttling in Django, an attacker can flood the application with requests that each perform multiple writes or queries. This leads to consumed write capacity units (WCUs) and potential throttling exceptions, which Django may handle poorly by retrying, further increasing load. Additionally, poorly designed secondary index usage or lack of caching can cause repeated queries to the same hot partitions, stressing DynamoDB’s internal scalability and indirectly degrading availability.

Django’s default behavior of opening a new database connection per request can also exacerbate the issue. Without connection pooling or careful management, a high request rate can lead to many simultaneous connections to DynamoDB via the AWS SDK, increasing the chance of throttling at both the SDK and service level. The combination of these factors means that what might be a minor inefficiency in a low-traffic setup can become a full availability problem under DDoS conditions.

To mitigate DDoS risks when using Django with DynamoDB, focus on reducing per-request amplification, adding defensive patterns, and using AWS features wisely. Below are concrete code examples that demonstrate safe query patterns, caching, and bulk operations.

1. Use Query with Key Conditions Instead of Scan

Always prefer query with a partition key (and sort key condition) over scan. Scans examine every item in a table and consume far more RCUs.

import boto3
from django.conf import settings

dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table(settings.DYNAMODB_TABLE_NAME)

# Safe: query with partition key
response = table.query(
    KeyConditionExpression='user_id = :uid',
    ExpressionAttributeValues={':uid': 'user-123'}
)
items = response.get('Items', [])

2. Implement Pagination and Limit Results

Avoid returning large result sets in a single call. Use pagination with Limit and pagination tokens to control page size and prevent runaway consumption of RCUs.

response = table.query(
    KeyConditionExpression='user_id = :uid',
    ExpressionAttributeValues={':uid': 'user-123'},
    Limit=50
)
items = response.get('Items', [])
while 'LastEvaluatedKey' in response:
    response = table.query(
        KeyConditionExpression='user_id = :uid',
        ExpressionAttributeValues={':uid': 'user-123'},
        ExclusiveStartKey=response['LastEvaluatedKey'],
        Limit=50
    )
    items.extend(response.get('Items', []))

3. Use Conditional Writes and Avoid Hot Partitions

Design keys to distribute load across partitions. Avoid high-cardinality attributes that concentrate traffic on a single partition, which can throttle write capacity.

# Example: include a random suffix to spread writes
import random

suffix = random.randint(0, 9)
partition_key = f'user-{user_id}-shard{suffix}'
table.put_item(
    Item={
        'pk': partition_key,
        'sk': 'order#20240101',
        'data': { ... }
    },
    ConditionExpression='attribute_not_exists(pk)'
)

4. Add Caching for Repeated Reads

Cache frequent query results in Django’s cache framework to reduce DynamoDB read traffic. This lowers RCU consumption and protects against repeated expensive queries during bursts.

from django.core.cache import cache

key = f'profile:{user_id}'
profile = cache.get(key)
if profile is None:
    resp = table.get_item(Key={'pk': f'user#{user_id}', 'sk': 'profile'})
    profile = resp.get('Item')
    if profile:
        cache.set(key, profile, timeout=300)  # 5 minutes

5. Use Bulk Operations and Backoff

For batch writes, use batch_write_item and implement exponential backoff to handle throttling gracefully without retrying aggressively and amplifying load.

from botocore.exceptions import ClientError
import time

items_to_write = [...]  # list of PutRequest/DeleteRequest
table = dynamodb.Table(settings.DYNAMODB_TABLE_NAME)

for i in range(0, len(items_to_write), 25):
    batch = items_to_write[i:i+25]
    max_retries = 3
    for attempt in range(max_retries):
        try:
            with table.batch_writer() as batch_handler:
                for item in batch:
                    batch_handler.put_item(Item=item)
            break
        except ClientError as e:
            if e.response['Error']['Code'] == 'ProvisionedThroughputExceededException':
                time.sleep(2 ** attempt)  # exponential backoff
            else:
                raise

6. Enforce Rate Limits in Django

Apply per-view or per-IP rate limiting using Django middleware or a cache-based token bucket to prevent bursts that amplify DynamoDB load.

# settings.py
MIDDLEWARE = [
    ...,
    'middleware.DynamoDBRateLimitMiddleware',
]

# middleware.py
from django.http import HttpResponseForbidden
from django.core.cache import cache

class DynamoDBRateLimitMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        key = f'rate_limit:{request.META.get(\"REMOTE_ADDR\", \"\")}'
        current = cache.get(key, 0)
        if current > 100:  # 100 requests per window
            return HttpResponseForbidden('Rate limit exceeded')
        cache.set(key, current + 1, timeout=60)
        return self.get_response(request)