Керовані бази даних

Навіщо це

Базу даних можна поставити на віртуальну машину самому: apt install postgresql і працює. Далі починається робота, яка не кінчається: оновлення й патчі, резервні копії та їх перевірка, реплікація, перемикання при відмові, місце на диску, налаштування пам’яті. У керованої бази (managed database) цю роботу виконує провайдер, а ви платите за це надбавкою до ціни машини.

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

Другий вибір стосується самої моделі. Реляційна база оплачується розміром машини й диска, і її розмір ви обираєте наперед. NoSQL-сервіси оплачуються за запити, і одиниця запиту в кожного провайдера своя: read request unit у DynamoDB, Request Unit у Cosmos DB, операція з документом у Firestore. Одне й те саме навантаження за різними схемами оплати коштує в рази по-різному, і нижче це пораховано.

Передумови. Регіони й зони доступності (availability zones, модуль 1), бюджети (модуль 2), ролі й секрети (модуль 3), мережа й приватні ендпоінти (модуль 5), диски й знімки (модуль 6). Як база даних влаштована всередині (журнал, транзакції, індекси), розглядає курс баз даних; тут це вважається відомим. Диски, на яких вона лежить, і їхні IOPS описано в курсі ОС.

Що бере на себе провайдер, а що лишається вам

Модель спільної відповідальності (shared responsibility model) з модуля 1 для бази даних має конкретний вигляд.

Три варіанти однієї бази. Провайдер забирає нижні шари, а схема, запити, доступ і перевірка відновлення лишаються вашими в усіх трьох. У serverless NoSQL у режимі provisioned розмір і ємність теж ваші.

Провайдер керованої реляційної бази бере на себе такі речі:

обладнання, віртуальну машину й операційну систему, доступу до яких у вас немає: підключитися по SSH до хоста RDS не можна;
установлення рушія і мінорні оновлення у вікні обслуговування (maintenance window). Azure, наприклад, виконує патчі й мінорні оновлення саме в такому вікні, а якщо його не задати, призначає одну годину між 23:00 і 07:00 за місцевим часом;
виконання бекапів за розкладом і безперервну доставку журналу транзакцій;
перемикання на резервний вузол, якщо основний вийшов з ладу: адреса сервера лишається тією самою, а провайдер міняє DNS-запис на нового основного.

Ви залишаєтеся відповідальним за таке:

Схема, індекси й запити. Повільний запит не стає швидшим тому, що база керована.
Розмір. Клас інстансу й обсяг диска обираєте ви, а масштабування вгору й вниз зазвичай означає перезапуск або перемикання.
Мажорні версії. Піднімати PostgreSQL із 16 до 17 ви вирішуєте й перевіряєте самі, а провайдер лише дає інструмент.
Строк зберігання бекапів. Це параметр, який ви ставите і за який платите. Знайти помилку через три доби, маючи бекапи на одну добу, не вдасться.
Відновлення. Провайдер гарантує, що бекап є, і не гарантує, що ви вмієте з нього відновитися й що відновлена база запуститься з вашим застосунком.
Доступ. Хто може підключитися, з якої мережі, з якими правами й секретами (модуль 3, модуль 12).
Захист від видалення. Про нього далі окремо: його не вмикає ніхто, крім вас.

Що ви втрачаєте: доступ до операційної системи, права суперкористувача на рівні сервера й частину розширень і налаштувань, які провайдер не підтримує. Якщо без цього не обійтися, лишається база на власній машині або варіанти на кшталт RDS Custom.

Реляційні бази: від «PostgreSQL на диску» до розподіленого SQL

Три провайдери пропонують реляційні бази на трьох рівнях.

Класична керована база. Рушій (PostgreSQL, MySQL, SQL Server та інші) працює на віртуальній машині, а дані лежать на прив’язаному диску. Це Amazon RDS, Azure Database for PostgreSQL і MySQL, Azure SQL Database, Cloud SQL. Вертикально масштабується кожна, а горизонтально лише читанням: через репліки.

