Edited to clarify: *The bucket is used by EC2 instances that process its data and display parts of it to the user. The EC2-S3 interaction is invisible to the user. *
Can I assume that a public S3 bucket will not be discovered if it has a very long and complicated URL?
For example s3://5eb63bbbe01eeed093cb22bb8f5acdc8/
One could argue that this is not "security by obscurity", but "security by secrecy".
First, standard disclaimer: Security is not an all or nothing proposition. Security procedures for an anonymous favorite-cat-voting website will not be as stringent as the security procedures for the nuclear football. You need to decide on a security level that property balances cost vs usability for your organization.
That being said, I agree with keithRozario's answer, and will give you a couple more reasons on top of his why I personally wouldn't rely on just the bucket name.
Many studies show that roughly half of all data breaches start internally. Even if the "public" never guesses your bucket name, that doesn't help if the group that is responsible for half of all data breaches (aka your employees) does know your bucket name. Like anything else, if it contains production data, it should only be accessible to employees who need access to production data. If you have a "secret" bucket name but embed it in your source code where everyone can see it, then it isn't really a secret, and you may in fact have problems in the future.
In a comment you asked why a long bucket name was different from API access credentials. There is a very simple reason why they are in fact very different. If the employee in charge of your production systems leaves on bad terms, you can invalidate their access credentials, create new ones, and update your systems. However, it's not always as easy to change the name of your bucket.
It's like the difference between a building that has magnetic card entry vs a single master key. With magnetic card keys, if someone leaves, you just revoke their access. When everyone has a single master key then you have no choice but to change the locks and replace everyone's key when one person leaves, which in reality means that the locks never change. Relying on the bucket name for security is equivalent to giving out the master key to everyone who works for you. No thank you.
Bottom line, the answer is No.
If your S3 bucket is public, and you make it a website, the bucket name will appear in certificate logs which are fully public. There are tools that sniff certificate logs just to find such S3 buckets.
Also if you make it a website -- it'll appear in the links you're presumably sharing out.
The way to secure an S3 bucket is to make it private, and grant access to the specific IAM roles that need access. Do not rely on long complicated names to protect it alone.
That being said -- if you truly don't want anyone to find the stuff in your bucket, I'd definitely give it a long complicated name and make it private. It at least adds some layer of protection, for the times where maybe some script somewhere turns it public (AWS is complicated!)
Also, the recommended way to expose an S3 bucket website is usually CloudFront, where your bucket can remain fully private, yet still expose its contents to the internet. This way, folks can't perform bucket operations like list buckets without being granted the specific permissions.
