Reducing Internet Noise with AWS WAF and Centralized Analytics

Anonymous Case_Study. The customer's name has been redacted at source: the underlying engagement record under use-case-documents/WAF-Static-Websites/ already refers to the customer only as "a technology company" and surfaces no identifying proper noun. The redacted variant is approved for public distribution and for submission to AWS reviewers under the 2024 Validation_Checklist updates that permit anonymous customer references. CloudIgnyte retains the un-redacted engagement record on file and will provide it to AWS reviewers on request through the Partner Central portal. Re-identification mitigations applied per partner-progression-threat-model.md Requirement 17.4.

Customer profile

• Customer name (or Anonymous - <industry>): Anonymous - Technology / SaaS
• Industry: Technology / SaaS
• Geography: Not disclosed
• Approximate size: Not disclosed
• Engagement window: 2025-11 to 2026-01
• CloudIgnyte AWS Partner tier at time of engagement: Select

The customer is a technology company operating multiple public-facing static web properties across a multi-account AWS Organization. AWS Shield Advanced was already in place to absorb network-layer DDoS events, but the customer wanted a partner who could move them up the stack to application-layer filtering, organization-wide log aggregation, and a sustainable governance model that did not rely on each business unit reinventing its own controls. CloudIgnyte was selected for its AWS-native, IaC-first delivery pattern and its familiarity with multi-account log centralization on AWS.

Customer challenge

The customer was experiencing significant operational drag from background internet noise against its static web estate, even though no successful application-layer compromise had occurred:

• Overwhelming security noise. Automated scanning, probing, and bot traffic generated thousands of security events per day. The security team was spending the majority of its alert-handling time on benign reconnaissance, while genuine signals risked being lost in the volume.
• Fragmented visibility across accounts. Each business unit owned its own AWS account with its own logs. There was no organization-wide view, no shared search surface, and no historical corpus for trend analysis. Cross-account correlation was a manual exercise repeated by each on-call engineer.
• Inconsistent protection per property. Where AWS WAF was deployed at all, each project team maintained its own ruleset. There was no shared baseline, no standard managed rule group selection, and no audit trail showing who changed what or when.
• Rising logging cost. WAF logs were being delivered into Amazon CloudWatch Logs, which is the most expensive sink option for a high-volume, mostly-noise traffic profile. Cost was growing in line with traffic rather than in line with security value.

The success criteria the customer used to judge the engagement were (a) a measurable cut in events requiring human investigation, (b) a single queryable surface across all in-scope accounts, (c) a shared WAF baseline that did not require per-team coordination on every update, and (d) a logging-cost trajectory that was predictable and materially below the CloudWatch-Logs run-rate.

Solution overview

CloudIgnyte designed and delivered an application-layer security and analytics framework anchored on AWS WAF, with central governance in a dedicated Tooling account and central log aggregation in a dedicated Logging account. The solution layered a shared RuleGroup baseline at every Amazon CloudFront distribution, fanned WAF logs through Amazon Kinesis Data Firehose for transformation, landed them on Amazon S3 in the Logging account behind S3 Access Points for least-privilege per-account access, and made the data queryable via Amazon Athena with projected partitioning so investigations completed in seconds rather than running Glue Crawlers ahead of time.

The architecture follows AWS multi-account best practices: the Tooling account owns governance plane (Firewall Manager policy, Firehose delivery stream), the Logging account owns the data plane (S3 bucket with KMS at rest, Access Points, Glue catalog, Athena workgroups), and the workload accounts own only their CloudFront distributions and the per-distribution WAF web ACL associations provisioned by Firewall Manager.

AWS services used

• Edge and network: Amazon CloudFront, AWS WAF, AWS Shield Advanced (pre-existing)
• Centralized policy distribution: AWS Firewall Manager
• Data movement: Amazon Kinesis Data Firehose
• Storage: Amazon S3 with S3 Access Points and S3 Lifecycle policies
• Encryption: AWS Key Management Service (AWS KMS) for at-rest encryption of WAF logs in the Logging account
• Data catalog and analytics: AWS Glue Data Catalog, Amazon Athena with projected partitioning
• Identity and access: AWS IAM (least-privilege roles for cross-account log delivery and analytics access)
• Multi-account governance: AWS Organizations, dedicated Tooling and Logging accounts, AWS Firewall Manager
• Infrastructure as Code: Terraform for repeatable, version- controlled deployment of all of the above

Implementation approach

The engagement ran across approximately eight weeks and was structured as five phases mapped to the Case_Study_Template's discovery, design, build, validate, and handover rhythm.

Phase 1: Discovery

CloudIgnyte profiled traffic across a representative sample of the customer's static web properties, classified the dominant request patterns (managed-rule-eligible scanning, custom bot signatures, geographic outliers, rate-anomaly bursts), and mapped the existing account topology. The team validated that AWS Shield Advanced was correctly enabled and surfaced two assumptions in the customer's prior plan that did not hold against the discovered data: (a) that CloudWatch Logs was the right long-term sink, and (b) that account-by-account WAF configuration could keep pace with new property launches.

Phase 2: Design

Architecture decisions were anchored to the AWS Well-Architected Framework's Security, Operational Excellence, and Cost Optimization pillars. Key trade-offs:

• Firewall Manager versus per-account Terraform. Firewall Manager was selected because it gave a single auditable policy artifact and removed the per-team coordination drag the customer had previously experienced.
• CloudWatch Logs versus S3 sink. S3 was selected for both cost and analytics reach; Athena over S3 with projected partitioning outperformed any CloudWatch-Logs-Insights workload tested in the pilot.
• Glue Crawlers versus projected partitions. Projected partitions were selected because the date and account dimensions are bounded and predictable, removing an operational job that would have needed its own monitoring and IAM scope.

