Дані, AI і майбутнє хмари

Навіщо це

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

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

Передумови. Об’єктне сховище (модуль 6), керовані бази (модуль 7), інстанси й spot (модуль 4), вихідний трафік (модуль 5), моделі оплати й unit economics (модуль 13). Про GPU як пристрій і про навантаження AI на ОС див. курс ОС.

Озеро даних і сховище даних

Озеро даних (data lake) зберігає дані в сирому вигляді в об’єктному сховищі: файли Parquet, CSV, JSON, логи. Схему визначає той, хто читає («schema on read»), а обчислення відокремлено від зберігання: дані лежать у бакеті, запити виконує окремий рушій. Сховище даних (data warehouse) зберігає дані у власному оптимізованому форматі з наперед заданою схемою й дає швидкі SQL-запити та транзакційні гарантії.

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

Останні роки межу розмили. Відкриті табличні формати (Apache Iceberg, Delta Lake) додають до файлів в об’єктному сховищі транзакції й версії, а керовані сервіси читають їх напряму. Архітектуру «озеро плюс шар таблиць» називають lakehouse. Це відповідь на невдоволення обома крайнощами: озеро без порядку перетворюється на болото, а закрите сховище прив’язує до одного постачальника.

	AWS	Azure	GCP
Об’єктне сховище	S3	Blob Storage (ADLS Gen2)	Cloud Storage
Запити до файлів «на місці»	Athena	Fabric (SQL endpoint, Spark)	BigQuery (зовнішні таблиці, BigLake)
Сховище даних	Redshift	Fabric Warehouse, Synapse	BigQuery
Модель оплати запитів	за терабайт, прочитаний Athena, або за ємність	за ємність (Fabric capacity), яку можна зупиняти	за прочитані TiB або за слоти

Athena тарифікується за обсяг даних, які запит прочитав: $5 за ТБ станом на вересень 2026. BigQuery пропонує дві моделі: on-demand за обсяг прочитаних даних (близько $6.25 за TiB, перший TiB на місяць безкоштовний) і ємність у слотах (editions). Microsoft Fabric об’єднує зберігання (OneLake), Spark, SQL і Power BI під однією ємністю (SKU F2, F4 і так далі до F2048), і за неї платять за час роботи ємності, а не за окремі запити.

Із моделі оплати випливає головна поведінкова відмінність. У Athena й BigQuery on-demand кожен запит має ціну, тож проблемою стає поганий запит. У Fabric ви платите за ємність, тож проблемою стає чужий запит, що з’їв ваш ліміт. Приклад: таблиця 500 ГБ, 20 запитів на день протягом місяця, кожен читає всю таблицю. Це 600 повних читань, 300 ТБ, $1 500 в Athena. Той самий обсяг у Parquet із розбиттям за датою, коли запити читають 5 %: 15 ТБ, $75. Різниця в двадцять разів визначається форматом файлів, а не вибором провайдера.

resource "aws_s3_bucket" "athena_results" {
  bucket = "example-athena-results"
}

resource "aws_athena_workgroup" "analytics" {
  name = "analytics"

  configuration {
    enforce_workgroup_configuration = true

    # Запит, що намагається прочитати понад 1 ТБ, буде зупинено
    bytes_scanned_cutoff_per_query = 1099511627776

    result_configuration {
      output_location = "s3://${aws_s3_bucket.athena_results.bucket}/output/"
    }
  }
}

variable "fabric_admin_upn" {
  type        = string
  description = "UPN адміністратора ємності Fabric"
}

resource "azurerm_resource_group" "data" {
  name     = "rg-data"
  location = "westeurope"
}

resource "azurerm_fabric_capacity" "main" {
  name                   = "fabriccapacitydemo"
  resource_group_name    = azurerm_resource_group.data.name
  location               = azurerm_resource_group.data.location
  administration_members = [var.fabric_admin_upn]

  sku {
    name = "F2"
    tier = "Fabric"
  }
}

