Cloud9 Cloud 9 Ltd. продаёт размещённые мощности, которые по-прежнему зависят от стоек, транзита и окон ремонта

Кратко

• Собственный публичный сайт Cloud9 представляет её как грузинского хостинг-, облачного и дата-центрального провайдера с услугами, которые включаютколокацию и стойки,VPS,VDS,выделенные серверы,общий хостинг,почту Zimbra, домены, SSL и услуги клиентского портала.
• Сетевые доказательства содержательны.RIPEstat показывает AS57814как анонсированную для держателя Cloud9 Cloud 9 Ltd. на 12 июля 2026 года, тогда какAS49297связана с тем же держателем, но не анонсируется. Подсчёты RIPE RIS для AS57814 показывают28 анонсируемых префиксов IPv4, 13 транзитных префиксов IPv4, три анонсируемых префикса IPv6 и два транзитных префикса IPv6.
• Физический центр тяжести — Тбилиси.Страница дата-центра Cloud9говорит, что большинство услуг предоставляется из собственного дата-центра Cloud9 в Тбилиси, аPeeringDB указываетобъект Cloud9 Dinamo Arena по адресу проспект А. Церетели, 2, Тбилиси, с одной точкой обмена трафиком и публичными контактами поддержки.
• Риск покупателя не в том, что Cloud9 невидима. Риск в том, что публичные доказательства до сих пор не подтверждают клиентскую ёмкость аварийного переключения, наличие запасного оборудования, скорость восстановления из резервных копий, эскалацию поддержки или права на выход. Клиентам следует проверить эти условия, прежде чем считать мощности Cloud9 заменой собственного плана непрерывности.

Компания достаточно заметна для анализа

Cloud9 Cloud 9 Ltd. заслуживает более конкретной оценки, чем многие небольшие хостинг-компании, поскольку между собой согласуются несколько независимых публичных записей. Сайт компании использует бренд Cloud9 для грузинского хостингового и дата-центрального бизнеса.Главная страницаописывает Cloud9 как профессионального веб-хостинг-провайдера и опытного оператора дата-центра в Грузии. В подвале указан операционный адрес: проспект Акакия Церетели, 2, стадион «Динамо», 5-й вход, Тбилиси, Грузия 0112, а также телефон и адрес поддержки.Условия обслуживанияназывают «Cloud 9 LLC», идентификатор компании 405063755, юридический адрес в Тбилиси и контактные адреса для договорных и технических вопросов. Названия не полностью единообразны на всех публичных поверхностях, но адрес, домен и данные реестра указывают на одного и того же грузинского хостинг-оператора.

Записи RIR делают эту идентификацию чем-то большим, чем заявление на сайте.RIPE RDAP для AS57814указывает организацию-регистранта как Cloud 9 Ltd., адрес: проспект Церетели, 2, 0112, Тбилиси, Грузия, и публичные административные, технические контакты и контакты для сообщений о злоупотреблениях.RIPE RDAP для ORG-CL434-RIPEуказывает организацию Cloud 9 Ltd., тот же адрес в Тбилиси, телефон и контактный email.RIPE RDAP для AS49297связывает ещё одну автономную систему с той же организацией и теми же контактами.

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

Поэтому важнее всего практическая рамка. Cloud9 видна как действующий грузинский хостинг- и сетевой провайдер. При этом значительная часть клиентской истории сосредоточена вокруг названного объекта в Тбилиси. Такое сочетание полезно для региональных услуг и локальности данных. Оно также означает, что клиент должен спрашивать, где именно работает каждая услуга, как она отказывает, как восстанавливается и что произойдёт, если клиенту нужно быстро уйти.

В сетевых записях два номера AS, но видимо активен только один

Публичная картина маршрутизации имеет чёткий центр и одну важную оговорку.Обзор AS57814 в RIPEstatпоказывает держателя Cloud9 Cloud 9 Ltd. и отмечает AS как анонсированную на время запроса 12 июля 2026 года.Обзор AS49297 в RIPEstatпоказывает ту же строку держателя, но отмечает эту AS как не анонсированную на тот же момент запроса.Данные анонсированных префиксов RIPEstat для AS57814перечисляют широкий набор видимых маршрутов, включая 185.229.110.0/24, 45.138.44.0/22 и 195.69.140.0/22 среди прочих, тогда кактот же интерфейс данных для AS49297не возвращает анонсированных префиксов.