База з відокремленим сховищем. Провайдер переробив шар зберігання так, що обчислення й дані масштабуються окремо. Amazon Aurora зберігає дані в кластерному томі, копії якого лежать у трьох зонах доступності, і кількість копій не залежить від кількості інстансів. Нові репліки не копіюють таблиці, а підключаються до готового тому. Google Cloud AlloyDB робить схожу річ для PostgreSQL. Azure має Hyperscale у складі Azure SQL Database. У Aurora є два варіанти оплати сховища: Standard з платою за мільйон I/O-запитів і I/O-Optimized без неї, який AWS радить, коли I/O складає 25% і більше витрат на Aurora.

Aurora Serverless v2 вміє масштабуватися до нуля одиниць ємності (ACU) і автоматично призупинятися без активності. Під час паузи ви не платите за обчислення, а лише за сховище, і першому підключенню доводиться чекати відновлення до 15 секунд. Для середовищ розробки й тестів це помітна економія.

Розподілений SQL. База масштабується горизонтально, у тому числі на запис, і зберігає транзакції та SQL. Google Cloud Spanner розподіляє дані по вузлах і регіонах із суворою консистентністю; ємність у ньому вимірюється вузлами й частками вузла (100 processing units становлять десяту частину вузла). Amazon Aurora DSQL, що вийшов у загальний доступ у травні 2025 року, пропонує активно-активну (active-active) архітектуру, розраховану на доступність 99.99% в одному регіоні і 99.999% у кількох. Таку базу обирають, коли одного вузла або однієї зони для запису вже недостатньо, і сплачують складнішою моделлю цін і відмінностями від «звичайного» PostgreSQL.

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

Репліки, резервний вузол, бекапи і PITR

Три механізми, які часто плутають, вирішують три різні задачі.

Резервний вузол дає перемикання при відмові, репліка розвантажує читання, а лише бекап із журналом повертає дані після помилкової команди.

Резервний вузол (standby) відповідає за доступність. Основна база синхронно передає кожну зміну на вузол в іншій зоні й підтверджує транзакцію лише після того, як вузол її зберіг. Тому втрати даних при відмові немає, а записи стають трохи повільнішими через додатковий обмін. Якщо основний вузол відмовляє, резервний стає основним; у Cloud SQL перемикання займає близько хвилини, в Azure Database for PostgreSQL 60–120 секунд. В Amazon RDS у варіанті Multi-AZ DB instance резервний вузол читати не можна: документація прямо називає його не засобом масштабування читання. Читання розвантажують реплікою або варіантом Multi-AZ DB cluster із двома резервними вузлами, які приймають читання.

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

Резервна копія (backup) відповідає за повернення в минуле. Механізм у трьох провайдерів однаковий: періодичний знімок (повний або диференційний) плюс безперервний журнал транзакцій. Разом вони дають відновлення на момент часу (point-in-time recovery, PITR): ви називаєте час, а сервіс відтворює базу з останнього знімка й проганяє журнал до цієї миті.

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

Ключова властивість, яку варто запам’ятати: PITR завжди створює нову базу. У всіх трьох провайдерів відновлення ніколи не перезаписує наявну базу. Ви отримуєте новий інстанс зі старим станом, вибираєте з нього потрібні дані (наприклад, видалену таблицю) і переносите в основну базу, або перемикаєте застосунок на нову. Це безпечно, але повільно: час відновлення залежить від розміру бази й обсягу журналу, а нова база спочатку може працювати повільніше, доки підвантажуються блоки.

Цифри провайдерів:

	AWS RDS	Azure SQL Database / PostgreSQL	Cloud SQL
Як часто журнал	завантажується в S3 кожні 5 хвилин	журнал транзакцій приблизно кожні 10 хвилин (SQL Database)	у перевіреній документації не вказано
Вікно PITR	до 35 діб	SQL Database: 7 діб за замовчуванням, 1–35 діб; PostgreSQL flexible: 7–35 діб	1–7 діб журналу (`transaction_log_retention_days`)
Результат	нова база	нова база	нова база (клон)
Довготривале зберігання	знімки й AWS Backup	LTR до 10 років	резервні копії за кількістю чи строком

Два способи втратити дані попри бекапи й репліки:

