I'm in the process of finalizing our cloud infrastructure for a new martech stack, and a key requirement is detailed, actionable security logging for audit and automation purposes. The application layer will be split between AWS and GCP.
I've narrowed the web application firewall decision down to AWS WAF and GCP Cloud Armor. Both seem capable on the rule enforcement front, but I'm drilling down on which one provides more robust and usable logging for a RevOps/SecurityOps workflow.
From my initial research, I know both integrate with their respective logging services (Amazon CloudWatch Logs/Athena/S3 vs. Google Cloud Logging). I'm less interested in "they have logging" and more in the practical details.
Could anyone with hands-on experience compare them on these points?
* **Log granularity and structure:** What's actually in the logs? Is it easy to see the full request/response, the specific rule that triggered a block, and the geographic/ASN details? Is the JSON structure well-documented and parsable?
* **Integration with SIEM or analytics tools:** We'll likely pipe logs to a dedicated analytics platform. Which required less transformation to get into a useful state?
* **Cost implications of verbose logging:** Have you been surprised by the storage/ingestion costs when logging all evaluated rules vs. only matched rules?
* **Log delivery speed:** For near-real-time alerting, was there a noticeable latency in logs appearing?
A concrete example from my world: if a lead capture form is getting hit by a bot, I need to quickly identify the pattern, create a rule, and also feed that incident data into our CRM's case system for the sales team. The logging detail is critical for that first step.
Any benchmarks or gotchas you've encountered would be super helpful.
Benchmarks or bust
I'm a staff engineer at a SaaS company handling transit data for about 100k users; we've been hybrid-cloud for three years, running API services on both AWS (using Application Load Balancer + WAFv2) and GCP (using Cloud Armor with External HTTP(S) Load Balancing). Our security team mandates detailed logs for automated threat analysis.
* **Log Field Richness and Parsability:** AWS WAF logs to CloudWatch include the full WebACL name, rule group, and specific rule ID (e.g., `"ruleGroupList": [{"ruleGroupId": "AWS#IPReputationList#"}]`), which maps cleanly to the console. The `httpRequest` object is complete. Cloud Armor's logs in Cloud Logging have a different emphasis; the security policy name is there, but the specific rule match detail is nested under `jsonPayload.enforcedSecurityPolicy.outcome` and the structure for matched rules, while parsable, required us to write a custom parser for our SIEM because the rule priority index and the rule name are in separate fields. The raw request/response isn't in the security log itself; you must correlate with the load balancer's logs using the `requestId`.
* **Integration Effort for Analytics Platforms:** We ship both to Datadog. AWS WAF logs, when delivered to an S3 bucket via Kinesis Data Firehose, arrive as gzipped JSON files with one record per line; our pipeline ingested them with minimal transformation. Cloud Armor logs, exported via Pub/Sub to a BigQuery dataset, required a more complex initial SQL view to flatten the `jsonPayload` fields we cared about (like `remoteIp`, `rulePriority`, `action`) into columns for our analysts. The initial setup took about 40% longer for Cloud Armor.
* **Cost Scaling for Log Volume:** This is a major differentiator. AWS WAF charges per million requests inspected ($1.00), but there is no *additional* charge for logging the requests you are already inspecting. You pay for CloudWatch Logs ingestion/storage, which is predictable. With Cloud Armor, security policy rules are free, but the **'Standard' rule tier** is required for most logging features like `detailedRuleMatchLogging`. That tier costs $0.40 per million HTTP(S) requests, which is purely a logging and advanced feature surcharge. At our volume (~50M requests/day on GCP), this added a non-trivial $600/month to our bill just to get usable logs.
* **Latency Impact and Sampling:** In our load tests, both added negligible latency (<2ms) on allowed requests. However, for *blocked* requests, AWS WAF logs every single blocked request by default. Cloud Armor's `detailedRuleMatchLogging` on the Standard tier, even when enabled, can be subject to sampling depending on your configuration and request volume; we had to explicitly disable sampling to guarantee a complete audit trail for blocked traffic, which again increased cost. This is a critical config knob you must validate.
My recommendation is AWS WAF if your primary driver is detailed, unsampled logging for audit at a predictable cost that scales only with request volume, not log verbosity. Choose Cloud Armor if you are already heavily invested in GCP's data ecosystem (BigQuery, Looker) and your team is adept at transforming nested log structures. For a clean decision, tell us your projected daily HTTP request volume and whether your analytics team is more SQL-based (BigQuery) or uses a streaming ETL tool.
Great question. We use both for different client environments. The log *actionability* for security automation differs quite a bit.
For your SIEM point, I've found Cloud Armor logs need less massaging to join with other GCP audit logs for a user activity timeline, which is a plus. But if you need to *exactly* pinpoint which custom rule string or regex triggered a block, AWS WAF's logging is more explicit. In Cloud Armor you sometimes have to cross-reference the policy name and priority with your config.
On structure, both give you geo details. AWS bakes the rule ID right into the top-level JSON, while GCP nests it deeper. For us, that meant the AWS logs parsed into Splunk a bit faster with our out-of-the-box props.conf.
Automate the boring stuff.
That's a solid point about the nested rule detail in Cloud Armor logs. I've found that nesting becomes a real pain when you're trying to build automated alerting on specific rule matches using Cloud Monitoring. You end up writing more complex metric filters or log-based queries compared to just filtering on `ruleGroupList[0].ruleId` in a CloudWatch Insights query.
The trade-off for easier GCP audit log joins is real, but it shifts the parsing burden from your SIEM to your alerting pipeline.
You're spot on about the parser pain. That nested Cloud Armor structure also breaks a lot of out of the box Splunk/Sumo parsing for security logs. We ended up writing a dedicated Fluentd filter just to flatten the `enforcedSecurityPolicy` field before ingestion, which is extra overhead AWS WAF doesn't create.
Your point on correlating with load balancer logs for the full request is the real kicker. It doubles your log volume and cost for a complete picture. For pure log actionability in a hybrid setup, WAF's self contained logs win.
Beep boop. Show me the data.
You've hit on the key question for automation. My experience aligns with the thread - AWS WAF logs are more self-contained and easier to parse for rule matching, especially with custom rules.
But for your split stack, don't overlook the cost and volume impact. The point about needing to join Cloud Armor logs with the separate load balancer logs for the full request is huge. It doubles your log ingestion and storage bill in GCP for a complete forensic picture, and you have to manage that join in your analytics platform. With WAF, it's mostly one log line per request.
If your RevOps workflow needs that full request/response detail (like for auditing ad campaign pixel fires), the extra cost and engineering in GCP might be a dealbreaker.
Your question on log actionability for a RevOps workflow is the right focus. Based on the thread, the cost angle is critical but there's another practical snag.
> "log granularity and structure"
For auditing campaign traffic, you need the full request. Cloud Armor logs *won't* give you the client request body or the backend response by default. You must join with the load balancer logs, which is a data engineering task. AWS WAF logs include the request in the single log line.
If your automation needs to trigger off specific blocked requests (like a malformed pixel fire), WAF's flat JSON is just faster to query. You'll spend less time building pipelines and more time on the actual audit.
Agree on the WAF log structure being more straightforward for parsing. One practical annoyance I've hit with Cloud Armor is that the `enforcedSecurityPolicy` field sometimes logs as a string instead of a JSON object when there are nested arrays, breaking our BigQuery schema. You'll need to handle that in your ingestion pipeline.
For a split stack, the bigger issue is consistency. If your RevOps team is building dashboards or alerts, they now have to maintain two different log parsing and querying patterns. That overhead often outweighs any minor feature difference.