Access Amazon S3 Static Website Through IPv6

The A-record alias you create has to be the same as the name of the bucket, because virtual hosting of buckets in S3 requires that the Host: header sent by the browser match the bucket name. There's not really another practical way in which virtual hosting of buckets could be accomplished... the bucket has to be identified by some mechanism, and that mechanism is the http headers.

In order to create an alias to a bucket inside the "example.com" domain, the bucket name is going to have to also be a hostname you can legally declare within that domain... the Route 53 A-Record "testbucket.example.com," for example, can only be aliased to a bucket called "testbucket.example.com" ... and no other bucket.

In your question, you're breaking this constraint... but you can only create an alias to a bucket named "simples3websitetest.com" inside of (and at the apex of) the "simples3websitetest.com" domain.

This is by design, and not exactly a limitation of Route 53 nor of S3. They're only preventing you from doing something that can't possibly work. Web servers are unaware of any aliasing or CNAMEs or anything else done in the DNS -- they only receive the original hostname that the browser believes it is trying to connect to, in the http headers sent by the browser ... and S3 uses this information to identify the name of the bucket to which the virtual hosted request applies.

Amazon S3 requires that you give your bucket the same name as your domain. This is so that Amazon S3 can properly resolve the host headers sent by web browsers when a user requests content from your website. Therefore, we recommend that you create your buckets for your website in Amazon S3 before you pay to register your domain name.

http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-create-bucket.html#bucket-requirements

Note, however, that this restriction only applies when you are not using CloudFront in front of your bucket.

With CloudFront, there is more flexibility, because the Host: header can be rewritten (by CloudFront itself) before the request is passed through to S3. You configure the "origin host" in your CloudFront distribution as your-bucket.s3-website-xx-yyyy-n.amazonaws.com where xx-yyyy-n is the AWS region of S3 where your bucket was created. This endpoint is shown in the S3 console for each bucket.

DNS is a hierarchical system, and simply does not provide a mechanism for delegating only the apex record of a zone elsewhere.

The most straightforward solution is to move your DNS hosting to Route 53, because Alias records in Route 53 solve the issue by using Route 53's internal knowledge of the contents of S3's domains (as well as those for ELB and CloudFront) in order to return a correct A-record response to your query. (An Alias isn't a DNS record type, it's a configuration directive.)

There's little reason that I can think of to resist such a change -- you don't have to change your registrar to Route 53 (although you can), you only need to change your authoritative name servers with your current registrar. You can continue to use the current registrar for your annual renewals and any other bonus/bundle things they provide... just not for DNS hosting itself.

Other providers accomplish the appearance of similar functionality by proxying the incoming DNS request to a destination "out the back," looking up the target and returning the appropriate portions of the response to the original requester.

That's what Cloudflare does, with "CNAME flattening" --

The CloudFlare [DNS] server generating the response follows the CNAME chain so that the response to the request from the client (for example, the browser) contains only non-CNAME data -- usually, an IP address. This effectively creates an A or an AAAA record.

https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

Using a web proxy server, with a static IP address and an A record is a viable option -- and, in fact, is not a bad one if you want to serve your site with an SSL certificate (S3 doesn't support SSL for custom domains). If the proxy is in the same AWS region as the bucket, there aren't any additional data transport charges, and a proxy on a given piece of hardware can certainly serve up more content than an actual web server on the same hardware, since there's no disk access. (On one such setup, a t2 micro, running haproxy, I served 891,683 web requests yesterday without ever hitting 5% CPU on the one-minute CloudWatch graph). Of course, this introduces an additional cost and availability issues.

But there are no magic bullets.