This study examines how training data composition and model capacity shape the reliability and generalization of an edge-based distributed denial-of-service (DDoS) detector on Amazon Web Services (AWS). We build a minimal pipeline from Amazon CloudFront logs using one-minute aggregates-request rate, unique client IPs, and 4xx/5xx counts. A separate validation set is used to select and fix a single operating threshold before testing. Two supervised detectors-Random Forest (RF) and Logistic Regression (LR)-are trained on a comprehensive dataset that combines benign background, a known high-requests-per-second (RPS) attack, and a benign flash crowd, and are evaluated on a continuous A→B→C→D timeline in which D is an unseen attack. With representative training coverage, both detectors remain stable on benign traffic with no false positives. Under distribution shift, only the nonlinear RF maintains sensitivity to the unseen attack, whereas the linear LR fails. These results motivate a practical design for availability-focused detection at the content delivery network (CDN) edge: rely on edge-visible signals, fix the operating threshold on a validation set, and deploy a lightweight nonlinear ensemble that integrates with a Web Application Firewall (WAF) under an explicit falsepositive budget.
Cloud computing has become the backbone of contemporary digital ecosystems, enabling services
to scale elastically and deliver content with unprecedented speed and global reach. Its promise of
cost efficiency and reliability has accelerated adoption across critical domains, ranging from
ecommerce and finance to healthcare and government platforms. With this deep integration into
daily life, the expectation of continuous availability has become non-negotiable: even short
disruptions can cascade into operational paralysis, financial damage, and reputational loss. As
emphasized in cybersecurity frameworks, availability must be treated as a cornerstone of digital
resilience and safeguarded with the same rigor as confidentiality and integrity [
Availability in large-scale cloud infrastructures is most critically challenged by Distributed
Denial-of-Service (DDoS) attacks, which remain among the most disruptive incidents affecting
online services [
Cloud providers respond with layered defenses—content delivery networks, Web Application
Firewalls (WAFs), managed anti-DDoS rule sets, and rate-limiting—establishing essential baselines
by filtering known signatures, enforcing quotas, and absorbing sudden surges. These controls are
indispensable; yet they are predominantly reactive and often parameterized by static thresholds
and coarse heuristics. When traffic is non-stationary, such thresholds become brittle: they may fail
open during attacks or, conversely, trigger false positives during legitimate flash crowds. The
resulting operational trade-off—under-protection versus over-protection—remains a recurring risk
for availability-critical services [
This study moves beyond a simple performance comparison to investigate a more fundamental prerequisite for building a reliable DDoS classifier: the composition of its training data. The central hypothesis is that the ability of a lightweight classifier to distinguish between attacks and legitimate flash crowds is critically dependent on the representativeness of the dataset it was trained on. To test this, the research contrasts two distinct training methodologies. The first is a naive approach, where a model is trained only on benign background and attack patterns—a common practice that, as demonstrated, leads to poor generalization. The second is a comprehensive approach, where the training data is strategically enriched with examples of highvolume benign surges.
The evaluation is conducted on a continuous timeline that includes benign background traffic, a known attack pattern, a legitimate flash crowd, and a previously unseen attack scenario to rigorously test for stability and generalization. This work’s primary contribution is the quantitative demonstration of the naive approach’s failure modes and the subsequent proof that a targeted enrichment of training data is sufficient to achieve high stability without compromising attack detection. By restricting the feature set to minimal, edge-available signals from Amazon CloudFront logs and adhering to a strict frozen-threshold protocol, this study provides a pragmatic and reproducible framework for developing more robust DDoS detectors, emphasizing the critical role of data curation over mere algorithmic complexity.
Research on mitigating DDoS in cloud environments spans from static perimeter defenses to
learning-based detection and adaptive control. A widely cited starting point is the taxonomy by
Somani et al., who mapped infrastructural and application-layer vectors in cloud settings and
argued that purely reactive mechanisms and fixed thresholds are inadequate under elastic,
Internetscale demand [
Building on such taxonomies, the literature turned to supervised detection on labeled network
data. Golduzian reported that classical models—including logistic regression, random forests, and
gradient boosting—achieve strong detection accuracy on modern benchmarks and outperform
simple statistical thresholds on precision and recall [
Parallel to classical supervised learning, deep architectures and sequence-aware methods have
been explored to capture temporal structure in traffic. Ouhssini et al. proposed hybrid deep
learning models for anomaly detection in cloud computing and highlighted the value of learning
temporal dependencies for real-time decisions [
Orthogonal to detection per se, some work emphasizes proactive surface dynamism. Kansal and
Dave advanced a moving-target defense for cloud–fog environments that shifts exposed resources
to raise attacker cost and disrupt campaign persistence [
This section details the experimental design used to evaluate a minimal, edge-centric anti-DDoS
approach. Our methodology prioritizes reproducibility and operational realism by combining a
controlled web application stack with traffic scenarios that separately exercise legitimate flash
crowds and adversarial L7 bursts. We first present the cloud architecture and logging/observability
setup, then define the traffic scenarios and the dataset assembly pipeline based exclusively on
minute-level CloudFront access logs. We next describe the learning protocol—feature construction,
train/validation/test splits, model selection, and threshold freezing—and the baseline rule for
comparison (a plain RPS threshold). Finally, we specify the evaluation metrics used under a strict
false-positive constraint on a clean flash-crowd test. Forecasting and online policy tuning are
deliberately out of scope here and are discussed separately as a safe operational sketch and future
work rather than as part of the offline methodology [
The experiment uses a small, realistic cloud-native stack that keeps the data path simple and the
signals close to the perimeter. The target application is OWASP Juice Shop on Amazon ECS.
Incoming requests terminate at Amazon CloudFront and are then forwarded to an Application
Load Balancer (ALB), which distributes them across ECS tasks. CloudFront serves as the public
entry point, caching static assets and shielding the origin from direct Internet exposure [
Observability is configured to privilege signals available at the CDN perimeter. CloudFront
standard access logs are enabled and delivered to Amazon S3 in structured form, exposing fields
required to derive minute-level aggregates such as request rate (RPS), unique client IP count, and
4xx/5xx response totals [
The architecture is modular. Each component—CloudFront distribution, WAF web ACL, ALB, and ECS service—can be scaled or replaced without altering the logging pipeline. The evaluation relies only on edge-observable features aggregated at one-minute cadence: RPS, unique IP count, 4xx/5xx counts, and a raw row count used as a coverage indicator. This design keeps the classifier transparent, reduces dependence on application-internal signals, and matches constraints typical of availability-critical systems. In practice, the setup mirrors a common production topology while remaining small enough to support rigorous and reproducible experiments.
To facilitate a comprehensive training and evaluation process, four distinct, methodologically clean traffic scenarios were generated. All scenarios targeted the same CloudFront-ALB-ECS stack hosting the OWASP Juice Shop application. The design of these scenarios was crucial for creating a robust training set and for rigorously evaluating the final classifier’s sensitivity, stability, and generalization capabilities.
A: Benign Background. This scenario provides a baseline of normal, low-intensity user activity. The traffic profile was intentionally kept stable and at a low volume (RPS consistently below 150) to create an unambiguous representation of a system under normal operating conditions. All data points generated in this scenario were labeled as benign (label = 0).
B: Known DDoS Attack. This scenario emulates a concentrated, application-layer DDoS attack, intended to be part of the training data. It consists of a scripted ramp-peak-cooldown sequence, characterized by a high volume of requests originating from a limited number of IP addresses. This low-diversity, high-volume pattern is a classic indicator of a denial-of-service attack. Data points within the core attack window were labeled as malicious (label = 1).
C: Benign Flash Crowd. This scenario models a legitimate, high-volume traffic surge, such as from a successful marketing campaign. Crucially, the traffic was generated from a diverse pool of source IP addresses, simulating a large number of unique users. The profile included a rapid rampup, a sustained high-volume peak (RPS > 400), and a gradual cooldown. Despite the high request rate, all data points in this scenario were labeled as benign (label = 0), serving as a critical example of “good” high-volume traffic for the training set. D: Unseen DDoS Attack. This scenario was created to serve as a held-out test set for evaluating the model’s generalization capabilities. While similar in structure to the “Known DDoS Attack” (B), it was generated using different parameters, request patterns, and source IP addresses. The model was never exposed to this data during training or validation, making it a true “blind” test of the classifier’s ability to identify a novel threat. As with scenario B, data points within the core attack window were labeled as malicious (label = 1).
The dataset was constructed strictly from Amazon CloudFront standard access logs. Per-request records were processed to generate minute-level feature tables, while logs from other services like Application Load Balancer were excluded to prevent data leakage. The feature engineering process was intentionally kept minimal, focusing on a compact vector of edge-available signals: request rate (RPS), unique client IP count (cf_uniq_ip), and response error counts.
To ensure model robustness, a comprehensive TRAIN set was created. Preliminary experiments showed that a model trained naively on only background and attack data failed to generalize to legitimate traffic surges. The final training set therefore incorporates examples from three distinct scenarios: the benign background (A), the known DDoS attack (B), and the benign flash crowd (C). This representative dataset was shuffled to prevent the model from learning spurious temporal dependencies and to teach it the structural differences between malicious and legitimate highvolume events. A small, consistent VAL set was used for stable threshold tuning, composed of unambiguous positive samples from the core of attack B and negative samples from background A. The final TEST set was constructed as a continuous timeline concatenating all four scenarios (A → B → C → D), with the unseen DDoS attack (D) serving as a rigorous, held-out evaluation of generalization capability. The composition of these final datasets is summarized in Table 1. The inclusion of the fourth scenario, an unseen DDoS attack (D), served as a rigorous, held-out evaluation of the model's generalization capability on a novel threat.
The primary model is a Random Forest (RF) classifier, chosen for its ability to capture nonlinear interactions between features without requiring extensive tuning. As a baseline for comparison, a linear Logistic Regression (LR) model is also evaluated to determine if a simpler decision boundary is sufficient for this task. Both machine learning models were trained on the comprehensive TRAIN set, which includes diverse examples of benign and malicious traffic. The third model is a nonlearning RPS Threshold comparator, which serves as a simple benchmark to anchor the performance of the ML-based approaches.
To ensure a rigorous and operationally realistic evaluation, the analysis adheres to a strict
frozen-threshold protocol. For both the RF and LR classifiers, an optimal operating point was
determined by selecting a single decision threshold (τ). This threshold was chosen by maximizing
the F1-score on the VAL set, which contains a balanced mix of unambiguous attack and benign
samples. Once selected, this threshold was “frozen” and applied without any further adjustments to
the final TEST set. This methodology is critical for preventing data leakage from the test
distribution and for mirroring production environments where detection policies must be stable,
auditable, and are not continuously re-tuned.
The evaluation metrics were selected to align with the primary operational goal of maximizing
attack detection while strictly controlling for false positives on legitimate traffic. Performance on
the VAL set was primarily assessed using precision, recall, and the F1-score. Operating points were
selected using precision–recall analysis to align with an FP-dominant utility under class imbalance,
while ROC/partial-ROC were also inspected to contextualize PR-based choices [
Evaluation follows a production-style constraint in which false positives during benign surges
dominate operational risk. All quantities are computed on one-minute windows, and threshold
selection on validation is kept strictly separate from testing to avoid leakage. On the frozen
validation split, a scalar operating threshold τ is chosen at the F1 maximum. At that operating
point, the report includes precision (precision = TP/(TP+FP)), recall—also referred to as the true
positive rate (TPR = TP/(TP+FN))—and F1 (F1 = 2·precision·recall/(precision+recall)). Detection
delay is measured as the difference, in minutes, between the first alarm and the onset of the
contiguous attack core; a delay of zero indicates immediate detection at one-minute cadence.
Operating points were selected using precision–recall analysis to align with an FP-dominant utility
under class imbalance, while ROC/partial-ROC were also inspected to contextualize PR-based
choices [
This section presents the results of the final experiment. The classifiers were trained on the comprehensive dataset (composed of scenarios A, B, and C) and then evaluated on a continuous timeline that included all three training scenarios followed by a fourth, previously unseen attack scenario (D). This design allows for a thorough assessment of the models' stability on known benign traffic, their sensitivity to known attacks, and, crucially, their ability to generalize to novel threats.
The comparative performance of the Random Forest classifier, the Logistic Regression (LR) baseline, and a simple RPS threshold is visualized across the full experimental timeline in Figure 2. The figure plots the RPS profile and overlays markers indicating alarms from each detector, providing a direct visual comparison of their behavior in different traffic regimes.
An analysis of the timeline, quantitatively summarized in Table 2, reveals critical differences in model performance. A primary finding is that both the RF and LR models, after training on the comprehensive dataset, achieved perfect stability. During the Benign Background phase (A) and the Benign Flash Crowd phase (C), neither classifier produced a single false positive, correctly identifying all legitimate traffic.
In the Known Attack phase (B), both machine learning models proved effective. The LR model demonstrated slightly higher sensitivity, detecting 20 out of 21 attack minutes (95% recall). The RF model was also highly effective, identifying 17 out of 21 minutes (81% recall). Both significantly outperformed the simple RPS threshold.
The decisive test of robustness came in the final Unseen Test Data phase (D). Here, the Logistic Regression model completely failed to generalize, detecting 0 out of 13 minutes of the novel attack. In stark contrast, the Random Forest classifier successfully generalized its learning, identifying 9 out of 13 minutes (69% recall) of the new threat. This result highlights the fundamental inability of the linear model to adapt, whereas the nonlinear RF model proved effective against a previously unseen attack pattern.
In summary, the results demonstrate a clear hierarchy of model performance. While both machine learning models learned to be perfectly stable on known benign traffic patterns, only the Random Forest classifier possessed the capacity to generalize its knowledge to effectively identify a novel, unseen threat. The complete failure of the Logistic Regression model on the unseen test data underscores the limitations of linear models for complex security tasks. These findings strongly suggest that a combination of a representative training dataset and a nonlinear model architecture is essential for building a truly robust DDoS detection system.
The final evaluation indicates that reliability in edge-based DDoS detection on AWS is shaped
jointly by training-data coverage and model capacity. After expanding TRAIN to include
background (A), a known high-RPS attack (B), and a benign flash-crowd regime (C), both detectors
operated at a validation-frozen threshold with zero false positives on benign minutes—evidence
that stability under a strict FP budget is primarily a property of representative coverage. Operating
points were fixed on a disjoint validation slice using precision–recall analysis; ROC/partial-ROC
was consulted only for context [
Benign stability (FP=0 on A+C) after widening TRAIN shows that flash crowds share marginal
signatures with attacks (elevated RPS, burstiness) yet differ in joint structure (client-IP diversity,
error mix). Exposing those legitimate surges during training teaches safe regions that an
attackonly curriculum cannot provide [
Learning was restricted to CloudFront-only signals—minute-level RPS, unique clients, and 4xx/5xx
counts—while ALB and WAF telemetry was reserved for audit and enforcement [
Both hypotheses are supported. A CloudFront-only classifier outperformed a plain RPS threshold
on recall without violating a strict FP budget on the flash crowd, and a nonlinear learner proved
more robust than a linear separator under the same frozen-threshold protocol. RF exceeded the RPS
baseline on B and retained partial sensitivity on D, where LR failed completely—consistent with
recent evidence on the strength of tree/ensemble methods for tabular data [
Internal validity. Scenarios used a single-domain topology, one-minute aggregation, and bounded
IP diversity. These choices prioritize label clarity and reproducibility but may narrow
withinscenario variance. A single, small validation slice, even when disjoint from test, can overstate
separation if its boundary is unusually clean; fixing the operating point before test mitigates but
does not eliminate this risk [
External validity. The CloudFront→ALB stack is laboratory-bound and may not capture
multi-origin, multi-region routing or broader adversary tactics. Evolving protocol-level stressors
such as HTTP/2 Rapid Reset (CVE-2023-44487) challenge control paths in ways not exercised here
[
Conclusion validity. The superiority of nonlinear capacity under distribution shift is shown at the pattern level; repeated trials with seed variation and bootstrap intervals would quantify uncertainty on TP/TN counts and specificity.
Operationalize with a conservative WAF control loop: score each minute; raise an alarm only after
K consecutive exceedances; start with CHALLENGE/CAPTCHA or temporary BLOCK as a canary;
escalate only if the condition persists; rollback on recovery, with all actions logged for audit [
This study examined whether the reliability and generalization of a pragmatic, edge-based DDoS detector on AWS are governed more by training data composition or by model choice. The evidence indicates that both elements are necessary and complementary. When the training set explicitly covered low, stable background traffic, a known high-RPS attack, and a benign flashcrowd regime, machine-learning detectors operated at a fixed, validation-frozen threshold with zero false positives on benign minutes—demonstrating that stability is primarily a property of representative training coverage. At the same time, model capacity determined performance under distribution shift: the Random Forest preserved stability and achieved partial sensitivity to a novel attack pattern, while Logistic Regression—despite strong performance on the known burst—failed to register any true positives on the blind scenario, consistent with the limits of linear decision surfaces for interaction-driven tabular telemetry.
These results support a pragmatic recipe for availability-centric DDoS detection at the CDN
perimeter. First, keep features minimal and edge-visible—CloudFront-only aggregates, with
ALB/WAF reserved for audit and enforcement rather than training — so that the pipeline remains
portable, auditable, and decoupled from origin specifics. Second, select and freeze the operating
point using precision–recall analysis aligned to a strict false-positive budget, which is more
informative than ROC when classes are imbalanced and availability costs dominate [
Limitations qualify the scope of the claim. The evaluation used a single-domain topology, oneminute cadence, and bounded IP diversity; broader benign regimes (multi-region campaigns, heterogeneous devices, cache behavior variation) and richer adversarial tactics (e.g., protocol-level stressors such as HTTP/2 Rapid Reset) warrant systematic inclusion before generalizing further. Nevertheless, the core conclusion is robust within the examined constraints: representative training data ensures stability, and modest nonlinear capacity enables generalization to novel attack morphology at fixed thresholds. In operational terms, this amounts to a conservative but effective blueprint: edge-only features, PR-frozen thresholds, and lightweight nonlinearity, implemented under auditable change control and evaluated against an explicit false-positive budge —a configuration consistent with current security and AI risk-management guidance. Declaration on Generative AI While preparing this work, the authors used the AI programs Grammarly Pro to correct text grammar and Strike Plagiarism to search for possible plagiarism. After using this tool, the authors reviewed and edited the content as needed and took full responsibility for the publication’s content.