🧭Як пройти цей курс і не загубитися

Що таке AWS — одним абзацом

Компанія Amazon колись була просто інтернет-магазином книжок. Щоб магазин витримував мільйони покупців, вона збудувала величезні приміщення, повні комп'ютерів. А потім зрозуміла: ці комп'ютери можна здавати в оренду всім охочим — через інтернет, на хвилини, з оплатою лише за використане.

Так з'явився AWS (читається «ей-дабл-ю-ес», Amazon Web Services). Сьогодні це найбільший у світі «прокат» комп'ютерних ресурсів: понад 200 окремих послуг — сервісів. Один сервіс зберігає файли, інший — дані клієнтів, третій розсилає повідомлення, четвертий захищає від хакерів. Замість купувати власні комп'ютери, компанія бере в AWS рівно те, що потрібно, і платить, як за електрику — за спожите.

Такий прокат через інтернет називають хмарою (cloud, «клауд»). Чому саме хмара — розберемо в окремому розділі.

Хто такий Solutions Architect

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

Solutions Architect (читається «солюшнз архітект», «архітектор рішень») робить те саме з комп'ютерними системами в AWS. Замовник каже: «Хочу інтернет-пекарню». Архітектор обирає з двохсот «будматеріалів» AWS потрібні й поєднує їх так, щоб система:

• не зламали — безпека;
• не падала й не губила дані — надійність;
• працювала швидко — продуктивність;
• коштувала розумно — вартість.

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

Іспит SAA-C03 — коротко

SAA-C03 — код іспиту AWS Certified Solutions Architect – Associate («асоушіейт» — рівень «спеціаліст»). Головне, що варто знати вже зараз:

• 65 питань за 130 хвилин, прохідний бал — 720 з 1000. Питання англійською (української немає), але на кожне є пояснення в цьому курсі.
• Якщо англійська не рідна, перед записом на іспит можна попросити +30 хвилин (ESL +30). Як це зробити — в останній частині курсу.
• Майже кожне питання — міні-історія: «Компанія має… Потрібно… Яке рішення найкраще?». Команди й кнопки напам'ять знати не треба. Треба розуміти, для чого кожен сервіс, і вміти обрати.

Саме тому цей курс не змушує зубрити. Він пояснює, як усе працює, — а вибір потім стає очевидним.

Маршрут: шість кроків до сертифіката

Сайт побудований як дорога. Кожен наступний крок спирається на попередній — тож іди по порядку.

1. 🧠 Глибоке навчання (ця вкладка). Кожна тема з нуля: образи, картинки, історія «Хмаринки», міні-тести. Тут закладається розуміння.
2. 🎓 Навчання. 24 короткі уроки з тими самими образами, але стисло, плюс «як про це питають на іспиті». Після глибокого навчання вони читаються легко — як повторення знайомого.
3. 📘 Шпаргалка. Усі факти й цифри, розкладені по поличках, і тригери — пари «бачиш у питанні → відповідь».
4. 🎲 Квіз. Тренуєш тригери, поки 9 з 10 не будуть «знав».
5. 📝 Тест. 65 питань у стилі іспиту, з таймером. Ціль — стабільно 80% і більше в режимі «Іспит».
6. 🏆 Іспит. Записуєшся й складаєш.

Скільки це займе? Якщо починати зовсім з нуля й приділяти 1–1,5 години на день, реалістично — 6–10 тижнів. Хтось швидше, хтось повільніше, і це нормально. Важливо не поспішати з глибоким навчанням: кожна година тут економить дві на повторенні.

Як читати кожен розділ

Усі розділи побудовані однаково, тож скоро ти почуватимешся в них як удома:

• 🎯 Що ти дізнаєшся — кілька рядків угорі: навіщо цей розділ.
• 🥐 Історія «Хмаринки» — що сталося в Олі і чому тема знадобилася.
• Пояснення — невеликими кроками, з образами з життя й ілюстраціями.
• 📖 Словничок — нові слова розділу з перекладом і вимовою.
• 🧩 Міні-тест — кілька питань. Помилятися тут корисно: пояснення покаже, що перечитати.
• ✅ Головне — розділ у п'яти рядках.
• 🔁 Закріпи — посилання на відповідний короткий урок і розділ шпаргалки.

Ще два види вставок можна при першому читанні пропускати:

• 🔍 Для допитливих — глибші подробиці. Корисні, але не обов'язкові.
• 🧪 Спробуй у справжньому AWS — маленькі практичні вправи в безкоштовному акаунті. Дуже допомагають «відчути» сервіси руками.

П'ять звичок, які роблять навчання легким

1. Уявляй. Кожен образ — «кухня», «склад», «охоронець» — намалюй у голові. Картинка запам'ятовується краще за визначення.
2. Переказуй своїми словами. Після розділу поясни уявному другові (або бабусі), про що він. Якщо не виходить — перечитай один підрозділ, а не весь розділ.
3. Не пропускай міні-тести. Навіть якщо здається, що все ясно.
4. Повторюй «Головне» наступного дня. Одна хвилина — і вчорашній розділ закріплено.
5. Торкайся підкреслених слів. Це 🤖 підказки: коротке пояснення будь-якого сервісу чи терміна прямо в тексті.

Прогрес (пройдені розділи, відповіді міні-тестів) зберігається на цьому пристрої. Сайт можна встановити як застосунок на телефон — він працюватиме й без інтернету.

Не бійся слів

Спочатку незнайомих слів буде багато. Це нормально: навіть досвідчені інженери AWS щодня щось гуглять. Ми ніколи не використовуватимемо слово, не пояснивши його. А ті самі ідеї повертатимуться знову і знову, щоразу трохи глибше, — так вони й запам'ятаються.

📖 Словничок

• AWS («ей-дабл-ю-ес») — Amazon Web Services, найбільший хмарний провайдер.
• Хмара (cloud, «клауд») — оренда комп'ютерних ресурсів через інтернет з оплатою за використане.
• Сервіс — окрема послуга AWS: зберігання файлів, база даних, розсилка повідомлень тощо.
• Solutions Architect — фахівець, який обирає й поєднує сервіси під вимоги замовника.
• SAA-C03 — код іспиту AWS Certified Solutions Architect – Associate.
• Тригер — у цьому курсі: пара «бачиш у питанні → обираєш відповідь».

✅ Головне

• AWS — прокат комп'ютерних ресурсів через інтернет: понад 200 сервісів, оплата за використане.
• Solutions Architect обирає й поєднує сервіси так, щоб система була безпечна, надійна, швидка й недорога.
• Іспит — про вибір, а не про команди: 65 питань, 130 хвилин, прохідний бал 720 з 1000.
• Маршрут: Глибоке навчання → Навчання → Шпаргалка → Квіз → Тест → Іспит.
• Уявляй образи, переказуй своїми словами, проходь міні-тести, повторюй «Головне» наступного дня.

💻Що всередині комп'ютера: процесор, пам'ять і диск

Комп'ютер — це кухня

Телефон, ноутбук, величезний сервер в AWS — усі вони влаштовані однаково. Уяви кухню ресторану. У ній є три головні речі:

• Процесор — це кухар. Він виконує всю роботу: рахує, порівнює, перекладає, малює картинку на екрані. Кухар неймовірно швидкий — мільярди простих дій за секунду.
• Оперативна пам'ять — це робочий стіл кухаря. Усе, з чим він працює просто зараз, лежить на столі під рукою. Брати зі столу — миттєво. Але стіл невеликий, і коли кухня закривається (комп'ютер вимикається), стіл прибирають начисто.
• Диск — це холодильник і комора. Тут усе зберігається надовго: рецепти, продукти, записи. Місця багато, і вимкнене світло нічого не зіпсує. Але щоб узяти щось із комори, треба сходити й принести — це помітно довше, ніж зі столу.

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

Тепер зрозуміло, звідки беруться знайомі скарги:

• «Комп'ютер гальмує, бо мало пам'яті» — стіл замалий, кухар постійно бігає до холодильника.
• «Слабкий процесор» — кухар повільний або один на велике замовлення.
• «Закінчилося місце» — комора забита вщерть, нові продукти нікуди покласти.

Процесор: кухар, що рахує мільярдами

Процесор англійською — CPU (читається «сі-пі-ю», Central Processing Unit — «центральний обчислювальний пристрій»).

Два слова про нього знадобляться весь курс:

• Ядра (cores, «корз»). У сучасному процесорі не один кухар, а кілька — їх називають ядрами. Чотири ядра — четверо кухарів, які готують одночасно. У серверів ядер бувають десятки.
• Частота (вимірюється в гігагерцах, ГГц). Це те, як швидко рухається кожен кухар. 3 ГГц — приблизно три мільярди кроків за секунду.

В AWS ти не бачитимеш справжніх процесорів. Тобі виділятимуть vCPU (читається «ві-сі-пі-ю», virtual CPU) — «віртуального кухаря», частку справжнього процесора. Замовляєш 2 vCPU — отримуєш двох кухарів на свою кухню.

А ще процесори бувають різних «шкіл кулінарії» — архітектур. Одна школа — Intel і AMD (у більшості ноутбуків). Інша — ARM (у телефонах). AWS робить власні процесори на ARM — Graviton («гравітон»). Вони готують ту саму страву дешевше, тож на іспиті Graviton часто з'являється у відповідях про економію.

Оперативна пам'ять: робочий стіл

Оперативна пам'ять англійською — RAM (читається «рем», Random Access Memory). Її вимірюють у гігабайтах: у телефоні 6–12 ГБ, у ноутбуці 8–32 ГБ, у великих серверах — сотні гігабайтів і навіть терабайти.

Дві властивості, які треба запам'ятати:

1. RAM дуже швидка — у сотні й тисячі разів швидша за диск.
2. RAM тимчасова. Вимкнули живлення — усе на столі зникло. Тому програми просять «зберегти» роботу: зберегти — означає перенести зі столу в комору.

Ця пара властивостей — основа цілого класу сервісів AWS. Коли щось треба віддавати блискавично, дані тримають саме в пам'яті — це називається кеш («записник на столі»). А ще є сервери з «величезним столом» — для задач, де весь масив даних мусить лежати під рукою.

Диск: холодильник і комора

Диск — це постійне сховище: дані лишаються, навіть якщо вимкнути живлення. Буває двох головних видів:

• HDD (читається «ейч-ді-ді», жорсткий диск) — усередині обертаються металеві пластини, а над ними бігає голівка, як у старому програвачі платівок. Дешевий і місткий, але повільний, особливо коли треба дістати багато дрібних речей з різних полиць.
• SSD (читається «ес-ес-ді») — без рухомих частин, як велика флешка. Набагато швидший, але кожен гігабайт коштує дорожче.

В AWS ти обиратимеш диски під задачу: швидкі SSD — для баз даних і системи, дешеві HDD — для великих архівів, які читають підряд. Детально — у розділі про диски.

Біти й байти: як комп'ютер міряє інформацію

Усередині комп'ютера все — текст, фото, музика — записано нулями й одиницями. Одна така позначка, 0 або 1, називається біт (bit). Уяви вимикач світла: увімкнено — 1, вимкнено — 0.

Один біт мало що вміщує, тому біти збирають у групи по вісім. Вісім бітів — це байт (byte). Одного байта досить, щоб записати одну англійську літеру чи цифру. Українська літера в поширеному кодуванні займає два байти.

Далі — як з грамами й кілограмами, тільки крок приблизно в тисячу разів:

Ці одиниці ти бачитимеш скрізь: «об'єкт у сховищі — до 50 TB», «диск на 500 GB», «повідомлення — до 1 MB».

Біти для швидкості, байти для розміру

Тут новачки часто плутаються. Розмір файлів міряють у байтах (MB, GB). А швидкість інтернету — у бітах за секунду: Mbps («мегабіт за секунду»), Gbps («гігабіт за секунду»). Зверни увагу на маленьку «b» — біти, і велику «B» — байти.

Правило перекладу просте: швидкість у бітах ділимо на 8 — отримуємо байти.

• Домашній інтернет 100 Mbps → приблизно 12 мегабайтів за секунду.
• Фільм на 3 GB (3 000 MB) такий канал завантажить приблизно за 250 секунд — трохи більше чотирьох хвилин.

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

GPU: бригада помічників

Є ще один вид «кухаря» — GPU (читається «джі-пі-ю», Graphics Processing Unit, графічний процесор). Звичайний процесор — кілька майстрів, кожен уміє все. GPU — тисячі простих помічників, які вміють лише нарізати, зате всі разом і одночасно.

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

Що ти «замовлятимеш» в AWS

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

Тепер ти розумієш кожен рядок цього «чека». Скільки кухарів (vCPU), який завбільшки стіл (RAM), яка комора (диск) — і платиш лише за час, поки кухня працює. Про те, як саме такий комп'ютер стає «віртуальним», поговоримо в розділі про віртуалізацію.

📖 Словничок

• Процесор, CPU («сі-пі-ю») — «кухар»: виконує обчислення.
• Ядро (core, «кор») — окремий «кухар» усередині процесора.
• vCPU («ві-сі-пі-ю») — віртуальний процесор: частка справжнього, яку дає хмара.
• Graviton («гравітон») — процесори AWS на архітектурі ARM: та сама робота дешевше.
• Оперативна пам'ять, RAM («рем») — «робочий стіл»: дуже швидка, але тимчасова.
• Диск — «холодильник і комора»: повільніший, зате зберігає назавжди.
• SSD («ес-ес-ді») — швидкий диск без рухомих частин.
• HDD («ейч-ді-ді») — дешевий місткий диск з обертовими пластинами.
• Біт / байт — 0 або 1 / вісім бітів.
• KB, MB, GB, TB, PB — кіло-, мега-, гіга-, тера-, петабайт; кожен ≈ у 1000 разів більший.
• Mbps, Gbps — мегабіти й гігабіти за секунду: швидкість мережі.
• GPU («джі-пі-ю») — «бригада помічників» для графіки та штучного інтелекту.

✅ Головне

• Будь-який комп'ютер — кухня: процесор (кухар), оперативна пам'ять (стіл), диск (холодильник і комора).
• Пам'ять — швидко, але тимчасово. Диск — повільніше, зате назавжди.
• Біт → байт (8 бітів) → KB → MB → GB → TB → PB, кожен крок ≈ ×1000.
• Швидкість мережі — у бітах (Mbps), розмір — у байтах (MB): ділимо на 8.
• В AWS ти орендуватимеш саме такі «кухні»: обираєш vCPU, пам'ять і диск.

🧩Програми, операційна система і файли

Програма — це рецепт

Пам'ятаєш кухню з попереднього розділу? Кухар (процесор) дуже швидкий, але сам нічого не вигадує. Йому потрібен рецепт — точна послідовність кроків: «візьми борошно, додай масло, вимішуй 5 хвилин».

Програма і є таким рецептом для комп'ютера — набором інструкцій. Пишуть програми люди-програмісти спеціальними мовами (Python, Java, JavaScript та інші). Браузер, у якому ти зараз читаєш, — програма. Калькулятор — програма. Сайт «Хмаринки» теж буде програмою, яка працює на сервері.

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

Операційна система — керуючий рестораном

Хтось має вирішувати, яку страву кухарі готують цієї миті, скільки місця на столі дати кожній і де в коморі що лежить. Цим займається операційна система (ОС, англійською OS — «оу-ес»).

ОС — найголовніша програма комп'ютера, керуючий рестораном:

• розподіляє процесор і пам'ять між програмами;
• тримає лад у коморі — керує файлами на диску;
• «розмовляє» з пристроями: екраном, мережею, принтером;
• пильнує, хто має право заходити на кухню, — керує користувачами й правами.

Найвідоміші операційні системи: Windows (більшість домашніх комп'ютерів), macOS (комп'ютери Apple), Android та iOS (телефони) і Linux («лінукс»).

Linux — безкоштовна система з відкритим кодом: її може переглянути й удосконалити будь-хто. Вона стабільна, економна й добре працює без екрана, тому на Linux працює більшість серверів у світі, зокрема більшість серверів в AWS. Windows Server обирають, коли потрібні саме віндоусівські програми — наприклад, спільні папки для офісу з Windows чи корпоративний каталог користувачів Active Directory. Ця різниця ще знадобиться на іспиті: «спільні файли для Linux» і «спільні файли для Windows» — різні сервіси AWS.

Файли, папки й формати

Файл — це окремий документ у коморі, у якого є ім'я: krouasan.jpg, menu.pdf, zamovlennia.csv. Папки (їх ще називають каталогами, directories) — полиці й коробки, у які файли розкладено. Шлях до файлу — ніби адреса полиці:

• у Windows: C:\Users\Olia\Retsepty\krouasan.txt
• у Linux: /home/olia/retsepty/krouasan.txt

Закінчення імені після крапки — розширення — підказує формат, тобто як усередині записані дані і якою програмою їх відкривати:

