Как выбрать облачного провайдера в Казахстане: критерии и советы оценки характеристик для бизнеса

Облачный провайдер — это компания, которая предоставляет бизнесу:

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

Если вы не планируете закупать серверы самостоятельно, то для запуска сервисов вам потребуется провайдер облачных услуг. Но выбрать подходящего можно, только если вы сами можете сформулировать требования к инфраструктуре. Эта статья поможет их сформулировать.

Ниже разберем, по каким параметрам оценивать поставщиков IT-инфраструктуры, как читать SLA, как уберечь бизнес от юридических рисков в Казахстане и как правильно рассчитать совокупную стоимость облака.

Что такое облачный провайдер и какие услуги он предоставляет

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

Провайдер облачных сервисов разворачивает гибко настраиваемые пулы ресурсов — это отличает его от классического хостинга, где клиент получает тариф с фиксированными ресурсами и ограниченными возможностями настройки.

Вот что входит в облачную инфраструктуру.

Вычислительные ресурсы (Compute):

• Облачные серверы: масштабируемые виртуальные машины с гибкой настройкой количества процессорных ядер (CPU) и объема оперативной памяти (RAM).
• Выделенные серверы: физические серверы (Bare Metal) для ресурсоемких приложений без накладных расходов на гипервизор.
• Серверы с GPU: серверы с графическими ускорителями под задачи машинного обучения, рендеринга и обработки видеопотоков.

Сетевые сервисы (Network):

• Маршрутизация, виртуальные приватные сети (Private Network), публичные IP-адреса (Public IP).
• Балансировщики нагрузки (Load Balancer) для распределения входящих запросов между нодами.
• Защита от DDoS-атак на сетевом и транспортном (L3–L4), а у части провайдеров — и на прикладном (L7) уровне.

Системы хранения данных (Storage):

• Блочные хранилища (Block Storage) на базе быстрых SSD- и NVMe-накопителей для баз данных и системных дисков.
• Объектные S3-совместимые хранилища (Object Storage) для медиаконтента, статических файлов и неструктурированных архивов.
• Автоматизированное резервное копирование (Backup) с гибкими политиками хранения.

Управляемые платформенные сервисы (PaaS):

• Managed Kubernetes для оркестрации контейнерных приложений.
• Управляемые базы данных и брокеры сообщений (PostgreSQL, MySQL, Redis, Kafka), где администрирование, отказоустойчивость и установку обновлений берет на себя сервис-провайдер облака.
• Инструменты автоматизации: API и провайдеры для Terraform для реализации подхода «Инфраструктура как код» (IaC).

Юридическая чистота, регуляторика и локализация

Компании, работающей на локальном рынке, нужно соответствовать региональному законодательству, а в идеале — заранее продумать документооборот с провайдером и отражение расходов в учете.

Требования к локализации персональных данных в Казахстане

Если ваш бизнес обрабатывает персональные данные граждан РК, ключевое требование — соблюдение Закона Республики Казахстан № 94-V «О персональных данных и их защите».

Согласно пункту 2 статьи 12 закона, хранение персональных данных должно осуществляться в базе, находящейся на территории Республики Казахстан.

За нарушение предусмотрены административные штрафы по статье 79 КоАП РК. Их размер рассчитывается в МРП и зависит от вида нарушения и статуса нарушителя.

Что проверять: физический адрес ЦОД, закрепленное в договоре место хранения данных и сертификаты площадки, подтверждающие, что инфраструктура находится в пределах Республики Казахстан.

Финансовый комплаенс и взаиморасчеты

Работа с зарубежными провайдерами (AWS, GCP, Hetzner) создает для локального юридического лица ряд сложностей. Как правило, это:

