Що таке хмарні технології: як працює невидимий комп’ютер

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

Формальне визначення, на яке досі спирається галузь, дав американський інститут NIST у стандарті SP 800-145: хмарні обчислення — це зручний мережевий доступ на вимогу до спільного пулу ресурсів, які можна швидко виділити й звільнити майже без участі людини з боку провайдера. Саме ця формула відділяє справжню хмару від звичайного хостингу, оренди виділеного сервера чи «диска в інтернеті».

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

Хмара — не «місце в інтернеті», а модель доступу до ресурсів

У побуті словом «хмара» називають усе підряд: Google Диск, iCloud, Zoom, навіть «файл зберігся в хмарі». Технічно це різні речі. Хмарне сховище — лише один сервіс. Хмарні технології — спосіб організації ІТ, у якому інфраструктура перестає бути власністю компанії і стає послугою з вимірюваним споживанням.

NIST фіксує п’ять обов’язкових ознак. Якщо хоча б однієї немає — це вже не хмара, а щось інше, навіть якщо продавець пише «cloud» на сайті.

• Самообслуговування на вимогу. Ви самі створюєте віртуальну машину, базу чи сховище за хвилини, без заявки в техпідтримку й очікування на монтаж заліза.
• Доступ через мережу. Ресурс відкривається зі смартфона, ноутбука чи сервера за стандартними протоколами, а не лише з локальної мережі офісу.
• Спільний пул ресурсів. Фізичні сервери, диски й канали об’єднані. Провайдер динамічно нарізає з них частки різним клієнтам, зберігаючи ізоляцію.
• Швидка еластичність. Навантаження виросло — потужність додається автоматично або за кілька кліків. Сезон минув — ресурси згортаються, і рахунок зменшується.
• Вимірюване споживання. Процесорний час, гігабайти, трафік, кількість запитів фіксуються. Оплата прив’язана до метрик, а не до «сервера на рік наперед».

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

Ідея не нова. Ще в 1960-х Джон Маккарті припускав, що обчислення стануть комунальною послугою. Термін «хмара» прийшов із телефонних схем, де хмаринкою малювали мережу, внутрішній устрій якої абоненту неважливий. Комерційний вибух стався 2006 року, коли Amazon відкрив AWS: вільні потужності власних дата-центрів почали продавати стороннім клієнтам. Відтоді модель лише ускладнювалась — з’явились контейнери, serverless, GPU-кластери для штучного інтелекту, суверенні хмари. Принцип лишився тим самим: ви купуєте результат, а не стійку з серверами.

Як із заліза в дата-центрі виходить хмара

Фізично нічого «ефірного» в хмарі немає. Є будівлі з резервуванням живлення, охолодженням, пожежогасінням і фізичною охороною. Усередині — тисячі серверів у стійках, системи зберігання й комутатори. Різниця не в залізі, а в програмному шарі, який перетворює ці стійки на пул, з якого клієнт відрізає потрібний шматок за хвилини.

Перший шар — віртуалізація. Гіпервізор (KVM, VMware ESXi, Hyper-V) ділить один фізичний сервер на кілька ізольованих віртуальних машин. Кожна має власну операційну систему, диски й мережу. Клієнт А не бачить дисків клієнта Б, навіть якщо їхні віртуалки стоять на сусідніх процесорних ядрах. Без цього пул неможливий: один сервер обслуговував би одного замовника, як у класичному хостингу.

Другий шар — оркестрація. Системи на кшталт OpenStack, VMware Cloud Director чи Kubernetes вирішують, на якому саме фізичному вузлі запустити нову машину, як перенести її при відмові диска, як розподілити навантаження. Користувач бачить кнопку «створити сервер». Під нею — черга задач, перевірка квот, вибір хоста, нарізка мережі, підключення сховища.

Третій шар — мережа й зберігання. Вам виділяють віртуальну приватну мережу (VPC), підмережі, балансувальник, файрвол, VPN-шлюз. Дані лежать не «на диску сервера», а в одному з трьох типів сховищ: блочному (як жорсткий диск для ОС), файловому (спільні каталоги) або об’єктному (S3-сумісні бакети для резервних копій, медіа, логів). Об’єктне сховище масштабується майже без стелі й тому стало стандартом для бекапів і статичного контенту.