Видалення інстансу. В Amazon RDS автоматичні бекапи прив’язані до інстансу. Якщо видалити його без опції «зберегти автоматичні бекапи», вони зникнуть разом з ним, а лишаться тільки ручні знімки та фінальний знімок, якщо ви його зробили. В Azure SQL Database, навпаки, бекапи зберігаються за строком утримання й після видалення бази, тому її можна відновити. Різниця між провайдерами велика, і на неї варто перевіряти власні процедури.
Реплікація помилки. Резервний вузол і репліка отримують DROP TABLE так само, як усе інше. Документація Azure прямо радить у такому випадку відновлюватися з бекапу, а не з резервного вузла.

Захистом стають захист від видалення (deletion_protection в RDS і Cloud SQL, блокування ресурсів в Azure), фінальний знімок, копія бекапів в інший акаунт чи регіон і, найважливіше, регулярне репетиційне відновлення.

NoSQL: ключ замість запитів

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

Ключ-значення й документи. Amazon DynamoDB, Azure Cosmos DB (API для NoSQL, MongoDB та інші), Google Cloud Firestore. Запис знаходять за ключем розділу (partition key). Запити по інших полях доступні через вторинні індекси, а операцій на кшталт JOIN немає.
Широкі колонки. Google Cloud Bigtable зберігає дані як розріджену таблицю з ключем рядка й вузлами кластера як одиницею потужності. Її використовують для великих потоків часових рядів і подій.

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

NoSQL масштабується горизонтально й вимагає менше адміністрування. Ціна за це полягає в необхідності наперед знати запити: змінити спосіб доступу після виходу в продукцію означає міграцію даних.

Консистентність тут теж вибір, і вона коштує:

DynamoDB за замовчуванням читає з кінцевою консистентністю. Сильно консистентне читання (strongly consistent) коштує вдвічі більше: один read request unit покриває одне сильно консистентне читання елемента до 4 КБ або два кінцево консистентні.
Cosmos DB має п’ять рівнів: Strong, Bounded staleness, Session, Consistent prefix, Eventual. Найуживаніший Session. Читання на рівнях Strong і Bounded staleness споживають приблизно вдвічі більше Request Units, ніж на слабших, бо звертаються до двох реплік замість однієї. Рівень Strong також збільшує затримку запису на кількох регіонах.
Firestore дає сильну консистентність.

Як NoSQL оплачується: on-demand, provisioned і Request Unit

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

On-demand (за запит). Ви платите за кожну операцію і нічого, коли трафіку немає. DynamoDB в цьому режимі бере $0.125 за мільйон одиниць читання (read request unit, RRU) і $0.625 за мільйон одиниць запису (WRU). Одна WRU відповідає запису одного елемента до 1 КБ, а одна RRU сильно консистентному читанню до 4 КБ. Обмеження такі: нова on-demand таблиця спершу витримує до 4000 записів і 12 000 читань за секунду, миттєво приймає трафік до двократного попереднього піку, а різкіше зростання за 30 хвилин може дати затримки й відмови через тротлінг. Cosmos DB у режимі serverless бере $0.25 за мільйон одиниць запиту (RU), а Firestore $0.30 за мільйон прочитаних і $0.90 за мільйон записаних документів.

Provisioned (замовлена ємність). Ви заздалегідь замовляєте пропускну здатність і платите за неї щогодини, незалежно від використання. У DynamoDB одиниця запису (WCU) коштує $0.00065 за годину, тобто $0.4745 на місяць, а одиниця читання (RCU) $0.00013 за годину, тобто $0.0949 на місяць. У Cosmos DB 100 RU/s коштують $0.008 за годину ($5.84 на місяць), мінімум для контейнера становить 400 RU/s, тобто $23.36 на місяць. Режим autoscale дозволяє задати максимум, а його тариф становить $0.012 за годину за 100 RU/s.

Request Unit у Cosmos DB. Одиниця запиту є нормалізованою «валютою», у якій вимірюється будь-яка операція: читання елемента за ключем розміром близько 1 КБ коштує 1 RU. Складніший запит, більший елемент, більше індексованих полів і суворіший рівень консистентності дають більше RU. Тому точну ціну операції не рахують, а вимірюють: SDK повертає її в заголовку відповіді про плату за запит.

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

