Архітектура, відмовостійкість і вартість

Навіщо це

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

Тому модуль поєднує дві теми, які зазвичай розносять. Спершу терміни й механізми: HA і DR, RTO і RPO, зони, регіони, клітини. Потім ціна кожної сходинки на конкретних числах. Наприкінці FinOps, дисципліна, що тримає рахунок під контролем.

Окремих прайсів тут мало: ціни на інстанси, диски й бази вже є в блоках «Скільки це коштує» модулів 4–9. У цьому модулі вони правлять за вхідні дані для моделі, а предмет розмови становлять компроміси.

Передумови. Регіони й зони доступності (модуль 1), бюджети й теги (модуль 2), вихідний трафік і NAT-шлюз (модуль 5), репліки й бекапи (модуль 7), інфраструктура як код (модуль 10), SLO й бюджет помилок (модуль 11). Віртуалізація, на якій стоять зони й інстанси, описана в курсі ОС.

Well-Architected: три рамки

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

Стовп	AWS (6)	Azure (5)	Google Cloud (6)
Операційна досконалість	Operational Excellence	Operational Excellence	Operational Excellence
Безпека	Security	Security	Security
Надійність	Reliability	Reliability	Reliability
Продуктивність	Performance Efficiency	Performance Efficiency	Performance Optimization
Вартість	Cost Optimization	Cost Optimization	Cost Optimization
Сталість	Sustainability	окремого стовпа немає	Sustainability

Станом на вересень 2026 Azure Well-Architected Framework має п’ять стовпів. AWS додав до перших п’яти шостий, сталість. Google Cloud перейменував колишній Architecture Framework на Well-Architected Framework і теж має шість стовпів; окрім них у документації є «перспективи» для AI та ML і для окремих галузей.

Практичну користь дають сторінки компромісів (tradeoffs) у кожному стовпі. Стовпи суперечать один одному: надійність вимагає надлишку, а надлишок б’є по вартості; безпека додає шари, що додають затримку; оптимізація вартості прибирає запас, потрібний надійності. Каркас цих суперечностей не розв’язує, він примушує називати їх уголос: перш ніж додати другий регіон, ви записуєте, який стовп за це платить. Для оцінювання є інструменти (AWS Well-Architected Tool, Azure Well-Architected Review, Azure Advisor), але відповідати на їхні питання варто разом із людьми, які експлуатують систему.

HA, DR і дві цифри

Висока доступність (high availability, HA) означає, що сервіс переживає відмову окремого компонента без участі людини: впав сервер чи зона, а користувачі цього не помітили або помітили на секунди. Аварійне відновлення (disaster recovery, DR) означає повернення сервісу після події, яку HA не витримала: втрата регіону, видалення даних, компрометація акаунта, помилкове масове розгортання. DR зазвичай потребує рішення людини й процедури, яку виконують рідко.

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

Відновлення описують двома цільовими числами.

RTO (recovery time objective) визначає, скільки сервіс може бути недоступним, від початку простою до робочого стану.
RPO (recovery point objective) визначає, скільки даних можна втратити, виміряно часом. RPO у 15 хвилин дозволяє після відновлення втратити все, що з’явилося за останні 15 хвилин.

Це бізнесові вимоги, а не технічні параметри: скільки годин без виставлення рахунків компанія витримає, відповідають фінансисти. З цієї відповіді вибір архітектури здебільшого зводиться до пошуку найдешевшого варіанта, що дає такі числа. Зв’язок із модулем 11: SLO 99,9 % допускає близько 43 хвилин простою на місяць, 99,99 % близько 4 хвилин, і кожна додаткова «дев’ятка» вимагає іншого класу архітектури.

Зона, регіон і межі надлишку