Четвертий шар — облік і білінг. Кожна година vCPU, кожен гігабайт на місяць, кожен гігабайт трафіку назовні потрапляє в лічильник. Саме тут народжуються і економія, і «шок від рахунку». Забута тестова віртуалка з GPU може коштувати дорожче за весь продакшен. Не Tarифікований вихідний трафік після міграції великої бази — окрема стаття витрат, про яку рідко попереджають на етапі «давайте в хмару, буде дешевше».

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

IaaS, PaaS і SaaS: хто за що відповідає насправді

Три класичні моделі послуг відрізняються не «рівнем крутості», а межею відповідальності. Це так звана модель спільної відповідальності: провайдер закриває одні шари, клієнт — інші. Більшість інцидентів трапляється саме на стику, коли обидві сторони вважають, що «це не наше».

Джерело: узагальнено за моделями NIST SP 800-145 і типовим розподілом відповідальності гіперскейлерів.

IaaS (інфраструктура як послуга) — ви отримуєте віртуальні машини, диски, мережу. Ставите Windows чи Linux, самі латаєте діри, самі ставите Nginx, самі вирішуєте, як робити бекап. Максимальний контроль і максимум роботи для системного адміністратора. Ця модель найближча до «переїхали з власного сервера».

PaaS (платформа як послуга) — вам дають готове середовище: мову, рантайм, базу, чергу повідомлень. Ви заливаєте код, платформа збирає, масштабує й перезапускає. Зате ви прив’язані до стеку провайдера: змінити базу чи винести застосунок «як є» на іншого оператора буває болісно. Це й є vendor lock-in у найбільш побутовому вигляді.

SaaS (програмне забезпечення як послуга) — відкриваєте браузер і працюєте. Оновлень «у ніч з п’ятниці на суботу» немає, серверів немає, патчів немає. Зате немає й глибокого налаштування. Якщо SaaS-бухгалтерія не вміє ваш сценарій — ви або змінюєте процес, або пишете костилі через API, або йдете геть разом із даними, які ще треба вміти вивантажити.

Поруч уже давно живуть вужчі моделі: FaaS (функція як послуга, або serverless — платите за час виконання функції, а не за сервер), CaaS (контейнери як послуга), DRaaS (аварійне відновлення як послуга), IDaaS (ідентичність як послуга). Для більшості компаній достатньо розуміти трійку IaaS–PaaS–SaaS і не змішувати їх в одній розмові. «Ми перейшли в хмару» може означати і «купили ліцензії Microsoft 365», і «перенесли ERP на віртуалки в українському ЦОД». Це принципово різні проекти з різною ціною, ризиками й командою.

Як обрати модель без презентації від продажів

Якщо потрібен готовий інструмент для людей — пошта, документи, CRM, відеозв’язок — починайте з SaaS. Якщо команда пише власний продукт і не хоче адмініструвати Linux — PaaS або керований Kubernetes. Якщо є легасі-система, ліцензії «на процесор», особливі вимоги до ОС або регулятор — IaaS, іноді навіть виділене обладнання поруч із хмарою.

Змішувати моделі нормально. Типова українська компанія вже сидить у гібриді, навіть якщо так це не називає: пошта в Microsoft 365, сайт на віртуалці локального провайдера, 1С/BAS на окремому сервері, бекапи в об’єктне сховище. Питання не в «чистій» архітектурі, а в тому, чи хтось бачить усю картину й відповідає за стики.

Публічна, приватна, гібридна і суверенна: ярлики, за якими ховаються різні ризики

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

Джерело: моделі розгортання NIST плюс практика суверенних хмар 2025–2026 років.

Публічна хмара дешевша на старті, бо витрати на стійки й чергових інженерів ділять сотні клієнтів. Ціна — мультиорендність: ви довіряєте ізоляції провайдера. Приватна хмара дорожча, зате ви контролюєте контур, політику доступу й фізичне розташування. Гібрид має сенс, коли частина систем не може вийти за периметр (старий АСУ ТП, ліцензія, секретність), а сайти, аналітика й тестові середовища спокійно живуть ззовні.

