Timeweb Cloud — обзор облачной платформы IaaS/DBaaS/Kubernetes/S3

Timeweb Cloud — российская облачная платформа, в которой в одной панели управления собраны вычислительные ресурсы, управляемые базы данных, Kubernetes, балансировщики, объектное хранилище S3 и сервисы сетевой безопасности. Модель использования ориентирована на типичные DevOps-сценарии: быстро поднять инфраструктуру под проект, масштабировать по нагрузке, автоматизировать через API/CLI/Terraform и закрыть базовые риски за счёт резервного копирования, сетевой сегментации и защитных контуров.

Короткая карточка сервиса

Для кого рассчитан Timeweb Cloud

Платформа хорошо ложится на несколько типовых аудиторий:

• Разработка и продуктовые команды: быстрое развертывание окружений (dev/stage/prod), контроль расходов за счёт почасовых списаний, стандартные “кирпичики” инфраструктуры (серверы, сети, балансировка, S3, базы).

• DevOps/SRE: автоматизация через Public API, CLI и Terraform; воспроизводимые инфраструктурные изменения и уменьшение ручной рутины.

• SaaS и высоконагруженные веб-проекты: горизонтальное масштабирование на уровне серверов и балансировщиков, а также управляемые базы и объектное хранилище под статический контент/медиа/бэкапы.

• Проекты с требованиями к размещению в РФ и комплаенсу: в продуктовой линейке явно выделяются формулировки про соответствие 152-ФЗ для облачных сервисов и управляемых решений.

Панель управления: логика, сущности, сценарии

В Timeweb Cloud единая панель строится вокруг сущностей “сервис → ресурс → настройки → доступы/ключи → мониторинг/логи”. В ежедневной работе это выражается в том, что:

• серверы, базы, бакеты S3 и балансировщики создаются как отдельные ресурсы;

• сетевые сущности (VPC, публичные IP, правила Firewall, роутеры) подключаются к ресурсам и позволяют сегментировать доступ;

• часть операций (например, переустановка ОС, включение бэкапов/снапшотов) оформлена как действия на вкладках конкретного ресурса — без отдельной “мастер-панели”.

Ниже — ключевые практические блоки, которые чаще всего используются в связке.

Локации и зоны доступности

Облачная инфраструктура в Timeweb Cloud разбита на регионы и зоны доступности. В документации перечислены доступные зоны, включая варианты для Санкт-Петербурга, Москвы, Новосибирска, Казахстана (Алматы) и Польши (Варшава).

Для проектирования это важно по трём причинам:

1. Задержки и близость к аудитории — выбор региона влияет на latency.

2. Отказоустойчивость — при построении HA-архитектуры ресурсы разводятся по зонам.

3. Ограничения сервисов по регионам — часть функций/сервисов привязана к конкретным локациям (это отражается в документации отдельных продуктов).

Облачные серверы: основа IaaS-части

Облачные серверы — базовый строительный блок: на них разворачиваются приложения, прокси-слои, фоновые воркеры, self-hosted сервисы и т. п. В описании сервиса акцентируется производительность на CPU 3.3 ГГц, NVMe-диски и сетевой порт до 5 Гбит/с.

Создание сервера: пресеты и гибкая конфигурация

При создании сервера в панели доступен выбор готовых тарифных пресетов и ручная настройка параметров (CPU/RAM/диск) с привязкой к региону, образу ОС и способу доступа. В документации отдельно отмечены линейки пресетов (включая High CPU) и то, что при создании задаются имя, регион, образ, ключи авторизации и дополнительные параметры установки.

Сеть: приватная сегментация и публичный доступ

Для серверов типовой сетевой набор выглядит так:

• Приватная сеть (VPC) для связи между сервисами без выхода в интернет.

• Публичный IP для внешнего доступа (SSH/RDP, веб-сервисы, API).

• Firewall для ограничения входящих/исходящих потоков по портам/сетям.

• DDoS-защита (при необходимости) для публично доступных точек.

Стоимость публичного IP в документации указана как 180 ₽ в месяц; IP можно переносить между облачными сервисами внутри одного региона.

VPC и приватные сети: сегментация без “лишних” сервисов