• Валютные риски и конвертация: счет растет при колебаниях курса.
• Налоговые последствия: необходимость уплатить НДС за нерезидента, а в ряде случаев — удержать корпоративный подоходный налог у источника выплаты. Точные обязательства зависят от вида услуг и соглашения об избежании двойного налогообложения, поэтому их стоит уточнить у налогового консультанта.
• Первичная документация: глобальные провайдеры не выставляют электронные счета-фактуры (ЭСФ) и акты выполненных работ (АВР), что затрудняет подтверждение расходов в налоговом учете.

Чтобы избежать этих рисков, стоит выбирать провайдера с местным юрлицом, который принимает оплату в тенге и предоставляет закрывающие документы.

Надежность, доступность и SLA

От стабильности платформы напрямую зависит бесперебойная работа клиентских сервисов. Доступность на уровне 99% сегодня предлагает практически любой провайдер, и может показаться, что этого достаточно. Однако разница между 99% и 99,98% велика, особенно в масштабе месяца и года.

Уровень дата-центра (Tier)

Физическая безопасность и непрерывность электропитания зависят от площадки, на которой размещено оборудование. Самая распространенная система классификации дата-центров — методология Uptime Institute:

• Tier II: резервирование критических компонентов (N+1). Для плановых работ может потребоваться остановка оборудования.
• Tier III: резервирование компонентов (N+1) и несколько путей подачи питания и охлаждения. Любой компонент можно обслужить или заменить без отключения стоек. В отраслевых материалах для Tier III часто приводят ориентир 99,982% доступности (около 1,6 часа простоя в год), хотя сам Uptime Institute процентов в стандарте не закрепляет.
• Tier IV: полная отказоустойчивость с дублированием (2N) и изоляцией резервных путей. Встречается реже, в основном там, где цена простоя исключительно высока.

Для критичных бизнес-приложений стандартом де-факто является уровень Tier III.

Гарантированный Uptime и SLA

Соглашение об уровне обслуживания (SLA) фиксирует гарантии доступности сервисов и финансовую ответственность провайдера. Вот что нужно учесть, помимо базовой метрики доступности:

1. Зоны доступности (Availability Zone). Зрелый провайдер предлагает несколько изолированных друг от друга зон доступности внутри региона, связанных высокоскоростными каналами с минимальной задержкой. Это позволяет строить отказоустойчивые кластеры, которые продолжат работу даже при отказе целой площадки.
2. Финансовая ответственность. Изучите раздел компенсаций: по нему вы поймете, будут ли они достаточными, если провайдер превысит порог недоступности.
3. Методика расчета. Уточните, как провайдер измеряет доступность, входят ли в расчет плановые работы и какие случаи исключены из гарантий.

Катастрофоустойчивость и резервное копирование данных

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

Технические возможности и стек технологий

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

Главное — не оценивать виртуальные машины только по количеству ядер и гигабайтам памяти: 4 vCPU у одного провайдера могут работать заметно медленнее, чем те же 4 vCPU у другого.

Оценивать стек нужно комплексно: от процессоров до инструментов автоматизации. Вот на что нужно смотреть.

Вычислительные мощности: архитектура, частота и скрытый оверселлинг

Производительность виртуального сервера зависит не от абстрактных «ядер», а от того, как именно гипервизор передает вам ресурсы физического процессора.

Архитектура и поколения процессоров. Обращайте внимание на модель процессора. Современные линейки Intel Xeon Scalable и AMD EPYC обеспечивают высокий показатель IPC (инструкций за такт). Старым поколениям CPU нужно больше ядер для того же объема вычислений, что напрямую увеличивает ваши затраты.

Переподписка (Overcommit) и проблема «шумных соседей». На тарифах с переподпиской одно физическое ядро делят несколько клиентов в расчете на то, что они не будут нагружать его одновременно. Если соседний виртуальный сервер на том же хосте запускает тяжелый расчет, ваша система теряет процессорное время (эффект CPU Steal).

Разделение на профили нагрузок. Зрелый провайдер четко разделяет виртуальные машины на типы:

