You could set a threshold on connection rate using connection limiting policies. I would say you will need to stick to connection rate on the policy, as during the SYN flood you wont see many 'active' connections, just the incoming connection requests.
Combining SYN cookie + connection rate limiting may work better than DoS Learning in your case, as the single source IP for the attack will always be the Akamai reverse proxy. I've never had the need to combine these in prod so cannot tell you what to expect.
I believe though, even combining these, you can still run into issues, as the link between the Akamai IP and the IPS could get saturated depending on the DOS traffic generated.
Mitigating the attack at the proxy level seems the logical solution... But then we would not be talking about the IPS
As you can see from the screenshot you posted, the sensor supports over 500k flows, but that may be far too many for your servers/load balancers. So when configuring DoS/DDoS prevention mechanism, I usually always check what is the maximum number of connections supported on the server side, and then decide what limits/thresholds configure on the policies.
So if for example your servers/LB support 100k connections, you may want to limit that to 80k (so 80%) of the maximum supported.
However, each environment is different and depending on how your web server/application works, you may want to lower that number - i.e., other things you may want to take into account when setting thresholds:
- What the max supported sessions at each application tier? Front end, middle tier, back end?
- How much traffic a single request to the front end web server will be generating against the application (middle tier) and back end (i.e database)?
- How much response traffic will be generated by a single request? It could be that 100k incoming request would saturate the pipe outbound?
If you have NTBA or another netflow analyser, I would also suggest you check the inbound/outbound throughput and sessions stats to get a better understanding of what the limit/thresholds should be on your DoS/DDoS policies.