Суверенна хмара — один із найбільш перевантажених термінів у закупівлях оборонного ІТ. Постачальники застосовують його до всього: від гіперскейлерного регіону, будівлі якого стоять у межах національних кордонів, до повністю air-gapped приватної хмари, яку обслуговують виключно громадяни з допусками. Цей ярлик ховає архітектурні рішення, які на практиці визначають, чи може іноземний уряд примусити до розкриття ваших даних, чи може ворожа розвідка кооптувати персонал оператора хмари, чи переживе ваш план безперервності операцій геополітичний розкол. Для оборонних навантажень ці питання — несучі.

Ця стаття проходить практичним ландшафтом суверенної хмари станом на 2026 рік: урядові регіони американських гіперскейлерів, нове покоління європейських суверенних пропозицій (Bleu, Delos, T-Systems, OVH), хмари NATO та національних оборонних відомств і базисна on-prem інфраструктура, з якою всі вони зрештою конкурують. Стаття написана для архітекторів, що ухвалюють рішення про розміщення, а не для команд закупівель, що пишуть RFP.

1. Що насправді означає «суверенна хмара»

Суверенітет у хмарі — не одна властивість, а три ортогональні вектори, і будь-яка чесна оцінка має оцінювати кожен незалежно.

Резидентність даних — найпростіший і найбільш переоцінений. Вона запитує: де фізично живуть байти? Регіон у Франкфурті, Парижі або Варшаві задовольняє резидентності для покупців ЄС. Але резидентність сама по собі — найслабша з пропонованих гарантій суверенітету, бо вона нічого не каже про те, хто може досягнути цих байтів через control plane.

Операторський суверенітет запитує: хто може адмініструвати інфраструктуру? Комерційні регіони американських гіперскейлерів обслуговуються глобально розподіленими інженерними командами — L2-тікет, що торкається вашого тенанта, можна обробляти з Індії, Ірландії або Сіетла. Урядового рівня суверенні пропозиції обмежують це визначеним набором громадян із допуском, з аудитом, достатнім для доказу відповідності. SecNumCloud (Франція) і C5 (Німеччина) обидва вимагають, щоб оператори були громадянами ЄС, які працюють під юрисдикцією ЄС.

Юрисдикційний суверенітет — вектор, що руйнує найбільше припущень закупівель. US CLOUD Act 2018 року дозволяє американській владі примушувати будь-яку компанію, інкорпоровану в США, надавати дані під її контролем, незалежно від того, де ці дані фізично знаходяться. Тож американський за штаб-квартирою гіперскейлер, що тримає інфраструктуру у Франкфурті, юридично все одно досяжний з американського суду. Відповідь ЄС — GDPR, Schrems II, Data Act — загострила питання, але не розв'язала. Єдина структурна відповідь — помістити і дані, і корпоративну сутність, що ними керує, під юрисдикцію ЄС.

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

2. Суверенні пропозиції американських гіперскейлерів

Американські гіперскейлери провели п'ятнадцять років, будуючи ізоляцію урядового класу. Результат — найбільш зрілий рівень суверенної хмари на планеті, для покупців, пов'язаних із США.

AWS GovCloud (US-East і US-West) фізично ізольований, адмініструється лише особами США, акредитований за FedRAMP High та DoD IL4/IL5. AWS Secret Region і AWS Top Secret Region існують для класифікованих рівнів, але доступні лише акредитованим урядовим покупцям і підрядникам США. AWS оголосив European Sovereign Cloud (Бранденбург) із поставкою у 2026 році, що повністю керується громадянами ЄС, — перший американський гіперскейлер, що зобов'язався перед цією структурою для покупців ЄС.

Azure Government віддзеркалює модель AWS: Azure Government (FedRAMP High, IL5), Azure Government Secret (IL6) та Azure Government Top Secret. Microsoft має найширший акредитований слід на класифікованому рівні, і Azure Government успадковує більшість комерційних сервісів Azure із затримкою від шести до дванадцяти місяців. Microsoft також керує Microsoft Cloud for Sovereignty як конфігурованим шаром поверх комерційного Azure для покупців, які хочуть контролів суверенітету без повного оверхеду акредитації Azure Government — див. наше порівняння архітектур GovCloud для деталей розміщення Azure-vs-AWS.

Google Assured Workloads — найлегший з трьох: оверлей control plane на комерційному Google Cloud, що забезпечує обмеження резидентності, персоналу та керування ключами. Він націлений на FedRAMP High та IL5 для специфічних конфігурацій, але не керує окремим регіоном. Для навантажень, де налаштований комерційний регіон прийнятний, це може скоротити час до ATO; для IL6 і вище не конкурує.