Суверенна хмара — окрема історія, і саме вона стала однією з головних тем ринку. За прогнозом Gartner від лютого 2026 року, світові витрати на суверенний IaaS сягнуть близько 80 мільярдів доларів — на 35,6% більше, ніж роком раніше. Причина не технічна, а політична: держави й великі компанії хочуть, щоб дані не підпадали під чужу юрисдикцію, а ключі шифрування й персонал підтримки залишались у зрозумілому правовому полі. Для України це не абстракція. Після 2022 року питання «в якій країні лежить бекап і хто може отримати до нього доступ за ордером» перестало бути теоретичним.

Мультихмара звучить як страховка, але без єдиного шару спостереження перетворюється на два окремі зоопарки з двома рахунками. Мати AWS для ML і українського провайдера для персональних даних клієнтів — розумна схема. Тягнути ту саму ERP у три хмари «про всяк випадок» — майже завжди зайві гроші й потрійна поверхня атаки.

Сім міфів, через які бізнес або боїться хмари, або переплачує

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

1. «Хмара завжди дешевша за власний сервер». Ні. Дешевша вона тоді, коли навантаження нерівномірне, команда не хоче тримати інженерів 24/7, а обладнання морально старіє швидше, ніж окупається. Якщо ви роками крутите один стабільний сервіс із передбачуваним навантаженням і вже маєте ЦОД — пряма оренда або навіть власне залізо може виграти. Хмара виграє на піках, експериментах, швидкому старті й відмовостійкості, яку малому бізнесу не потягнути самостійно.

2. «Дані в хмарі менш захищені, ніж у шафі в офісі». Офісна шафа не має ані ISO 27001, ані чергових охоронців, ані рознесеного резервування. Провайдер закриває фізику й периметр краще за 95% компаній. Зате пароль «Admin123» на віртуалці, відкритий порт RDP у світ і відсутність MFA зводять цю перевагу до нуля. Безпека хмари — це безпека провайдера плюс ваші налаштування. Друга частина частіше підводить.

3. «Раз воно в хмарі — бекап не потрібен». Провайдер відновлює свою інфраструктуру, не ваш випадково видалений каталог і не зашифровану програмою-вимагачем базу. Snapshot — не стратегія. Потрібні копії з окремими правами, перевірка відновлення й правило 3-2-1 (три копії, два носії, одна поза основним майданчиком). Багато хто стикається з ситуацією, коли «бекап був», але відновити з нього бойову систему ніхто ніколи не пробував — і саме в ніч інциденту з’ясовується, що ланцюжок зламаний.

4. «Переїзд у хмару — це скопіювати віртуалки як є». Lift-and-shift працює як перший крок, але залишає вам старі проблеми плюс новий рахунок. Моноліт, який на власному сервері їв 8 ядер «про запас», у хмарі їстиме їх щогодини й ніколи не стиснеться. Вигода з’являється, коли переписують автомасштабування, викидають зайві середовища, переносять статику в об’єктне сховище, а базу — в керований сервіс.

5. «Хмара = Google Диск». Диск — це SaaS-сховище файлів. Воно не замінює контролер домену, не хостить інтернет-магазин і не закриває вимоги до обробки персональних даних пацієнтів. Коли керівник каже «ми вже в хмарі, бо є Диск», ІТ-відділ ще тримає пошту на власному Exchange 2013 і касовий сервер під столом.

6. «Після міграції системного адміністратора можна скоротити». Адміністрування заліза справді меншає. З’являються інші задачі: IAM, мережеві політики, контроль рахунків, резервне копіювання логіки, відповідність закону, спостереження за вартістю. Компанії, які «звільнили адміна після переїзду», через пів року наймають дорожчого cloud-інженера або живуть з відкритими бакетами.

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

Що змінює українське законодавство і локальний ринок

Для українського бізнесу «просто взяти AWS» — вже не єдина й не завжди законна відповідь, якщо йдеться про державу чи критичну інфраструктуру. Закон України «Про хмарні послуги» № 2075-IX від 17 лютого 2022 року визначив правила гри: хто є надавачем хмарних послуг, які обов’язки він несе, як держава може закуповувати такі сервіси. Постанова Кабміну № 154 від 11 лютого 2025 року закрила прогалини в реєстрації надавачів і задала перехідний період.

