AWS WAF vs Snort: Which to Use for WordPress, and Where

This article is a localized edition of the Japanese original. Read the Japanese original

AWS WAF and Snort are both tools that "find and stop malicious traffic," but they look at different layers and sit in different places, so you choose between them by architecture, not by a simple ranking. AWS WAF is a managed web application firewall that inspects HTTP requests in front of CloudFront or an ALB, and Snort is an open source IDS/IPS that inspects packets on a server or network. This article sorts out the differences between the two, then explains how to choose for each WordPress site architecture and how to think about using them together.

Where each one fits

AWS WAF

AWS WAF is a WAF that you associate with AWS services such as CloudFront, an Application Load Balancer or API Gateway. You create a Web ACL, a set of rules, and decide to allow, block or count (log only) based on conditions such as the request's URL, headers, body and source IP. The managed rule groups that AWS provides include ones for general web attacks as well as ones for WordPress and PHP applications (as of October 2026).

Because TLS is terminated at CloudFront or the ALB, a big advantage is that the contents of HTTPS traffic can be inspected as they are. There is no server to manage, and you configure it through the management console, the API, or tools such as Terraform.

Snort

Snort is an open source intrusion detection and prevention system that Cisco's Talos continues to develop, and Snort 3 is the current mainstream version. You place it near a server or network device and it matches the packets flowing by against signatures (rules). Its feature is that it can cover all kinds of protocols, not only HTTP but also SSH, DNS, SMTP and more.

On the other hand, it cannot see the contents of HTTPS as is. If you want to inspect HTTP content, you need to arrange the setup, for example by placing it behind a reverse proxy that terminates TLS. As for rule sets, besides the community edition there are registered and paid ones provided by Talos, and the scope and delivery timing can change, so check the official site.

Comparison table

The cost model is also different. AWS WAF is pay-as-you-go based on Web ACLs, rules, the number of requests and so on, and additional features such as Bot Control are charged separately. Snort itself is free software, but you pay for the server that runs it and the operational effort. Actual prices change, so check the AWS pricing page.

How to choose for each WordPress setup

When you use CloudFront or an ALB on AWS

If you run WordPress on EC2 or ECS with CloudFront or an ALB in front, AWS WAF is the first candidate for protection against web attacks. It can inspect the contents of HTTPS and stop brute-force attempts on the login screen and requests targeting known vulnerabilities before they reach the server.

When introducing it, it is safer not to go straight to Block, but to run the managed rules in Count (log only) and check for false positives. In WordPress, depending on the post content, saving in the Block editor (sending to the REST API) or traffic to admin-ajax.php can trigger SQL injection or cross-site scripting rules. Check which rules fired in the logs, make adjustments such as changing a specific rule to Count only for admin screen paths, and then switch to Block.

For brute-force attempts on the login screen, you can use a rate-based rule. The following is an example that counts requests to wp-login.php per source IP and limits them.

{
  "Name": "rate-limit-wp-login",
  "Priority": 10,
  "Action": { "Block": {} },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/wp-login.php",
          "FieldToMatch": { "UriPath": {} },
          "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ],
          "PositionalConstraint": "EXACTLY"
        }
      }
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "rateLimitWpLogin"
  }
}

Limit is the number of requests per evaluation window (5 minutes by default). The minimum value you can set and the evaluation window options may change, so check the latest documentation. Also note that if you attach WAF on the ALB side in a setup with an ALB behind CloudFront, the source IP will be CloudFront's. In that case, consider attaching it on the CloudFront side or using a setting that uses the IP from the forwarded header.

When you run on a VPS or a dedicated server

In a setup that does not go through AWS services, AWS WAF cannot be used in the first place. For web attack protection in this case, the main options are an on-server WAF such as ModSecurity, a CDN-type WAF such as Cloudflare, and WordPress security plugins. Snort is realistically used alongside those in the role of "detecting suspicious traffic to the server as a whole."

When running Snort on a WordPress server, operate it in detection-only mode at first and get a sense of what alerts appear. Here is an example local rule.

# local.rules (Snort 3 example)
alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"WP login POST burst";
    flow:to_server,established;
    http_method; content:"POST";
    http_uri; content:"/wp-login.php";
    detection_filter:track by_src, count 20, seconds 60;
    sid:1000001; rev:1;
)

# Check that the configuration and rules load, then start
snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -T
snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -i eth0 -A alert_fast

Adjust the installation paths and interface name to your environment. This rule looks at HTTP content, so if you receive traffic over HTTPS, you need to let Snort see the traffic behind the point where TLS is terminated. Limiting login attempts itself can often be achieved more easily with Fail2ban or a plugin, so it is best to expect Snort to play the role of "finding traffic that other mechanisms cannot see."

The option of using both

The two do not compete, so on larger sites using both is also an option. For example, you can divide the roles like this.

• AWS WAF: Inspect HTTP/HTTPS requests from the internet at the entrance and stop known attacks and brute-force attempts
• Network-based IDS: Monitor traffic inside the VPC and detect suspicious outbound traffic after an intrusion and anomalies in non-HTTP protocols

To achieve the latter on AWS, besides running Snort on EC2 and receiving traffic through VPC Traffic Mirroring, there is also a setup using AWS Network Firewall, which can use Suricata-compatible rules. Which one is suitable depends on the management effort and the inspection you need. Supported instance types and the scope of features change, so check the official documentation before adopting one.

Checkpoints for choosing

• Is there CloudFront or an ALB in front of WordPress? (If not, you cannot choose AWS WAF)
• Do you want to protect against attacks on the web application, or against suspicious traffic to the server as a whole?
• Do you need to inspect the contents of HTTPS, and where is it terminated?
• Do you have a team that will keep updating and tuning the server and rules?
• When a false positive occurs, who looks at which logs to decide?

Summary

• AWS WAF is a managed WAF that inspects HTTP/HTTPS in front of AWS services, and Snort is an open source IDS/IPS that inspects packets. Their roles differ
• For WordPress using CloudFront or an ALB on AWS, AWS WAF is the first candidate for web attack protection. Check for false positives in Count before moving to Block
• AWS WAF cannot be used on a VPS and similar, so combine a server-type WAF or plugins with it, and use Snort in a detection role
• On larger sites, a setup that uses both an entrance WAF and an internal network-based IDS is also conceivable
• Prices and the contents of rule sets change, so check the official information before adopting

• A setup to protect WordPress with CloudFront and AWS WAF
• How to introduce a WAF to WordPress

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)