For MiaB, it is already configuring its own firewall. Generally, if there is not a useful function for an extra thing, the extra thing represents an additional opportunity for failure.
Having a slightly less restrictive firewall in the cloud with a more restrictive firewall on the server itself is redundant and adds complexity that you don’t need.
Just utilize the built in firewall config on MIAB and reduce your headaches.
I use the cloud-level firewall at my VPS provider (Vultr) in addition to MIAB’s built-in UFW firewall. I simply duplicated all the existing UFW rules in the VPS firewall settings, with the additional restriction of only allowing SSH logins from my own IP address. This has eliminated the constant SSH connection attempts from intruders on the Internet (if you look at your logs, you’ll see how many there are).
This setup has worked fine for me in the several months that I’ve been using MIAB; it was pretty much “set and forget” at the VPS level.
You are free to do with your server as you desire, but note that if MiaB project makes a change that requires a port not previously used, some functionality may be unavailable or broken until the external firewall rules are revised.
The attempts on the port 22 login are insignificant load on the server - openssh is designed that way.
The other side of this is if there is a change in the external firewall it may start causing problems in MiaB that cannot be immediately diagnosed as a firewall issue, which can then generate a lot of time spent troubleshooting the wrong device.
Unless being installed to a local network (which always requires an external firewall), it is difficult to see any good reason to run MiaB behind a firewall for most users. The exception would be a highly visible server that might require some sort of DDoS protection, but that is a different matter, altogether.