resource "google_bigquery_dataset" "analytics" {
  dataset_id  = "analytics"
  location    = "US"
  description = "Аналітичний набір даних"

  # Тимчасові таблиці зникають самі через 30 днів
  default_table_expiration_ms = 2592000000
}

Кожен блок ставить свій «запобіжник» вартості. В AWS це ліміт на прочитане одним запитом у робочій групі: провайдер зупинить запит, який спробує прочитати понад терабайт. В Azure запобіжником стає сама ємність F2: більше, ніж вона дає, ви не витратите, але запити сповільняться. У GCP аналогічний ліміт задається на рівні запиту (bq query --maximum_bytes_billed) або проєкту, тому в Terraform-блоці тут лише термін життя тимчасових таблиць.

Стабільне: розділення зберігання й обчислень, колонкові формати (Parquet), розбиття за ключем запитів, ціна за прочитане. Змінюється: назви й склад пакетів (Synapse поступово поступається Fabric), обсяг підтримки Iceberg у кожному рушії, конкретні тарифи.

GPU і їхній дефіцит

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

Наслідки видно в рахунку. У січні 2026 року AWS підняв ціни на Capacity Blocks for ML приблизно на 15 %, пояснивши це співвідношенням попиту й пропозиції, і за повідомленнями галузевих видань додав ще близько 20 % з 1 липня 2026. Це рідкісний випадок, коли список цін хмари зростає, а не падає, і ілюстрація того, що GPU-ємність є ринком із дефіцитом, а не комунальною послугою.

Практика роботи з дефіцитом складається з кількох звичок.

Квоти й запити на них. Для GPU-інстансів початкова квота часто нульова. Запит на її збільшення варто подавати за тижні до потреби, у кількох регіонах.
Capacity Blocks та резервування ємності. Ви бронюєте певну кількість GPU на визначений час за наперед відомою ціною. AWS називає це Capacity Blocks for ML, Azure і Google Cloud мають власні механізми резервування GPU-ємності. Ціна такого бронювання динамічна.
Spot для навчання, а не для обслуговування. Навчання з контрольними точками витримує переривання (модуль 4); обслуговування користувачів на spot-GPU нестабільне.
Гнучкість щодо регіону й типу. Модель, яка вміщається на менші GPU, знаходить ємність легше, ніж та, що вимагає новітніх.

Стабільне: що GPU є обмеженим ресурсом, який треба планувати, і що використання GPU визначає вартість. Змінюється: покоління чіпів, ціни, наявність у регіонах, спеціалізовані прискорювачі (власні чіпи провайдерів: AWS Trainium і Inferentia, Google TPU, Microsoft Maia). Конкретну модель GPU обирайте за поточними прайсами, а не за цим модулем.

Керовані LLM-платформи

Більшість команд не тренує моделі, а викликає їх. Три провайдери пропонують платформу, яка дає доступ до кількох моделей одним API, разом із контролем доступу, журналуванням, фільтрами вмісту й приватним мережевим доступом.

	AWS	Azure	GCP
Платформа	Amazon Bedrock	Microsoft Foundry (до листопада 2025 — Azure AI Foundry)	Gemini Enterprise Agent Platform (до квітня 2026 — Vertex AI)
Моделі	кілька виробників: Anthropic, Meta, Mistral, Amazon та інші	моделі OpenAI та інших виробників	Gemini, моделі партнерів, відкриті моделі (Model Garden)
Оплата	за токени, пакетна обробка дешевше, гарантована пропускна здатність за зобов’язання	за токени або за виділену пропускну здатність	за токени, за виділену пропускну здатність

Назви в цій таблиці — головний приклад того, що «змінюється за рік». Microsoft перейменувала Azure AI Foundry на Microsoft Foundry на конференції Ignite у листопаді 2025 року (платформа мала три назви за два роки: Azure AI Studio, Azure AI Foundry, Microsoft Foundry). Google Cloud у квітні 2026 року об’єднав Vertex AI з іншими продуктами під назвою Gemini Enterprise Agent Platform; SDK і команди на кшталт gcloud ai за документацією лишилися незмінними. Amazon Bedrock лишається під тією самою назвою.