Одиниця	Замовлена, $ на місяць	Така сама кількість запитів «за запит», $ на місяць	Поріг окупності
DynamoDB, 1 WCU (1 запис на секунду)	0.4745	1.6425	близько 29% завантаження
DynamoDB, 1 RCU (1 читання на секунду)	0.0949	0.3285	близько 29% завантаження
Cosmos DB, 100 RU/s	5.84	65.70	близько 9% завантаження

Розрахунок для DynamoDB: 1 запис на секунду цілодобово дає 2 628 000 записів на місяць, і в режимі on-demand вони коштують 2.628 × $0.625 = $1.64. Отже, для стабільного трафіку замовлена ємність дешевша в 3–11 разів, а on-demand виграє, коли трафік рідкісний, стрибкоподібний або невідомий. Режими можна перемикати: DynamoDB дозволяє переходити з provisioned на on-demand до чотирьох разів за добу (за ковзним вікном), а назад у будь-який момент. Тому типовий шлях такий: почати з on-demand, поспостерігати реальне навантаження і перейти на замовлену ємність із autoscaling, коли профіль стабілізується.

Кеші

Кеш зберігає результати дорогих запитів у пам’яті, щоб не ходити в базу щоразу. Типовий шаблон називається cache-aside: застосунок питає кеш, а якщо там порожньо, читає з бази й кладе результат у кеш зі строком життя (TTL). Кеш не є джерелом істини, тому втрата його вмісту повинна лише уповільнити систему, а не зламати її.

Сервіси однакові за суттю й мають різну долю:

Amazon ElastiCache працює з Valkey, Redis OSS і Memcached. Valkey є форком Redis OSS, який підтримує Linux Foundation: він з’явився після того, як Redis змінив ліцензію. У ElastiCache для Valkey вузли коштують на 20% менше, а serverless-варіант на 33% менше, ніж для інших рушіїв, і AWS дозволяє оновити наявний кластер із Redis OSS на Valkey без простою.
Azure Cache for Redis замінюють. Рівні Basic, Standard і Premium виводяться з експлуатації 30 вересня 2028 року (з 1 жовтня їхні інстанси вимикаються), а Enterprise і Enterprise Flash 31 березня 2027. Наступник називається Azure Managed Redis. Він побудований на програмному забезпеченні Redis Enterprise, за замовчуванням працює як кластер, за замовчуванням зональностійкий і має рівні Memory Optimized, Balanced, Compute Optimized і Flash Optimized. Для клієнтів це означає зміну адреси й ключа, а також перевірку сумісності з кластерним режимом, зокрема команд, що зачіпають кілька слотів.
Google Cloud Memorystore пропонує Valkey, Redis Cluster, окремий Redis і Memcached. Memorystore for Valkey і Redis Cluster мають SLA 99.99%, а для окремих версій Redis Google публікує дати завершення підтримки.

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

Як це в трьох хмарах

Функція	AWS	Azure	GCP
Керована реляційна база	RDS (PostgreSQL, MySQL, SQL Server та інші)	Azure Database for PostgreSQL, MySQL; Azure SQL Database	Cloud SQL
З відокремленим сховищем	Aurora	Azure SQL Hyperscale	AlloyDB
Розподілений SQL	Aurora DSQL	прямого аналога немає	Spanner
Ключ-значення й документи	DynamoDB	Cosmos DB	Firestore
Широка колонка	немає окремого сервісу (Keyspaces для сумісності з Cassandra)	Cosmos DB for Apache Cassandra	Bigtable
Кеш	ElastiCache (Valkey, Redis OSS, Memcached)	Azure Managed Redis	Memorystore (Valkey, Redis Cluster)
Резервний вузол	Multi-AZ	zone-redundant HA	REGIONAL (`availability_type`)
PITR	RDS до 35 діб; DynamoDB до 35 діб	SQL Database 1–35 діб; Cosmos DB 7 або 30 діб	Cloud SQL до 7 діб журналу; Firestore 7 діб
Модель оплати NoSQL	on-demand або provisioned (WCU і RCU)	serverless, provisioned, autoscale (RU)	за операцію з документом

