IONOS
IONOS
IONOS — крупный немецкий хостинг и облачный провайдер. В заметку он попал по отзыву от 2 июня 2026 года: «говорят, что IONOS в РФ еще работает».
Этот отзыв не является рекомендацией. Текущая категория — «Рискованные»: главный вопрос для пользователя из России — не только характеристики VPS, но и возможность легально и стабильно завести аккаунт, оплатить услугу и не попасть под закрытие из-за резидентства.
Статусы TXL, Managed Kubernetes, DCD и ограничения GPU capacity выборочно сверены 27 сентября 2026 года с официальной панелью и журналом. Прежняя проверка S3 и поддержки — 10 сентября, DBaaS-дедлайнов в этой карточке — 7 сентября. Тарифы и юридические условия заново не проверялись; старые цены не являются новым замером.
1 октября 2026 года отдельно сверено отключение PostgreSQL API v1: официальная карточка подтверждает Completed 28 сентября в 16:00 UTC / 19:00 МСК. Ниже обновлены статус и действия после отключения; остальные исторические проверки этим дополнением не переаттестованы.
Что есть по тарифам
На немецкой странице VPS на момент проверки были указаны Linux VPS от 2 евро в месяц на первые 6 месяцев. В младшем тарифе Linux S+ заявлялись:
- 2 vCPU;
- 2 ГБ RAM;
- 80 ГБ NVMe;
- установка 10 евро;
- неограниченный трафик до 1 Гбит/с;
- IPv6-сеть включена;
- 1 IPv4 включен, дополнительные IPv4 — 5 евро в месяц;
- Plesk Obsidian — 5 евро в месяц.
Также заявлены Windows Server, KVM-консоль, Cloud Panel, root-доступ и круглосуточная поддержка. Цены и промопериоды перед покупкой нужно перепроверять.
Инциденты и операционные риски
В 2026 году официальная status-панель IONOS Cloud фиксировала:
8–9 сентября — сетевое событие DE/TXL с поэтапным восстановлением Compute, Storage и DBaaS; финальное закрытие — 21 сентября в 07:24 UTC;
24 августа — 3 сентября, по опубликованному RCA: деградацию S3
eu-central-1; временная мера применена, постоянное исправление QoS ещё готовится;периодическую недоступность control plane Managed Kubernetes;
ошибки provisioning, Cloud API и Data Center Designer;
ограничения свободной емкости GPU с 18 июня; 21 сентября в 08:31 UTC провайдер объявил расширение ёмкости и закрытие ограничения;
невозможность создать некоторые MongoDB-кластеры во Frankfurt East;
временную остановку автоматического обслуживания Kubernetes из-за высокой нагрузки;
21–23 августа — невозможность резервировать и управлять IP blocks через DCD и API;
два ограничения телефонной поддержки Cloud Support: 4–8 сентября и отдельно 8 сентября; оба закрыты.
Важно различать control plane и workloads: уже запущенные приложения могли работать, когда API управления кластером или создание новых ресурсов были недоступны. Ограничение Cloud Support также не означает остановку VPS или облачных баз.
TXL: восстановление сервисов не равно закрытию записи
Событие TXL 8–9 сентября переведено в Resolved 21 сентября в 07:24 UTC. Сервисы были объявлены восстановленными ещё 9 сентября; Monitoring на проверку 10 сентября сохранён в истории, но больше не является текущим статусом. Наблюдение до закрытия нельзя считать непрерывным простоем. Провайдер связывал проблему с заменой маршрутизатора.
Отдельный сетевой инцидент TXL / provisioning 24 сентября закрыт в 14:33 UTC. Managed Kubernetes DE/FRA получил Resolved 24 сентября в 05:43 UTC, после mitigation около 23 сентября 19:00 UTC; DCD — 26 сентября в 11:11 UTC, после объявления доступности интерфейса в 02:57 UTC. Источники, этапы и границы воздействия — в журнале IONOS. События не объединяются в одну аварию; отказ управления не означает остановку всех приложений.
S3 Object Storage: опубликован RCA
3 сентября в 13:39 UTC IONOS отметил восстановление нормального времени ответа S3 в eu-central-1. Опубликованный 8 сентября RCA уточнил более раннее начало воздействия и причину в QoS. Точный таймлайн, различие между периодом воздействия и окном сообщений, временное отключение rate limiting и незавершённое постоянное исправление разобраны в журнале инцидентов.
Закрытие устраняет актуальное предупреждение о продолжающемся сбое, но не отменяет необходимость проверять S3 data plane отдельно от управления buckets и keys в DCD.
Для рабочей нагрузки полезны:
- synthetic
PUT/HEAD/GET/DELETE; - измерение p95/p99 latency;
- контроль timeout и HTTP 5xx;
- ограниченные retries с exponential backoff;
- checksum после чтения тестового объекта;
- мониторинг длительности backup и media jobs;
- независимая копия критичных данных у другого провайдера.
DBaaS: миграции августа и завершённое отключение PostgreSQL API v1
Августовские миграции PostgreSQL/MariaDB и отключение In-Memory DB v1 отмечены завершёнными в status-панели. Это не подтверждает, что клиентские API, Terraform и SDK автоматически обновились.
Подробно:
PostgreSQL
Инфраструктурная миграция v1 → v2 завершена. Отключение PostgreSQL API v1 получило Completed 28 сентября в 16:00 UTC / 19:00 МСК, после начала работ в 14:00 UTC. Это уже завершённое отключение, а не предстоящий дедлайн. Два часа между сообщениями — окно работ, не измеренный простой баз.
После отключения:
- management API требует TOKEN authentication вместо BASIC;
- интеграции должны использовать региональный v2 endpoint;
- кластеры на HDD/SSD Standard переводились на SSD Premium с соответствующей тарификацией;
- optional Observability оплачивается отдельно;
- провайдер заявлял отсутствие простоя уже перенесённых баз при отключении management API; собственных SQL-измерений здесь нет.
TOKEN auth Cloud API не заменяет SQL-пользователя и пароль приложения. Проверьте SQL-подключение отдельно от Terraform/API/SDK, найдите оставшиеся обращения к v1 и убедитесь, что IaC-план не пересоздаёт БД. Возврат к отключённому API v1 не является откатом. Completed у провайдера не подтверждает исправность клиентского CI/CD.
MariaDB
- с 17 августа нельзя создавать новые v1 clusters;
- окно автоматической миграции existing clusters 24–28 августа завершено;
- 31 августа завершено отключение MariaDB API v1;
- API scripts, Terraform и SDK должны использовать v2.
Сам database cluster может быть мигрирован автоматически, но это не обновляет клиентский IaC-код.
In-Memory DB / Valkey
Августовский дедлайн уже прошёл:
- новые v1 instances запрещены с 4 августа;
- отключение v1 было назначено на 31 августа и отмечено завершённым;
- automatic migration не предусматривалась;
- клиент должен использовать v2 instance с перенесёнными необходимыми данными и новым endpoint;
- v2 использует Valkey;
- с 1 сентября действуют новые цены snapshot-возможностей.
Если In-Memory DB используется для sessions/queues/locks, это production-critical зависимость, а не обычный disposable cache. После EOL нельзя рассчитывать на rollback к работающему v1.
Что проверить пользователю IONOS Cloud после 28 сентября
[ ] PostgreSQL regional API v2; зависимостей от отключённого v1 нет
[ ] PostgreSQL TOKEN auth для management API
[ ] PostgreSQL storage class / new cost
[ ] MariaDB API v2
[ ] MariaDB Terraform/SDK v2
[ ] In-Memory DB v1 отсутствует в зависимостях приложения
[ ] Valkey endpoint tested
[ ] DB backups checked
[ ] IaC plan tested без непреднамеренного пересоздания БД
[ ] invoice forecast reviewed
[ ] актуальный канал поддержки проверен
Плюсы
- крупный европейский провайдер, не мелкий реселлер;
- есть VPS, облачные серверы и managed-сервисы;
- есть Linux и Windows;
- есть публичная информация по дата-центрам;
- инфраструктура IONOS Cloud размещается в США и Европе;
- есть открытая status-панель с техническими обновлениями;
- status page заранее публикует часть migration/deprecation deadlines.
Минусы и риски
- в опубликованной политике IONOS указаны отказ от новых клиентских контрактов из России и прекращение существующих отношений с российскими клиентами;
- даже если сайт открывается и заказ технически проходит, аккаунт может попасть под проверку или закрытие позже;
- оплата российскими картами, адрес биллинга, телефон и документы могут стать проблемой;
- цены в евро, возможны НДС и комиссии;
- дополнительный IPv4 и панели управления могут быть платными;
- в облаке встречались сбои управляющего слоя и ограничения свободной емкости;
- в августе–сентябре зафиксированы как сбой Object Storage management, так и длительная деградация S3; опубликованный RCA не означает завершения постоянного QoS-исправления;
- сетевое событие TXL 8–9 сентября затронуло несколько инфраструктурных компонентов и закрыто 21 сентября; отдельный TXL-инцидент 24 сентября также закрыт, но остаётся в истории повторяемости;
- во время дефицита GPU остановленный сервер мог не запуститься повторно; ограничение закрыто 21 сентября, но это не гарантия свободной ёмкости любой конфигурации в будущем;
- managed products могут иметь обязательные API migrations с жестким deadline;
- автоматическая infrastructure migration не гарантирует, что Terraform/SDK/API automation обновится автоматически;
- PostgreSQL migration может изменить storage class и стоимость;
- In-Memory DB v1 требовал manual migration до отключения;
- недавние ограничения Cloud Support показывают риск получения помощи, хотя оба события уже закрыты.
Что проверить
Аккаунт и санкционные риски
- открывается ли сайт и личный кабинет напрямую из РФ;
- допускается ли новый договор с фактическим резидентством клиента;
- какие страны доступны в биллинге;
- проходит ли оплата разрешённым способом;
- какие KYC-документы потребуются;
- каковы условия прекращения договора и выгрузки данных.
Инфраструктура
- какой дата-центр реально выдается;
- какой пинг и трассировка из РФ;
- можно ли быстро выгрузить бэкап или образ;
- достаточно ли свободной емкости в резервной локации;
- как приложение переживает недоступность Cloud API или Kubernetes control plane;
- как меняются S3 latency и error rate в рабочее время;
- есть ли независимый backup Object Storage и проверенный restore.
DBaaS
- нет ли обращений к v1 API;
- нет ли hardcoded BASIC auth для management API;
- Terraform provider/modules актуальны;
- In-Memory DB переведен на v2;
- стоимость storage/snapshots после migration приемлема;
- restore процедуры проверены.
Итог
Технически IONOS выглядит сильнее многих небольших VPS-провайдеров: это крупная компания, развитая инфраструктура и понятные дата-центры. Но для пользователя из РФ главный риск — аккаунт, оплата и санкционная политика.
Для IONOS Cloud дополнительно нужно учитывать:
- доступность и производительность data plane;
- доступность управляющего слоя;
- свободную емкость;
- migration/deprecation lifecycle managed services;
- возможность роста стоимости после infrastructure upgrade;
- доступность поддержки при восстановлении.
Категория остаётся «Рискованные». Восстановление S3 и поддержки не отменяет оснований, связанных с аккаунтом, оплатой и санкционной политикой; технические события и выполнение корректирующих мер оцениваются отдельно.
Для важных проектов обязательны независимые бэкапы, IaC export и готовый план переезда.