Отказались от AWS в пользу Hetzner и снизили расходы на хостинг примерно на 70% без существенной потери качества. Практический разбор миграции, используемых инструментов и итоговых метрик.
0
Статья была полезной?
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…
Мы завершили миграцию с AWS на Hetzner в середине 2025 года и зафиксировали экономию около 70% на ежемесячных расходах. Ниже — подробный отчет: почему приняли решение, как проходил план миграции, какие части инфраструктуры сработали «из коробки» и что пришлось допиливать вручную.
Почему ушли с AWS?
Основной мотив — стоимость. В январе 2025 года счёт за облачные услуги стабильно рос: мы платили около 7 200 USD в месяц за комбинированную инфраструктуру (EC2 + RDS + ALB + EBS + S3 + трафик). Бизнес требовал сокращения расходов без снижения производительности и отказоустойчивости.
Помимо цены были и вторичные причины:
Накладные расходы на сетевой трафик: NAT Gateway и межрегиональные передачи увеличивали счёт на ~900 USD/мес.
Сложность биллинга и непредсказуемые spike-расходы в периоды CI/CD и бэкап-операций.
Наличие альтернатив с сопоставимым функционалом: Hetzner Cloud предлагал S3-совместимое Object Storage, Load Balancer и дешевые облачные серверы с фиксированной ценой.
Выбрали Hetzner как баланс цены и удобства: у них была простая ценовая модель, API, Terraform-провайдер и «чистые» тарифы без хитрых дополнительных плат.
Какая инфраструктура была
Описание исходной архитектуры в AWS в марте 2025 года:
Ежемесячные расходы по категориям (январь—февраль 2025, округлено):
EC2 + EBS: 3 200 USD
RDS: 1 800 USD
S3 + запросы + исходящий трафик: 900 USD
ALB + NAT + IP: 600 USD
Мониторинг/логирование/прочее: 700 USD
Итого: ~7 200 USD/мес
Критерии при выборе целевой платформы
Мы оценивали провайдеров по таким параметрам:
Стоимость стабильной инстансной тарификации и дисков.
Поддержка S3-совместимого Object Storage или возможность развернуть MinIO.
API и Terraform-провайдер.
Наличие сетевых опций: Load Balancer, Floating IP, VPN.
Простота резервного копирования и snapshot-ов.
План миграции
Миграция была рассчитана на 2 этапа: подготовительный и рабочий. Время выполнения — с мая по август 2025 года, с постепенным переносом трафика и тестированием на каждом шаге.
Этап 0: инвентаризация и тестирование
Провели аудит: какие сервисы критичны, где есть stateful-данные, что можно пересобрать в контейнеры.
Создали небольшую тестовую среду на Hetzner в июне 2025 (nbg1, fsn1) с минимальным набором сервисов.
Прогнали load-тесты с JMeter для характерных пиков — 500 RPS в течение 20 минут.
Этап 1: перенос хранения и резервов
Выбрали Object Storage Hetzner (S3-совместимый) для основных файлов, разместили архивы на Storage Box.
Перенос S3: использовали rclone и awscli для синхронизации, пример команды в июле 2025:
aws s3 sync s3://my-bucket/ s3://hetzner-bucket/ --source-region eu-central-1
# или через rclone (s3-совместимый Hetzner)
rclone sync s3:aws-bucket s3:hetzner-bucket --s3-endpoint=https://s3.eu-central-1.hetzner.com
Развернули MinIO в качестве кэша и тестовой S3-совместимой прослойки для локальной разработки.
Этап 2: базы данных
Самая деликатная часть — MySQL (RDS). Решения, которые рассматривали:
Оставить RDS в AWS и подключиться из Hetzner (выявлено: дорогой исходящий трафик).
Перенести на управляемую базу у стороннего провайдера (ScaleGrid и прочие) — дорого и непрозрачно.
Развернуть MariaDB/MySQL на Hetzner с репликацией: выбрали этот путь.
Шаги миграции БД в августе 2025:
Создали новую кластерную конфигурацию MariaDB (3 узла) на Hetzner Cloud с дисками NVMe для производительности.
Сняли полный дамп из RDS в момент низкой нагрузки и прогнали инкрементальную репликацию:
# на RDS
mysqldump --single-transaction --master-data=2 --databases myapp > dump.sql
# загрузили на primary в Hetzner
mysql < dump.sql
# настроили репликацию, проверили статус
SHOW SLAVE STATUS\G
Мы планировали короткую даунтайм-окно утром воскресенья: окончательная промена DNS и переключение на нового мастера заняли ~12 минут для работы приложения в продакшн.
Этап 3: compute и сеть
Разворачивали виртуальные серверы через Terraform и Hetzner Cloud API. Пример конфигурации Terraform (сокращённый):
Использовали Floating IP для быстрых переключений и hetzner load balancer для HTTPS-терминации.
Этап 4: CI/CD и monitoring
CI/CD: перенастроили GitHub Actions для деплоя на Hetzner через SSH + Terraform. Внедрили immutable-deploy: новые инстансы, тесты, переключение.
Monitoring: оставили Prometheus + Grafana, но перевели экспортёры на новое окружение и настроили Alertmanager. CloudWatch остался для исторических метрик за период 12 месяцев.
Что получилось из коробки
Некоторые элементы инфраструктуры сработали без доработок и потребовали минимальной адаптации:
Создание инстансов через API/Terraform: Hetzner Cloud поддерживает полноценный провайдер Terraform, что позволило одноразово описать инфраструктуру и реплицировать её быстро.
Floating IP и Load Balancer: аналог ALB, базовый набор фичей (TLS-терминация, health checks) — выставили HTTPS через Let's Encrypt и отработало стабильно.
Object Storage (S3-совместимый): большинство операций S3 перенеслись без изменений, rclone и boto3 работали корректно.
Snapshot-ы дисков: Hetzner предоставляет snapshot-ы и backup schedule — мы использовали для быстрого восстановления и тестирования масштабирования.
Время и стоимость развертывания
Первичное развертывание тестовой среды заняло 3 рабочих дня (июнь 2025), а перенос production — около 7 дней активных работ (с учётом даунтайм-окна и откатов). Порог входа по времени оказался низким благодаря Terraform и знакомым инструментам.
Что пришлось допилить
Несмотря на общую гладкость, были критические и мелкие доработки:
1. Сеть и безопасность
Hetzner не предоставляет все managed-возможности AWS VPC. Придумали архитектуру с приватной сетью + firewall rules на уровне хоста и cloud-firewall API. Настроили strimzi и fwctl через Ansible.
VPN между офисом и Hetzner: настроили strongSwan в связке с маршрутизацией. Для тех же задач на AWS мы использовали Managed VPN — тут всё вручную.
2. Бэкапы и долговременное хранилище
Hetzner Object Storage подходит для большинства сценариев, но для дешёвого архивирования в долгосрочный cold storage решили использовать внешние архивы на Backblaze B2 для старых бэкапов. Написали cron-скрипты для lifecycle.
3. Автошкалы и оркестрация
В AWS мы пользовались Auto Scaling Groups. На Hetzner были два пути: Kubernetes (K3s/Kubernetes) или собственные cloud-init + systemd + Terraform для воспроизводимости. Выбрали гибрид: критичные фоновые воркеры — под K3s, веб — на managed-instances с autoscaling-скриптами.
Реализовали простой горизонтальный scaler через Prometheus-алерты и автодеплой новых инстансов по API.
4. Латентность и CDN
Hetzner располагается в нескольких европейских зонах (nbg1, fsn1). У нас были пользователи и вне Европы, поэтому подключили Cloudflare CDN для статики и уменьшения времени ответа. Это снизило входящий трафик к Object Storage на 40%.
5. CI/CD и секреты
Заменили использование IAM-ролей: для доступа к Hetzner API настроили токены и Vault для секретов. GitHub Actions использует HashiCorp Vault + deploy keys.
Какие результаты?
Ключевой показатель — снижение ежемесячных расходов. Финальные числа для сентября 2025 — февраля 2026 (средние месячные):
Расходы на Hetzner Cloud (инстансы + диски): ~1 400 USD/мес.
Дополнительные сервисы (Backblaze B2 для архивов, Cloudflare, мониторинг): ~200 USD/мес.
Итого: ~2 000 USD/мес.
Сравнивая со старым значением 7 200 USD/мес, мы получили экономию порядка 72%.
Метрики производительности и SLA
Среднее p95 latency веб-запроса: выросло с 320 ms до 340 ms — +6% (в пределах приемлемого для бизнеса).
Время переключения при failover БД: уменьшилось с 35 сек (RDS failover) до 18 сек (MariaDB + keepalived/HAProxy), благодаря настроенному репликационному топологу.
Аптайм за 6 месяцев после миграции (сентябрь 2025 — февраль 2026): 99.94% (учтены плановые работы и два коротких инцидента в ноябре и январе).
Операционные расходы и командные усилия
Перенос потребовал дополнительных усилий команды DevOps (примерно 0.6 FTE в течение трёх месяцев). После стабилизации поддержка сократилась: для повседневных задач хватает 0.1–0.2 FTE.
Экономия достигнута за счёт линейного уменьшения стоимости инстансов и дисков, а также отказа от ряда управляемых сервисов с высокой добавочной ценой.
Чему научились и что посоветовать
Тщательно планируйте миграцию баз данных. Делегирование RDS нам стоило бы потери в цене; собственная MariaDB дала контроль, но потребовала больше внимания к HA и бэкапам.
Используйте Terraform и хранилище состояний (remote state) с самого начала. Это ускорит восстановление и повторяемость окружений.
Не экономьте на мониторинге: продумайте метрики, alerting и playbooks для инцидентов.
CDN — лёгкий способ снизить трафик и улучшить UX для пользователей из других регионов.
Если вы хотите посмотреть похожие кейсы по оптимизации и DevOps-практикам, ознакомьтесь с материалами в разделе DevOps и статьями про серверы в разделе Серверы на нашем сайте.
Примеры реальных скриптов
Привожу рабочий пример Ansible playbook для установки docker и запуска контейнера приложения на Hetzner-инстансе (сокращённый):
В примерах выше важно настроить корректные права доступа и периодические сверки контрольных сумм, чтобы не потерять данные при синхронизации.
Итог: миграция с AWS на Hetzner потребовала планирования, ручной работы и доработок по сети и HA, но дала устойчивое снижение затрат без значимой потери качества обслуживания. Если бюджет и контроль важнее максимально управляемых сервисов "из коробки", переход может быть оправданным и выгодным решением.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…