Чим відрізняється і що з цього випливає.

Різні одиниці для схожих речей. Одна й та сама операція читання вимірюється в RRU (DynamoDB, 4 КБ), у RU (Cosmos DB, 1 КБ за цінову одиницю) і в документах (Firestore). Порівнювати «ціну за мільйон» без вимірювання на своїх елементах безглуздо.
Cosmos DB закладає багаторегіональність у цінову модель. Замовлені RU доступні в кожному регіоні акаунта, тобто ціна множиться на кількість регіонів. Додати другий регіон означає подвоєння рахунку за пропускну здатність.
Aurora і AlloyDB продають «сховище окремо». Це відрізняє їх від RDS і Cloud SQL, де диск прив’язаний до інстансу. Зміна кількості реплік не копіює дані.
Бекапи поводяться по-різному після видалення. RDS прибирає автоматичні бекапи разом з інстансом, Azure SQL Database зберігає їх за строком. Перевіряйте це для того сервісу, який ви використовуєте.

Керована PostgreSQL із резервним вузлом і бекапами

resource "aws_db_instance" "app" {
  identifier                  = "app-db"
  engine                      = "postgres"
  engine_version              = "17"
  instance_class              = "db.m6g.large"
  allocated_storage           = 100
  storage_type                = "gp3"
  storage_encrypted           = true
  username                    = "app"
  manage_master_user_password = true
  multi_az                    = true
  backup_retention_period     = 14
  deletion_protection         = true
  skip_final_snapshot         = false
  final_snapshot_identifier   = "app-db-final"
}

variable "db_name" {
  type = string
}

variable "db_password" {
  type      = string
  sensitive = true
}

resource "azurerm_resource_group" "db" {
  name     = "rg-db-demo"
  location = "eastus"
}

resource "azurerm_postgresql_flexible_server" "app" {
  name                         = var.db_name
  resource_group_name          = azurerm_resource_group.db.name
  location                     = azurerm_resource_group.db.location
  version                      = "17"
  sku_name                     = "GP_Standard_D2ds_v5"
  storage_mb                   = 131072
  administrator_login          = "app"
  administrator_password       = var.db_password
  backup_retention_days        = 14
  geo_redundant_backup_enabled = true
  zone                         = "1"

  high_availability {
    mode                      = "ZoneRedundant"
    standby_availability_zone = "2"
  }
}

resource "google_sql_database_instance" "app" {
  name                = "app-db"
  database_version    = "POSTGRES_17"
  region              = "us-central1"
  deletion_protection = true

  settings {
    tier              = "db-custom-2-8192"
    edition           = "ENTERPRISE"
    availability_type = "REGIONAL"
    disk_type         = "PD_SSD"
    disk_size         = 100

    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
      transaction_log_retention_days = 7
    }
  }
}

Усі три конфігурації описують ту саму річ: два вузли в різних зонах із синхронною реплікацією, бекапи з PITR і захист від видалення. У AWS пароль адміністратора створює й зберігає сам RDS у Secrets Manager (manage_master_user_password), тож його не видно в коді. В Azure паролем керуєте ви, і він приходить зі змінної.

Таблиця NoSQL із відновленням на момент часу

resource "aws_dynamodb_table" "orders" {
  name         = "orders"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "customer_id"
  range_key    = "order_id"

  attribute {
    name = "customer_id"
    type = "S"
  }

  attribute {
    name = "order_id"
    type = "S"
  }

  point_in_time_recovery {
    enabled                 = true
    recovery_period_in_days = 35
  }

  deletion_protection_enabled = true
}

variable "cosmos_name" {
  type = string
}

resource "azurerm_resource_group" "nosql" {
  name     = "rg-nosql-demo"
  location = "eastus"
}

resource "azurerm_cosmosdb_account" "shop" {
  name                = var.cosmos_name
  location            = azurerm_resource_group.nosql.location
  resource_group_name = azurerm_resource_group.nosql.name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  capabilities {
    name = "EnableServerless"
  }

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = azurerm_resource_group.nosql.location
    failover_priority = 0
  }

  backup {
    type = "Continuous"
    tier = "Continuous7Days"
  }
}

