It depends on what you mean by "private".

###Actually Private###

If you mean that the bucket has no read/write/access permissions from unauthenticated users, then revealing the bucket name in a signed URL doesn't matter because the bucket name is not sensitive data - the keys are.  Trying to hide the bucket name would just be security through obscurity, and in this particular case would add very little security.  Feel free to use signed URLs.

###Merely Hidden###

If you mean that the bucket allows public users to read/write/access it, and the only thing stopping people from doing so is that they don't know the bucket name, then yes, revealing the bucket name is a bad idea.  Of course for a bucket that contains private/sensitive data, this is a terrible way to manage your bucket anyway.  Hackers and penetration testers regularly find hidden buckets by using brute-force searching.  There are tools to make it easier.  As a result the only way to keep data in a bucket private is by denying all public access.

###Threat Modeling###

You also asked if you should hide the bucket name just in case some hacker finds a way to hack buckets knowing only the bucket name.  What you need is a [threat model](https://security.stackexchange.com/questions/225012/what-is-a-threat-model-and-how-do-i-make-one).  It's important to recognize that like all features in an application, every security measure has an associated cost (development time, possible loss of functionality, future maintenance costs).  Every security measure should also have a benefit.  As a result there is never really a point where something is "secure" or "not secure".  It's merely a matter of deciding when something is "secure enough", and each individual business is ultimately responsible for finding that point for themselves.  To get you started, I'll mention the risk you are concerned about and add some more to the list:

 1. What if someone figures out how to hack an amazon bucket knowing just the bucket name?
 2. Do you store you AWS keys in your code repositories?  What if one of your employees uses it to steal the data in your bucket?  After all, they already know everything anyway.
 3. What if one of your employees wants to be able to make data available without a signed URL and so decides to just make the whole bucket public, forgetting that it also stores private data?

Personally, item #1 there would be the lowest on my list of concerns.  After all, something like 50% of all data breaches start with internal employees (either intentionally or not).  If someone did find some way to hack an AWS bucket knowing just the bucket name, it would be a **huge** deal.  It would generate world-wide headlines and Amazon would have people working around the clock until it was fixed.

Besides, you should stop thinking that you can keep a bucket name private.  You really can't.  Your employees probably all know it and they are as likely to cause leaks as "hackers" anyway.  Moreover, performing brute-force searches for buckets is a very common practice in both the hacking and penetration testing world.

Your bucket name isn't private.  It never will be.  Don't kid yourself into thinking otherwise.  Either way, there are an infinite number of possible things to be concerned about, and you don't have time to fix them all.  You need a threat modeling process to help you decide what is most important to your business, prioritize the potential risks for those assets, and then address them according to your available resources.