Зона доступності є природною одиницею відмови всередині регіону, тому multi-AZ став базовим рівнем HA: кілька інстансів у різних зонах за балансувальником навантаження й база з синхронною реплікою в іншій зоні. Multi-region переживає втрату регіону цілком: збій площини керування провайдера, DNS усередині регіону, стихію, регуляторне рішення. Приклад дає AWS us-east-1 у жовтні 2025 року (модуль 11): помилка автоматизації DNS для DynamoDB зачепила десятки сервісів регіону більш ніж на чотирнадцять годин. Друга зона тут нічого б не змінила, бо ламалася залежність, спільна для всього регіону.

Якщо зона має доступність 99,9 % і відмови незалежні, обидві зони впадуть разом із ймовірністю 10⁻⁶. Реально доступність нижча з двох причин. Відмови не бувають повністю незалежними: спільний конфіг, DNS чи розгортальний конвеєр ламають обидві копії одночасно. До того ж більшість простоїв спричиняють люди й розгортання. Звідси правило: надлишок захищає від відмов заліза, але не від помилок у програмах і процесах. Проти останніх працюють поетапні розгортання (модуль 10) і клітини, про які нижче.

Ще одна пастка: спільні залежності, про які ніхто не згадав. Єдиний реєстр образів, єдиний провайдер ідентифікації, DNS-зона в одному регіоні, конвеєр CI/CD, без якого не розгорнути виправлення, моніторинг у тому ж регіоні, що й зламаний застосунок. Документація AWS радить під час відновлення покладатися на площину даних (data plane), бо вона проєктується під вищу доступність, ніж площина керування (control plane). План DR, який починається зі слів «створити новий кластер», залежить від тієї частини хмари, що в аварію працює гірше за все.

Скільки коштує друга зона, а скільки другий регіон

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

Припущення. Базовий варіант, одна зона: застосунок $1 000 на місяць, база $600, диски й сховище $100. NAT-шлюз коштує $0.045 за годину плюс $0.045 за кожен ГБ, що через нього пройшов (тариф AWS у us-east-1, станом на вересень 2026); через нього проходить 2 ТБ на місяць, разом $33 + $92 ≈ $125. Усього $1 825 на місяць. Трафік між зонами в AWS коштує $0.01 за ГБ у кожен бік, між регіонами $0.02 за ГБ з боку відправника. Копії лежать в об’єктному сховищі по $0.023 за ГБ на місяць.

Друга зона

Друга зона має сенс, лише якщо кожна зона здатна нести повне навантаження, інакше після втрати першої система впаде від перевантаження. Тому застосунок $2 000, база із синхронною реплікою $1 200, диски $200. NAT-шлюз потрібен у кожній зоні (єдиний шлюз у втраченій зоні лишив би без інтернету обидві): годинна плата $66, трафік ті самі $92. Додається трафік між зонами, скажімо 2 ТБ на місяць: $41.

Стаття	Одна зона	Дві зони
Застосунок	$1 000	$2 000
База даних	$600	$1 200
Диски й сховище	$100	$200
NAT-шлюзи (година + трафік)	$125	$158
Трафік між зонами	$0	$41
Разом на місяць	$1 825	$3 599

Друга зона обійшлася майже в 1,97 раза: подвоєння основних статей і невеликий «податок» на трафік. Дві поправки. Перша: три зони дешевші за дві в розрахунку на обчислення. Щоб пережити втрату однієї з двох зон, кожна мусить нести 100 % навантаження (разом 200 %); з трьох достатньо по 50 % на зону (разом 150 %). База від цього не виграє. Друга: якщо після втрати зони ви розраховуєте на автомасштабування, ви залежите від площини керування й від вільної ємності в решті зон саме тоді, коли всі вони шукають її одночасно. Статично стійка схема тримає запас заздалегідь.

Другий регіон

Другий регіон додає те саме плюс те, чого в першому не було: міжрегіональний трафік і дві копії конфігурації. Нехай реплікація даних, логів і подій дає 20 ТБ на місяць: 20 × 1024 × $0.02 ≈ $410. Що ви платите ще, залежить від обраної стратегії.

