I would start with fail2ban if I was you.
Both can be a drain on your resources if they aren't configured properly, but I suspect the caveats of working with regex will be more familiar to you.
fail2ban is easier to make immediately useful (in my eyes at least).
It is much simpler to setup to actually block malicious sources than snort, and you can configure fail2ban to scan snort logs, in order to ban them.
Neither will in all likelihood actually protect you against DDoS as such, but both could, in their equivalent to blocking mode, be used to prevent non-network resource exhaustion, by (in effect) avoiding interactions with actual application servers.
One issue with snort is that it is somewhat non-trivial to have it work in IPS mode (i.e. actually blocking traffic) - AFAIK, much more common is to run it as an IDS (i.e. only detecting malicious traffic).
fail2ban is, as you say, essentially just a script that does regex on log files, extracts malicious sources from those logs (e.g. failed SSH login, web client triggering repeated 4xx or 5xx respones, or having a user-agent associated with known attacker profiles).
It integrates with iptables (and whatever might be running on top of iptables, e.g. firewalld, shorewall), in order to block traffic related to malicious hosts.
Those blocks tend to be implemented either as simple iptables rules, or as an iptables rule + an ipset.
snort (and suricata, and other IDSen) actually inspect various aspects of traffic flows, in order to detect potentially malicious traffic.
It uses rules in a domain-specific format, which can also do IP address (and/or hostname/domain) matching, as well as packet inspection, reassembly, and more.
A fairly widely used ruleset in EmergingThreat's - you might want to read through (some of) them, to get a feel for snort's capabilities.
One consideration is that fail2ban will generally be useful out of the box, where that isn't entirely the case for snort - you generally need to tune its rules (and possibly add some of your own) in order to balance event volumes with their actionability.
Personally, a setup that works for me while I spend some time getting better on snort, is:
- setup fail2ban with ssh and relevant web jails
- create a jail reading the IDS alert log (in my case, that's suricata, but that's a detail), notably looking for Prio 1 alerts, and also looking at any hosts that flagged as DROP (yes, I could just load the relevant ipsets)
- let fail2ban do the rest.
That may or may not work for you, but it means you get some extra protection from snort without needing to become particularly knowledgeable of its internals.
However, I would mention that snort rules can seem a little more alarmist than might be warranted - having some idea of what threats they are pointing to, and how to understand/interpret alerts, is generally worth the effort.
Once you get more comfortable with snort, tune it, first, and then consider whether you want to allow it to deal with things directly (e.g. put it in IPS mode).
In passing, you may want to consider how a WAF could be part of the picture, if a lot of your exposed assets are web-based.
