There's always a chicken and egg problem when you want to store private keys securely, but the app needs automated access to them. If you poke around this site you'll find plenty of related questions, for example:
Ask yourself what your threat model is; if you're only worried about remote attackers, then focus your efforts on hardening the perimeter of your server. If nobody can get in to your server, then encrypting it with AES might already be overkill.
If your threat model includes malicious users on that system, users introducing malware onto the server, or if whatever app the server is running is complex enough that it could become compromised, then protecting the keys at rest becomes a good idea. As you say, nothing is 100% secure; a software-based approach will always be breakable by someone with root access to the server and enough time to study memory dumps of your program. It sounds like what you're doing is reasonable. Some possible improvements:
- Rather than have the AES key embedded in the source code, have an admin enter a password at process startup that is used to derive the AES key. That way an attacker really does need to be on your server taking memory dumps rather than being able to extract it from your binary or source code, which I assume is easier to acquire than a memory dump of a prod server.
- You could maybe encrypt each private key with its own AES key just to increase the barrier between getting one key and getting all the keys.
- The next big step up would be to generate the keys on dedicated crypto hardware so that the private keys are never on the server at all. Cheap option: a bunch of PKI Smart Cards dangling out of the server on USB dongles. Expensive option: a network HSM.