Місячний рахунок навчальної моделі. Виділено двозонний варіант, до якого додаються сходинки DR. Числа на стовпчиках: долари на місяць.

Стратегія	Що працює в другому регіоні	Додатково	Разом	Орієнтовні RPO / RTO
Backup and restore	лише копії бекапів	$70	$3 669, +2 %	години / доба і більше
Pilot light	база реплікується, застосунок вимкнений	$1 210	$4 809, +34 %	секунди–хвилини / десятки хвилин–години
Warm standby	зменшена працююча копія (чверть потужності)	$1 743	$5 342, +48 %	секунди–хвилини / хвилини
Active-active	повна копія, обслуговує трафік	$4 009	$7 608, +111 %	близько нуля / близько нуля

Додатково: $70 = 2 ТБ копій у сховищі + 1 ТБ трафіку; $1 210 = репліка бази $600 + диски $200 + реплікація $410; $1 743 = чверть застосунку $500 + база $600 + диски $200 + один NAT $33 + реплікація $410; $4 009 = друга повна копія $3 599 + реплікація $410. Діапазони RPO й RTO орієнтовні, вони залежать від бази, обсягу даних і відпрацьованості процедури. Опис самих чотирьох стратегій відповідає документу AWS «Disaster Recovery of Workloads on AWS», який добре працює й поза AWS.

Backup and restore. Копії лежать в іншому регіоні (в ідеалі й в іншому акаунті, щоб зламаний акаунт не знищив копії). Після катастрофи ви розгортаєте інфраструктуру з коду й відновлюєте дані. Ціна мізерна, RTO обчислюється годинами, RPO дорівнює інтервалу між копіями. Ця сходинка потрібна кожній системі з даними, бо лише вона рятує від видалення й пошкодження, і вона вимагає інфраструктури як коду (модуль 10), інакше відновлення стає археологією.

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

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

Active-active. Обидва регіони обслуговують користувачів, тож «перемикання» немає: трафік просто перестає йти в загиблий регіон. Це найдорожча й найскладніша сходинка, головно через дані: обидва регіони записують, і конфлікти треба розв’язувати. Документація AWS називає три підходи: «write global» (усі записи в один регіон), «write local» (у найближчий, як глобальні таблиці DynamoDB з правилом «останній запис перемагає») і «write partitioned» (регіон визначає ключ розбиття). Кожен жертвує затримкою, консистентністю або простотою.

Порівняйте з ціною простою. Якщо година простою коштує $500, warm standby за $1 743 на місяць ($20 900 на рік) окупається лише тоді, коли без нього простій тривав би понад 40 годин на рік. Якщо година коштує $50 000, розрахунок протилежний. Ціну відмовостійкості порівнюють із ціною простою.

Cell-based архітектура: обмежити радіус ураження

Multi-AZ і multi-region захищають від відмов інфраструктури. Найчастіша причина великих простоїв інша: помилка в самому програмному забезпеченні, яка одразу потрапляє на всіх користувачів. Проти неї працює клітинна (cell-based) архітектура.

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

Чотири клітини, кожна обслуговує чверть клієнтів. Збій, помилкове розгортання чи «отруйний» запит у клітині 3 зачіпає лише її клієнтів.

Радіус ураження обмежується часткою клієнтів однієї клітини: із чотирма клітинами найгірший збій зачіпає 25 %, із двадцятьма 5 %. Поетапне розгортання стає природним: нову версію спершу отримує одна клітина. Масштабування теж змінюється: ви додаєте клітини відомого розміру, а не збільшуєте одну систему.

Ціна клітин реальна. Маршрутизатор є єдиною спільною точкою, тож його треба зробити якомога простішим. Операції над клієнтами, що охоплюють кілька клітин, ускладнюються, а невеликі клітини використовують ресурси гірше за одну велику систему. AWS описує підхід у Well-Architected, але сама ідея від провайдера не залежить: межею клітини можуть бути окремі акаунти, підписки чи проєкти (модуль 2).