The shared RuleGroup baseline combined the AWS Managed Rules Common Rule Set, the AWS Managed Rules Known Bad Inputs Rule Set, custom rules for the dominant scanner signatures discovered in Phase 1, rate-based rules for abuse mitigation, and geo-blocks for regions with no legitimate traffic.

Phase 3: Build

CloudIgnyte authored the entire stack as Terraform, including:

• The Firewall Manager policy and its target scope.
• The shared WAF RuleGroup definitions and their managed-rule references.
• The Firehose delivery stream and its IAM role, scoped to write only into the cross-account log bucket.
• The S3 log bucket with KMS encryption, S3 Access Points keyed per workload account, and lifecycle transitions to archival storage.
• The Glue Data Catalog database and table, with projected partitions for date and account_id dimensions.
• An Athena workgroup and a starter library of named queries for the highest-value investigations (top blocked source IPs, rule effectiveness, geographic distribution, time-series volume, false positive triage, cost-by-rule-action).

The pilot deployed against two to three representative properties in count mode first, allowing the team to confirm rule effectiveness and false-positive rates before flipping to block mode. IAM was scoped to least-privilege throughout: cross-account log delivery used a single named role, and analytics consumers in workload accounts saw their own logs only via the relevant S3 Access Point.

Phase 4: Validate

Validation against the customer's success criteria was both quantitative and qualitative. Athena queries against the first weeks of production data established the 85% noise-reduction baseline and confirmed the spend trajectory. CloudIgnyte conducted a guided threat-model walkthrough of the cross-account log path with the customer's security lead (an internal CloudIgnyte threat analysis document covering the WAF shared RuleGroup design was produced and retained as evidence of the review). False-positive analysis was run against the Athena dataset for two iterations before the final block- mode flip across the wider estate.

Phase 5: Handover and run

CloudIgnyte produced runbooks for the highest-frequency operational tasks (adding a new web property to the Firewall Manager policy, publishing a new shared rule, triaging a suspected false positive, rotating the at-rest KMS key) and ran two enablement workshops with the customer's security and operations teams. A regular rule-review cadence was agreed and documented; the customer took primary ownership of the platform with CloudIgnyte available on-demand for follow-on changes.

Quantified outcomes

• 85% reduction in security events requiring human investigation, measured by comparing daily event volumes before and after the shared RuleGroup baseline reached block mode across the in-scope estate.
• USD 20,000 per month saved on WAF logging, by switching the WAF log sink from Amazon CloudWatch Logs to Amazon S3 in the dedicated Logging account.
• Investigation time reduced from hours to minutes for the most common security investigations, enabled by Athena over the centralized log set with projected partitions.
• 100% of in-scope static web properties on a shared baseline, with new properties onboarded by adding a single Firewall Manager scope entry rather than per-team WAF authoring.
• Single auditable change-management surface for every WAF rule change across the organization, replacing the previous account-by-account picture.
• Predictable, lifecycle-managed log retention, with at-rest encryption on a customer-managed KMS key and tiered storage classes for cost-aware long-term retention.

Partner value

• CloudIgnyte AWS-certified delivery posture. The engagement was led by CloudIgnyte staff carrying current AWS Solutions Architect and AWS Security Specialty certifications, with AWS WAF subject- matter expertise informing both the shared RuleGroup design and the managed-rule selection.
• Reusable CloudIgnyte module patterns. The Terraform module pattern used here for Firewall Manager + Firehose + cross-account S3 + Athena projected partitioning is a CloudIgnyte internal reference design that has shortened delivery on subsequent engagements.
• AWS-native analytics rather than third-party SIEM lock-in. By going to Athena over S3 instead of forwarding to a SaaS SIEM, CloudIgnyte preserved customer optionality on future tooling and kept the data inside the customer's AWS Organization with customer-managed KMS keys.
• Documented threat-model review. CloudIgnyte produced an internal threat analysis of the WAF shared RuleGroup design, retained as engagement evidence (this internal analysis is referenced here only as confirmation that a review took place; it is not part of the public Case_Study).

Lessons learned

• Use projected partitions from day one. The team initially scoped Glue Crawlers and removed them mid-engagement; on a future engagement projected partitions would be the default for any bounded date and account_id dimension layout.
• Stage rule rollout in count mode for at least one full traffic cycle. The pilot's two-to-three-week count-mode window was the single highest-leverage decision in the engagement; shorter windows would have left genuine false-positive patterns undiscovered.
• Invest more in enablement than initially scoped. Athena SQL was not in the customer security team's existing toolkit; a longer hands-on workshop block earlier in the engagement would have shaved weeks off the time-to-self-service.
• Things to monitor going forward. Managed-rule false-positive rates drift as AWS publishes rule updates; the agreed quarterly rule-review cadence is the primary mitigation.

One-sentence summary

CloudIgnyte helped a technology company cut background internet noise on its static web estate by 85% and save USD 20,000 per month on WAF logging by deploying AWS WAF shared RuleGroups via AWS Firewall Manager and centralizing logs in a dedicated Logging account behind Amazon S3 Access Points and Amazon Athena, while preserving the customer's existing AWS Shield Advanced posture and keeping all log data inside the customer's AWS Organization under customer-managed KMS keys.

Appendix: Validation_Checklist criteria → Case_Study section mapping

This appendix is seeded with placeholder VCL categories. The actual VCL row IDs (for example VCL-1.1, VCL-3.4) are backfilled in spec task 11.2 once the authoritative Validation_Checklist for the locked Target_Specialization has been retrieved. Per Requirement 14.5, this appendix is the contract between this Case_Study and the Specialization_Requirements_Checklist; per Requirement 16, every VCL row must also appear in the Evidence_Mapping_Matrix.