VPC в Timeweb Cloud описывается как бесплатный сервис для создания приватных сетей и изолированной инфраструктуры; приватные сети используются для связи ресурсов между собой без публикации в интернет.

Что это даёт в архитектуре:

• База данных и внутренние сервисы остаются в приватном контуре.

• Публичный доступ есть только у edge-узлов (LB, reverse proxy, bastion).

• Миграции, бэкапы и сервис-to-service трафик идут по внутренним адресам.

Балансировщики нагрузки: отказоустойчивость и распределение трафика

Балансировщики используются как фронтовой слой между интернетом и группой серверов/сервисов. В расширенных настройках поддерживаются:

• алгоритмы Round Robin и Least Connections;

• sticky sessions через cookie;

• health checks, которые в фоне исключают “падающие” цели из балансировки и возвращают их после восстановления;

• настройки лимитов соединений и таймаутов (client/server/connect/http-request).

Практический сценарий: один балансировщик распределяет HTTP/HTTPS на пул приложений; параллельно health check следит за целями, а изменения можно вносить без длительных простоев (в документе отмечено кратковременное прерывание соединений при применении изменений).

Объектное хранилище S3: файлы, бэкапы, статика, медиаконтент

S3-хранилище в Timeweb Cloud — отдельный сервис, ориентированный на хранение и раздачу данных через S3-совместимый API. На странице сервиса отдельно отмечены:

• совместимость с S3-API;

• тройная репликация данных;

• SLA 99.98%;

• тарифные пресеты объёма от 10 ГБ до 20 000 ГБ.

Тарифные пресеты и трафик

На странице S3 приведены примеры пресетов:

Исходящий трафик указывается как 0 ₽ за первые 100 ГБ.
В документации по трафику зафиксировано: первые 100 ГБ исходящего трафика — бесплатно, далее списания идут по тарифу (в том числе отдельно выделен “холодный” трафик).

Подключение через AWS CLI: как выглядит на практике

Для интеграции с большинством инструментов достаточно S3-совместимости. В документации показан вариант настройки AWS CLI с endpoint s3.twcstorage.ru и стандартной логикой aws configure.

Типовой рабочий процесс:

1. создать бакет в панели;

2. выпустить ключи доступа/токены;

3. настроить клиент (AWS CLI/SDK/CI-систему);

4. подключить права доступа и (при необходимости) домен под раздачу статики.

Облачные базы данных (DBaaS): управляемые СУБД без ручной поддержки

DBaaS в Timeweb Cloud позиционируется как “база данных как сервис” для MySQL, PostgreSQL, Redis, MongoDB и ClickHouse — запуск и управление через панель без ручной установки и обслуживания.

Какие СУБД доступны и какие версии поддерживаются

В инструкции по созданию кластера баз данных перечислены конкретные версии:

• MySQL 8.0, 8.4

• PostgreSQL 14, 15, 16, 17, 18

• MongoDB 7.0, 8.0

• Redis 7, 8.1

• OpenSearch 2.19.1

• ClickHouse 23.10.1, 24.8.14, 25.1.6

• Kafka 3.5.1

• RabbitMQ 4.0

После выбора тип и версия не меняются.

Бэкапы для DBaaS

На странице DBaaS прямо указано: резервное копирование баз данных есть и оно бесплатное; периодичность настраивается в панели управления.

Что означает “managed” в реальной эксплуатации

На страницах управляемых сервисов (например, MongoDB) описано, что провайдер берёт на себя инфраструктурные задачи: развертывание кластера, обновления/патчи, резервное копирование, мониторинг и масштабирование.

Это меняет эксплуатационную модель: команда подключается к БД как к обычной СУБД, а инфраструктурная часть закрывается сервисом, при этом управление параметрами остаётся в панели и через инструменты автоматизации.

Резервное копирование для облачных серверов: бэкапы, снапшоты, аварийная копия

Для серверов Timeweb Cloud разделяет три механики: резервные копии (бэкапы), снапшоты (точки восстановления) и отдельную опцию аварийной копии.

Бэкапы дисков (платно)

• Стоимость бэкапа указана как 6 ₽ за 1 ГБ диска.

