If you have a non-static request like:
example.tld/some-slug/
then you will need to run WordPress to see if that slug is available.
The webserver (nginx/apache) doesn’t know that, because WordPress will have to inform us about that through the 404 response header.
If your site has only few pages, then you could tell the webserver about it beforehand.
I don’t know if there exists any webserver modules that can store the existing WordPress sitemaps (on disk or memory) to pre-check for possible 404 errors.
If this slug doesn’t exists and you get thousands of requests on that slug, then you might try to cache the 404 response.
There are cache plugins out there that can do that.
But that might not be so useful if the attack consists of random slugs:
example.tld/azwc/
example.tld/eldw/
example.tld/tpwh/
...
Then you could block the IP address, but most likely there are thousands of IP addresses as well.
Then you might try services that collect and block large number of bad IP addresses.
Any way, you should try to trim down your 404.php page.
The defense might depend a lot on what kind of attack requests you’re getting.