• .txt — простий текст; .pdf — документ; .jpg, .png — зображення; .mp4 — відео;
• .csv — таблиця, записана простим текстом, де значення розділено комами;
• .json — дані для програм (познайомимося в розділі про вебсайти).

Формати ще повернуться в розділі про аналітику: там ти дізнаєшся, чому той самий масив даних у форматі Parquet можна проаналізувати в десятки разів дешевше, ніж у CSV.

Встановлення, оновлення і патчі

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

Програми пишуть люди, а люди помиляються. Деякі помилки — просто незручності, а деякі — дірки в безпеці: через них зловмисник може проникнути в комп'ютер. Це як виявити, що замок на задніх дверях відчиняється шпилькою.

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

Користувачі й права

Операційна система знає, хто за нею працює. У кожного — свій обліковий запис (акаунт) з ім'ям і паролем, і свої права: бухгалтер бачить облік, але не може видалити систему.

Є й особливий запис з повною владою: адміністратор у Windows, root («рут») у Linux. Це майстер-ключ від усього будинку. Правило досвідчених людей: майстер-ключем не користуються щодня — лише для рідкісних особливих справ. Те саме правило буде і в AWS: там теж є «root» — і його теж ховають.

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

Найзвичніше керувати комп'ютером мишкою чи пальцем: вікна, кнопки, значки. Це графічний інтерфейс (GUI, «джі-ю-ай»).

Є й інший спосіб — командний рядок (CLI, «сі-ел-ай», command line interface). Ти набираєш коротку команду, комп'ютер виконує й відповідає текстом. Наприклад, у Linux команда ls показує файли в папці, а mkdir retsepty створює папку «retsepty».

Навіщо команди, якщо є кнопки? Три причини:

1. Сервери не мають екрана. Вони стоять у дата-центрі, і керують ними через мережу.
2. Команди можна записати. Список команд у файлі — скрипт — комп'ютер виконає сам, скільки завгодно разів, без помилок і втоми.
3. Швидкість. Налаштувати сто серверів кнопками — тиждень. Скриптом — хвилини.

Керувати на відстані: SSH і RDP

Щоб дістатися до сервера через мережу, адміністратори використовують:

• SSH («ес-ес-ейч») — захищений командний рядок для Linux. Працює через «двері» номер 22 (що таке номери дверей — портів, — у наступному розділі).
• RDP («ар-ді-пі») — віддалений робочий стіл Windows, ніби дивишся на екран сервера здалеку. Двері номер 3389.

Відкриті для всього інтернету двері 22 чи 3389 — улюблена ціль зловмисників. В AWS є безпечніший спосіб зайти на сервер узагалі без відчинених дверей — Session Manager. Ми до нього дійдемо.

Скрипт за розкладом — і чому на іспиті він програє

Уяви: щоночі о 2:00 треба копіювати замовлення в архів. Можна написати скрипт і попросити керуючого запускати його за розкладом (у Linux розклад задач називається cron — «крон»).

Це працює. Але такий скрипт живе на одному сервері: сервер зламався — архівація тихо зупинилась, і ніхто не помітив. У хмарі для більшості таких задач є керовані сервіси, які роблять те саме надійніше й без твого нагляду. Тому на іспиті варіант «напишемо скрипт на сервері й запускатимемо cron» майже завжди неправильний, якщо поруч є керований сервіс.

📖 Словничок

• Програма — набір інструкцій для комп'ютера, «рецепт».
• Процес — програма, яка виконується просто зараз.
• Операційна система, ОС («оу-ес») — головна програма-«керуючий»: розподіляє ресурси, керує файлами, пристроями й правами.
• Linux («лінукс») — безкоштовна ОС, на якій працює більшість серверів.
• Файл / папка — документ з ім'ям / полиця, на яку документи розкладено.
• Розширення — закінчення імені файлу (.jpg, .csv), що вказує формат.
• Патч — оновлення, яке виправляє помилку, часто — дірку в безпеці.
• root / адміністратор («рут») — обліковий запис з повною владою, «майстер-ключ».
• GUI («джі-ю-ай») — керування кнопками й вікнами.
• CLI («сі-ел-ай») — керування текстовими командами.
• Скрипт — записаний список команд, який комп'ютер виконує сам.
• SSH («ес-ес-ейч», порт 22) / RDP («ар-ді-пі», порт 3389) — віддалене керування Linux / Windows.
• cron («крон») — розклад задач у Linux.

✅ Головне

• Програма — «рецепт», процес — «готування за рецептом просто зараз».
• Операційна система — «керуючий»: ділить ресурси, тримає файли, стереже права.
• Більшість серверів — на Linux; Windows Server — коли потрібні саме віндоусівські програми.
• Патчі закривають дірки в безпеці; хто їх ставить у хмарі — залежить від сервісу.
• Сервери без екрана керуються командами (SSH, RDP); скрипт на одному сервері на іспиті програє керованому сервісу.

🔌Мережа: як комп'ютери розмовляють

Мережа — це пошта між комп'ютерами

Мережа — це кілька пристроїв, з'єднаних так, щоб вони могли обмінюватися даними. Кабелем чи через Wi-Fi — неважливо.

• Ноутбук, телефон, телевізор і принтер удома чи в пекарні утворюють локальну мережу (LAN, «лан»).
• Інтернет — це мережа мереж: мільйони локальних мереж по всьому світу, з'єднаних між собою.

Найкраще уявляти мережу як пошту — наприклад, Нову пошту. Дані — це посилки, у кожного пристрою є адреса, а по дорозі посилки проходять сортувальні центри.

Дані їдуть посилками — пакетами

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

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

IP-адреса — адреса поштомата

Щоб пакет доїхав, у кожного пристрою в мережі має бути адреса. Це IP-адреса (читається «ай-пі», від Internet Protocol). Виглядає як чотири числа через крапку:

• 192.168.1.25 — типова адреса ноутбука в домашній мережі;
• 52.95.110.1 — адреса одного із серверів в інтернеті.

Без IP-адреси пакет нікуди не доставити. Як влаштовані адреси всередині і чому числа лише від 0 до 255 — у розділі про IP-адреси.

Порт — номер комірки поштомата

На одному комп'ютері одночасно працює багато програм, і кожна чекає свою пошту: сайт, пошта, база даних. Як пакет знає, якій саме програмі він призначений?

Для цього є порт — номер «дверей» чи комірки. Уяви поштомат: адреса поштомата — це IP, а номер комірки — порт. Посилка на 52.95.110.1:443 означає: «поштомат 52.95.110.1, комірка 443».

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

Навіщо це архітектору? У правилах захисту постійно пишуть саме порти: «пускати всіх на 443», «базу даних на 3306 — лише від наших серверів». Хто знає порти, той читає такі правила, як газету.

Роутер і комутатор: сортувальні центри

Пакети не летять напряму від тебе до сервера. Їх передають із рук у руки спеціальні пристрої:

• Комутатор (switch, «світч») — сортує пакети всередині однієї локальної мережі, як кур'єр у межах одного будинку.
• Роутер, або маршрутизатор (router, «раутер»), — сортувальний термінал між мережами. Він дивиться на адресу одержувача й вирішує, куди передати пакет далі: «на Київ, звідти — на Франкфурт».

Домашній Wi-Fi-роутер — теж роутер: він з'єднує твою маленьку мережу з мережею провайдера. А пакет зі Львова до сервера у Франкфурті по дорозі проходить десяток-другий роутерів.

Щоб роутер знав, куди що передавати, у нього є таблиця маршрутів — «дорожні вказівники»: «пакети для 10.0.0.x — ліворуч, для всього іншого — на головну трасу». Запам'ятай цей образ: в AWS ти власноруч налаштовуватимеш такі таблиці.

Протокол — домовленість, як розмовляти