Жорстке обмеження для покупців не зі США: GovCloud, Azure Government і рівні IL5/IL6 контрольовані доступом лише для осіб США та експортним контролем США. Французький авіаційний підрозділ не може купити ємність GovCloud. Це структурна причина існування європейського рівня суверенної хмари.

3. Європейські суверенні пропозиції

Bleu — французьке спільне підприємство суверенної хмари між Capgemini і Orange. Воно запускає ліцензовану технологію Microsoft Azure всередині французьких ЦОДів, керується лише французькими громадянами, з корпоративним контролем повністю під французьким законом — явно поза досягом CLOUD Act. Кваліфікація SecNumCloud — заголовкова акредитація. Bleu — найчіткіший приклад моделі «ліцензований гіперскейлер під суверенним оператором» і є вибором розміщення для французьких оборонних, міністерських і OIV-навантажень.

Delos — німецька суверенна хмара, побудована SAP та Arvato Systems, знову ж на ліцензованій технології Microsoft, націлена на акредитацію C5 і призначена для навантажень Bund (федеральних) і Länder (земельних). Delos і Bleu — родичі: той самий технічний патерн, різні національні юрисдикції.

T-Systems Sovereign Cloud — старіша пропозиція Deutsche Telekom: суверенна хмара, побудована без ліцензійного шару гіперскейлера, на основі OpenStack і пропрієтарної оркестрації Telekom. Вона цілить у ту саму базу покупців, що і Delos, але з нижчою стелею функцій і довшим операційним досвідом. Для навантажень, що не потребують повної API-поверхні гіперскейлера, T-Systems часто дешевший і швидший для онбордингу.

OVHcloud займає окрему нішу: повністю європейсько-власна гіперскейлерна альтернатива з bare-metal-подами, dedicated cloud і публічним хмарним рівнем, все під французькою юрисдикцією. OVH не претендує на паритет з AWS за функціями, але для обчислювально-важких та сховищно-важких навантажень він конкурентний за ціною і доставляє справжній юрисдикційний суверенітет без американської ліцензійної залежності. Для глибшого аналізу розміщення ЄС vs США див. наше порівняння суверенних хмар ЄС vs США.

4. NATO та національні оборонні хмари

Над комерційним суверенним рівнем сидить шар, що не з'являється у брошурах постачальників: хмари NATO та національних МО. Це призначення для класифікованих навантажень, де навіть SecNumCloud чи FedRAMP High недостатньо.

NCIA Software Factory і ширша хмарна програма NATO забезпечують альянсну платформу для міжнаціональних класифікованих навантажень (NATO Secret і нижче). Національні МО експлуатують паралельні суверенні хмари — MODCloud у Великій Британії, BWI Bundeswehr-хмара в Німеччині, нідерландська CC-NDC, польська хмара МО — кожна акредитована до національного класифікованого рівня та інтегрована з протоколами обміну союзників.

Нижче цих сидить власне рівень повної ізоляції, для навантажень рівня TS/SCI. Архітектурний патерн ми покривали в air-gapped розгортанні для оборони. Релевантне тут: рішення про розміщення навантаження повинні явно включати цей рівень — переміщення навантаження з NATO Secret донизу до комерційної суверенної хмари рідкісне, але вгору — поширене, і архітектура має пережити цей перехід без перепроєктування.

5. Гібридний і on-prem базис

Суверенна хмара не завжди правильна відповідь. Базис on-prem приватної хмари — VMware vSphere, OpenStack або Kubernetes на bare-metal у акредитованому національному ЦОДі — все ще виграє у трьох сценаріях.

По-перше, для класифікованих або air-gapped навантажень, що не толерують жодних зовнішніх мережевих залежностей. Суверенні гіперскейлери пропонують відключені режими (Azure Stack Hub, AWS Outposts, Google Distributed Cloud Air-Gapped), але ціна, модель підтримки та обмеження операторського доступу часто повертають калькуляцію до приватної хмари.

По-друге, для стабільних навантажень, де амортизація capex б'є націнку гіперскейлера. Навантаження, що працює 24/7 з передбачуваним навантаженням п'ять років, — це найгірший економічний матч для будь-якої хмари, суверенної чи ні. Націнка гіперскейлера понад амортизоване bare-metal зазвичай 3–5x у річному обчисленні.

По-третє, для організацій, що вже експлуатують сертифіковані ЦОДи. Маргінальна вартість ще одного racka низька. Маргінальна вартість побудови експлуатаційної спроможності суверенної гіперскейлерної хмари висока. Для діючих ІТ-організацій МО розширення on-prem зазвичай дешевший шлях переходу.