Это различие нужно сохранить. Было бы неверно говорить, что каждая AS, связанная с Cloud9, активно передаёт трафик. Неверно было бы и говорить, что у компании нет видимой сети. AS57814 явно жива в публичной картине маршрутов.Подсчёты префиксов RIPE RISпоказывают 28 анонсируемых префиксов IPv4, 13 транзитных префиксов IPv4, три анонсируемых префикса IPv6 и два транзитных префикса IPv6 для AS57814 на время запроса 12 июля 2026 года. Эти цифры не доказывают, сколько клиентов активно, насколько заполнена платформа или каков объём свободных мощностей, но они показывают сетевую поверхность, заметно большую, чем один бездействующий маршрут.

Примеры маршрутов также показывают текущую видимость префиксов.Обзор префикса 185.229.110.0/24 в RIPEstatговорит, что префикс анонсируется AS57814 и связывает его с 185.229.108.0/22.Пример состояния BGP для 185.229.110.0/24 в RIPEstatвернул сотни наблюдений маршрутов; среди них пути достигают AS57814 через апстримы или пиринговые AS, такие как AS20771 и AS35805.BGP.tools для AS57814описывает Cloud 9 Ltd. как давно работающую сеть, которая пирится с другими сетями и имеет вышестоящих операторов, аBGP.tools для 185.229.110.0/24показывает, что этот префикс происходит из AS57814.

Операционный вывод сбалансирован. Cloud9 — не безликий реселлер без сети. У компании есть живая AS, видимость IPv4 и IPv6, объекты маршрутов и публичные данные о пиринге. Но видимость маршрутов — это не гарантия для клиента. Клиенту по-прежнему нужно знать, какие из его нагрузок находятся на собственных префиксах Cloud9, какие — на платформах вендоров, какие маршруты несут резервные сервисы и хватит ли запаса при переключении после обычной клиентской нагрузки.

Дата-центр — сердце предложения

Страницадата-центра Cloud9необычно прямо говорит о физической зависимости. На ней сказано, что большинство услуг Cloud9 предоставляется из собственного дата-центра в Тбилиси. Страница описывает нейтральный к операторам дата-центр, круглосуточный мониторинг инженерами 24/7/365, меры безопасности, резервирование электропитания, пожарную сигнализацию и пожаротушение, климат-контроль и межсетевые соединения. Там сказано, что объект питается от трёх независимых подстанций и резервного дизель-генератора мощностью 630 кВА; также сказано, что зона колокации имеет резервированный ввод питания N+N с ИБП. По части связности Cloud9 заявляет, что подключён к ведущим телекоммуникационным операторам и небольшим интернет-провайдерам через зарезервированное тёмное волокно с несколькими альтернативными маршрутами и совокупной ёмкостью межсоединений 250 Гбит/с.

PeeringDB подтверждает заявление о тбилисском объекте иначе.Запись объекта PeeringDB для Cloud9 Dinamo Arenaуказывает адрес: проспект А. Церетели, 2, Тбилиси, Грузия 0112, организацию Cloud9 LTD, примечание о том, что бизнес предоставляет в Грузии услуги дата-центра, хостинга, облака и ISP, число сетей 7, число обменных точек 1 и число операторов 1.Связь сети и объекта в PeeringDB для net_id 20057также связывает AS57814 с Cloud9 Dinamo Arena. Эти публичные данные PeeringDB не подтверждают инженерный проект, но дают независимый якорь объекта, совпадающий с адресной схемой на собственных страницах Cloud9.

Ключевой вопрос — установленная мощность против доступной. Страница дата-центра может называть подстанции, ИБП и генератор, но клиенту нужно знать, как эти активы ведут себя при обслуживании и отказах. Сколько стоек реально развёрнуто и запитано? Какова норма мощности на стойку? Сколько запаса ИБП и генератора остаётся после текущей нагрузки? Какой объём топлива законтрактован при длительном отключении электросети? Действительно ли цепи питания независимы до стойки клиента или они объединяются до точки отказа? Как проверяется запуск генератора под нагрузкой? Публичные страницы не отвечают на эти вопросы на должной глубине.

То же различие относится к связности. Заявление о совокупном межсоединении 250 Гбит/с содержательно, особенно для регионального рынка, но это не то же самое, что полоса, доступная клиенту при сбое. Клиенту нужно знать, использует ли его сервис общий транзит, путь через точку обмена, частное кросс-соединение, маршрут местного провайдера или магистральный путь Cloud9; выходит ли резервный путь из того же здания; сохраняются ли какие-либо гарантии полосы при обрыве волокна или обслуживании оператора. Публичные страницы Cloud9 дают достаточно уверенности, чтобы считать дата-центр реальным.

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

