I ran into this problem recently and I found a workaround that seemed to work.
I created a Cloudfront distribution with a custom origin pointing to the S3 static website hostname instead of the bucket hostname. In the OP's case, the desired origin would be.
mysite.s3-website-us-east-1.amazonaws.com
Hitting a Cloudfront distribution just using the bucket as the origin does not work because the bucket does not actually serve redirects. It only serves files and stores metadata.
Hope that helps.
Option 1 will not work with S3-hosted web sites because what S3 sees in the Host: header of the incoming HTTP request must match exactly the name of the bucket, and setting a duplicate A record does will not solve your problem.
Option 2 will not work for the same reason -- the request will never arrive at the bucket containing the redirect rules except for requests directed toward the actual name of the bucket. The answer you linked to is nothing more than the "hard way" of doing Option 6, and requires one bucket per hostname.
Option 3 is not useful because PTR records don't cause browser redirects. Usually used for reverse-DNS, A PTR record has no application in this context.
Option 4 Go Daddy has options called "Domain Forwarding" and "Subdomain Forwarding" but this means you have to have your DNS hosted by Go Daddy, not just have your domain registered there (those are two different things that often, but not necessarily, go together). If this is what you have now, you can "forward" the "www" subdomain (www.example.com) to the apex (example.com) which Go Daddy accomplishes by creating either A or CNAME records for www.example.com which point to their own web servers, which generate HTTP 301 or 302 redirects to http://example.com. If your DNS is hosted with Go Daddy, and not on Route 53, then this is probably the simplest option, but if your DNS is not hosted with Go Daddy, this option is not available. Since you are using the apex of your domain as a web site in S3, I'm assuming your DNS is hosted with Route 53, which means this won't work.
Option 5 seems like a bad idea, introducing an unnecessary third party into the equation, but more importantly, it solves the wrong problem. They don't redirect www.example.com to example.com, they redirect example.com to www.example.com.
Option 6 is a good choice, with the drawbacks that you mentioned, regarding the limited number of buckets available to each AWS account.
If you have that many different domains, than another option would be to allocate an Elastic IP Address in EC2 (so that you have a static endpoint IP address that won't change), then spin up a Micro instance bound to that IP address and install HAProxy on it. HAProxy is actually designed to front-end actual web servers and load balance traffic to them from the outside world, but it also has the capability of generating redirects. Configuration is not terribly complicated, and HAProxy is very efficient with CPU, so I would expect you'd get a lot of work out of a Micro but could always scale it up to a larger instance if traffic made that necessary.
You'd configure a front-end listener on port 80:
frontend main
bind *:80
And then for each domain create an access control list (acl) to watch for requests containing that hostname in the "Host" http header...
acl www.example.com hdr(host) -i www.example.com
...then configure a redirect to generate a 301 to the desired hostname.
redirect prefix http://example.com if www.example.com
In DNS, you'd configure www.example.com with an A record pointing to this Micro instance's public Elastic IP address.
With this configuration, the path is preserved, so a request that is sent to any path, sush as http://www.example.com/foo/bar will be met with an HTTP 301 redirect to the exact same path on the other domain, such as http://example.com/foo/bar.
You can do similar things with an actual web server running on a machine, such as Nginx or Apache, but HAProxy is a very heavy-duty-yet-light-weight tool that seems quite appropriate for such a task, and generating redirects like this this is one of the things that I use it for in my operations.
Best Answer
There isn't a way to do this in Route53/CloudFront without getting a server involved. Like it or not, your best option is an EC2 t1.micro instance that handles these redirects.