Ключовий висновок: Питання розміщення рідко стоїть як «суверенна хмара чи ні». Це «який рівень суверенітету на навантаження і які переходи між рівнями потрібні?» Сучасне оборонне середовище запускає всі чотири — комерційну хмару для маркетингу, суверенну для CUI, національну хмару МО для обмеженого і вище, air-gapped приватну для секретного і вище — і архітектура живе в конекторах між ними. Див. повний гайд з оборонної кібербезпеки для оточуючого фреймворку контролів.

6. Рішення про розміщення навантажень

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

Некласифіковані, публічні (вебсайти, рекрутингові портали, публічні API) належать у комерційні гіперскейлерні регіони у вашій юрисдикції. Контролі суверенітету додають вартість і операційне тертя без пропорційної цінності.

Некласифіковані, внутрішні CUI (HR, фінанси, внутрішня колаборація) належать у суверенну хмару — Bleu/Delos/Azure Gov-класу — для юрисдикційного захисту персональних та оперативних даних, навіть якщо формальне класифіковане маркування не застосовується. Експозиція до CLOUD Act — контрольний фактор.

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

Secret і вище належать у air-gapped національну або альянсну інфраструктуру. Жодна комерційна хмарна акредитація не досягає цього рівня в 2026 році.

Вартість, яку команди закупівель недооцінюють у бюджеті, — це міждоменна передача: щоразу, коли дані перетинають рівні, потрібне cross-domain solution (однонапрямлений діод, гард із інспекцією контенту або акредитований cross-domain прилад). Вони повільні, дорогі і становлять операційне вузьке місце багаторівневих архітектур. Проєктування для мінімізації потрібних передач цінніше за оптимізацію всередині будь-якого окремого рівня.

7. Архітектурні патерни

Три патерни повторюються у добре спроєктованих оборонних середовищах.

Control plane у суверенній хмарі, data plane у місійній хмарі. Ідентичність, політика, моніторинг і CI/CD живуть у хмарі суверенного рівня, де операторський доступ та аудит щільні. Місійні навантаження — обробка сенсорів, C2-сервіси, геопросторова аналітика — працюють там, де вимагає затримка і класифікація, часто на edge або місійній хмарній інфраструктурі. Control plane керує mission plane через вузькі, аудовані інтерфейси. Це той самий поділ, який zero-trust для військових мереж формалізує на мережевому рівні.

Федерована ідентичність через рівні. Ідентичність має охоплювати все середовище — аналітику не повинно бути потрібно три окремі облікові записи для суверенної хмари, хмари МО і air-gapped анклаву. Федерована ідентичність із claims-based авторизацією, прив'язана до провайдера ідентичності у суверенній хмарі та спроєктована (через схвалені cross-domain механізми) у вищі класифіковані рівні, — стандартний патерн. Складна проблема — життєвий цикл облікових даних через air-gap.

Топологія регіонального розгортання. Суверенні хмарні регіони рідкісніші за комерційні. Багаторегіональне active-active розгортання, тривіальне у комерційному AWS, стає обережною дизайн-вправою у GovCloud (два регіони) або Bleu (спочатку один). Математика failure-domain змінюється: регіональна стійкість часто означає гібридну стійкість, із суверенно-хмарним primary, що відмовляє на on-prem secondary у тій самій юрисдикції. Див. мульти-хмарну оборонну стратегію для деталей патерна стійкості.

8. Vendor Lock-In і планування виходу

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

Пом'якшення має три шари.

Інфраструктурні абстракції. Terraform з провайдер-агностичними модулями або Crossplane поверх Kubernetes дозволяють артефакту розгортання пережити зміну провайдера. Складніша дисципліна — уникати провайдер-пропрієтарних сервісів там, де існує портативна альтернатива: використовувати керований Kubernetes (EKS, AKS, OVH Managed Kubernetes) замість провайдер-специфічного PaaS, S3-сумісне об'єктне сховище замість нативних blob API, PostgreSQL або відкриті движки даних замість провайдер-пропрієтарних БД. Вартість портативності реальна, але обмежена; вартість пізньої міграції — необмежена.

Тренування виходу. Вправа «вихід з GovCloud» — реальне табл-топ або пілотне перенесення некритичного навантаження з обраної суверенної хмари до іншого суверенного провайдера або на on-prem — конкретно виявляє вартість лок-іну. Оборонні організації мають проводити цю вправу щонайменше раз на два роки на основне навантаження. Вихід — задокументований migration runbook із оцінками часу й вартості, що живить реєстр ризиків закупівель та план BCP/DR.

Контрактні положення. Закупівлі мають вимагати machine-readable експорту даних у визначене вікно, прав IP на автоматизацію розгортання, відсутності націнки на egress для цілей виходу та умов transition assistance. Тут ITAR-free поставки ПЗ і мова про вихід провайдера сходяться: мета в обох випадках — зберегти суверенну опціональність незалежно від продовження співпраці будь-якого окремого іноземного постачальника.

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