• Оплачивается хранение созданных копий; списания идут за каждый существующий бэкап.

• В панели доступны ручное создание, удаление, восстановление и настройка автоматических бэкапов.

Важные эксплуатационные нюансы из документации:

• восстановление возможно целиком или частично (через монтирование копии в read-only режиме);

• монтирование недоступно для Windows-серверов;

• скачивание бэкапов доступно только в локациях Санкт-Петербург и Москва, формат выгрузки — .qcow2.

Снапшот (бесплатно)

• снапшот создаётся/восстанавливается мгновенно;

• для одного сервера доступен один снапшот;

• срок хранения — 7 дней, затем удаляется автоматически;

• при активном снапшоте блокируется ряд операций (изменение дисков, бэкапы, образы, переустановка ОС и др.).

Аварийная копия (отдельная опция)

В документации выделена опция аварийной копии:

• фиксированная стоимость 200 ₽/мес и не зависит от размера диска;

• периодичность: создаётся не реже одного раза в 5 дней;

• восстановление выполняется через поддержку.

Образы серверов: миграции, клонирование, перенос к другому провайдеру

Образы в панели — это отдельная сущность, позволяющая:

• создать полный образ сервера в формате Qcow2 со всеми настройками и содержимым;

• использовать образ для создания нового сервера или переустановки существующего;

• скачать образ и развернуть копию у другого провайдера;

• загрузить собственный образ на аккаунт.

Тарификация хранения образов описана прямо: 4 ₽/ГБ в месяц, списания почасовые; также указан набор поддерживаемых форматов (iso, vmdk, vhd/vhdx, vdi, raw, img, qcow2) и максимальный размер файла 500 ГБ.

Переустановка ОС: контроль чистоты окружения

Переустановка ОС оформлена как действие на вкладке “Конфигурация” сервера:

• нажать “Переустановить”;

• выбрать вариант: чистая ОС, сборка из “Маркетплейса” или “Свой образ”;

• выбрать SSH-ключи и (при необходимости) указать cloud-init;

• подтвердить действие.

Документация отдельно фиксирует последствия: данные на диске удаляются, при этом резервные копии сохраняются, а настройки локальной сети не затрагиваются.

Cloud-init: автоматизация настройки при установке

Cloud-init используется для передачи user-data при запуске и автоматизации первичной настройки (ПО, пользователи, директории, права). В документе указаны:

• форматы #cloud-config и #!/bin/sh;

• выполнение от root, лог в /var/log/cloud-init-output.log;

• загрузка сценария при создании сервера или при переустановке;

• редактирование на вкладке “Конфигурация” через “Редактировать” в блоке Cloud-init.

Firewall: централизованные правила доступа

Firewall в Timeweb Cloud реализован в формате групп правил, которые можно применять к ресурсам в разных регионах. В документации по ограничениям Firewall перечислены лимиты, в том числе:

• до 15 групп правил на аккаунт;

• до 4 списков разрешенных/запрещенных IP-адресов;

• до 1000 строк в списках.

Для практического использования это означает, что правила удобно проектировать как набор профилей (например, “public-web”, “admin-ssh”, “db-internal”), а затем назначать на нужные серверы/сервисы.

DDoS-защита: подключение на L3/L4 и L7

В документации описан сервис DDoS-защиты для облачных серверов:

• защита доступна на уровнях L3/L4 и L7;

• подключение возможно через панель или через обращение в поддержку;

• услуга доступна для серверов в Санкт-Петербурге и Москве;

• для Windows после подключения требуется дополнительная настройка на стороне клиента.

Пошагово для существующего сервера это выглядит так:

1. открыть страницу сервера → вкладка “Сеть”;

2. в блоке “DDoS-защита” нажать “Включить”;

3. на следующем экране принять условия и нажать “Создать запрос” (уходит тикет в поддержку).

Managed Kubernetes: кластеры, автоскейлинг, автохиллинг, инструменты

Kubernetes в Timeweb Cloud позиционируется как управляемый сервис (KaaS). На странице сервиса указаны ключевые элементы:

• мониторинг кластеров в панели;

