Доставка целого сайта на CloudFront

After some more research, it seems that Cloudfront CAN cache your whole website, but whether you want to or not merits investigation. Here's hoping this is useful for any future passersby.

Whole Site Delivery

Here's some information on Whole-Site Delivery Warning: This slideshare is high-level - it doesn't get into details of implementation

In order to accomplish whole-site-delivery, you need to follow these general steps.

Let's assume you want to serve example.com and www.example.com via Cloudfront (you want Cloudfront to act as a site-wide cache, similar to how you might use Varnish).

Setup a distribution

Setup a distribution on Cloudfront for your domain.

• I typically choose to let my origin server decide on cache settings via output headers
• Set your origin to be something like content.example.com

Point your domain

1) Point your domains top-level (example.com and probably www.example.com) to your Cloudfront URL - it'll be something like abc123.cloudfront.net rather than an IP address

Note that this is a CNAME (abc123.cloudfront.net) rather than an A record (IP address). Whether your DNS allows you to set a CNAME over an A for the root domain I believe can vary between providers.

In fact, I think setting a CNAME for your root domain level is against RFC. This might restrict you to having to set the "www" version of your domain to Cloudfront, using Route 53, or using DNS Made Simple as this article suggests.

2) Set your DNS records so that something like content.example.com points to your origin server. This will provide a way for cloudfront to reach your origin server, but the public still use example.com and www.example.com to view site content

Caveats

There are a few caveats:

1. Cookies - Whether or not the cache strips cookies is important. Request with cookies aren't typically cached (or more accurately, each unique cookie will create a different cached copy). Consider having Cloudfront ignore server-set cookies so it can cache content. This won't affect cookies added client-side from services such as Google Analytics or Disqus comments. It will affect server logic if you rely on separating cookies/session IDs from guests and authenticated users.

2. Cloudfront supports GET and HEAD requests. POST and other HTTP verb request will result in error pages. This has implications if you allow users submit forms as well as ajax-requests.

I don't have public users on my site. I do have an admin area that I alone use. I therefore can enter my site's admin area via content.example.com directly rather than via the public example.com and www.example.com. This bypasses the cache altogether, eliminating the need for passing cookies through and allowing the use of any HTTP verb.

That happens to work for me, but I suspect that's not a great situation for most people. YMMV with Cloudfront and whole-site caching. It's still great for static asset caching.

Что мне нужно, чтобы понять, могу ли я указать свой домен на cloudfront, поэтому example.com сначала обращается к кешу Cloudfront (аналогично как бы вы настроили Varnish «перед» исходным сервером).

Да, вы правильно поняли. DNS будет указывать прямо на облачный фронт.

Что в такой конфигурации сделать исходным сервером в Cloudfront? Установка его как example.com приведет к циклической ссылке, где Cloudfront пытается проверить себя на наличие ресурса.

Вам нужно другое доменное имя, указывающее на ваш «источник» (он же ваш настоящий сервер). Итак, если ваш фактический URL-адрес example.com, вы можете сделать direct.example.com, который указывает прямо на ваш хост. Обратите внимание, что сертификаты и правила маршрутизации вашего сервера должны быть в состоянии принять это альтернативное доменное имя.

Должен ли мой исходный сервер больше не отвечать на example.com запросы в этой настройке? (Это позволило мне установить исходный сервер в Cloudfront на что-то вроде «content.example.com» и отвечает на динамические и статические запросы оттуда?)

Правильно. Но вам не обязательно устанавливать для источника значение «больше не принимать» запросы. Вам просто нужно убедиться, что он может обрабатывать запросы через новое имя хоста (например, content.example.com)

Или Cloudfront не идеален для кэширования всего сайта? Должен ли я не попытаться обслужить динамический ответ (вывод HTML) из кеша и обслуживать только статические ресурсы (js, img, css и т. д.)?

Вы абсолютно точно можете кэшировать весь сайт. Cloudfront будет реагировать на заголовки управления кешем (если вы настроите его для этого).Я предлагаю вам убедиться, что вы разрешаете любые типы HTTP-запросов, заголовки и файлы cookie, которые вам нужны (возможно, разрешаете все). Вы можете установить значение TTL по умолчанию равным 0, чтобы он кэшировал только тот контент, который вы ему указали (с заголовками управления кешем).