Вартість репатріації в хмарі: 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/); Метал проти хмари у 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 має включати доступність прискорювача, використання, зберігання моделі та вартість успішного запиту.

Використовуйте обсяг бізнес-транзакцій, години обчислень, активне сховище, переміщені байти, обсяг підтримки та цільову затримку як модель невеликої ємності, а не знімок інформаційної панелі. Розділіть постійний попит, планову роботу та виняткові піки. Модель повинна пояснювати, який ресурс насичується першим, як довго триває насиченість і який клієнт або операційний результат змінюється в цей момент.

Використовуйте низький, очікуваний і високий сценарії для кожного робочого навантаження та змінюйте одне припущення за раз. Дизайн все ще може бути невдалим через вибір прикладу, модель використання чи доступності якого не нагадує реальну систему. Доведіть заплановану поведінку за допомогою тіньового робочого навантаження або пілотного режиму з однаковою сумішшю запитів і обсягом даних. Включіть у тест моніторинг, резервне копіювання та контроль безпеки, оскільки виробничі витрати не повинні з’являтися вперше після запуску.

Вартість має бути пов’язана з одиницею успішної роботи, такою як замовлення, запит, виконане завдання, відновлений терабайт або прийнята відповідь моделі. Таке подання запобігає виграшу дешевої конфігурації, якщо вона не досягає цільової затримки або відновлення, і запобігає розгляду невикористаного резерву як безкоштовного.

Приклад припущень щодо робочого навантаження

навантаження	Драйвери хмарних витрат	Фактори витрат на чистий метал	Метрика рішення
Steady SaaS API плюс база даних	Завжди ввімкнені екземпляри, служба бази даних, сховище та вихід	Обчислення, NVMe, резервне копіювання та керування	Цільова ціна за успішну трансакцію p95
Конвеєр аналітики	Обчислювальні пакети, операції з об’єктами, переміщення між зонами	Основні вузли, локальні NVMe, рівень зберігання та планування	Вартість заповненого набору даних у вікні
LLM висновок	GPU годин, накладні витрати кінцевої точки, пам’ять моделі та вихід	GPU сервер, VRAM придатний, електроенергія включена в оренду, операції	Ціна за прийняту відповідь із цільовою затримкою

Перегляньте спеціальні конфігурації

Які зміни в продуктивності та передбачуваності

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

Вимірюйте пропускну здатність, p95 і p99 затримку, CPU використання, хвостову затримку зберігання, втрату пакетів, використання прискорювача та вартість одиниці роботи з достатньою роздільною здатністю для захоплення пакетів і достатньою тривалістю для виявлення витоків, ефектів кешу та фонових завдань. Тримайте поєднання робочого навантаження видимим. Тест, в якому переважають легкі запити, може повідомити про хороші середні значення, тоді як дорогий шлях уже стоїть у черзі.

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

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

Ризики, гібридні варіанти та випадки, коли публічна хмара повинна залишитися

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

Створіть повторюваний набір доказів на основі відхилень попиту, часу масштабування, глибини залежності, можливості відновлення, регіональних вимог і охоплення персоналу. Зберігайте дані про робоче навантаження поруч із результатами, включаючи версію програмного забезпечення, розмір даних, стан кешу та паралельність. Це перетворює наступний огляд потужності на порівняння замість іншої оцінки з пам’яті.

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

Покроковий план переходу з AWS на «голе метал».

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

Відстежуйте затримку реплікації, контрольні суми даних, частоту помилок, затримку, глибину черги, вартість під час подвійної роботи та час відкату на рівнях компонентів і сервісів. Запас ресурсів цінний лише тоді, коли він зберігає цілі затримки, коректності та відновлення, які важливі для бізнесу. Використовуйте перший постійно обмежений показник, щоб керувати наступним тестом.

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

Користувачі робочого аркуша Cloud TCO можуть копіювати

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

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

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

Копіюваний робочий аркуш TCO.

Лінійка	Кількість	Розцінка за одиницю	Усього за місяць	Джерело і впевненість
Обчислення або сервер				Рахунок або актуальна пропозиція
RAM або акселератор преміум				Виміряна вимога
Зберігання та експлуатація				Ємність, IOPS і збереження
Інтернет та міжзоновий трансфер				Експорт білінгу та журнали трафіку
Підтримка, управління та моніторинг				Еквівалентний обсяг послуг
Ліцензії та безпека				Поточні договори
Міграційна амортизація				Кошторис проекту та період
Резерв ризику				Задокументована невизначеність

Запит на оцінку вартості та міграції в хмарі

Питання та відповіді

Що таке хмарна репатріація?

Хмарна репатріація переміщує вибрані робочі навантаження або дані з загальнодоступної хмари до «голого металу», приватної хмари або іншого контрольованого середовища. Зазвичай це вибірково, а не тотально. Метою може бути зниження поточних витрат, стабільніша продуктивність, контроль даних або краща операційна відповідність.

Коли голий метал дешевший за AWS?

Метал може бути дешевшим, якщо робоче навантаження виконується безперервно зі значним завантаженням, потребує великого локального сховища або передає значні дані. Відповідь залежить від зобов’язань, керованих послуг, підтримки та операцій. Порівняйте повний TCO з ідентичними вимогами до доступності та безпеки.

Які витрати слід включити в хмару TCO?

Включає обчислення, пам’ять, прискорювачі, ємність і операції зберігання, знімки, резервні копії, вихід, передачу між зонами, підтримку, ліцензії, моніторинг, засоби безпеки та час персоналу. Окремо покажіть витрати на міграцію та подвійну роботу. Використовуйте поточні рахунки-фактури та документально підтверджені ставки.

Чи може компанія використовувати гібридну модель хмари та голого металу?

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