Another issue; the overlap between SSH scanners also running HTTP/S attacks is negligible.
From experience; what makes sense is shifting your SSH port away from 22, disabling password based authentication, whitelisting your IP address from your cloud provider's firewall, and still aggressively auto-banning incorrect logins with fail2ban.
Then, for good measure, implement a WAF to protect your HTTP/S traffic as well.
Do not turn your production system into a honeypot. Only do this with a separate system that contains no valuable data.
You could potentially create a fake daemon that listens on port 22 and just logs every access attempt, and set up fail2ban to block any IP that even opens a connection to the port, regardless of what they try to send over it.
Actually, I think iptables has a LOG target that can log connection attempts even without something listening, so that could work too and be much simpler.