Практичний висновок: пишіть код проти шару абстракції власного застосунку (сервіс моделей, що ховає конкретного провайдера), а не розкидайте виклики SDK по коду. Це не про «прив’язку до постачальника» в загальному сенсі, а про дуже конкретну вимогу: назва платформи, версія моделі й ціна змінюються частіше, ніж змінюється ваш продукт.

aws bedrock list-foundation-models \
  --by-provider "Anthropic" \
  --by-output-modality TEXT \
  --query 'modelSummaries[].modelId' \
  --output text

Перелік моделей, доступних вашому акаунту в поточному регіоні. Доступ до кожної моделі окремо вмикається в консолі Bedrock.

az cognitiveservices model list -l swedencentral \
  --query '[].model.name' -o tsv | sort -u | head -20

Перелік моделей, доступних у регіоні. Розгортання конкретної моделі створюється окремою командою в ресурсі Foundry і має власну квоту.

gcloud ai model-garden models list --model-filter=gemma --limit=10

Моделі каталогу Model Garden за фільтром. Команда може мати статус alpha або beta.

Вартість інференсу: токени чи власні GPU

Інференс (inference) називають виконання вже навченої моделі. Керована платформа бере плату за токени: окремо за вхідні й вихідні, зазвичай за мільйон. Власні GPU коштують за час, поки вузол увімкнений, незалежно від того, чи хтось ним користується. Звідси ключова змінна: завантаження.

Навчальна модель із припущеннями. Вузол із GPU коштує $4 за годину. Він видає 2 000 токенів на секунду під повним навантаженням, тобто 7.2 млн токенів на годину. Ціна мільйона токенів на власному вузлі дорівнює $4 / 7.2 = $0.56 за 100 % завантаження й зростає обернено пропорційно до завантаження. API коштує $1 за мільйон токенів у середньому за вхідні й вихідні. Усі три числа умовні: реальні ціни різняться на порядок між моделями й змінюються, тож підставте свої.

Ціна мільйона токенів на власному вузлі за різного завантаження проти умовного API за $1. Виділено варіанти, де власний вузол дешевший.

Точка беззбитковості лежить на 56 % завантаження. Нижче за неї API дешевший, вище власний вузол. Реальний вибір складніший з кількох причин.

Відмовостійкість подвоює вузол. Один GPU-вузол є єдиною точкою відмови, а за логікою модуля 13 для HA потрібно щонайменше два. Тоді $5 840 на місяць за два вузли треба порівнювати з $5 840, які API взяв би за 5.84 млрд токенів, тобто в середньому близько 2 200 токенів на секунду цілодобово.
Навантаження рідко буває рівним. Пік удень, тиша вночі: реальне середнє завантаження власного вузла зазвичай далеко від 100 %, а вночі вузол коштує стільки ж.
Людські витрати. Хтось має підтримувати рушій обслуговування моделі, оновлювати версії, налаштовувати пакетування запитів і стежити за пам’яттю GPU.
Якість моделі. Відкриті моделі, які можна запустити самому, і закриті моделі провайдерів не є еквівалентними за якістю, тож порівнювати ціну за токен треба на одному завданні.

Тому типова траєкторія така: починають із API, бо це дешево при малому обсязі й без операційних витрат. Власні GPU розглядають, коли обсяг стабільно високий, навантаження рівне, а дані не можна відправляти назовні. Проміжний варіант: зарезервована пропускна здатність на керованій платформі (Bedrock Provisioned Throughput, виділена ємність у Foundry і Vertex) дає передбачувану ціну без власної експлуатації, хоча й потребує зобов’язання.

Стабільне: формула «ціна = вартість вузла / (пропускна здатність × завантаження)», важливість пакетування запитів, відмінність між ціною вхідних і вихідних токенів. Змінюється: ціни на токени (вони падали швидше за будь-яку інфраструктурну ціну), швидкість чіпів, список доступних моделей.

