Задача
Есть AWS аккаунт, на котором требуется поднять статический сайт (html, js, css, png, jpg) на своём домене example.com.
Ссылки: http://example.com, http://www.example.com, https://www.example.com должны перенаправлять на основной сайт https://example.com.
План действий
Покупка домена
Выпуск SSL сертификата
Заливка файлов html, js, css в S3.
Создание двух CloudFront distributions (основного и для редиректа с www)
Привязка CloudFront функции редиректа к CloudFront distribution
Создание A-записей в DNS
Покупка домена
Route 53 → Registered domains → Register domains
Ищем нужный домен example.com, оплачиваем. Домен появляется в списке Registered domains.
В разделе Route 53 → Hosted zones будет создана hosted zone для выбранного домена example.com с DNS записями NS и SOA.
Выпуск SSL сертификата
Выпускаем Amazon issued SSL certificate для двух доменов: example.com и www.example.com.
AWS Certificate Manager → Certificates → Request certificate
Request a public certificate, Next.
Fully qualified domain name: example.com
Нажать Add another name to this certificate. Добавить www.example.com
Validation method: DNS validation - recommended
Нажать Request.
View certificate. Нажать Create records in Route 53.
В течение нескольких минут статус сертификата поменяется на Issued. Он будет автоматически перевыпускаться до истечения срока действия (год).
Заливка файлов в S3
S3 → Create bucket.
Bucket name: example-com (точки меняем на дефис)
AWS Region: любой по желанию.
Включить Block all public access. (Публичный доступ к файлам в S3 крайне не рекомендуется, AWS предоставляет другие способы доступа)
Нажать Create bucket.
В корень бакета заливаем файл index.html и другие статические файлы любым удобным способом (перетаскиванием или AWS CLI, если файлов много или сложная структура папок) с настройками по умолчанию.
CloudFront distribution для example.com
CloudFront → Distributions → Create distribution
Origin domain: выбрать из списка example-com.s3.amazonaws.com (это S3 бакет, созданный на предыдущем шаге).
Origin access: Origin access control settings (recommended)
Нажать Create control setting. Нажать Create. Выбрать его из списка.
Появится предупреждение: You must update the S3 bucket policy
Viewer protocol policy: Redirect HTTP to HTTPS (для редиректа http://example.com → https://example.com)
Отметить Do not enable security protections
Price class: выбрать нужный по балансу цена/время отклика.
Alternate domain name (CNAME) → Add item → example.com
Custom SSL certificate: Выбрать SSL сертификат из списка.
Default root object: index.html
Нажать Create distribution.
CloudFront функция для редиректа www.example.com → example.com
CloudFront Functions появились в 2021г. как более простая и дешёвая замена Lambda@Edge функций для программной модификации HTTP ответов и заголовков. Эта функция будет использована во вспомогательном CloudFront distribution (www.example.com) на следующем шаге. Когда бразер запрашивает страницу из distribution, к которому привязана эта функция, она мгновенно, без доступа к файлам в S3, вернёт HTTP ответ с кодом 301 (Permanently Moved) и новым URL, https://example.com.
CloudFront → Functions → Create function
Name: Redirect-www-example-com
Description: Redirect www.example.com to https://example.com
Нажать Create function.
На вкладке Development заменить код функции на такой, изменив значение ключа location на свой домен:
function handler(event) {
// NOTE: This example function is for a viewer request event trigger.
// Choose viewer request for event trigger when you associate this function with a distribution.
var response = {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
'cloudfront-functions': { value: 'generated-by-CloudFront-Functions' },
'location': { value: 'https://example.com' }
}
};
return response;
}
Нажать Save changes. Вкладка Publish → кнопка Publish function.
CloudFront distribution для редиректа www.example.com → example.com
CloudFront → Distributions → Create distribution
Origin domain: выбрать из списка example-com.s3.amazonaws.com (выбранное значение не важно, т.к. будет настроен редирект).
Origin access: Origin access control settings (recommended)
Origin access control: выбрать ранее созданный.
Viewer protocol policy: HTTP and HTTPS
В разделе Function associations, в строке Viewer request выбрать CloudFront Functions, выбрать Redirect-www-example-com (функция, созданная на предыдущем шаге)
Отметить Do not enable security protections
Price class: выбрать нужный по балансу цена/время отклика.
Alternate domain name (CNAME) → Add item → www.example.com
Custom SSL certificate: Выбрать тот же SSL сертификат из списка.
Default root object: оставить пустым (не имеет значения).
Нажать Create distribution.
После создания distribution скопировать в буфер текст policy для S3.
Текст policy вставить в S3 → example-com → Permissions → Bucket policy.
Создание A-записи для example.com
Route 53 → Hosted zones → example.com
Create record.
Record name: example.com (поле ввода subdomain - пустое)
Record type: A.
Alias: Yes.
Route traffic to: Alias to CloudFront distribution.
Choose distribution: example.com (*.cloudfront.net).
Нажать Create records.
Создание A-записи для www.example.com
Route 53 → Hosted zones → example.com
Create record.
Record name: www.example.com (в поле ввода subdomain вписать www)
Record type: A.
Alias: Yes.
Route traffic to: Alias to CloudFront distribution.
Choose distribution: www.example.com (*.cloudfront.net).
Нажать Create records.
Обычно записи активируются в течение пары минут.
Результат
Сайт работает по главной ссылке https://example.com.
CloudFront обеспечивает быструю загрузку файлов сайта при любой нагрузке. Обслуживание не требуется.
Ссылки http://www.example.com, https://www.example.com, http://example.com перенаправляют (HTTP code 301) на основной сайт https://example.com.
Обратное перенаправление (example.com → www.example.com) при необходимости делается похожим образом.
Такой способ хостинга отлично работает для небольших сайтов с невысокой нагрузкой. При наличии тяжёлой графики и высокой частоты запросов итоговая цена может оказаться высоковата и стоит задуматься об альтернативах.
Комментарии (20)
BogdanPetrov
28.12.2023 20:09Во сколько в итоге это обойдется? На yandex cloud похожий вариант у меня получился за ~ 30 рублей в месяц, так как нужно оплачивать Cloud DNS, остальное укладывается в бесплатные лимиты.
Andreyul Автор
28.12.2023 20:09Минимум: годовая оплата за доменное имя ($13/год за .com) и $0.5/месяц за управление зоной DNS Route53. Остальные затраты зависят от текущей нагрузки на сайт и объёма переданных ГБ: от пары центов до сотен $ в месяц.
Tempest23
28.12.2023 20:09+1Хоть убейте, не понимаю желания играть в такие авантюры. Это как лотерея, только платишь деньги ты. Не понимаю, зачем в это ввязываться частнику при наличии альтернатив.
savostin
28.12.2023 20:09А можно тоже самое, но только отдельную папку домена хостить на S3, а весь сайт на Lambda/EC2?
denis-isaev
28.12.2023 20:09+6У дедов проще было )
server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; } server { listen 443; server_name www.example.com; return 301 https://example.com$request_uri; } server { listen 443; server_name example.com; ... }
Vaderom
28.12.2023 20:09+1Да, только статический сайт в конфигурации в статье даёт вам сразу кучу преимуществ:
Он дешевле, т.к не нужен сервер с процессором для того чтоб запускать апач
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Он быстрее, т.к тут вы получаете CDN в комплекте
Он требует меньше головняка ибо не нужно обновлять сертификат
Да и насчёт простоты - конфигурация описанная в статье поднимается 30 строками терраформ кода которые можно найти в гитхабе готовым модулем. При желании сразу интегрированным с гитхабом для авто-обновления сайта с билдом (если скажем страничка на nodejs с webpack). И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Так что не уверен что на самом деле проще. Наверное только github pages и всякие такие.
(автор сего камента сам много лет apt-get install apache2 пока не ушел в девопс, если что)denis-isaev
28.12.2023 20:09+6Вообще мой коммент был лулзов ради, но с вашими утверждениями готов поспорить :)
Он дешевле, т.к не нужен сервер с процессором
Сервер вам все равно нужен :) Обязательно с процессором :) Причем он будет нагружен кроме вашего редиректа еще тоннами логики приложений высокого уровня абстракций, которые скрывают от вас тот низкий уровень абстракции, где апач и процессор.
А сравнивать стоимость облака с необлаком без конкретных величин трафика, и т.п. бессмысленно. Каждый будет прав.для того чтоб запускать апач
В моем примере апач запускать не надо :)
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Дискуссионное утверждение )
Он быстрее, т.к тут вы получаете CDN в комплекте
Точно быстрее? После фразы в статье "Price class: выбрать нужный по балансу цена/время отклика."? Более того, тут вот пишут, что для этих функций latency 100мс - это офигеть как круто.
Он требует меньше головняка
Меньше головняка, что аж статью написали о том как это сделать :) Причем через 2 года она скорее всего устареет т.к. админ интерфейсы у прова изменятся и кнопки тыкать нужно будет в других местах.
И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Ну да, без fail2ban на каком-нить vsp, если вдруг вы заинтересовали какого-нибуть доморощенного кулхацкера, у вас будет лежать сервер с вашей статикой, а на serverless, у вас будет лежать на столе счет на несколько килобаксов, т.к. хардлимитов из коробки нет, а прикрутить костыли для гашения всего этого добра, если оно начало жрать финансы, модуля терраформ не нашлось )
P.S.
Но я не хейчу облака, если что ) Они вполне круты для определенного рода задач.Vaderom
28.12.2023 20:09
Данное в статье решение, емнип, умещается в free tier амазона, так что сильно волноватся насчет внезапного счёта на пару килобаксов я бы не стал. Хотя если это волнует больше чем аптайм сайта, склонен согласится. Я в данном случае возможно забил бы на редирект с http вообще, ибо не помню где и кто последние пару лет куда либо тыкался по http, тем самым уменьшил риск на перерасход квоты запусков.
Время отдачи самого cloudfront на порядок быстрее чем запуск фукнции, и это то что вы получите при прямом доступе к файлам по https. И это будет более-менее одинаково безотносительно того как далеко юзер от вашего сервера.
Если не рассматривать варианты физического сервера (или кустарщину а-ля подавать сайт с домашнего компа) - альтернативы облаку в данном случае все сами по себе "облачные", будь то vpc-шка в хецнере или что либо другое. Так что для данных требований на сегодняшний день, если ты не организация у которой есть своя платформа для раздачи статики - шило на мыло, а мыло в этом случае означает админить свой сервак. Для дедов у которых конфиги апача от зубов отскакивают - не вопрос. А для тех кто родился после 2000 года - уже не факт ))
И вам придётся таки жёстко поспорить за утверждение что S3 + cloudfront не обгоняют по надёжности сервачок с апачем, даже если его админит сам Линус ))а прикрутить костыли для гашения всего этого добра, если оно начало жрать финансы, модуля терраформ не нашлось )
terraform destroy
Проблема не гасить, проблема узнать что есть проблема, особенно в амазоне где обновления билинга могут опаздывать аж на сутки, за которы может утечь многоводыбаксов.
Хотя в целом, если требуется поднять статический сайт хоть как-то за 2 копейки я бы тоже не шёл в амазон а выбрал бы решение где биллинг фиксирован и есть защита от такой ерунды, даже если это будет стоить на пару копеек больше, зато фикс.
Arkasha
28.12.2023 20:09+1Вы сами пишете, что счёт может быть несколько сотен баксов, потом - что "Он дешевле", а потом - что нет нормальной защиты от гигантских счетов (при чём амазоны специально всё путают)
Время отдачи самого cloudfront на порядок быстрее чем запуск фукнции
В примере nginx файлы отдаёт. Он быстрый. Вы бы лучше написали, какая нагрузка планируется, чтобы вам можно было наглядно на примере ответить по финансам
льтернативы облаку в данном случае все сами по себе "облачные", будь то vpc-шка в хецнере или что либо другое
Альтернатива - vps. Без "облаков" (как хостинги жили и живут без этого слова - загадка)
И вам придётся таки жёстко поспорить за утверждение что S3 + cloudfront не обгоняют по надёжности сервачок с апачем
Есть вероятность, что у вас деньги на "облако" раньше закончатся, чем vps-ка ляжет, в остальном тут не о чем спорить.
Dmitri-D
28.12.2023 20:09+1да, но только скорость nginx не играет никакой роли если а) у вас тормозной диск, а файлов много и они не влазят в кеш б) если клиент с другой стороны земли и до него сигнал даже со скоростью света, без учета тормозов раутеров, всё равно идет десятки миллисекунд. Скажете это не много? Но в силу особенностей протокола HTTP вам нужно сначала запросить страницу, потом получить ее - вот уже пакет туда и пакет обратно. А потом надо запросить все ресурсы на этой странице (картинки и стили) и снова пакет туда, пакет обратно. Уже 4 раз. Это еще если сессия SSL уже установлена. А если нет - браузер еще должен получить сертификат и сбегать проверить его цепочку. Обычно и сертификаты цепочки - в той же стране.
AWS решает эту проблему наличием датацентров во всех уголках мира, за исключением некоторых стран, напр. России. Врочем, судя по всему, Россия была в планах тоже. Поэтому 30ms на RTT сокращаются до минимума и всё работает быстрее.
И S3 надежнее, конечно, чем одиночный диск, не нужно с этим спорить. И горизонтально масштабируется очень хорошо.denis-isaev
28.12.2023 20:09100мс форы, которую дает latency этих CloudFront Functions покроют удаленность клиента от сервера при отсутствии CDN.
Касательно надежности S3, я вот тут нашел SLA амазона на S3 в котором они пишут, что за просадки до 99.9 они вообще никак не отвечают, а за просадки до 99.0 они отвечают 10% платежа. Т.е. получается они официально могут лежать до 40 минут в месяц без штрафов, а за штраф в 10% могут спокойно валяться 7.5 часов каждый месяц. Не сказал бы, что это крутой SLA. Вот тут попсовый beget обещает такой же SLA на свои VPS-ки.
Если что я не хейчу облака или CDN - это важные штуки, но пользоваться ими надо уметь, бездумное использование может приводить к забавным последствиям.
В гугле целый плейлист запилили на несколько часов посмотра на предмет "как не залететь". И это только верхушка айсберга )
chilic
28.12.2023 20:09+1У дедов было так:
<IfModule mod_rewrite.c> RewriteCond %{HTTP_HOST} ^www.example.com$ [NC] RewriteRule ^(.*)$ http://example.com/$1 [L,R=301] </IfModule>denis-isaev
28.12.2023 20:09Тогда уж виртуалхостами: ) И тогда надо наоборот non_www -> www, в те времена именно так редиректили :)
zabanen2
28.12.2023 20:09я в восторге от гайда!
1) структурированность
2) восхитительная последовательность ссылок вместо обычных скриншотов или описания действий!
3) текст вместо скриншотов!
4) компактность!
5) единичная статья с нормальными тегами
BobArctor
28.12.2023 20:09И пачка случайно (или не очень) пришедших ботов отправляет ваш баланс привязанной карты в минус (пока "бесконечно масштабируемое решение" не стукнется о lambda concurrency soft limit)
Sanes
Для чего это? Хостинг стоит копейки.
WondeRu
Когда вся инфра в aws, бывает проще сделать на том же решении.
Sanes
Это по-вашему проще?