Хостинг — это услуга стойки, а уже потом облачная услуга

Розничное меню Cloud9 широкое. Компания продаётLinux-хостинг,Windows-хостинг,VPS,VDS,выделенные серверы,почту Zimbra,домены, сертификаты и колокацию. Вусловиях обслуживанияописаны хостинговые услуги, регистрация доменов, аренда виртуальных серверов, аренда физических серверов, почтовые услуги, услуги дата-центра, безопасность и защита от DDoS, планирование серверной инфраструктуры, DevOps-услуги и облачные услуги. Это не одинаковые зависимости.

Общий хостинг зависит от веб-серверов, панелей управления, DNS, хранилища и политики поддержки. VPS зависит от физического хоста, гипервизора, хранилища, снапшотов и контроля «шумных соседей». VDS позиционируется как более сильный виртуальный сервер, но по-прежнему зависит от выделения физического сервера и схемы отказоустойчивости. Аренда выделенного сервера зависит от оборудования Cloud9, запаса комплектующих, удалённой консоли и доступности персонала. Колокация зависит от собственного оборудования клиента, стоечных услуг Cloud9 и возможности клиента ремонтировать оборудование или заказывать услуги remote hands.

Почта зависит от работы почтовых серверов, спам-фильтрации, DNS, хранилища, резервных копий и инструментов миграции.

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

Доменом или почтой можно управлять через клиентский портал, но восстановление клиента может зависеть от того, можно ли быстро перенести DNS и экспорт почтовых ящиков.

Именно поэтому размещённые мощности всё равно нуждаются в физическом аудите со стороны клиента. Вопрос не просто в том, существует ли услуга. Вопрос в том, останется ли услуга работоспособной после отказа одного хоста, одного коммутатора, одной системы хранения, одного охлаждающего блока, одного пути питания, одного кросс-соединения или одной смены поддержки. Публичная информация Cloud9 подтверждает реального провайдера услуг с объектом и сетью. Она не публикует достаточно деталей, чтобы судить о выживании конкретного клиента при каждом из этих отказов.

Колокация задаёт чёткую границу собственности

Страница колокации— один из самых ценных публичных источников, потому что она показывает границу между мощностями, принадлежащими Cloud9, и оборудованием клиента. Cloud9 продаёт колокацию 1U, 2U и tower-серверов, половину стойки, полную стойку и индивидуальные клетки (cage). Предложения 1U и 2U включают двухвводное питание A/B, канал 1 Гбит/с и управляющий канал; предложение tower-сервера указывает одинарное питание, канал 1 Гбит/с и управляющий канал. На странице сказано, что подключение 1 Гбит/с не тарифицируется по объёму для грузинских ISP и включает глобальную связность 30 Мбит/с на клиента. Также сказано, что управляющий канал предназначен для IPMI, iLO, iDRAC или BMC-доступа с внутренним IP и защищённым VPN-доступом.

Эти детали коммерчески полезны и одновременно показывают ограничения. Колокация — это не то же самое, что управляемый выделенный хостинг. В FAQ Cloud9 сказано, что при колокации оборудование является ответственностью клиента, а Cloud9 предложит помощь в ускорении устранения неполадок. Там сказано, что инженеры Cloud9 доступны 24/7/365 для remote hands и что Cloud9 выполняла масштабные миграции, причём каждая миграция зависит от нагрузки.

Также сказано, что пространство и IP-адреса могут быть готовы менее чем за 24 часа после расчёта стоимости и первоначальной оплаты, тогда как полные стойки и клетки могут потребовать больше времени из-за комплектующих и работ.

Для клиентов эта граница решающа при простоях. Если у колоцированного сервера вышел из строя диск, блок питания или прошивка, Cloud9 может предоставить remote hands только в рамках договора клиента и доступных запчастей или плана замены. Если у клиента нет запасных дисков, учётных данных удалённой консоли, задокументированного загрузочного носителя и цели для миграции, стойка может оставаться под напряжением, пока приложение остаётся офлайн. То же касается сетевых изменений: управляющий канал помогает, только если у клиента есть права доступа, данные VPN, известные учётные данные и проверенный путь к консоли.