RAG як архітектурний шаблон

Мовна модель знає лише те, на чому вчилася, і не знає ваших документів. Є два способи це виправити: донавчити модель (дорого, повільно, знання застаріває) або передати потрібні документи прямо в запит. Другий спосіб називають RAG (retrieval-augmented generation): генерацією, доповненою пошуком.

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

Перший потік готує знання. Документи розбивають на фрагменти (chunks), кожен перетворює ембединг-модель на вектор, тобто набір чисел, у якому близькі за змістом тексти лежать поруч, і зберігають у векторному індексі. Другий потік працює на кожен запит: запит теж перетворюється на вектор, індекс повертає найближчі фрагменти, вони разом із запитом складають промпт, і модель відповідає, спираючись на них.

Це архітектурний шаблон, а не продукт, тому його складники беруться з різних сервісів.

Складник	AWS	Azure	GCP
Векторне сховище	OpenSearch, Aurora PostgreSQL з pgvector, Bedrock Knowledge Bases	Azure AI Search, PostgreSQL з pgvector, Cosmos DB	Vertex AI Vector Search, AlloyDB і Cloud SQL з pgvector
Ембединги й генерація	моделі в Bedrock	моделі у Foundry	моделі в Model Garden
Готовий керований RAG	Bedrock Knowledge Bases	Foundry (пошук по даних)	Gemini Enterprise Agent Platform (Agent Builder)

Найбільші ризики RAG лежать не в моделі. Розбиття на фрагменти: надто дрібні втрачають контекст, надто великі розмивають пошук. Доступ: якщо індекс містить документи з різним рівнем доступу, пошук має фільтрувати за правами користувача, інакше модель розкаже все кожному (модуль 12). Свіжість: індекс треба оновлювати, тож у RAG є конвеєр даних із власною вартістю. Вартість запиту: кожен додатковий фрагмент у промпті збільшує кількість вхідних токенів, тобто ціну.

Стабільне: сама схема «знайти, потім згенерувати», вимоги до прав доступу, вартість вхідних токенів. Змінюється: назви керованих сервісів, розмір контекстного вікна моделей (що робить простіші схеми можливими), а разом з ним і мода на складніші схеми пошуку.

Суверенні хмари

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

AWS European Sovereign Cloud запущено: загальну доступність оголошено 15 січня 2026 року, перший регіон у Бранденбурзі (Німеччина). За заявою AWS, це фізично й логічно відокремлена інфраструктура повністю в ЄС, з незалежними кореневими сертифікатами, власною мережею й власним центром безпеки; на старті було доступно близько 90 сервісів. AWS планує вкласти понад €7,8 млрд і розширити присутність суверенними Local Zones у Бельгії, Нідерландах і Португалії. Microsoft і Google обрали інший шлях: партнерські моделі, в яких технологію експлуатує європейська компанія (Delos Cloud у Німеччині, S3NS у Франції, яку контролює Thales).

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

Стабільне: що вимоги до місця зберігання даних і юрисдикції існують незалежно від технологій (модуль 1), і що суверенність є вибором за ціною. Змінюється: список регіонів і сервісів у суверенних пропозиціях, юридичні рамки (регулювання ЄС розвивається), моделі партнерства.

Multi-cloud без ілюзій

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

Реальні причини: вимоги регулятора чи замовника, злиття компаній із різними хмарами, унікальний сервіс (наприклад, конкретні моделі чи TPU), що є лише в однієї хмари, переговорна позиція при великих контрактах.

Ілюзії: «ми легко переїдемо». Прив’язка до постачальника лежить не в обчисленнях, а в даних і в керованих сервісах. Ваші дані мають вагу: перенести 100 ТБ з us-east-1 в інтернет за звичайним тарифом коштує близько $8 000 (перші 10 ТБ по $0.09 за ГБ, далі дешевше сходинками), і це без часу й ризику. На початку 2024 року всі три провайдери, зважаючи на Data Act ЄС, пообіцяли не брати плати за вихідний трафік, якщо клієнт повністю йде з хмари: за заявкою, з погодженням і з обмеженим строком на переїзд. Для multi-cloud це нічого не змінює: постійний обмін даними між двома живими хмарами оплачується щомісяця за повним тарифом. Kubernetes переносить контейнери, але не переносить балансувальник, IAM, бази й черги, з яких складається система. Переносимий «найменший спільний знаменник» відмовляється від сильних сторін кожної хмари, тобто ви платите за складність і не отримуєте переваг.