Щоб пошта працювала, усі мають однаково писати адресу, пакувати й підтверджувати доставку. Такі домовленості в мережах називають протоколами. Ти вже знаєш кілька: IP — як адресувати й доставляти пакети; далі будуть HTTP (як браузер розмовляє із сайтом) і DNS (як шукати адресу за ім'ям). А зараз — два найважливіші способи доставки.

TCP і UDP: посилка з відстеженням і листівка

• TCP («ті-сі-пі») — посилка з відстеженням і підтвердженням. Перед відправкою сторони «тиснуть руки» й домовляються про з'єднання. Кожен пакет пронумеровано, одержувач підтверджує отримання, загублене надсилають повторно, порядок відновлюють. Надійно, але трохи повільніше. Так працюють сайти, пошта, передавання файлів, бази даних.
• UDP («ю-ді-пі») — листівка без відстеження. Просто відправили — і все: ні рукостискання, ні підтверджень. Швидко й легко, але частина листівок може загубитися. Це нормально для відеодзвінків, онлайн-ігор і трансляцій: краще на мить втратити кадр, ніж чекати, поки його перешлють.

Швидкість: ширина дороги і довжина дороги

Люди кажуть «швидкий інтернет», маючи на увазі дві різні речі:

• Пропускна здатність (bandwidth, «бендвідс») — ширина дороги: скільки даних проходить за секунду. Вимірюється в Mbps чи Gbps. Широка дорога — фільм завантажується швидко.
• Затримка (latency, «лейтенсі») — довжина дороги: скільки часу пакет їде від тебе до сервера й назад. Вимірюється в мілісекундах (мс). Навіть на найширшій трасі зі Львова до Токіо їхати далеко: відповідь прийде приблизно за чверть секунди, хоч би який швидкий був інтернет.

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

Файрвол — охоронець на вході

Коли пакети можуть приходити звідусіль, потрібен хтось, хто вирішує, кого впускати. Це файрвол, або брандмауер (firewall, «файрвол» — «вогняна стіна»). Він перевіряє кожен пакет за правилами: з якої адреси, на який порт. «На 443 — пускати всіх. На 22 — лише з адреси офісу. Решту — не пускати».

В AWS таких охоронців два, і різницю між ними обов'язково запитають на іспиті. Про них — у частині про мережу.

📖 Словничок

• Мережа / LAN («лан») — з'єднані пристрої / локальна мережа будинку чи офісу.
• Інтернет — мережа мереж на весь світ.
• Пакет — маленька порція даних з адресами відправника й одержувача.
• IP-адреса («ай-пі») — адреса пристрою в мережі, напр. 192.168.1.25.
• Порт — номер «комірки» для конкретної програми: 443 — HTTPS, 22 — SSH.
• Роутер («раутер») — передає пакети між мережами за таблицею маршрутів.
• Комутатор (switch, «світч») — передає пакети всередині однієї мережі.
• Протокол — домовленість, як саме обмінюватися даними.
• TCP («ті-сі-пі») — надійна доставка з підтвердженням. UDP («ю-ді-пі») — швидка без підтвердження.
• Пропускна здатність (bandwidth) — скільки даних за секунду, «ширина дороги».
• Затримка (latency) — скільки чекати відповіді, «довжина дороги»; у мілісекундах.
• Файрвол («файрвол») — охоронець, що пропускає пакети лише за правилами.

✅ Головне

• Дані їдуть мережею пакетами, які проходять через роутери за таблицями маршрутів.
• IP-адреса — адреса поштомата, порт — номер комірки: 443 HTTPS, 80 HTTP, 22 SSH, 3389 RDP.
• TCP — надійно з підтвердженням; UDP — швидко без підтверджень (ігри, відео, дзвінки).
• Пропускна здатність (ширина дороги) і затримка (довжина дороги) — різні речі; затримку зменшує лише близькість.
• Файрвол пропускає пакети за правилами «звідки і на який порт».

🌐Інтернет і вебсайти: що відбувається, коли відкриваєш сторінку

Клієнт і сервер

Будь-який сайт — це розмова двох сторін:

• Клієнт — той, хто питає. Твій браузер (Chrome, Safari, Firefox) чи мобільний застосунок.
• Сервер — той, хто відповідає. Комп'ютер десь у дата-центрі, на якому працює програма сайту.

Як у кав'ярні: гість (клієнт) робить замовлення, кухня (сервер) готує й віддає. Гостей багато, кухня одна — і вона має встигати всім. Запам'ятай слово запит (request, «ріквест») — це «замовлення» клієнта, і відповідь (response, «респонс»).

Адреса сайту — URL

Адреса, яку ти бачиш угорі браузера, називається URL (читається «ю-ар-ел»). Розберемо її по частинах:

• https:// — протокол: мова розмови. Літера «s» означає secure — захищено.
• www.khmarynka.ua — доменне ім'я: назва «кав'ярні», зручна для людей.
• /menu/croissants — шлях: яку саме сторінку чи файл дати, ніби номер полиці.
• ?size=big — параметри: уточнення до замовлення.

DNS — телефонна довідка інтернету

Комп'ютери знаходять одне одного за IP-адресами, а люди запам'ятовують імена. Хтось має перекласти khmarynka.ua у 52.95.110.1. Це робить DNS (читається «ді-ен-ес», Domain Name System — система доменних імен). Уяви телефонну довідку: називаєш ім'я — отримуєш номер.

Як це відбувається, коли адреси ще ніхто не знає:

1. Браузер питає резолвер — «довідкову» твого провайдера.
2. Резолвер питає кореневі сервери: «Хто відповідає за .ua?»
3. Потім сервери зони .ua: «Хто відповідає за khmarynka.ua?»
4. І нарешті авторитетний сервер домену (його налаштовує власник сайту): «Яка адреса в khmarynka.ua?» — «52.95.110.1».
5. Резолвер повертає адресу браузеру й запам'ятовує її на певний час — TTL («ті-ті-ел», time to live). Наступного разу відповідь миттєва.

Дві речі звідси знадобляться в AWS:

• Щоб мати ім'я сайту, домен реєструють (купують на рік чи кілька) у реєстратора. А записи «ім'я → адреса» тримають у DNS-сервісі. В AWS і те, і те вміє Route 53.
• Через TTL зміни в DNS розходяться світом не миттєво: резолвери ще якийсь час пам'ятають стару адресу. На іспиті це пояснює, чому перемикання «через DNS» не завжди найшвидше.

HTTP — як браузер і сервер розмовляють

Коли адресу знайдено, браузер відправляє серверу запит мовою HTTP («ейч-ті-ті-пі», HyperText Transfer Protocol). Запит складається з методу й шляху:

• GET /menu — «дай мені сторінку меню» (отримати);
• POST /orders — «ось моє замовлення, прийми» (надіслати дані, наприклад форму);
• ще бувають PUT (замінити), DELETE (видалити) та інші.

Сервер відповідає кодом стану і самим вмістом (сторінкою, картинкою). Коди варто знати за першою цифрою:

HTTPS і замочок

Звичайний HTTP — як листівка: будь-хто на шляху (наприклад, у кав'ярняному Wi-Fi) може прочитати, що там написано, навіть пароль.

HTTPS — той самий HTTP, але в замкненому броньованому конверті. Дані шифруються (технологія TLS), тож по дорозі їх неможливо прочитати. А сертифікат сайту — ніби паспорт — підтверджує, що це справді khmarynka.ua, а не підробка. Замочок біля адреси в браузері означає: конверт замкнено, паспорт перевірено.

Як працює шифрування і де брати сертифікати в AWS — в окремому розділі про шифрування.

З чого складається сторінка

Сторінка — це не один файл, а десятки:

• HTML — зміст і структура: заголовки, текст, кнопки;
• CSS — оформлення: кольори, шрифти, розташування;
• JavaScript — поведінка: що станеться, коли натиснеш кнопку;
• картинки, шрифти, відео.

Частина з них статична — однакова для всіх: логотип, фото круасанів, стилі. Їх можна просто зберігати як файли й роздавати дуже дешево й швидко — пізніше ти дізнаєшся, що в AWS для цього поєднують сховище S3 і мережу доставки CloudFront.

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

Cookies і сесії: як сайт тебе пам'ятає

HTTP сам нічого не пам'ятає: кожен запит для сервера — як від нової людини. Як же сайт знає, що ти вже в особистому кабінеті і що в кошику три круасани?

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

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

API і JSON: меню й бланк замовлення для програм

Не лише люди спілкуються із сервером. Мобільний застосунок «Хмаринки» теж питає сервер — але не сторінки, а дані. Для цього сервер має API (читається «ей-пі-ай», Application Programming Interface) — перелік дозволених запитів і їхній формат. Образ: меню з правилами замовлення для програм.

Наприклад, застосунок надсилає GET /api/menu, а сервер відповідає даними у форматі JSON («джейсон»):

{
  "name": "Круасан з мигдалем",
  "price": 45,
  "inStock": true,
  "tags": ["випічка", "хіт"]
}

JSON — простий текст: назви полів у лапках, двокрапка, значення. Його легко читати і людям, і програмам. Зверни на нього увагу вже зараз: в AWS у JSON записують правила доступу (хто що може робити), налаштування й події. Ти читатимеш JSON постійно.

Де тут хмара

Усе, що відбувається «з того боку» — сервер із програмою, база даних, DNS, сертифікат, сховище для фото, — можна не купувати, а орендувати в AWS. Саме цим і займеться Оля. Але спершу ще кілька основ.

📖 Словничок

• Клієнт / сервер — той, хто питає / той, хто відповідає.
• Запит / відповідь (request / response) — «замовлення» клієнта і «страва» від сервера.
• URL («ю-ар-ел») — повна адреса сторінки: протокол, домен, шлях, параметри.
• Домен — ім'я сайту, напр. khmarynka.ua; його реєструють на певний строк.
• DNS («ді-ен-ес») — «довідкова»: перетворює ім'я на IP-адресу.
• TTL («ті-ті-ел») — скільки часу відповідь DNS можна пам'ятати.
• HTTP / HTTPS — мова браузера й сервера / те саме, але в зашифрованому конверті.
• Метод — тип запиту: GET отримати, POST надіслати.
• Код стану — трицифрова відповідь сервера: 200 добре, 404 не знайдено, 503 недоступно.
• Сертифікат — «паспорт» сайту, що підтверджує справжність.
• Статичний / динамічний вміст — однаковий для всіх / створений під конкретного користувача.
• Cookie («кукі») / сесія — номерок у гардеробі / записи сервера про тебе.
• API («ей-пі-ай») — «меню» запитів для програм. JSON («джейсон») — текстовий формат даних.

✅ Головне

• Сайт — розмова клієнта (браузер, застосунок) і сервера: запит → відповідь.
• URL = протокол + домен + шлях + параметри; DNS перекладає домен в IP і запам'ятовує відповідь на TTL.
• HTTP: GET отримати, POST надіслати; коди 2xx добре, 4xx помилка клієнта (404, 429), 5xx помилка сервера (500, 503).
• HTTPS — шифрування + сертифікат-«паспорт».
• Статичне можна роздавати з простого сховища; динамічне створює програма з базою даних. Cookie — номерок до твоєї сесії. API + JSON — як програми розмовляють між собою.

🔢IP-адреси, підмережі й CIDR без страху

Будова IP-адреси

Ти вже знаєш, що IP-адреса — це чотири числа через крапку: 192.168.1.25. Кожне з чотирьох чисел займає рівно один байт — вісім бітів. А вісьмома бітами (нулями й одиницями) можна записати лише 256 різних значень: від 0 до 255. Тому в IP-адресі не буває чисел на кшталт 300.

Усього в адресі 4 × 8 = 32 біти. Це дає приблизно 4,3 мільярда різних адрес. Здається, багато — але пристроїв у світі давно більше. Тому придумали дві хитрості: приватні адреси з NAT і нову, величезну версію адрес — IPv6. Звичні адреси з чотирма числами називаються IPv4.

Публічні й приватні адреси

• Публічна адреса унікальна на весь інтернет — як повна поштова адреса з країною, містом і вулицею. Саме за нею тебе знаходять будь-звідки.
• Приватна адреса діє лише всередині однієї мережі — як внутрішній номер телефону в офісі («набери 214»). Такі самі номери одночасно використовують мільйони інших офісів і квартир, і нікому це не заважає.

Для приватних мереж домовилися використовувати три діапазони:

Домашні роутери зазвичай роздають адреси 192.168.x.x, а у своїх мережах в AWS найчастіше беруть 10.x.x.x.

NAT — одна адреса на всю родину

Провайдер дає твоєму домашньому роутеру одну публічну адресу. А вдома — телефон, ноутбук, телевізор, усі з приватними адресами 192.168.x.x. Як вони всі ходять в інтернет?

Роутер працює як ресепшн в офісі. Коли телефон надсилає запит на сайт, роутер замінює на пакеті зворотну адресу на свою публічну й записує в журнал: «відповідь від цього сайту — для телефона». Відповідь приходить на ресепшн, і роутер передає її потрібному пристрою. Ця підміна адрес називається NAT («нат», Network Address Translation — «переклад мережевих адрес»).

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

CIDR: як записати цілий район адрес

Мережі рідко складаються з однієї адреси. Зазвичай це цілий діапазон — «район» адрес. Записувати його з першої до останньої незручно, тому користуються записом CIDR (читається «сайдер»):

10.0.0.0/16

Число після слеша означає: скільки бітів ліворуч зафіксовано. Зафіксована частина — ніби назва вулиці, однакова для всіх будинків району. Решта бітів — вільні: це номери будинків усередині.

• /16 — зафіксовано перші 16 бітів, тобто перші два числа: 10.0.x.x. Вільних бітів — 32 − 16 = 16, отже адрес 2¹⁶ = 65 536.
• /24 — зафіксовано перші три числа: 10.0.1.x. Вільних бітів 8 → 256 адрес.
• /32 — зафіксовано все: рівно одна адреса.

Формула одна: кількість адрес = 2 у степені (32 − число після слеша). А найпростіше — запам'ятати кілька рядків:

Два особливі записи варто знати напам'ять:

• 0.0.0.0/0 — зафіксовано нуль бітів, тобто будь-яка адреса, «увесь інтернет». У таблицях маршрутів рядок 0.0.0.0/0 → ворота в інтернет означає: «усе, що не належить до наших районів, — на головну трасу».
• x.x.x.x/32 — одна конкретна адреса. У правилах захисту так пишуть: «пускати лише адресу офісу 203.0.113.10/32».

Підмережі: ділимо місто на квартали

Великий діапазон зазвичай ділять на менші — підмережі (subnets, «сабнетс»), як місто на квартали. З 10.0.0.0/16 можна зробити, наприклад:

• 10.0.1.0/24 — квартал для того, що має бути видно з інтернету;
• 10.0.2.0/24 — квартал для серверів із програмою;
• 10.0.3.0/24 — квартал для баз даних.

Кожен такий квартал — 256 адрес, а всього їх у /16 поміститься 256 штук.

Саме так ти будуватимеш мережу в AWS. Дві деталі звідти, які люблять на іспиті:

• розмір мережі в AWS — від /16 (найбільша) до /28 (найменша);
• у кожній підмережі AWS забирає собі 5 адрес (для мережі, роутера, DNS, запасу й «широкомовлення»), тож у /24 вільних лишиться 251.

Чому адреси не можуть перетинатися

Уяви два міста з однаковими адресами: і там, і там є «вулиця Шевченка, 5». Якщо з'єднати їх однією поштою, листоноша не знатиме, в яке місто нести лист.

З мережами так само. Якщо мережа офісу — 10.0.0.0/16, а мережа в AWS — теж 10.0.0.0/16, з'єднати їх напряму неможливо: пакет для 10.0.1.5 не знатиме, куди йти. Тому досвідчені архітектори одразу дають мережам різні діапазони: офіс — 192.168.0.0/16, мережа A — 10.0.0.0/16, мережа B — 10.1.0.0/16. Навіть якщо з'єднувати їх поки не планують.

IPv6 коротко

IPv6 — нова версія адрес: 128 бітів замість 32. Виглядає так: 2001:db8:1f70::5c. Адрес стільки, що кожен пристрій на планеті може мати власну публічну — NAT уже не потрібен.

А як тоді дозволити пристроям виходити назовні, але не пускати гостей усередину? В AWS для IPv6 є окремі «ворота лише на вихід» — Egress-only Internet Gateway. Поки просто запам'ятай: для IPv4 цю роль грає NAT, для IPv6 — egress-only ворота.

📖 Словничок

• IPv4 — звичні адреси з чотирьох чисел від 0 до 255 (32 біти).
• IPv6 — нові 128-бітні адреси, наприклад 2001:db8::5c.
• Публічна адреса — унікальна на весь інтернет.
• Приватна адреса — діє лише всередині мережі: 10.x, 172.16–31.x, 192.168.x.
• NAT («нат») — підміна адрес: багато пристроїв виходять назовні з однієї публічної адреси, ззовні до них не зайти.
• CIDR («сайдер») — запис діапазону: 10.0.0.0/16; адрес = 2^(32 − число після слеша).
• Підмережа (subnet, «сабнет») — менший діапазон усередині мережі, «квартал».
• 0.0.0.0/0 — будь-яка адреса, «увесь інтернет».
• /32 — рівно одна адреса.
• Перетин CIDR — коли діапазони двох мереж спільні; такі мережі напряму не з'єднати.

✅ Головне

• IPv4 — чотири числа від 0 до 255 (32 біти); IPv6 — 128 бітів, адрес вистачить усім.
• Приватні адреси (10.x, 172.16–31.x, 192.168.x) — «внутрішні номери»; публічні — унікальні на весь інтернет.
• NAT випускає багато пристроїв назовні з однієї адреси й не пускає непрохану пошту всередину.
• CIDR: адрес = 2^(32 − N); /16 = 65 536, /24 = 256, /28 = 16; що більше N, то менша мережа. 0.0.0.0/0 — увесь інтернет.
• Мережу ділять на підмережі; діапазони мереж, які можуть з'єднуватися, не повинні перетинатися.

🏗️Як влаштований сучасний застосунок

Три шари: зала, кухня, комора

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

1. Презентація, або фронтенд (frontend, «фронтенд») — зала ресторану. Те, що бачить і чого торкається клієнт: сайт у браузері, мобільний застосунок, кнопки, фото, форма замовлення.
2. Логіка, або бекенд (backend, «бекенд») — кухня. Програма на сервері, яка приймає замовлення, перевіряє, чи є товар, рахує ціну, оформлює доставку. Клієнт її не бачить, але вона робить усю справжню роботу.
3. Дані — комора й журнал замовлень. База даних, де зберігаються клієнти, товари, замовлення, і сховище для файлів (фото тортів, чеки).

Цей малюнок — «трирівнева архітектура» (three-tier). Запам'ятай його: в AWS ти будуватимеш його знову і знову, лише щоразу надійніше й масштабніше. На іспиті він виглядає так: балансувальник → сервери з програмою → база даних.

Моноліт і мікросервіси

Кухню можна організувати двома способами.

• Моноліт — одна велика кухня, де ті самі кухарі печуть торти, варять каву й пакують доставку. Програма одна, велика, усе в ній переплетено. На початку це просто. Але щоб змінити рецепт тістечка, доводиться «зупиняти» всю кухню. А коли кава стала популярною, розширювати доводиться кухню цілком, хоча бракує лише кавоварок.
• Мікросервіси — фудкорт: окремі маленькі кіоски — випічка, кава, доставка, оплата. Кожен має свою команду, оновлюється й розширюється окремо, а між собою кіоски спілкуються через API. Зламалася кавоварка — випічку однаково продають. Ціна за гнучкість: більше «рухомих частин», за якими треба стежити.

На іспиті мікросервіси часто йдуть поруч зі словами decouple («розв'язати» частини), контейнери і serverless — про них у частині про обчислення.

Stateful і stateless: офіціант, що пам'ятає, і дошка замовлень

Це одна з найважливіших ідей усього курсу.

• Stateful («стейтфул», зі станом) — сервер пам'ятає щось про клієнта між запитами. Як офіціант, що тримає твоє замовлення в голові: зручно, але до цього офіціанта доведеться звертатися щоразу, а якщо він піде додому — замовлення зникне.
• Stateless («стейтлес», без стану) — сервер нічого не пам'ятає між запитами. Усе, що треба пам'ятати (кошик, вхід), лежить у спільному місці — на дошці замовлень на кухні (база даних чи швидке сховище в пам'яті). Клієнт приносить лише номерок (cookie), і будь-який офіціант знайде за ним замовлення на дошці.

Чому це вирішальне в хмарі? Бо stateless-сервери можна вільно додавати й прибирати. Прийшов натовп — поставили ще десять серверів, натовп пішов — прибрали. Один сервер зламався — нічого не загубилося: наступний запит обслужить інший. Зі stateful-серверами так не вийде: разом із сервером зникають і кошики клієнтів.

Синхронно чи асинхронно

• Синхронно — як телефонний дзвінок: ти питаєш і чекаєш на лінії, поки не відповідять. Так перевіряють оплату: не можна підтвердити замовлення, поки банк не сказав «так».
• Асинхронно — як повідомлення в месенджері: написав і займаєшся своїми справами, відповідь прийде пізніше. Так надсилають лист-підтвердження, генерують PDF-чек, оновлюють складський облік.

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

Черги й події: як частини системи не заважають одна одній

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

Ця рейка — черга (queue, «к'ю»). Одна частина системи кладе в неї завдання, інша забирає, коли готова. Вони не залежать від швидкості одна одної: це називається розв'язування (decoupling, «декаплінг»).

А подія (event, «івент») — це оголошення «щось сталося»: «нове замовлення №512!». Хто зацікавлений, той реагує: кухня починає пекти, бухгалтерія записує, клієнтові йде SMS. Той, хто оголосив, навіть не знає, скільки слухачів у нього є — і це добре: нового слухача можна додати, нічого не змінюючи.

Черги й події — величезна тема іспиту. Слова «decouple», «buffer», «spikes» (сплески) у питанні майже завжди ведуть до черги.

Масштабування: більша піч чи більше печей

Клієнтів побільшало. Є два шляхи:

• Вертикальне масштабування (scale up, «скейл ап») — купити більшу піч: потужніший сервер. Просто, але є межа (найбільша піч колись закінчиться), і на час заміни піч доведеться вимкнути.
• Горизонтальне масштабування (scale out, «скейл аут») — поставити більше печей: більше серверів, і адміністратора, який розподіляє замовлення між ними (це балансувальник навантаження). Межі практично немає, і одна зламана піч не зупиняє пекарню.

Хмара обожнює горизонтальне масштабування — і воно працює лише зі stateless-серверами. Бачиш, як усе пов'язано?

Єдина точка відмови

Якщо вся пекарня тримається на одній печі, то її поломка зупиняє все. Така деталь називається єдиною точкою відмови (single point of failure, «сингл пойнт оф фейлюр»).

Головна звичка архітектора — шукати такі точки й дублювати їх: дві печі в різних приміщеннях, дві копії бази даних, два входи в будівлю. Про це — ціла частина курсу про надійність.

Логи й метрики: щоденник кухні

Як дізнатися, що щось пішло не так? Досвідчені кухні ведуть журнал:

• Логи (logs, «логз») — записи подій з часом: «12:03 прийнято замовлення №512», «12:04 ПОМИЛКА: оплата не пройшла». Без логів, коли щось ламається, ти сліпий.
• Метрики (metrics) — числа в часі: скільки замовлень за хвилину, наскільки завантажений процесор, скільки помилок. На метрики ставлять тривоги: «якщо помилок більше 10 за хвилину — надіслати SMS».

В AWS цим займається окремий сервіс, схожий на приладову панель автомобіля. Ми до нього дійдемо.

📖 Словничок

• Фронтенд / бекенд — «зала» (що бачить клієнт) / «кухня» (логіка на сервері).
• Трирівнева архітектура (three-tier) — фронтенд + бекенд + дані.
• Моноліт — одна велика програма на все.
• Мікросервіси — багато маленьких незалежних сервісів, що спілкуються через API.
• Stateful / stateless («стейтфул / стейтлес») — сервер пам'ятає клієнта / не пам'ятає, стан лежить окремо.
• Сесія — дані про користувача між запитами: вхід, кошик.
• Синхронно / асинхронно — чекати відповіді на лінії / надіслати й займатися своїм.
• Черга (queue, «к'ю») — «рейка з замовленнями» між частинами системи.
• Подія (event, «івент») — оголошення «щось сталося», на яке реагують зацікавлені.
• Розв'язування (decoupling, «декаплінг») — частини системи не залежать від швидкості й збоїв одна одної.
• Вертикальне / горизонтальне масштабування — більший сервер / більше серверів.
• Балансувальник навантаження — «адміністратор», що розподіляє запити між серверами.
• Єдина точка відмови — деталь, поломка якої зупиняє все.
• Логи / метрики — записи подій / числа в часі.

✅ Головне

• Застосунок = фронтенд (зала) + бекенд (кухня) + дані (комора). На іспиті: балансувальник → сервери → база.
• Моноліт — одна кухня на все; мікросервіси — фудкорт незалежних кіосків.
• Stateless-сервери нічого не пам'ятають самі — тому їх легко додавати, прибирати й замінювати; сесії тримають окремо.
• Черги й події розв'язують частини системи: у пік нічого не губиться, повільне не гальмує швидке.
• Хмара любить горизонтальне масштабування; архітектор шукає й дублює єдині точки відмови; логи й метрики — очі системи.

🗄️Бази даних і кеш з нуля

Навіщо база даних

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

База даних — це картотека з архіваріусом. Дані розкладено за чіткими правилами, пошук миттєвий, а архіваріус стежить, щоб двоє людей не зіпсували одну картку одночасно і щоб ніхто не вписав нісенітницю. Самого «архіваріуса» — програму, яка керує базою, — називають СКБД (система керування базами даних). Найвідоміші: MySQL, PostgreSQL, Oracle, Microsoft SQL Server.

Реляційна база: таблиці, як в Excel

Найпоширеніший вид баз — реляційні (relational, «рілейшнл»). Дані в них лежать у таблицях:

• стовпці — поля: ім'я, телефон, місто;
• рядки — записи: один рядок — один клієнт;
• первинний ключ (primary key) — унікальний номер кожного рядка, як номер паспорта: client_id = 17.

А найцікавіше — зв'язки між таблицями. У таблиці замовлень не пишуть щоразу ім'я й телефон клієнта — лише його номер client_id. Так дані не дублюються, а за потреби таблиці «зшивають» разом. Від цих зв'язків (relations) і походить назва «реляційна».

SQL — мова запитів

З реляційною базою розмовляють мовою SQL (читається «ес-к'ю-ел» або «сіквел», Structured Query Language). Вона дуже схожа на звичайні англійські речення:

SELECT name, phone
FROM clients
WHERE city = 'Львів';

Читається так: «вибери ім'я і телефон з таблиці клієнтів, де місто — Львів». Ще кілька слів: INSERT — додати запис, UPDATE — змінити, DELETE — видалити, JOIN — зшити таблиці («покажи замовлення разом з іменами клієнтів»).

Писати SQL для іспиту не треба. Але треба знати: SQL, таблиці, JOIN — це реляційні бази.

Транзакція: все або нічого

Уяви переказ грошей з одного рахунку на інший. Це дві дії: зняти гроші з першого рахунку і додати на другий. А якщо світло вимкнеться між ними? Гроші зникнуть!

Щоб такого не траплялося, бази вміють транзакції — групу дій, яка виконується повністю або ніяк. Реляційні бази дають чотири гарантії, які називають ACID («ейсид»):

• Atomicity — атомарність: усе або нічого;
• Consistency — узгодженість: правила бази не порушуються;
• Isolation — ізольованість: одночасні операції не змішуються;
• Durability — довговічність: якщо база сказала «збережено», дані не зникнуть навіть при збої.

Тому гроші, замовлення, склад — класична робота для реляційних баз.

Схема: бланк, надрукований заздалегідь

Реляційна таблиця вимагає наперед визначити стовпці — схему. Це як друкований бланк: є поле «ім'я», «телефон», «місто» — і нічого іншого вписати не можна. Порядок і передбачуваність — сила таких баз. Але якщо в одного товару 3 характеристики, а в іншого 30, бланк стає незручним.

NoSQL: коли таблиці тісні

NoSQL («ноу-ес-к'ю-ел», «не лише SQL») — загальна назва баз, які зберігають дані не в класичних таблицях. Найважливіші види:

• Ключ-значення (key-value) — шафка з номерками в гардеробі: даєш номер (ключ) — миттєво отримуєш вміст. Ідеально для мільйонів простих швидких запитів: кошики, сесії, профілі гравців.
• Документні — кожен запис — окремий документ (часто в JSON) зі своїм набором полів. У торта — «кількість ярусів», у кави — «ступінь обсмаження», і нікому це не заважає.
• Графові — карта знайомств: головне не записи, а зв'язки між ними. «Друзі друзів», «хто купував разом із цим», ланцюжки шахраїв.
• Часових рядів (time series) — показники з мітками часу: температура в печі щосекунди, дані датчиків.

Коротке правило вибору:

• складні зв'язки, JOIN, транзакції з грошима → реляційна база;
• величезний масштаб, прості запити за ключем, гнучка структура → NoSQL.

OLTP і OLAP: касир і бухгалтер

Бази даних працюють у двох дуже різних режимах:

• OLTP («оу-ел-ті-пі», online transaction processing) — касир: тисячі маленьких швидких операцій щосекунди. «Продати круасан», «записати замовлення», «змінити адресу».
• OLAP («оу-лап», online analytical processing) — бухгалтер наприкінці року: небагато, але величезних запитів по всій історії. «Продажі кожного товару по місяцях за п'ять років».

Касирові й бухгалтерові потрібні різні інструменти. Для OLTP використовують звичайні бази (реляційні чи NoSQL), а для OLAP — спеціальні сховища даних (data warehouse), які вміють швидко перемелювати мільярди рядків. На іспиті: «аналітика по всій історії, складні звіти» → сховище даних, а не основна база сайту.

Кеш: записник на столі

Деякі питання до бази повторюються тисячі разів: «що сьогодні в меню?», «скільки коштує круасан?». Бігати щоразу в архів — марнувати час.

Кеш (cache, «кеш») — записник на столі з відповідями на часті питання. Він тримає дані в пам'яті (пам'ятаєш — швидкий «робочий стіл»), тому відповідає в десятки й сотні разів швидше за базу, а база відпочиває.

Слабке місце кешу — застарілі дані: ціна в базі змінилася, а в записнику ще стара. Тому записам у кеші дають «строк придатності» — TTL, як у DNS: минув строк — запис викидають і наступного разу беруть свіжий з бази.

Репліка і бекап: копія копії не рівня

Дані дорогоцінні, тому їх копіюють. Але копії бувають принципово різні.

• Репліка (replica, «репліка») — жива копія бази на іншому сервері, яка постійно оновлюється. Як колега, що паралельно веде такий самий журнал. Зламався основний сервер — перемикаємося на копію. А ще з репліки можна читати, розвантажуючи основну базу.
• Бекап (backup, «бекап») — фотографія даних на певний момент, яка зберігається окремо. Сама вона не оновлюється.

Реплікація буває двох видів:

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

Ця різниця — основа цілої групи питань іспиту: коли потрібна копія для виживання, коли — для швидкого читання, а коли — бекап.

📖 Словничок

• База даних — впорядковане сховище даних зі швидким пошуком і правилами.
• СКБД — програма-«архіваріус», що керує базою (MySQL, PostgreSQL, Oracle…).
• Реляційна база («рілейшнл») — таблиці зі зв'язками між ними.
• Таблиця / рядок / стовпець — «аркуш» / один запис / одне поле.
• Первинний ключ (primary key) — унікальний номер запису.
• SQL («ес-к'ю-ел», «сіквел») — мова запитів до реляційних баз.
• JOIN — «зшити» таблиці в одному запиті.
• Транзакція / ACID («ейсид») — група дій «все або нічого» / чотири гарантії надійності.
• Схема — заздалегідь визначений набір стовпців, «бланк».
• NoSQL — бази без класичних таблиць: ключ-значення, документи, графи, часові ряди.
• OLTP / OLAP — «касир» (багато дрібних операцій) / «бухгалтер» (великі аналітичні запити).
• Сховище даних (data warehouse) — база для важкої аналітики по всій історії.
• Кеш — швидкий «записник» у пам'яті для частих відповідей; TTL — строк придатності запису.
• Репліка — жива копія бази; синхронна (точна) чи асинхронна (з невеликим запізненням).
• Бекап — знімок даних на момент часу; рятує від помилок і видалень.

✅ Головне

• База даних — «картотека з архіваріусом»: швидкий пошук, правила, захист від одночасних змін.
• Реляційні бази: таблиці, ключі, SQL, JOIN, транзакції ACID — для грошей, замовлень, складних зв'язків.
• NoSQL: ключ-значення, документи, графи, часові ряди — для величезного масштабу й гнучкої структури.
• OLTP — «касир» (основна база застосунку); OLAP — «бухгалтер» (сховище даних для аналітики).
• Кеш — швидкий записник у пам'яті з TTL; репліка — жива копія (синхронна або асинхронна); бекап — знімок у минулому. Від помилок рятує лише бекап.

🏭Сервери й дата-центри: де живе інтернет

Як виглядає сервер

Сервер — це комп'ютер без екрана, клавіатури й миші. Зазвичай це плаский металевий ящик, трохи схожий на коробку від піци. Усередині те саме, що й у будь-якому комп'ютері, — процесори, пам'ять, диски, — тільки потужніше і з запасом:

• кілька процесорів з десятками ядер;
• сотні гігабайтів оперативної пам'яті;
• багато дисків;
• два блоки живлення — якщо один згорить, другий підхопить;
• кілька мережевих карт для швидкого зв'язку.

Сервери не стоять на столах. Їх вставляють у стійки (rack, «рек») — високі металеві шафи з полицями, по кілька десятків серверів у кожній. Працює сервер цілодобово, роками.

Дата-центр: місто серверів

Дата-центр — будівля, в якій тисячі стійок. Звучить просто, але щоб сервери працювали без перерви, будівля мусить уміти дуже багато:

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

Збудувати такий дата-центр коштує сотні мільйонів доларів. Утримувати — теж недешево. Тому своїми дата-центрами володіють переважно великі компанії й провайдери — такі як AWS.

«Свій сервер у підсобці» — on-premises

Коли компанія тримає сервери у власному приміщенні чи власному дата-центрі, це називають on-premises (читається «он-преміс», часто скорочують до «он-прем») — «на своїй території». Це слово ти зустрічатимеш на іспиті постійно: «компанія має on-premises дата-центр і хоче…».

Що насправді означає Олина підсобка:

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

А найскладніше — вгадати потужність. Скільки серверів купувати? Замало — сайт упаде в Чорну п'ятницю, коли всі кинуться купувати торти. Забагато — решту року дорогі сервери гудітимуть вхолосту.

Усе ламається — завжди

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

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

Кроки до хмари

Між «підсобкою» і хмарою є проміжні сходинки:

• колокація — ставиш своє залізо в чужий професійний дата-центр і платиш за місце, живлення й інтернет;
• хостинг — орендуєш цілий сервер у провайдера на місяці.

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

Гібрид: трохи тут, трохи там

Багато компаній не переносять усе в хмару одразу. Частина систем лишається on-premises, частина працює в хмарі, і вони з'єднані між собою. Це називається гібридна інфраструктура (hybrid, «гайбрід»). На іспиті ціла група питань про те, як з'єднати офіс із хмарою, як переносити дані й як жити на два доми.

📖 Словничок

• Сервер — потужний комп'ютер без екрана, що працює цілодобово.
• Стійка (rack, «рек») — металева шафа з полицями для серверів.
• Дата-центр — будівля з тисячами стійок, живленням, охолодженням, мережею й охороною.
• On-premises («он-преміс», «он-прем») — власні сервери компанії на її території.
• Колокація / хостинг — місце для свого заліза в чужому дата-центрі / оренда цілого сервера.
• Дублювання (redundancy, «рідандансі») — запасні копії всього важливого, щоб поломка нічого не зупинила.
• Гібридна інфраструктура («гайбрід») — частина систем on-premises, частина в хмарі.

✅ Головне

• Сервер — потужний комп'ютер без екрана в стійці; дата-центр — тисячі стійок з живленням, охолодженням, мережею й охороною.
• On-premises — власні сервери: гроші наперед, тижні очікування, утримання й чергування.
• Потужність доводиться вгадувати: замало — падіння в пік, забагато — гроші на вітер.
• Обладнання ламається завжди; надійність — це дублювання всього важливого.
• Гібрид — частина on-premises, частина в хмарі.

🪆Віртуалізація, контейнери і serverless: як один сервер стає сотнею

Проблема: сервери нудьгують

Звичайний фізичний сервер більшу частину часу завантажений на 10–20%. Уяви величезний будинок, у якому живе одна людина: решта кімнат порожні, а платити за опалення доводиться за все.

А що, як один потужний сервер поділити між багатьма клієнтами — так, щоб кожен думав, що має власний окремий комп'ютер?

Гіпервізор і віртуальні машини: багатоквартирний будинок

Саме це робить віртуалізація. На фізичний сервер ставлять особливу програму — гіпервізор (hypervisor, «гіпервайзор»). Він ділить залізо на кілька віртуальних машин (VM, «ві-ем»):

• у кожної — свої віртуальні процесори (vCPU), своя пам'ять, свій диск;
• на кожній — своя операційна система: на одній Linux, на сусідній Windows;
• машини ізольовані: одна не бачить і не може зачепити іншу.

Образ — багатоквартирний будинок. Будівля одна (фізичний сервер), а квартир багато (віртуальні машини). У кожної квартири свої стіни, двері й замок. Керуючий будинку (гіпервізор) розподіляє воду й електрику (процесор і пам'ять) і стежить, щоб сусіди не лазили одне до одного.

Віртуальний сервер в AWS називається інстанс EC2 (instance — «екземпляр»; EC2 читається «і-сі-ту»). Гіпервізор AWS називається Nitro («найтро») — це поєднання спеціального заліза й дуже легкої програми, завдяки якому віртуальні машини працюють майже так само швидко, як «голе» залізо.

Що дає віртуалізація

• Швидкість. Нова «квартира» готова за хвилини, а не за тижні доставки заліза.
• Знімки й клони. Стан цілої машини можна «сфотографувати» й створити з цього знімка десять однакових машин. В AWS такий шаблон називається AMI — до нього дійдемо.
• Гнучкість. Потрібно більше пам'яті — переїжджаєш у більшу «квартиру».
• Економія. Залізо завантажене щільно, тому кожна квартира коштує недорого.

Контейнери: морські контейнери для програм

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

Тут з'являються контейнери (containers, «контейнерз»). Контейнер не має власної повної ОС — він користується ядром спільної операційної системи хоста й везе лише саму програму та все, що їй потрібно (бібліотеки, налаштування). Тому контейнер важить мегабайти і стартує за секунди.

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

Два слова, які варто розрізняти:

• образ (image, «імідж») — «креслення» контейнера: програма й усе потрібне, запаковане в один файл;
• контейнер — запущений образ, що працює просто зараз (як процес і програма).

Найвідоміший інструмент для контейнерів — Docker («докер»). В AWS є окремі сервіси, які запускають і доглядають тисячі контейнерів, — про них у частині про обчислення.

Serverless: код без турботи про сервери

Наступна сходинка — serverless («сервер-лес», «без серверів»). Ти не орендуєш ні машину, ні контейнер. Ти даєш хмарі лише код — функцію — і кажеш, коли її запускати: «коли клієнт натисне "Замовити"», «коли з'явиться нове фото».

• Код запускається лише на подію і працює, поки виконує задачу.
• Платиш за мілісекунди роботи. Немає подій — немає витрат.
• Прийшла тисяча подій одночасно — хмара сама запустить тисячу копій.

«Без серверів» не означає, що серверів немає. Вони є, але це не твоя турбота: ні встановлювати, ні латати, ні масштабувати. В AWS головний serverless-сервіс називається Lambda («лямбда»).

Сходинки: хто за що відповідає

Зведемо все в одну картину — від найбільшого контролю до найменшого клопоту. Образ — житло:

• Власний сервер (on-premises) — власний будинок: усе твоє, і все лагодиш ти.
• Віртуальна машина — орендована квартира: будинок доглядає власник, а меблі, замки й порядок усередині — твої. Ти ставиш і латаєш операційну систему.
• Контейнери на керованій платформі — номер у готелі: приходиш зі своїми речами (образом), а все інше вже готове.
• Serverless — таксі: не володієш машиною, не ремонтуєш, платиш лише за поїздку.

На іспиті ця драбинка з'являється як «least operational overhead» — «найменше клопоту з експлуатацією». Що вище сходинка (ближче до serverless і керованих сервісів), то менше клопоту — і тим частіше саме така відповідь правильна.

📖 Словничок

• Віртуалізація — поділ одного фізичного сервера на багато ізольованих віртуальних.
• Гіпервізор («гіпервайзор») — програма-«керуючий будинку», що ділить залізо між VM.
• Віртуальна машина, VM («ві-ем») — «квартира»: свої vCPU, пам'ять, диск і ОС.
• Інстанс EC2 («і-сі-ту») — віртуальний сервер в AWS.
• Nitro («найтро») — гіпервізор і спеціальне залізо AWS.
• Контейнер — легка упаковка програми, що ділить ядро ОС з іншими; стартує за секунди.
• Образ (image, «імідж») — «креслення» контейнера чи машини.
• Docker («докер») — найвідоміший інструмент для контейнерів.
• Serverless («сервер-лес») — даєш лише код, провайдер запускає його на подію; оплата за час роботи.
• Lambda («лямбда») — головний serverless-сервіс AWS.
• Operational overhead — «клопіт з експлуатацією»: патчі, масштабування, нагляд.

✅ Головне

• Гіпервізор ділить фізичний сервер на ізольовані віртуальні машини — «квартири» в будинку. В AWS VM — це інстанс EC2.
• Контейнер — «морський контейнер» для програми: без власної ОС, легкий, стартує за секунди, працює однаково будь-де.
• Serverless — даєш лише код; він запускається на подію, оплата за мілісекунди. В AWS — Lambda.
• Драбинка: власний сервер → VM → контейнери на платформі → serverless — що вище, то менше клопоту.
• «Least operational overhead» на іспиті → керовані й serverless-сервіси.

☁️Що таке хмара і чому всі туди переїжджають

Що таке хмара — точно

AWS визначає хмару так: надання ІТ-ресурсів на вимогу через інтернет з оплатою за використане (on-demand delivery of IT resources over the internet with pay-as-you-go pricing). Розберемо на шматочки:

• ІТ-ресурси — обчислювальна потужність, сховище, бази даних, мережа, готові сервіси.
• На вимогу — натискаєш кнопку (або програма робить запит) і отримуєш ресурс за хвилини. Без дзвінків, договорів і доставки.
• Через інтернет — керуєш усім здалеку, з браузера чи з коду.
• Плата за використане (pay-as-you-go, «пей-ез-ю-гоу») — як за електрику: ти не будуєш електростанцію, а платиш за кіловат-години. Вимкнеш — лічильник зупиниться.

Шість переваг хмари

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

1. Змінні витрати замість великих вкладень наперед. Не купуєш сервери на три роки вперед (капітальні витрати, CapEx), а платиш щомісяця за спожите (операційні витрати, OpEx).
2. Економія на масштабі. AWS купує мільйони серверів і терабайти дисків дешевше, ніж будь-хто окремо, — і ця знижка потрапляє в ціни.
3. Не треба вгадувати потужність. Замало — додаєш за хвилини, забагато — прибираєш.
4. Швидкість і гнучкість. Нові ресурси — за хвилини, тому експериментувати дешево: спробуєш, не підійде — видалиш.
5. Не витрачаєш гроші на дата-центри. Кондиціонери, генератори й охорону бере на себе AWS, а ти зосереджуєшся на своєму бізнесі — випічці.
6. Глобально за хвилини. Відкрити сайт для клієнтів у Японії, не їдучи до Японії.

Масштабованість і еластичність

Ці слова схожі, але не однакові:

• Масштабованість (scalability, «скейлабіліті») — система вміє рости: витримати вдесятеро більше клієнтів, додавши ресурсів.
• Еластичність (elasticity, «еластісіті») — ресурси автоматично ростуть і зменшуються разом з попитом, як гармошка. Удень десять серверів, уночі — два, і платиш саме за це.

Саме еластичність — головний «фокус» хмари, якого не дасть жодна підсобка. На іспиті вона ховається за словами «unpredictable traffic», «spikes», «scale automatically».

IaaS, PaaS, SaaS: скільки роботи бере провайдер

Хмарні послуги поділяють на моделі — за тим, скільки роботи провайдер бере на себе. Пояснимо на пекарні:

• Власна пекарня (on-premises) — усе власноруч: будуєш піч, купуєш обладнання, печеш і прибираєш.
• IaaS («ай-ес», Infrastructure as a Service — інфраструктура як послуга) — орендуєш обладнану кухню: піч, столи, електрика є, а тісто, рецепти й випічка — твої. В AWS: віртуальні сервери EC2 — ОС, програми й дані на тобі.
• PaaS («пес», Platform as a Service — платформа як послуга) — орендуєш кухню з кухарями: приносиш лише рецепт, решту роблять вони. В AWS: платформи, куди просто завантажуєш код, і керовані бази даних, які AWS встановлює й латає сам.
• SaaS («сас», Software as a Service — програма як послуга) — купуєш готові круасани в іншій пекарні: просто користуєшся. Приклади: пошта в браузері, відеозв'язок, онлайн-бухгалтерія.

Serverless-функції (як Lambda) іноді виділяють в окрему модель — FaaS («функція як послуга»): ти даєш тільки код однієї функції.

Публічна, приватна, гібридна

• Публічна хмара — AWS, Azure, Google Cloud: ресурси для всіх охочих, кожен клієнт ізольований.
• Приватна хмара — хмарні технології у власному дата-центрі компанії, лише для неї.
• Гібридна — поєднання: частина систем on-premises, частина в публічній хмарі, з'єднані між собою. Дуже поширено у великих компаніях і на іспиті.
• Мультихмара (multi-cloud) — кілька провайдерів одночасно.

Чого хмара не зробить за тебе

Хмара дає будівельні блоки: надійні, швидкі, безпечні. Але вона не збере з них правильну систему автоматично. Якщо поставити один сервер в одному дата-центрі й відкрити його всьому інтернету, хмара не врятує ні від падіння, ні від злому.

Будувати з блоків правильно — робота архітектора. Тобто твоя. Далі ми вивчатимемо блоки AWS один за одним і вчитимемося їх поєднувати.

📖 Словничок

• Хмара (cloud, «клауд») — ІТ-ресурси на вимогу через інтернет з оплатою за використане.
• Pay-as-you-go («пей-ез-ю-гоу») — платиш за фактичне споживання, як за електрику.
• CapEx / OpEx («кепекс / опекс») — великі вкладення наперед / поточні витрати за спожите.
• Масштабованість (scalability) — уміння рости під більше навантаження.
• Еластичність (elasticity) — автоматичне збільшення й зменшення ресурсів разом з попитом.
• IaaS («ай-ес») — оренда інфраструктури: віртуальні сервери, мережа, диски.
• PaaS («пес») — платформа: приносиш код, решту робить провайдер.
• SaaS («сас») — готова програма, якою просто користуєшся.
• Публічна / приватна / гібридна хмара — для всіх / лише для однієї компанії / поєднання on-premises і хмари.

✅ Головне

• Хмара — ІТ-ресурси на вимогу, через інтернет, з оплатою за використане.
• Шість переваг: змінні витрати, економія на масштабі, не вгадувати потужність, швидкість, без утримання дата-центрів, глобально за хвилини.
• Еластичність — ресурси автоматично ростуть і зменшуються з попитом; масштабованість — уміння рости.
• IaaS (обладнана кухня) → PaaS (кухня з кухарями) → SaaS (готові круасани).
• Хмара дає блоки, а правильну систему з них будує архітектор.

🗺️AWS по всьому світу: регіони, зони доступності й edge

Регіон — місто AWS

AWS розмістив свої дата-центри в різних куточках світу. Групу дата-центрів в одній географічній місцевості називають регіоном (region, «ріджн»). Образ з простого курсу: регіон — окреме місто AWS. Таких міст — понад три десятки, і їх постійно більшає.

Кожен регіон має код з трьох частин: частина світу — напрямок — номер:

Регіону в Україні немає. Для українських проєктів найчастіше обирають Франкфурт (eu-central-1) — він близько й має всі сервіси.

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

Зона доступності — окремий район міста

Усередині кожного регіону є кілька (зазвичай три й більше) зон доступності — Availability Zones, або скорочено AZ («ей-зі»). Кожна AZ — це один або кілька дата-центрів з власним живленням, охолодженням і мережею. Зони розташовані на відстані одна від одної — досить великій, щоб пожежа, повінь чи збій електромережі в одній не зачепили інші, і досить малій, щоб між ними була дуже швидка приватна мережа.

Образ: регіон — місто, AZ — окремі райони зі своїми електростанціями. Якщо в одному районі вимкнули світло, інші живуть як жили.

Зони називають кодом регіону з літерою в кінці: eu-central-1a, eu-central-1b, eu-central-1c.

З цього випливає найголовніше правило надійності в AWS:

• щоб пережити аварію одного дата-центру — розміщуй систему щонайменше у двох AZ;
• щоб пережити катастрофу цілого регіону (рідко, але буває) — потрібен другий регіон.

Як обирати регіон

Чотири причини, які варто пам'ятати в такому порядку:

1. Закон і вимоги (compliance, «комплаєнс»). Якщо регулятор вимагає, щоб дані лишалися в країні чи в ЄС, — вибір уже зроблено.
2. Близькість до користувачів (latency). Ти пам'ятаєш: довга дорога — довга відповідь. Клієнти у Львові — Франкфурт, клієнти в Канаді — канадський регіон.
3. Потрібні сервіси. Не кожен сервіс є в кожному регіоні, особливо нові.
4. Ціна. У різних регіонах ціни трохи відрізняються.

Edge locations — кіоски біля людей

Регіонів кілька десятків, а міст, де живуть люди, — тисячі. Тому AWS поставив ще й сотні маленьких точок присутності у великих містах — edge locations («едж локейшнз»), або просто edge («край»). Образ — кіоски біля людей: у них не запускають твої сервери, зате там кешують контент і приймають трафік якомога ближче до користувача.

На edge працюють сервіси для швидкості всього світу: мережа доставки контенту CloudFront, DNS Route 53 і Global Accelerator. До них дійдемо в частині про мережу.

Особливі «філії» AWS

• Local Zones («локал зоунз») — AWS у великому місті: частина сервісів розміщена просто в мегаполісі, щоб затримка для мешканців була одноцифровою в мілісекундах. Для ігор, стрімінгу, обробки відео.
• Wavelength («вейвленс») — AWS усередині 5G-мережі мобільного оператора: наднизька затримка для телефонів і пристроїв.
• Outposts («аутпостс») — стійка AWS у твоєму власному дата-центрі: ті самі сервіси й інструменти, але обладнання фізично стоїть у тебе. Для випадків, коли дані мусять лишатися on-premises.

Глобальні, регіональні й зональні сервіси

Сервіси AWS живуть на різних «рівнях». Від цього залежить, де вони доступні й що переживуть.

• Глобальні — одні на весь світ: керування користувачами й правами (IAM), DNS (Route 53), доставка контенту (CloudFront).
• Регіональні — живуть в одному регіоні, але самі розподіляються по його зонах: сховище S3, бази DynamoDB, черги SQS, функції Lambda. Більшість сервісів — саме такі.
• Зональні — прив'язані до однієї AZ: віртуальний сервер EC2, його диск EBS, підмережа.

Особливий регіон us-east-1

Північна Вірджинія (us-east-1) — найстаріший і найбільший регіон AWS. Нові сервіси часто з'являються саме тут, а деякі глобальні речі «прописані» саме в ньому. Один факт звідси точно буде на іспиті: сертифікат для HTTPS у CloudFront треба створювати в us-east-1. Поки просто запам'ятай, що цей регіон особливий.

📖 Словничок

• Регіон (region, «ріджн») — «місто AWS»: група дата-центрів у одній місцевості, напр. eu-central-1.
• Зона доступності, AZ («ей-зі») — «район»: один або кілька дата-центрів зі своїм живленням і мережею.
• Висока доступність (high availability) — система працює, навіть коли одна частина зламалася; в AWS — кілька AZ.
• Compliance («комплаєнс») — вимоги законів і регуляторів.
• Edge location («едж локейшн») — «кіоск» біля людей для кешування й прийому трафіку.
• Local Zones / Wavelength / Outposts — AWS у мегаполісі / у 5G-мережі / у твоєму дата-центрі.
• Глобальний / регіональний / зональний сервіс — один на світ / в одному регіоні / в одній AZ.

✅ Головне

• Регіон — «місто AWS» (eu-central-1 — Франкфурт); дані не покидають регіон без твоєї команди.
• AZ — «райони» з окремим живленням і мережею; висока доступність = щонайменше дві AZ, катастрофа регіону — другий регіон.
• Регіон обирають за законом, близькістю до людей, наявністю сервісів і ціною.
• Edge — кіоски біля людей; Local Zones — мегаполіс, Wavelength — 5G, Outposts — твій дата-центр.
• Сервіси бувають глобальні (IAM, Route 53, CloudFront), регіональні (S3, DynamoDB, Lambda) і зональні (EC2, EBS).

🔑Як виглядає AWS зсередини: акаунт, консоль, API і рахунки

Акаунт — твоя ділянка в місті AWS

Акаунт AWS (account) — це твоя окрема ділянка в місті AWS: усе, що ти створиш (сервери, сховища, бази), належить акаунту, а рахунок за це приходить йому. Акаунти ізольовані: з одного акаунта не видно ресурсів іншого, якщо спеціально не дозволити.

У кожного акаунта є номер з 12 цифр — Account ID, наприклад 123456789012.

Той, хто створив акаунт (email і пароль), — root user («рут юзер»): власник з майстер-ключем від усього. Пам'ятаєш правило з розділу про операційні системи? Майстер-ключем щодня не користуються. Для щоденної роботи створюють окремих користувачів з обмеженими правами — про це весь наступний розділ про безпеку. А root захищають MFA — другим «замком» (кодом з телефона).

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

Три способи керувати AWS

1. Консоль (AWS Management Console) — вебсайт з кнопками, таблицями й майстрами налаштування. Зручно, щоб роздивитися й навчитися.
2. CLI («сі-ел-ай») — командний рядок. Наприклад, команда aws s3 ls покаже всі твої сховища S3.
3. SDK («ес-ді-кей») — бібліотеки для мов програмування (Python, JavaScript, Java…). Програма сама створює й змінює ресурси.

А тепер головне: під капотом усі три способи роблять одне й те саме — викликають API AWS. Кнопка в консолі, команда в CLI і рядок коду перетворюються на однаковий захищений запит HTTPS до AWS: «створи сервер», «покажи список файлів».

З цього випливають дві суперсили хмари:

• Усе можна автоматизувати. Будь-яку дію, яку можна зробити мишкою, можна записати в код і повторити тисячу разів.
• Усе можна записати. Кожен виклик API можна зафіксувати в журналі: хто, коли, звідки і що саме зробив. Сервіс, що веде цей журнал, називається CloudTrail — ти зустрінеш його в частині про безпеку.

Регіон у консолі: найчастіша пастка новачків

Угорі консолі є перемикач регіону. Усе, що ти створюєш, з'являється в поточному обраному регіоні.

Класична історія: «Вчора створили сервер, а сьогодні його немає!» — а він є, просто консоль відкрилася в іншому регіоні. Спершу перевір регіон — потім панікуй.

ARN — повна адреса ресурсу

Кожен ресурс в AWS має унікальну повну адресу — ARN («ей-ар-ен», Amazon Resource Name). Вона схожа на поштову адресу, де вказано все: країну, місто, вулицю, будинок.

arn:aws:s3:::khmarynka-photos — сховище S3 з назвою khmarynka-photos. arn:aws:iam::123456789012:user/olia — користувачка olia в акаунті 123456789012.

Будова: arn : розділ : сервіс : регіон : акаунт : ресурс. Деякі частини можуть бути порожніми (у S3 немає регіону й акаунта в ARN, бо назви сховищ унікальні на весь світ).

Навіщо це? У правилах доступу пишуть саме ARN: «користувачці olia дозволено читати arn:aws:s3:::khmarynka-photos/*». Скоро ти читатимеш такі правила.

Теги — ярлики на ресурсах

До будь-якого ресурсу можна причепити теги (tags) — ярлики «ключ = значення»:

• project = site
• env = prod (робоче середовище) або env = test
• owner = taras

Теги допомагають знайти ресурси, розподілити витрати («скільки коштує сайт, а скільки тести?») і навіть керувати доступом («розробникам можна чіпати лише ресурси з env = test»).

Квоти — ліміти акаунта

У кожного сервісу є квоти (Service Quotas) — ліміти на акаунт у регіоні: скільки серверів можна запустити, скільки функцій одночасно тощо. Вони захищають і тебе (від випадкового запуску тисячі серверів), і AWS. Більшість квот — «м'які»: їх можна підняти запитом.

Як AWS рахує гроші

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

• обчислення — за секунди чи години роботи серверів і функцій;
• зберігання — за гігабайти на місяць;
• запити — за кожну тисячу чи мільйон звернень до деяких сервісів;
• передача даних — вхід в AWS безкоштовний, а вихід в інтернет і переміщення між зонами та регіонами — платні.

Рахунок приходить щомісяця, а поточні витрати видно в розділі Billing and Cost Management.

Як вчитися безкоштовно

Нові акаунти (з липня 2025 року) отримують безкоштовний план (Free plan) приблизно на 6 місяців: 100 доларів кредитів одразу і ще до 100 доларів — за виконання кількох навчальних кроків (запустити сервер, створити базу даних, функцію, спробувати генеративний AI і налаштувати бюджет). На безкоштовному плані AWS не знімає грошей з картки; коли кредити чи 6 місяців закінчуються, акаунт пропонують перевести на платний план, інакше його закривають. Деякі дорогі сервіси на безкоштовному плані недоступні. Умови можуть змінюватися — актуальні завжди на сторінці aws.amazon.com/free.

Звідси порада для навчання: навчальний акаунт — для експериментів, а не для важливих даних.

Як не отримати рахунок-сюрприз

1. Налаштуй AWS Budgets — «сторожа витрат», який напише на пошту, коли витрати чи їхній прогноз перевищать заданий поріг.
2. Прибирай за собою. Експеримент закінчено — видали сервер, базу, диск. Зупинений сервер може далі коштувати за диски.
3. Увімкни MFA для root і не користуйся root щодня.
4. Ніколи не публікуй ключі доступу (про них у розділі про безпеку). Боти цілодобово шукають у відкритих репозиторіях випадково викладені ключі AWS і за лічені хвилини запускають на чужі гроші майнинг криптовалют.

📖 Словничок

• Акаунт AWS — «ділянка»: контейнер для всіх ресурсів і рахунків; номер з 12 цифр.
• Root user («рут юзер») — власник акаунта з повною владою; захищають MFA і не використовують щодня.
• MFA («ем-еф-ей») — багатофакторна автентифікація: пароль + код з телефона.
• Консоль / CLI / SDK — кнопки / команди / бібліотеки для коду; усі викликають API.
• API-виклик — запит до AWS «зроби те-то»; кожен можна записати в журнал.
• ARN («ей-ар-ен») — повна унікальна адреса ресурсу.
• Тег — ярлик «ключ = значення» на ресурсі.
• Service Quotas — ліміти сервісів в акаунті й регіоні; більшість можна підняти.
• AWS Budgets — «сторож витрат»: сповіщення про перевищення бюджету чи прогнозу.
• Free plan — безкоштовний навчальний план для нових акаунтів з кредитами.

✅ Головне

• Акаунт — ізольована «ділянка» з усіма ресурсами й рахунками; root — майстер-ключ, під MFA і не щодня.
• Консоль, CLI, SDK — три входи до одного API: усе можна автоматизувати й записати в журнал.
• Ресурси створюються в поточному регіоні; ARN — повна адреса ресурсу; теги — ярлики для пошуку, витрат і доступу; квоти — ліміти, які можна підняти.
• Платиш за обчислення, зберігання, запити й вихідний трафік; вхід в AWS безкоштовний.
• Безпека гаманця: Budgets, прибирати за собою, MFA на root, ніколи не публікувати ключі.

⚖️Словник архітектора: надійність, швидкість, безпека, ціна

Доступність і «дев'ятки»

Доступність (availability, «евейлабіліті») — яку частку часу система працює. Її міряють у відсотках, а говорять «дев'ятками»:

Кожна дев'ятка дається все дорожче: щоб з 99,9% стало 99,99%, треба дублювати вже не лише сервери, а й бази, мережу, цілі зони. Тому архітектор завжди питає: скільки простою бізнес справді може собі дозволити? Пекарні 99,9% вистачить з головою, банку — ні.

Обіцянку провайдера щодо доступності записують в SLA («ес-ел-ей», Service Level Agreement — угода про рівень обслуговування).

Надійність зберігання: чи не загубляться дані

Надійність зберігання (durability, «дюрабіліті») — наскільки ймовірно, що збережені дані не загубляться. Сховище S3 обіцяє одинадцять дев'яток — 99,999999999%. Образно: з 10 мільйонів файлів у середньому губиться один за 10 000 років.

Висока доступність, відмовостійкість і аварійне відновлення

Три схожі, але різні поняття:

• Висока доступність (high availability, HA) — запасне колесо: щось зламалося, коротка зупинка — і їдемо далі. Користувач може помітити паузу в кілька секунд чи хвилину.
• Відмовостійкість (fault tolerance, «фолт толеранс») — двомоторний літак: один мотор відмовив, а політ триває взагалі без перерви. Дорожче, бо все працює в подвійному екземплярі постійно.
• Аварійне відновлення (disaster recovery, DR, «ді-ар») — план на випадок пожежі в цілому місті: як повернути систему, якщо зник цілий регіон.

Для DR є два числа, які ти зустрічатимеш у десятках питань:

• RPO («ар-пі-оу», Recovery Point Objective) — скільки даних можна втратити. «Не шкода останніх 15 хвилин замовлень» → RPO = 15 хвилин.
• RTO («ар-ті-оу», Recovery Time Objective) — скільки часу можна простояти. «За годину сайт має знову приймати замовлення» → RTO = 1 година.

Мнемоніка: P — Point, точка в минулому, до якої повернемося (дані). T — Time, час простою.

Масштабованість, продуктивність і IOPS

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

• затримка (latency) — за скільки мілісекунд приходить відповідь;
• пропускна здатність (throughput, «сру-пут») — скільки запитів чи мегабайтів за секунду система переробляє;
• IOPS («ай-опс», input/output operations per second) — скільки окремих операцій читання чи запису за секунду робить диск. Образ: скільки коробок за секунду комірник виносить із комори. Для баз даних, де багато дрібних операцій, IOPS — головне.

Безпека: три букви CIA

Безпеку в ІТ часто описують трьома буквами CIA (не розвідка!):

• Confidentiality — конфіденційність: чужі не прочитають;
• Integrity — цілісність: ніхто не змінить непомітно;
• Availability — доступність: система працює, коли потрібна (наприклад, не впала від атаки).

І два принципи, які ти бачитимеш у правильних відповідях постійно:

• мінімальні права (least privilege, «ліст привілідж») — кожен отримує рівно ті права, що потрібні для роботи, і не більше;
• захист на всіх рівнях (defense in depth) — не одні двері з замком, а кілька рубежів: огорожа, двері, сейф, сигналізація.

Вартість: найдешевше, що виконує все

У хмарі платиш за використане, тому економія — це правильний вибір: потрібний розмір, потрібний спосіб оплати, вимикати непотрібне. Але на іспиті є важливе правило:

Хто за що відповідає: модель спільної відповідальності

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

У хмарі так само. Це називається модель спільної відповідальності (Shared Responsibility Model):

• AWS відповідає за безпеку хмари (security OF the cloud): будівлі дата-центрів, залізо, мережу, гіпервізор, внутрішню «кухню» керованих сервісів.
• Клієнт відповідає за безпеку в хмарі (security IN the cloud): свої дані, хто має доступ, шифрування, налаштування мережевих охоронців, а на віртуальних серверах — ще й патчі операційної системи.

Межа рухається залежно від сервісу:

• EC2 (віртуальний сервер) — ОС, патчі, програми, мережеві правила — на тобі.
• Керована база даних — ОС і рушій бази латає AWS; тобі лишаються доступи, бекап-політики, шифрування.
• Serverless і сховища (Lambda, S3, DynamoDB) — серверів ти не бачиш зовсім; тобі — код, дані, права й налаштування.

Але навіть у найбільш керованому сервісі дані й доступи — завжди твої. Якщо сховище стало публічним через неправильне налаштування, винен не AWS.

Well-Architected: шість стовпів

AWS зібрав досвід тисяч проєктів у Well-Architected Framework — набір питань і принципів, за якими оцінюють будь-яку архітектуру. Він стоїть на шести стовпах. Мнемоніка з простого курсу — CROPS + S:

• Cost Optimization — оптимізація вартості: чи не переплачуємо? Плати за використане, прибирай зайве, розподіляй витрати тегами.
• Reliability — надійність: чи відновимося після збою? Автоматичне відновлення, кілька AZ, горизонтальне масштабування, перевірені бекапи.
• Operational Excellence — операційна досконалість: чи автоматизоване керування, чи бачимо, що відбувається, і чи вчимося на інцидентах? Інфраструктура як код, малі часті зміни.
• Performance Efficiency — ефективність продуктивності: чи правильні ресурси під навантаження? Керовані й serverless-сервіси, близькість до людей, правильний тип бази.
• Security — безпека: чи захищені дані й доступи? Мінімальні права, шифрування, журнали всіх дій, захист на всіх рівнях.
• Sustainability — сталість: чи ефективно використовуємо ресурси й енергію? Щільне завантаження, економні процесори, менше зайвих даних.

Іспит поділено на чотири домени, і вони майже збігаються зі стовпами: безпека — 30%, відмовостійкість — 26%, продуктивність — 24%, вартість — 20%. Операційна досконалість і сталість «розчинені» в питаннях усіх доменів.

📖 Словничок

• Доступність (availability) — частка часу, коли система працює; «дев'ятки».
• SLA («ес-ел-ей») — обіцянка провайдера щодо рівня обслуговування.
• Надійність зберігання (durability) — імовірність, що дані не загубляться; S3 — 11 дев'яток.
• Висока доступність (HA) — «запасне колесо»: працює далі після короткої паузи.
• Відмовостійкість (fault tolerance) — «двомоторний літак»: без жодної перерви.
• Аварійне відновлення (DR, «ді-ар») — план на випадок катастрофи регіону.
• RPO («ар-пі-оу») — скільки даних можна втратити. RTO («ар-ті-оу») — скільки часу можна простояти.
• Throughput / IOPS («сру-пут / ай-опс») — обсяг за секунду / операцій диска за секунду.
• CIA — конфіденційність, цілісність, доступність.
• Least privilege («ліст привілідж») — мінімально потрібні права.
• Defense in depth — захист на всіх рівнях.
• Shared Responsibility Model — AWS відповідає за безпеку OF the cloud, клієнт — IN the cloud.
• Well-Architected — шість стовпів: вартість, надійність, операції, продуктивність, безпека, сталість.

✅ Головне

• Доступність — «двері відчинені» (дев'ятки: 99,9% ≈ 8,8 год простою на рік); durability — «речі цілі» (S3 — 11 дев'яток).
• HA — запасне колесо, fault tolerance — двомоторний літак, DR — план на пожежу регіону; RPO — скільки даних втратити, RTO — скільки стояти.
• Безпека — CIA, мінімальні права, захист на всіх рівнях; «найдешевше» = найдешевше з тих, що виконують усі вимоги.
• Спільна відповідальність: AWS — безпека OF the cloud, клієнт — IN the cloud; дані й доступи завжди твої.
• Well-Architected — CROPS + S; домени іспиту: безпека 30%, відмовостійкість 26%, продуктивність 24%, вартість 20%.

🪪Хто ти і що тобі можна: IAM з нуля

Два питання охоронця

На вході в будь-який офісний центр охорона ставить два питання:

1. «Хто ти?» — показуєш паспорт чи перепустку. Це автентифікація (authentication, «автентикейшн»): перевірка, що ти — це ти.
2. «Куди тобі можна?» — охоронець дивиться, які поверхи й кабінети вписано у твою перепустку. Це авторизація (authorization, «авторизейшн»): перевірка прав.

Людина може бути автентифікована (охорона знає, хто вона), але не авторизована зайти в серверну. Ці два слова часто плутають — а на іспиті вони мають різні відповіді.

Пароль і MFA: два замки замість одного

Пароль — це «те, що ти знаєш». Його можуть підглянути, вгадати, викрасти через фальшивий сайт.

MFA («ем-еф-ей», multi-factor authentication — багатофакторна автентифікація) додає «те, що ти маєш»: телефон із застосунком-автентифікатором, що щопівхвилини показує новий код, або фізичний ключ-брелок. Тепер, щоб увійти, треба і знати пароль, і тримати в руці телефон. Викрадений пароль сам по собі вже нічого не відчинить.

IAM — офісний центр із перепустками

IAM (читається «ай-ем», Identity and Access Management — керування ідентичністю й доступом) — сервіс AWS, який вирішує, хто і що може робити в акаунті. Він глобальний (один на весь акаунт, а не на регіон) і безкоштовний.

Образ з простого курсу — великий офісний центр:

• Root user — власник будівлі з майстер-ключем. Вмикає MFA, ховає ключ і майже ніколи ним не користується.
• IAM users (користувачі) — працівники з особистими перепустками. У кожного — свій логін і пароль для консолі, а для програм — ключі доступу.
• Groups (групи) — відділи. Права дають відділу, а працівники отримують їх, бо в ньому числяться. Групи не вкладаються одна в одну: «відділу у відділі» немає.
• Roles (ролі) — тимчасові гостьові бейджі, які охорона видає на кілька годин. Власного пароля в ролі немає. Детально — у наступному розділі.
• Policies (політики) — таблички на дверях: хто, у які двері й за яких умов може заходити.

Політика — табличка на дверях

Політика — це невеликий документ у форматі JSON (пам'ятаєш його з розділу про вебсайти?). Ось політика, яка дозволяє читати й завантажувати фото в сховище пекарні:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::khmarynka-photos/*"
    }
  ]
}

Розберемо рядок за рядком:

• "Version": "2012-10-17" — версія «мови» політик. Завжди саме цей рядок, просто запам'ятай.
• "Statement" — список правил. Їх може бути кілька.
• "Effect" — що робити: Allow (дозволити) або Deny (заборонити).
• "Action" — які дії: назва сервісу, двокрапка, назва дії. s3:GetObject — «взяти файл із S3», s3:PutObject — «покласти файл».
• "Resource" — над чим: ARN ресурсу. Зірочка * означає «будь-що»: khmarynka-photos/* — усі файли в сховищі.
• "Condition" (необов'язково) — за яких умов. Наприклад, лише з адреси офісу або лише якщо людина увійшла з MFA:

"Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }

Бачиш знайомий запис /24? Це «квартал» адрес офісу з розділу про IP. Усе вивчене раніше тут складається докупи.

Ще одне поле — "Principal" (хто) — з'являється в політиках, які чіпляють не до людини, а до ресурсу (наприклад, до сховища). Про це — у наступному розділі.

Як AWS вирішує: три кроки напам'ять

Коли будь-хто робить будь-яку дію, AWS збирає всі політики, що стосуються цього запиту, і перевіряє їх так:

1. Є явна заборона (Deny)? Якщо хоч в одній політиці написано «заборонити» — заборонено. Крапка. Deny перемагає будь-які дозволи.
2. Є дозвіл (Allow)? Якщо заборони немає, AWS шукає дозвіл. Є — дозволено.
3. Немає нічого? Тоді заборонено. Це «неявна заборона»: за замовчуванням не можна нічого.

Звідси два правила, які розв'язують десятки питань іспиту:

• Deny б'є все.
• Нічого не сказано — значить, не можна. Новий користувач без політик не може зробити в AWS абсолютно нічого.

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

Принцип мінімальних прав

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

Практично це виглядає так:

• починати з нуля прав і додавати потрібне, а не «дати все, потім заберемо»;
• давати права групам, а не кожній людині окремо;
• регулярно прибирати зайве.

Допомагають два інструменти:

• IAM Access Analyzer — знаходить ресурси, до яких мають доступ чужі акаунти, і вміє згенерувати політику з мінімальними правами на основі того, що людина чи програма справді робила.
• Access Advisor («last accessed») — показує, якими сервісами користувач чи роль реально користувалися. Рік не заходив в S3 — право на S3 можна забрати.

Готові й власні політики

• AWS managed — готові політики від AWS: ReadOnlyAccess (лише дивитися), AdministratorAccess (усе), AmazonS3ReadOnlyAccess тощо. Зручно, але часто ширше, ніж треба.
• Customer managed — власні політики, які ти пишеш і чіпляєш до багатьох груп чи ролей.
• Inline — політика, «вшита» в одного конкретного користувача чи роль. Використовують рідко.

За тим, куди чіпляють політику, розрізняють:

• identity-based — до людини, групи чи ролі: «що цей хтось може робити»;
• resource-based — до самого ресурсу (сховища, черги, ключа): «хто може працювати зі мною».

Ключі доступу: перепустка, що не закінчується

Щоб програма чи командний рядок працювали від імені користувача, йому можна видати access keys — пару «Access Key ID + Secret Access Key». Це довгострокові облікові дані: вони діють, доки їх не видалять.

Звідси ризик: ключ, що потрапив у код, у спільну папку чи на форум, — як перепустка, приклеєна скотчем до дверей. Її знайдуть. Тому для програм, що працюють в AWS, ключі не використовують узагалі — для них є ролі. Це тема наступного розділу.

📖 Словничок

• Автентифікація — перевірка «хто ти». Авторизація — перевірка «що тобі можна».
• MFA («ем-еф-ей») — другий «замок»: пароль + код з телефона чи ключ-брелок.
• IAM («ай-ем») — глобальний безкоштовний сервіс керування доступом.
• IAM user / group / role — працівник з перепусткою / відділ / тимчасовий бейдж.
• Політика (policy) — JSON-документ: Effect, Action, Resource, Condition (і Principal у політиках ресурсів).
• Allow / Deny — дозволити / заборонити. Явний Deny перемагає все.
• Неявна заборона — усе, що не дозволено явно, заборонено.
• Least privilege («ліст привілідж») — мінімально потрібні права.
• AWS managed / customer managed / inline policy — готова від AWS / власна багаторазова / вшита в одного.
• Identity-based / resource-based policy — прив'язана до «хто» / до ресурсу.
• Access keys — довгострокові ключі для програм і CLI; ризиковані, краще ролі.
• IAM Access Analyzer / Access Advisor — пошук зайвого доступу / які сервіси реально використовуються.

✅ Головне

• Автентифікація — хто ти; авторизація — що тобі можна. MFA — другий замок.
• IAM — глобальний безкоштовний «офісний центр»: root (майстер-ключ під MFA), users (працівники), groups (відділи), roles (тимчасові бейджі), policies (таблички на дверях).
• Політика: Effect, Action, Resource, Condition (+ Principal у політиках ресурсів); * — будь-що.
• Перевірка: явний Deny → Allow → інакше заборонено. Deny б'є все; нічого не сказано — не можна.
• Least privilege: права групам, мінімально потрібні; Access Analyzer і Access Advisor допомагають прибрати зайве. Довгі access keys — ризик.

🎫Ролі й тимчасові ключі: безпечніше за паролі

Чим погані довгі ключі

Ключ доступу (access key) — це перепустка, яка ніколи не закінчується. Вона працює, доки хтось не помітить і не видалить її. А помічають зазвичай тоді, коли на рахунку вже з'явилися чужі сервери для майнингу криптовалют.

Потрібна перепустка, яка:

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

Саме це і є роль.

Роль — тимчасовий гостьовий бейдж

Роль (IAM role) — це набір прав без власного пароля чи ключів. Роль ніхто не «має» постійно — її приймають (assume, «ассьюм») на певний час.

Коли хтось приймає роль, спеціальна служба AWS — STS («ес-ті-ес», Security Token Service — служба токенів безпеки) — видає йому тимчасові облікові дані: ключ, секрет і токен, що діють від кількох хвилин до кількох годин. Минув строк — бейдж перетворюється на шматок пластику.

Навіть якщо тимчасовий ключ хтось підгляне, користі від нього мало: скоро він стане недійсним.

Ролі для серверів, функцій і контейнерів

Найчастіше роль приймають не люди, а сервіси AWS:

• EC2 — роль чіпляють до сервера через instance profile («інстанс профайл»). Програма на сервері автоматично отримує тимчасові ключі й сама їх оновлює. Образ з простого курсу — бейдж, прикріплений до робота: він сам продовжується кожні кілька годин, і нікому не треба ховати ключ.
• Lambda — у кожної функції є execution role («роль виконання»): що функції дозволено робити.
• ECS (контейнери) — task role: права саме для конкретного контейнера.

Дві політики ролі: хто може взяти і що відчиняє

У кожної ролі є дві різні політики:

• Trust policy («траст полісі», політика довіри) — хто може взяти бейдж: «сервіс EC2», «сервіс Lambda», «користувачі акаунта 111122223333».
• Permissions policy (політика дозволів) — що бейдж відчиняє: «читати й писати в сховище фото».

Ось як виглядає trust policy, що дозволяє серверам EC2 приймати роль:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Principal — хто; sts:AssumeRole — «прийняти роль».

Доступ до іншого акаунта

У компанії багато акаунтів, і людям з одного треба часом попрацювати в іншому. Ключі тут теж не потрібні:

1. В акаунті B створюють роль, у trust policy якої написано: «довіряю акаунту A».
2. Людина з акаунта A (якій її власна політика дозволяє sts:AssumeRole на цю роль) «перемикається» в роль.
3. STS видає тимчасові ключі, і людина працює в акаунті B з правами ролі.

ExternalId: захист від «плутанини заступника»

Буває, що доступ до твого акаунта потрібен сторонній компанії — наприклад, сервісу, який аналізує рахунки AWS. Ти створюєш для неї роль.

Але уяви: цей сервіс обслуговує тисячі клієнтів. Хитрий клієнт X може вказати сервісу чужу роль — твою — і сервіс, сам того не бажаючи, полізе у твій акаунт від імені X. Це називається confused deputy («плутанина заступника»).

Захист простий: у trust policy твоєї ролі додають умову sts:ExternalId — секретну «кодову фразу», яку сервіс видав саме тобі. Без правильної фрази роль не прийняти, а чужу фразу клієнт X не знає.

Resource-based policy: табличка на самому ресурсі

Політику можна причепити не лише до людини чи ролі, а й до ресурсу. Найвідоміший приклад — bucket policy (політика сховища S3). Інші — політики черг SQS, тем SNS, ключів KMS, функцій Lambda. У таких політиках обов'язково є поле Principal — кому дозволено.

Наприклад, дозволити акаунту партнера 111122223333 читати файли:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::khmarynka-photos/*"
  }]
}

Корисна умова для політик ресурсів — aws:PrincipalOrgID: «пускати лише акаунти моєї організації», не перелічуючи їх усіх.

Permission boundary: стеля для конкретної людини

Уяви: розробникам треба дозволити самим створювати ролі для своїх програм. Небезпечно: розробник може створити роль з правами адміністратора і взяти її собі.

Permission boundary («пермішн баундері», межа прав) — це стеля для користувача чи ролі. Навіть якщо політика дає більше, фактичні права — лише те, що вміщується і в політику, і в межу. Розробникам дозволяють створювати ролі лише з цією межею — і вище стелі ніхто не стрибне.

ABAC: права за ярликами

Замість сотні політик «Марку — ці сервери, Соні — ті» можна написати одну: «людина може керувати ресурсами, у яких тег project такий самий, як у неї». Це ABAC («ей-бі-ей-сі», attribute-based access control) — доступ за атрибутами (тегами). Новий проєкт — новий тег, а політика та сама.

Ще кілька інструментів

• Федерація — вхід через зовнішню «систему паспортів» (корпоративний каталог, Google) без окремих IAM-користувачів: STS видає тимчасові ключі за підтвердженням від неї (протоколи SAML 2.0 чи OIDC). Детальніше — у наступному розділі.
• IAM Roles Anywhere — тимчасові ключі AWS для серверів поза AWS (в офісі) за цифровим сертифікатом, без довгих ключів.
• Credential report — звіт про всіх користувачів: у кого є пароль, MFA, коли востаннє змінювали ключі.

📖 Словничок

• Роль (IAM role) — набір прав без пароля; її тимчасово приймають (assume).
• STS («ес-ті-ес») — служба, що видає тимчасові облікові дані.
• Instance profile — «кріплення» ролі до сервера EC2.
• Execution role / task role — роль функції Lambda / контейнера ECS.
• IMDSv2 — безпечна версія сервісу метаданих сервера.
• Trust policy — хто може прийняти роль. Permissions policy — що роль дозволяє.
• sts:AssumeRole — дія «прийняти роль».
• Confused deputy — «плутанина заступника»; захист — умова sts:ExternalId.
• Resource-based policy — політика на ресурсі (bucket policy тощо) з полем Principal.
• aws:PrincipalOrgID — умова «лише акаунти моєї організації».
• Permission boundary — стеля прав для користувача чи ролі.
• ABAC («ей-бі-ей-сі») — доступ за тегами.
• Федерація — вхід через зовнішню систему ідентичності (SAML, OIDC).
• IAM Roles Anywhere — тимчасові ключі для серверів поза AWS за сертифікатом.

✅ Головне

• Довгі access keys — перепустка, що не закінчується; для програм в AWS їх замінюють ролі.
• Роль приймають на час: STS видає тимчасові ключі. EC2 — instance profile, Lambda — execution role, ECS — task role.
• У ролі дві політики: trust (хто може взяти) і permissions (що відчиняє).
• Інший акаунт — роль із довірою; стороння компанія — ще й sts:ExternalId. Політика ресурсу (bucket policy) з іншого акаунта — Allow з обох боків; «лише моя організація» — aws:PrincipalOrgID.
• Permission boundary — стеля прав; ABAC — доступ за тегами; Roles Anywhere — для серверів поза AWS.

🏢Багато акаунтів і багато людей: Organizations, SCP, вхід для працівників і клієнтів

Навіщо багато акаунтів

Один акаунт на все — як одна кімната для всієї компанії: тісно, і будь-яка помилка зачіпає всіх. Окремі акаунти дають:

• ізоляцію — помилка чи злам у тестовому акаунті не зачепить робочий сайт (фахівці кажуть «менший радіус ураження», blast radius);
• окремі права — розробникам можна все в тестах і майже нічого в робочому акаунті;
• зрозумілі витрати — видно, скільки коштує кожен проєкт;
• окремі ліміти — квоти одного акаунта не заважають іншому.

AWS Organizations: головний офіс мережі

AWS Organizations — сервіс, що об'єднує багато акаунтів під одним «головним офісом»:

• Management account («менеджмент акаунт», керуючий) — головний офіс: створює організацію, запрошує чи створює акаунти, встановлює правила.
• Member accounts — філії.
• OU («оу-ю», organizational units — організаційні одиниці) — відділи, у які групують акаунти: «Робочі», «Тести», «Безпека». OU можна вкладати одна в одну.

Приємний бонус — consolidated billing (об'єднаний рахунок): один рахунок за всі акаунти, об'ємні знижки (що більше спожито разом, то дешевше) і спільне використання знижок за довгострокові зобов'язання (до них дійдемо в розділі про оплату серверів).

SCP: стеля для цілих філій

SCP («ес-сі-пі», service control policy — політика контролю сервісів) — правила головного офісу для філій. Їх чіпляють до OU чи акаунта, і вони діють на всіх у ньому — навіть на адміністраторів і навіть на root філії.

Головне про SCP — три речі:

1. SCP — це стеля, а не ключ. Вона нічого не дозволяє сама, лише обмежує максимум. Щоб людина щось могла, їй усе одно потрібен Allow у звичайній IAM-політиці. Але вище стелі SCP не стрибне ніхто.
2. SCP не діє на management account — головний офіс правилами для філій себе не обмежує.
3. Типові приклади: «заборонити вимикати журнали CloudTrail», «заборонити працювати поза дозволеними регіонами» (для вимог про дані в ЄС), «заборонити виходити з організації».

Тепер повна перевірка доступу виглядає так — фільтри один за одним:

• Є явний Deny будь-де — заборонено.
• SCP організації не дозволяє дію — заборонено.
• Permission boundary (якщо є) не дозволяє — заборонено.
• Політика людини чи ресурсу дає Allow — дозволено.
• Інакше — заборонено.

Control Tower: готова «правильна» організація

Налаштувати організацію за всіма найкращими практиками вручну — довго. AWS Control Tower робить це за тебе й будує landing zone («лендінг зоун» — «посадкову зону»):

• окремі акаунти для журналів і аудиту;
• централізовані журнали з усіх акаунтів;
• guardrails («гардрейлз», огорожі; нині їх звуть controls): превентивні (забороняють, через SCP), детективні (помічають порушення, через правила AWS Config), проактивні (перевіряють шаблони до створення ресурсів);
• Account Factory — «фабрика» нових акаунтів, однаково налаштованих з першої хвилини.

Працівники: один вхід в усе — IAM Identity Center

Створювати кожному працівнику окремого IAM-користувача в кожному з двадцяти акаунтів — жах. IAM Identity Center (колишня назва — AWS SSO) дає одну перепустку працівника на всі будівлі компанії:

• людина входить один раз (single sign-on, «сингл сайн-он») і бачить усі акаунти й бізнес-застосунки, куди їй можна;
• права задають permission sets («набори прав»): «адмін у тестах», «лише перегляд у робочому»;
• користувачі можуть жити у вбудованому каталозі Identity Center, у корпоративному Active Directory або в зовнішній системі — Okta, Microsoft Entra ID — через стандарти SAML 2.0 і SCIM.

Active Directory в AWS: Directory Service

Багато компаній тримають працівників і комп'ютери в Active Directory (AD) — корпоративному «довіднику» від Microsoft. AWS Directory Service пропонує три варіанти:

• AWS Managed Microsoft AD — справжній AD у хмарі; можна налаштувати довіру (trust) з AD в офісі.
• AD Connector — «перехідник»: запити до офісного AD, нічого не зберігаючи в AWS.
• Simple AD — дешевий спрощений сумісний каталог для невеликих середовищ, без довіри з офісним AD.

Клієнти застосунку: Amazon Cognito

Працівники — це одне, а клієнти твого застосунку — зовсім інше: їх тисячі, вони реєструються самі, входять через Google чи Facebook. Для них є Amazon Cognito («когніто»). Він має дві частини — і їх постійно плутають:

• User Pool («юзер пул», пул користувачів) — реєстрація і вхід: email і пароль, вхід через соцмережі чи корпоративні системи, підтвердження пошти, MFA. Після входу видає застосунку токени (JWT) — «ти — це пані Ірина». Вміє працювати разом з балансувальником ALB та API Gateway. Це про хто ти.
• Identity Pool («айдентіті пул») — тимчасові AWS-ключі для користувачів застосунку (навіть неавторизованих гостей), щоб застосунок на телефоні міг напряму працювати з сервісами AWS — наприклад, завантажити фото в S3. Це про що тобі можна в AWS.

Ділитися ресурсами між акаунтами: RAM

Іноді ресурс зручно створити один раз і дати ним користуватися кільком акаунтам — наприклад, спільну мережу. Для цього є AWS RAM («рем», Resource Access Manager): він «ділиться» підмережами (так звана VPC sharing), мережевими хабами, правилами DNS та іншим між акаунтами організації.

Хто де входить — одна таблиця

📖 Словничок

• AWS Organizations — об'єднання акаунтів під «головним офісом».
• Management account / member account — керуючий акаунт / акаунт-філія.
• OU («оу-ю») — організаційна одиниця, «відділ» з акаунтів.
• Consolidated billing — один рахунок за всі акаунти й спільні знижки.
• SCP («ес-сі-пі») — стеля прав для OU чи акаунта; сама нічого не дозволяє; не діє на management account.
• RCP — стеля для ресурсів організації.
• Control Tower — готова landing zone з guardrails, журналами й Account Factory.
• IAM Identity Center (колишній AWS SSO) — єдиний вхід працівників; permission sets.
• SAML 2.0 / SCIM — стандарти входу / синхронізації користувачів із зовнішніх систем.
• Directory Service — Managed Microsoft AD, AD Connector, Simple AD.
• Cognito User Pool — реєстрація й вхід клієнтів застосунку (токени JWT).
• Cognito Identity Pool — тимчасові AWS-ключі для клієнтів застосунку.
• AWS RAM («рем») — спільне використання ресурсів між акаунтами.

✅ Головне

• Багато акаунтів = ізоляція, окремі права, зрозумілі витрати. Organizations: management account, member accounts, OU, consolidated billing.
• SCP — стеля для OU/акаунтів: нічого не дозволяє, лише обмежує; не діє на management account. Повна перевірка: Deny → SCP → boundary → Allow → інакше заборонено.
• Control Tower — готова landing zone з guardrails і журналами.
• Працівники → IAM Identity Center (+ Directory Service для AD). Клієнти → Cognito: User Pool — вхід, Identity Pool — тимчасові ключі до AWS.
• RAM — ділитися ресурсами (підмережами, хабами) між акаунтами.

🔐Шифрування з нуля: замки, ключі й конверти

Що таке шифрування

Шифрування (encryption, «енкрипшн») — перетворення зрозумілих даних на «кашу», яку можна повернути назад лише за допомогою ключа:

Круасан з мигдалем, вул. Сихівська 5 → k8#Qz!v2Lp0…

Важливо розрізняти дві речі:

• алгоритм — «конструкція замка». Її не приховують: найкращі алгоритми (наприклад, AES) відомі всім і перевірені тисячами фахівців;
• ключ — те, що тримають у секреті. Без ключа навіть знаючи алгоритм, дані не прочитати за розумний час.

Симетричне шифрування: один ключ

Симетричне шифрування — як ключ від квартири: той самий ключ і замикає, і відмикає. Це дуже швидко, тому ним шифрують великі обсяги даних. Найвідоміший алгоритм — AES-256.

Слабке місце одне: як передати ключ іншій стороні? Якщо передати його відкрито, дорогою його можуть підглянути.

Асиметричне шифрування: відкритий замок і ключ

Асиметричне шифрування використовує пару ключів:

• публічний (public key) — можна роздавати всім;
• приватний (private key) — тримаєш лише в себе.

Що зашифровано публічним, розшифрує лише приватний. Образ — поштова скринька з щілиною: будь-хто може вкинути лист (зашифрувати публічним ключем), але відчинити скриньку може лише власник ключа.

Асиметричне шифрування повільніше, тому ним зазвичай шифрують не самі дані, а передачу ключа і цифрові підписи (доказ, що документ підписав саме власник приватного ключа).

HTTPS: як браузер і сайт домовляються

Тепер зрозуміло, як працює замочок у браузері. Спрощено:

1. Браузер звертається до сайту, сайт показує свій сертифікат — «паспорт» з публічним ключем.
2. Браузер перевіряє паспорт: чи видав його довірений центр сертифікації (CA — «сі-ей»), чи не прострочений, чи збігається ім'я сайту.
3. Користуючись асиметричним шифруванням, сторони безпечно домовляються про спільний симетричний ключ.
4. Далі вся розмова йде швидким симетричним шифруванням.

Протокол, який це робить, називається TLS («ті-ел-ес»; старша назва — SSL). Тому кажуть «TLS-сертифікат» або «SSL-сертифікат» — це одне й те саме.

Дані в спокої і дані в дорозі

Дані бувають у двох станах — і захищати треба обидва:

• At rest («ет рест», у спокої) — дані лежать: на диску, у сховищі, в базі. Образ — документи в сейфі. Захист — шифрування ключем, яким керує, наприклад, KMS.
• In transit («ін транзит», у дорозі) — дані їдуть мережею. Образ — броньований інкасаторський фургон. Захист — TLS, тобто HTTPS.

KMS — банк ключів

AWS KMS («кей-ем-ес», Key Management Service — сервіс керування ключами) — банк ключів. Головне правило банку: ключ тобі на руки не видають. Ти приносиш дані й кажеш «зашифруй» або «розшифруй» — банк робить це всередині, у спеціальному захищеному обладнанні, і записує кожну операцію в журнал (CloudTrail): хто, коли, яким ключем.

Ключі KMS бувають трьох видів:

• AWS owned — ключі, якими AWS шифрує дані «під капотом»; ти їх не бачиш і нічого не платиш.
• AWS managed — ключі з назвами на кшталт aws/s3, aws/ebs, створені сервісами для тебе. Ротація (заміна ключового матеріалу) — автоматично щороку; керувати їхньою політикою не можна.
• Customer managed — твої ключі. Ти сам пишеш key policy (хто може користуватися ключем), налаштовуєш ротацію (раз на 90–2560 днів, за замовчуванням щороку, або вручну на вимогу) і можеш дати доступ іншим акаунтам.

Ще кілька важливих фактів:

• Key policy обов'язкова — це головний «замок» ключа. Якщо вона не дозволяє, жодна IAM-політика доступу до ключа не дасть.
• KMS — регіональний. Для шифрування в одному регіоні й розшифрування в іншому тим самим ключем є Multi-Region keys.
• Ключ не видаляють миттєво: лише з очікуванням 7–30 днів (за замовчуванням 30). Поки строк не минув — видалення можна скасувати. Безпечніша альтернатива — вимкнути ключ. Адже дані, зашифровані видаленим ключем, повернути неможливо.

Envelope encryption: лист у конверті, конверт у сейфі

KMS шифрує напряму лише невеликі дані — до 4 KB. А як шифрувати фото на мегабайти чи бази на гігабайти? Для цього є envelope encryption («енвелоуп енкрипшн», шифрування конвертом):

1. Програма просить KMS: «дай ключ даних» (GenerateDataKey).
2. KMS повертає ключ даних у двох видах: звичайному й зашифрованому своїм головним ключем.
3. Програма шифрує великий файл звичайним ключем даних просто в себе — швидко — і одразу забуває звичайний ключ.
4. Поруч із зашифрованим файлом зберігається зашифрований ключ даних — «конверт».
5. Щоб прочитати файл, програма надсилає конверт у KMS, отримує звичайний ключ, розшифровує файл і знову його забуває.

Образ з простого курсу: лист у конверті, конверт у сейфі банку. Сервіси AWS (S3, EBS, бази) роблять усе це самі — тобі досить обрати ключ. Але на іспиті слова «4 KB» і «data key» — підказка саме на envelope encryption.

Як шифрують сховище S3

• SSE-S3 — шифрування ключами, якими повністю керує S3. Увімкнене за замовчуванням для всіх нових об'єктів з 2023 року.
• SSE-KMS — шифрування ключем KMS: кожне використання ключа видно в журналі CloudTrail, а доступ до ключа — окремий від доступу до файлу. Обирають, коли потрібен аудит і контроль ключа.
• DSSE-KMS — подвійне шифрування двома шарами, для найсуворіших вимог.
• SSE-C — ключ щоразу приносить клієнт; AWS його не зберігає (лише через HTTPS).
• Шифрування на клієнті — дані шифрують ще до відправки в S3.

Два практичні нюанси:

• Якщо мільйони файлів шифруються через SSE-KMS, KMS може почати відповідати помилкою ThrottlingException (забагато запитів). Ліки — S3 Bucket Keys: сховище отримує проміжний ключ і звертається до KMS у рази рідше. Ще й дешевше.
• Щоб заборонити нешифроване з'єднання зі сховищем, у bucket policy пишуть Deny за умови aws:SecureTransport = false.

Диски й бази: як зашифрувати вже існуючі

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

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

1. Зробити знімок (snapshot) бази чи диска.
2. Скопіювати знімок, увімкнувши шифрування.
3. Відновити нову базу чи диск із зашифрованої копії й переключити застосунок на неї.

Ще два факти: репліка бази для читання шифрується так само, як основна база; а поділитися зашифрованим знімком з іншим акаунтом можна лише тоді, коли він зашифрований customer managed ключем (і тому акаунту дано доступ до ключа). Знімок з AWS managed ключем спершу копіюють, перешифровуючи своїм ключем.

CloudHSM — власний сейф

AWS CloudHSM («клауд-ейч-ес-ем», Hardware Security Module) — виділений апаратний модуль лише для тебе (single-tenant, «сингл-тенант»): ключі повністю під твоїм контролем, AWS не має до них доступу. Відповідає суворому стандарту FIPS 140 Level 3. Працює через стандартні інтерфейси (PKCS#11, JCE, CNG), підходить для шифрування баз Oracle (TDE), для «розвантаження» TLS і як особисте сховище ключів для KMS. Для надійності — кластер щонайменше з двох HSM у різних AZ.

Образ з простого курсу: KMS — банк ключів (спільний, зручний, інтегрований з усім), CloudHSM — власний сейф у сховищі банку, код від якого знаєш тільки ти.

Секрети: паролі до баз і налаштування

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

• AWS Secrets Manager — сейф з автоматичною заміною замків: зберігає секрети й сам змінює паролі за розкладом (ротація) — вбудовано для RDS, Aurora, Redshift, DocumentDB, для інших — через функцію Lambda. Уміє копіювати секрети в інші регіони. Платний за кожен секрет.
• SSM Parameter Store — шафка для налаштувань: зберігає параметри й секрети (тип SecureString шифрується KMS), має ієрархію «папок», звичайний рівень — безкоштовний. Вбудованої ротації немає.

Сертифікати для HTTPS: ACM

ACM («ей-сі-ем», AWS Certificate Manager) — паспортний стіл для сайтів: видає безкоштовні публічні TLS-сертифікати й сам їх поновлює (якщо підтвердити домен через DNS). Сертифікат ставлять на балансувальник, CloudFront, API Gateway.

Три факти, які треба знати напам'ять:

• Для CloudFront сертифікат ACM має бути в регіоні us-east-1 (для балансувальника — у регіоні балансувальника).
• Публічний сертифікат ACM не можна встановити просто на сервер EC2 — лише на інтегровані сервіси.
• Імпортовані (куплені деінде й завантажені в ACM) сертифікати ACM сам не поновлює — за строком стежать через сповіщення.

📖 Словничок

• Шифрування («енкрипшн») — перетворення даних на «кашу», яку повертає лише ключ.
• Симетричне — один ключ на обидві дії (AES-256). Асиметричне — пара: публічний і приватний ключі.
• Сертифікат / CA («сі-ей») — «паспорт» сайту / центр, що видає паспорти.
• TLS («ті-ел-ес», колишній SSL) — протокол шифрування в дорозі; основа HTTPS.
• At rest / in transit — дані в спокої (сейф) / у дорозі (броньований фургон).
• KMS («кей-ем-ес») — банк ключів; ключі не залишають сервіс, кожне використання в журналі.
• AWS owned / AWS managed / customer managed key — невидимий / створений сервісом (aws/s3) / твій власний.
• Key policy — обов'язкова політика доступу до ключа.
• Envelope encryption — великі дані шифрує ключ даних, а ключ даних шифрує KMS (напряму KMS — до 4 KB).
• SSE-S3 / SSE-KMS / SSE-C — способи шифрування S3: ключі S3 / ключ KMS з аудитом / ключ клієнта.
• S3 Bucket Keys — менше викликів KMS, без ThrottlingException, дешевше.
• CloudHSM — виділений апаратний модуль ключів, FIPS 140 Level 3.
• Secrets Manager — секрети з автоматичною ротацією. Parameter Store — налаштування й секрети без ротації.
• ACM («ей-сі-ем») — безкоштовні TLS-сертифікати з автопоновленням; для CloudFront — us-east-1.

✅ Головне

• Симетричне шифрування — один ключ (швидко, AES-256); асиметричне — «скринька з щілиною»: публічний і приватний ключі. HTTPS/TLS поєднує обидва; сертифікат — «паспорт» сайту.
• Захищай дані at rest (KMS) і in transit (TLS). KMS — банк ключів: ключі не виходять, кожне використання в журналі; key policy обов'язкова; видалення — через 7–30 днів.
• Envelope encryption: KMS напряму — до 4 KB, великі дані шифрує ключ даних.
• S3: SSE-S3 за замовчуванням, SSE-KMS для аудиту, Bucket Keys проти throttling. Існуючі RDS/EBS — через зашифровану копію знімка.
• CloudHSM — власний сейф (FIPS 140 Level 3); Secrets Manager — ротація паролів; Parameter Store — налаштування; ACM — безкоштовні сертифікати, для CloudFront — us-east-1.

🛡️Атаки й охорона: від DDoS до розслідувань

Як нападають: словничок злодія

• DDoS («ді-дос», distributed denial of service — розподілена відмова в обслуговуванні) — натовп фальшивих відвідувачів перекриває вхід, і справжні клієнти не можуть зайти. «Розподілена» — бо натовп іде з тисяч заражених комп'ютерів одночасно. Буває на рівні мережі (засипати пакетами) і на рівні сайту (засипати HTTP-запитами).
• SQL injection («ес-к'ю-ел ін'єкшн») — зловмисник вписує в поле форми не ім'я, а шматок команди для бази даних. Якщо програма наївна, база цю команду виконає. Уяви, що в бланку замовлення написали «…і видайте ключ від каси», а кухар слухняно видав.
• XSS («екс-ес-ес», cross-site scripting) — у текст, який бачать інші користувачі (відгук, коментар), підкидають шкідливий скрипт. Браузери відвідувачів його виконують — і, наприклад, віддають зловмисникові їхні cookies.
• Підбір паролів (brute force) — мільйони спроб угадати пароль.
• Боти — програми, що автоматично обходять сайт: копіюють ціни, скуповують товар, шукають слабкі місця.
• Вразливості — відомі «тріщини» в програмах (їх нумерують як CVE). Зловмисники автоматично шукають сервери, де тріщини ще не залатані.
• Викрадені ключі — і на твоєму рахунку з'являються чужі сервери для майнингу криптовалют.
• Витік даних — наприклад, сховище з документами випадково стало публічним.

Захист на всіх рівнях

Жоден окремий замок не зупинить усіх. Тому захист будують шарами, як середньовічний замок: рів, стіна, ворота, варта, сейф у вежі. Навіть якщо один шар подолано, далі — наступний. Це і є defense in depth — захист на всіх рівнях.

• Край — захист від натовпу й фільтр запитів ще до того, як вони дійдуть до сайту.
• Мережа — хто взагалі може постукати в які двері.
• Сервери — патчі, пошук вразливостей.
• Застосунок — перевірка того, що вводять користувачі.
• Дані — шифрування, пошук чутливого, бекапи.
• Доступи — мінімальні права, MFA.
• Нагляд — журнали, тривоги, автоматична реакція.

Далі — охоронці AWS для кожного шару. Образ з простого курсу: торговий центр та його охорона.

WAF — фейс-контроль на вході

AWS WAF («ваф», web application firewall — файрвол вебзастосунків) перевіряє кожен HTTP-запит (це «рівень 7» — рівень змісту запиту) за правилами:

• блокує типові атаки — SQL injection і XSS;
• блокує окремі IP-адреси та цілі країни (geo match);
• rate-based rules — «цей відвідувач заходить надто часто»: обмежує кількість запитів з однієї адреси;
• готові набори правил від AWS і партнерів (managed rule groups), захист від ботів (Bot Control).

WAF ставлять перед сайтом: на CloudFront, балансувальник ALB, API Gateway, AppSync, Cognito, App Runner.

Shield — дамба від натовпу

• Shield Standard — безкоштовно й автоматично для всіх клієнтів AWS: захист від поширених DDoS-атак на рівні мережі (рівні 3–4). Нічого вмикати не треба.
• Shield Advanced — платна «страховка» (близько 3 000 доларів на місяць на організацію): команда експертів SRT цілодобово, компенсація рахунку, якщо під час атаки ресурси масштабувалися й витрати зросли, розширене виявлення і захист на рівні 7 разом з WAF. Для CloudFront, Route 53, Global Accelerator, балансувальників і EC2 з Elastic IP.

Мережеві файрволи й централізоване керування

• AWS Network Firewall — митниця на в'їзді в мережу (VPC): фільтрує весь трафік, зокрема вихідний за доменними іменами («сервери можуть ходити лише на сайти оновлень»), вміє виявляти й зупиняти вторгнення (IPS/IDS).
• Route 53 Resolver DNS Firewall — не дає серверам навіть дізнатися адресу шкідливих доменів.
• AWS Firewall Manager — єдиний пульт правил WAF, Shield Advanced, мережевих охоронців і Network Firewall для всіх акаунтів організації. Нові акаунти й ресурси отримують правила автоматично.

Виявлення: хто помічає проблеми

П'ять сервісів, які постійно плутають. Запам'ятовуй за образами:

• Amazon GuardDuty («гард-д'юті») — розумні камери, що помічають загрози. Аналізує журнали дій (CloudTrail), мережеві потоки (VPC Flow Logs) і DNS-запити, а за бажанням — і S3, Kubernetes (систему керування контейнерами — про неї в частині про обчислення), бази, Lambda. Помічає криптомайнинг, викрадені ключі, зв'язок з відомими шкідливими адресами, дивні входи.
• Amazon Inspector («інспектор») — технагляд, що шукає вразливості (CVE) і відкриті мережеві шляхи в серверах EC2, образах контейнерів і функціях Lambda. Працює безперервно.
• Amazon Macie («мейсі») — пес-шукач, що нюхає чутливі дані (персональні дані, номери карток) у сховищах S3.
• Amazon Detective — слідчий: коли тривога вже спрацювала, будує граф подій і допомагає знайти першопричину.
• AWS Security Hub — пульт охорони: збирає знахідки всіх інших в одне місце й перевіряє відповідність стандартам (CIS, PCI DSS, найкращі практики AWS).

Мнемоніка з простого курсу: GuardDuty — охорона від загроз. Inspector — інспектор дефектів. Macie — «мої персональні дані».

Аудит і відповідність

• AWS CloudTrail — відеореєстратор усіх дій: хто, що, коли і звідки зробив (кожен виклик API). Історія за 90 днів безкоштовно; для довгого зберігання — «trail» у S3; organization trail — журнал одразу всіх акаунтів. Уміє доводити, що журнали не змінювали (log file integrity validation).
• AWS Config — фотоархів налаштувань: як виглядав кожен ресурс учора й місяць тому і чи відповідає він правилам («усі диски зашифровані», «жодного публічного сховища»). Порушення можна виправляти автоматично.
• AWS Artifact — «шафа з документами» AWS для твоїх аудиторів: звіти відповідності самого AWS (SOC, PCI, ISO) і угоди (наприклад, для медичних даних).
• AWS Audit Manager — автоматично збирає докази для аудиту.

Автоматична реакція

Помітити загрозу мало — треба швидко відреагувати, навіть о третій ночі. Типовий ланцюжок:

1. GuardDuty знаходить загрозу (наприклад, сервер спілкується з відомою шкідливою адресою).
2. Знахідка стає подією в сервісі EventBridge (що таке подія, пам'ятаєш з розділу про застосунки).
3. Правило EventBridge запускає функцію Lambda чи автоматизацію Systems Manager: ізолювати сервер, відкликати ключі, написати в чат чергових.

Так само працює AWS Config: знайшов публічне сховище — автоматично закрив.

А щоб увімкнути GuardDuty, Security Hub, Macie й Inspector в усіх акаунтах організації (і в нових теж), призначають один delegated administrator («делегований адміністратор») — окремий акаунт безпеки, який керує ними централізовано.

📖 Словничок

• DDoS («ді-дос») — атака натовпом запитів з тисяч пристроїв.
• SQL injection / XSS — «команда в бланку» для бази / «шкідлива записка» у вмісті сайту.
• Brute force — підбір паролів. CVE — номер відомої вразливості.
• Defense in depth — захист шарами.
• AWS WAF («ваф») — фільтр HTTP-запитів (рівень 7): SQLi, XSS, IP, країни, rate-based; не на NLB.
• Shield Standard / Advanced — безкоштовний базовий DDoS-захист / платна «страховка» з експертами SRT і компенсацією.
• Network Firewall — файрвол на рівні VPC, зокрема фільтр вихідного трафіку за доменами.
• Firewall Manager — єдиний пульт правил для всіх акаунтів організації.
• GuardDuty — загрози. Inspector — вразливості. Macie — чутливі дані в S3. Detective — розслідування. Security Hub — пульт знахідок і стандартів.
• CloudTrail — хто що зробив (API). Config — стан ресурсів і правила. Artifact — звіти відповідності AWS.
• Delegated administrator — акаунт, що централізовано керує сервісами безпеки для всієї організації.