Chaos engineering: перевіряти відмову до її настання

Архітектура «витримує втрату зони» лише тоді, коли ви бачили, як вона її витримує. Chaos engineering називають практику навмисного внесення відмов у контрольований спосіб для перевірки гіпотези про поведінку системи. Експеримент має форму наукового: описати сталий стан («частка успішних запитів понад 99,5 %»), висунути гіпотезу («втрата однієї зони цього не змінить»), внести відмову з обмеженим радіусом і кнопкою зупинки, порівняти результат з гіпотезою. Розбіжність і є знахідкою: хибний таймаут, забутий кеш, прихована спільна залежність.

AWS має Fault Injection Service, Azure має Chaos Studio: вони зупиняють інстанси, вносять затримки й помилки, імітують втрату зони. Google Cloud, судячи з документації, окремого керованого сервісу цього класу не має: використовують внесення відмов на рівні балансувальника й відкриті інструменти на кшталт Chaos Mesh для Kubernetes. Почати можна й без інструмента: «ігровий день» (game day), коли команда вимикає зону в тестовому середовищі й дивиться на панелі, а також регулярне навчальне відновлення з бекапу.

FinOps: як тримати рахунок під контролем

FinOps називають практику, за якої інженери, фінансисти й бізнес спільно керують витратами в хмарі. FinOps Foundation описує її як цикл: бачити витрати (inform), оптимізувати (optimize), керувати процесом (operate). Основна ідея: рахунок формують рішення інженерів, тож і бачити ціну своїх рішень мають вони.

Моделі оплати

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

Модель	Що ви обіцяєте	Знижка (за заявою провайдера)	Ризик
On-demand	нічого	0 %	найдорожче
Зобов’язання на 1 або 3 роки	стабільну витрату	AWS Savings Plans до 66–72 %, Azure Reservations до 72 %, Google CUD залежно від продукту	платите й за невикористане
Spot	згоду на переривання	Azure до 90 %, Google до 91 %	ВМ забирають зі стислим попередженням

Це заголовні цифри станом на вересень 2026; реальні відсотки залежать від сімейства, регіону й терміну, тож ведіть розрахунок у калькуляторі. Google пропонує committed use discounts двох видів: на ресурси (vCPU, пам’ять, GPU, Local SSD; лише Compute Engine) і на витрату (гроші на годину, діють на кількох сервісах). У AWS Compute Savings Plans діють незалежно від сімейства, розміру й регіону та покривають Fargate і Lambda, а EC2 Instance Savings Plans дають більшу знижку за прив’язку до сімейства в регіоні. Тому Savings Plans краще переживають зміну архітектури.

Spot придатний лише для роботи, яку можна перервати: пакетна обробка, CI, навчання з контрольними точками, розбір черг (модуль 4, модуль 9). Типова зріла структура закупівлі: базове навантаження покрито зобов’язаннями, змінне оплачується on-demand, переривне йде на spot. Купувати зобов’язання на весь пік означає платити за порожні години. Це той самий принцип, що й у відмовостійкості: гарантія коштує грошей, і зобов’язання є ставкою на те, що потреба збережеться. Якщо за рік ви змінили архітектуру, а потужність куплено під старі інстанси, знижка перетворюється на борг.

Unit economics

Загальна сума рахунку мало що каже. Зростання з $10 000 до $15 000 на місяць є проблемою, якщо клієнтів стало стільки ж, і успіхом, якщо їх стало втричі більше. Тому дивляться на ціну одиниці (unit cost): вартість замовлення, активного користувача, тисячі запитів, обробленого відео. Витрати беруть із білінгу, метрику з телеметрії, а зв’язок між ними забезпечують теги. Якщо ціна замовлення зростає за стабільної кількості замовлень, причину видно: нова залежність, забуте тестове середовище, запит, що сканує всю таблицю.

