Anomaly Detection in CDN Traffic Patterns: Statistical and ML Approaches

CDN infrastructure generates traffic volumes that make manual monitoring impossible. A mid-sized CDN processes billions of requests per day across hundreds of edge locations, each with its own traffic baseline influenced by geography, time zones, content popularity, and seasonal patterns. Within this massive flow, anomalies — traffic spikes, DDoS attacks, cache poisoning attempts, origin failures — must be detected in seconds, not hours. Effective anomaly detection combines statistical baselines with machine learning models to separate genuine threats from normal traffic variability, building on the observability foundations that every CDN team needs.

Building Traffic Baselines

Anomaly detection requires knowing what “normal” looks like before identifying what isn’t. CDN traffic exhibits strong temporal patterns: daily cycles driven by user activity (morning ramp, evening peak, overnight trough), weekly cycles (weekday versus weekend), and seasonal patterns (holiday traffic spikes, back-to-school periods, major sporting events). A baseline model must capture all three periodicities to avoid flagging predictable variations as anomalies.

STL Decomposition for Traffic Modeling

STL (Seasonal and Trend decomposition using Loess) separates a time series into three additive components. The trend component captures long-term growth or decline in traffic volume. The seasonal component captures recurring periodic patterns. The residual component contains everything that the trend and seasonal models cannot explain — this is where anomalies live.

import numpy as np
from statsmodels.tsa.seasonal import STL

# Hourly request counts for the past 8 weeks
traffic = load_hourly_traffic(days=56)

# Decompose with daily seasonality (24 hours)
stl = STL(traffic, period=24, seasonal=13, robust=True)
result = stl.fit()

# The residual component contains anomaly signal
residuals = result.resid

# Z-score threshold for anomaly detection
mean_resid = np.mean(residuals)
std_resid = np.std(residuals)

anomalies = []
for i, r in enumerate(residuals):
    z_score = (r - mean_resid) / std_resid
    if abs(z_score) > 3.0:
        anomalies.append({
            'timestamp': traffic.index[i],
            'value': traffic.values[i],
            'z_score': z_score,
            'direction': 'spike' if z_score > 0 else 'drop'
        })

# Result: list of timestamps where traffic deviated
# significantly from the seasonal+trend baseline

The robust=True parameter is critical for CDN data because it uses iteratively reweighted least squares (IRLS) that down-weight outliers during the decomposition. Without robustness, existing anomalies in the training data corrupt the seasonal model, causing future anomalies of similar magnitude to appear normal.

Multi-Resolution Baselines

A single decomposition captures one level of periodicity, but CDN traffic has nested patterns. Daily patterns sit inside weekly patterns that sit inside monthly patterns. Multi-resolution baselines apply STL decomposition at multiple time scales, then combine the residuals to produce a more sensitive anomaly signal.

The practical implementation maintains three baseline windows: a short-term baseline (past 7 days, hourly resolution) for detecting acute spikes within daily patterns, a medium-term baseline (past 30 days, 4-hour resolution) for detecting multi-day shifts, and a long-term baseline (past 90 days, daily resolution) for detecting gradual trends that deviate from seasonal norms. An anomaly confirmed at two or more resolutions has a significantly lower false positive probability than one detected at a single scale.

Statistical Anomaly Detection Methods

Statistical methods provide the first layer of anomaly detection. They are computationally cheap, interpretable, and effective for the volume-based anomalies that constitute most CDN incidents. Three statistical approaches cover the majority of use cases.

Z-Score with Adaptive Thresholds

The z-score measures how many standard deviations a data point sits from the mean. For CDN traffic, a static z-score threshold (e.g., alert when z > 3.0) works poorly because traffic variance changes throughout the day — a 20% spike during peak hours represents a much larger absolute change than the same percentage spike at 3 AM.

Adaptive thresholds solve this by computing z-scores within time-of-day windows. Instead of comparing the current request rate against the global mean, compare it against the mean and standard deviation for the same hour-of-day and day-of-week from the past 4 weeks. This approach naturally tightens thresholds during quiet periods (where any spike is suspicious) and loosens them during peak hours (where variance is naturally higher).

CUSUM (Cumulative Sum) for Drift Detection

Z-scores excel at detecting sudden spikes but miss gradual changes. CUSUM accumulates small positive deviations over time, triggering an alert when the cumulative sum exceeds a threshold. This catches scenarios like a slow DDoS ramp-up where each individual minute looks normal but the sustained elevation over an hour is significant.

def cusum_detect(values, target, threshold=5.0, drift=0.5):
    """CUSUM algorithm for detecting upward shifts.
    target: expected value (baseline)
    threshold: alert boundary for cumulative sum
    drift: allowance for normal variation
    """
    cumsum = 0
    alerts = []
    for i, val in enumerate(values):
        cumsum = max(0, cumsum + (val - target - drift))
        if cumsum > threshold:
            alerts.append(i)
            cumsum = 0  # Reset after detection
    return alerts

Exponentially Weighted Moving Average (EWMA)

EWMA provides a middle ground between z-scores (which weight all historical data equally) and pure recency (which ignores historical patterns). The exponential weighting gives recent observations more influence on the expected value, making the baseline responsive to legitimate traffic shifts while still detecting anomalies against the recent trend.

For CDN traffic monitoring, EWMA with a smoothing factor (alpha) between 0.1 and 0.3 balances responsiveness with stability. Lower alpha values produce a more stable baseline that detects larger anomalies, while higher values track the traffic curve more closely and detect smaller deviations. The control limits (upper and lower bounds) use 2.5-3.0 standard deviations of the EWMA residuals.

Machine Learning Approaches

