I saw that while I was creating my AWS instance I opted for only my IP address being able to access my server. Also There is a RSA key that is configured for you. In this case do I really need fail2ban installed on the server?
In that case, I would say that fail2ban would not be required.
I would really only use fail2ban when you have to expose a management service to the Internet in the hypervisor (aws) firewall. In your case, all requests except those from your IP are being dropped.
One thing to note, if your IP address changes (non-static) you will have to update the aws security group.
All the answers saying fail2ban is unnecessary because of the AWS security policies, effectively another firewall. However, if that ever fails or becomes misconfigured, then attacks can come in. A combination of iptables/firewalld/ufw and fail2ban makes complete sense, and layered security is an important tactic. So fail2ban (along with basic firewall configuration) is still a good idea.
I want to add as @tim has mentioned, that fail2ban (and other kinds of similar tools) can provide more granularity than AWS security policies, which seem to be limited to protocols and ip address ranges. For example, aggressive spiders can be blocked, as well as bots that try and login. Blocking at the network layer is more efficient than the web server, or the web application (e.g., Wordpress) layer.
Fail2ban scans log files for potentially malicious actions and bans the IP-addresses from which such behaviour originates. Generally Fail2Ban is then used initiate an action that will block subsequent (malicious) actions from that IP-address from recurring.
To prevent getting locked out as an administrator you would normally add your own (management) network addresses to an IP-whitelist in fail2ban.
Now if your server or service has been firewalled to only allow access from the same ip-addresses and/or networks present in that whitelist, fail2ban will never actually do anything, right?
The only reason I would add fail2ban in your case would be to DROP kids trying to connect on the server indefinitely and limit the responses it serves for nothing (in the case your server does generate REJECT answers to those trying to connect).
Now, you might have a good reason to whitelist IPs but on SSH is fairly secure, as long as you keep your key private (and disable root login is best). Also, it is quite easy to setup 2 factor authentication on ssh (e.g. using Google 2FA), using your password and a 'random' generated number. Whitelisting an IP for ssh might just become unpractical at some point !