С ценой и формулировками о полосе тоже нужно обращаться осторожно. Локальный канал 1 Гбит/с и глобальная связность 30 Мбит/с могут быть достаточны для многих видов грузинского хостинга, но это не то же самое, что глобальная облачная полоса. Клиенту, обслуживающему международных пользователей, внеплощадочные резервные копии или крупные экспорты данных, нужно знать, как ведут себя всплески трафика, биллинг, перегрузки и экстренная миграция за пределами обычного месячного использования. Страница колокации делает Cloud9 честь тем, что публично указывает эту границу.

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

Пиринг и разнообразие маршрутов выглядят лучше, чем самая слабая гипотеза

Исходная гипотеза риска предупреждала о слабом публичном следе. Фактические данные о маршрутах и пиринге сильнее.Сетевая запись AS57814 в PeeringDBописывает Cloud9 как профиль сетевых услуг с AS57814, сайтом https://www.cloud9.ge/, поддержкой IPv6, региональным охватом, преимущественно исходящим трафиком, самооценкой трафика 200–300 Гбит/с, открытой общей пиринговой политикой, одним объектом и одной точкой обмена. В ней указан набор AS в IRR как AS-SET-CLOUD9. Профиль поддерживается самой компанией, и его не следует считать проверенной ёмкостью, но это публичный инфраструктурный профиль, а не пустая страница.

Запись netixlan в PeeringDBперечисляет Cloud9 на IXP.ge с портом 10 000 Мбит/с, IPv4-адресом 185.1.224.232, статусом пиринга через route server: true и операционным статусом: true.Запись IXP.ge в PeeringDBописывает точку обмена как расположенную в Тбилиси и Кутаиси, а Cloud9 Dinamo Arena — среди объектов. Собственнаястраница дата-центра Cloud9говорит, что компания также является оператором точки обмена интернет-трафиком и предоставляет кросс-соединения с операторами. В совокупности эти источники подтверждают значимую роль в локальном межсетевом обмене.

RIPEstat также показывает согласованность маршрутной политики на более широком наборе префиксов и пиров.Согласованность маршрутизации AS57814перечисляет многие префиксы как присутствующие и в BGP, и в whois-данных маршрутизации, включая 45.138.44.0/22, 185.229.108.0/24, 185.229.109.0/24, 185.229.110.0/24, 188.93.88.0/24 и 195.69.140.0/22. Она также показывает несколько импортных и экспортных пиров в BGP и whois, включая AS49628, AS20771, AS35805, AS16010 и AS34797, а также других видимых в BGP пиров, которых нет в проверенных whois-данных.Данные длины AS-пути в RIPEstatпоказывают AS57814 видимой из многих точек коллекторов.

Это не профиль хостинга с одним префиксом и единственным наблюдаемым апстримом. Однако разнообразие на уровне маршрутизации нужно переводить в устойчивость сервиса. У маршрута может быть несколько путей, тогда как сервис клиента по-прежнему зависит от одного коммутатора ToR, одного массива хранения, одного пути распределения питания или одного решения поддержки. Клиенту следует спрашивать, какие провайдеры используются для его сервиса, активно ли мониторятся маршруты, может ли Cloud9 переключать трафик во время обслуживания и остаётся ли международная доступность приемлемой при отказе одного пира или транзитного провайдера.

Гигиена маршрутизации частичная, но видимая

Безопасность маршрутизации — область, где у Cloud9 есть видимые доказательства, хотя оценивать их нужно по каждому префиксу.Проверка RPKI для AS57814 и 185.229.110.0/24 в RIPEstatвозвращает статус valid, включая валидирующие ROA для источника 57814, покрывающие 185.229.110.0/24 и 185.229.108.0/22. Это важно, потому что валидная авторизация происхождения маршрута помогает сетям отклонять анонсы от неправильного источника для этого префикса. Она не решает проблему недоступности приложений, но снижает один класс ошибок маршрутизации или угонов.

Интерфейс согласованности маршрутизации ASдаёт ещё один положительный сигнал, показывая многие префиксы Cloud9 и в BGP, и в whois-данных маршрутизации. Набор AS в профиле PeeringDB также даёт сетям публичный объект для использования в маршрутной политике. Это хорошие сигналы для регионального провайдера, потому что многие операционные инциденты начинаются с фильтра маршрутов, устаревшего объекта, отсутствия ROA или несоответствия между тем, что провайдер анонсирует, и тем, что готов пропускать апстрим.

Оговорка в том, что доказательства не являются универсальной сертификацией. Ссылка на валидацию RPKI выше проверяет один репрезентативный префикс, а не каждый маршрут. В выводе согласованности маршрутизации AS видны некоторые whois-маршруты, которых сейчас нет в BGP, и некоторые пиры в BGP, которых нет в проверенной whois-политике. Это нормально для многих сетей, но означает, что заявления для клиентов следует сверять с конкретным префиксом или услугой.

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