When statistical methods produce too many false positives or miss complex multi-dimensional anomalies, machine learning models provide a more nuanced detection layer. Two ML approaches are particularly well-suited to CDN traffic analysis.

Isolation Forest for Multi-Dimensional Anomalies

Isolation forests detect anomalies by exploiting the fact that outliers are easier to isolate than normal points. The algorithm builds an ensemble of random binary trees. At each tree node, a random feature and a random split value are chosen. Normal points, which are similar to many other points, require many splits to isolate. Anomalous points, which are rare and different, are isolated in few splits.

For CDN traffic, the feature vector at each time window includes: requests per second, unique client IPs, error rate (5xx/total), cache miss rate, average response time, bandwidth consumption, geographic entropy (how spread the traffic is across countries), and the ratio of GET to non-GET requests. Anomalies in this space capture complex attack patterns that simple volume thresholds miss — for example, a cache poisoning attack that maintains normal request volume but shifts the cache miss rate and targets a narrow set of URLs.

from sklearn.ensemble import IsolationForest

# Feature matrix: each row is a 5-minute window
features = [
    'rps', 'unique_ips', 'error_rate', 'cache_miss_rate',
    'avg_response_ms', 'bandwidth_mbps', 'geo_entropy',
    'get_ratio', 'avg_path_depth', 'unique_user_agents'
]
X = build_feature_matrix(cdn_logs, window='5min',
                         features=features)

# Train on 30 days of normal traffic
model = IsolationForest(
    n_estimators=200,
    max_samples=0.8,
    contamination=0.01,  # expect ~1% anomalies
    random_state=42
)
model.fit(X_train)

# Score new windows: -1 = anomaly, 1 = normal
predictions = model.predict(X_new)
scores = model.decision_function(X_new)

# Lower scores = more anomalous
anomalous_windows = X_new[predictions == -1]

LSTM Autoencoders for Temporal Pattern Anomalies

Isolation forests treat each time window independently, missing sequential patterns. An LSTM autoencoder learns to reconstruct normal traffic sequences and flags windows where the reconstruction error exceeds a threshold. The model sees traffic patterns like “ramp-up, peak, ramp-down” as normal sequences and detects when the actual sequence deviates from learned patterns.

Training requires at least 60 days of clean (incident-free) traffic data. The autoencoder architecture uses an encoder LSTM that compresses a sequence of 12 five-minute windows (one hour) into a latent representation, and a decoder LSTM that reconstructs the original sequence. High reconstruction error on a specific window indicates that the traffic pattern at that time does not match any pattern the model learned during training.

The LSTM approach excels at detecting anomalies that are invisible to point-in-time analysis: a traffic pattern that looks normal at any individual moment but follows an abnormal trajectory over time. This includes slow ramp attacks, unusual traffic redistribution across PoPs, and gradual shifts in content access patterns that may indicate cache poisoning or data exfiltration.

Reducing False Positives

The hardest problem in CDN anomaly detection is not finding anomalies but avoiding false alarms. A system that cries wolf ten times a day trains operators to ignore alerts, defeating the entire purpose. Three strategies reduce false positives to actionable levels.

Contextual suppression integrates known events into the detection pipeline. Scheduled traffic events (marketing campaigns, product launches, sports events) are pre-registered with expected impact profiles. When a traffic spike coincides with a registered event and matches the expected pattern, the detection system suppresses the alert or downgrades it to informational. This prevents the most common class of false positives — legitimate traffic surges that are expected but look anomalous to the baseline model.

Multi-signal correlation requires anomalies to appear in multiple dimensions before escalating. A traffic volume spike alone could be organic growth, a bot crawl, or a DDoS attack. Combined with a spike in unique IPs and a normal error rate, it is likely organic. Combined with constant unique IPs and an elevated error rate, it is likely an attack. By requiring concordance across signals, the system filters single-metric noise while capturing genuine multi-dimensional incidents.

Feedback loops close the gap between detection and reality. When operators acknowledge or dismiss alerts, the feedback updates the model. Dismissed alerts with similar feature profiles receive lower priority scores in future detections. Acknowledged alerts strengthen the detection patterns. Over time, the system learns the specific anomaly signatures that matter to each CDN deployment, producing fewer but more actionable alerts.

Real-Time Implementation Architecture

Production anomaly detection for CDN traffic demands sub-minute detection latency. The architecture uses a streaming pipeline that processes CDN access logs in near real-time. Edge PoPs forward logs to a centralized stream processor (Apache Kafka + Flink, or cloud equivalents) that aggregates metrics into 1-minute windows per PoP and globally.

The detection engine runs as a Flink job that applies the three-layer detection cascade: statistical checks run on every window (sub-10ms per check), the isolation forest model scores windows flagged by Layer 1 (sub-50ms), and the LSTM autoencoder evaluates hourly sequences when Layer 2 confirms an anomaly (sub-200ms). Alerts flow to an incident management system (PagerDuty, Opsgenie) with severity levels derived from the detection layer: Layer 1 alone generates a P3, Layer 1 + Layer 2 confirmation generates a P2, and all three layers agreeing generates a P1.

Model retraining runs offline on a weekly schedule. The isolation forest retrains on the most recent 30 days of clean data (excluding labeled incident windows). The LSTM autoencoder retrains monthly on 90 days of clean data. Both models are deployed via blue-green deployment to the Flink job, enabling zero-downtime model updates with automatic rollback if the new model produces significantly different alert volumes than the previous version.

The complete pipeline — from log generation at the edge to alert delivery — operates within a 90-second end-to-end latency budget. This speed enables automated DDoS mitigation responses that engage within two minutes of attack onset, a critical performance window for CDN infrastructure where even minutes of unmitigated attack traffic can saturate origin servers and degrade service across the entire CDN performance surface.