The right way to go is to add an error fallback to index.html in the S3 bucket's static web hosting configuration.
The reason of this is when a URL is hit (either by manual input in the browser or a refresh), it sends a request to /list to the S3's root server (the one managed by AWS) before it hits our bucket. That S3 server have no idea if this is a reactjs app or not, so it goes into the bucket to look for the /list in the root of my bucket, which doesn't exist, so it returns the 404 error.
However by adding the error fallback, now when it gets 404, it redirects the request to index.html, where the react app defined and loaded into. In this case, the /list will go through the normal flow to reach the right router that handles page rendering, problem solved.
This is a request that if you don't find this answer helpful please don't downvote me because I was just trying to help you out with your problem.

As @Panther mentioned in the comment, the right way to go is to add an error fallback to index.html in the S3 bucket's static web hosting configuration.
The reason of this is when a URL is hit (either by manual input in the browser or a refresh), it sends a request to /list to the S3's root server (the one managed by AWS) before it hits our bucket. That S3 server have no idea if this is a reactjs app or not, so it goes into the bucket to look for the /list in the root of my bucket, which doesn't exist, so it returns the 404 error.
However by adding the error fallback, now when it gets 404, it redirects the request to index.html, where the react app defined and loaded into. In this case, the /list will go through the normal flow to reach the right router that handles page rendering, problem solved.