Гигиену маршрутизации следует связывать и с правами на миграцию. Если сервис клиента использует IP-адреса, предоставленные Cloud9, клиенту нужно знать, могут ли эти адреса переехать вместе с нагрузкой или DNS, сертификаты, списки разрешённых адресов и репутация почты должны быть пересозданы в другом месте. Сетевое доказательство Cloud9 достаточно сильное, поэтому сервисы клиентов могут быть глубоко интегрированы с его адресным пространством. Это делает чистую документацию ещё более важной, а не менее.

Заявления об электропитании и охлаждении требуют доказательств для конкретного клиента

Публичные заявления Cloud9 о дата-центре достаточно детальны, чтобы их использовать, но недостаточно детальны, чтобы заменить инженерные доказательства в договоре.Страница дата-центраговорит, что объект питается от трёх независимых подстанций и дизель-генератора мощностью 630 кВА. Там сказано, что зона колокации имеет резервированный ввод N+N и систему ИБП. Описаны раннее обнаружение температуры, дыма и огня, система пожаротушения 3M Novec 1230, DX-охлаждение, контроль температуры и влажности, отсутствие окон и внешних стен в серверных помещениях и только трубопроводы пожаротушения рядом. Также сказано, что все ключевые системы круглосуточно мониторятся инженерами.

Это правильные категории: питание, огонь, охлаждение, физическая безопасность и мониторинг. Остаётся вопрос, получает ли клиент резервирование после обычного обслуживания и правдоподобных отказов. Если клиент покупает колокацию 1U с двухвводным питанием A/B, действительно ли оба ввода идут по раздельным путям питания до самого верха, или один вышестоящий компонент всё равно может повлиять на оба? Если клиент покупает tower-колокацию с одинарным питанием, учёл ли он риск отказа одного блока питания? Если клиент арендует выделенный сервер, включает ли договор сроки замены комплектующих и путь замены оборудования?

Если виртуальный сервер работает на оборудовании Cloud9, какой уровень отказа хоста или хранилища платформа может пережить без простоя?

У охлаждения аналогичные скрытые ограничения. DX-охлаждение может подходить объекту, но клиенту нужно знать пределы плотности на стойку, схему горячих и холодных коридоров, размещение датчиков и путь эскалации, когда стойка перегревается. Объект может иметь резервную схему охлаждения, тогда как конкретная стойка клиента всё равно ограничена воздушным потоком или плотностью мощности. Пожаротушение тоже по-разному влияет на физическую колокацию и виртуальные сервисы. Событие пожаротушения может защитить оборудование от худшего ущерба, но всё равно может привести к аварийным ограничениям доступа, инспекциям и задержкам восстановления.

Публичный сайт говорит, что объект относится к Tier 3 в том смысле, что обслуживание может планироваться без прерывания сервиса. FAQ по колокации объясняет Tier 3 как классификационную систему Uptime Institute и говорит, что дата-центр Cloud9 соответствует Tier 3. Клиентам следует спрашивать, есть ли у Cloud9 актуальная сторонняя сертификация или термин используется для описания проектного замысла. Это различие не педантично. Проект, близкий к концепциям Tier III, полезен, но сертифицированный объект, аудиторская история обслуживания и письмо о резервировании для конкретного клиента имеют разную доказательную силу.

Портал упрощает сервис, но биллинг и доступ становятся зависимостями

Условия обслуживанияCloud9 важны, потому что показывают, как клиенты реально взаимодействуют с инфраструктурой. Согласно условиям, пользователь регистрируется на cloud9.ge и получает личный аккаунт в портале Cloud9 по адресу my.cloud9.ge, где может покупать новые продукты, управлять существующими, отменять ненужные, контролировать платежи и открывать тикеты поддержки в любое время. Условия также гласят, что пользователь отвечает за сохранность конфиденциальности аккаунта и за действия, совершённые с его использованием.

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

Это обычный юридический язык, но во время простоя он становится операционным.

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

Критическим клиентам всё равно нужно управление аккаунтом: совместное владение порталом, задокументированные контакты, правила вывода сотрудников и проверенная эскалация поддержки.

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

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

Суверенитет данных — преимущество, только если размещение сервисов явно