Multi-cloud подвоює навчання команди, IAM, спостережуваність і мережеві схеми, тож перед рішенням варто порахувати ці витрати так само, як у модулі 13 рахували другий регіон. Розумніший початок: переносимість там, де вона дешева (контейнери, Terraform, OpenTelemetry, відкриті формати даних) і свідома прив’язка там, де вона дає вигоду (керована база, черга). Питання, чи виживе бізнес, коли зникне один регіон, вирішує multi-region, а не multi-cloud.

Різницю між прив’язкою й репатріацією докладно розібрано в модулі 1.

Platform engineering

Що більше сервісів у хмарі, то більше кожна команда має вчити й налаштовувати: мережі, IAM, Terraform-модулі, конвеєри, спостережуваність. Platform engineering називають підхід, за якого спеціальна команда будує внутрішню платформу розробника (internal developer platform): набір готових, безпечних і задокументованих способів виконати типові задачі. Розробник створює новий сервіс за шаблоном, який уже містить мережу, ролі за принципом найменших привілеїв, конвеєр, дашборд і теги для розподілу витрат.

Такі шаблони називають золотими шляхами (golden paths). Вони не забороняють інших шляхів, а роблять правильний шлях найлегшим. Інструменти різні: портали на зразок Backstage, модулі Terraform (модуль 10), Kubernetes-оператори. Ключова ідея не в інструменті, а в підході: платформа є продуктом з користувачами (розробниками), метриками (час до першого розгортання) і власною дорожньою картою.

Зв’язок із цим курсом пряма. Усе, що ви вивчили, від тегів (модуль 2) до федерації CI (модуль 3, модуль 10) і бюджетів (модуль 13), у зрілій організації вбудовано в золотий шлях, щоб не покладатися на пам’ять кожного інженера.

Стабільне: потреба знижувати когнітивне навантаження, підхід «платформа як продукт». Змінюється: конкретні інструменти порталів і їхня популярність.

Що стабільне, а що зміниться за рік

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

Тема	Стабільне (механізм)	Зміниться (перевіряйте)
Дані	озеро й сховище, колонкові формати, ціна за прочитане	назви пакетів (Synapse, Fabric), підтримка Iceberg, тарифи
GPU	дефіцит, планування ємності, квоти	покоління чіпів, ціни, наявність
LLM-платформи	єдиний API до кількох моделей, оплата токенами	назви (Foundry, Agent Platform), моделі, ціни
Інференс	формула ціни через завантаження	ціни на токени, швидкість чіпів
RAG	схема «знайти, потім згенерувати», права доступу	керовані сервіси, розміри контексту
Суверенність	юрисдикція існує незалежно від технологій	регіони, партнери, регулювання
Multi-cloud	вага даних, ціна складності	умови виходу, ціни на вихідний трафік
Платформи	платформа як продукт	інструменти порталів

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

Розбір: власні GPU чи API

Команда будує внутрішнього асистента, який відповідає на питання по документації компанії. Обсяг на старті невеликий, але зростає, і фінансовий директор питає, чи не купити власні GPU.

Крок 1. Порахувати обсяг. За даними логів: 40 000 запитів на день, у кожному близько 3 000 вхідних токенів (запит і знайдені фрагменти, RAG) і 300 вихідних. Це приблизно 3.3 тис. × 40 000 ≈ 132 млн токенів на день, або близько 4 млрд на місяць.

Крок 2. Порівняти за моделлю розділу вище. API за $1 за мільйон дасть близько $4 000 на місяць. Два вузли для HA коштують $5 840, а їхня пропускна здатність (10.5 млрд токенів на місяць при 100 %) використана на 38 %. Власні GPU програють: нижче точки беззбитковості в 56 %.

