Хостинг статического сайта на S3 и CloudFront

Хостинг статического сайта на Amazon S3 — дешёвая и масштабируемая альтернатива запуску NGINX/Apache на EC2. Если ваше приложение не рендерит страницы на сервере (PHP, SSR), можно хранить все файлы в S3 и раздавать их напрямую или через CloudFront с поддержкой HTTPS.
Пошагово: собрать приложение (например, create-react-app), синхронизировать папку сборки в S3, включить статический хостинг и добавить политику доступа. Для HTTPS и кастомного домена используйте CloudFront (рекомендуется).

Логотип Amazon S3 и облачная иконография

Этот материал объясняет, когда и как правильно размещать статические сайты и одностраничные приложения (SPA) на Amazon S3, как настроить доступ, обработать HTTPS и варианты автоматического развёртывания. Включены практические рекомендации по безопасности, чек‑листы для ролей и сценарии, когда S3 не подойдёт.

Что значит «статический сайт» и когда S3 подходит

Определение: статический сайт — это набор файлов (HTML, CSS, JS, изображения), которые сервер отдает ровно в том виде, в каком они хранятся, без генерации разного HTML для разных пользователей. Если вся логика выполняется в браузере (на клиенте), а сервер — только API для данных, то сайт можно считать статическим с точки зрения хостинга.

Когда S3 подходит:

Одностраничные приложения (React, Vue, Angular) и статические сайты (HTML/CSS/JS).
Сайты, где рендеринг данных происходит в браузере, а не на сервере.
Портфолио, документация, маркетинговые лендинги.

Когда S3 не подходит:

Приложения с серверным рендерингом (SSR) или требующие генерации страницы на сервере (например, Wordpress на PHP).
Сайты, которым нужен доступ к файловой системе сервера или выполнение серверных скриптов.

Important
Статический сайт может быть современным и интерактивным — это не означает «старую страницу без JavaScript». Статический — значит «без серверного рендеринга HTML».

Преимущества и ограничения S3

Преимущества:

Низкая стоимость для малых и средних проектов.
Без управления серверами — автошкала и высокая доступность.
Простая интеграция с другими AWS‑сервисами (CloudFront, Lambda@Edge, API Gateway).

Ограничения:

Нативно S3 Static Website Hosting не поддерживает HTTPS для кастомных доменов. Решение — CloudFront.
Нельзя выполнять серверный код (PHP, Node.js) непосредственно в S3.
Публичный доступ требует аккуратной настройки политик безопасности.

Быстрый пример: deploy create-react-app на S3

Мы будем использовать проект, созданный через create-react-app, поскольку он хорошо демонстрирует возможность отдавать одно bundle.js и index.html.

Сборка приложения

Сначала соберите проект:

# В корне проекта
yarn build

После сборки в папке /build появятся файлы и папки, которые нужно загрузить в S3.

Содержимое папки сборки React с index.html, static, asset-файлами

Создание бакета в S3

Откройте S3 Management Console и нажмите “Create Bucket”.

Экран создания бакета в S3 с заполненным именем

Дайте бакету уникальное имя (имя должно быть уникально среди всех аккаунтов AWS). На следующих шагах можно включить версионирование, но это по желанию.
На этапе прав вам нужно снять галочку с “Block all public access” только если вы действительно хотите раздавать контент публично. AWS предупредит — это ожидаемое поведение для статического хостинга.

Окно подтверждения включения публичного доступа для статического хостинга

Загрузка файлов в бакет

Можно перетащить файлы вручную через консоль, но удобнее использовать AWS CLI:

aws s3 sync . s3://bucket-name

Пример вывода после успешной синхронизации:

Просмотр содержимого бакета в консоли S3 после синхронизации

Включение статического хостинга

Перейдите в “Properties” бакета и включите “Static Website Hosting”, укажите index.html и, при желании, файл для ошибок (404).

Включение опции Static Website Hosting в свойствах бакета

Добавление публичной политики на бакет

