Когда инфраструктурный счёт за AWS начинает пугать, а трафиковые счета пугают ещё сильнее, взгляд закономерно уходит к Hetzner: немецкий провайдер с дата-центрами в Нюрнберге, Фалькенштайне, Хельсинки и Ашберне с виртуалками от 4 евро в месяц и почти бесплатным трафиком. Но переезд это не только вопрос цены. У Hetzner другое устройство API, свои ограничения по сети и дискам, иной набор managed-сервисов. В статье разбираем реальную настройку через официальный клиент hcloud, как устроена автоматизация, и где разница с AWS на самом деле ощущается в деньгах и в эксплуатации.
Установка hcloud-cli и первый контур
Официальный CLI hcloud это один бинарник на Go, собранный под Linux, macOS и Windows. В Linux его проще всего скачать с GitHub Releases или поставить пакетом: на Debian и Ubuntu доступен репозиторий, на macOS есть brew install hcloud. Быстрый вариант без пакетного менеджера: скачать архив из релизов, распаковать и положить в /usr/local/bin/hcloud.
После установки нужен API-токен из панели Hetzner Cloud: проект, Security, API Tokens, с правами Read & Write. Токен подаётся CLI одним из трёх способов: через переменную окружения HCLOUD_TOKEN (самый удобный для скриптов), через hcloud context create (интерактивно создаёт контекст и хранит токен в ~/.config/hcloud/cli.toml), или через флаг --token в каждой команде. Для CI и Terraform первый вариант самый чистый: export HCLOUD_TOKEN=... один раз на runner, и все команды дальше работают в выбранном проекте.
Проверка, что всё на месте: hcloud server-type list покажет таблицу доступных типов, а hcloud datacenter list - список дата-центров: nbg1-dc3 (Нюрнберг), fsn1-dc14 (Фалькенштайн), hel1-dc2 (Хельсинки), ash-dc1 (Ашберн) и hil-dc1 (Хилсборо). Уже на этом этапе видна важная разница с AWS: у Hetzner зоны и дата-центры не распределены по десяткам регионов, а сгруппированы по нескольким площадкам. Даже если нужна мульти-AZ архитектура, здесь выбирают два разных дата-центра как аналог AZ.
Создание сервера через hcloud с cloud-init и SSH-ключом
Минимальная последовательность реального запуска: сначала ключ, потом сеть, потом сервер. SSH-ключ загружается один раз: hcloud ssh-key create --name mykey --public-key-from-file ~/.ssh/id_ed25519.pub. Приватная сеть создаётся для связи между машинами: hcloud network create --name backend --ip-range 10.0.0.0/16, потом hcloud network add-subnet backend --type cloud --network-zone eu-central --ip-range 10.0.1.0/24. Сеть нужна не всем, но с ней серверы общаются по внутренним адресам без публичных IP, и трафик между ними не тарифицируется.
Сам запуск выглядит так:
hcloud server create \
--name app-01 \
--type cax11 \
--image ubuntu-24.04 \
--location fsn1 \
--ssh-key mykey \
--network backend \
--user-data-from-file bootstrap.yml
Здесь несколько решений, которые стоит проговорить. Тип cax11 это ARM Ampere с 2 vCPU и 4 ГБ RAM за символические деньги, но если прикладной софт собран только под x86, берите cx22: 2 vCPU Intel, 4 ГБ RAM, чуть дороже cax11. Выбор location определяет, в каком дата-центре будет жить диск и трафик. Параметр --user-data-from-file принимает cloud-config файл, и cloud-init в образе Ubuntu 24.04 отрабатывает его при первом старте точно так же, как на EC2: установка пакетов, создание пользователей, запуск systemd-юнитов.
После создания hcloud server describe app-01 покажет публичный IPv4 и внутренний адрес в network. У Hetzner публичный IPv4 платный отдельно (порядка 0.5 евро в месяц), и ради экономии некоторые сервисы выпускают наружу только через NAT: тогда при создании сервера можно не просить публичный IP и полностью закрыть машину от мира, выходя наружу через отдельный NAT-инстанс.
Локальные диски у Hetzner зеркалированы на уровне хоста через Ceph, и отказ одного диска не приводит к потере данных. Но это не отменяет бэкапы: hcloud server enable-backup app-01 включает ежедневные снапшоты за 20% от цены сервера. Отдельные диски данных создаются через hcloud volume create --name data --size 100 --server app-01 --format ext4 - volume пристёгивается к серверу и живёт независимо, это прямой аналог EBS.
Что в Hetzner устроено иначе, чем в AWS
Главное отличие - масштаб managed-экосистемы. В AWS из коробки: RDS, ElastiCache, SQS, EKS, Lambda, CloudWatch и ещё сотня сервисов. У Hetzner из managed остаётся объектное хранилище (S3-совместимое), балансировщик нагрузки, managed Kubernetes и появившиеся managed базы данных. Всё остальное придётся поднимать самому на своих виртуалках. Это не минус, это другой профиль: Hetzner выгоден тем, у кого есть навык самостоятельной эксплуатации, а AWS выгоден тем, кто готов платить за готовый сервис вместо своих рук.
Второе отличие - сеть. У AWS каждому аккаунту положено 100 ГБ бесплатного исходящего трафика в месяц, а сверх порога трафик наружу стоит порядка 0.09 USD за гигабайт. У Hetzner в каждый тариф включено от 20 ТБ исходящего трафика в месяц, превышение стоит около 1 евро за ТБ. Для сервиса, отдающего 10 ТБ в месяц, разница на одном трафике это уже сотни долларов ежемесячно. Это и есть главная причина, по которой контент-проекты любят Hetzner.
Третье - лимиты. У AWS через поддержку поднимаются квоты почти до бесконечности. У Hetzner новый аккаунт имеет ограничения по количеству серверов и ресурсов; увеличение лимитов тоже делается через запрос, но проходит вручную и медленнее. Для стартапа это не проблема, для резкого набора сотен виртуалок под всплеск нагрузки - уже требует подготовки.
Четвёртое - юридическая география. Дата-центры Hetzner в Германии и Финляндии дают GDPR-совместимость из коробки для европейских клиентов, и это иногда главный аргумент выбора. У AWS тоже есть европейские регионы, но сопроводительная нагрузка по compliance на стороне клиента выше из-за американской юрисдикции провайдера.
Сравнение цен на одинаковой конфигурации
Конкретика полезна на одинаковой нагрузке: 4 vCPU x86, 8 ГБ RAM и 80 ГБ диска, круглосуточная работа. У Hetzner это cx32 (примерно 7.4 евро в месяц в базовой конфигурации) или cax21 на ARM примерно за 4.5 евро. В AWS ближайший аналог - t3.large с burstable credits (около 53 USD в месяц во Франкфурте до учёта докупленных кредитов) или m5.large (около 70 USD). Даже если burstable t3 хорошо подходит под волнообразную нагрузку, разница на голой машине - от трёх до десяти раз в пользу Hetzner. Трафик добавляет новую ступень: 20 ТБ включены в цену машины у Hetzner; в AWS тот же объём internet egress обошёлся бы в районе тысячи восьмисот долларов.
Когда AWS всё же нужен: ключевое - managed-сервисы и глобальное присутствие. Если сервис опирается на RDS с автоматическим failover, ElastiCache, SQS, Lambda, CloudFront с edge-точками на пяти континентах - чтобы построить эквиваленты на Hetzner, вы заплатите собственными вечерами. На маленьком масштабе это разумно; при сервисе с десятками тысяч RPS managed-сервисы отыгрывают общую стоимость через экономию на людях.
Практический паттерн экономии: статика и API живут на Hetzner внутри ЕС, а отдельные сервисы, которые больно и дорого строить самим, остаются на AWS. Такая связка собирается через зашифрованную mesh-сеть поверх интернета между провайдерами, но это отдельная большая тема, которой в этой серии посвящена своя статья.
Автоматизация через Terraform вместо CLI
Команды hcloud удобны для разведки, но реальная инфраструктура живёт в Terraform. Провайдер hetznercloud/hcloud устанавливается как обычно, токен передаётся через переменную окружения HCLOUD_TOKEN. Минимальный рабочий модуль выглядит примерно так:
resource "hcloud_server" "app" {
name = "app-01"
server_type = "cax11"
image = "ubuntu-24.04"
location = "fsn1"
ssh_keys = [hcloud_ssh_key.default.id]
network {
network_id = hcloud_network.backend.id
}
user_data = file("bootstrap.yml")
}
resource "hcloud_volume" "data" {
name = "app-data"
size = 100
server_id = hcloud_server.app.id
format = "ext4"
}
Terraform берёт на себя идемпотентность и состояние, hcloud остаётся инструментом отладки: быстро проверить hcloud server list, зайти на машину по SSH и посмотреть, что на самом деле вышло из-под apply. Такая комбинация закрывает и провижининг, и повседневную диагностику.
Эксплуатационные детали, о которых узнают только после переезда
Первое, что бьёт по привыкшим к AWS, это rescue-система. Если инстанс перестал грузиться, у Hetzner есть штатный rescue-режим: hcloud server enable-rescue app-01 --type linux64, потом hcloud server reset app-01 для жёсткой перезагрузки, и сервер поднимается с live-образа, где диск доступен для chroot-ремонта. Это прямой аналог того, что в AWS делают через детач EBS и пристёгивание к спасательному инстансу, только быстрее и проще, потому что rescue-режим встроен в панель и CLI.
Второе - firewall. У Hetzner есть cloud firewall на уровне проекта: hcloud firewall create и hcloud firewall apply-to-resource. Правила описываются декларативно, применяются к серверу без агента внутри гостевой ОС. Это удобнее security groups в мелочах: одно правило можно переиспользовать на многих серверах, а сами правила версионируются вместе с инфраструктурным кодом.
Третье - мониторинг. В AWS CloudWatch встроен и метрики сыплются сами. У Hetzner метрик инфраструктуры в привычном смысле нет: ставится node_exporter и Prometheus, или подключают внешний SaaS. Это не сложно, но это ещё одна система, которую нужно собрать и поддерживать. Именно поэтому для совсем маленькой команды managed-сервис AWS иногда оправдан: там уже всё воткнуто в дашборды и алерты.
Четвёртое - SLA. У Hetzner SLA скромнее, чем у AWS по managed услугам, и это объективно. Если требования к доступности у сервиса 99.99%, то нужно собирать мульти-ДЦ резервирование собственными руками: два сервера в fsn1 и nbg1 за балансировщиком, репликация базы между ними, синхронизация объектов в S3-совместимое хранилище Hetzner. Это выполнимо, но это снова про собственную эксплуатацию.
И последнее - ценообразование на объёмах. Цены Hetzner растут почти линейно: удвоил число серверов - удвоил счёт. У AWS на больших объёмах появляются скидки через Savings Plans и Reserved Instances, и реальная стоимость per instance падает. Поэтому корректное сравнение делают на объёмах, близких к реальным: то, что выгодно на трёх виртуалках, не обязательно выгодно на ста пятидесяти.
Короткий чек-лист миграции без сюрпризов
Переезд с AWS на Hetzner проходит гладко, если его разделить на этапы. Сначала переносится stateless-часть: приложения за балансировщиком, статические сайты, worker-пулы очередей. Затем отдельным этапом - данные: база поднимается репликой, идёт прогон в режиме replica, потом короткий promote с минимальным простоем. И только после наблюдения за новой площадкой неделю-две отключается старая часть. Параллельно на каждом этапе измеряются фактические счета: сколько реально выходит за серверы, трафик и бэкапы на новой площадке против старой. Этот фактический счёт и есть ответ на вопрос, сколько вы сэкономили, без домыслов по прайсам.
И ещё одна деталь, которую легко пропустить на старте: включите двухфакторную аутентификацию в панели Hetzner, ограничьте API-токены только нужными проектами и заведите отдельный проект под production. В Hetzner проект - это естественная граница изоляции ресурсов и токенов, и это бесплатный способ держать тестовую и боевую среду врозь без дополнительных аккаунтов.
В итоге выбор сводится к честному вопросу: вы готовы сами эксплуатировать базу, очередь и мониторинг - берите Hetzner и экономьте в разы; вам важнее заплатить деньгами, а не временем - оставайтесь на AWS и платите за себя спокойствие зрелой экосистемы. Ошибка тут одна - выбрать Hetzner ради экономии, а потом обнаружить, что все сэкономленные деньги ушли на зарплату инженера, который ночами поднимает self-hosted очередь. Счёт надо вести по полной стоимости владения, а не по строке в прайсе.