Крок 3. Врахувати неочевидне. Найбільша складова тут вхідні токени RAG. Скорочення кількості фрагментів у промпті з десяти до шести зменшує рахунок API приблизно на третину, тоді як GPU від цього не дешевшають. Пакетний режим (дешевший приблизно вдвічі, якщо відповіді не потрібні миттєво) підходить для нічного індексування.

Рішення. Лишитися на API, оптимізувати промпт і розглянути власні GPU знову, коли обсяг зросте втричі або з’являться вимоги до локальності даних. Пропозицію записують разом з умовою, за якої її буде переглянуто.

Типові помилки розуміння

«Озеро даних — це просто дешеве сховище». Без формату, розбиття й каталогу озеро перетворюється на болото, а запити коштують дорого, бо читають усе.
«RAG навчає модель нашим документам». Модель не змінюється: документи тимчасово передаються в промпті на кожен запит, тому права доступу й вартість вхідних токенів визначають усе.
«Власні GPU дешевші за API». Лише за високого й рівного завантаження, з урахуванням резервування й людей. Нижче точки беззбитковості вони програють.
«Multi-cloud позбавляє прив’язки». Прив’язка лежить у даних і керованих сервісах, а не в обчисленнях, тож multi-cloud вирішує інше питання, ніж multi-region.
«Суверенна хмара — це просто регіон в ЄС». Вона відрізняється операціями, персоналом і юридичною структурою, і за це беруть премію.
«Назву сервісу можна вивчити раз». Платформи LLM змінили назви двічі за два роки. Вивчайте механізм, а назву перевіряйте.

Перевір себе

1. Таблиця 500 ГБ у CSV, запити читають усі колонки й рядки. В Athena кожен запит коштує $2.50. Що найефективніше знизить рахунок?Перейти на більший регіонПеретворити дані на Parquet із розбиттям за датою, щоб запити читали лише потрібнеЗбільшити кількість запитів на деньВимкнути шифрування

2. Модель обслуговується на власному GPU-вузлі за $4 на годину; при 100 % завантаження мільйон токенів коштує $0.56. API коштує $1 за мільйон. За якого завантаження вузла обидва варіанти коштують однаково?Близько 20 %Близько 35 %Близько 75 %Близько 56 %

3. Чому в оцінці власного інференсу потрібно рахувати щонайменше два GPU-вузли, а не один?Один вузол не вміщає жодної моделіПровайдери не продають один вузолОдин вузол є єдиною точкою відмови, а HA потребує другого, і його ціна входить у порівнянняДва вузли дешевші за один

4. Асистент на основі RAG показав співробітнику фрагмент документа, до якого той не має доступу. Де, найімовірніше, помилка?Векторний індекс містить усі документи, а пошук не фільтрує результати за правами користувачаМодель донавчили на закритих документахЕмбединг-модель занадто великаУ промпті надто мало токенів

5. Що змінилося з назвою Vertex AI станом на 2026 рік?Нічого, Vertex AI лишається основною назвоюСервіс закритоЙого об’єднано з іншими продуктами під назвою Gemini Enterprise Agent Platform, а SDK й команди gcloud ai за документацією лишилисяЙого перейменовано на Foundry

6. Компанія хоче «уникнути прив’язки до постачальника» й розгортає однакову систему в AWS і Azure. Що вона, найімовірніше, отримає?Повну переносимість без додаткових витратЗнижку від обох провайдерівАвтоматичну відмовостійкість вищу за multi-regionПодвоєння інфраструктури, навчання команди й IAM, а прив’язка лишиться в даних і керованих сервісах

7. Чим золотий шлях у platform engineering відрізняється від заборони інших способів створювати сервіси?Він робить правильний спосіб найлегшим, не забороняючи іншихВін усуває потребу в TerraformВін автоматично зменшує рахунокВін замінює команду інфраструктури