Теги й мітки

Рахунок за замовчуванням знає, що ви витратили на «EC2», але не знає, який продукт і яка команда. Розподіл витрат забезпечують теги в AWS і Azure та мітки (labels) в GCP: team, product, env. Потрібні три умови: позначено всі ресурси, значення беруться з фіксованого словника, і (в AWS) теги розподілу витрат окремо активовано в білінгу.

aws resourcegroupstaggingapi get-resources \
  --query 'ResourceTagMappingList[?Tags[?Key==`team`]==`[]`].ResourceARN' \
  --output text

Ресурси без тега team. Сервіс повертає лише те, що коли-небудь мало теги, тож ніколи не позначені ресурси він може не показати. Витрати за тегом видно в Cost Explorer або командою aws ce get-cost-and-usage --group-by Type=TAG,Key=team.

az resource list \
  --query "[?tags.team==null].{name:name,type:type,rg:resourceGroup}" \
  -o table

Ресурси підписки без тега team. Тег групи ресурсів не переходить на ресурси автоматично, для цього є політика Azure Policy зі спадкуванням. Розріз витрат за тегом видно в Cost Analysis, а повторюваний експорт створює az costmanagement export create.

gcloud compute instances list \
  --filter='-labels.team:*' \
  --format='table(name,zone.basename(),machineType.basename())'

Віртуальні машини без мітки team. Детальну аналітику витрат за мітками роблять експортом білінгу в BigQuery.

Rightsizing і зайве

Rightsizing означає підбір розміру за фактичним навантаженням. Типова знахідка: машини з середнім завантаженням процесора 8 %, розмір яких вибрали «із запасом» три роки тому. Рекомендації дають AWS Compute Optimizer, Azure Advisor і Google Cloud Recommender; вони бачать лише середнє й пік за обмежений період і нічого не знають про місячне закриття звітності через два тижні. Друга група знахідок простіша: осиротілі диски, застарілі снапшоти, балансувальники без трафіку, dev-середовища, що працюють уночі й на вихідних. Вимкнення dev на ніч і вихідні зменшує його ціну приблизно на 70 %, бо ви платите за 50 із 168 годин тижня.

Прихована вартість

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

Вихідний трафік. Плата за трафік в інтернет (AWS у us-east-1 бере $0.09 за ГБ у першому тарифі), між регіонами й зонами. Вхідний трафік здебільшого безкоштовний. Для сервісів, що віддають багато даних (відео, файли, API мобільних клієнтів), це головна стаття. Засоби: CDN (модуль 5), стискання, розташування клієнтів поруч з даними.

NAT-шлюз. Береться і погодинна плата, і плата за кожен гігабайт. Якщо приватні підмережі тягнуть образи, пакети й об’єкти сховища через NAT, ви платите $0.045 за ГБ за те, що можна отримати безкоштовно: для S3 і DynamoDB в AWS існують gateway-ендпоінти без погодинної плати й плати за обробку.

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

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

Задача	AWS	Azure	GCP
Каркас	Well-Architected, 6 стовпів	Well-Architected, 5 стовпів	Well-Architected, 6 стовпів
Копії між регіонами	AWS Backup	Azure Backup, Recovery Services vault	Backup and DR Service, dual-region бакети
DR для серверів	AWS Elastic Disaster Recovery	Azure Site Recovery	прямого аналога немає
Керування перемиканням	Route 53 Application Recovery Controller	Azure Front Door, Traffic Manager	Cloud DNS, глобальний балансувальник
Експерименти з відмовами	Fault Injection Service	Chaos Studio	першопартійного сервісу немає, Chaos Mesh
Зобов’язання	Savings Plans, Reserved Instances	Reservations, Savings Plan for Compute	Committed use discounts
Переривні ВМ	Spot	Spot VMs	Spot VMs
Рекомендації	Compute Optimizer	Azure Advisor	Recommender
Трафік між зонами	$0.01 за ГБ у кожен бік	безкоштовно з 2024 року	платний ($0.01 за ГБ)
Трафік між регіонами (Півн. Америка)	$0.02 за ГБ	$0.02 за ГБ	$0.02 за ГБ