Чтобы объекты были доступны по HTTP, добавьте публичную политику доступа (замените example-bucket на имя вашего бакета):

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
    "Effect":"Allow",
    "Principal":"*",
    "Action":["s3:GetObject"],
    "Resource":["arn:aws:s3:::example-bucket/*"]
  }]
}

После этого ваш сайт будет доступен по дефолтному endpoint:

http://BUCKET-NAME.s3-website.REGION.amazonaws.com/

Тестовый просмотр сайта с адресом s3-website и работающей страницей React

Важно: это “обычный” HTTP‑endpoint. Для HTTPS и кастомного домена используйте CloudFront.

Настройка CloudFront для HTTPS и кастомного домена

CloudFront — CDN, который кеширует контент и может выступать как фронтенд для S3, поддерживая кастомные домены и HTTPS.

Откройте CloudFront Console и нажмите “Create Distribution” → тип Web.
В поле Origin Domain Name выберите ваш S3 бакет.
Включите “Redirect HTTP to HTTPS” для принудительного HTTPS.

Выбор origin и настройка редиректа HTTP→HTTPS в CloudFront

В разделе Alternate Domain Names укажите ваш домен и прикрепите SSL‑сертификат. Можно запросить сертификат в AWS Certificate Manager (ACM). При использовании Route 53 верификация сертификата автоматическая и обычно занимает минуты; при стороннем DNS — до получаса.

Настройка alternate domain и выбор Custom SSL в CloudFront

Нажмите Create Distribution и дождитесь развёртывания (обычно ~15 минут).

Если вы используете Route 53, создайте A‑запись типа Alias, указывающую на дистрибутив CloudFront. Это обеспечит корректное разрешение имени и поддержку HTTPS.

Автоматизация развёртывания

Для удобства версионирования и CI/CD можно использовать AWS CodePipeline, GitHub Actions, GitLab CI или другие инструменты.

Простой pipeline:

Триггер: push в main/master.
Шаг сборки: yarn build (или npm run build).
Шаг развертывания: aws s3 sync build/ s3://bucket-name –delete
(Опционально) Шаг: CloudFront invalidation для очистки кеша:

aws cloudfront create-invalidation --distribution-id E123456ABC --paths "/*"

Альтернативные подходы

Если вы хотите более простое решение без сложной настройки AWS, рассмотрите:

Netlify — простая настройка, автоматические deploys из Git, встроенный CDN и HTTPS.
Vercel — отлично подходит для фронтенд‑приложений, поддерживает SSR/ISR (если нужно серверный рендеринг), автоматизация из Git.
GitHub Pages — для простых статических сайтов (ограниченная функциональность для кастомного домена и HTTPS поддерживается).
Firebase Hosting — быстрый CDN, простой деплой, интеграция с другими GCP сервисами.

Каждое решение имеет свои преимущества: Netlify/Vercel упрощают CI/CD и дают функции уровня платформы без глубокой настройки AWS.

Когда S3 не подойдёт — контрпримеры

Если вам нужен серверный рендеринг (например, SEO‑ориентированный сайт с динамическим HTML), S3 сам по себе не справится.
Если вы храните персональные данные в статических файлах и хотите строгую изоляцию (GDPR, локальное хранение), публичный бакет может быть ошибкой.
Если требуется сложная маршрутизация с серверными хуками на уровне HTTP (middleware), лучше использовать серверные решения или серверлесс функции с рендерингом.

Практические рекомендации по безопасности

По возможности не делайте бакет полностью публичным. Используйте CloudFront Origin Access Identity (OAI) или Origin Access Control (OAC) и давайте прямой доступ только CloudFront.
Минимизируйте права в политике IAM и бакета — принцип наименьших привилегий.
Используйте версионирование объектов, чтобы можно было восстановить случайно удалённые файлы.
Логируйте доступ через S3 access logs или AWS CloudTrail для аудита.
Для приватных файлов используйте подписи временных URL (presigned URLs) вместо публичного доступа.

