Стоимость репатриации в облако: AWS, Azure или GCP или Bare Metal TCO Калькулятор

Репатриация облака перемещает выбранные рабочие нагрузки из общедоступного облака в «голое железо», частное облако или гибридную среду. Финансовое обоснование зависит от использования, перемещения данных, зависимостей сервисов и объема операций. При корректном сравнении используются одинаковые рабочие нагрузки, целевые показатели доступности, средства управления безопасностью и уровень поддержки с обеих сторон.

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

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

Коммерческие варианты, упомянутые в этом руководстве: миграция и репатриация в облако (https://unihost.com/migration/); выделенные серверы (https://unihost.com/dedicated/); управление сервером (https://unihost.com/management/)

Связанное чтение Unihost: От облака к железу (https://unihost.com/blog/from-cloud-to-bare-metal-2025/); Bare Metal против Cloud в 2026 году (https://unihost.com/blog/bare-metal-vs-cloud-2026/); миграция без простоев (https://unihost.com/blog/zero-downtime-migration/)

Что означает репатриация облака и когда она имеет смысл

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

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

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

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

Стоимость репатриации облака и модель TCO

Облачный калькулятор TCO должен включать в себя вычислительные ресурсы, память, ускорители, блочное и объектное хранилище, IOPS, снимки, резервные копии, выход данных, межзональный трафик, поддержку, лицензии, мониторинг, инструменты безопасности и время персонала. Для «голого железа» требуются соответствующие записи сервера, сети, хранилища, управления, резервного копирования и миграции. Используйте модель затрат «облако» и «голое железо», чтобы выявить факторы стоимости AWS и выделенных серверов, которые могут скрыть основные показатели стоимости экземпляров.

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

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

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

Облако против модели «голое железо» TCO

Категория	Входные данные общедоступного облака	Голый металлический ввод	Правило нормализации
Вычислить	Экземпляры, обязательства, автомасштабирование	Серверы и зарезервированная мощность	Та же рабочая нагрузка и доступность
Хранение	Емкость, IOPS, снимки, операции	Локальное, NAS или объектное хранилище плюс резервирование	Та же полезная емкость и восстановление
Сеть	Выход в Интернет и межзональная передача	Порт, разрешение на трансфер и частная сеть	Те же направления и пиковая пропускная способность
Поддержка и операции	Поддержка провайдера плюс работа на платформе	Менеджмент плюс рабочая сила на платформе	Те же часы работы и обязанности
Лицензии и безопасность	Изображения, торговая площадка, услуги безопасности	OS, панели, средства безопасности	Те же функции и соответствие
Миграция	Подготовка к выходу	Сборка, синхронизация, тестирование и откат	Единовременно, амортизируется отдельно

 

Три примера рабочих нагрузок с прозрачными предположениями

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

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

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

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

Примеры предположений о рабочей нагрузке

Рабочая нагрузка	Факторы затрат на облако	Факторы затрат на «голое железо»	Метрика решения
Стабильный SaaS API плюс база данных	Постоянно включенные экземпляры, служба базы данных, хранилище и выход	Вычисления, NVMe, резервное копирование и управление	Цена за успешную транзакцию в цели p95
Аналитический конвейер	Вычисление всплесков, операций с объектами, перемещения между зонами	Высокопроизводительные узлы, локальный NVMe, уровень хранения и планирование	Стоимость за завершенный набор данных в пределах окна
LLM вывод	GPU часов, издержки конечной точки, хранилище модели и выход	GPU сервер, VRAM подходит, мощность включена в аренду, операции	Цена за принятый ответ при целевой задержке

 

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

Что меняется в производительности и предсказуемости на «голом железе»

Bare Metal устраняет общее планирование гипервизора и дает команде прямой контроль над топологией CPU, RAM, локальными NVMe, сетевыми очередями и ускорителями. Это может улучшить согласованность, но результаты по-прежнему зависят от дизайна приложения, структуры хранилища, настройки ядра и аварийного переключения. Предсказуемое ценообразование на инфраструктуру имеет ценность только при правильном использовании мощности.

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

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

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

Риски, гибридные варианты и случаи, когда публичное облако следует сохранить

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

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

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

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

Пошаговый план перехода с AWS на «голое железо»

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

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

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

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

Пользователи облачного листа TCO могут копировать

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

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

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

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

Копируемый рабочий лист TCO

Позиция	Количество	Единичная ставка	Итого за месяц	Источник и уверенность
Компьютер или сервер				Счет или текущее предложение
RAM или премиум-ускоритель				Измеренное требование
Хранение и операции				Емкость, IOPS и сохранение
Интернет и межзоновый трансфер				Экспорт биллинга и журналов трафика
Поддержка, управление и мониторинг				Эквивалентный объем услуг
Лицензии и безопасность				Текущие контракты
Миграционная амортизация				Смета и период проекта
Рисковый резерв				Документированная неопределенность

 

Часто задаваемые вопросы

Что такое репатриация облака?

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

Когда «голое железо» дешевле, чем AWS?

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

Какие затраты следует включить в облако TCO?

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

Может ли компания использовать гибридное облако и модель «голого железа»?

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