resource "azurerm_cosmosdb_sql_database" "shop" {
  name                = "shop"
  resource_group_name = azurerm_resource_group.nosql.name
  account_name        = azurerm_cosmosdb_account.shop.name
}

resource "azurerm_cosmosdb_sql_container" "orders" {
  name                = "orders"
  resource_group_name = azurerm_resource_group.nosql.name
  account_name        = azurerm_cosmosdb_account.shop.name
  database_name       = azurerm_cosmosdb_sql_database.shop.name
  partition_key_paths = ["/customer_id"]
}

resource "google_firestore_database" "orders" {
  name                              = "orders"
  location_id                       = "us-central1"
  type                              = "FIRESTORE_NATIVE"
  point_in_time_recovery_enablement = "POINT_IN_TIME_RECOVERY_ENABLED"
  delete_protection_state           = "DELETE_PROTECTION_ENABLED"
}

Усі три варіанти працюють без замовленої потужності: у DynamoDB режим PAY_PER_REQUEST, у Cosmos DB EnableServerless, у Firestore потужності немає взагалі. Переходячи на замовлену ємність, у DynamoDB замінюють billing_mode і задають read_capacity та write_capacity, а в Cosmos DB прибирають EnableServerless і додають до контейнера throughput або autoscale_settings.

Відновлення на момент часу з командного рядка

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier app-db \
  --target-db-instance-identifier app-db-restored \
  --restore-time 2026-09-29T14:02:00Z

az postgres flexible-server restore \
  --resource-group rg-db-demo \
  --name app-db-restored \
  --source-server app-db-demo \
  --restore-time "2026-09-29T14:02:00Z"

gcloud sql instances clone app-db app-db-restored \
  --point-in-time '2026-09-29T14:02:00.000Z'

Кожна команда створює нову базу зі станом на 14:02, а стара лишається незмінною, так само як на діаграмі вище.

Скільки це коштує

Ціни станом на вересень 2026, з офіційних прайс-листів і сторінок цін; регіони us-east-1, eastus, us-central1, Linux, оплата за фактом, 730 годин на місяць.

Реляційна PostgreSQL: 2 vCPU і 8 ГіБ пам’яті, 100 ГБ SSD, один вузол проти резервного вузла в іншій зоні.

	AWS RDS (db.m6g.large, gp3)	Azure PostgreSQL flexible (GP_Standard_D2ds_v5)	GCP Cloud SQL (Enterprise, 2 vCPU + 8 ГіБ, SSD)
Обчислення, один вузол	$0.159 за годину, $116.07	$0.178 за годину, $129.94	$0.1386 за годину, $101.18
Диск 100 ГБ	$11.50	$11.50	$17.00
Разом, один вузол	$127.57	$141.44	$118.18
Разом, з резервним вузлом	$255.14	близько $283	$236.36

Резервний вузол подвоює рахунок у всіх трьох: він оплачується як другий сервер із таким самим диском. У Cloud SQL це прямо сказано в документації. Питання, чи потрібна вам така надійність у розробці, є суто фінансовим: середовище розробки з резервним вузлом коштує вдвічі більше за середовище без нього. Бекапи оплачуються окремо або частково входять у ціну: Azure SQL Database дає безкоштовно обсяг, що дорівнює розміру бази, а в Azure PostgreSQL бекапи в LRS коштують $0.095 за ГБ на місяць.

Найменший розподілений SQL. Spanner Standard edition в Iowa коштує $0.90 за вузол на годину, а мінімальний інстанс зі 100 processing units в десять разів менше, $0.09 за годину, приблизно $65.70 на місяць.

Постійне навантаження 1000 читань за секунду цілодобово, місяць.

Сервіс і режим	Ціна
DynamoDB, on-demand, сильно консистентні читання до 4 КБ	$328.50
DynamoDB, provisioned, 1000 RCU	$94.90
Cosmos DB, serverless, елементи за ключем близько 1 КБ	$657.00
Cosmos DB, provisioned, 1000 RU/s	$58.40
Cosmos DB, autoscale з максимумом 1000 RU/s	$87.60
Firestore, 1000 документів за секунду	$788.40