• Shared (базовые): ядра с допустимой переподпиской — подходят для тестирования, микросервисов и фоновых задач.
• Dedicated vCPU (выделенные): ядро (или поток) физического процессора закреплено за вашей ВМ — критично для высоконагруженных API, транзакционных баз данных и компиляции.
• High-Frequency (высокочастотные): процессоры с базовой частотой от 3,4–3,7 ГГц — обязательное требование для приложений, чувствительных к однопоточной производительности (например, «1С:Предприятие»).

Наличие физических серверов (Dedicated Servers / Bare Metal). Для задач, где виртуализация создает неприемлемые накладные расходы (тяжелые кластеры СУБД, финтех-процессинг), стоит искать провайдера, который предоставляет физические серверы без гипервизора, но с управлением через общую панель.

Дисковая подсистема: почему сетевым дискам нужны гарантированные IOPS

Медленный диск способен полностью парализовать быстрый процессор: сервер будет простаивать в ожидании завершения операций ввода-вывода (iowait).

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

• Локальные накопители. Физически установлены в тот же сервер, где работает ВМ. Обеспечивают минимальную задержку (latency < 0,5 мс) и максимальные IOPS, но несут риск: при выходе из строя физической ноды диск становится недоступен вместе с сервером.
• Сетевые блочные хранилища (Block Storage). Данные передаются по высокоскоростной сети хранения. Это дает гибкость: диск можно отключить и подключить к другой машине, расширить его объем без остановки ОС или сделать мгновенный снапшот.

При выборе сетевых дисков тип накопителя (SSD или NVMe) сам по себе ничего не гарантирует, если провайдер не фиксирует производительность. Смотрите на:

1. Гарантию IOPS. Провайдер должен четко указывать, сколько операций ввода-вывода выделяется на гигабайт объема или тарифный план, чтобы дисковая система не деградировала в часы пик.
2. Время задержки (Latency). Для NVMe-дисков промышленного класса задержка не должна превышать 1–2 мс при смешанной нагрузке.

Отдельно проверьте наличие объектного хранилища (Object Storage). Хранить медиафайлы, резервные копии и логи на блочных дисках экономически нецелесообразно. Для этого в платформе должен быть доступен S3-совместимый сервис с низкой ценой за терабайт и практически неограниченным масштабированием.

Сетевая инфраструктура: связность, изоляция и маршрутизация

Сетевой контур должен справляться с входящим трафиком, иначе он станет узким местом, которое не позволит серверу работать в полную мощность. Оценивайте следующие параметры:

• Пропускная способность и задержки. Учитывайте скорость внешнего порта (от 1 Гбит/с) и связность ЦОД с локальными операторами связи. Прямое подключение к национальным точкам обмена трафиком снижает риск того, что пакеты внутри региона пойдут транзитом через другие страны с высоким пингом.
• Приватные сети (Private Network). Трафик между фронтендом, бэкендом и базами данных не должен идти через публичный интернет. Провайдер должен предоставлять возможность создавать изолированные приватные сети L2/L3 без тарификации внутреннего трафика.
• Балансировка нагрузки (Load Balancer). Нативный сервис распределения входящего трафика позволяет горизонтально масштабировать веб-серверы: балансировщик сам отслеживает состояние нод (health checks) и исключает упавшие инстансы из пула.
• Безопасность периметра. Защита от DDoS-атак на уровнях L3/L4 (сетевой флуд) и L7 (атаки на веб-приложения) должна работать на уровне инфраструктуры провайдера и отсекать вредоносный трафик до того, как он забьет полосу пропускания сервера.

Автоматизация: от ручных кликов к Infrastructure as Code (IaC)

Если вы планируете активно развивать сервисы и расширять команду, со временем ручное управление серверами начнет приводить к лишним расходам и разнобою в конфигурациях.

Чтобы избежать таких проблем, проверьте наличие:

