The 100% correct solution, obviously, would be not to make files publicly readable and writable. That's out of your control here, but it is also not strictly necessary.
The server is set up in a way similar to how
incoming folders have been set up on FTP servers for 30-40 years: You can
cd into that directory and create/write files, and read any files that you can open, but you cannot list the directory's contents (and optionally, you can create and write any file, but not overwrite an existing one).
Assuming that file names cannot be guessed, this is secure insofar as you can't do much without knowing a file's name. An UUID has 128 bits, but you could use any other random file name of the same or greater size (or a 160-bit random name, if you think 128 bits are not enough).
While it is in theory possible to guess a random 128-bit number (and there is even a chance that two filenames will collide by accident), the chances for such a thing to happen is astronimically small given the time it takes to access a file over the network (which severely limits the number of operations per second that you can do). This is much different from e.g. someone brute-forcing a hash from a stolen password database, where the attacker would typically try a few hundred million hashes per second.
You are probably more likely to die from being hit by a meteor than to ever see this in your life.
Also, a quick Google says that S3 supports folders, so if you are in ultra-paranoia mode, you can create a folder with a UUID name and place your UUID-named files in there. Someone would have to guess a 256 bit number correctly for accessing a file, you can be pretty sure that this won't happen during your lifetime.