
Root Domain Website Hosting for Amazon S3 - jeffbarr
http://aws.typepad.com/aws/2012/12/root-domain-website-hosting-for-amazon-s3.html
======
mmastrac
This is great news. Back when we were building DotSpots (now defunct, sadly),
our website was built entirely in GWT. We weren't just serving a static site -
we had the full functionality being run in GWT-compiled code. This meant that
the majority of the site itself could be hosted from a static domain, and only
the APIs behind the scenes needed to be running on our EC2 fleet. At least
that was the idea.

We managed to get the majority of the static images and JS running off
CloudFront back then, but were always stuck serving html from our EC2 boxes (a
combination of what was available from AWS at the time, and the previous one-
day minimum timeout of CloudFront). We put a lot of work into optimizing them
so that they'd be super lightweight and could be served quickly. It was pretty
fast considering that we weren't able to put all of the static-like files into
S3/CloudFront.

Now that you can host the whole static bits of your domain through
S3/CloudFront, I'd love to give this another shot with a future project. With
strongly-named resources (ie: resource name == MD5) being served with one-year
expiration times from Amazon's infrastructure, you could build a blazing fast
dynamic site without having to spin up a single EC2 box.

Exciting!

(My original comment was on the dupe here...
<http://news.ycombinator.com/item?id=4976475>)

~~~
twistedpair
One of the many reasons I <3 GWT. Why run all the logic on the server if it
can live in the client? Currently working on the same with www.runpartner.com
from S3/EC2/CF.

------
saurik
Why do people host static websites on S3 at all? It really isn't designed for
that: it is an object store. Yes: it has a URL structure accessible in a way
that makes it look like static hosting, and Amazon caved pretty early to
people wanting to use it that way by adding features to make it more
reasonable, but it doesn't fix the underlying problem.

Specifically, it is both allowed to-- _and often does_ \--return 50x errors to
requests. The documentation for the S3 API states you should immediately
retry; that's fine for an API where I can code that logic into my client
library, but is simply an unacceptable solution on the web. Maybe there are
one or two exceptions to this, but I have simply never seen a web browser
retry these requests: the result is you just get broken images, broken
stylesheets, or even entire broken pages. Back when Twitter used to serve user
avatar pictures directly from S3 the issue was downright endemic (as you'd
often load a page with 30 small images to request from S3, so every few pages
you'd come across a dud).

Sure, it only happens to some small percentage of requests, but for a popular
website that can be a lot of people (and even for an unpopular one, every user
counts), and it is orders of magnitude higher of a random error rate than I've
experience with my own hosting on EC2; it is also irritating because it is
random: when my own hosting fails, it fails in its entirely: I don't have some
tiny fraction of requests for users all over the world failing.

Regardless, I actually have an administrative need to stop hosting a specific
x.com to www.x.com redirect on some non-AWS hosting I have (the DNS is hosted
by Route53, etc., but I was left with a dinky HTTP server in Kentucky
somewhere handling the 301), and I figured "well, if it doesn't have to
actually request through to an underlying storage system, maybe I won't run
into problems; I mean, how hard is it to take a URL and just immediately
return a 301?", but after just a few minutes of playing with it I managed to
get a test request that was supposed to return a 301 returning a 500 error
instead. :(

    
    
        HTTP/1.1 500 Internal Server Error
        x-amz-request-id: 1A631406498520D6
        x-amz-id-2: hXQ1YXyu0gxaiGITKvcB+P8+tgPsP3UITX/Or4emyjZtaL16ULAyHFx2ROT4QPXY
        Content-Type: text/html; charset=utf-8
        Content-Length: 354
        Date: Fri, 28 Dec 2012 07:19:24 GMT
        Connection: close
        Server: AmazonS3
    

This wasn't just a single-time problem either: I've setup a loop requesting
random files (based on the timestamp of the test run and a sequence number
from the test) off this pure-redirect bucket that I've left running for a few
minutes, and some of the S3 nodes I'm talking to (72.21.194.13 being a great
example) are just downright unreliable, often returning 500 errors in small
clumps (that one node is giving me a 2% failure rate!!). S3 is simply not an
appropriate mechanism for site hosting, and it is a shame that Amazon is
encouraging people to misuse it in this fashion.

(edit: Great, and now someone downvoted me: would you like more evidence that
this is a problem?)

~~~
notaddicted
It is very easy to set up S3 to provide the files to cloudfront ... have you
seen any issues with that?

~~~
saurik
I believe not: I'm pretty certain putting CloudFront in front of your bucket
is fine (it handles the HTTP layering correctly); this problem is one of
attempting to directly host static content from S3 only.

(That said, I have very little personal experience with CloudFront, as in my
experience it is more expensive for fewer features with less POPs than using a
"real CDN" like CDNetworks, or even Akamai.)

(edit:)

For this specific circumstance, I'm not certain at all what CloudFront's
behavior will be; it seems like the "redirect" concept is a property of the
"static website hosting" feature of S3, not part of the underlying bucket, and
CloudFront "normally" (in quotes, as I just mean the default origin options it
provides) directly accesses the bucket.

I thereby imagine that if I simply set a custom origin to the ___.s3-website-
us-east-1.amazonaws.com URL provided by the S3 static hosting feature I will
get the right behavior (where CloudFront forwards and caches the 301
responses), but then I have no clue if it will correctly retry the 500 error
responses.

That said, I will point out that I am not even certain if CloudFront retries
the 500 requests anyway: it occurred to me that with a small error rate
_combined with a cache_ , if you (as I somewhat did at least) expect the
potential fix to be S3-specific, you might simply never really "catch" an
actual failing request in a test scenario.

It could then be that CloudFront retries all 50x failures (in which case if I
set it up with a custom origin to the S3 static hosting URL you'd still get
the retry behavior), but I somehow doubt that it does that (and just earlier I
saw two requests in a row to S3 fail for these 301 redirects, so it might not
even help).

~~~
isb
CloudFront doesn't retry on 500s. Besides, you can't alias to a CloudFront
distribution from x.com apex, so I don't think it would work for you even if
that were the case.

~~~
saurik
CloudFront, when used with Route 53 as your DNS provider, can be used for zone
apex hosting, as you can place an "ALIAS" record (as opposed to a real DNS
CNAME) to the other hostname; this is the same procedure you use to get S3's
static hosting feature working with a zone apex and these new instructions
today. (That said, I have never done this personally with CloudFront, as
again: I do not use CloudFront.)

~~~
donavanm
Nope. Route 53 has to ALIAS to another RR in your own hosted zone. There's no
way for Route 53 to return the A records/IP address RDATA that CloudFront uses
to direct clients to the fastest site.

Other "ALIAS" providers can't do real CloudFront apex support either. Their
intermediate resolvers end up caching the CloudFront records without varying
per client subnet.

~~~
saurik
Interesting! I was reading something in one of the FAQ's earlier that seemed
to indicate that that works, but now digging further and reading through the
forums, I see that you are totally right: you simply couldn't do build this
use-case with pure-AWS (non-EC2) tools without having this new S3 static
hosting redirection feature.

(As for non-Amazon DNS with server-side aliasing support, it wouldn't be
_that_ bad, for this kind of use case: you are already taking a latency hit by
returning the 301, and direct links will never target these URLs as they will
have the canonical www. hostname, so if you just end up with an edge node near
a geo-ip DNS server near the original user, it will be approximately good
enough.)

------
donretag
Now only if Google App Engine would support the same.

The amount of features that AWS release is astonishing given their size. Great
work.

------
toomuchtodo
Great work guys! Now can we work on functionality to prepay for AWS services?
;)

<https://forums.aws.amazon.com/thread.jspa?threadID=51931>

~~~
nikcub
Prepay and keeping user balances puts you in an entirely new compliance
bracket that is much more complicated than charging a credit card and shipping
a product. You get regulated almost like a bank.

I'm not surprised that they aren't bothering with all that yet

~~~
JoshTriplett
Depends on how you treat it. If you treat it like buying a gift card, and
either don't allow refunds or only refund to the same payment mechanism the
user originally used, then you shouldn't trigger any of the "financial
instrument" regulations. That just leaves you with any issues raised by your
credit card processor, about whether you've "delivered" the product the user
purchased.

------
jvoorhis
This is great news. Now I'm looking forward to root domain support for
CloudFront.

------
nodesocket
Instead of using www.mydomain.com as the primary and 301 redirecting requests
from mydomain.com, is it possible to do this the other way around? I want
mydomain.com as the primary and 301 redirect www.mydomain.com.

~~~
surrealize
Yeah, that's what this example does:

[http://docs.amazonwebservices.com/AmazonS3/latest/dev/websit...](http://docs.amazonwebservices.com/AmazonS3/latest/dev/website-
hosting-custom-domain-walkthrough.html)

"In this step, you will configure both buckets for website hosting. First, you
will configure example.com as a website and then you'll configure
www.example.com to redirect all requests to the example.com bucket."

------
gregr
Interesting. Root level cnames go against the RFC spec, yet it seems this
solution is technically on par. Looking at the linked site, users mark the
root as an A record and then select a new option in Route53 called 'Alias'.
Since many DNS providers enforce actual A records, sounds like route53 will
often be required for this feature (not a show stopper for most, just
checking).

FTA: "In the Amazon Route 53 Management Console, create two records for your
domain. Create an A (alias) record in the domain's DNS hosted zone, mark it as
an Alias, then choose the value that corresponds to your root domain name.

Create a CNAME record and set the value to the S3 website endpoint for the
first bucket."

~~~
isb
Route 53 alias feature is RFC compliant - we will return an A record for an
apex alias. Aliases can be used at non-apex too to avoid following CNAME
chains. So, for e.g., the configuration in docs can be improved upon by having
www.example be an alias to example.com instead of a CNAME.

------
saurik
These 301 redirects seem to be billed as "WebsiteGetObject,Requests-Tier2",
which I believe is $0.01 per 10,000 (not including bandwidth, and with no
decrease in price for large scale). I mean, its nice that its hosted in the
cloud and all, but billing at the same rate as a much more complex S3 GET
request (or "GetObject,Requests-Tier2") seems much too expensive (although I
can imagine that if you have only a small number of requests; if you have any
other server on which you can host the 301 redirect, you can do so with a
marginal cost near 0, even at a load of many millions of redirects per day.

------
aneth4
You can also use a service like dnsimple that offers more generalized aliases
to any domain. As I understand it, you can only alias to AWS services with
Route 53, but that may have changed.

I've been using Dnsimple for quite a while to host root domains on heroku.

~~~
donavanm
Sad face indeed. I wish route 53 had generic "alias" support like other
providers. IIRC Route 53 can ALIAS to 1) your own hosted zone 2) an ELB
instance 3) an S3 website bucket.

