Сколько нужно сервисов AWS для простого блога

Десять.

В этой статье я разберу по шагам сколько требуется сервисов Amazon Web Services для того, чтобы запустить статичный блог. Параллельно на примере Василия Пупкина я буду считать сколько понадобится сервисов для достижения того же результата, но без Амазона. Заодно сравним цены насколько «дешевле shared hosting».

Шаг первый: Регистрация домена и DNS

Наверное, все согласятся, что блог лучше иметь на своем домене. Василий Пупкин идет на GoDaddy или NameCheap и регистрирует vasilypupkin.sexy. Я иду в Route53 Registrar и регистрирую marat.to. Большинство регистраторов доменов предоставляют DNS-серверы бесплатно, у амазона Route 53 будет стоить дополнительных $0.10 в месяц.

Итого: +2 сервиса; Пупкин $0; AWS $0.10/мес. Стоимость домена не считаем.

Шаг второй: хостинг статики

В данном упражнении мы делаем сайт статическим генератором, например, Hugo, Jekyll или Eleventy. Результат работы сборщика нужно куда-то загрузить. Василий Пупкин берет shared hosting прям от своего DNS провайдера, загружает все файлы по FTP (+1 сервис) и настраивает nginx (+1 сервис). У namecheap, например, такой сервис обойдется в $2.88/мес, но, наверно, можно найти и бесплатный.

Я создаю AWS S3 bucket и загружаю туда файлы. После настройки DNS записей оба блога, в принципе, работают.

Итого: Пупкин +2 сервиса, +$2.88/мес; AWS +1 сервис, +$0.

Промежуточный итог: минимальная конфигурация для рабочего статического сайта — это 4 сервиса Пупкина за $2.88/мес и 3 сервиса AWS за $0.10/мес.

Шаг третий: TLS сертификат

В 2021 году отдавать свой сайт по HTTP небезопасно. Нам нужен TLS сертификат. Василий Пупкин идет настраивать Let's Encrypt на своем хостинге, но быстро сталкивается с суровой реальностью. Certbot запустить не получится, а в cPanel хостера можно сертификат только купить за $8.88/год.

Я захожу в AWS Certificate Manager и создаю сертификат в один клик за $0.00/мес.

Итого: +1 сервис; Пупкин +$0.74/мес, AWS +$0

Шаг четвертый: Content Delivery Network (CDN)

Поскольку сайт статический, имеет смысл кэшировать картинки и CSS-стили, чтобы каждый визит не грузил и без того слабый shared хостинг. Вдобавок CDN-серверы распределены по всей планете, поэтому задержка до сайта будет одинаковая что из Бразилии, что из Москвы. Если сайт грузится долго, то читатели просто закроют вкладку до того, как он загрузится, а у нас их всего десять человек! Очень ценные люди.

Василий Пупкин решает использовать CloudFlare и уходит еще на день в чтение документации как там правильно все настроить. Тут начинаются проблемы: TLS сертификат, купленный у Namecheap, уже нельзя использовать в Cloudflare. Впрочем, Cloudflare даст свой бесплатно. DNS-серверы на namecheap не могут прописать apex запись для vasilypupkin.sexy, потому что CNAME указать нельзя, а список A и AAAA адресов у CloudFlare постоянно меняется. Вася перенастраивает DNS с namecheap на Cloudflare, прописывает нужные записи, политику кэширования картинок и CSS, получает новый TLS сертификат и готово!

Я поднимаю AWS CloudFront в один клик и цепляю к нему сертификат, полученный на третьем шаге. Все apex записи в Route 53 нативно поддерживают ALIAS для CloudFront.

Итого: +1 сервис, +$0 в обоих случаях.

Шаг пятый: HTTP заголовки

Мало добавить TLS сертификат. Нужно указать браузеру, чтобы он никогда не пользовался небезопасным HTTP при доступе к сайту. Плюс нужно отключить всякие небезопасные функции у старых браузеров и прописать политику безопасности для контента.

Пупкин начинает настраивать nginx, я добавляю Lambda@Edge.

Итого: Вася +0 сервисов; +1 AWS сервис; +$0 в обоих случаях.

Шаг шестой: git и автоматическая сборка сайта по коммиту

В идеале хочется хранить данные в git, чтобы обеспечить версионность, и собирать блог по коммиту. Вася регистрируется на github.com и добавляет Github Actions. После нескольких часов Василий справляется с интеграцией Actions с выгрузкой контента по ssh. Я подключаю CodeCommit вместо GitHub, CodeBuild вместо GitHub Actions, и CodePipeline для автоматизации выгрузки в S3.

Итого: +2 сервиса у Василия, +3 сервиса AWS; +$0 в обоих случаях.

Шаг седьмой: дать доступ к сайту твоему другу

Блог Василия немного подрос и теперь у него есть второй автор, Иван. Ему нужно дать доступ к git-репозиторию, но не к master-ветке. По каждому коммиту Ивана Василий хочет поднимать предпросмотр сайта на домене preview.vasilypupkin.sexy и после ревью добавлять изменения в master. Василий теперь начинает все действия с первого шага, настраивает github так, чтобы Иван не мог ничего коммитить лишнего, и добавляет еще один github action для билда предпросмотра.

Я просто запускаю всю описанную инфраструктуру еще раз одной командой cdk deploy на другом домене, использя AWS Cloud Development Kit. Ивану создается отдельная роль в AWS IAM, которая ограничивает его доступ к production ресурсам.

Итого: + столько же сервисов у Ивана заново, +1 AWS сервис.

Суммарно

Василий: 8 сервисов (два раза), $3.62 в месяц (два раза).

AWS: 9 сервисов + 1 для воспроизведения всех действий, $0.10 в месяц.

Справедливости ради, AWS под капотом будет использовать еще пару сервисов. Например, CloudWatch для логов или CloudFormation для provisioning и прочие мелкие сервисы, о которых Василий предпочел не думать.

Читатели начнут возражать, что всё то же самое можно было сделать на Netlify или Vercel, но чем подобный vendor lock-in будет отличаться от AWS, пояснить они не смогут. В данной статье я не затрагивал вопросы безопасности и доступности (Service Level Agreement, SLA). Сравнить надежность AWS и шаред хостингов можете самостоятельно.

Не согласны? Пишите реплаи в твиттер @touzoku.