• инструменты автоматизации: Public API, CLI, Terraform для создания/удаления кластеров;

• инструменты работы через kube-API (kubectl, k9s, Lens/Freelens);

• автоскейлинг;

• автохиллинг: проверка состояния нод каждые 10 минут, попытка восстановления и автоматический запуск новой ноды при необходимости.

Версии Kubernetes и модель обновления

На странице сервиса перечислены поддерживаемые ветки Kubernetes: v1.33, v1.32, v1.31, v1.30, v1.29, v1.28, v1.27, v1.26. Также указано, что обновить версию Kubernetes внутри уже созданного кластера нельзя — создаётся новый кластер и выполняется перенос проекта.

Автоматизация: Public API, CLI twc, Terraform

CLI twc: управление ресурсами из терминала

twc описан как утилита командной строки для управления сервисами Timeweb Cloud. В инструкции “Установка и начало работы” зафиксировано:

• установка через pip install twc-cli;

• требование: Python 3.8+;

• первичная настройка через выпуск API-токена в панели (“Токены API”) и команду twc config;

• наличие встроенной справки twc --help, включая вложенные команды для управления серверами (twc server --help, twc server create --help).

Terraform: инфраструктура как код

В документации Terraform указан базовый подход: управление ресурсами Timeweb Cloud через конфигурации HCL. Отдельно перечислены сценарии управления сервисами через Terraform, включая создание кластера баз данных и управление Firewall.

Для хранения state через S3 (Remote State) приведена отдельная статья. В ней зафиксировано ограничение: загрузка состояний в S3 не поддерживается для Terraform версий 1.6.0 и выше (по причине изменений в структуре конфигурации).

Тарификация и контроль расходов: что важно понимать

Timeweb Cloud активно использует модель почасовых списаний (это отмечается в интерфейсной логике сервисов и отдельных страницах продуктов). Для практики контроля бюджета важны три правила:

1. Дробить инфраструктуру на независимые ресурсы: серверы отдельно, базы отдельно, S3 отдельно. Так легче отключать лишнее.

2. Использовать пресеты там, где это ускоряет выбор: S3-пресеты объёма, DB-пресеты, стандартные профили безопасности.

3. Автоматизировать жизненный цикл окружений: Terraform/CLI, чтобы dev-окружения жили по расписанию, а не “вечно”.

Ниже — примеры цен, которые прямо указаны в документации/страницах сервисов.

Примеры фиксированных цен из документации

Плюсы и минусы Timeweb Cloud

Плюсы

• Единая облачная платформа с ключевыми сервисами для типовой инфраструктуры: серверы, сети, балансировка, S3, DBaaS, Kubernetes.

• Прозрачный набор инструментов автоматизации: Public API, CLI twc, Terraform, cloud-init.

• Сильный блок по бэкапам и восстановлению: бэкапы, снапшоты, образы, скачивание в .qcow2, аварийная копия.

• Понятная сетево-безопасностная обвязка: VPC как базовая изоляция, Firewall-правила, DDoS-подключение, публичные IP с переносом внутри региона.

• DBaaS закрывает широкий спектр задач: от классических SQL/NoSQL до OpenSearch, Kafka и RabbitMQ с явно перечисленными версиями.

Минусы

• Обновление версии Kubernetes в рамках существующего кластера не предусмотрено: используется модель “новый кластер → перенос”.

• У части функций есть региональные ограничения (например, для отдельных операций с бэкапами/подключением защитных сервисов это явно отмечается в документации).

• Ограничения по сущностям Firewall (количество групп/списков) требуют аккуратной дисциплины проектирования правил в больших аккаунтах.

• Remote State в S3 не поддерживается для Terraform 1.6.0+ в текущем виде — это влияет на команды, которые уже стандартизировались на новых версиях Terraform.

Сравнение с конкурентами: Reg.cloud (REG.RU), Selectel, Beget Cloud, Yandex Cloud, VK Cloud

Ниже — практическое сравнение именно по сервисам, которые чаще всего определяют выбор облака: Kubernetes, объектное хранилище, управляемые базы, инструменты автоматизации и экосистема.

1) Timeweb Cloud и Reg.cloud (REG.RU)