• Декларативного управления через Terraform. Официально поддерживаемый провайдер для Terraform позволяет описывать всю инфраструктуру (серверы, диски, правила файрвола, приватные подсети) в виде текстовых конфигурационных файлов. Это снижает влияние человеческого фактора: развертывание тестового или боевого контура занимает минуты и полностью воспроизводимо.
• Полнофункционального REST API. Любое действие, доступное в графическом интерфейсе (перезагрузка, заказ IP, изменение размера диска, создание снапшота), должно быть выполнимо через API для интеграции в корпоративные CI/CD-пайплайны (GitLab CI, GitHub Actions, Jenkins).
• Managed Kubernetes. Самостоятельное развертывание и обслуживание кластера k8s отнимает десятки часов работы высокооплачиваемых инженеров. Сервис Managed Kubernetes перекладывает поддержку управляющих (master) нод, их резервирование и обновление на провайдера, а команда разработки может сосредоточиться на деплое контейнеров (например, собранных в Docker).

Финансы и TCO: как считать реальную стоимость облака

Сравнение прайс-листов «в лоб» часто вводит в заблуждение: выгоду от дешевого процессора может перечеркнуть дорогая тарификация сопутствующих услуг.

Скрытые статьи расходов: на что обращать внимание

Тарификация исходящего трафика. Некоторые провайдеры предлагают дешевые серверы, но выставляют счет за каждый переданный гигабайт. Такая модель подойдет внутренним сервисам с небольшим исходящим трафиком. Остальным стоит выбирать поставщиков с включенным пакетом трафика или безлимитными каналами на фиксированной скорости.

Платные публичные IP и балансировщики. Посчитайте, сколько стоит аренда внешних IPv4-адресов и инстансов Load Balancer.

Запросы и операции ввода-вывода. Проверьте, тарифицируются ли запросы к S3 Object Storage и операции ввода-вывода (IOPS) на блочных дисках.

Снапшоты и резервные копии. Уточните, как рассчитывается стоимость гигабайта архивного хранилища.

Модели оплаты: Pay-as-you-go и коммиты

Pay-as-you-go (почасовая/поминутная оплата) подходит для тестирования, сезонных всплесков посещаемости и временных стендов разработки. Деньги списываются только за время работы ноды. Важно учитывать, что платить придется за сам факт ее работы, даже если нода не загружена.

Резервирование мощностей (Reserved/Monthly). Аренда пула ресурсов на 6, 12 или 36 месяцев со скидкой от базового тарифа: чем дольше срок, тем обычно выше скидка. Подходит для стабильных продуктивных нагрузок.

Как выбрать инфраструктуру под задачи бизнеса

Универсальной конфигурации не существует: то, что идеально подходит для статического сайта, приведет к деградации тяжелой ERP-системы или перерасходу бюджета в ML-проекте. Выбор архитектуры всегда отталкивается от профиля нагрузки и критичности задержек.

Рассмотрим самые распространенные типы проектов, их нагрузки и оптимальную архитектуру.

Интернет-магазины и веб-сервисы (E-commerce)

В электронной коммерции нагрузка распределяется неравномерно: в период распродаж или маркетинговых кампаний трафик возрастает в разы, а в ночные часы серверы простаивают. Попытка держать постоянный запас мощностей под пики приводит к неоправданным расходам, а нехватка ресурсов — к потере заказов из-за зависшей корзины.

Для таких сценариев оптимальна горизонтально масштабируемая архитектура с балансировщиком нагрузки. Он распределяет входящие запросы между несколькими экземплярами приложения, поэтому в часы пиковых нагрузок можно добавлять новые виртуальные машины, а при спаде — отключать их. Чтобы не перегружать дисковую подсистему веб-серверов десятками тысяч изображений товаров, медиаконтент выносится в S3-совместимое объектное хранилище, а сессии пользователей и кэш — в быстрые in-memory базы вроде Redis.

Высоконагруженные сервисы и финтех (Highload)

