24 уроки з образами, «запам'ятай», тригерами іспиту і пастками. Інтерактивна версія з підказками, квізом і тестом — на сайті.
Незалежний навчальний курс. Не пов'язаний з Amazon Web Services і не схвалений AWS. AWS і назви сервісів — торговельні марки Amazon.com, Inc. або її афілійованих осіб. Практичні питання — оригінальні, це не реальні питання іспиту.
🎓 AWS з нуля до SAA-C03
24 короткі уроки з образами, які легко уявити й запам'ятати. Кожен урок — 5–8 хвилин: образ → пояснення → «запам'ятай» → як питають на іспиті → не плутай. Після уроку — шпаргалка і квіз по темі.
📘 Глибоке навчання — повний курс з нуля: 46 розділів з поясненнями, схемами й лабораторіями, два пробні іспити, окремий офлайн-застосунок.Відкрити →
📲 Встанови як застосунок — відкриватиметься з головного екрана і працюватиме без інтернету.iPhone: Safari → «Поділитися» → «На початковий екран».
✓ Курс збережено на цьому пристрої — відкривається і без інтернету.
🤖 Підказки: торкнись підкресленої назви сервісу або виділи її пальцем — з'явиться пояснення з образом і тригерами для іспиту. Вимикаються кнопкою 🤖 угорі. Повний довідник — вкладка 📚 «Сервіси».
Незалежний навчальний курс. Не пов'язаний з Amazon Web Services і не схвалений AWS. AWS і назви сервісів — торговельні марки Amazon.com, Inc. або її афілійованих осіб. Практичні питання — оригінальні, це не реальні питання іспиту.
🎯Хто такий Solutions Architect і як влаштований іспит
🖼️ Образ. Ти — архітектор, який будує місто в хмарі. Замовник каже чотири побажання: «щоб не зламали», «щоб не падало», «щоб було швидко», «щоб недорого». AWS — величезний будівельний магазин на 200+ матеріалів (сервісів). Твоя робота — обрати ті, що виконують усі побажання одночасно.
Solutions Architect — людина, яка вирішує, як система житиме в AWS: де зберігати дані, як витримати мільйон користувачів, як не втратити дані при аварії і як не переплатити. Іспит SAA-C03 перевіряє саме це вміння вибирати.
Майже кожне питання — міні-історія: «Компанія має… Потрібно… Яке рішення найкраще?». Правильна відповідь — не «найкрутіша», а та, що виконує всі вимоги з тексту. Часто всі варіанти технічно робочі, але лише один — найдешевший, найпростіший чи найнадійніший саме в цій ситуації.
Чотири побажання замовника — це чотири домени іспиту:
Безпека — 30%: «щоб не зламали».
Відмовостійкість — 26%: «щоб не падало й не губило дані».
Продуктивність — 24%: «щоб було швидко».
Вартість — 20%: «щоб недорого».
Формат: 65 питань (50 оцінюються), 130 хвилин, прохідний бал 720 з 1000. Штрафу за неправильну відповідь немає, тож порожніх не лишай. Якщо англійська не рідна — до запису на іспит попроси +30 хвилин (ESL +30).
Як вчитися на цьому сайті — чотири кроки по колу:
🎓 Урок — зрозуміти й уявити.
📘 Шпаргалка — стисло повторити факти й тригери.
🎲 Квіз — закріпити тригери «бачиш у питанні → відповідь».
📝 Тест — потренуватися як на іспиті.
Увімкни 🤖 Підказки вгорі: торкнись будь-якої підкресленої назви сервісу (або виділи її пальцем) — з'явиться коротке пояснення, образ і тригери для іспиту.
💡 Запам'ятай
Іспит — про вибір сервісу під вимоги, а не про команди й меню консолі.
Шукай у питанні критерій: MOST cost-effective, LEAST operational overhead, MOST secure, highly available.
Правильна відповідь виконує всі вимоги одночасно.
Відповідай на всі питання — штрафу немає.
🎯 Як питають на іспиті
«…with the LEAST operational overhead»→керований або serverless сервіс замість власних серверів і скриптів
«…the MOST cost-effective solution»→найдешевше з рішень, що виконують усі вимоги
Варіант «напишемо скрипт на EC2 і запускатимемо cron»→майже завжди програє керованому сервісу
⚠️ Не плутай
«Найдешевше» на іспиті ≠ «найдешевше взагалі»: дешевий варіант без потрібної доступності — неправильний.
«Highly available» (працює попри збій, з короткою паузою) ≠ «fault tolerant» (працює взагалі без перерви).
🖼️ Образ. AWS — мережа «міст» по всьому світу. Кожне місто — Region (наприклад, Франкфурт — eu-central-1). У кожному місті кілька окремих «районів» зі своїм живленням, охолодженням і мережею — Availability Zones (AZ). А ще біля людей стоять сотні «кіосків» — edge locations, звідки швидко роздають контент.
Що таке хмара. Замість купувати сервери і чекати їх місяцями, ти орендуєш потужність на хвилини, платиш за використане і за хвилини збільшуєш або зменшуєш її. Це називають еластичністю.
Region обирають з чотирьох причин:
Закони — дані мають лишатися в країні чи в ЄС.
Близькість до користувачів — менша відстань, менша затримка.
Потрібні сервіси — не кожен сервіс є в кожному регіоні.
Ціна — у різних регіонах ціни трохи різні.
AWS не переносить твої дані між регіонами сам — лише коли ти налаштуєш реплікацію чи копіювання.
Availability Zone — один або кілька дата-центрів, ізольованих від аварій в інших AZ, але з'єднаних швидкою мережею. Звідси головне правило архітектора: висока доступність = розкласти систему щонайменше у 2 AZ. Захист від падіння цілого регіону = другий регіон.
Edge locations — точки CloudFront, Route 53 і Global Accelerator: там не запускають сервери, там кешують і приймають трафік ближче до людей.
Особливі «філії» AWS:
Local Zones — AWS у великому місті: одноцифрові мілісекунди до мешканців.
Wavelength — AWS усередині 5G-мережі оператора.
Outposts — стійка AWS у твоєму власному дата-центрі.
Словничок новачка:
Сервер / віртуальна машина — комп'ютер, який ти орендуєш; фізично він в AWS, а керуєш ним через інтернет.
Затримка (latency) — за скільки мілісекунд приходить відповідь.
Доступність (availability) — чи працює сервіс зараз («двері відчинені»).
Надійність зберігання (durability) — чи не загубляться дані («речі на складі цілі»).
💡 Запам'ятай
Region ⊃ AZ ⊃ дата-центри.
Збій зони — рятують 2+ AZ. Збій регіону — рятує другий регіон.
Edge location — не регіон: тут кешують, а не запускають сервери.
🎯 Як питають на іспиті
Дані мають фізично лишатися в ЄС→регіон у ЄС + заборона інших регіонів через SCP
Одноцифрові мілісекунди для мешканців конкретного мегаполіса→Local Zones
Дані мають лишатися у своєму дата-центрі, але потрібні сервіси AWS→Outposts
Застосунок має пережити збій одного дата-центру→розгортання у 2+ Availability Zones
⚠️ Не плутай
Availability (працює зараз) ≠ durability (дані не загубляться): 11 дев'яток S3 — це саме durability.
Local Zones (місто) ≠ Wavelength (5G) ≠ Outposts (твій дата-центр).
🤝Хто за що відповідає і 6 стовпів Well-Architected
🖼️ Образ. Оренда квартири. Фундамент, стіни, ліфт і дах — турбота власника будинку (AWS: дата-центри, обладнання, мережа, віртуалізація). А хто має ключі від твоїх дверей, що лежить у шафі й чи зачинене вікно — твоя відповідальність (клієнт: дані, доступи, шифрування, налаштування).
Це модель спільної відповідальності (Shared Responsibility Model). AWS відповідає за безпеку хмари (security OF the cloud), ти — за безпеку в хмарі (security IN the cloud).
Чим більше сервіс «керований», тим менше роботи тобі:
EC2 — ти сам оновлюєш ОС, ставиш патчі, налаштовуєш Security Groups.
RDS — ОС і рушій бази латає AWS; тобі лишаються доступи, бекап-політики, шифрування.
Lambda, S3, DynamoDB — серверів ти не бачиш зовсім; тобі — дані, права і налаштування.
Але навіть у повністю керованому сервісі дані й доступи — твої. Якщо bucket S3 став публічним, винен не AWS.
Well-Architected Framework — шість «питань інспектора», за якими AWS оцінює будь-яку архітектуру. На них побудований і іспит. Мнемоніка — CROPS + S:
Cost Optimization — чи не переплачуємо?
Reliability — чи відновимося після збою?
Operational Excellence — чи автоматизоване керування і чи вчимося на інцидентах?
Performance Efficiency — чи правильні ресурси під навантаження?
Security — чи захищені дані й доступи?
Sustainability — чи ефективно використовуємо ресурси й енергію?
Кілька принципів, які часто «ховаються» в правильних відповідях: мінімальні права і журнали всіх дій (Security); автоматичне відновлення і горизонтальне масштабування замість одного великого сервера (Reliability); керовані сервіси і serverless (Performance); плати лише за використане і розподіляй витрати тегами (Cost).
💡 Запам'ятай
AWS — OF the cloud, ти — IN the cloud.
EC2: ОС латаєш ти. RDS: ОС латає AWS.
Шість стовпів — CROPS + S.
🎯 Як питають на іспиті
Хто встановлює патчі ОС на EC2?→Клієнт
Хто відповідає за фізичну безпеку дата-центрів?→AWS
Хто налаштовує Security Groups і права IAM?→Клієнт
Потрібна самоперевірка архітектури за кращими практиками→AWS Well-Architected Tool
⚠️ Не плутай
Керований сервіс не знімає з тебе відповідальності за дані і доступи.
Well-Architected — це рамка кращих практик, а не окремий сервіс захисту.
🖼️ Образ. Великий офісний центр. IAM users — працівники з перепустками. Groups — відділи: права дають відділу, а не кожному окремо. Roles — тимчасові гостьові бейджі, які охорона (STS) видає на кілька годин. Policies — таблички на дверях: хто, в які двері і за яких умов може заходити.
Як охорона вирішує, чи пустити — три кроки, які треба знати напам'ять:
Ти в чорному списку (явний Deny)? Не пустить ніхто, навіть якщо десь є дозвіл.
Чорного списку немає — охорона шукає дозвіл (Allow).
Дозволу немає — не пускає (неявна заборона). За замовчуванням заборонено все.
Root user — власник будівлі з майстер-ключем. Увімкни йому MFA, сховай ключ і не користуйся ним щодня.
Ролі замість ключів. Застосунок на EC2 отримує права через роль (instance profile) — це бейдж, прикріплений до робота, який сам оновлюється кожні кілька годин. Access keys у коді чи на сервері — як перепустка, приклеєна скотчем до дверей: рано чи пізно її знайдуть.
Багато акаунтів:
AWS Organizations — головний офіс мережі компаній: один рахунок (consolidated billing), акаунти згруповані в OU.
SCP — правила головного офісу для філій: стеля, вище якої ніхто у філії не стрибне, навіть її директор. SCP нічого не дозволяє сама, лише обмежує, і не діє на management account.
Permission boundary — стеля для конкретної людини чи ролі (щоб дати розробникам створювати ролі, але не ширші за межу).
Крос-акаунт — роль в акаунті B, у trust policy якої написано, хто з акаунта A може взяти бейдж (sts:AssumeRole). Стороннім компаніям додають умову sts:ExternalId — захист від «confused deputy».
Вхід людей:
IAM Identity Center — одна перепустка співробітника на всі акаунти компанії (SSO), можна через корпоративний Okta, Entra ID чи Active Directory.
Amazon Cognito — для клієнтів застосунку: User Pool — реєстрація і вхід (хто ти), Identity Pool — тимчасові AWS-ключі (що тобі можна в AWS), наприклад щоб фото з телефона летіли прямо в S3.
🖼️ Образ.KMS — банк ключів. Ключ тобі на руки не видають: ти приносиш дані й кажеш «зашифруй» або «розшифруй», банк робить це всередині й записує кожну операцію в журнал (CloudTrail). CloudHSM — власний сейф у сховищі банку, код від якого знаєш тільки ти.
Дані бувають у двох станах: at rest — лежать на диску («сейф удома»), і in transit — їдуть мережею («броньована машина», тобто TLS/HTTPS). Захищати треба обидва.
KMS — головне:
AWS managed keys (aws/s3, aws/ebs) — ключ «від банку за замовчуванням»: ротація щороку, керувати не можна.
Customer managed keys — твій ключ: сам пишеш key policy (хто може ним користуватися), налаштовуєш ротацію, даєш доступ іншим акаунтам.
Envelope encryption — KMS напряму шифрує лише до 4 KB. Великі дані шифрує окремий «ключ даних», а його самого шифрує KMS-ключ: лист у конверті, конверт у сейфі.
Ключ можна видалити лише з очікуванням 7–30 днів — встигнеш передумати.
S3 шифрує нові об'єкти за замовчуванням (SSE-S3). Потрібен аудит, хто і коли користувався ключем, — обирай SSE-KMS. SSE-C — ключ щоразу приносиш сам.
Існуючі диски й бази не можна «зашифрувати галочкою»: знімок → копія знімка з шифруванням → відновлення з копії. Як переїзд у зашифровану квартиру.
Секрети:
Secrets Manager — сейф з автозаміною замків: сам змінює паролі до БД за розкладом (ротація).
Parameter Store — шафка для налаштувань і секретів: дешево, але без вбудованої ротації.
ACM — паспортний стіл для сайтів: безкоштовні TLS-сертифікати для ALB, CloudFront, API Gateway, які поновлюються самі. Для CloudFront сертифікат має бути в регіоні us-east-1.
💡 Запам'ятай
Аудит використання ключа → SSE-KMS. Ключі лише твої, виділене обладнання → CloudHSM.
Ротація паролів → Secrets Manager. Просто конфіг → Parameter Store.
KMS напряму — до 4 KB, далі envelope encryption.
Зашифрувати існуючу БД чи диск — тільки через копію знімка.
🎯 Як питають на іспиті
Автоматично змінювати пароль до БД кожні 30 днів→Secrets Manager
Ключі лише під контролем компанії, FIPS 140 Level 3, single-tenant→CloudHSM
HTTPS на ALB без ручного поновлення сертифіката→ACM
ThrottlingException від KMS при масовій роботі з S3→S3 Bucket Keys
Поділитися зашифрованим снапшотом з іншим акаунтом→Customer managed key + доступ до ключа
⚠️ Не плутай
KMS (керований, спільний) ≠ CloudHSM (виділене залізо, ключі тільки твої).
🖼️ Образ. Торговий центр і його охорона. WAF — фейс-контроль на вході: перевіряє кожного відвідувача. Shield — дамба від натовпу (DDoS). GuardDuty — розумні камери, що помічають дивну поведінку. Inspector — технагляд, що шукає тріщини. Macie — пес-шукач персональних даних. Security Hub — пульт охорони, куди сходяться всі тривоги.
Захист від атак:
WAF (рівень 7, HTTP) — правила проти SQL injection і XSS, блок IP і країн, rate-based rules («цей відвідувач заходить надто часто»). Ставиться на CloudFront, ALB, API Gateway, AppSync, Cognito — але не на NLB.
Shield Standard — безкоштовно і автоматично для всіх: захист від DDoS рівнів 3–4.
Shield Advanced — платна «страховка»: команда експертів 24/7 і компенсація рахунку, якщо під атакою все масштабувалося.
Firewall Manager — єдиний пульт правил WAF, Shield і Security Groups для всіх акаунтів організації.
Network Firewall — митниця на в'їзді у VPC: фільтрує трафік, зокрема вихідний — за доменами.
Виявлення і розслідування:
GuardDuty — загрози: аналізує CloudTrail, VPC Flow Logs і DNS (криптомайнінг, викрадені ключі, підозрілі IP).
Inspector — вразливості (CVE) в EC2, образах контейнерів і Lambda.
Macie — чутливі дані (PII) в S3.
Detective — слідчий: знаходить першопричину інциденту.
Security Hub — зводить усі знахідки в одне місце і перевіряє стандарти (CIS, PCI DSS).
Журнали і відповідність:
CloudTrail — «хто, що і коли зробив»: кожен виклик API. Хто видалив bucket — питай CloudTrail.
Config — «як виглядав ресурс і чи відповідає правилам»: історія налаштувань і автоматичні перевірки («усі диски зашифровані»).
Artifact — звіти відповідності самого AWS (SOC, PCI) для твоїх аудиторів.
🖼️ Образ.VPC — огороджене містечко в хмарі. Діапазон адрес (CIDR, напр. 10.0.0.0/16) — «номери будинків». Підмережі — квартали, кожен в одному районі (AZ). Internet Gateway — головні ворота на трасу. Route table — дорожні вказівники в кожному кварталі.
Публічна чи приватна підмережа — вирішує лише дорожній вказівник. Якщо в route table є маршрут 0.0.0.0/0 → Internet Gateway, квартал публічний. Немає — приватний. Зазвичай у публічних підмережах стоять балансувальники, а сервери й бази — у приватних.
NAT Gateway — виїзд з односторонньою смугою: мешканці приватного кварталу можуть виїхати в інтернет (завантажити оновлення), а чужі до них не в'їдуть. Стоїть у публічній підмережі; для надійності — по одному в кожній AZ. Платний за годину і за кожен гігабайт.
Два охоронці — головне питання про мережу на іспиті:
Security Group — охоронець біля дверей конкретного будинку (інстансу). Пам'ятає, хто вийшов, і сам пускає відповідь назад (stateful). Має лише список «кого пускати» — тільки Allow. Вміє пускати «всіх, у кого бейдж SG вебсерверів».
Network ACL — шлагбаум на в'їзді в квартал (підмережу). Нічого не пам'ятає (stateless): перевіряє машини в обидва боки, тому треба окремо дозволити відповіді (порти 1024–65535). Має і дозволи, і заборони (Deny), правила перевіряє по черзі за номером.
VPC endpoints — приватні дороги до сервісів AWS без інтернету:
Gateway endpoint — безкоштовна дорога лише до двох складів: S3 і DynamoDB.
Interface endpoint (PrivateLink) — «віконце» з приватною IP-адресою у твоєму кварталі до майже будь-якого сервісу (SQS, KMS, Secrets Manager…). Платний.
Дрібниці, які люблять на іспиті: у кожній підмережі AWS резервує 5 IP-адрес; розмір VPC — від /16 до /28; адміни заходять на приватні сервери через SSM Session Manager, без відкритого порту 22 і без бастіону.
🌉З'єднання — peering, Transit Gateway, VPN, Direct Connect
🖼️ Образ. Твої VPC — окремі містечка. VPC Peering — міст між двома містечками. Transit Gateway — велика транспортна розв'язка, де сходяться дороги всіх містечок і офісу. Site-to-Site VPN — броньований фургон по загальній трасі (інтернету). Direct Connect — власна приватна залізниця до AWS.
VPC Peering:
Зв'язує дві VPC — навіть у різних акаунтах і регіонах.
Не транзитивний: A–B і B–C не дають A–C. Кожній парі — свій міст.
Адреси (CIDR) не можуть перетинатися — інакше «листи заблукають».
Дешевий і простий для 2–3 VPC.
Transit Gateway:
Хаб для десятків і сотень VPC, VPN і Direct Connect, маршрутизація транзитивна.
Ділиться між акаунтами через AWS RAM, між регіонами — через TGW peering.
Платиш за кожне підключення і за кожен гігабайт трафіку.
PrivateLink — «віконце видачі»: сусіди отримують твій сервіс (через NLB), не заходячи в твоє містечко. CIDR можуть збігатися, а споживачів — тисячі.
З'єднання з офісом:
Site-to-Site VPN — зашифровані IPsec-тунелі через інтернет. Налаштовується за хвилини, недорого, 2 тунелі для резерву, до 1,25 Gbps на тунель.
Direct Connect — виділений приватний канал 1–400 Gbps: стабільна швидкість, дешевший вихідний трафік, але прокладання займає тижні. Сам по собі не шифрує — для шифрування VPN поверх нього або MACsec. Резерв — друга лінія в іншій локації або VPN.
Client VPN — для ноутбуків окремих працівників.
Гібридний DNS — Route 53 Resolver endpoints: inbound (офіс питає імена AWS) і outbound (VPC питає імена офісу).
🧭DNS і швидкість для всього світу — Route 53, CloudFront, Global Accelerator
🖼️ Образ.Route 53 — довідкова інтернету: перекладає ім'я (example.com) в адресу і ще вирішує, яку адресу дати саме тобі. CloudFront — мережа місцевих магазинів з копіями товару: береш у найближчому, а не їдеш на центральний склад. Global Accelerator — VIP-коридор в аеропорту з двома постійними входами: заходиш у найближчі двері, далі йдеш швидкою приватною доріжкою AWS.
Route 53 — як довідкова обирає відповідь (routing policies):
Simple — один номер.
Weighted — «90% дзвінків у старий офіс, 10% — у новий» (поступовий реліз).
Latency — до регіону з найменшою затримкою для користувача.
Failover — основний, а якщо перевірка здоров'я провалилась — запасний.
Geolocation — за країною користувача («за паспортом»).
Geoproximity — за відстанню, з можливістю зсунути трафік (bias).
Multivalue — кілька живих адрес на вибір.
Alias — ярлик на ресурс AWS (ALB, CloudFront, S3): працює й для кореневого домену example.com, де звичайний CNAME заборонений, і такі запити безкоштовні.
CloudFront:
Кешує статичний контент на edge-локаціях і прискорює динамічний через мережу AWS.
OAC — склад S3 відчиняється тільки кур'єрам CloudFront: bucket лишається приватним.
Signed URL — квиток на один файл; signed cookies — абонемент на багато файлів.
Блокування країн, WAF, Shield, HTTPS (сертифікат ACM у us-east-1).
Global Accelerator:
2 статичні anycast IP для всього світу; протоколи TCP і UDP; миттєве перемикання між регіонами без очікування DNS-кешу.
🖼️ Образ. Супермаркет. Балансувальник — адміністратор біля входу, що розводить покупців по касах. Auto Scaling — менеджер зміни: черги ростуть — відкриває нові каси, спад — закриває зайві, касир захворів — ставить заміну.
Три балансувальники:
ALB (рівень 7, HTTP/HTTPS) — адміністратор, що читає, куди тобі треба: маршрутизує за шляхом (/api, /images), доменом, заголовками; вміє відправляти запити в Lambda; тримає кілька сертифікатів (SNI); пускає через Cognito. Статичного IP немає.
NLB (рівень 4, TCP/UDP) — швидкісний турнікет: мільйони запитів, наднизька затримка, статичний IP (можна Elastic IP), основа для PrivateLink.
GWLB (рівень 3) — пункт огляду багажу: пропускає весь трафік через сторонні файрволи чи IDS і масштабує їх.
Auto Scaling group (ASG):
Тримає min / desired / max інстансів у кількох AZ і замінює нездорові.
Увімкни ELB health checks — інакше ASG бачить лише, що «сервер увімкнений», а не що застосунок відповідає.
Як масштабувати: target tracking («тримай CPU біля 50%» — найпростіше), step, scheduled («щоп'ятниці о 18:00 більше кас»), predictive («прогноз за історією»).
Воркерів, що обробляють чергу, масштабуй за кількістю повідомлень у SQS на один інстанс.
Корисне: lifecycle hooks (дія перед стартом чи видаленням), warm pools (прогріті інстанси), instance refresh (оновити всіх на новий AMI).
Stateless — золоте правило: касир не тримає твій кошик. Сесії зберігаються в ElastiCache або DynamoDB, а не на сервері — тоді сервери можна вільно додавати й прибирати.
🖼️ Образ. EC2 — автопрокат комп'ютерів. Тип інстансу — модель авто: C — спорткар (потужний процесор), R — вантажівка з великим кузовом (багато пам'яті), I — авто з величезним швидким багажником (диски), P/G — з турбіною (GPU), T/M — універсал на кожен день.
Як читати назву:m7g.2xlarge — сімейство m, покоління 7, g — процесор Graviton (ARM, помітно вигідніший), розмір 2xlarge.
Як платити — найважливіша тема для питань про вартість:
🚕 On-DemandТаксі: платиш за час, без зобов'язаньКороткі й непередбачувані задачі💲💲💲
🚗 Savings Plans / RIАбонемент або лізинг на 1–3 роки, до ~72% знижкиСтабільне навантаження 24/7💲
🎟️ SpotГорящий тур: до 90% дешевше, але можуть забрати з попередженням за 2 хвЗадачі, які можна переривати💲 найдешевше
🏠 Dedicated HostЦілий гараж тільки твій: видно ядра й сокетиЛіцензії BYOL, комплаєнс💲💲💲💲
Compute Savings Plans діють на будь-яке сімейство і регіон, а також на Fargate і Lambda. Capacity Reservation — бронь місця в AZ без знижки.
Розміщення (placement groups):
Cluster — команда за одним столом: максимальна швидкість обміну між серверами (HPC), але одна «пожежа» зачепить усіх.
Spread — кожен у своєму будинку: максимум 7 інстансів на AZ, для кількох критичних серверів.
Partition — секції з окремими входами: сотні серверів Hadoop, Kafka, Cassandra.
Диски і стан:
EBS — «підключений жорсткий диск», дані переживають вимкнення.
Instance store — записи крейдою на дошці: найшвидше, але зникає при зупинці.
AMI — «зліпок» комп'ютера для швидкого клонування; регіональний, копіюється в інші регіони.
Hibernate — сон ноутбука: вміст пам'яті зберігається на диск.
User data — скрипт при першому запуску; IMDSv2 — безпечний доступ до метаданих інстансу.
💡 Запам'ятай
Spot — 2 хвилини попередження. Spread — 7 на AZ.
Постійно — Savings Plans/RI. Можна переривати — Spot. Невідомо — On-Demand. Ліцензії на ядра — Dedicated Host.
Instance store зникає, EBS — ні.
🎯 Як питають на іспиті
Нічні пакетні задачі, які можна перезапускати, найдешевше→Spot Instances
24/7 на 3 роки + свобода міняти сімейства і перейти на Fargate→Compute Savings Plans
Ліцензії Windows або SQL Server прив'язані до фізичних ядер→Dedicated Hosts
HPC з мінімальною затримкою між вузлами→Cluster placement group + EFA
Кодування відео (навантаження на процесор)→C-сімейство
⚠️ Не плутай
Spot не для основної бази і не для задач без чекпоінтів.
Вертикальне масштабування (більший інстанс) — з зупинкою. Горизонтальне (більше інстансів) — через ASG.
🖼️ Образ. Ресторан без власної кухні. API Gateway — офіціант: приймає замовлення, перевіряє, чи ти гість, стежить, щоб не було натовпу. Lambda — кухар на виклик: приходить, готує страву (до 15 хвилин), і ти платиш лише за приготоване. DynamoDB — холодильник, S3 — комора.
🙋 КлієнтМобільний застосунок або сайт
→
🧑💼 API GatewayОфіціант: авторизація, ліміти, кеш
→
👨🍳 LambdaКухар на виклик: до 15 хв, оплата за мілісекунди роботи
→
🧊 DynamoDB · 🪣 S3Холодильник (дані) і комора (файли)
Серверів, які треба латати й масштабувати, немає: кожен шар масштабується сам. Класична відповідь на «serverless API з мінімальним адмініструванням».
Lambda — головне:
До 15 хвилин на виклик, пам'ять 128 MB – 10 GB (процесор росте разом з пам'яттю), 1 000 одночасних виконань за замовчуванням.
Запускається подіями: новий файл у S3, повідомлення в SQS, запит з API Gateway, розклад EventBridge, зміни в DynamoDB.
Cold start — кухар щойно прийшов і розкладає ножі. Ліки: provisioned concurrency (кухарі вже чекають на кухні) і SnapStart (Java, Python, .NET).
Забагато з'єднань до RDS → RDS Proxy. Обмежити функцію → reserved concurrency.
Довше 15 хвилин → Step Functions (розбити на кроки), ECS/Fargate або AWS Batch.
Контейнери — стандартні «морські контейнери» для застосунків: усередині програма з усім потрібним, і вона однаково працює будь-де.
ECS — диспетчер порту від AWS (простіше). EKS — керований Kubernetes (якщо команда вже на K8s).
Fargate — порт сам дає крани й причали: контейнери без серверів (для ECS і EKS).
ECR — склад образів контейнерів.
Elastic Beanstalk — ресторан під ключ: приносиш код, AWS сам ставить сервери, балансувальник і масштабування.
AWS Batch — цех для великих пакетних задач будь-якої тривалості.
💡 Запам'ятай
Lambda: 15 хвилин, 10 GB, 1 000 одночасно.
Cold start → provisioned concurrency або SnapStart.
Контейнери без серверів → Fargate. Уже є Kubernetes → EKS.
🎯 Як питають на іспиті
Задача виконується 40 хвилин→не Lambda: AWS Batch, ECS/Fargate або Step Functions
🖼️ Образ. Поліклініка. SQS — талончики в черзі: пацієнти (повідомлення) чекають, а лікарі (воркери) беруть по одному у своєму темпі. SNS — гучномовець: одне оголошення чують усі одразу. EventBridge — диспетчерська з правилами «яка подія — куди». Step Functions — головлікар з покроковим планом лікування.
SQS (pull — «забирай сам»):
Розв'язує компоненти й згладжує піки: замовлення не губляться, навіть якщо бекенд упав (повідомлення зберігаються до 14 днів).
Visibility timeout — талон у руках лікаря: інші його не бачать. Не встиг за відведений час — талон повертається в чергу, і його обробить хтось іще. Ліки від «обробки двічі» — збільшити timeout.
Standard — майже без лімітів, але можливі дублі й зміна порядку. FIFO — строгий порядок і без дублів.
DLQ — окрема папка для «безнадійних» талонів після кількох невдалих спроб.
Long polling — лікар чекає до 20 секунд, а не смикає реєстратуру щосекунди (дешевше).
SNS (push — «кажу всім»):
Одне повідомлення → багато підписників: SQS, Lambda, email, SMS, HTTP.
SNS — не черга: «на потім» нічого не зберігає. Тому класика — fan-out: SNS → кілька SQS, у кожного обробника своя поштова скринька.
EventBridge — події від AWS, твоїх застосунків і SaaS (Zendesk, Shopify…) → правила → цілі. Плюс Scheduler — будильник (cron) без серверів.
Step Functions — покроковий процес з повторами, розгалуженнями і паузою на ручне схвалення. Standard — до року; Express — до 5 хвилин, для величезних потоків.
Kinesis Data Streams — річка даних з пам'яттю: кілька заводів беруть воду з тієї ж річки в реальному часі й можуть «перемотати» назад. Data Firehose — трубопровід, що сам доставляє потік у S3, Redshift чи OpenSearch.
Amazon MQ — перекладач для старих застосунків на JMS, AMQP чи MQTT (RabbitMQ, ActiveMQ) без переписування коду.
🖼️ Образ. S3 — безрозмірний склад. Bucket — окремий склад з унікальною на весь світ назвою. Object — коробка з ярликом-адресою (ключем), розміром до 50 TB. «Повно» на цьому складі не буває, а надійність — 11 дев'яток: з 10 мільйонів коробок у середньому губиться одна за 10 000 років.
S3 — не диск і не файлова система, а сховище об'єктів, до якого звертаються через HTTP/API. Ідеальне для файлів, фото й відео, бекапів, логів, data lake і статичних сайтів. Змонтувати S3 як диск для бази не можна.
Класи зберігання — будинок від передпокою до сховища в горах:
🚪 ПередпокійS3 Standardчасто, мілісекунди
🤖 Розумний комірникIntelligent-Tieringсам переносить, коли доступ змінюється
🧺 КомораStandard-IAOne Zone-IAрідко, але миттєво; мінімум 30 днів; плата за отримання
🗄️ Архів поручGlacier Instant Retrieval~раз на квартал, мілісекунди; мінімум 90 днів
🧊 ПідвалGlacier Flexible Retrievalхвилини–години; мінімум 90 днів
🏔️ Сховище в горахGlacier Deep Archiveдо 12–48 год, найдешевше; мінімум 180 днів
Що нижче — то дешевше зберігати, але довше й дорожче діставати. Мнемоніка мінімальних строків: 30 · 90 · 180.
Керування складом:
Lifecycle — автоматичне переселення речей з віком: через 30 днів у комору, через 90 — в архів, через 7 років — викинути.
Versioning — машина часу: перезапис і видалення не знищують попередніх версій.
Object Lock — сейф з таймером (WORM): у режимі compliance не видалить ніхто, навіть root; у governance — лише з особливим дозволом.
Replication — філія складу в іншому регіоні (CRR) або в тому самому (SRR); потрібен versioning.
Доступ і безпека: Block Public Access увімкнено за замовчуванням; права — через bucket policy та IAM; presigned URL — тимчасовий пропуск на одну коробку; сайт з HTTPS — через CloudFront + OAC.
Швидкість: 3 500 записів і 5 500 читань за секунду на кожен префікс (більше префіксів — швидше); великі файли — multipart upload частинами; з далеких країн — Transfer Acceleration.
🖼️ Образ. Три способи тримати документи. Блочне сховище (EBS) — жорсткий диск, прикручений до одного комп'ютера. Файлове (EFS, FSx) — спільна мережева папка для всього офісу. Об'єктне (S3) — склад, куди звертаються через інтернет.
EBS:
Живе в одній AZ і підключається до одного інстансу (виняток — Multi-Attach для io1/io2).
Snapshot — «фотографія» диска в S3: з неї створюють диск в іншій AZ чи регіоні.
Типи: gp3 — універсал, продуктивність налаштовується окремо від розміру (до 80 000 IOPS); io2 Block Express — гоночний SSD для критичних баз (до 256 000 IOPS, затримка менше мілісекунди); st1 — вантажівка для великих послідовних даних (логи, big data); sc1 — холодний і найдешевший. HDD-диски (st1, sc1) не можуть бути системними.
Шифрування за замовчуванням вмикається однією галочкою на весь регіон.
Instance store — крейда на дошці: найшвидше, але зникає при зупинці. Лише для кешу й тимчасових даних.
EFS — спільна мережева папка (NFS) для Linux: тисячі серверів у кількох AZ одночасно, об'єм росте сам. Класи Standard, Infrequent Access і Archive з автоматичним переселенням. Security Group має пропускати порт 2049.
FSx — спеціалізовані файлові сервери:
for Windows File Server — SMB, NTFS і Active Directory для Windows-програм.
for Lustre — болід Формули-1 для HPC і машинного навчання: сотні GB/s, дружить із S3.
for NetApp ONTAP — швейцарський ніж: NFS, SMB і iSCSI одночасно.
for OpenZFS — для переїзду з ZFS.
💡 Запам'ятай
Блок — один сервер (EBS). Файли — багато серверів (EFS для Linux, FSx для Windows і HPC). Об'єкти — через HTTP (S3).
Понад 80 000 IOPS на одному томі → io2 Block Express.
Windows + AD → FSx for Windows. HPC + S3 → FSx for Lustre.
🎯 Як питають на іспиті
Спільна папка для сотень Linux-серверів у різних AZ→EFS
Спільні файли для Windows з Active Directory→FSx for Windows File Server
HPC з даними в S3→FSx for Lustre
Дешевше за gp2 і без простою→перейти на gp3
Перенести диск в іншу AZ→snapshot → новий том у потрібній AZ
⚠️ Не плутай
EBS не можна підключити до інстансу в іншій AZ.
EFS — лише Linux (NFS); для Windows — FSx for Windows.
🖼️ Образ. Переїзд великої компанії в хмару. Storage Gateway — перехідник між старим офісом і хмарою. DataSync — швидкісна вантажівка по трасі (мережею). Snowball — фізичний контейнер, який везуть поштою, коли траса надто повільна. DMS — переїзд магазину без зачинення: товари переносять, а продажі тривають.
Гібридне зберігання — Storage Gateway:
S3 File Gateway — звичні NFS/SMB-папки в офісі, а файли лягають у S3 (з локальним кешем).
Volume Gateway — диски iSCSI: Cached — основні дані в хмарі, Stored — основні локально, копія в хмарі.
Tape Gateway — віртуальні касети замість справжніх для наявного бекап-ПЗ.
Перенесення даних:
DataSync — онлайн-перенесення і синхронізація терабайтів з NAS, NFS, SMB чи HDFS у S3, EFS або FSx — з перевіркою цілісності й за розкладом.
Transfer Family — SFTP/FTPS/FTP-сервер поверх S3: партнери надсилають файли як і раніше.
Snowball Edge — офлайн-перенесення сотень терабайтів; орієнтир — якщо мережею довше тижня. (З листопада 2025 недоступний новим клієнтам, але на іспиті може зустрітися.)
Бази даних:
DMS — міграція з мінімальним простоєм: стара база працює, а зміни безперервно копіюються (CDC).
Однаковий рушій (MySQL → Aurora MySQL) — достатньо DMS. Різні рушії (Oracle → Aurora PostgreSQL) — спершу SCT («перекладач креслень»), потім DMS.
Сервери:
Application Migration Service (MGN) — «перевезти будинок цілком»: lift-and-shift серверів у EC2.
Elastic Disaster Recovery — резервна копія серверів в AWS з RPO в секунди.
7 R — стратегії переїзду:Retire (викинути), Retain (залишити), Rehost (перевезти як є — MGN), Relocate (разом з фундаментом — VMware Cloud on AWS), Replatform (перевезти й трохи підлатати, напр. базу на RDS), Repurchase (купити готовий SaaS), Refactor (перебудувати по-новому, serverless).
💡 Запам'ятай
Жити гібридно → Storage Gateway. Перенести мережею → DataSync. Без мережі → Snowball.
Різні рушії бази → SCT + DMS.
Сервери «як є» → MGN.
🎯 Як питають на іспиті
Офісні програми пишуть файли в S3 через NFS/SMB→S3 File Gateway
🖼️ Образ.RDS — найнятий адміністратор бази даних: сам встановлює, латає, робить бекапи. Multi-AZ — дублер у запасній кімнаті: синхронно записує все, але з клієнтами не говорить; основний знепритомнів — дублер за хвилину-дві стає до роботи. Read replicas — помічники, які лише відповідають на запитання (читання) і можуть трохи відставати.
RDS:
MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2. Доступу до операційної системи немає (крім RDS Custom).
Multi-AZ — для виживання: синхронна копія в іншій AZ, автоматичне перемикання (зазвичай 60–120 с), та сама адреса підключення.
Read replicas — для читання: асинхронні, до 15, можуть бути в іншому регіоні (і стати основною базою під час аварії). Застосунок сам надсилає читання на репліку.
Бекапи на 1–35 днів + відновлення на будь-яку мить (point-in-time). Відновлення завжди створює нову базу з новою адресою.
RDS Proxy — секретар, що тримає телефонні лінії: пул з'єднань для тисяч функцій Lambda і швидше перемикання.
Aurora — «турбо-версія» MySQL і PostgreSQL від AWS:
6 копій даних у 3 AZ, сховище саме росте до 256 TiB.
До 15 реплік на спільному сховищі, перемикання приблизно за 30 с, репліки можна додавати автоматично.
Входи: writer (запис), reader (читання, розподіляє між репліками), custom (окремий вхід, напр. для аналітиків).
Global Database — філії в інших регіонах (до 10) з відставанням менше секунди; перемикання менш ніж за хвилину.
Serverless v2 — «авто з автоматичною коробкою»: сам додає потужність і може «заснути» до нуля, тоді платиш лише за сховище.
Backtrack — перемотка назад без відновлення з бекапу (лише Aurora MySQL). Cloning — миттєва копія для тестів. Babelfish — розуміє мову SQL Server (T-SQL).
💡 Запам'ятай
Multi-AZ — для виживання. Read Replica — для читання.
Aurora: «6 копій у 3 AZ», 15 реплік, Global Database — менше секунди.
🖼️ Образ.DynamoDB — гігантська картотека: знаєш номер картки (ключ) — отримуєш її за мілісекунди, навіть коли запитів мільйони. DAX — кишенька з найчастішими картками (мікросекунди). ElastiCache — записник на столі: не треба щоразу бігти в архів (у базу).
DynamoDB:
Serverless NoSQL: мілісекунди на будь-якому масштабі, дані в кількох AZ автоматично. Одна «картка» (елемент) — до 400 KB.
Ключ — partition key (номер ящика) + за потреби sort key. Обирай ключ з багатьма різними значеннями (userId), інакше буде «гарячий» ящик і throttling.
Оплата: on-demand (за кожен запит — для непередбачуваного трафіку) або provisioned (абонемент на RCU/WCU + auto scaling — для стабільного).
Global Tables — картотека в кількох регіонах із записом у будь-якому.
Streams — стрічка змін → Lambda. TTL — картки самі знищуються з часом. PITR — відновлення на будь-яку секунду за 35 днів.
Складних JOIN немає — це не реляційна база.
Кеш:
ElastiCache (Redis OSS / Valkey) — реплікація, Multi-AZ, складні структури: sorted sets для лідербордів, сесії.
Memcached — простий швидкий кеш без реплікації.
Кеш вимагає змін у коді («спершу глянь у записник»). DAX — майже без змін, але тільки для DynamoDB.
🖼️ Образ.Data lake — озеро, куди стікають усі річки даних у сирому вигляді (S3). Glue — бібліотекар: складає каталог, що де лежить, і наводить лад (ETL). Athena — питаєш SQL прямо в озера. Redshift — склад з упорядкованими полицями для звітів. Quick — вітрина з дашбордами для керівників.
Потоки:
Kinesis Data Streams — річка в реальному часі: кілька споживачів, перемотка (replay) до 365 днів.
Data Firehose — трубопровід: сам складає потік у S3, Redshift чи OpenSearch і може перетворити JSON у Parquet.
Managed Service for Apache Flink — аналіз потоку «на льоту» (вікна часу, аномалії).
MSK — керований Kafka для наявних Kafka-застосунків.
Озеро і запити:
Glue — crawler визначає схему, Data Catalog зберігає опис таблиць, ETL перетворює CSV у Parquet.
Athena — SQL по файлах у S3 без серверів; платиш за прочитані дані. CSV — щоб знайти одне слово, читаєш усю книгу; Parquet з партиціями — одразу відкриваєш потрібну главу. Тому в рази дешевше і швидше.
Redshift — сховище даних для важкої регулярної аналітики; Spectrum — «зі складу заглянути в озеро»; zero-ETL з Aurora.
EMR — важкий завод Spark/Hadoop (task-вузли на Spot — дешево).
OpenSearch — пошук і аналіз логів.
Amazon Quick (колишній QuickSight) — дашборди.
Lake Formation — охорона озера: доступ аж до окремих колонок і рядків.
🖼️ Образ. Набір готових «органів чуття» для твого застосунку. Rekognition — очі. Transcribe — вуха. Polly — голос. Translate — перекладач. Comprehend — читач, що розуміє настрій і зміст тексту. Textract — бухгалтер, що читає документи й таблиці. Lex — співрозмовник-чатбот. SageMaker AI — лабораторія, де вирощують власний «мозок» (модель).
Головна думка для іспиту: якщо задача стандартна (розпізнати обличчя, перетворити мову в текст, перекласти) — бери готовий сервіс, знання машинного навчання не потрібні. Якщо потрібна власна модель — SageMaker AI.
Rekognition — об'єкти й обличчя на фото і відео, модерація контенту.
Textract — текст, форми й таблиці зі сканів і PDF (більше, ніж простий OCR).
Comprehend — тональність відгуків, ключові фрази, мова, персональні дані в тексті.
Transcribe — мова → текст (дзвінки, субтитри).
Polly — текст → мова (озвучення). Мнемоніка: папуга Поллі говорить.
Translate — машинний переклад.
Lex — чатботи (голос і текст).
SageMaker AI — навчити, розгорнути й обслуговувати свою модель.
Ланцюжок, який люблять на іспиті: записи дзвінків → Transcribe → текст → Comprehend (настрій) або Translate → Polly (озвучити).
А ще для фронтенду: Amplify — хостинг і бекенд для веб- і мобільних застосунків, Device Farm — тестування на сотнях справжніх телефонів.
💡 Запам'ятай
Очі — Rekognition. Вуха — Transcribe. Голос — Polly. Документи — Textract. Розуміння тексту — Comprehend.
Власна модель — SageMaker AI.
🎯 Як питають на іспиті
Модерація фото користувачів→Rekognition
Дані з рахунків і форм у PDF→Textract
Тональність відгуків→Comprehend
Субтитри з відео→Transcribe
Озвучити статті→Polly
⚠️ Не плутай
Transcribe (мова → текст) ≠ Polly (текст → мова).
Textract (документи, форми) ≠ Rekognition (фото і відео).
← Усі урокиЕксплуатація та іспит · урок 21 з 24 · ⏱ 7 хв
📈Моніторинг, аудит і автоматизація
🖼️ Образ. Автомобіль. CloudWatch — приладова панель: спідометр (метрики), лампочки (аларми), бортовий журнал (логи). CloudTrail — відеореєстратор: записує кожну дію водія (виклик API). Config — фотоархів: як виглядала машина вчора і чи відповідає правилам техогляду. X-Ray — рентген поїздки запиту через усі вузли.
CloudWatch:
Метрики EC2: процесор, мережа, диск, статус. Пам'ять і вільне місце на диску він не бачить без CloudWatch agent — датчик пального ставлять окремо.
Аларми → сповіщення (SNS), масштабування, дії з EC2 (відновити, перезавантажити).
Logs: зберігання й пошук логів, metric filters («порахуй рядки з ERROR»), передача далі в реальному часі.
CloudTrail — хто, що, коли і звідки зробив через API. Історія за 90 днів безкоштовна; для довгого зберігання — trail у S3; organization trail — одразу всі акаунти.
Config — історія налаштувань ресурсів і правила відповідності з автовиправленням: «усі bucket приватні», «усі диски зашифровані».
Systems Manager — пульт керування автопарком серверів:
Session Manager — зайти на сервер без SSH і відкритих портів;
Run Command — виконати команду на всіх серверах одразу;
Patch Manager — встановлювати патчі за розкладом;
Parameter Store — налаштування і секрети.
CloudFormation — креслення будинку (інфраструктура як код): за одним кресленням будують однакові середовища будь-де. StackSets — одразу в багатьох акаунтах і регіонах.
Порадники:Trusted Advisor (вартість, безпека, ліміти сервісів), Compute Optimizer (правильний розмір інстансів), Health Dashboard (збої й обслуговування AWS, які зачіпають саме тебе).
💡 Запам'ятай
CloudWatch — Watch (здоров'я і метрики). CloudTrail — Trail (сліди дій). Config — стан і правила.
Пам'ять на EC2 → CloudWatch agent.
Без SSH → Session Manager.
🎯 Як питають на іспиті
Моніторити пам'ять і диск EC2→CloudWatch agent
Хто видалив ресурс→CloudTrail
Автоматично перевіряти й виправляти налаштування→Config rules + remediation
Де гальмує запит між мікросервісами→X-Ray
Однакова інфраструктура в багатьох акаунтах→CloudFormation StackSets
⚠️ Не плутай
CloudTrail ≠ CloudWatch: сліди дій проти метрик і логів.
← Усі урокиЕксплуатація та іспит · урок 22 з 24 · ⏱ 8 хв
🛟Висока доступність і відновлення після аварій
🖼️ Образ.Висока доступність — запасне колесо і другий водій: щось зламалось — їдемо далі після короткої зупинки. Відмовостійкість — двомоторний літак: один мотор відмовив, а політ триває без зупинки. Disaster recovery (DR) — план на випадок пожежі в цілому місті (регіоні).
Два числа, які визначають усе:
RPO — скільки даних можна втратити: «скільки останніх сторінок щоденника не шкода».
RTO — скільки часу можна простояти: «через скільки ресторан знову годує гостей».
Стратегії DR — від дешевої до дорогої:
Backup & Restore — фото документів у сейфі: після аварії відновлюєш усе з бекапів. RPO і RTO — години.
Pilot Light — запальник котла: у другому регіоні постійно «горить» лише база (реплікується), решту розпалюєш під час аварії. Десятки хвилин.
Warm Standby — прогріта запасна кухня з мінімальним персоналом: зменшена копія працює завжди, при аварії її збільшують. Хвилини.
Multi-site Active-Active — два ресторани працюють одночасно. Майже нуль, але найдорожче.
Цеглинки надійності:
2+ AZ всюди: ALB + Auto Scaling + Multi-AZ база; сервери без збереженого стану.
Черги SQS між компонентами: збій одного не валить інших.
Другий регіон: Route 53 failover або Global Accelerator; Aurora Global Database; DynamoDB Global Tables; S3 Cross-Region Replication; AMI і знімки в другому регіоні; CloudFormation, щоб швидко відтворити інфраструктуру.
AWS Backup — централізовані бекапи з копіями між регіонами й акаунтами; Vault Lock — навіть адмін не видалить бекап (захист від ransomware).
Старий застосунок на одному сервері → Auto Scaling group з min = max = 1: зламався — його замінять автоматично.
← Усі урокиЕксплуатація та іспит · урок 23 з 24 · ⏱ 7 хв
💰Вартість — розумний гаманець
🖼️ Образ. В'їзд у місто AWS безкоштовний, а виїзд — платний. Переїзд між районами (AZ) — платний міст. NAT Gateway — платний КПП, що бере гроші з кожної тонни вантажу (гігабайта). Gateway endpoint — безкоштовна приватна дорога до S3 і DynamoDB. CloudFront — доставка з місцевих складів, дешевша за доставку з центру.
Принцип: плати лише за використане і підбирай спосіб оплати під характер навантаження.
Обчислення: постійне навантаження → Savings Plans або RI; переривне → Spot; невідоме → On-Demand або serverless; правильний розмір → Compute Optimizer; процесори Graviton; вимикати dev/test на ніч (EventBridge Scheduler).
Сховище: lifecycle у S3, Intelligent-Tiering, gp3 замість gp2, прибирати старі знімки й непідключені диски.
Бази: Aurora Serverless v2 або DynamoDB on-demand для нерівномірного навантаження; кеш замість більшого сервера; Database Savings Plans.
Мережа: gateway endpoints замість NAT для S3 і DynamoDB; CloudFront для роздачі контенту; для кількох VPC з великим трафіком peering дешевший за Transit Gateway; Direct Connect для великих постійних обсягів.
Інструменти:
Budgets — ліміт на картці з SMS: сповіщення, коли витрати або прогноз перевищать поріг.
Cost Explorer — виписка з графіками, прогнозом і порадами щодо Savings Plans.
Cost and Usage Report — найдетальніший чек (кожен ресурс, кожна година) для аналізу в Athena.
Cost allocation tags — ярлики на чеках: розподіл витрат між відділами (теги треба активувати в Billing).
← Усі урокиЕксплуатація та іспит · урок 24 з 24 · ⏱ 6 хв
🏁Як розв'язувати питання іспиту
🖼️ Образ. Кожне питання — детектив. Замовник залишив у тексті докази (вимоги). Твоє завдання — знайти ключові докази, викреслити «підозрюваних з алібі» (неможливі варіанти) і обрати того, хто підходить під усі докази.
Алгоритм на кожне питання (≈2 хвилини):
Прочитай останнє речення — там критерій: MOST cost-effective, LEAST operational overhead, MOST secure, highly available.
Виділи вимоги: регіон чи AZ, RPO/RTO, «без змін коду», real-time, serverless, шифрування.
Викресли неможливе: Deny у Security Group, WAF на NLB, Lambda на годину, EBS в іншій AZ, читання з Multi-AZ standby.
З решти обери керований і простіший варіант, що виконує всі вимоги.
Не впевнений — познач (flag), дай найкращу відповідь і повернися в кінці. Порожніх не лишай.
Три розбори:
«Замовлення губляться під час непередбачуваних піків. Як розв'язати компоненти?» Шукаємо буфер, що зберігає повідомлення → SQS. SNS не зберігає, Kinesis — для потокової аналітики, більший сервер не лікує піки.
«EC2 у приватній підмережі пишуть у S3; мінімальна вартість, без інтернету». Потрібен приватний шлях до S3 без плати за гігабайти → gateway endpoint. NAT Gateway бере гроші за трафік, interface endpoint платний, публічна підмережа — гірша безпека.
«Дані читають рідко, але коли треба — миттєво; зберігати рік». Рідко + мілісекунди → S3 Standard-IA (якщо раз на квартал — Glacier Instant Retrieval). Glacier Flexible — хвилини чи години, One Zone-IA — ризик втратити дані разом з AZ.
Фінальна підготовка: план на 14 днів — у шпаргалці (розділ 29). Проходь «Тест» у режимі «Іспит»; якщо стабільно 80%+ — можна записуватися. І не забудь подати ESL +30 хвилин до запису.
💡 Запам'ятай
Останнє речення → вимоги → викреслити неможливе → керований варіант, що виконує все.
Штрафу немає — відповідай на все.
🎯 Як питають на іспиті
«LEAST operational overhead»→керований або serverless сервіс
«without code changes»→RDS Proxy, Storage Gateway, EFS, Global Accelerator, MGN
«real-time with multiple consumers»→Kinesis Data Streams
«decouple» / «buffer»→SQS
⚠️ Не плутай
Надто складна відповідь з купою сервісів і скриптів — зазвичай пастка, якщо є простий керований шлях.
Стисла версія курсу: короткі факти → 🎯 тригери «бачиш у питанні → відповідь» → ⚠️ пастки. Перевірено за офіційним гайдом і документацією AWS станом на вересень 2026.
+30 хвилин (ESL +30): якщо англійська не рідна — у кабінеті aws.training/Certification → Request Exam Accommodations → ESL +30 MINUTES. Подається один раз і до запису на іспит (якщо вже записаний — скасуй запис, подай запит, запишись знову). Схвалюється автоматично.
Мови: англійська, французька, італійська (до 31.12.2026), японська, корейська, португальська (Бразилія), іспанська, китайська. Української немає — вчи терміни англійською.
Назви сервісів: в іспиті короткі назви (Amazon SNS замість Amazon Simple Notification Service). Повні назви — за кнопкою Help під час іспиту.
Де складати: центр Pearson VUE або онлайн з проктором (вдома, з веб-камерою, чистий стіл).
Результат: одразу після іспиту бала не показують — він приходить на email і в кабінет, зазвичай за кілька годин (AWS обіцяє до 5 робочих днів).
Сертифікат діє 3 роки. Після здачі в кабінеті є знижка 50% на наступний іспит AWS.
2Тактика: як читати питання
Спочатку прочитай останнє речення — там критерій вибору («MOST cost-effective», «LEAST operational overhead»).
Подумки випиши всі вимоги: RPO/RTO, бюджет, «без змін коду», «serverless», регіони, шифрування. Правильна відповідь виконує всі вимоги одночасно.
Відкидай неможливе: Deny-правило в Security Group, Gateway endpoint для SQS, WAF на NLB, читання з RDS Multi-AZ standby, EBS-том до інстансу в іншій AZ, Lambda на 2 години.
Якщо є керований (managed) сервіс, варіант «напишемо свій скрипт на EC2 / cron» майже завжди неправильний.
Два варіанти схожі — шукай одну відмінну деталь: Standard vs FIFO, Gateway vs Interface, User pool vs Identity pool, Compliance vs Governance.
Час: ~2 хв на питання. Не впевнений — дай найкращу відповідь, познач Flag for review і йди далі. В кінці поверніться до позначених.
В питаннях можуть бути старі назви: Kinesis Data Firehose = Amazon Data Firehose; QuickSight = Amazon Quick; Kinesis Data Analytics = Managed Service for Apache Flink; SageMaker = SageMaker AI; AWS SSO = IAM Identity Center; CloudWatch Events = EventBridge.
Ключові фрази в питаннях
Фраза в питанні
Що це означає
MOST cost-effective / LOWEST cost
Найдешевше, що виконує всі вимоги: Spot, lifecycle S3, serverless, Savings Plans, gateway endpoint
LEAST operational overhead / minimal management
Керований або serverless сервіс, мінімум компонентів, без власних скриптів і EC2
MOST secure / least privilege
Мінімальні права, IAM roles замість ключів, KMS, приватні підмережі, VPC endpoints
highly available
Кілька AZ: Multi-AZ, ASG у 2+ AZ + ALB
fault tolerant
Працює без перерви навіть під час збою (надлишковість, active-active)
durable
Дані не загубляться: S3 (11 дев'яток), реплікація, бекапи
scalable / elastic
Auto Scaling, serverless, DynamoDB on-demand, Aurora Serverless
decouple / buffer / spikes
SQS між компонентами
real-time (мілісекунди, свої споживачі, replay)
Kinesis Data Streams
near real-time, доставка в S3/Redshift/OpenSearch без коду
Amazon Data Firehose
without code changes / minimal changes
RDS Proxy, Storage Gateway, EFS, Global Accelerator, MGN (lift-and-shift), Babelfish
temporary credentials
IAM Role + STS
static IP
NLB з Elastic IP або Global Accelerator
global users + static/dynamic web content
CloudFront
global users + TCP/UDP + fast regional failover
Global Accelerator
on-premises + low-latency access to cloud storage
Storage Gateway (локальний кеш)
migrate TBs/PBs over the network
DataSync
orchestrate / workflow / human approval
Step Functions
3Основи: інфраструктура, модель відповідальності, Well-Architected
Region — географічний регіон (напр., eu-central-1). Складається з кількох (зазвичай 3+) Availability Zones (AZ) — ізольованих дата-центрів з окремим живленням і мережею. Висока доступність = кілька AZ; захист від падіння всього регіону = кілька регіонів.
Edge locations — точки CloudFront, Route 53 і Global Accelerator поруч з користувачами.
Local Zones — AWS у великому місті (одноцифрові мс до користувачів). Wavelength — AWS всередині 5G-мережі оператора. Outposts — стійки AWS у твоєму дата-центрі.
Shared Responsibility Model: AWS відповідає за безпеку OF the cloud (залізо, дата-центри, гіпервізор, керовані сервіси). Клієнт — за безпеку IN the cloud (дані, IAM, шифрування, Security Groups/NACL, патчі ОС на EC2, налаштування). На RDS і Lambda ОС патчить AWS, але доступи й дані — твоя відповідальність.
Well-Architected — 6 стовпів: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability. Увесь іспит побудований на них.
Service Quotas — ліміти сервісів. Soft-ліміти можна підняти. Для DR-регіону квоти треба підняти заздалегідь.
Well-Architected: принципи кожного стовпа (коротко)
Operational Excellence: операції як код (IaC), часті малі зворотні зміни, передбачати збої, вчитися на кожному інциденті, спостережуваність (метрики, логи, трасування).
Security: сильна основа ідентичності (least privilege, без довгострокових ключів), відстежуваність (логи, аудит), захист на всіх рівнях (мережа, інстанс, застосунок, дані), автоматизація безпеки, шифрування in transit і at rest, «тримати людей подалі від даних», готовність до інцидентів.
Reliability: автоматичне відновлення після збоїв, тестування відновлення, горизонтальне масштабування замість одного великого ресурсу, «не вгадувати потужність» (Auto Scaling), зміни через автоматизацію.
Performance Efficiency: використовувати готові керовані сервіси, «глобально за хвилини» (регіони, CloudFront), serverless, часті експерименти, обирати технологію під патерн доступу.
Cost Optimization: фінансове керування хмарою, модель «плати за використане», вимірювати ефективність, не витрачати на «важку рутину» (керовані сервіси), розподіляти витрати (теги, акаунти).
Sustainability: розуміти свій вплив, максимізувати завантаження ресурсів, нові ефективніші типи (напр., Graviton), керовані сервіси, менше зайвих даних і трафіку.
🎯 Тригери
Дані мають фізично лишатися у своєму дата-центрі, але потрібні сервіси AWS→AWS Outposts
Одноцифрова мс затримка для користувачів у конкретному місті→AWS Local Zones
Ультранизька затримка для мобільних пристроїв у 5G-мережі→AWS Wavelength
Перенести VMware-середовище без зміни інструментів→VMware Cloud on AWS
Хто патчить ОС на EC2?→Клієнт (на RDS — AWS)
Резервний регіон не зміг запустити потрібну кількість інстансів під час аварії→Заздалегідь підняти Service Quotas у DR-регіоні
4IAM і керування доступом
IAM — глобальний сервіс. Суб'єкти: users, groups (групи не вкладаються одна в одну), roles. Політика — JSON: Effect, Action, Resource, Condition (і Principal у resource-based).
Root user: лише для задач, які може тільки root. Увімкни MFA, не створюй access keys для root.
Least privilege — мінімальні права. IAM Access Analyzer знаходить ресурси, відкриті зовнішнім акаунтам, і генерує політики з історії CloudTrail.
Ролі замість ключів: EC2 → instance profile з роллю; Lambda → execution role; ECS → task role. Ніколи не зберігай access keys у коді чи на EC2.
STS видає тимчасові облікові дані: AssumeRole (крос-акаунт, перемикання ролей), AssumeRoleWithSAML (корпоративний IdP), AssumeRoleWithWebIdentity (краще через Cognito).
Cross-account доступ: роль в акаунті B з trust policy для акаунта A. Або resource-based policy на ресурсі (S3 bucket policy, KMS key policy, SQS/SNS policy, Lambda policy).
Permission boundary — «стеля» прав для user/role. Дає делегувати: розробник може створювати ролі, але не ширші за межу.
Умови в політиках:aws:SourceIp, aws:RequestedRegion, aws:MultiFactorAuthPresent, aws:PrincipalOrgID (доступ лише акаунтам твоєї організації), aws:SecureTransport. Теги + умови = ABAC.
AWS Organizations: багато акаунтів в OU; consolidated billing (один рахунок, об'ємні знижки, спільні RI і Savings Plans).
SCP — обмежують максимум дозволів для акаунтів/OU. Самі не дають прав. Не діють на management account.
RCP (resource control policies, з 2024) — обмеження на ресурси в акаунтах, напр. «до S3 не може звертатися ніхто поза організацією».
Також tag policies, backup policies.
AWS Control Tower — готова landing zone для багатьох акаунтів за best practices: Account Factory, controls/guardrails (preventive = SCP, detective = Config rules, proactive = CloudFormation hooks), централізовані логи.
IAM Identity Center (колишній AWS SSO) — єдиний вхід співробітників у всі акаунти й бізнес-застосунки. Permission sets. Джерело користувачів: вбудоване, Active Directory або зовнішній IdP (Okta, Entra ID) через SAML 2.0 / SCIM.
AWS Directory Service:
Managed Microsoft AD — справжній AD в AWS, trust з on-prem AD.
AD Connector — проксі до on-prem AD, нічого не зберігає в AWS.
Simple AD — дешевий Samba-сумісний, без trust, для малих середовищ.
Amazon Cognito:
User Pools — реєстрація і вхід користувачів застосунку (email/пароль, соцмережі, SAML/OIDC), видає JWT-токени, інтеграція з ALB і API Gateway.
Identity Pools — видає тимчасові AWS-credentials користувачам (навіть гостям), щоб напряму працювати з S3, DynamoDB тощо.
AWS RAM — ділитися ресурсами між акаунтами: підмережі (VPC sharing), Transit Gateway, правила Route 53 Resolver, конфігурації License Manager тощо.
IAM Access Advisor (last accessed) — показує, якими сервісами роль чи користувач реально користувалися → прибрати зайві права.
IAM Roles Anywhere — on-prem сервери отримують тимчасові AWS-credentials за X.509-сертифікатом, без довгострокових ключів.
Як AWS перевіряє доступ
1
Є явний Deny у будь-якій політиці? SCP/RCP, resource-based, permission boundary, identity-based
Так → ❌ DENY
↓ ні
2
SCP (і RCP) організації дозволяють дію? Діють на member-акаунти, але не на management account
Ні → ❌ DENY
↓ так
3
Permission boundary (якщо задана) дозволяє? Це «стеля» прав користувача або ролі
Ні → ❌ DENY
↓ так
4
Identity-based або resource-based policy дає Allow?
Так → ✅ ALLOW
↓ ні
5
Неявна заборона — за замовчуванням заборонено все
❌ DENY
Крос-акаунтний доступ: потрібен Allow і з боку того, хто звертається (IAM-політика в акаунті A), і з боку ресурсу (resource-based policy або trust policy ролі в акаунті B). У реальній логіці AWS є ще нюанси (session policies тощо), але для іспиту достатньо цієї схеми.
Приклади політик
Читання одного bucket. Зверни увагу: s3:ListBucket дається на ARN самого bucket, а s3:GetObject — на об'єкти (/*):
Застосунок на EC2 має читати S3→IAM role (instance profile), а не access keys
Дати іншому акаунту доступ до своїх ресурсів→IAM role з trust policy + STS AssumeRole
Заборонити всім акаунтам в OU вимикати CloudTrail або працювати поза дозволеними регіонами→SCP
Розробники можуть створювати ролі, але не ширші за певні права→Permission boundary
Швидко налаштувати багато акаунтів «правильно», з guardrails і логуванням→AWS Control Tower
Єдиний вхід співробітників у багато акаунтів AWS через корпоративний AD або Okta→IAM Identity Center
Реєстрація і вхід користувачів мобільного або веб-застосунку, вхід через соцмережі→Cognito User Pool
Користувачі мобільного застосунку мають завантажувати фото напряму в S3→Cognito Identity Pool (тимчасові credentials)
Повноцінний AD в AWS з довірою (trust) до on-prem AD→AWS Managed Microsoft AD
Використати наявний on-prem AD без копіювання даних в AWS→AD Connector
Дозволити доступ до bucket лише акаунтам своєї організації→Bucket policy з умовою aws:PrincipalOrgID
Кілька акаунтів мають працювати в одній спільній VPC→VPC sharing через AWS RAM
Знайти ресурси, до яких мають доступ зовнішні акаунти→IAM Access Analyzer
Один рахунок і спільні знижки RI/Savings Plans на всі акаунти→Organizations: consolidated billing
Надавати доступ за тегами (відділ, проєкт) замість сотень політик→ABAC (теги + умови)
Стороння компанія (SaaS-вендор) отримує доступ до акаунта через роль, треба захист від confused deputy→Роль з умовою sts:ExternalId у trust policy
On-prem сервери мають отримувати тимчасові AWS-credentials без довгострокових ключів→IAM Roles Anywhere
Знайти й прибрати права, якими роль ніколи не користується→IAM Access Advisor (last accessed) / IAM Access Analyzer
Вимагати MFA для небезпечних дій (напр., видалення)→Умова aws:MultiFactorAuthPresent у політиці
⚠️ Пастки
SCP не дає дозволів, а лише обмежує. На management account SCP не діє.
s3:ListBucket — на ARN bucket, s3:GetObject / s3:PutObject — на bucket/*. Переплутаєш — буде AccessDenied.
Крос-акаунт через resource-based policy: потрібен Allow з обох боків (у політиці ресурсу і в IAM-політиці того, хто звертається).
Cognito User Pool = автентифікація (хто ти). Identity Pool = доступ до AWS (тимчасові ключі).
IAM Identity Center — для співробітників; Cognito — для клієнтів застосунку.
5Шифрування, ключі, секрети, сертифікати
At rest — шифрування KMS; in transit — TLS (HTTPS, сертифікати ACM).
AWS KMS — керовані ключі, регіональні.
AWS managed keys (aws/s3, aws/ebs) — ротація щороку автоматично, керувати політикою не можна.
Customer managed keys — сам керуєш key policy, grants і ротацією: автоматично раз на 90–2560 днів (за замовчуванням 365) або вручну on-demand.
Symmetric (AES-256) і asymmetric (RSA/ECC — підпис, шифрування поза AWS).
Key policy — головний контроль доступу до ключа. Cross-account: дозвіл у key policy + IAM-політика в іншому акаунті.
Envelope encryption: KMS Encrypt шифрує максимум 4 KB; великі дані шифрують data key (GenerateDataKey).
Multi-Region keys — той самий ключ у кількох регіонах: зашифрував в одному, розшифрував в іншому. Без них при копіюванні снапшота в інший регіон його перешифровують ключем того регіону.
ThrottlingException від KMS при масовій роботі з S3 (SSE-KMS) → S3 Bucket Keys (у рази менше викликів KMS і дешевше).
CloudHSM — виділений (single-tenant) апаратний HSM. Ключі повністю під твоїм контролем, AWS до них доступу не має. FIPS 140 Level 3. Стандартні API (PKCS#11, JCE, CNG), Oracle TDE, SSL offload. Можна підключити до KMS як custom key store.
ACM (AWS Certificate Manager): безкоштовні публічні TLS-сертифікати для ELB, CloudFront, API Gateway; автоматичне поновлення (для DNS-валідації). Для CloudFront сертифікат має бути в регіоні us-east-1. Імпортовані сертифікати ACM сам не поновлює — стеж за терміном (події в EventBridge, Config rule).
Secrets Manager — секрети + автоматична ротація (вбудована для RDS, Aurora, Redshift, DocumentDB; для решти — через Lambda), реплікація в інші регіони. Платно за кожен секрет.
SSM Parameter Store — конфігурація і секрети (SecureString з KMS), ієрархія, standard tier безкоштовний. Вбудованої ротації немає.
EBS: увімкни encryption by default для регіону. Незашифрований том → snapshot → copy snapshot з шифруванням → новий том.
RDS: шифрування вмикається тільки при створенні. Незашифрована БД → snapshot → copy з шифруванням → restore. Read replica шифрується так само, як основна БД.
S3:SSE-S3 (за замовчуванням для всіх нових об'єктів з 2023), SSE-KMS (аудит використання ключа в CloudTrail + окремий контроль доступу до ключа), DSSE-KMS (двошарове), SSE-C (ключ надає клієнт, тільки HTTPS), шифрування на клієнті.
Примусити HTTPS до S3: bucket policy з Deny, якщо aws:SecureTransport = false.
Видалення ключа KMS — лише із затримкою 7–30 днів (за замовчуванням 30). Поки строк не минув, видалення можна скасувати. Безпечніша альтернатива — вимкнути (disable) ключ.
Key policy обов'язкова: якщо вона не дозволяє акаунту делегувати доступ через IAM, IAM-політики до ключа не діють.
Зашифрований снапшот для іншого акаунта: поділитися можна лише снапшотом, зашифрованим customer managed key (ділишся снапшотом і даєш доступ до ключа). Снапшот з AWS managed key спершу копіюють, перешифрувавши своїм ключем.
CloudHSM для HA — кластер щонайменше з 2 HSM у різних AZ.
🎯 Тригери
Потрібен аудит, хто і коли використовував ключ шифрування даних у S3→SSE-KMS (виклики ключа видно в CloudTrail)
Ключі лише під твоїм контролем в апаратному модулі, FIPS 140 Level 3, AWS не має доступу→CloudHSM
Автоматично змінювати пароль до БД кожні 30 днів→Secrets Manager (rotation)
Дешево зберігати конфігурацію і рядки підключення без ротації→SSM Parameter Store
HTTPS на ALB або CloudFront без ручного поновлення сертифікатів→ACM
Шифрувати в одному регіоні й розшифровувати в іншому тим самим ключем→KMS Multi-Region keys
ThrottlingException від KMS при масовому завантаженні в S3 з SSE-KMS→S3 Bucket Keys
Зашифрувати наявну незашифровану RDS→Snapshot → copy з шифруванням → restore
Шифрувати через KMS файли більші за 4 KB→Envelope encryption (data key)
Заборонити HTTP-доступ і незашифровані завантаження в bucket→Bucket policy з Deny та умовами
Ключ має змінюватися частіше, ніж раз на рік→Customer managed key з власним періодом ротації
Поділитися зашифрованим снапшотом RDS/EBS з іншим акаунтом→Customer managed KMS key + доступ до ключа для того акаунта
Ключ KMS випадково запланували на видалення→Скасувати видалення, поки не минув період очікування (7–30 днів)
⚠️ Пастки
На існуючій RDS або EBS не можна просто «увімкнути шифрування» — тільки через копію снапшота.
Сертифікат ACM для CloudFront — тільки в us-east-1 (для ALB — у регіоні ALB).
Класично (і на іспиті) публічний сертифікат ACM ставиться лише на інтегровані сервіси (ELB, CloudFront, API Gateway), а не прямо на EC2.
6Сервіси безпеки: захист від атак і аудит
AWS WAF — файрвол рівня 7 (HTTP): SQL injection, XSS, блокування IP і країн (geo match), rate-based rules (ліміт запитів з одного IP), managed rule groups, Bot Control. Ставиться на CloudFront, ALB, API Gateway, AppSync, Cognito User Pool, App Runner. Не на NLB і не на EC2.
AWS Shield Standard — безкоштовно й автоматично для всіх: DDoS рівнів 3–4.
AWS Shield Advanced — платно (~$3 000/міс на організацію): команда SRT 24/7, захист від зростання рахунку через DDoS, розширена детекція, захист рівня 7 разом з WAF. Для CloudFront, Route 53, Global Accelerator, ELB, EC2 Elastic IP.
AWS Firewall Manager — централізовано керує правилами WAF, Shield Advanced, Security Groups, Network Firewall, DNS Firewall у всіх акаунтах Organizations. Нові акаунти і ресурси отримують правила автоматично.
AWS Network Firewall — керований файрвол на рівні VPC (stateful/stateless, IPS/IDS, фільтрація за доменами, правила Suricata). Часто — в окремій inspection VPC за Transit Gateway.
Route 53 Resolver DNS Firewall — блокує DNS-запити з VPC до шкідливих доменів.
Amazon GuardDuty — виявлення загроз за допомогою ML: аналізує CloudTrail, VPC Flow Logs, DNS-логи (+ S3, EKS, RDS, Lambda, runtime, сканування malware). Криптомайнінг, скомпрометовані ключі, зв'язок з C&C. Знахідки → EventBridge → автоматична реакція.
Amazon Inspector — сканування вразливостей (CVE) і мережевої доступності: EC2, образи в ECR, Lambda. Працює безперервно.
Amazon Macie — ML-пошук чутливих даних (PII, номери карток) у S3.
Amazon Detective — розслідування: граф подій і першопричина знахідок GuardDuty.
AWS Artifact — звіти відповідності AWS (SOC, PCI, ISO) і угоди (напр., BAA для HIPAA).
AWS Audit Manager — автоматичний збір доказів для аудиту.
CloudTrail vs Config vs CloudWatch: CloudTrail — хто і коли викликав API (аудит). Config — яка конфігурація ресурсу була і чи відповідає вона правилам (історія, compliance). CloudWatch — метрики, логи, аларми (продуктивність).
Багато акаунтів: GuardDuty, Security Hub, Macie та Inspector вмикають централізовано через delegated administrator в AWS Organizations — нові акаунти підключаються автоматично.
Хтось зробив bucket публічним — треба автоматично виправити→AWS Config rule + автовиправлення (SSM Automation) або EventBridge → Lambda
Увімкнути GuardDuty в усіх акаунтах організації, включно з новими→Delegated administrator в AWS Organizations
⚠️ Пастки
WAF не підтримує NLB. Для NLB: Shield Advanced від DDoS, фільтрація — Security Groups, NACL або Network Firewall.
GuardDuty = загрози, Inspector = вразливості, Macie = чутливі дані в S3. Їх часто плутають.
7VPC і мережа
VPC — приватна мережа в регіоні. IPv4 CIDR від /16 до /28. У кожній підмережі AWS резервує 5 IP-адрес (перші 4 і останню).
Subnet живе в одній AZ.
Public subnet — у route table є маршрут 0.0.0.0/0 → Internet Gateway (IGW).
Private subnet — маршруту на IGW немає; вихід в інтернет через NAT Gateway.
NAT Gateway — керований, платно за годину + за кожен ГБ. Класичний (zonal) стоїть у public subnet; для HA — по одному в кожній AZ (інакше збій однієї AZ відріже інтернет усім, а трафік між AZ ще й коштує грошей).
🆕 Regional NAT Gateway (з листопада 2025) — один на VPC, сам розширюється на потрібні AZ, public subnet не потрібен. Іспит частіше питає класичну схему «NAT на кожну AZ».
NAT instance — старий самокерований варіант (EC2, вимкнути Source/Destination check). Дешевший, але без HA і масштабування.
Egress-only Internet Gateway — для IPv6: вихід в інтернет без вхідних з'єднань (аналог NAT для IPv6).
Security Group (SG) — на рівні інстансу (ENI), stateful (відповідь дозволяється автоматично), тільки Allow. Можна посилатися на іншу SG як на джерело.
Network ACL (NACL) — на рівні підмережі, stateless (треба окремо дозволити відповідь на ephemeral ports 1024–65535), є Allow і Deny, правила перевіряються за номером (від меншого, спрацьовує перше збігле).
Route table — перемагає найспецифічніший маршрут (longest prefix match).
Схема типової VPC
Region · VPC 10.0.0.0/16 🌐 Internet Gateway🪣 Gateway endpoint → S3
AZ a
Public subnet 10.0.1.0/24
ALB (вузол)NAT Gateway
0.0.0.0/0 → IGW
Private subnet — застосунок 10.0.11.0/24
EC2 (Auto Scaling)
0.0.0.0/0 → NAT Gateway (AZ a)
Private subnet — БД 10.0.21.0/24
RDS primary
маршруту в інтернет немає
AZ b
Public subnet 10.0.2.0/24
ALB (вузол)NAT Gateway
0.0.0.0/0 → IGW
Private subnet — застосунок 10.0.12.0/24
EC2 (Auto Scaling)
0.0.0.0/0 → NAT Gateway (AZ b)
Private subnet — БД 10.0.22.0/24
RDS standby (Multi-AZ)
синхронна копія, читати з неї не можна
Інтернет → IGW → ALB (публічні підмережі) → EC2 (приватні). EC2 виходять в інтернет через NAT Gateway своєї AZ. До S3 — через безкоштовний gateway endpoint. SG бази пускає лише SG серверів застосунку (порт 3306 або 5432).
Доступ до сервісів і з'єднання
VPC Endpoints — доступ до сервісів AWS без інтернету і без NAT:
Gateway endpoint — тільки S3 і DynamoDB, безкоштовний, додається запис у route table.
Interface endpoint (PrivateLink) — ENI з приватним IP у підмережі. Майже всі сервіси (SQS, SNS, KMS, Secrets Manager, ECR, CloudWatch, S3…). Платно. Доступний з on-prem через VPN/Direct Connect.
Endpoint policy — обмежує, що можна робити через endpoint (напр., лише певні bucket).
AWS PrivateLink — надати свій сервіс іншим VPC/акаунтам приватно: провайдер ставить NLB → endpoint service, споживач створює interface endpoint. Односторонній доступ, CIDR можуть перетинатися, масштабується на тисячі споживачів.
VPC Peering — пряме з'єднання двох VPC (між акаунтами й регіонами). Нетранзитивне (A–B і B–C не дають A–C). CIDR не можуть перетинатися. Потрібно оновити route tables з обох боків.
Transit Gateway (TGW) — хаб для сотень VPC, VPN і Direct Connect. Транзитивна маршрутизація, окремі route tables для сегментації, peering між регіонами, шариться через RAM, ECMP для VPN (сумує пропускну здатність тунелів), multicast.
Site-to-Site VPN — IPsec-тунелі через інтернет: Virtual Private Gateway (VGW) або TGW на боці AWS + Customer Gateway на боці офісу. 2 тунелі для резерву. До 1,25 Gbps на тунель (🆕 з листопада 2025 — тунелі до 5 Gbps на TGW). Налаштовується за хвилини.
VPN CloudHub — кілька офісів спілкуються між собою через VGW.
Accelerated VPN — через мережу Global Accelerator (лише з TGW).
Direct Connect (DX) — виділений приватний канал до AWS. Dedicated: 1/10/100/400 Gbps. Hosted (через партнера): від 50 Mbps до 25 Gbps. Стабільна затримка, дешевший вихідний трафік. Прокладання — тижні або місяці.
Не шифрується сам по собі → IPsec VPN поверх DX або MACsec.
Direct Connect Gateway — один DX до багатьох VPC у різних регіонах.
Резервування: 2 DX у різних DX-локаціях (максимальна стійкість) або DX + Site-to-Site VPN як дешевий бекап.
VIF: private (до VPC), public (до публічних сервісів AWS), transit (до TGW).
AWS Client VPN — доступ окремих співробітників (ноутбуків) до VPC (OpenVPN).
Схема гібридного з'єднання
🏢 On-premisesДата-центр або офіс: Customer Gateway (роутер), AD, DNS
⇄
🔌 КаналSite-to-Site VPN IPsec через інтернет, за хвилини, 1,25 Gbps на тунель Direct Connect приватний канал, тижні, 1–400 Gbps; шифрування — VPN поверх DX або MACsec
⇄
🔀 Transit GatewayХаб з транзитивною маршрутизацією. DX підключають через Direct Connect Gateway
⇄
☁️ VPC A · VPC B · VPC CІнші регіони — через TGW peering. DNS між офісом і VPC — Route 53 Resolver inbound/outbound endpoints
Дешево і швидко → VPN. Стабільно і великі обсяги → Direct Connect (+ VPN як резерв). Багато VPC → Transit Gateway замість десятків peering-з'єднань.
Решта мережевих можливостей
VPC Flow Logs — метадані IP-трафіку (хто, куди, порт, ACCEPT/REJECT) → CloudWatch Logs, S3 або Firehose. Вміст пакетів не пишуть (для цього — Traffic Mirroring).
Доступ до приватних EC2 без SSH:SSM Session Manager (жодних відкритих портів, логування сесій) або EC2 Instance Connect Endpoint. Класичний варіант — bastion host у public subnet.
Інстанси в private subnet мають завантажувати оновлення з інтернету→NAT Gateway у public subnet (для HA — по одному на AZ)
Приватний EC2 звертається до S3 або DynamoDB без інтернету і безкоштовно→Gateway VPC endpoint
Приватний EC2 звертається до SQS, KMS, Secrets Manager без інтернету→Interface VPC endpoint (PrivateLink)
Великі рахунки за NAT Gateway через трафік до S3→Gateway endpoint для S3
Заблокувати конкретну IP-адресу→Network ACL з Deny (у Security Group Deny немає)
БД має приймати трафік лише від вебсерверів→SG бази з джерелом = SG вебсерверів
Надати свій сервіс сотням клієнтських VPC приватно, CIDR перетинаються→PrivateLink (NLB + endpoint service)
З'єднати 2–3 VPC просто і дешево→VPC Peering
З'єднати десятки або сотні VPC і on-prem з транзитивною маршрутизацією→Transit Gateway
Швидко і дешево створити зашифрований канал до офісу→Site-to-Site VPN
Стабільна пропускна здатність, приватне з'єднання, великі обсяги даних→Direct Connect
Direct Connect + вимога шифрування→IPsec VPN поверх DX (або MACsec)
Недорогий резерв для Direct Connect→Site-to-Site VPN як backup
Максимальна стійкість гібридного з'єднання→Кілька DX у різних DX-локаціях
Один Direct Connect до VPC у кількох регіонах→Direct Connect Gateway
Віддалені співробітники підключаються до VPC→AWS Client VPN
Кілька філій мають спілкуватися між собою через AWS→VPN CloudHub
IPv6-інстанси виходять в інтернет, але недоступні ззовні→Egress-only Internet Gateway
Адмін-доступ до EC2 без відкритого порту 22 і з логуванням сесій→SSM Session Manager
On-prem сервери мають резолвити приватні DNS-імена в AWS→Route 53 Resolver inbound endpoint
VPC має резолвити внутрішні домени офісу→Route 53 Resolver outbound endpoint + forwarding rule
Проаналізувати відхилений трафік, хто стукає в інстанс→VPC Flow Logs
Дозволити через endpoint доступ лише до кількох «своїх» bucket→VPC endpoint policy
⚠️ Пастки
Gateway endpoint — тільки S3 і DynamoDB. Для решти сервісів — Interface endpoint.
Gateway endpoint не працює для трафіку з on-prem (через VPN/DX) — для цього Interface endpoint.
VPC Peering нетранзитивний і неможливий при перетині CIDR.
У NAT Gateway немає Security Groups. Один NAT Gateway в одній AZ — єдина точка відмови.
8DNS і доставка контенту: Route 53, CloudFront, Global Accelerator
Route 53
Керований DNS + реєстрація доменів + health checks. SLA 100%.
Alias record — вказує на ресурси AWS (ELB, CloudFront, S3 website, API Gateway, інший запис). Працює на zone apex (example.com). Запити до ресурсів AWS безкоштовні. CNAME на apex не можна.
Routing policies:
Simple — один ресурс, без health checks.
Weighted — розподіл у відсотках (A/B-тести, поступова міграція, blue/green).
Latency-based — до регіону з найменшою затримкою для користувача.
Failover — active-passive: primary + secondary, перемикання за health check.
Geolocation — за країною/континентом користувача (мова, ліцензії, закони). Потрібен default-запис.
Geoproximity — за відстанню, з bias (змістити більше трафіку до певного регіону).
Multivalue answer — до 8 здорових записів (простий балансинг на клієнті, не заміна ELB).
IP-based — за CIDR клієнта (напр., за провайдером).
Health checks перевіряють endpoint, інші health checks (calculated) або CloudWatch alarm. Приватні ресурси — лише через CloudWatch alarm, бо перевіряльники Route 53 працюють з інтернету.
Private hosted zone — DNS тільки всередині VPC (потрібні enableDnsHostnames і enableDnsSupport).
S3 static website через alias — ім'я bucket має збігатися з доменом (bucket example.com для запису example.com).
CloudFront
CDN: кешує контент на сотнях edge-локацій → менша затримка, менше навантаження на origin, дешевший трафік в інтернет.
Origins: S3, ALB, EC2, API Gateway, будь-який HTTP-сервер (зокрема on-prem). VPC origins (з 2024) — приватні ALB/NLB/EC2 без публічного доступу.
Origin Access Control (OAC) — bucket S3 доступний лише через CloudFront. OAC — сучасна заміна OAI (підтримує SSE-KMS).
Signed URL — доступ до одного файлу. Signed cookies — до багатьох файлів (весь преміум-розділ) без зміни URL.
S3 presigned URL — інша річ: тимчасовий доступ напряму до об'єкта S3 з правами того, хто підписав.
Geo restriction — дозволити або заборонити країни.
Origin failover — origin group (primary + secondary) при помилках 5xx/4xx.
Field-level encryption — шифрує окремі поля форми (напр., номер картки) вже на edge.
Cache behaviors — різні правила кешу та origins за шаблоном шляху: /static/* → S3 з довгим кешем, /api/* → ALB без кешу.
Кешування: TTL, cache policies, invalidation (краще версіонувати імена файлів).
HTTPS: сертифікат ACM у us-east-1. Інтеграція з WAF і Shield.
Price classes — обмежити набір edge-локацій, щоб платити менше.
Global Accelerator
2 статичні anycast IP-адреси. Трафік заходить у найближчу edge-точку і далі йде мережею AWS до endpoint (ALB, NLB, EC2, Elastic IP) в одному або кількох регіонах.
Швидкий failover між регіонами (не залежить від DNS-кешу), health checks, traffic dials і ваги.
TCP і UDP, нічого не кешує. Для ігор, IoT, VoIP або HTTP, коли потрібні статичні IP і швидке перемикання регіонів.
🎯 Тригери
Направити домен example.com (apex) на ALB→Route 53 Alias record
Поступово перевести 10% трафіку на нову версію→Weighted routing
Користувачі мають потрапляти до найшвидшого для них регіону→Latency-based routing
Active-passive DR між регіонами через DNS→Failover routing + health checks
Користувачі з Німеччини бачать німецьку версію / обмеження контенту за країною→Geolocation routing
Змістити більше трафіку до одного регіону→Geoproximity routing (bias)
Прискорити статичний і динамічний контент для глобальних користувачів→CloudFront
Заборонити прямий доступ до S3, лише через CloudFront→OAC (Origin Access Control)
Платний доступ підписників до багатьох відео→CloudFront signed cookies
Тимчасове посилання на один приватний файл→CloudFront signed URL (або S3 presigned URL)
Заблокувати доступ до контенту з певних країн→CloudFront geo restriction (або WAF geo match)
Статичні IP для глобального застосунку, UDP/ігри, швидкий failover регіонів→Global Accelerator
Легкі зміни заголовків і редиректи на edge→CloudFront Functions
Health check для приватного ресурсу→CloudWatch alarm + Route 53 health check
Автоматично показати сторінку-заглушку з S3, якщо основний сайт впав→Route 53 failover на S3 static website (або CloudFront origin failover)
Статика й API на одному домені через CloudFront, з різним кешуванням→Cache behaviors за шляхом (/static/* → S3, /api/* → ALB)
⚠️ Пастки
CloudFront — кеш HTTP(S)-контенту. Global Accelerator — без кешу, TCP/UDP, статичні IP.
Route 53 failover залежить від TTL (клієнти кешують DNS). Global Accelerator перемикає швидше.
9Балансувальники (ELB) і Auto Scaling
Elastic Load Balancing
ALB (рівень 7: HTTP/HTTPS/gRPC/WebSocket). Маршрутизація за path (/api), host (api.example.com), заголовками, query string, методом, IP джерела. Targets: EC2, IP, Lambda, ECS (dynamic port mapping). Кілька сертифікатів через SNI. Автентифікація через Cognito/OIDC. Sticky sessions. Редирект HTTP→HTTPS. Статичного IP немає.
NLB (рівень 4: TCP/UDP/TLS). Мільйони запитів/с, наднизька затримка, статичний IP на кожну AZ (можна Elastic IP), зберігає IP клієнта, основа для PrivateLink. Підтримує Security Groups.
GWLB (рівень 3, протокол GENEVE, порт 6081). Прозоро пропускає трафік через віртуальні апарати сторонніх вендорів (файрволи, IDS/IPS, DPI) і масштабує їх.
CLB — застарілий, для нових рішень не обирають.
Cross-zone load balancing: ALB — увімкнено за замовчуванням, безкоштовно. NLB/GWLB — вимкнено за замовчуванням, трафік між AZ платний.
Deregistration delay (connection draining) — дочекатися завершення запитів перед виведенням цілі (за замовчуванням 300 с).
TLS можна завершувати на ELB (сертифікат ACM). Для end-to-end шифрування — HTTPS і до targets.
Auto Scaling
ASG: min / desired / max, Launch Template (Launch Configuration застаріла), кілька AZ, автоматична заміна нездорових інстансів.
Health check за замовчуванням — статус EC2. Увімкни ELB health check, щоб ASG замінював інстанси, які «живі», але застосунок на них не відповідає.
Health check grace period — час після запуску, коли ASG ще не перевіряє здоров'я (застосунку треба встигнути стартувати).
ELB access logs → S3: хто, коли, який запит і з яким кодом відповіді.
Політики масштабування:
Target tracking — тримати метрику на рівні (CPU 50%, запити на ціль ALB). Найпростіша і рекомендована.
Step scaling — різні кроки залежно від величини порушення аларму.
Simple scaling — одна дія + cooldown (застаріла).
Scheduled — за розкладом (відомий пік щопонеділка о 9:00).
Predictive — ML прогнозує циклічне навантаження і масштабує заздалегідь.
Воркери з черги SQS: масштабуй за backlog per instance (ApproximateNumberOfMessagesVisible / кількість інстансів) через target tracking.
Cooldown / instance warmup — пауза, поки новий інстанс не прогріється (default cooldown 300 с).
Lifecycle hooks — дія під час запуску або видалення інстансу (встановити ПЗ, забрати логи перед термінацією).
Warm pools — заздалегідь підготовлені інстанси для швидкого масштабування застосунків з довгим стартом.
Instance refresh — поступово замінити всі інстанси на новий AMI / launch template.
Default termination policy (спрощено): спершу AZ з найбільшою кількістю інстансів → інстанс з найстарішим launch template/configuration → найближчий до наступної години білінгу.
Mixed instances policy — база On-Demand + Spot, кілька типів інстансів.
AWS Auto Scaling (окремий сервіс) — масштабування кількох ресурсів разом: ASG, ECS, DynamoDB, репліки Aurora.
🎯 Тригери
Маршрутизувати /api і /images на різні групи серверів→ALB path-based routing
Кілька доменів з різними сертифікатами на одному балансувальнику→ALB + SNI
Статичний IP балансувальника (клієнт додає IP у whitelist)→NLB з Elastic IP (або Global Accelerator)
Тримати середній CPU близько 50%→Target tracking scaling
Масштабувати воркерів за довжиною черги SQS→Target tracking за backlog per instance
Застосунок довго стартує, масштабування запізнюється→Warm pools (або AMI з уже встановленим ПЗ)
Забрати логи з інстансу перед його видаленням при scale-in→Lifecycle hook
Користувач втрачає сесію, коли запит іде на інший сервер→Sticky sessions (краще — сесії в ElastiCache або DynamoDB)
Оновити всі інстанси ASG на новий AMI без простою→Instance refresh
Нові інстанси ASG одразу вважаються «нездоровими», бо застосунок довго стартує→Збільшити health check grace period
⚠️ Пастки
Для stateless-архітектури сесії зберігають в ElastiCache або DynamoDB, а не на самому інстансі.
ALB не дає статичного IP. Потрібен статичний IP — NLB або Global Accelerator.
10EC2: інстанси, тарифи, розміщення
Типи інстансів
T / M — загального призначення (T — burstable, накопичує CPU-кредити).
C — compute optimized: пакетна обробка, кодування відео, HPC, ігрові сервери, ML-інференс на CPU.
R / X / z — memory optimized: in-memory БД і кеші, SAP HANA, аналітика в пам'яті.
I / D / H — storage optimized: дуже високі IOPS на локальних NVMe (OLTP, NoSQL, data warehouse).
P / G / Inf / Trn — прискорювачі (GPU, ML).
Graviton (літера g у назві, напр. m7g) — процесори ARM, помітно краща ціна/продуктивність.
Як читати назву:m7g.2xlarge → сімейство m, покоління 7, g = Graviton, розмір 2xlarge. Інші літери: a — AMD, i — Intel, d — локальні NVMe-диски, n — посилена мережа.
Сховище і стан
Instance store — локальні диски хоста: найвищі IOPS, але дані зникають при stop, terminate або збої хоста. Для кешу, буферів і тимчасових даних.
EBS root — зберігається при stop.
Hibernate — зберігає RAM на EBS root (том має бути зашифрований) → швидкий старт з «теплим» станом застосунку.
AMI — регіональний образ. Для іншого регіону — copy AMI. «Golden AMI» з готовим ПЗ = швидкий старт при масштабуванні.
User data — скрипт при першому запуску. Instance metadata — використовуй IMDSv2 (токени).
Status checks:system (проблема хоста AWS → stop/start переносить інстанс на інший хост або CloudWatch alarm з дією recover) vs instance (проблема в ОС → reboot, виправлення).
Мережа і розміщення
Placement groups:
Cluster — одна AZ, інстанси поруч: найменша затримка і найвища пропускна між ними (HPC). Ризик: все поруч.
Spread — кожен інстанс на окремому обладнанні; максимум 7 інстансів на AZ у групі. Для кількох критичних інстансів.
Partition — групи стійок (до 7 partitions на AZ), сотні інстансів. Hadoop, Cassandra, Kafka.
EFA (Elastic Fabric Adapter) — для HPC/MPI, обхід ОС, наднизька затримка між вузлами. ENA — розширена мережа (до 100+ Gbps).
Elastic IP — статична публічна IPv4 (з 2024 всі публічні IPv4 платні).
ENI — мережевий інтерфейс; його можна перечепити на інший інстанс (failover з тим самим приватним IP).
Тарифи (purchasing options)
On-Demand — посекундна/погодинна оплата без зобов'язань. Короткі й непередбачувані навантаження.
Reserved Instances (RI) — 1 або 3 роки, до ~72% знижки. Standard RI — більша знижка, сімейство змінювати не можна (можна продати на RI Marketplace). Convertible RI — можна міняти сімейство/ОС, знижка менша.
Savings Plans — зобов'язання витрачати $/год протягом 1 або 3 років:
Compute Savings Plan — до ~66%, будь-яке сімейство, регіон, ОС + Fargate і Lambda.
EC2 Instance Savings Plan — до ~72%, конкретне сімейство в конкретному регіоні.
🆕 Database Savings Plans (з грудня 2025) — до 35% на RDS, Aurora, DynamoDB, ElastiCache тощо (1 рік).
Spot — до 90% знижки, але AWS може забрати інстанс з попередженням за 2 хвилини. Лише для переривних задач: batch, CI/CD, рендеринг, аналітика, stateless-вебсервери за ASG. Spot Fleet / EC2 Fleet, стратегія price-capacity-optimized.
Dedicated Hosts — окремий фізичний сервер: видно сокети і ядра → BYOL-ліцензії (Windows Server, SQL Server, Oracle), вимоги комплаєнсу.
Dedicated Instances — обладнання не ділиться з іншими клієнтами, але без контролю над хостом.
On-Demand Capacity Reservations — гарантують ємність у конкретній AZ на будь-який термін, без знижки (знижку дають RI/Savings Plans поверх).
🎯 Тригери
Пакетні задачі, які можна переривати, мінімальна ціна→Spot Instances
Стабільне навантаження 24/7 на 1–3 роки→Reserved Instances або Savings Plans
Знижка + свобода міняти сімейство, регіон або перейти на Fargate/Lambda→Compute Savings Plan
Ліцензії прив'язані до фізичних ядер/сокетів (BYOL)→Dedicated Hosts
Гарантувати ємність в AZ на важливу подію без довгого зобов'язання→On-Demand Capacity Reservation
HPC, мінімальна затримка між вузлами→Cluster placement group + EFA
Кілька критичних інстансів не повинні відмовити разом→Spread placement group
Hadoop/Cassandra/Kafka на сотнях інстансів з ізоляцією стійок→Partition placement group
Найвищі IOPS для тимчасових даних або кешу→Instance store
Швидко відновити застосунок з «теплою» пам'яттю після зупинки→EC2 Hibernate
Інстанс не проходить system status check→Stop/Start або CloudWatch alarm → recover
In-memory застосунок, потрібно багато RAM→R-сімейство (memory optimized)
Кодування відео, наукові розрахунки→C-сімейство (compute optimized)
Швидкий запуск нових інстансів з готовим ПЗ→Golden AMI
Запустити той самий сервер в іншому регіоні→Copy AMI в інший регіон
⚠️ Пастки
Spot не підходить для основної БД і критичних довгих задач без чекпоінтів.
Instance store не переживає stop. EBS переживає.
Вертикальне масштабування (більший тип інстансу) потребує зупинки; горизонтальне — додає інстанси через ASG.
11Serverless і контейнери
AWS Lambda
До 15 хвилин на один виклик. Пам'ять 128 MB–10 240 MB (CPU росте пропорційно пам'яті). /tmp — від 512 MB до 10 GB.
Payload: 6 MB синхронно (streamed response — до 200 MB), 1 MB асинхронно. Пакет коду: 50 MB zip / 250 MB розпакований; container image — до 10 GB; до 5 layers.
Concurrency: за замовчуванням 1 000 одночасних виконань на регіон (можна підняти).
Reserved concurrency — гарантує функції частку і водночас обмежує її (захист БД від перевантаження).
Provisioned concurrency — заздалегідь прогріті середовища → немає cold start.
Версії й aliases: alias може ділити трафік між двома версіями (напр., 90/10) для поступового релізу.
Lambda + SQS: visibility timeout черги ставлять щонайменше в 6 разів більшим за timeout функції; невдалі повідомлення — у DLQ.
Довше 15 хвилин → розбити через Step Functions, або ECS/Fargate, або AWS Batch.
Amazon API Gateway
REST API — повний функціонал: кешування, API keys + usage plans, WAF, валідація запитів. HTTP API — дешевше і простіше (JWT-авторизація). WebSocket API — двосторонній зв'язок (чати, реальний час).
Типи endpoint: Edge-optimized (через CloudFront), Regional, Private (лише з VPC через interface endpoint).
Throttling: за замовчуванням 10 000 запитів/с на акаунт у регіоні (burst 5 000); usage plans — окремі ліміти для клієнтів; при перевищенні — помилка 429.
Таймаут інтеграції за замовчуванням 29 с (для Regional і Private REST API можна збільшити). Payload до 10 MB.
Stages (dev, prod) і canary deployment — частина трафіку йде на нову версію API.
Контейнери та інша обчислювальна платформа
Amazon ECS — оркестрація контейнерів від AWS (простіше за Kubernetes).
Launch type EC2 — сам керуєш інстансами (дешевше при стабільному навантаженні, GPU, особливі вимоги).
Launch type Fargate — serverless, без серверів.
Task definition, service, task IAM role (права саме для контейнера), ALB з dynamic port mapping.
Amazon EKS — керований Kubernetes: коли вже використовують K8s, потрібна портативність або open-source інструменти. Managed node groups, Fargate profiles, EKS Auto Mode.
ECS Anywhere / EKS Anywhere / EKS Distro — запуск на власних серверах on-prem.
AWS Fargate — serverless для контейнерів (ECS і EKS): платиш за vCPU і пам'ять задачі, EC2 не керуєш.
Elastic Beanstalk — PaaS: завантажуєш код (Java, .NET, Node.js, Python, PHP, Go, Docker), Beanstalk сам створює EC2, ASG, ELB і моніторинг. Політики розгортання: all at once, rolling, rolling with additional batch, immutable, traffic splitting, blue/green (swap URL).
AWS Batch — пакетні задачі будь-якої тривалості на EC2, Spot або Fargate; черги й планувальник задач.
Serverless Application Repository — готові serverless-застосунки для швидкого розгортання.
🎯 Тригери
Задача виконується 40 хвилин→Не Lambda: AWS Batch, ECS/Fargate або розбити через Step Functions
Cold start критичний для API на Lambda→Provisioned concurrency (для Java — SnapStart)
Lambda вичерпує з'єднання до RDS→RDS Proxy
Обмежити кількість одночасних виконань функції→Reserved concurrency
Обробити зображення одразу після завантаження в S3→S3 event → Lambda
Різні ліміти запитів для різних клієнтів API, API keys→API Gateway usage plans + throttling
Двосторонній чат у реальному часі→API Gateway WebSocket API
Власна перевірка токенів доступу до API→Lambda authorizer
Контейнери без керування серверами→Fargate (ECS або EKS)
Компанія вже використовує Kubernetes→Amazon EKS (on-prem — EKS Anywhere)
Розробники хочуть просто задеплоїти веб-застосунок без роботи з інфраструктурою→Elastic Beanstalk
Нова версія з мінімальним ризиком і швидким відкатом→Blue/green (Beanstalk swap URL або Route 53 weighted)
Тисячі пакетних задач з чергами і Spot→AWS Batch
Контейнеру потрібен доступ до S3→ECS task IAM role
Перенести застосунок у контейнери без переписування коду→Образ у ECR + ECS/EKS на Fargate
Функція має реагувати на нові записи в DynamoDB→DynamoDB Streams → Lambda
Поступово випустити нову версію Lambda на 10% трафіку→Lambda alias з вагами (weighted alias)
Lambda читає SQS, і повідомлення обробляються повторно→Visibility timeout черги ≥ 6 × timeout функції
⚠️ Пастки
Lambda — максимум 15 хвилин. Усе довше — не Lambda.
Beanstalk не «serverless»: він створює EC2, просто керує ними за тебе.
Лише зміна пам'яті Lambda збільшує і CPU (окремо CPU не налаштовується).
12Інтеграція і повідомлення: SQS, SNS, EventBridge, Step Functions, MQ
Amazon SQS
Керована черга, pull-модель: споживачі самі забирають повідомлення. Розв'язує компоненти (decoupling) і згладжує піки (buffer).
Standard: майже необмежена пропускна здатність, at-least-once (можливі дублікати), порядок не гарантується.
FIFO: суворий порядок у межах MessageGroupId, exactly-once processing (дедуплікація за 5 хв), 300 викликів/с (3 000 повідомлень/с з батчами по 10), high-throughput режим — у рази більше. Назва черги закінчується на .fifo.
Повідомлення до 1 MiB (з серпня 2025; раніше 256 KB). Більші — Extended Client Library (до 2 GB через S3).
Зберігання: від 1 хв до 14 днів (за замовчуванням 4 дні).
Visibility timeout — поки один споживач обробляє повідомлення, інші його не бачать (30 с за замовчуванням, максимум 12 год). Обробка довша за timeout → повідомлення оброблять двічі → збільш visibility timeout.
Long polling (WaitTimeSeconds до 20 с) — менше порожніх відповідей, дешевше.
Delay queue — затримати доставку до 15 хв.
Dead-letter queue (DLQ) — «отруйні» повідомлення після N невдалих спроб (maxReceiveCount) для аналізу.
Споживач сам видаляє повідомлення (DeleteMessage) після успішної обробки.
Amazon SNS
Pub/sub, push: одне повідомлення → багато підписників (SQS, Lambda, HTTP/S, email, SMS, мобільні push, Firehose).
Fan-out: SNS topic → кілька SQS-черг, кожна система обробляє незалежно.
Message filtering — підписник отримує лише потрібні повідомлення (filter policy).
SNS FIFO topic → SQS FIFO (порядок + без дублікатів).
Повідомлення до 256 KB (🆕 з вересня 2026 можна до 1 MiB через налаштування MaximumMessageSize).
Щоб SNS або S3 могли писати в SQS, потрібна queue policy (resource-based), що дозволяє їм sqs:SendMessage.
Схема: подієва архітектура
📤 ПодіяНовий файл у S3, замовлення з API, подія EventBridge
→
📣 SNS topicFan-out: копія повідомлення кожному підписнику (з фільтрами)
→
📥 Окрема SQS-черга на кожну задачуSQS «мініатюри» → LambdaSQS «метадані» → LambdaSQS «антивірус» → EC2 в ASGПомилки після N спроб → DLQ
→
💾 РезультатDynamoDB, S3 або інший сервіс
Кожен обробник працює у своєму темпі й не заважає іншим. Якщо обробник впав, повідомлення чекають у черзі (до 14 днів), а не губляться. ASG масштабує воркерів за довжиною черги.
Amazon EventBridge
Шина подій: події від сервісів AWS, власних застосунків і SaaS-партнерів (Zendesk, Datadog, Shopify…) → правила з event pattern → цілі (Lambda, SQS, Step Functions тощо). Колишні CloudWatch Events.
EventBridge Scheduler / cron — serverless-запуск задач за розкладом.
Standard — до 1 року, exactly-once, повна історія виконання (довгі бізнес-процеси).
Express — до 5 хвилин, великі обсяги подій, at-least-once, дешевше.
Прямі інтеграції з сотнями сервісів без Lambda-«клею». Distributed Map — масова паралельна обробка об'єктів S3.
Amazon MQ і AppFlow
Amazon MQ — керований ActiveMQ або RabbitMQ. Для міграції наявних застосунків, що використовують стандартні протоколи (JMS, AMQP, MQTT, STOMP, OpenWire), без переписування коду. Нові застосунки — SQS/SNS.
Amazon AppFlow — перенесення даних між SaaS (Salesforce, SAP, ServiceNow, Zendesk, Slack) і S3/Redshift без коду, за розкладом або подією.
Що обрати
Потреба
Сервіс
Черга між компонентами, воркери самі забирають задачі
SQS
Одне повідомлення → багато одержувачів (push)
SNS (fan-out → SQS)
Маршрутизація подій за вмістом, SaaS-події, розклад
EventBridge
Суворий порядок і без дублікатів
SQS FIFO / SNS FIFO
Потік даних у реальному часі, кілька споживачів, replay
Kinesis Data Streams
Багатокроковий процес з помилками, повторами, схваленням
Step Functions
Міграція з on-prem брокера (JMS/AMQP/MQTT)
Amazon MQ
🎯 Тригери
Розв'язати компоненти, замовлення не повинні губитися при піках→SQS
Обробка суворо по порядку і без дублікатів (фінансові транзакції)→SQS FIFO
Одне повідомлення мають обробити кілька незалежних систем→SNS fan-out → кілька SQS
Повідомлення обробляються двічі→Збільшити visibility timeout
Повідомлення, які постійно падають з помилкою→Dead-letter queue
Зменшити кількість порожніх ReceiveMessage і витрати→Long polling
Повідомлення більші за 1 MiB→SQS Extended Client Library + S3
Реагувати на подію від SaaS-партнера або маршрутизувати події за правилами→EventBridge
Запускати Lambda щоночі о 2:00→EventBridge Scheduler (cron)
Багатокроковий процес з повторами і ручним схваленням→Step Functions (Standard)
Мільйони коротких подій на секунду в workflow→Step Functions Express
Мігрувати застосунок на RabbitMQ/ActiveMQ без переписування→Amazon MQ
Регулярно вивантажувати дані з Salesforce у S3 без коду→Amazon AppFlow
Різні підписники мають отримувати лише свої типи повідомлень→SNS message filtering
⚠️ Пастки
SQS не видаляє повідомлення після читання автоматично — споживач викликає DeleteMessage.
SNS не зберігає повідомлення. Для надійної обробки став SQS за SNS.
SQS Standard може доставити повідомлення двічі і не за порядком.
13Amazon S3 і Glacier
Основне
Об'єктне сховище, durability 11 дев'яток (99,999999999%). Bucket — регіональний, але ім'я глобально унікальне.
Об'єкт до 50 TB (🆕 з грудня 2025; раніше 5 TB — на іспиті може трапитися стара цифра).
Один PUT — до 5 GB. Multipart upload рекомендований від 100 MB і обов'язковий понад 5 GB: частини вантажаться паралельно, збійні частини — повторно.
Strong read-after-write consistency для всіх операцій.
Продуктивність: 3 500 PUT/COPY/POST/DELETE і 5 500 GET/HEAD запитів/с на кожен префікс → більше префіксів = більше швидкість.
Transfer Acceleration — швидке завантаження з далеких країн через edge-локації. Byte-range fetches — паралельне читання частин файлу.
Класи зберігання
Клас
Для чого
Мін. термін оплати
Доступ
Standard
Часті звернення
—
мс
Intelligent-Tiering
Невідомий або змінний патерн доступу
—
мс (архівні рівні — години); плата за моніторинг, без плати за отримання
Express One Zone
Найшвидший, 1 AZ, одноцифрові мс, directory buckets
1 година
мс
Standard-IA
Рідко, але потрібні миттєво
30 днів
мс, плата за ГБ отримання
One Zone-IA
Рідко, дані можна відтворити, 1 AZ
30 днів
мс, плата за ГБ отримання
Glacier Instant Retrieval
Архів, доступ ~раз на квартал, але миттєво
90 днів
мс
Glacier Flexible Retrieval
Архів і бекапи
90 днів
Expedited 1–5 хв, Standard 3–5 год, Bulk 5–12 год (безкоштовно)
Glacier Deep Archive
Найдешевше, зберігання 7–10+ років
180 днів
Standard до 12 год, Bulk до 48 год
Мінімальний розмір об'єкта для оплати в Standard-IA, One Zone-IA і Glacier Instant Retrieval — 128 KB.
Intelligent-Tiering сам переносить об'єкти: 30 днів без доступу → Infrequent, 90 днів → Archive Instant; опційно — Archive Access і Deep Archive Access.
Provisioned capacity для Glacier Flexible Retrieval гарантує, що Expedited-відновлення (1–5 хв) спрацює навіть у пікові періоди.
S3 Standard0–30 днів: часті звернення
→
Standard-IAпісля 30 днів: рідко, але миттєво
→
Glacier Instant / Flexibleпісля 90 днів: архів (мс або хвилини–години)
→
Glacier Deep Archiveпісля 180 днів: найдешевше, відновлення до 12–48 год
→
🗑️ Expirationвидалення через N років
Строки — лише приклад. У Standard-IA можна перевести не раніше ніж через 30 днів; кожен клас має мінімальний строк оплати (30 / 90 / 180 днів). Невідомий патерн доступу — просто Intelligent-Tiering.
Керування даними
Lifecycle rules — автоматичні переходи між класами (transition) і видалення (expiration), зокрема для старих версій і незавершених multipart-завантажень. У Standard-IA/One Zone-IA можна перевести не раніше ніж через 30 днів після створення.
Versioning — захист від перезапису і видалення (видалення = delete marker, стару версію можна повернути). MFA Delete — для остаточного видалення версій потрібен MFA (вмикає тільки root).
Replication:CRR (в інший регіон: DR, менша затримка, комплаєнс) і SRR (в тому ж регіоні: збір логів, prod → test). Потрібен versioning з обох боків. Реплікуються лише нові об'єкти; наявні — через S3 Batch Replication. RTC — 99,99% об'єктів за 15 хв (SLA).
Object Lock (WORM):
Compliance mode — ніхто, навіть root, не видалить і не змінить до кінця терміну.
Governance mode — можуть обійти користувачі з окремим дозволом.
Legal hold — без терміну, доки не знімуть.
S3 Glacier Vault Lock — WORM-політика для vault. (Окремий старий сервіс «Amazon Glacier» з vaults з листопада 2025 закритий для нових клієнтів; класи S3 Glacier працюють як завжди.)
Безпека і доступ
Block Public Access увімкнено за замовчуванням. ACL вимкнені за замовчуванням (Object Ownership = Bucket owner enforced). Доступ — через bucket policy та IAM.
Presigned URL — тимчасовий доступ до приватного об'єкта (завантажити або скачати) з правами того, хто підписав.
Access Points — окремі точки доступу зі своїми політиками для різних команд і застосунків (можна «тільки з VPC»).
Multi-Region Access Points — один глобальний endpoint до bucket у кількох регіонах з маршрутизацією і failover.
CORS — дозволити браузеру з іншого домену звертатися до bucket.
aws:SourceVpce / aws:SourceVpc в bucket policy — доступ лише через конкретний VPC endpoint або з конкретної VPC.
Приклад bucket policy: заборонити HTTP і будь-який доступ не через свій VPC endpoint (обережно: друге правило закриє доступ навіть з консолі):
Розміри: gp3 і io2 — до 64 TiB (gp3 так з вересня 2025; раніше 16 TiB і 16 000 IOPS).
EBS прив'язаний до однієї AZ. Перенести в іншу AZ або регіон → snapshot → створити том там (snapshot можна копіювати між регіонами).
Snapshots — інкрементальні, зберігаються в S3. Автоматизація: Data Lifecycle Manager (DLM) або AWS Backup. Snapshot Archive — дешевше для рідко потрібних. Recycle Bin — захист від випадкового видалення. Fast Snapshot Restore — том одразу на повній швидкості.
Multi-Attach (лише io1/io2) — один том до кількох Nitro-інстансів в одній AZ (кластерні застосунки).
Elastic Volumes — змінити тип, розмір або IOPS тому без зупинки інстансу. Тому gp2 → gp3 — зазвичай дешевше і без простою.
Amazon EFS
Керована NFS-файлова система для Linux: одночасно для тисяч EC2, ECS, EKS і Lambda, у кількох AZ (або One Zone — дешевше).
Росте автоматично до петабайтів, платиш за використане.
Throughput: Elastic (рекомендовано), Provisioned, Bursting. Performance mode — General Purpose.
Шифрування, POSIX-права, Access Points, реплікація в інший регіон. Дорожча за EBS за ГБ, зате спільна.
Mount target створюють у кожній AZ; його Security Group має дозволяти NFS, порт 2049 від клієнтів.
Amazon FSx
FSx for Windows File Server — SMB, NTFS, інтеграція з Active Directory, DFS, Multi-AZ. Для Windows-застосунків, SharePoint, домашніх папок.
FSx for Lustre — високопродуктивна ФС для HPC, ML, рендерингу, фінансових моделей: сотні GB/s, суб-мс затримка, інтеграція з S3 (читає дані з S3, пише результати назад). Scratch (тимчасово, дешево) vs Persistent (довготривало, з реплікацією).
FSx for NetApp ONTAP — NFS + SMB + iSCSI одночасно, Linux/Windows/macOS, snapshots, клонування, дедуплікація і компресія. Міграція з NetApp.
FSx for OpenZFS — міграція ZFS/Linux NFS, snapshots, низька затримка.
🎯 Тригери
Спільна файлова система для кількох Linux-інстансів у різних AZ→Amazon EFS
Спільна файлова система для Windows з Active Directory→FSx for Windows File Server
HPC або ML, дуже висока продуктивність, дані лежать у S3→FSx for Lustre
Потрібні NFS і SMB одночасно / міграція з NetApp→FSx for NetApp ONTAP
БД на EC2 потребує понад 100 000 стабільних IOPS→io2 Block Express
Дешевий диск для великих послідовних логів і big data→st1
Найдешевший блочний диск для холодних даних→sc1
Знизити витрати на EBS без простою→gp2 → gp3
10 000 IOPS на невеликому томі дешево→gp3 (IOPS окремо від розміру)
Перенести EBS-том в іншу AZ→Snapshot → новий том в іншій AZ
Щоденні автоматичні знімки EBS з видаленням старих→Data Lifecycle Manager або AWS Backup
Кластерний застосунок на кількох інстансах з одним спільним томом→EBS Multi-Attach (io1/io2)
Файли в EFS майже не відкривають після 30 днів→EFS lifecycle → Infrequent Access / Archive
EC2 не можуть змонтувати EFS (timeout)→Дозволити порт 2049 (NFS) у Security Group mount target
Тимчасовий кеш з максимальними IOPS→Instance store
⚠️ Пастки
EBS — одна AZ і, як правило, один інстанс. EFS — багато інстансів, багато AZ, тільки Linux (NFS).
HDD-томи (st1, sc1) не можуть бути boot-томом.
Для Windows-шар — FSx for Windows, а не EFS.
15Гібрид, міграція і перенесення даних
Storage Gateway (on-prem доступ до хмарного сховища з локальним кешем)
S3 File Gateway — NFS/SMB-шари, файли стають об'єктами в S3 (далі lifecycle, Glacier).
FSx File Gateway — локальний кеш для FSx for Windows (з жовтня 2024 недоступний новим клієнтам).
Volume Gateway (iSCSI):
Cached — основні дані в S3, «гарячі» — локально.
Stored — усі дані локально, асинхронний бекап в S3 (як EBS snapshots).
Tape Gateway — віртуальна стрічкова бібліотека (VTL) для наявного бекап-ПЗ → S3 / Glacier. Заміна фізичних стрічок.
Перенесення даних
AWS DataSync — онлайн-перенесення і синхронізація великих обсягів: NFS, SMB, HDFS, об'єктні сховища, інші хмари ↔ S3, EFS, FSx. Агент on-prem, шифрування, перевірка цілісності, збереження метаданих і прав, розклад, обмеження пропускної. Також між сервісами AWS.
AWS Transfer Family — керований SFTP / FTPS / FTP / AS2-сервер поверх S3 або EFS. Партнери працюють як раніше, нічого не змінюючи.
Snow Family (Snowball Edge) — фізичні пристрої для офлайн-перенесення терабайтів і петабайтів і для edge-обчислень, коли мережа повільна або дорога.
Орієнтир: якщо передача мережею займе більше ~тижня → фізичний пристрій.
🆕 З 7.11.2025 Snowball Edge недоступний новим клієнтам. AWS радить DataSync, Data Transfer Terminal (фізичні локації AWS для швидкого завантаження) або партнерів. На іспиті Snowball ще може бути правильною відповіддю.
Міграція серверів і баз даних
AWS DMS — міграція БД з мінімальним простоєм: джерело працює під час міграції, CDC (безперервна реплікація змін).
Керовані реляційні БД: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2. AWS робить патчі, бекапи, Multi-AZ. Доступу до ОС немає (виняток — RDS Custom для Oracle і SQL Server).
Multi-AZ (DB instance) — синхронна standby-копія в іншій AZ, автоматичний failover (зазвичай 60–120 с, той самий DNS-endpoint). Standby не обслуговує читання — це для доступності, а не для масштабування.
Multi-AZ DB cluster (MySQL, PostgreSQL) — 1 writer + 2 standby, з яких можна читати, у 3 AZ; failover зазвичай до 35 с.
Read Replicas — асинхронні, до 15 (MySQL, MariaDB, PostgreSQL), в інших AZ і регіонах. Для масштабування читання і звітів. Можна promote у самостійну БД (DR). Застосунок сам спрямовує читання на endpoint репліки. Автоскейлінгу реплік у RDS немає (в Aurora є).
Бекапи: автоматичні (зберігання 1–35 днів, point-in-time restore з точністю до секунд, приблизно до останніх 5 хв) і ручні snapshots (живуть, доки не видалиш). Відновлення завжди створює нову БД з новим endpoint.
RDS Proxy — пул з'єднань (Lambda, тисячі коротких з'єднань), швидший failover (до 66%), IAM-автентифікація, паролі з Secrets Manager. Код не змінюється — лише endpoint.
Storage autoscaling — диск БД росте автоматично.
IAM database authentication (MySQL, PostgreSQL) — токени замість паролів.
RDS Blue/Green Deployments — безпечне оновлення версії БД з перемиканням менш ніж за хвилину.
Enhanced Monitoring — метрики ОС бази (процеси, пам'ять) з інтервалом до 1 с. Performance Insights — які SQL-запити навантажують БД.
Зупинка RDS — інстанс можна зупинити до 7 днів (потім він стартує сам). Економія для dev/test.
Шифрування — лише при створенні (див. розділ 5).
🎯 Тригери
Висока доступність БД, автоматичний failover в іншу AZ→RDS Multi-AZ
Багато читань, звіти гальмують основну БД→Read Replicas (або кеш ElastiCache)
Недорогий DR БД в іншому регіоні→Cross-Region Read Replica (promote при аварії) або копіювання snapshots
Lambda вичерпує з'єднання до БД→RDS Proxy
Відновити БД на стан 10 хвилин тому→Point-in-time restore (створить нову БД)
Потрібен доступ до ОС бази (агенти, кастомні патчі)→RDS Custom (або БД на EC2)
Оновити версію БД з мінімальним простоєм і можливістю відкату→RDS Blue/Green Deployments
Не зберігати паролі до БД у коді→IAM DB authentication або Secrets Manager
Потрібні і HA, і читання зі standby→Multi-AZ DB cluster
Потрібні метрики ОС бази (пам'ять процесів) щосекунди→RDS Enhanced Monitoring
Знайти SQL-запити, які найбільше навантажують БД→Performance Insights
Restore зі snapshot або PITR створює новий інстанс з новим endpoint.
17Amazon Aurora
Сумісна з MySQL і PostgreSQL; за даними AWS — до 5× швидша за MySQL і до 3× за PostgreSQL.
6 копій даних у 3 AZ, сховище росте автоматично до 256 TiB (з 2025; раніше 128 TiB), самовідновлюється.
До 15 Aurora Replicas на спільному сховищі (затримка реплікації зазвичай < 100 мс). Автоматичний failover на репліку (зазвичай до ~30 с), порядок — за failover tiers. Aurora Auto Scaling додає і прибирає репліки за навантаженням.
Endpoints
Writer (cluster) endpoint — на поточний primary для запису (INSERT, UPDATE, DELETE). Після failover перемикається сам.
Reader endpoint — балансує SELECT-запити між репліками.
Custom endpoints — окремі групи реплік під різні навантаження (напр., аналітичні звіти окремо від веб-трафіку, більші інстанси — для звітів).
Instance endpoints — до конкретного інстансу.
Катастрофостійкість і масштаб
Aurora Global Database — реплікація на рівні сховища до 10 вторинних регіонів (з травня 2025; раніше 5). Затримка зазвичай < 1 с, RPO ~1 с, RTO < 1 хв. Локальне швидке читання в кожному регіоні; write forwarding.
Aurora Cross-Region Read Replica (Aurora MySQL) — логічна реплікація (binlog) на рівні БД, більша затримка (від секунд до хвилин). Для мінімальних RPO/RTO — Global Database.
Спеціальні можливості
Aurora Serverless v2 — автоматично і миттєво масштабує потужність в ACU (1 ACU ≈ 2 GiB RAM + CPU і мережа). З кінця 2024 може опускатися до 0 ACU: БД «засинає» (auto-pause), платиш лише за сховище, пробудження до ~15 с. Для непередбачуваних або переривчастих навантажень, dev/test. Можна змішувати з provisioned-інстансами в одному кластері.
Babelfish for Aurora PostgreSQL — розуміє T-SQL і протокол SQL Server: застосунки з MS SQL Server переходять майже без змін коду.
Aurora Machine Learning — ML-прогнози прямо в SQL-запитах (виклики SageMaker AI, Comprehend, Bedrock) без знань ML.
Aurora Backtrack — «перемотати» кластер назад у часі (до 72 год) без відновлення з бекапу. Тільки Aurora MySQL.
Aurora Cloning — швидка copy-on-write копія кластера (тести на свіжих даних без повної копії).
Aurora I/O-Optimized — без плати за I/O; вигідно, коли I/O > ~25% витрат на Aurora.
Zero-ETL integration з Redshift — дані з Aurora майже в реальному часі доступні в Redshift без ETL-пайплайнів.
Aurora DSQL (з 2025) — distributed serverless SQL (PostgreSQL-сумісна), active-active у кількох регіонах.
🎯 Тригери
Розділити аналітичне навантаження і веб-трафік на різні репліки→Custom Endpoints
Найшвидша реплікація між регіонами, RPO ~1 с, RTO < 1 хв→Aurora Global Database
Міграція з MS SQL Server без переписування T-SQL-коду→Babelfish for Aurora PostgreSQL
ML-прогнози через звичайні SQL-запити без знань ML→Aurora Machine Learning (SageMaker AI / Comprehend)
Непередбачувані сплески навантаження або БД «спить» уночі→Aurora Serverless v2
Випадково видалили дані — швидко повернути стан без відновлення з бекапу→Aurora Backtrack (тільки MySQL)
Швидко створити копію prod-бази для тестів→Aurora Cloning
Автоматично додавати репліки при зростанні читання→Aurora Auto Scaling
Аналітика в Redshift на даних з Aurora без ETL→Zero-ETL integration
Великі витрати на операції I/O в Aurora→Aurora I/O-Optimized
Максимальна доступність реляційної БД з мінімальним адмініструванням→Amazon Aurora
Читання всередині кожного регіону для глобального застосунку→Aurora Global Database (secondary regions)
⚠️ Пастки
Backtrack є лише в Aurora MySQL. Для PostgreSQL — point-in-time restore або клон.
Застосунок має писати через writer endpoint, а читати через reader/custom endpoints.
18Amazon DynamoDB
Serverless NoSQL (key-value і документи): одноцифрові мілісекунди на будь-якому масштабі, автоматично в кількох AZ. Елемент — до 400 KB.
Ключ: partition key (+ sort key). Індекси: GSI — інший partition key, можна додати будь-коли; LSI — той самий partition key з іншим sort key, лише під час створення таблиці.
Режими ємності:
On-demand — плата за запити, без планування (непередбачуваний або новий трафік).
Provisioned — RCU/WCU + auto scaling (передбачуваний трафік, дешевше; можна reserved capacity).
Читання: eventually consistent (за замовчуванням, дешевше) або strongly consistent. Transactions — ACID для кількох елементів.
DAX — кеш у пам'яті перед DynamoDB: мікросекунди, сумісний API, код майже не змінюється. Тільки для DynamoDB.
Global Tables — кілька регіонів, multi-active (запис у будь-якому регіоні). Eventual consistency або 🆕 (з 2025) strong consistency між регіонами (RPO = 0).
DynamoDB Streams — потік змін (зберігається 24 год) → Lambda: тригери, агрегації, реплікація. Kinesis Data Streams for DynamoDB — довше зберігання і більше споживачів.
TTL — автоматичне безкоштовне видалення застарілих елементів (сесії, тимчасові дані).
Бекапи:PITR до 35 днів з точністю до секунди, on-demand backups, AWS Backup. Export to S3 без навантаження на таблицю → аналітика в Athena.
Шифрування за замовчуванням. Доступ з VPC — через gateway endpoint.
Standard-IA table class — дешевше зберігання для таблиць, які рідко читають.
Розрахунок ємності (RCU / WCU)
1 RCU = 1 strongly consistent читання за секунду елемента до 4 KB, або 2 eventually consistent читання. Транзакційне читання — 2 RCU.
1 WCU = 1 запис за секунду елемента до 1 KB. Транзакційний запис — 2 WCU.
Розмір округлюється вгору: елемент 10 KB = 3 блоки по 4 KB (читання) і 10 блоків по 1 KB (запис).
Потрібні складні JOIN і реляційна модель→Не DynamoDB → RDS / Aurora
Throttling, бо всі запити йдуть в один ключ (напр., поточна дата)→Partition key з високою кардинальністю (userId) або write sharding
⚠️ Пастки
DAX — кеш лише для DynamoDB. Для RDS — ElastiCache.
LSI створюється тільки разом з таблицею. GSI можна додати будь-коли.
Елемент DynamoDB — максимум 400 KB. Великі файли → S3, а в таблиці — посилання.
19Кешування та інші бази даних
Amazon ElastiCache
Керований кеш у пам'яті: Redis OSS / Valkey і Memcached. Відповіді за мікросекунди–мілісекунди. Знімає навантаження з БД, зберігає сесії.
Redis / Valkey: реплікація, Multi-AZ з автоматичним failover, persistence і бекапи, складні структури (sorted sets → лідерборди), pub/sub. Є serverless-варіант.
Memcached: простий, багатопотоковий, шардування, без реплікації і без persistence.
Стратегії кешування:
Lazy loading (cache-aside) — у кеш потрапляє те, що запитували; дані можуть застаріти → TTL.
Write-through — запис одночасно в БД і кеш; кеш завжди свіжий, але зберігає й непотрібне.
Потребує змін у коді застосунку (логіка роботи з кешем).
Інші бази
Amazon Redshift — сховище даних для аналітики (див. розділ 20).
Amazon DocumentDB — документна БД, сумісна з MongoDB.
Amazon MemoryDB — Redis/Valkey-сумісна основна (не кеш) БД у пам'яті з durability.
Amazon QLDB (ledger) — закритий 31.07.2025, не обирай.
Яку БД обрати
Вимога
Сервіс
Реляційна, SQL, JOIN, транзакції (OLTP)
RDS / Aurora
Максимальна доступність і продуктивність реляційної БД
Aurora
Key-value, мілісекунди, будь-який масштаб, serverless
DynamoDB
Кеш, сесії, лідерборди
ElastiCache (Redis / Valkey)
Аналітика, OLAP, data warehouse, петабайти
Redshift
MongoDB-сумісна документна
DocumentDB
Графи, зв'язки
Neptune
Cassandra
Keyspaces
Часові ряди
Timestream
Повнотекстовий пошук, аналіз логів
OpenSearch
🎯 Тригери
Лідерборд гри в реальному часі→ElastiCache for Redis/Valkey (sorted sets)
Зберігати сесії користувачів для stateless-вебсерверів→ElastiCache або DynamoDB
Зменшити навантаження на RDS для повторюваних запитів→ElastiCache (lazy loading)
Простий багатопотоковий кеш без реплікації→Memcached
Перенести MongoDB-застосунок у керований сервіс→DocumentDB
Соцмережа «друзі друзів» або виявлення шахрайських зв'язків→Neptune
Перенести Cassandra в керований сервіс→Keyspaces
Показники IoT-датчиків з часовими мітками→Timestream
Кеш має пережити збій вузла без втрати даних→ElastiCache Redis/Valkey з Multi-AZ і реплікацією
⚠️ Пастки
ElastiCache потребує змін у коді. Якщо сказано «без змін коду» — дивись на read replicas (RDS) або DAX (DynamoDB).
Memcached не має реплікації і не зберігає дані на диск.
20Аналітика і потоки даних
Kinesis і Kafka
Kinesis Data Streams (KDS) — потік у реальному часі (затримка ~70–200 мс), власні споживачі (Lambda, KCL-застосунки, Flink), кілька споживачів читають один потік, replay, порядок у межах shard.
Зберігання: 24 год за замовчуванням, до 365 днів.
Shard: запис 1 MB/s або 1 000 записів/с, читання 2 MB/s (enhanced fan-out — 2 MB/s окремо кожному споживачу).
Режими: on-demand (масштабується сам) і provisioned (кількість shards).
Запис до 1 MiB (🆕 з жовтня 2025 можна налаштувати до 10 MiB).
Partition key визначає shard. «Гарячий» shard → розділити його (split), обрати кращий ключ або перейти в on-demand.
Amazon Data Firehose (колишній Kinesis Data Firehose) — near real-time доставка (з буферизацією) в S3, Redshift, OpenSearch, Splunk, HTTP endpoints, Snowflake, Iceberg-таблиці. Повністю керований, масштабується сам, трансформація через Lambda, конвертація в Parquet/ORC, стиснення. Replay і зберігання даних немає.
Managed Service for Apache Flink (колишній Kinesis Data Analytics) — обробка потоків у реальному часі: агрегації у вікнах часу, виявлення аномалій (SQL, Java, Python).
Kinesis Video Streams — потокове відео з камер для аналітики і ML (напр., Rekognition Video).
AWS Glue — serverless ETL на Spark; Data Catalog (центральні метадані таблиць для Athena, Redshift Spectrum, EMR); crawlers (самі визначають схему); job bookmarks (обробляти лише нові дані); Glue DataBrew (візуальна підготовка даних без коду); конвертація CSV → Parquet.
Amazon Athena — serverless SQL прямо по файлах у S3, плата за обсяг сканування (~$5 за TB). Дешевше: формат Parquet/ORC, стиснення, партиціювання. Аналіз логів (CloudTrail, ALB, VPC Flow Logs, CloudFront). Federated Query — SQL до RDS, DynamoDB та інших джерел через конектори. CTAS (CREATE TABLE AS SELECT) перетворює CSV у Parquet прямо запитом.
Amazon EMR — керований Hadoop, Spark, Hive, Presto, HBase для великих даних. Кластер на EC2 (primary / core / task-вузли на Spot), EMR Serverless, EMR on EKS. Коли потрібен контроль над фреймворками або вже є Spark/Hadoop-код.
Redshift Spectrum — запити до даних у S3 без завантаження.
Concurrency Scaling — додаткова потужність у пікові години.
Zero-ETL з Aurora, RDS і DynamoDB; data sharing.
DR — cross-region snapshot copy.
Найшвидше завантаження даних — команда COPY з S3 (паралельно з багатьох файлів).
Amazon OpenSearch Service — повнотекстовий пошук і аналіз логів (аналог ELK), дашборди OpenSearch Dashboards, OpenSearch Serverless.
Amazon Quick (колишній QuickSight) — BI-дашборди для бізнесу: serverless, SPICE (in-memory), ML insights, вбудовування в застосунки, row-level security.
AWS Lake Formation — побудова і безпека data lake на S3: централізовані дозволи аж до колонок, рядків і комірок для Athena, Redshift Spectrum, EMR, Glue; шерінг між акаунтами.
AWS Data Exchange — підписка на сторонні датасети (фінансові, погодні тощо) з доставкою в S3.
🚰 ПрийманняKinesis Data Streams реальний час Data Firehose доставка в S3 (+ Parquet)
→
🪣 S3 rawСирі дані як є (CSV, JSON)
→
🧹 AWS GlueCrawler + Data Catalog (схеми); ETL у Parquet з партиціями → S3 curated
→
🔎 ЗапитиAthenaRedshift SpectrumEMR
→
📊 Amazon QuickДашборди для бізнесу
🛡️ Lake Formation — єдині дозволи до баз, таблиць, колонок і рядків для Athena, Redshift Spectrum, EMR і Glue
Реальний час з кількома споживачами і replay → Kinesis Data Streams. Просто складати потік у S3 → Firehose. Разові SQL-запити по S3 → Athena; важка регулярна BI-аналітика → Redshift.
🎯 Тригери
Потік кліків або IoT у реальному часі, кілька застосунків-споживачів, replay→Kinesis Data Streams
Складати потокові дані в S3, Redshift або OpenSearch без коду, near real-time→Amazon Data Firehose
Перетворити потік JSON у Parquet перед збереженням у S3→Firehose (конвертація формату)
Аналіз потоку у вікнах часу, аномалії в реальному часі→Managed Service for Apache Flink
Наявні Kafka-застосунки→Amazon MSK
SQL-запити по логах або CSV у S3 без серверів→Athena
Знизити вартість запитів Athena→Parquet + стиснення + партиціювання
ETL без серверів, CSV → Parquet, каталог даних→AWS Glue
ETL при кожному запуску має обробляти лише нові файли→Glue job bookmarks
Великі задачі Spark/Hadoop, контроль над кластером, дешево→EMR (task nodes на Spot)
Складна BI-аналітика на петабайтах структурованих даних→Redshift
Запитувати дані в S3 з Redshift без завантаження→Redshift Spectrum
Повнотекстовий пошук по каталогу товарів, аналіз логів→OpenSearch
Інтерактивні дашборди для бізнесу→Amazon Quick (QuickSight)
Детальні права до колонок і рядків у data lake→Lake Formation
Отримувати сторонні датасети від постачальників→AWS Data Exchange
Відео з камер для аналізу ML→Kinesis Video Streams
Один shard Kinesis перевантажений (ProvisionedThroughputExceeded)→Кращий partition key, split shard або on-demand режим
Перетворити CSV у Parquet без окремого ETL-сервісу→Athena CTAS (або Glue ETL)
Швидко завантажити великі обсяги з S3 у Redshift→Команда COPY
⚠️ Пастки
Kinesis Data Streams = реальний час + зберігання + replay. Firehose = доставка near real-time, без replay.
Athena — разові запити по S3; Redshift — постійне сховище для важкої регулярної аналітики.
21Машинне навчання, AI і фронтенд
Amazon Rekognition — аналіз зображень і відео: об'єкти, обличчя, модерація контенту, текст на фото.
Amazon Textract — витягує текст, форми і таблиці зі сканів і PDF (більше, ніж звичайний OCR).
Amazon Comprehend — NLP: тональність (sentiment), сутності, мова, ключові фрази, PII в тексті.
Amazon Transcribe — мова → текст (субтитри, записи дзвінків), з приховуванням PII.
Amazon Polly — текст → мова (озвучення).
Amazon Translate — машинний переклад.
Amazon Lex — чат-боти (голос і текст).
Amazon SageMaker AI — побудова, навчання і розгортання власних ML-моделей.
AWS Amplify — хостинг і бекенд для веб- і мобільних застосунків (full-stack), CI/CD фронтенду.
AWS Device Farm — тестування застосунків на реальних телефонах, планшетах і браузерах.
🎯 Тригери
Розпізнати обличчя або об'єкти, модерація фото і відео→Rekognition
Витягнути дані з рахунків, форм і PDF→Textract
Визначити тональність відгуків або знайти PII в тексті→Comprehend
Перетворити записи дзвінків у текст→Transcribe
Озвучити текст→Polly
Перекласти контент на інші мови→Translate
Чат-бот для сайту або кол-центру→Lex
Навчити і розгорнути власну модель→SageMaker AI
Тестувати мобільний застосунок на сотнях реальних пристроїв→Device Farm
Швидко розгорнути фронтенд і бекенд веб/мобільного застосунку→Amplify
Конвеєр «аудіо → текст → переклад → озвучення»→Transcribe → Translate → Polly
⚠️ Пастки
Готові AI-сервіси (Rekognition, Comprehend тощо) не потребують знань ML. SageMaker AI — для власних моделей.
22Моніторинг, керування, інфраструктура як код
CloudWatch Metrics: EC2 за замовчуванням — CPU, мережа, диск (instance store), status checks; раз на 5 хв (detailed monitoring — раз на хвилину). RAM і вільне місце на диску — ні! → CloudWatch agent. Можна власні (custom) метрики.
CloudWatch Alarms → SNS, ASG, дії EC2 (stop, terminate, reboot, recover), Systems Manager. Composite alarms — комбінація умов (менше хибних тривог).
CloudWatch Logs: збір логів агентом і сервісами; retention налаштовується (за замовчуванням — назавжди); metric filters (напр., рахувати ERROR і ставити аларм); Logs Insights (запити); subscription filters → Lambda, Firehose, Kinesis, OpenSearch у реальному часі; експорт в S3.
CloudWatch Synthetics (canaries — імітація користувача), Container Insights. Amazon Managed Grafana і Managed Service for Prometheus — дашборди і метрики контейнерів.
AWS CloudTrail — журнал API-викликів: хто, що, коли, звідки.
Event history — 90 днів management events безкоштовно.
Data events (об'єкти S3, виклики Lambda) — вимкнені за замовчуванням, платні.
CloudTrail Insights — незвична активність. Log file integrity validation — доказ, що логи не змінювали. CloudTrail Lake — SQL-запити по подіях.
AWS Config — інвентар і історія конфігурацій ресурсів, Config rules (готові і власні) для compliance, автоматичне виправлення через SSM Automation, conformance packs, aggregator для багатьох акаунтів і регіонів.
AWS X-Ray — трасування запитів через мікросервіси: де затримка або помилка, service map.
EventBridge + CloudTrail — реагувати на конкретний API-виклик (напр., хтось змінив Security Group) → Lambda або SNS.
Anomaly detection alarms у CloudWatch — аларм, коли метрика виходить за звичний коридор, без ручних порогів.
AWS Systems Manager (SSM):
Session Manager — shell без SSH і бастіону.
Run Command — команди на всіх серверах одразу.
Patch Manager + Maintenance Windows — патчі ОС за розкладом.
Parameter Store, Automation (runbooks), State Manager, Inventory.
Працює і з on-prem серверами (hybrid activations).
AWS CloudFormation — інфраструктура як код (шаблони YAML/JSON): однакові середовища, відтворення в іншому регіоні (DR). StackSets — розгортання в багатьох акаунтах і регіонах. Change sets — попередній перегляд змін. Drift detection — виявлення ручних змін. DeletionPolicy: Retain / Snapshot.
AWS Service Catalog — каталог затверджених продуктів (шаблонів) для самообслуговування користувачів з обмеженими правами.
AWS Trusted Advisor — рекомендації: вартість, продуктивність, безпека, стійкість, ліміти сервісів, операційна досконалість. Повний набір перевірок — з планами підтримки Business і вище.
AWS Compute Optimizer — ML-рекомендації правильного розміру для EC2, ASG, EBS, Lambda, ECS на Fargate, RDS.
AWS Health Dashboard — події AWS, що зачіпають твої ресурси (планове обслуговування, збої) → EventBridge.
AWS License Manager — облік і контроль ліцензій (Microsoft, Oracle, SAP), заборона перевищення лімітів.
AWS Well-Architected Tool — самоперевірка архітектури за 6 стовпами.
🎯 Тригери
Моніторити використання RAM і диска на EC2→CloudWatch agent
Сповіщення, коли в логах «ERROR» з'являється частіше за N разів→Metric filter + CloudWatch alarm → SNS
Хто змінив або видалив ресурс і коли→CloudTrail
Журнал усіх API-викликів у всіх акаунтах організації→Organization trail → S3
Хто читає об'єкти в S3-bucket→CloudTrail data events (або S3 server access logs)
БалансуванняApplication Load Balancer — публічні підмережі у 2+ AZ
↓
ЗастосунокEC2 в Auto Scaling — AZ aEC2 в Auto Scaling — AZ bприватні підмережі, без стану (stateless)
↓
ДаніAurora writer (AZ a)Aurora replica (AZ b)ElastiCache: сесії й кеш
↓
Бекапи і DRAWS Backup → інший регіонAurora Global Database (за потреби)
Немає єдиної точки відмови: кожен рівень щонайменше у двох AZ. Сесії зберігаються не на серверах, тому ASG вільно додає й прибирає інстанси.
HA в одному регіоні: ALB + ASG у ≥2 AZ + Multi-AZ БД + stateless-сервери (сесії в ElastiCache/DynamoDB) + статика в S3 + CloudFront.
Кілька регіонів: Route 53 (failover/latency) або Global Accelerator; Aurora Global Database або DynamoDB Global Tables; S3 CRR; копії AMI і snapshots; CloudFormation для відтворення інфраструктури; квоти в DR-регіоні — заздалегідь.
AWS Backup — централізовані плани бекапів для EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3, Storage Gateway, DocumentDB, Neptune та ін.; копії між регіонами й акаунтами; Backup Vault Lock (WORM — ніхто не видалить бекапи, захист від ransomware); backup policies в Organizations; Backup Audit Manager.
Elastic Disaster Recovery — постійна реплікація серверів, RPO секунди, RTO хвилини (див. розділ 15).
Immutable infrastructure — не латати «живі» сервери, а замінювати новими з нового AMI (instance refresh, blue/green).
Legacy-застосунок без змін коду: ASG (навіть min = max = 1 для автозаміни), ELB health checks, Multi-AZ RDS, RDS Proxy, EFS для спільних файлів, Route 53 health checks.
Стійкий код: слабке зв'язування (SQS між шарами), повтори з exponential backoff і jitter, ідемпотентність обробки.
🎯 Тригери
RPO/RTO — години, мінімальна вартість→Backup & Restore
RTO — десятки хвилин; БД реплікується, сервери піднімаються під час аварії→Pilot Light
RTO — хвилини; зменшена копія працює постійно→Warm Standby
RPO і RTO майже нуль, трафік в обох регіонах→Multi-site Active-Active
Централізовані бекапи багатьох сервісів з копією в інший акаунт і регіон→AWS Backup
Бекапи не може видалити навіть адміністратор (ransomware)→AWS Backup Vault Lock
Застосунок на одному EC2 має автоматично відновлюватися після збою→ASG з min = max = 1 (+ ELB health check)
Швидко відтворити всю інфраструктуру в іншому регіоні→CloudFormation (+ копії AMI)
Реляційна БД з RPO ~1 с і RTO < 1 хв між регіонами→Aurora Global Database
NoSQL, запис у кількох регіонах одночасно→DynamoDB Global Tables
Копія об'єктів S3 в іншому регіоні з гарантованим часом→S3 CRR + Replication Time Control
⚠️ Пастки
Multi-AZ захищає від збою AZ, але не від збою всього регіону — для цього потрібен інший регіон.
Read replica в іншому регіоні — це DR, але failover потребує promote (з можливою втратою останніх змін через асинхронність).
24Оптимізація витрат
Обчислення
Правильний розмір (Compute Optimizer), Spot для переривних задач, Savings Plans/RI для постійних, Graviton, serverless для переривчастих навантажень.
Вимикати dev/test поза робочим часом (EventBridge Scheduler + Lambda або Instance Scheduler).
ASG замість постійного запасу потужності.
Сховище
Lifecycle у S3 (→ IA → Glacier), Intelligent-Tiering для невідомого патерну.
gp3 замість gp2; видаляти старі snapshots і непідключені EBS-томи.
EFS Infrequent Access / Archive; стиснення і формат Parquet для аналітики.
Бази даних
Aurora Serverless v2 або DynamoDB on-demand — для нерівномірного навантаження; provisioned + резервування — для стабільного.
Кеш (ElastiCache, DAX) замість дорожчого інстансу; read replicas замість вертикального масштабування.
🆕 Database Savings Plans — до 35% на RDS, Aurora, DynamoDB та ін.
Мережа (передача даних)
Вхідний трафік в AWS — безкоштовний.
Усередині однієї AZ по приватних IP — безкоштовно; між AZ — платно; між регіонами — платно; в інтернет — найдорожче.
Gateway endpoints до S3/DynamoDB замість NAT Gateway (NAT бере плату за кожен ГБ).
CloudFront зменшує витрати на вихідний трафік і навантаження на origin.
NAT Gateway у кожній AZ — дорожче, але HA і без трафіку між AZ; одна NAT на всю VPC — дешевше, але єдина точка відмови (підходить для dev/test).
Direct Connect — дешевший вихідний трафік для великих обсягів.
Компоненти, що багато спілкуються, тримай в одній AZ або регіоні (якщо вимоги до HA дозволяють).
Transit Gateway vs VPC Peering: TGW бере плату за кожне вкладення (attachment) і за кожен ГБ обробленого трафіку; peering — лише за трафік між AZ/регіонами. Для кількох VPC з великим трафіком peering дешевший.
Обчислення: що дешевше
Lambda vs EC2: переривчасте або невелике навантаження — Lambda дешевша; постійне високе 24/7 — EC2 або Fargate із Savings Plans зазвичай дешевші.
RDS для dev/test можна зупиняти до 7 днів (потім інстанс стартує сам) або перейти на Aurora Serverless v2.
Інструменти
AWS Cost Explorer — аналіз і прогноз витрат, рекомендації RI і Savings Plans.
AWS Budgets — сповіщення при перевищенні бюджету або прогнозу; Budget Actions — автоматичні дії (напр., обмежити запуск ресурсів).
AWS Cost and Usage Report (CUR) / Data Exports — найдетальніші дані (кожен ресурс, кожна година) в S3 → Athena / Quick.
Cost Anomaly Detection — ML-сповіщення про аномальні витрати.
Cost allocation tags — розподіл витрат за проєктами і відділами (теги треба активувати в Billing).
Organizations consolidated billing — один рахунок, об'ємні знижки, спільні RI/SP.
Pricing Calculator — оцінка вартості майбутньої архітектури.
🎯 Тригери
Сповіщення, коли прогноз витрат перевищить $1000→AWS Budgets
Проаналізувати витрати за останні місяці і спрогнозувати наступні→Cost Explorer
Найдетальніші дані про витрати по кожному ресурсу для аналізу в Athena→Cost and Usage Report
Розподілити витрати між відділами або проєктами→Cost allocation tags (+ окремі акаунти)
Невідомий патерн доступу до об'єктів S3→S3 Intelligent-Tiering
Зменшити трафік між AZ для dev-середовища→Одна NAT Gateway / ресурси в одній AZ
Дві VPC обмінюються великим обсягом даних, потрібне найдешевше з'єднання→VPC Peering (не Transit Gateway)
Постійне високе навантаження 24/7 на Lambda, рахунки ростуть→EC2 або Fargate + Savings Plans
Знайти дані, які варто перевести в дешевші класи S3→S3 Storage Class Analysis / Storage Lens
⚠️ Пастки
«Найдешевше» на іспиті = найдешевше з тих, що виконують усі вимоги. Дешевий варіант без HA програє, якщо в питанні потрібна HA.
Трафік між AZ платний — навіть усередині однієї VPC.
25Цифри, ліміти і порти
Усі цифри звірені з документацією AWS станом на вересень 2026. На іспиті частіше питають не саму цифру, а наслідок: «Lambda — 15 хв, отже задача на годину — не Lambda».
раз на рік за замовчуванням (90–2560 днів або вручну)
KMS — видалення ключа
очікування 7–30 днів
CloudTrail — Event history
90 днів
CloudWatch — метрики EC2
5 хв (detailed monitoring — 1 хв)
CloudWatch Logs
зберігаються безстроково, доки не задаш retention
Shield Advanced
~$3 000 на місяць на організацію
Порти, які варто знати
Порт
Протокол або сервіс
22
SSH
3389
RDP (Windows)
80 / 443
HTTP / HTTPS
3306
MySQL, MariaDB, Aurora MySQL
5432
PostgreSQL, Aurora PostgreSQL
1433
Microsoft SQL Server
1521
Oracle
2049
NFS (EFS)
445
SMB (FSx for Windows)
6379
Redis OSS / Valkey
11211
Memcached
53
DNS
26«X чи Y?» — найчастіші плутанини
Мережа
Security Group vs NACL: SG — інстанс, stateful, лише Allow, посилання на інші SG. NACL — підмережа, stateless, Allow + Deny, правила за номерами.
Gateway vs Interface endpoint: Gateway — лише S3 і DynamoDB, безкоштовно, запис у route table. Interface — майже всі сервіси, ENI з приватним IP, платно, доступний з on-prem.
VPC Peering vs Transit Gateway vs PrivateLink: Peering — 1:1, нетранзитивно, дешево. TGW — хаб на сотні VPC і on-prem, транзитивно. PrivateLink — доступ до одного конкретного сервісу, односторонній, CIDR можуть перетинатися.
Site-to-Site VPN vs Direct Connect: VPN — через інтернет, шифрування IPsec, налаштування за хвилини, дешево. DX — приватний канал, стабільна швидкість, прокладання тижнями, шифрування окремо (VPN поверх DX або MACsec).
CloudFront vs Global Accelerator: CloudFront — кеш HTTP-контенту на edge. Global Accelerator — без кешу, TCP/UDP, 2 статичні IP, швидкий failover між регіонами.
ALB vs NLB vs GWLB: ALB — рівень 7, роутинг HTTP за шляхом і хостом, Lambda як ціль. NLB — рівень 4, TCP/UDP, статичні IP, мільйони запитів/с. GWLB — рівень 3, прогін трафіку через апарати безпеки.
Route 53 Geolocation vs Geoproximity vs Latency: Geolocation — за країною користувача. Geoproximity — за відстанню з можливістю змістити трафік (bias). Latency — до регіону з найменшою затримкою.
Обчислення
Lambda vs Fargate vs EC2 vs Batch: Lambda — подієві задачі до 15 хв. Fargate — контейнери без серверів, без ліміту часу. EC2 — повний контроль, особливі вимоги (GPU, ліцензії, ОС). Batch — черги пакетних задач будь-якої тривалості.
ECS vs EKS: ECS — простіше, «рідне» для AWS. EKS — Kubernetes (вже є K8s, портативність).
Spot vs Reserved vs Savings Plans vs On-Demand: Spot — до 90%, може перерватися. RI/SP — 1–3 роки, до ~72%, для постійного навантаження. On-Demand — без зобов'язань, найдорожче.
Dedicated Host vs Dedicated Instance: Host — видно фізичний сервер, сокети і ядра (BYOL). Instance — лише ізоляція обладнання.
Scheduled vs Predictive vs Target tracking: Scheduled — відомий час піку. Predictive — ML за історією циклів. Target tracking — тримати метрику на рівні.
Elastic Beanstalk vs CloudFormation: Beanstalk — PaaS для розгортання застосунку. CloudFormation — IaC для будь-якої інфраструктури.
Сховище
S3 vs EBS vs EFS vs FSx vs Instance store: S3 — об'єкти, необмежено, доступ по HTTP. EBS — блочний диск, одна AZ. EFS — спільні файли NFS для Linux у кількох AZ. FSx — Windows (SMB) / Lustre (HPC) / ONTAP (NFS + SMB + iSCSI) / OpenZFS. Instance store — ефемерний локальний диск.
DataSync vs Storage Gateway vs Transfer Family vs Snowball: DataSync — перенесення мережею. Storage Gateway — постійний гібридний доступ з кешем. Transfer Family — SFTP/FTP для партнерів. Snowball — фізичне офлайн-перенесення.
Volume Gateway Cached vs Stored: Cached — основні дані в S3, кеш локально. Stored — усе локально, бекап в S3.
Object Lock Compliance vs Governance: Compliance — не обійде ніхто, навіть root. Governance — можуть обійти користувачі з окремим дозволом.
CloudFront signed URL vs signed cookies vs S3 presigned URL: signed URL — один файл через CloudFront. Signed cookies — багато файлів через CloudFront. Presigned URL — напряму до одного об'єкта S3.
OAC vs OAI: OAC — сучасний спосіб закрити S3 за CloudFront (підтримує SSE-KMS). OAI — застарілий.
Бази даних
RDS Multi-AZ vs Read Replica: Multi-AZ — синхронна копія, HA, standby не читається. Read replica — асинхронна, масштабування читання, можна в іншому регіоні.
Aurora Global Database vs Cross-Region Read Replica: Global DB — реплікація сховища < 1 с, RTO < 1 хв. Cross-region replica — логічна, від секунд до хвилин.
DAX vs ElastiCache: DAX — лише для DynamoDB, код майже не змінюється. ElastiCache — для будь-якої БД, логіку кешу пише застосунок.
Redis/Valkey vs Memcached: Redis — реплікація, Multi-AZ, persistence, складні структури. Memcached — простий багатопотоковий кеш без реплікації.
Athena vs Redshift vs EMR: Athena — serverless SQL по S3 для разових запитів. Redshift — сховище даних для важкої регулярної BI-аналітики. EMR — кластери Spark/Hadoop.
Enhanced Monitoring vs Performance Insights (RDS): Enhanced Monitoring — метрики ОС (до 1 с). Performance Insights — які SQL-запити навантажують БД.
Kinesis Data Streams vs MSK: KDS — «рідний» сервіс AWS з shards. MSK — керований Apache Kafka для наявних Kafka-застосунків.
Інтеграція і потоки
SQS vs SNS vs EventBridge vs Kinesis: SQS — черга, споживачі забирають (pull). SNS — pub/sub, розсилка (push). EventBridge — маршрутизація подій за правилами, SaaS, розклад. Kinesis — потоки даних у реальному часі з replay.
Kinesis Data Streams vs Firehose: KDS — реальний час, свої споживачі, replay. Firehose — near real-time доставка в сховища без коду.
SQS Standard vs FIFO: Standard — максимальна швидкість, можливі дублікати і зміна порядку. FIFO — суворий порядок і обробка рівно один раз.
Step Functions Standard vs Express: Standard — до 1 року, exactly-once, історія. Express — до 5 хв, великі обсяги, дешевше.
Безпека
Secrets Manager vs Parameter Store: Secrets Manager — автоматична ротація, реплікація між регіонами, платно. Parameter Store — без вбудованої ротації, standard tier безкоштовний.
KMS vs CloudHSM: KMS — керований сервіс, інтеграція з усіма сервісами AWS. CloudHSM — виділений апаратний модуль, повний контроль над ключами, FIPS 140 Level 3.
Cognito User Pool vs Identity Pool: User Pool — вхід користувачів (JWT). Identity Pool — тимчасові AWS-credentials.
IAM Identity Center vs Cognito: Identity Center — співробітники в акаунтах AWS і бізнес-застосунках. Cognito — клієнти твого застосунку.
Managed Microsoft AD vs AD Connector vs Simple AD: Managed AD — справжній AD в AWS з trust. AD Connector — проксі до on-prem AD. Simple AD — дешевий базовий, без trust.
CloudTrail vs Config vs CloudWatch: CloudTrail — хто і коли викликав API. Config — яка була конфігурація і чи відповідає вона правилам. CloudWatch — метрики, логи, аларми.
GuardDuty vs Inspector vs Macie vs Detective vs Security Hub: загрози / вразливості / чутливі дані в S3 / розслідування / єдина панель.
WAF vs Shield vs Network Firewall vs Firewall Manager: WAF — рівень 7 (HTTP). Shield — DDoS. Network Firewall — файрвол рівня VPC. Firewall Manager — централізоване керування всім цим в Organizations.
SCP vs Permission boundary vs IAM policy: SCP — стеля для цілих акаунтів/OU. Permission boundary — стеля для конкретного користувача або ролі. IAM policy — власне надає дозволи.
27Пастки, на яких найчастіше ловлять
⚠️ Найчастіші пастки
У Security Group немає Deny. Заблокувати IP → NACL або WAF.
Standby в RDS Multi-AZ (DB instance) не обслуговує читання.
Read replicas асинхронні — остання частина даних може бути ще не скопійована.
Gateway endpoint — лише S3 і DynamoDB і не працює з on-prem.
WAF не ставиться на NLB.
SCP не надає дозволів і не діє на management account.
Lambda — максимум 15 хвилин.
EBS прив'язаний до AZ; instance store втрачає дані при зупинці.
EFS — тільки Linux (NFS); для Windows — FSx for Windows File Server.
Шифрування існуючих RDS/EBS — лише через копію снапшота.
Сертифікат ACM для CloudFront — тільки в us-east-1.
CloudWatch не бачить RAM і місце на диску без агента.
IA- і Glacier-класи мають мінімальний термін оплати (30 / 90 / 180 днів) і мінімальний розмір об'єкта 128 KB (IA, Glacier Instant Retrieval).
Aurora Backtrack — лише MySQL.
SQS Standard може доставити повідомлення двічі і не за порядком.
VPC Peering нетранзитивний і не працює з перетином CIDR.
Route 53 health checks не бачать приватні ресурси напряму — потрібен CloudWatch alarm.
Direct Connect не шифрує трафік сам по собі.
Spot може бути перерваний з попередженням лише за 2 хвилини.
Сервіси «One Zone» (S3 One Zone-IA, Express One Zone, EFS One Zone) не переживуть втрату AZ.
«Свій скрипт на EC2 / cron» майже завжди програє керованому сервісу.
Presigned URL працює з правами того, хто його підписав, і не довше, ніж діють його облікові дані.
Класичний NAT Gateway стоїть у public subnet, а маршрут 0.0.0.0/0 на нього прописують у route table private subnet.
Cross-zone load balancing у NLB вимкнений за замовчуванням.
RDS не вміє автоматично додавати read replicas (Aurora вміє).
LSI у DynamoDB створюється лише разом з таблицею.
Трафік між AZ платний, навіть в одній VPC.
Снапшот, зашифрований AWS managed key, не можна віддати іншому акаунту — лише з customer managed key.
Route 53 alias на S3 website працює, лише якщо ім'я bucket збігається з доменом.
Lambda + SQS: visibility timeout черги має бути щонайменше в 6 разів більшим за timeout функції.
Restore RDS зі снапшота або PITR дає новий endpoint — застосунок треба переналаштувати.
28Що змінилося у 2024–2026 (нові цифри і назви)
На іспиті можуть траплятися старі цифри й назви — відповідай за логікою питання. Але знай актуальні:
S3: об'єкт до 50 TB (грудень 2025; раніше 5 TB).
SQS: повідомлення до 1 MiB (серпень 2025; раніше 256 KB).
SNS: повідомлення до 1 MiB за налаштуванням (вересень 2026; раніше 256 KB).
Aurora: сховище до 256 TiB (2025); Global Database — до 10 вторинних регіонів (травень 2025; раніше 5); Serverless v2 опускається до 0 ACU (листопад 2024).
DynamoDB Global Tables: strong consistency між регіонами (червень 2025).
Kinesis Data Streams: записи до 10 MiB (жовтень 2025; раніше 1 MiB).
Site-to-Site VPN: тунелі до 5 Gbps (листопад 2025; раніше 1,25 Gbps).
Regional NAT Gateway — один NAT на всю VPC (листопад 2025).
Database Savings Plans — до 35% на бази даних (грудень 2025).
Закриті для нових клієнтів: Snowball Edge, старий сервіс Amazon Glacier (vaults), S3 Object Lambda, Migration Hub, Application Discovery Service (з листопада 2025), FSx File Gateway (з жовтня 2024), S3 Select (з липня 2024). Elastic Transcoder закрито 13.11.2025 (заміна — Elemental MediaConvert). QLDB — кінець підтримки 31.07.2025.
Перейменування: QuickSight → Amazon Quick; SageMaker → SageMaker AI; Kinesis Data Firehose → Amazon Data Firehose; Kinesis Data Analytics → Managed Service for Apache Flink.
29Як готуватися: план на 14 днів і день іспиту
Як вчитися на цьому сайті
📘 Шпаргалка — прочитай розділ, потім увімкни «🙈 Сховати відповіді» і пройди тригери, торкаючись розмитої відповіді лише після того, як сам відповів. Позначай «Вивчено».
⚡ Швидко — лише тригери, пастки, порівняння і цифри. Для повторення в останні дні.
🗺️ Схеми — усі архітектурні схеми в одному місці.
🎲 Квіз — випадкові тригери; ті, що «не знав», повертаються частіше.
📝 Тест — 65 практичних питань у стилі іспиту: режим «Тренування» (пояснення одразу) і «Іспит» (таймер, результат у кінці).
Прогрес зберігається в браузері телефона. Сайт працює і без інтернету, якщо хоч раз відкрити його онлайн. На телефоні його можна додати на головний екран як застосунок.
План на 14 днів (1–2 години на день)
День
Що вчити
Практика
1
Розділи 1–3: іспит, тактика, основи
Квіз: 20 тригерів
2
4–5: IAM, шифрування
Квіз по розділах 4–5
3
6: сервіси безпеки
Тест: набір «Безпека» у режимі «Тренування»
4
7: VPC і мережа, схеми VPC і гібриду
Квіз по розділу 7
5
8–9: Route 53, CloudFront, Global Accelerator, ELB, Auto Scaling
Квіз по розділах 8–9
6
10–11: EC2, serverless, контейнери
Квіз по розділах 10–11
7
12: SQS, SNS, EventBridge, Step Functions
«⚡ Швидко» по днях 1–6
8
13–14: S3, EBS, EFS, FSx
Тест: набір «Продуктивність»
9
15–17: міграція, RDS, Aurora
Квіз по розділах 15–17
10
18–19: DynamoDB, кеш, інші БД
Тест: набір «Відмовостійкість»
11
20–22: аналітика, ML, моніторинг
Квіз по розділах 20–22
12
23–25: DR, вартість, цифри
Тест: набір «Вартість»
13
Повний тест у режимі «Іспит» (130 хв)
Розібрати кожну помилку
14
26–28: порівняння, пастки, зміни
«Мої помилки» в тесті + «⚡ Швидко»
Якщо стабільно набираєш 80%+ у практичних тестах — записуйся на іспит.
Додатково: офіційний безкоштовний набір питань AWS (Official Practice Question Set) у AWS Skill Builder; популярні платні тести — Tutorials Dojo.
Подай запит ESL +30 хвилин до запису на іспит.
День іспиту: чек-лист
Документ: паспорт або інше посвідчення з фото; ім'я має збігатися з ім'ям у профілі AWS Certification.
Онлайн-іспит (Pearson VUE, OnVUE): заздалегідь пройди перевірку системи (system test) на тому самому комп'ютері й мережі. Check-in відкривається за 30 хв до початку. Потрібні тиха окрема кімната, чистий стіл, телефон поза досяжністю; кімнату фотографуєш під час check-in.
Під час онлайн-іспиту перерв, як правило, немає — підготуйся заздалегідь. Говорити вголос і виходити з кадру не можна. Нотатки — лише на вбудованій цифровій дошці (whiteboard).
У центрі тестування приходь раніше; речі залишаєш у шафці, для нотаток дають дошку.
Тактика: ~2 хв на питання. Не знаєш — познач (flag), дай найкращу відповідь, повернися в кінці. Відповідай на всі питання, бо штрафу немає.
Спершу читай останнє речення питання, шукай ключові слова: MOST cost-effective, LEAST operational overhead, highly available, real-time.
Результат прийде на email і в кабінет, зазвичай за кілька годин (до 5 робочих днів).