------
philip1209
You can do similar hosting on the Rackspace/Akamai CDN:

[http://www.rackspace.com/blog/running-jekyll-on-rackspace-
cl...](http://www.rackspace.com/blog/running-jekyll-on-rackspace-cloud-files/)

That's how the Obama fundraising website was hosted

~~~
WestCoastJustin
As far as I know, Rackspace was not involved with the Obama fundraising
website (other than this blog post which talks about Jekyll). Obama
fundraising website was Jekyll/Akamai/AWS[EC2,S3,RDS] [1]. You can also watch
a video from most of the Obama ops team about the stack on AWS [2].

[1] [http://net.tutsplus.com/articles/interviews/chatting-with-
ob...](http://net.tutsplus.com/articles/interviews/chatting-with-obama-for-
americas-director-of-frontend-development-daniel-ryan/)

[2] <https://www.youtube.com/watch?v=X1tJAT7ioEg>

~~~
miles932
I can confirm that.

------
arikrak
I have sites on Amazon S3 and OpenShift, but my Domain Name registar (1&1)
didn't support redirection, so I pointed it to Cloudflare and created a rule
there to redirect from the root to 'www'. This looks simpler though.

~~~
roozbeh18
back when google apps for business was free, they had an option to redirect
your naked domain to www under domains. then all you had to do was to point
your A record to google dns and it would forward it to www.

------
mleonhard
If you want hosted root domain redirects without switching to Route 53, you
can use <https://www.RootRedirect.com/> . I run it on multiple EC2 instances
and EIPs. Notable customers include Pizza Hut Australia and Airport Nürnberg.
My 301 responses are cached on the client so subsequent redirects are
instantaneous.

------
bradgessler
Check out shart at <https://github.com/polleverywhere/shart> if you're looking
for an easy way to deploy static websites, like Middleman, to S3.

------
magoon
I host a web site for my small community on S3 because it's nearly free to do
so and, for such a small site with no server-side programming, it performs
better and is more fault tolerant than a cheap VPS.

------
api
Combined with the ability to set headers to permit AJAX requests to another
site, it would be possible to host a webapp on S3 and have the "live" portion
be a JSON API only.

------
akulbe
Given Amazon's recent outages (and the fact that they happen a lot more
frequently)... hearing about this new service offering doesn't instill a lot
of confidence.

~~~
ceejayoz
Essentially all outages in the last few years have been EBS related.

S3 doesn't have an EBS dependency, and has been pretty rock-solid for half a
decade now.

------
weakwire
Time for heroku to implement root domain redirection!

------
asc76
AWS just keeps on getting better and better. Although, this particular release
isn't that exciting and press-worthy.

------
yosun
i guess amazon no longer needs the naturally free publicity from having 90% of
CDN content URLs being of the format xxx.s3.amazonaws.com ... you can now have
CDN URLs that look like xxx.yourdomain.com :O ... AMAZING!!!

well, let's hope adding domain hosting to amazon doesn't add to further
downtime.

~~~
yosun
sorry for sarc over-simplifying the new offering. :(

~~~
ceejayoz
You're not over-simplifying, you're just wrong.

S3 and CloudFront have supported custom subdomains for years.

------
mdrussell
So now all your root domains can suffer extended downtime on a monthly basis
too? :)

~~~
zwily
What are you talking about? The last big S3 outage was like 5 years ago.