До 31 грудня 2025 року державні установи ще могли купувати хмарні сервіси в компаній, які не встигли пройти реєстрацію. З 2026 року для роботи з держорганами та об’єктами критичної інфраструктури реєстрація фактично стає перепусткою. Пакет не формальний: комплексна система захисту інформації (КСЗІ) з експертизою Держспецзв’язку, підтвердження прав на інфраструктуру, політика обробки персональних даних, сертифікація. Експертизи можуть тривати місяцями. На початку 2026-го в реєстрі очікувано опиниться лише невелика група гравців — і це змінює конкуренцію сильніше за будь-яку рекламу.

Окреме обмеження: технічні засоби не можуть належати підсанкційним особам і не можуть стояти на території держави-агресора. Для компанії, яка тримає прод у ЄС, а «дешевий тест» — на сумнівному майданчику без прозорої юрисдикції, це вже не питання зручності, а питання відповідності.

За оцінкою Максима Агєєва (De Novo), обсяг споживання IaaS/PaaS в Україні 2025 року перевищив 7 мільярдів гривень, а з урахуванням донорської допомоги гіперскейлерів — орієнтовно понад 10 мільярдів. Від 2021-го ринок зріс більш ніж уп’ятеро. Понад 80% продажів тримають іноземні провайдери, насамперед AWS і Microsoft Azure. Українські оператори (De Novo, GigaCloud, Датацентр «Парковий» та інші) мають близько 20% — але саме вони закривають розміщення в українській юрисдикції, фізичний доступ до майданчика й супровід КСЗІ. Для частини замовників це не «патріотичний вибір», а єдина робоча схема.

Держава сама є великим споживачем. Портал Дія, реєстри, обмін між органами — усе це не існує «на одному сервері міністерства». Водночас військові та розвідувальні контури логічно тяжіють до ізольованих приватних рішень, а не до публічного пулу. Бізнесу з цього варто винести просте правило: клас даних визначає майданчик. Маркетингова розсилка може жити в будь-якому європейському регіоні. Медична картка, дані енергообліку, реєстр платників — уже предмет розмови з юристом і службою захисту інформації, а не лише з DevOps.

Суміжне питання, яке спливає одразу після «а де стоятиме сервер»: персональні дані. Хмарний договір має фіксувати роль провайдера (обробник чи співконтролер), місце обробки, субісполнителів, строк повернення даних після розірвання і те, чи вміє провайдер віддати їх у придатному форматі. Якщо цього пункту немає — ви не «в хмарі», ви в заложниках у власного архіву.

Коли рахунок росте, сервіс «лежить» або дані не їдуть: що робити

Хмара ламається інакше, ніж системник у серверній. Живлення в ЦОД майже напевно є. Немає доступу, бо скінчився токен, змінили групу безпеки, вичерпалась квота, впав конкретний регіон або хтось видалив не той Terraform-стан. Діагностика починається не з «перезавантажити», а з відповіді на три питання: це інфраструктура провайдера, наша конфігурація чи зовнішній канал?

1. Перевірте сторінку статусу провайдера і одночасно — чи відкривається інший ваш сервіс у тій самій зоні. Якщо лежить лише ваш сайт, шукайте в себе.
2. Подивіться логи доступу, IAM і зміни в мережі за останні години. Найчастіша причина «раптом 403» — людина або скрипт змінили політику.
3. Оцініть квоти й ліміти: диски, IP-адреси, кількість віртуалок, TPS бази. Хмара вміє відмовити мовчки, коли ви вперлися в ліміт акаунта.
4. Якщо це інцидент із даними — не перезаписуйте томи, зніміть знімок, обмежте доступ, повідомте відповідального за захист інформації. Для значущих кіберінцидентів в Україні є контур CERT-UA.
5. Відновлення робіть за заздалегідь написаним runbook, а не «з голови о другій ночі». Якщо runbook не тестували на навчальній тривозі — його немає.