Самое сильное заявление Cloud9 о локальности — присутствие в Грузии. Сайт компании, условия, записи RIPE и PeeringDB указывают на Тбилиси.RIPE RDAP для ORG-CL434-RIPEуказывает Cloud 9 Ltd. в Тбилиси.Запись объекта в PeeringDBуказывает Cloud9 Dinamo Arena в Тбилиси.Геолокация 185.229.110.0/24 в RIPEstatпомещает этот репрезентативный префикс в Тбилиси на момент результата июля 2026 года. Страница дата-центра Cloud9 говорит, что большинство услуг предоставляется из собственного дата-центра Cloud9 в Тбилиси.

Для клиентов, которым нужен грузинский хостинг, локальная поддержка или низкая задержка до грузинских сетей, это ценно. Многие компании не хотят отправлять каждую нагрузку в гиперскейл-регион в другой юрисдикции, особенно когда важны поддержка, регуляторные запросы, язык и местные интернет-пути. Предложения Cloud9 по колокации и виртуальным серверам можно читать как ставку на локальные мощности: клиент покупает близость, локальную компанию, доступ к местным операторам и локальный объект.

Слово «большинство» по-прежнему важно. Публичные страницы Cloud9 не доказывают, что каждая услуга, резервная копия, почтовая запись, функция портала, DNS-сервис, сервис безопасности или набор данных поддержки хранится только в Грузии.Политика конфиденциальностиобсуждает обработку персональных данных и предоставление услуг, но публичный текст не сопоставляет каждый продукт с местом хранения.Условия обслуживанияперечисляют широкий портфель услуг, включая домены, сертификаты, почту, безопасность, защиту от DDoS и облачные услуги, некоторые из которых могут использовать сторонние системы. Для хостингового бизнеса это нормально, но означает, что локальность данных должна быть определена для каждой услуги отдельно.

Поэтому клиенту с требованиями к суверенитету данных следует запросить у Cloud9 заявление о размещении сервисов. Где находится основная нагрузка? Где резервные копии? Где логи? Где тикеты поддержки? Какие внешние реестры, удостоверяющие центры, системы защиты почты или платёжные процессоры касаются данных клиента? Можно ли экспортировать и удалить все данные по определённому графику? Если клиенту нужна обработка только в Грузии, какие продукты Cloud9 подходят, а какие нет? Публичное доказательство Cloud9 подтверждает Тбилиси как сильный центр тяжести. Оно не решает автоматически каждый вопрос о суверенитете данных.

DNS и доменные услуги делают Cloud9 частью плоскости управления клиентов

Cloud9 продаётрегистрацию доменов, хостинг, связанный с DNS, и почтовые услуги, поэтому его роль может выходить за пределы вычислений. Панель серверов имён на сайте перечисляет cPanel-неймсерверы для Linux-, Windows- и VPS-хостинга: ns1.cpanel.ge и ns2.cpanel.ge для Linux-хостинга, ns5.cpanel.ge и ns6.cpanel.ge для Windows-хостинга, ns3.cpanel.ge и ns4.cpanel.ge для VPS-хостинга. Публичные DNS-наблюдения показывают, что cloud9.ge использует ns1.cpanel.ge и ns2.cpanel.ge в качестве авторитетных неймсерверов, cloud9.ge резолвится в 188.93.90.171, а его MX-запись указывает на tbs01-mail02.cpanel.ge. Эти имена связывают розничный веб-, хостинговый и почтовый сервис с собственным сервисным пространством имён провайдера.

Это важно, потому что DNS — это плоскость управления, а не украшение. Если клиент размещает веб-сайт, почтовый домен или приложение на Cloud9 и использует управляемые Cloud9 неймсерверы, инцидент с DNS может повлиять на миграцию, переключение и восстановление, даже когда основной сервер здоров. И наоборот, если клиент держит DNS у независимого провайдера и использует Cloud9 только для вычислений или колокации, он может быстрее перенаправить трафик во время проблемы с Cloud9. Выбор зависит от толерантности клиента к риску и его квалификации.

Регистрация доменов добавляет ещё один слой. Клиент, покупающий домены через Cloud9, должен знать, как работает доступ к реестру, может ли он быстро получить коды переноса, кто получает уведомления о продлении, установлены ли блокировки домена и что произойдёт, если проблема с оплатой совпадёт с продлением. Домен может пережить любого хостинг-провайдера, но только если клиент сохраняет контроль над учётными данными, данными регистранта и правами переноса.