• Kubernetes: у Reg.cloud есть Managed Kubernetes как отдельный сервис.

• S3: REG.RU публично описывает запуск объектного хранилища S3 и его связку с Kubernetes/облачными серверами.

• Сильная сторона Reg.cloud обычно проявляется, когда инфраструктура уже “завязана” на экосистему REG.RU (домены, корпоративные сервисы), и нужна единая точка биллинга/сопровождения.

Отличие Timeweb Cloud — более плотная “сшивка” IaaS+DBaaS+S3+балансировщиков+инструментов автоматизации в одной панели и документации в одном стиле (CLI/Terraform/cloud-init как связанный набор).

2) Timeweb Cloud и Selectel

• S3: у Selectel есть объектное хранилище с поддержкой Amazon S3 API (и Swift API).

• Kubernetes/экосистема хранения: у Selectel в документации много прикладных материалов по подключению хранилищ и эксплуатации рядом с Managed Kubernetes.

Selectel часто выбирают за “инженерную” зрелость сервисов и документации вокруг инфраструктурного слоя. Timeweb Cloud, в свою очередь, выделяется тем, что рядом с инфраструктурой даёт широкий DBaaS-набор (включая Kafka/RabbitMQ/OpenSearch с версиями) и простые механики резервного копирования/образов/снапшотов прямо в панели.

3) Timeweb Cloud и Beget Cloud

• S3: Beget предоставляет объектное хранилище S3 и публикует руководство по работе с ним.

• Позиционирование: Beget Cloud делает акцент на облачных решениях для бизнеса и разработчиков как экосистеме.

Beget часто рассматривают как “мягкий вход” в облако для пользователей хостинга/инфраструктуры Beget. Timeweb Cloud в сравнении выглядит более “платформенно” за счёт широкой DBaaS-матрицы и выраженной линии автоматизации через twc+Terraform+cloud-init.

4) Timeweb Cloud и Yandex Cloud

• Managed Kubernetes: у Yandex Cloud есть Managed Service for Kubernetes.

• Object Storage: Yandex Object Storage хранит данные с размещением копий в разных availability zones.

Yandex Cloud обычно выбирают, когда важны экосистемные сервисы “вокруг” (аналитика, IAM, интеграции, большие managed-продукты). Timeweb Cloud при этом закрывает типовой стек веб-приложений и DevOps-работы без усложнения, с понятными операционными механиками (бэкапы/снапшоты/образы/переустановка/сеть/Firewall) и широким набором DBaaS.

5) Timeweb Cloud и VK Cloud

VK Cloud как облачная экосистема (исторически — вокруг решений Mail.ru Cloud Solutions) широко использует объектное хранилище и Kubernetes-подходы, но при выборе обычно опираются на специфику сервисов и корпоративные интеграции. В практическом сравнении Timeweb Cloud проще оценивать по “базовому контуру” (IaaS+DBaaS+K8s+S3+сеть/безопасность) и скорости запуска типовых проектов.

Кому Timeweb Cloud подходит лучше всего

Наиболее сильные сценарии:

1. Веб-продукты и SaaS: LB + пул серверов + DBaaS + S3 под медиа/статику + бэкапы.

2. Микросервисы: Managed Kubernetes + Container Registry/образы + S3 + управляемые очереди/поиск (Kafka/RabbitMQ/OpenSearch) в DBaaS-линейке.

3. Среды разработки и тестирования: быстрый lifecycle через Terraform/CLI и воспроизводимые окружения через cloud-init.

4. Проекты, где критичны восстановление и контроль изменений: снапшот перед релизом, бэкап по расписанию, образы для миграции/архива.

Итог

Timeweb Cloud — практичная платформа для развертывания и сопровождения инфраструктуры “под ключ” в рамках одной панели: от облачных серверов и приватных сетей до управляемых баз данных, S3-хранилища и Managed Kubernetes. Ключевая ценность — в связке сервисов и эксплуатационных механик: резервное копирование (включая снапшоты и образы), сетевые инструменты (VPC, публичные IP, Firewall) и доступная автоматизация (Public API, twc, Terraform, cloud-init).