Пример: как позволить чтение только CloudFront через OAI

Создайте OAI в CloudFront.
В S3 Bucket Policy укажите Principal как OAI вместо “*”.

Минимизируйте период валидности presigned URL и избегайте публикации ключей доступа в клиентском коде.

Чек‑листы по ролям

Developer

Собрать приложение: yarn build.
Проверить относительные пути (особенно для SPA с basename).
Подготовить asset manifest и source maps (по необходимости).

DevOps / Инфраструктура

Создать/зарезервировать уникальное имя бакета.
Настроить версионирование и lifecycle правила для старых артефактов.
Настроить CloudFront и ACM для HTTPS.
Настроить Route 53 записи.

Security Officer

Проверить публичные политики бакета и IAM.
Убедиться в логировании доступа.
Проверить, что личные данные не лежат в публичных файлах.

SOP: Быстрый playbook развёртывания на S3 + CloudFront

Код: влить изменения в основную ветку.
CI: запустить build и unit tests.
Артефакты: собрать в build/.
Деплой: aws s3 sync build/ s3://bucket-name –delete
Инвалидация CDN: aws cloudfront create-invalidation –distribution-id –paths “/*”
Мониторинг: проверить доступность и логи CloudFront.

Критерии приёмки

Сайт доступен по кастомному домену по HTTPS.
Все важные страницы открываются и корректно загружают ресурсы.
Нет публичных конфиденциальных файлов в бакете.
CI/CD автоматически деплоит при push в основную ветку.

Тестовые кейсы

Проверить, что index.html отдаётся при переходе на корень домена.
Открыть несколько страниц SPA напрямую (deep links) — при SPA нужно настроить обработку 404 на index.html при помощи CloudFront или S3 редиректов.
Проверить работу сервиса из нескольких географических регионов (проверить кеш CloudFront).
Проверить восстановление файла из версии при включённом versioning.

Советы по совместимости и миграции с EC2

Перенос статики: скрипт aws s3 sync /path/to/static s3://bucket-name.
Если приложение с сервера отдаёт разную разметку для разных пользователей — нужно сохранить серверную логику (оставить EC2/Lambda) и отделить только статические ассеты в S3.
При миграции проверьте заголовки CORS и политики кеширования.

Примеры команд и сниппеты

Синхронизация и удаление удалённых файлов:

aws s3 sync build/ s3://your-bucket-name --delete

Инвалидация CloudFront:

aws cloudfront create-invalidation --distribution-id E123456ABC --paths "/*"

Подготовка presigned URL (пример на Python):

import boto3
s3 = boto3.client('s3')
url = s3.generate_presigned_url('get_object', Params={'Bucket':'your-bucket','Key':'private-file.pdf'}, ExpiresIn=3600)
print(url)

Частые ошибки и как их избежать

Ошибка: index.html ссылается на ресурсы по абсолютным путям, ломая сборку при размещении в поддиректории. Решение: использовать относительные пути или правильно настроить homepage в package.json.
Ошибка: забыли про инвалидацию CloudFront — старые файлы доступны у части пользователей. Решение: запускать create-invalidation после деплоя.
Ошибка: публичный бакет с конфиденциальными файлами. Решение: использовать отдельный приватный бакет и presigned URL.

Риски и смягчения

Риск DDoS: использовать AWS Shield/CloudFront, настроить WAF при необходимости.
Риск утечки данных: не хранить чувствительные данные в публичных объектах, использовать шифрование и ограниченный доступ.

Локальные альтернативы и нюансы для России

Если важна локальная юрисдикция хранения данных, проверьте требования законодательства и используйте местные облачные провайдеры или регион AWS (если доступен). Для GDPR/локальных регуляций пользуйтесь шифрованием и ограничительными политиками доступа.

Социальная превью и анонс

OG title: Быстрый хостинг статического сайта на S3 + CloudFront OG description: Разместите React или любой статический сайт на S3, подключите HTTPS через CloudFront и автоматизируйте деплой.