Розрахунок: 1000 читань на секунду за місяць дають 2.628 мільярда. Однакове навантаження коштує від $58 до $788 залежно від сервісу та режиму, тож різницю між «за запит» і «замовлено» видно одразу. Порівнювати рядки між сервісами треба обережно: одиниці різні, а Cosmos DB порахований для елемента в 1 КБ.

Сховище й бекапи NoSQL. DynamoDB: $0.25 за ГБ на місяць після перших 25 ГБ. Cosmos DB (транзакційне сховище): $0.25 за ГБ на місяць. Firestore: близько $0.15 за ГіБ на місяць.

Кеші, найменший вузол за годину:

	Ціна
ElastiCache for Valkey, cache.t4g.micro	$0.0128 за годину, $9.34 на місяць
ElastiCache for Redis OSS, cache.t4g.micro	$0.016 за годину
Azure Managed Redis, Balanced B0	$0.016 за годину, $11.68 на місяць
Memorystore for Valkey, shared-core-nano (1.4 ГБ)	$0.0318 за годину, $23.21 на місяць

Кеш вважають дешевим, поки не потрібен великий обсяг пам’яті: вузол ElastiCache for Valkey класу cache.m7g.large коштує $0.1264 за годину (близько $92 на місяць), а Memorystore standard-small із 6.5 ГБ $0.1425 за годину. Розміри пам’яті вузлів Azure Managed Redis дивіться в таблиці SKU документації.

Розбір: UniSuper і видалена хмара

Що сталося. Австралійський пенсійний фонд UniSuper тримав продуктивне середовище в Google Cloud VMware Engine: приватній хмарі, де працюють віртуальні машини VMware. У 2023 році її розгортали внутрішнім інструментом Google, і порожнє значення в одному з параметрів призвело до того, що хмару створили із фіксованим строком у один рік, а не безстроковою. Коли рік минув, на початку травня 2024 року, підписку на приватну хмару UniSuper було видалено автоматично, без жодного сповіщення. Спільна заява UniSuper і Google Cloud описує це як помилку конфігурації під час розгортання і називає подію «одиничною» (one-of-a-kind), такою, що не траплялася в жодного клієнта Google Cloud.

Чому дублювання не допомогло. У UniSuper було розгортання у двох геолокаціях саме на випадок відмови обладнання чи майданчика. Але, за спільною заявою, видалення зачепило обидві: це був не збій даних на одному з майданчиків, а видалення самої підписки, і команда «видалити» діє на всі копії однаково (той самий механізм, що в модулі 6).

Що врятувало. У UniSuper були резервні копії в іншого провайдера. Разом із бекапами в Google Cloud Storage, які видалення не зачепило, і сторонньою програмою резервного копіювання вони дозволили відновити роботу. Відновлення тривало кілька діб цілодобової роботи. Понад 647 000 учасників фонду деякий час не мали доступу до рахунків, а 15 травня UniSuper підтвердила повне відновлення сервісів для учасників.

Що змінила Google. Вона скасувала внутрішній інструмент, який спричинив помилку, вручну перевірила всі розгортання Google Cloud VMware Engine і виправила поведінку системи, щоб такі сценарії не призводили до видалення.

Що з цього випливає для керованих баз. Хоча інцидент стосується VMware, уроки прямо переносяться:

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

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

«Керована база означає, що бекапи вже налаштовано». Вони є, але строк їх зберігання, копії в інший регіон чи акаунт і перевірку відновлення налаштовуєте ви.
«Multi-AZ це і є резервна копія». Резервний вузол повторює кожну команду, зокрема помилкову, за долі секунди. Повернути таблицю здатен лише бекап із журналом.
«Резервний вузол можна використати для звітів». У RDS Multi-AZ DB instance і в Azure PostgreSQL резервний вузол читання не обслуговує, а для звітів потрібна репліка.
«PITR відкотить базу на місці». Він створює нову базу, і на перемикання застосунку та перенесення даних треба закласти час.
«On-demand завжди дешевший, бо платиш за використане». Для стабільного трафіку замовлена потужність дешевша в кілька разів, а on-demand виграє на рідкісному чи стрибкоподібному.
«Кеш можна ставити без плану на його втрату». Після перезапуску кеш порожній, і навала запитів до бази може її вбити, якщо не закладено прогрів і обмеження.
«Redis в Azure це Azure Cache for Redis». Для нових проєктів це Azure Managed Redis, а старий сервіс має дати виведення з експлуатації.