Окремий клас проблем — рахунок. Типові дірки: забуті тестові середовища після демо, диски від видалених машин, публічні балансувальники, які ніхто не вимкнув, вихідний трафік після синхронізації бекапів, GPU «на ніч, а ніч тривала три тижні». Ліки конкретні: бюджети й алерти на суму, теги на кожен ресурс (хто власник, який проект, до якої дати живе), автоматичне гасіння неробочих середовищ після 21:00, окремий акаунт для експериментів. Раз на місяць — розбір топ-10 найдорожчих рядків. Це і є побутовий FinOps, без якого «гнучка хмара» перетворюється на абонемент із сюрпризом.

Коли варто кликати зовнішнього фахівця, а не «ще трохи покрутити самому»:

• потрібна КСЗІ, робота з держсектором або об’єктом критичної інфраструктури;
• мігруєте легасі-ERP чи АСУ з простоєм, близьким до нуля;
• є вимоги PCI DSS, медичні дані, банківська таємниця;
• рахунок за квартал зріс удвічі без зростання виручки, і ніхто в команді не вміє читати білінг;
• немає перевіреного плану аварійного відновлення, а простій години вже рахується в прямих збитках.

Хороший підрядник на вході питає не «яку хмару оберете», а «які дані, який допустимий простій, яка юрисдикція, хто будить людей о 3:00». Якщо розмова одразу скаче до бренду провайдера — це продаж, не проєктування.

Коли хмара не потрібна і чим вона відрізняється від хостингу

Після основного питання майже завжди виникає друге: а чи не достатньо звичайного хостингу? Коротке розведення понять рятує від зайвої складності.

Віртуальний хостинг — місце під сайт на спільному сервері з обмеженою ізоляцією. Підходить для візитки й блогу. Це не хмара.

VPS — одна віртуальна машина з фіксованим тарифом. Схоже на міні-IaaS, але зазвичай без автомасштабування, без VPC і без поминутного обліку. Добре для малого проекту з рівним навантаженням.

Виділений сервер — конкретне залізо. Максимум контролю, нуль еластичності. Вигідний, коли ядра й диски завантажені постійно.

Хмара — пул з API, обліком і можливістю рости й стискатись. Дорожча за VPS на «завжди увімкненій» дрібниці, дешевша на піках і відмовостійких схемах.

Хмару варто відкласти, якщо одночасно справджуються кілька умов: навантаження рівне роками, немає регуляторного тиску на географію, у штаті є людина, яка вміє міняти диски й прошивки, а вартість простою нижча за вартість керованого контуру. Другий чесний випадок — мікробізнес із однією касаою й поштою: Microsoft 365 або Google Workspace плюс локальна каса закриють 90% потреб без жодного IaaS.

І навпаки, хмара майже безальтернативна, коли бізнес сезонний, команда розподілена, потрібен резервний майданчик «на випадок втрати офісу чи міста», або продукт сам є цифровим і має рости швидше, ніж закуповується залізо. Для інтернет-магазину перед чорною п’ятницею докупити 20 віртуалок на 10 днів дешевше й швидше, ніж пояснювати постачальнику серверів, що після понеділка вони знову не потрібні.

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

• Які дані поїдуть і якого вони класу (публічні, персональні, службові, з обмеженням на вивезення)?
• Який простій у хвилинах ми витримуємо і скільки коштує година мовчання?
• Хто власник акаунта, хто має права супер адміністратора, чи ввімкнено MFA на всіх?
• Де лежать бекапи, хто перевіряв відновлення востаннє, чи не збігаються права на прод і на копію?
• Яка юрисдикція ЦОД і чи проходимо ми Закон «Про хмарні послуги», якщо замовник — держава?
• Скільки коштує виїзд: вивантаження баз, трафік назовні, переписування унікальних сервісів?
• Хто читає рахунок і хто гасить ресурси, яким більше ніж 30 днів немає власника?

Якщо на три пункти поспіль відповідь «не знаємо» — проблема не в хмарі. Проблема в тому, що ІТ уже розмазане між сервісами, і ніхто не тримає карту. Переїзд у такому стані лише перенесе хаос на чужі стійки.

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