Чим це відрізняється і що з цього випливає. Найважливіше розходження стосується трафіку між зонами. В Azure він безкоштовний, тож multi-AZ між сервісами не додає плати, а в AWS кожен ГБ коштує $0.02 за цикл, і «балакуча» мікросервісна схема на трьох зонах стає окремою статтею рахунку. Друга відмінність: мережа GCP глобальна (модуль 5), тому для multi-region достатньо одного глобального балансувальника, тоді як в AWS і Azure маршрутизацію між регіональними стеками ви збираєте самі. Перед вибором архітектури порахуйте трафік між компонентами, а не тільки кількість серверів.

Приклад нижче задає копію бекапів в інший регіон кодом. AWS Backup копіює відновні точки в сховище іншого регіону, Recovery Services vault в Azure має геореплікацію з відновленням у парному регіоні, а в GCP аналогом є dual-region бакет із turbo-реплікацією.

variable "dr_vault_arn" {
  type        = string
  description = "ARN сховища резервних копій у регіоні DR"
}

resource "aws_backup_vault" "main" {
  name = "main-vault"
}

resource "aws_backup_plan" "daily" {
  name = "daily-with-dr-copy"

  rule {
    rule_name         = "daily"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 3 * * ? *)"

    lifecycle {
      delete_after = 35
    }

    copy_action {
      destination_vault_arn = var.dr_vault_arn

      lifecycle {
        delete_after = 35
      }
    }
  }
}

resource "azurerm_resource_group" "dr" {
  name     = "rg-backup"
  location = "eastus"
}

resource "azurerm_recovery_services_vault" "main" {
  name                         = "rsv-main"
  location                     = azurerm_resource_group.dr.location
  resource_group_name          = azurerm_resource_group.dr.name
  sku                          = "Standard"
  storage_mode_type            = "GeoRedundant"
  cross_region_restore_enabled = true
}

resource "google_storage_bucket" "backups" {
  name     = "example-backups-dual-region"
  location = "NAM4"

  # Turbo-реплікація: ціль RPO 15 хвилин замість типових годин
  rpo = "ASYNC_TURBO"

  uniform_bucket_level_access = true
}

Три блоки відповідають на одне питання різними шляхами. AWS вимагає окремого сховища в регіоні DR і явного копіювання. Azure вбудовує геореплікацію у властивість сховища, а відновлення в парному регіоні вмикає окремий прапорець. У GCP dual-region бакет реплікується сам, і параметр rpo є буквально числом RPO; ASYNC_TURBO коштує дорожче за стандартну реплікацію, тож навіть RPO має ціну.

Розбір: скільки коштує «на всякий випадок»

Після великого збою регіону в новинах керівництво вимагає «переїхати в active-active у двох регіонах» для застосунку з нашої моделі.

Вимога в грошах. З власником продукту з’ясовують: година простою коштує близько $2 000 упущеного доходу, а після трьох годин починаються штрафи за договором. Виходить RTO чотири години й RPO п’ятнадцять хвилин.

Найдешевша сходинка. Такі цифри вкладаються в pilot light: безперервна реплікація бази, готові образи, код інфраструктури й відпрацьована процедура запуску за годину-дві. Це $1 210 на місяць, близько $14 500 на рік.

Що додав би active-active. $4 009 на місяць, близько $48 000 на рік, плюс складність запису у двох регіонах і людські витрати. Вони купують RTO, близьке до нуля. Якщо втрата регіону очікується раз на п’ять років, а простій коштує кілька годин по $2 000, різниця не окупається.