Перевір себе

1. О 14:03 розробник виконав DROP TABLE orders на базі з Multi-AZ і резервним вузлом в іншій зоні. Що поверне таблицю?Перемикання на резервний вузол, бо він у іншій зоніВідновлення на момент 14:02 із бекапу й журналу в нову базуСтворення репліки для читанняПерезавантаження основної бази

2. Таблиця DynamoDB стабільно приймає 800 записів на секунду цілодобово. On-demand чи provisioned дешевше і приблизно на скільки?On-demand, бо платиш лише за використанеОднаково, різниця в межах відсоткаOn-demand дешевший на 50% через відсутність мінімальної потужностіProvisioned приблизно втричі дешевший: близько $380 проти $1310 на місяць

3. Команда перевела акаунт Cosmos DB з рівня Session на Strong, а рахунок за читання виріс. Чому?Читання на Strong і Bounded staleness звертаються до двох реплік і споживають приблизно вдвічі більше RUStrong вмикає автомасштабування, яке коштує дорожчеStrong потребує другого регіону, що подвоює рахунокCosmos DB не бере плату за читання на слабших рівнях

4. Команда стартує новий проєкт на Azure і хоче взяти Azure Cache for Redis Standard. Що варто знати?Нічого, це основний сервіс кешу AzureStandard дорожчий за EnterpriseРівні Basic, Standard і Premium заплановано до виведення 30 вересня 2028; для нових систем призначено Azure Managed RedisAzure не має керованого кешу, потрібна власна віртуальна машина

5. Інстанс RDS видалили без опції «зберегти автоматичні бекапи» і без фінального знімка, ручних знімків немає. Чи можна відновити базу PITR?Так, автоматичні бекапи зберігаються ще 35 дібНі, автоматичні бекапи видаляються разом з інстансом; лишилися б лише ручні або фінальний знімокТак, але тільки через підтримку AWSТак, з репліки для читання, якщо вона була

6. Звіти навантажують основну базу RDS Multi-AZ DB instance. Хтось пропонує читати їх із резервного вузла, він же просто простоює. Що відповісти?Так, це стандартна практикаТак, але тільки з підтвердженням від провайдераТак, якщо читання не міняють даніНі: резервний вузол читання не обслуговує; потрібна репліка для читання або Multi-AZ DB cluster

7. Помилку в даних виявили через три доби, а PITR у проєкті налаштовано на одну добу. Хто відповідає і що змінити?Ви: строк утримання бекапів є вашим налаштуванням; збільшити його та періодично перевіряти відновленняПровайдер: керований сервіс мав би зберігати бекапи довшеНіхто, це обмеження сервісуВимкнути PITR і використовувати лише репліки

Джерела

Amazon RDS: backups і restore to a point in time
Amazon RDS: Multi-AZ DB instance deployments
Amazon Aurora storage, scaling to 0 ACUs і Aurora DSQL
DynamoDB: on-demand capacity mode і point-in-time recovery
Amazon ElastiCache for Valkey і що таке Valkey
Ціни AWS: офіційні прайс-листи pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ для AmazonRDS, AmazonDynamoDB, AmazonElastiCache
Azure SQL Database: автоматичні бекапи
Azure Database for PostgreSQL: висока доступність
Azure Cosmos DB: рівні консистентності і Request Units
Виведення Azure Cache for Redis і перехід на Azure Managed Redis
Ціни Azure: Retail Prices API
Cloud SQL: висока доступність і PITR
Ціни Google Cloud: Cloud SQL, Spanner, Firestore, Memorystore for Valkey
UniSuper і Google Cloud, спільна заява, травень 2024, і Google Cloud, Details of Google Cloud GCVE incident
Курс ОС: диски і блочний рівень