Платежные шлюзы, биллинговые платформы и процессинговые системы требуют предсказуемого времени отклика и полного контроля над аппаратной частью. В виртуальной среде накладные расходы гипервизора и конкуренция за ресурсы хоста могут приводить к микрозадержкам, которые недопустимы при обработке финансовых транзакций.

Здесь стандартом остается гибридный контур. Тяжелое ядро системы и транзакционные СУБД разворачиваются на выделенных физических серверах (Dedicated Servers), где 100% ресурсов процессора и дисков принадлежат одному клиенту. Менее критичные интерфейсные части выносятся в облако. Вся система объединяется в изолированную приватную сеть без прямого выхода баз данных в интернет, а периметр закрывается межсетевыми экранами и защитой от DDoS-атак. Если система обрабатывает данные платежных карт, площадка провайдера должна быть сертифицирована по PCI DSS.

Корпоративные базы данных и системы 1С:Предприятие

Реляционные базы данных (PostgreSQL, MS SQL, Oracle) и платформы автоматизации учета крайне чувствительны к двум параметрам: производительности одного процессорного потока и задержкам на дисковых операциях. Если многопоточный веб-сервер можно масштабировать добавлением ядер, то проведение бухгалтерской проводки или тяжелый SQL-запрос упираются в тактовую частоту конкретного ядра.

Для стабильной работы таких систем нужны виртуальные машины с профилем High-Frequency: CPU с базовой частотой от 3,4 ГГц и без переподписки. Дисковая система строится на NVMe-накопителях с фиксированным пулом IOPS, который исключает просадки при массовой записи. Обязательный компонент архитектуры — автоматизированный бэкап: резервные копии баз данных снимаются по расписанию и передаются в географически удаленное хранилище без остановки работы пользователей.

AI, машинное обучение и аналитика больших данных

Обучение нейросетей, запуск больших языковых моделей (LLM) и задачи компьютерного зрения требуют массово-параллельных вычислений, которые классические центральные процессоры выполняют слишком медленно из-за архитектурных ограничений.

Для таких нагрузок используют серверы с графическими ускорителями — например, NVIDIA A100, RTX PRO 6000 или RTX A5000. Помимо самих видеокарт, критическую роль играет связность узлов: для распределенного обучения моделей нужны высокоскоростные шины передачи данных и широкие сетевые каналы между серверами, иначе обмен градиентами между нодами станет узким местом всего вычислительного процесса. Обучающие датасеты и веса моделей при этом хранятся в масштабируемых объектных хранилищах, подключенных к вычислительному кластеру.

Как проверить провайдера перед миграцией

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

Бенчмарк производительности дисков (fio). Проверьте реальные показатели скорости и latency под смешанной нагрузкой случайного чтения/записи (random read/write):

Обратите внимание на параметр latency (задержка): для качественных NVMe он не должен превышать 1–2 мс даже под такой нагрузкой.

Стресс-тест процессора (sysbench). Запустите длительный тест и сравните количество событий в секунду (events per second) между провайдерами и между повторными прогонами:

Если результат заметно плавает от прогона к прогону, это признак переподписки или троттлинга.

Анализ сетевых задержек и маршрутов (iperf3, mtr). Замерьте реальную пропускную способность канала и стабильность маршрутов от ваших ключевых офисов или целевой аудитории:

Для iperf3 на тестовом сервере должен быть запущен iperf3 -s. Убедитесь в отсутствии packet loss (потери пакетов) и аномальных скачков джиттера (jitter).

Проверка SLA и документации. Перед подписанием договора сверьте, что уровень доступности, порядок компенсаций и место хранения данных закреплены в документах, а не только указаны на сайте. Оцените и техническую документацию: по ней должно быть понятно, как работать с API, Terraform и основными сервисами.

Краш-тест службы поддержки. Создайте технический тикет средней сложности в нерабочее время (например, в субботу вечером):