Рішення. Компанія обирає pilot light і копії бекапів в окремому акаунті, а різницю вкладає в те, що справді зменшує ризик: клітини для найбільшого клієнта, щоквартальне навчання з відновлення й поетапні розгортання. Навчання показує RTO півтори години. Вимогу виконано із запасом. Порядок для повторення: спершу вимога в грошах, потім найдешевша сходинка, що її покриває, потім перевірка навчанням.

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

«Multi-AZ означає, що в нас є DR». Multi-AZ не захищає від видалення даних, помилки розгортання чи втрати регіону: реплікація вірно копіює і корисні зміни, і руйнівні.
«Другий регіон — це просто велика друга зона». Він додає міжрегіональний трафік, дві конфігурації й проблему консистентності записів: це інший клас складності.
«Копії в тому ж акаунті нас захищають». Скомпрометований акаунт знищує і дані, і копії. Копії тримають в іншому акаунті й регіоні.
«Купили Savings Plans, отже оптимізували». Зобов’язання знижує ціну одиниці, але не прибирає марнування: машини на 8 % завантаження ви просто оплатили зі знижкою.
«Налаштоване перемикання працює». Непротестований DR лишається гіпотезою: у розпал аварії виявляється, що бракує квоти в регіоні відновлення чи застарів образ.

Перевір себе

1. У продакшені хтось виконав DELETE без умови. База має синхронну репліку в іншій зоні доступності. Що з даними?Репліка збереже стару версію й дозволить відновитисяРепліка повторить видалення, тож потрібні бекап і відновлення на момент часуПровайдер автоматично скасує операціюДані збережуться, якщо база стоїть у трьох зонах замість двох

2. Що таке RPO?Час, за який сервіс має відновитисяЧастка запитів, що мають виконуватися успішноКількість регіонів, у яких розгорнуто системуСкільки даних можна втратити, виміряно часом

3. Вимоги: RTO 4 години, RPO 15 хвилин. Команда пропонує active-active у двох регіонах. Що розумніше?Погодитися: active-active закриває всі вимогиЩоденний бекап у той самий регіонSpot-інстанси, щоб скоротити RTOPilot light із безперервною реплікацією й відпрацьованою процедурою запуску, а різницю вкласти в тести й клітини

4. Чому захист від втрати зони на трьох зонах дешевший за дві, якщо рахувати потужність застосунку?Щоб пережити втрату однієї з трьох зон, достатньо 150 % потужності, а для двох потрібні 200 %Кожна зона у схемі з трьох дешевшаТрафік між трьома зонами безкоштовний в усіх провайдерівПровайдер дає знижку за третю зону

5. AWS-рахунок показує великі витрати на NAT-шлюз: сервіси у приватних підмережах щодня читають терабайти з S3. Що зробити першим?Замінити NAT-шлюз на більшийДодати gateway-ендпоінт для S3, щоб трафік до сховища не йшов через NATПеренести дані в інший регіонВимкнути логування

6. Навантаження працює цілодобово вже рік, розмір стабільний. Щоночі є пакетне завдання, яке можна безболісно перезапускати. Як купити потужність?Усе on-demand, щоб зберегти гнучкістьУсе за зобов’язанням на три роки, включно з пікомУсе на spot, бо він найдешевшийБазове навантаження за зобов’язанням, пакетну задачу на spot

7. Рахунок за хмару виріс удвічі, а фінансовий директор не хвилюється. Чому?Зростання вдвічі вважається нормою для хмарних системЦіна одиниці (наприклад, замовлення) впала, бо замовлень побільшало ще сильнішеЙому не показують деталей рахункуЗнижки провайдера покриють зростання

8. Що дає клітинна архітектура, чого не дає multi-AZ?Обмеження радіуса ураження помилки в самому програмному забезпеченніЗахист від збою апаратури в зоніНульове RPOЗнижку на трафік між зонами