Почта повышает ставки ещё сильнее. Почта Zimbra удобна для компаний, которым нужен локальный почтовый продукт, но восстановление почты зависит от DNS, резервных копий почтовых ящиков, форматов экспорта, репутации антиспама, паролей пользователей и сроков поддержки. Клиентам следует спрашивать, как экспортируются почтовые ящики, как восстанавливаются DNS-записи, как долго удалённая почта остаётся восстанавливаемой и какие обязательства поддержки действуют во время почтового простоя. Доменные и почтовые услуги Cloud9 — легитимная часть предложения.

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

Основные пути отказов обычные, а не экзотические

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

Для клиента общего хостинга отказ может означать недоступный сайт, недоступную базу данных, ошибку DNS, проблему со входом в панель управления или задержку восстановления из резервной копии. Для клиента VPS или VDS — конкуренцию за хост, отказ хранилища, обслуживание гипервизора, недоступную консоль управления или потерю сети. Для клиента выделенного сервера — физический компонент, требующий наличия запчастей и работы руками. Для клиента колокации — оборудование клиента, к которому Cloud9 может помочь получить доступ, но которым не владеет. Для клиента домена — потерю контроля над именем, а не сервером.

Для клиента почты — доступ к ящику, маршрутизацию DNS, очередь почты или репутацию спама.

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

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

Именно поэтому публичное доказательство Cloud9 следует читать как отправную точку для комплексной проверки, а не замену. Клиенты должны спрашивать, что отказывает вместе. Размещены ли серверы, DNS, портал и цели резервного копирования в одном здании? Есть ли у сервиса вторая площадка? Хранятся ли снапшоты вне основной системы хранения? Тестируются ли изменения маршрутов? Может ли клиент перенести домен, почтовый ящик или образ сервера во время спора или чрезвычайной ситуации? Каждый ответ сокращает разрыв между «размещено в дата-центре» и «восстановимо, когда дата-центр, сеть или путь аккаунта испытывают нагрузку».

Миграция — скрытая цена дешёвых мощностей

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

Проблема выхода различна для каждой услуги Cloud9. Клиентам общего хостинга нужны файлы сайта, базы данных, DNS-зоны, почтовые аккаунты и логи. Клиентам VPS нужны образы виртуальных машин, снапшоты или воспроизводимые сборки серверов. Клиентам VDS и выделенных серверов нужны доступ к операционной системе, пути копирования данных, правила файрвола, образы, лицензии и планы перенумерации IP. Клиентам колокации нужны физический доступ, окна отгрузки, координация remote hands, карты кабелей и списки оборудования. Клиентам доменов нужны коды переноса и разблокированные записи регистранта.

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

Полоса может стать ограничивающим фактором. На странице колокации Cloud9 сказано, что стандартная связность клиента включает безлимитный канал 1 Гбит/с до грузинских ISP и глобальную связность 30 Мбит/с на клиента. Для обычных локальных нагрузок этого может быть вполне достаточно, но массовый экспорт в другую страну может вести себя совсем иначе. Если клиенту нужно перенести терабайты виртуальных машин, резервных копий или почтовых ящиков, клиент должен знать, доступно ли временное повышение полосы, сколько оно стоит и конкурирует ли миграционный трафик с производственным.

IP-адресация — ещё одна скрытая цена. Если сервисы клиента построены вокруг IP-адресов, предоставленных Cloud9, миграция требует изменений DNS, перевыпуска сертификатов, обновления списков разрешённых адресов в файрволах, восстановления репутации почты и уведомления клиентов. Если у клиента есть независимые от провайдера адреса или он держит DNS с коротким TTL и независимым, миграция может быть проще. Сетевое присутствие Cloud9 полезно, но клиенту не следует предполагать, что используемое сегодня адресное пространство сможет переехать вместе с сервисом завтра.

Самая безопасная позиция покупателя — считать план первой миграции и план выхода одним документом. Если Cloud9 — правильный провайдер, всё равно должна быть возможность определить, как клиент вернёт под свой контроль данные, домены, почтовые ящики, образы серверов и оборудование.

Что клиентам следует проверить перед размещением критических нагрузок

Публичное доказательство поддерживает представление о Cloud9 как о реальном грузинском инфраструктурном провайдере. Поэтому вопросы клиента более продвинутые, чем «существует ли он?». Первая группа вопросов — об объекте и мощности. На каком именно объекте размещается услуга? Это Cloud9 Dinamo Arena, другое помещение Cloud9 или сторонняя платформа? Сколько стоек, цепей питания, контуров охлаждения и сетевых путей задействовано для конкретного сервиса клиента? Каковы плотность мощности, выделенная полоса и резервная ёмкость клиента? Есть ли вторая площадка, и она активная, тёплая или только для резервного копирования?

