Дата публікації:
Публікація:
Тема суверенітету даних більше не звучить як абстрактна політична дискусія. NIS2, DORA, посилений контроль за US CLOUD Act, вимоги європейських замовників до субпідрядників — усе це поступово перетворюється на конкретні пункти в технічних вимогах і тендерах. І саме тут бізнес, що працює з європейськими клієнтами або планує розміщувати інфраструктуру в ЄС, натикається на проблему, про яку рідко говорять прямо: європейські хмарні провайдери поки не відтворили глибину керованих сервісів AWS — і розрив цей не косметичний, а структурний.
Ми в Gart Solutions нещодавно провели галузевий аналіз та звели цей розрив у цифри й по сервісах. Нижче — головні висновки і, що важливіше, практичний вибір, який з них випливає для будь-якої компанії, що зважує переїзд із AWS на європейську інфраструктуру чи вихід на європейський ринок.
AWS у Франкфурті чи Дубліні — це той самий повний каталог із понад 200 керованих сервісів, що і в будь-якому іншому регіоні. У європейських IaaS-провайдерів картина зовсім інша:
| Провайдер | Глибина каталогу керованих сервісів |
|---|---|
| AWS (Франкфурт/Дублін) | 200+ |
| OVHcloud | ~45 (найглибший каталог серед EU-хмар) |
| Scaleway | ~30 (найбільш «розробницький» каталог) |
| Hetzner | ~8 (свідомо мінімальний IaaS) |
Важливе уточнення з аналізу: «керований сервіс» — це не VM із Docker-контейнером PostgreSQL усередині. Це сервіс, де провайдер сам відповідає за патчі, відмовостійкість, бекапи, масштабування та SLA. Більшість того, що називають «managed» на менших європейських платформах, насправді ближче до self-hosted з елементами автоматизації — а різниця в операційному навантаженні на команду величезна.
Бази даних: є RDS-рівень, немає Aurora-рівня
Керований PostgreSQL/MySQL — найбільший блокер міграції. Тут європейські хмари вже непогані: OVHcloud, Scaleway, Exoscale, IONOS і UpCloud (через Aiven) пропонують HA-кластери, PITR і пулінг з’єднань на рівні, близькому до AWS RDS. Але жоден провайдер не має аналога Aurora — розподіленого хмарно-нативного сховища зі справжнім scale-to-zero, миттєвим відновленням стану (Backtrack) і Global Database для крос-регіональної реплікації. Команди, що залежать від Aurora Serverless для непередбачуваного навантаження, сьогодні не мають шляху міграції в ЄС взагалі.
Kubernetes — найбільш конкурентна категорія
Тут розрив найменший: OVHcloud MKS, Scaleway Kapsule, Exoscale SKS, IONOS і UpCloud усі пропонують безкоштовний control plane та автоскейлінг. Слабке місце — спільні файлові системи (RWX-томи): там, де AWS EFS робить ReadWriteMany тривіальним, європейські провайдери або змушують переплачувати за надлишкове File Storage (мінімум 150 ГБ в OVHcloud), або вимагають ручного NFS.
Observability — найбільш системна прогалина
CloudWatch + X-Ray + OpenSearch — це один інтегрований рахунок без жодної інфраструктурної експлуатації. У ЄС немає жодного провайдера з порівнянним покриттям: OVHcloud дає логи (Graylog) без метрик, Scaleway дає метрики й логи без трейсингу, Exoscale — пошук без метрик. Розподілений трейсинг (аналог X-Ray) відсутній майже всюди. Команди без виділеної SRE-функції або тримають CloudWatch для EU-навантажень (що знецінює саму ідею суверенності), або експлуатують самостійно зібраний Prometheus/Grafana/Loki — і це стає постійним операційним тягарем.
Serverless/FaaS, messaging, MLOps — точкові прогалини
Із цього аналізу випливає не теоретична, а абсолютно практична розвилка для будь-якої компанії — української чи європейської, — що працює з регульованими клієнтами або просто хоче зменшити юридичну експозицію до US CLOUD Act.
Варіант 1. Залишитися на AWS/гіперскейлерах. Отримуєте повну глибину сервісів і нуль операційного навантаження на власну команду — але юридична експозиція до американського законодавства лишається, а шлях до сертифікацій типу SecNumCloud для AWS структурно неможливий. Для частини публічного сектору, фінансових установ і оборонних замовників у ЄС це вже не теоретичний ризик, а пряма умова контракту.
Варіант 2. Перейти на європейський IaaS і будувати керований шар самостійно. Технічно можливо: Patroni для HA Postgres, Knative для FaaS-сумісного шару, самостійний Prometheus/Grafana/Loki стек. Але це означає, що команда інженерів бере на себе ту експлуатаційну роботу, яку на AWS виконує сам провайдер — патчі, failover, моніторинг власного моніторингу. Для компаній без зрілої DevOps/SRE-практики це часто прихована вартість, яку недооцінюють на етапі планування міграції.
Варіант 3. Європейський IaaS + керований шар від системного інтегратора. SI чи MSP бере на себе експлуатацію бази даних, observability-стеку, FaaS-runtime та DR-оркестрації над сировинною інфраструктурою OVHcloud, Hetzner, Exoscale чи інших — і продає це як сервіс із SLA. Саме цю модель аналіз називає головною точкою зростання найближчих років: європейські провайдери самі не встигають інвестувати в глибину PaaS, тож розрив закривається не «знизу» (хмарами), а «згори» — інтеграторами, що добудовують операційний шар.
Для українських компаній ця розвилка має два додаткові вимірювання.
По-перше, попит з боку самих клієнтів. Українські продуктові компанії й аутсорсингові команди, що працюють із європейськими замовниками у фінтеху, healthtech чи держсекторі, дедалі частіше отримують вимоги щодо розміщення даних у ЄС і відповідності DORA/NIS2 — незалежно від того, де територіально працює сама команда розробки.
По-друге, інженерна можливість. Розрив у керованих сервісах — це попит на саме ту експертизу, якою традиційно сильна українська ІТ-індустрія: DevOps, SRE, побудова надійних self-managed Postgres/Kubernetes/observability-стеків. Якщо керований шар над європейським IaaS будуватимуть системні інтегратори, а не самі хмарні провайдери, — це конкретна ринкова ніша, у якій українські інженерні команди вже мають практичну перевагу.
Перш ніж приймати рішення про міграцію чи вихід на ринок ЄС, варто чесно відповісти на три питання:
Відповіді на ці питання різні для кожного бізнесу — але сам розрив у каталогах керованих сервісів більше не можна ігнорувати як «технічну деталь». Це питання, яке вже впливає на тендери, контракти з регульованими клієнтами та довгострокову архітектурну стратегію.
Стаття підготовлена на основі галузевого аналізу Федіра Компанійця (Gart Solutions) «The EU Cloud Managed Services Gap».