• Оцените реальное время первого содержательного ответа инженера (не бота).
• Обратите внимание на квалификацию специалистов: отвечают ли вам шаблонными отписками или действительно разбираются в проблеме на уровне системного администрирования.

Что предлагает облачный провайдер Servercore

Servercore — международный провайдер IT-инфраструктуры с локальным присутствием в Казахстане, Узбекистане и Кении.

Инфраструктура Servercore:

Размещена в Казахстане. Инфраструктура в Алматы работает в дата-центре с сертификатами Tier III Design и Tier III Facility, поэтому персональные данные граждан Республики Казахстан хранятся в стране в соответствии с Законом № 94-V. Оплата принимается в тенге, договор заключается с казахстанским юрлицом.

Поддерживает гибридный подход. Облачные серверы (Cloud Servers) и физические выделенные серверы (Dedicated Servers) можно объединить в единую изолированную приватную сеть (Private Network) через глобальный роутер без маршрутизации через публичный интернет.

Предоставляет быстрые диски и хранилища. Локальные NVMe-диски облачных серверов дают до 100 000 IOPS, а сетевые диски хранят данные в трех копиях на разных серверах. Для неструктурированных данных доступно S3-совместимое объектное хранилище (Object Storage).

Дает возможность арендовать GPU под AI/ML. Доступны облачные и выделенные серверы с видеокартами NVIDIA для обучения и инференса моделей, генеративных нейросетей и работы с LLM. Линейка карт регулярно пополняется, а если нужной модели нет в готовых конфигурациях, сервер можно собрать под заказ.

Предоставляет инструменты автоматизации и DevOps. На платформе есть собственный провайдер для Terraform, API с подробной документацией и Managed Kubernetes для быстрой доставки кода в production.

Uptime облачных серверов — 99,98% по SLA, выделенных — 100%, оба уровня с финансовой гарантией. Техническая поддержка работает 24/7 и входит в стоимость.

Чек-лист выбора облачного провайдера

Используйте эту сводную таблицу при аудите коммерческих предложений и оценке кандидатов.

FAQ

Как сравнить облачных провайдеров?

Сначала отсейте кандидатов по блокирующим критериям: локализация данных, местное юрлицо и закрывающие документы. Затем сравните SLA, уровень дата-центра и полную стоимость владения с учетом трафика, IP-адресов и хранилищ. Финальное решение принимайте после тестов производительности, сети и поддержки на пробном стенде.

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

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

Облачный провайдер предоставляет изолированную виртуальную или физическую инфраструктуру с полным административным доступом, масштабированием ресурсов в несколько кликов и возможностью строить сложные сетевые топологии.

Что важнее при выборе: низкая цена за ресурсы или высокий SLA?

Все зависит от цены простоя вашего сервиса. Если час недоступности интернет-магазина или платежного шлюза стоит компании сотни тысяч тенге упущенной выручки и репутационного ущерба, экономия на дешевом хостинге без SLA и гарантий обернется убытками. Для production-систем высокий SLA (от 99,95%) и финансовая ответственность поставщика важнее минимальной цены.

Как понять, сколько ресурсов нужно проекту на старте?

Оцените требования вашего стека технологий: минимальные требования ОС, движка приложения, СУБД и кэширующих серверов (Redis/Memcached).

Главное преимущество облака — не нужно покупать мощности «на вырост». Начните с минимально достаточной конфигурации (например, 2–4 vCPU, 8 ГБ RAM), проведите нагрузочное тестирование с помощью утилит k6 или Apache JMeter и при необходимости масштабируйте вычислительные мощности в панели управления за пару кликов.

Какие регуляторные требования критичны при размещении баз данных в Казахстане?

Ключевое требование — исполнение Закона РК № 94-V «О персональных данных и их защите». Базы, содержащие персональные данные граждан Казахстана, должны храниться на территории Республики Казахстан. Также важно, чтобы у провайдера были сертификаты безопасности и чтобы он предоставлял закрывающие документы по местным стандартам бухгалтерского учета.