Вторая группа — об эксплуатации сети. Какие префиксы будет использовать сервис клиента? Покрыты ли они валидными ROA RPKI и актуальными объектами маршрутов? Какие апстримы и пиры несут трафик клиента? Есть ли у клиента гарантия разнообразия маршрутов? Что произойдёт, если откажут IXP.ge, один апстрим, один волоконно-оптический маршрут или одна точка входа в здание? Как обрабатываются утечки маршрутов, события DDoS и проблемы международной доступности? Какую видимость клиент получает во время инцидента?

Третья группа — о восстановлении данных. Как часто создаются резервные копии? Где они хранятся? Неизменяемы ли они или изолированы от производственных учётных данных? Как часто тестируется восстановление? Как быстро восстанавливается полный виртуальный сервер, почтовый ящик или база данных? Может ли клиент восстановиться без доступности основного портала Cloud9? Включены ли экспорты резервных копий в цену и ограничиваются ли экстренные экспорты полосой?

Четвёртая группа — о поддержке и контроле. Кто отвечает вне рабочего времени? Какие вопросы покрываются remote hands, а какие оплачиваются отдельно? Каков путь эскалации для колокации, замены выделенного сервера, изменения маршрутов, переноса доменов и почтовых сбоев? Сколько авторизованных контактов может поддерживать клиент? Что произойдёт, если платёжный контакт уволится? Может ли клиент назначить аварийные контакты отдельно от платёжных?

Пятая группа — о выходе. Может ли клиент по запросу получить актуальный список активов, файл DNS-зоны, экспорт почтовых ящиков, образ виртуальной машины, копию резервных данных, код переноса домена и запись доступа? Какой срок уведомления требуется? Что происходит во время спора? Как долго можно восстановить удалённые или отменённые сервисы? Какие данные уничтожаются и когда? Эти вопросы не враждебны. Это минимальные условия, превращающие размещённую услугу в ответственную зависимость.

Итог

Cloud9 Cloud 9 Ltd. следует читать как действующего грузинского хостинг- и дата-центрального провайдера с заслуживающими доверия публичными инфраструктурными доказательствами. На его собственных страницах продаются соответствующие услуги. Записи RIPE связывают Cloud 9 Ltd. с AS57814 и AS49297, а RIPEstat показывает AS57814 как анонсированную, тогда как AS49297 в BGP не видна. AS57814 имеет содержательную поверхность маршрутов в IPv4 и IPv6 с видимостью анонсируемых и транзитных префиксов. PeeringDB помещает Cloud9 в Cloud9 Dinamo Arena в Тбилиси и показывает присутствие на IXP.ge.

Страница дата-центра Cloud9 даёт конкретные заявления об объекте: питание, охлаждение, пожаротушение, мониторинг и межоператорские соединения.

Этого достаточно, чтобы выйти за рамки самого слабого прочтения. Cloud9 — не просто имя в справочнике. Это локальный инфраструктурный провайдер с предложением, сосредоточенным вокруг объекта, публичным присутствием в маршрутизации и розничными продуктами, которые могут быть важны для грузинских компаний, разработчиков, государственных организаций и региональных поставщиков услуг. Ценностное предложение понятно: купить размещённые или колоцированные мощности рядом с грузинскими сетями, с локальной поддержкой и оператором дата-центра, который позиционирует себя как нейтральный к операторам.

Оставшийся риск — тот же, что сопровождает любого регионального облачного и хостинг-провайдера. Ярлык «облако» не отменяет стойки, транзит, питание, оборудование, DNS, биллинг, доступ к аккаунту или миграцию. Публичные страницы не доказывают резервную ёмкость при отказе компонента, скорость восстановления после инцидента с резервными копиями, права клиента на экспорт, эскалацию вне рабочего времени или чистое переключение между объектами. Клиенты могут хорошо использовать Cloud9, если задокументируют эти условия. Им не следует использовать его как чёрный ящик.

Для критических нагрузок мощности Cloud9 следует считать реальными, но зависящими от договора. У компании достаточно публичных инфраструктурных доказательств, чтобы к ней относились серьёзно. Безопасность клиента зависит от превращения этих доказательств в конкретные ответы: где работает нагрузка, что отказывает вместе с ней, как маршруты переживают сбои, как восстанавливаются резервные копии, кто ремонтирует оборудование, кто отвечает вне рабочего времени, что происходит, когда счёт или контакт аккаунта ломается, и как клиент выходит, не теряя данные или контроль.