Модуль 1.2: Virtual Private Cloud (VPC) та основні мережі

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Модуль 1.1, Мережі Linux

Чому цей модуль важливий

У 2018 році велика криптовалютна біржа виявила несанкціонований доступ до своїх внутрішніх інструментів адміністрування. Зловмисники повністю обійшли зовнішній файрвол веб-застосунків. Як? Інженерна команда розгорнула тимчасовий екземпляр EC2 для тестування нового скрипта міграції бази даних. Щоб було простіше підключатися по SSH, вони приєднали групу безпеки, яка дозволяла порт 22 з 0.0.0.0/0, і розмістили сервер у публічній підмережі, фактично виставивши сервер з обліковими даними адміністратора бази даних прямо в публічний інтернет. Зловмисники підібрали SSH-ключ за лічені години, перейшли в приватні підмережі, де зберігалися основні бази даних, і спричинили масштабний локальний збій, намагаючись викрасти дані.

Цей сценарій підкреслює безжальну природу хмарних мереж. Amazon Virtual Private Cloud (VPC) — це межа логічної ізоляції для вашої інфраструктури AWS. Це ваш приватний зріз хмари. Без правильно спроєктованої архітектури VPC ваші бази даних знаходяться на відстані однієї помилки в конфігурації від публічного інтернету, а внутрішній трафік відкритий для горизонтального переміщення зловмисників.

У цьому модулі ви навчитеся проєктувати стійку, високонадійну мережеву топологію. Ви зрозумієте критичну різницю між публічними та приватними підмережами, опануєте логіку маршрутизації, яка керує потоками трафіку, і навчитеся впроваджувати ешелонований захист за допомогою Security Groups та Network ACL. Нарешті, ви дізнаєтеся, як з’єднувати кілька VPC у масштабі. Опанування VPC — це не просто з’єднання серверів; це будівництво ровів, стін та мостів, які захищають увесь ваш хмарний ландшафт.

Анатомія VPC: Блоки CIDR та підмережі

VPC — це логічно ізольована віртуальна мережа, визначена основним блоком Classless Inter-Domain Routing (CIDR) IPv4 (наприклад, 10.0.0.0/16). Цей блок визначає загальний пул IP-адрес, доступних у межах VPC.

Думайте про нотацію CIDR як про вибір розміру вашої земельної ділянки перед тим, як ви почнете на ній щось будувати. Число після косої риски вказує, скільки бітів адреси є фіксованими (частина “мережі”), а решта бітів залишається для призначення окремим ресурсам (частина “хоста”).

Швидка довідка з CIDR

CIDR	Усього IP	Доступно IP (AWS)	Типове використання
`/16`	65,536	Варіюється*	Велика продуктова VPC
`/20`	4,096	4,091	Середня VPC або велика підмережа
`/24`	256	251	Стандартна підмережа
`/28`	16	11	Мінімальна підмережа (найменша в AWS)

AWS дозволяє блоки CIDR для VPC від /16 (найбільший) до /28 (найменший). Ви також можете додавати вторинні блоки CIDR до існуючої VPC, якщо у вас закінчиться адресний простір, але планування заздалегідь завжди краще, ніж переробка пізніше.

Планування IP має більше значення, ніж ви думаєте. Якщо ви плануєте з’єднувати VPC через піринг або Transit Gateway, їхні блоки CIDR не повинні перетинатися. Найпоширеніший жаль команд при масштабуванні: “ми використовували 10.0.0.0/16 для кожної VPC, і тепер не можемо їх з’єднати”. Плануйте схему без перетинів з першого дня:

Production VPC:   10.1.0.0/16
Staging VPC:      10.2.0.0/16
Development VPC:  10.3.0.0/16
Shared Services:  10.10.0.0/16

Підмережі (Subnets): Нарізка мережі

Ви не можете запустити екземпляр EC2 безпосередньо у VPC. Ви повинні запустити його в Підмережі (Subnet). Підмережі — це менші блоки IP-адрес, вирізані з діапазону CIDR вашої VPC.

Важливо: підмережа повинна повністю знаходитися в межах однієї зони доступності (AZ). Вона не може охоплювати кілька AZ. Щоб досягти високої доступності, ви повинні розгортати ресурси в кількох підмережах, розташованих у різних AZ.

VPC: 10.0.0.0/16 (65,536 IP)
├── Зона доступності: us-east-1a
│   ├── Subnet A (Публічна): 10.0.1.0/24  (251 доступний IP)
│   ├── Subnet B (Приватна): 10.0.2.0/24  (251 доступний IP)
│   └── Subnet C (Дані):    10.0.3.0/24  (251 доступний IP)
├── Зона доступності: us-east-1b
│   ├── Subnet D (Публічна): 10.0.11.0/24 (251 доступний IP)
│   ├── Subnet E (Приватна): 10.0.12.0/24 (251 доступний IP)
│   └── Subnet F (Дані):    10.0.13.0/24 (251 доступний IP)
└── Зона доступності: us-east-1c
    ├── Subnet G (Публічна): 10.0.21.0/24 (251 доступний IP)
    ├── Subnet H (Приватна): 10.0.22.0/24 (251 доступний IP)
    └── Subnet I (Дані):    10.0.23.0/24 (251 доступний IP)

Навіщо три рівні? Продуктові архітектури зазвичай розділяють навантаження на шари:

Публічні підмережі — Балансувальники навантаження, бастіон-хости, шлюзи NAT.
Приватні підмережі — Сервери застосунків, контейнери, обчислювальні ресурси.
Підмережі даних — Бази даних (RDS, ElastiCache), конфіденційні сховища.

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

Зарезервовані IP в AWS: AWS резервує перші 4 та останню 1 IP-адресу в кожній підмережі для внутрішніх мережевих цілей. У підмережі /24 (256 IP) зарезервовані адреси такі:

.0 — Адреса мережі.

.1 — Роутер VPC.

.2 — Зарезервовано (DNS-сервер знаходиться за адресою: база VPC + 2, напр. 10.0.0.2).

.3 — Зарезервовано для майбутнього використання.

.255 — Широкомовна адреса (AWS не підтримує broadcast, але резервує її).

Це дає вам 251 доступну адресу, а не 256.

Маршрутизація: Як трафік знаходить шлях

Кожна підмережа у VPC пов’язана рівно з однією Таблицею маршрутизації (Route Table). Таблиця маршрутизації — це набір правил (маршрутів), які визначають, куди спрямовується мережевий трафік. Якщо ви явно не пов’яжете підмережу з таблицею, вона використовуватиме Основну таблицю маршрутизації (Main Route Table) вашої VPC.

Основна таблиця маршрутизації

Кожна VPC постачається з основною таблицею, що містить один маршрут:

Призначення	Ціль	Мета
`10.0.0.0/16`	`local`	Увесь трафік у межах VPC залишається внутрішнім

Цей маршрут local є незмінним — ви не можете його видалити або змінити. Він гарантує, що будь-який ресурс у VPC може спілкуватися з будь-яким іншим ресурсом у цій же VPC (за умови дотримання правил Security Groups та NACL).

Публічні vs Приватні підмережі: Різниця в таблиці маршрутів

Що робить підмережу “публічною” чи “приватною”? Це не прапорець конфігурації в самій підмережі. Немає галочки “Зробити цю підмережу публічною”. Різниця визначається виключно Таблицею маршрутизації, пов’язаною з підмережею.

Публічна підмережа: Підмережа є публічною, якщо її таблиця маршрутів має запис, що спрямовує трафік в інтернет (0.0.0.0/0) до Інтернет-шлюзу (IGW). IGW — це високонадійний компонент VPC, що масштабується горизонтально і забезпечує зв’язок із публічним інтернетом.
Приватна підмережа: Підмережа є приватною, якщо вона не має маршруту до IGW. Екземпляри тут не можуть бути досягнуті з публічного інтернету, навіть якщо їм призначено публічні IP-адреси.

Ось як виглядають таблиці маршрутів поруч:

Таблиця маршрутів публічної підмережі:

Призначення	Ціль
`10.0.0.0/16`	`local`
`0.0.0.0/0`	`igw-abc123`

Таблиця маршрутів приватної підмережі:

Призначення	Ціль
`10.0.0.0/16`	`local`
`0.0.0.0/0`	`nat-xyz789`

Таблиця маршрутів підмережі даних (найбільш обмежена):

Призначення	Ціль
`10.0.0.0/16`	`local`

Зверніть увагу: рівень даних взагалі не має маршруту в інтернет. Ні через IGW, ні через NAT. Повна ізоляція.

Потік трафіку: Публічна підмережа

Ось як запит з інтернету потрапляє до екземпляра EC2 у публічній підмережі:

Користувач в інтернеті
      │
      ▼
┌──────────────┐
│ Інтернет-    │
│ шлюз (IGW)   │
└──────┬───────┘
       │  Таблиця маршрутів: 10.0.0.0/16 → local
       ▼
┌──────────────────────────────────────────┐
│         NACL (Межа підмережі)            │
│  Оцінює вхідні правила послідовно        │
└──────────────────┬───────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────┐
│      Security Group (Рівень екземпляра)  │
│  Перевірка: Чи дозволено порт 443?       │
└──────────────────┬───────────────────────┘
                   │
                   ▼
            ┌─────────────┐
            │ Екземпляр EC2│
            │ 10.0.1.10   │
            │ (Публічна IP:│
            │  54.x.x.x)  │
            └─────────────┘

Зворотний трафік іде тим самим шляхом. Оскільки Security Groups працюють зі збереженням стану (stateful), відповідь дозволяється автоматично. Але якщо на шляху є NACL, ви повинні мати явні вихідні правила (NACL працюють без збереження стану — stateless).

Інтернет-шлюз (IGW)

IGW заслуговує на окрему увагу, бо його часто розуміють неправильно:

Він виконує 1:1 NAT між приватною IP-адресою екземпляра та його публічною/Elastic IP адресою.
Він не є “вузьким місцем” — він масштабується горизонтально і є надлишковим за дизайном.
Він не накладає обмежень на пропускну здатність (ліміт іде від типу вашого екземпляра).
Ви можете приєднати тільки один IGW на одну VPC.
Створення самого IGW нічого не дає — ви також повинні приєднати його до VPC і додати маршрут до нього.

Шлюзи NAT: Вихідний доступ для приватних ресурсів

Якщо базі даних у приватній підмережі потрібно завантажити патчі безпеки з інтернету, або серверу застосунків потрібно викликати зовнішній API, як це зробити без маршруту до IGW?

Рішенням є Шлюз NAT (Network Address Translation Gateway).

Як працює NAT Gateway

Ви розгортаєте NAT Gateway у публічній підмережі (йому потрібен доступ до IGW).
Ви виділяєте Elastic IP адресу та призначаєте її шлюзу NAT.
Ви налаштовуєте таблицю маршрутів приватної підмережі так, щоб спрямовувати трафік в інтернет (0.0.0.0/0) на NAT Gateway.
NAT Gateway отримує трафік, транслює приватну IP в свою Elastic IP, передає трафік через IGW, отримує відповідь, транслює її назад і надсилає приватному екземпляру.

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

Потік трафіку через NAT Gateway

Приватний екземпляр (10.0.2.50)
      │
      │ Вихідний запит до https://api.example.com
      ▼
┌──────────────────────────────────────────┐
│  Таблиця маршрутів приватної підмережі   │
│  0.0.0.0/0 → nat-xyz789                 │
└──────────────────┬───────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────┐
│          NAT Gateway                     │
│  (Знаходиться в ПУБЛІЧНІЙ підмережі)     │
│  Транслює: 10.0.2.50 → 52.x.x.x (EIP)   │
└──────────────────┬───────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────┐
│  Таблиця маршрутів публічної підмережі   │
│  0.0.0.0/0 → igw-abc123                 │
└──────────────────┬───────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────┐
│          Інтернет-шлюз                   │
└──────────────────┬───────────────────────┘
                   │
                   ▼
            ┌─────────────┐
            │  Інтернет   │
            │ api.example │
            │   .com      │
            └─────────────┘

Відповідь іде точно зворотним шляхом. IGW надсилає її на Elastic IP шлюзу NAT, той транслює адресу призначення назад у 10.0.2.50 і доставляє приватному екземпляру.

NAT Gateway: Патерн високої доступності

Один NAT Gateway знаходиться в одній AZ. Якщо ця AZ вийде з ладу, усі приватні підмережі, що маршрутизуються через нього, втратять доступ до інтернету. Для продуктових навантажень розгортайте по одному NAT Gateway на кожну AZ:

AZ-1a: NAT-GW-1 (у Public-Subnet-1a) ← Private-Subnet-1a маршрутизується сюди
AZ-1b: NAT-GW-2 (у Public-Subnet-1b) ← Private-Subnet-1b маршрутизується сюди
AZ-1c: NAT-GW-3 (у Public-Subnet-1c) ← Private-Subnet-1c маршрутизується сюди

Таблиця маршрутів кожної приватної підмережі вказує на NAT Gateway у своїй же AZ. Це робить кожну зону доступності автономною для виходу в інтернет.

NAT Gateway vs NAT Instance

До появи NAT Gateway як керованого сервісу команди запускали власний NAT на екземплярах EC2. Ви все ще можете зустріти це у застарілих середовищах:

Функція	NAT Gateway	NAT Instance
Керується	AWS	Вами
Доступність	Надлишковий у межах AZ	Один екземпляр (ви керуєте failover)
Пропускна здатність	До 100 Гбіт/с	Залежить від типу екземпляра
Обслуговування	Немає	Ви патчите ОС та ПЗ
Security Groups	Не можна приєднати	Можна приєднати
Вартість	~$0.045/год + трафік	Вартість екземпляра + трафік
Використовувати зараз?	Так (рекомендовано)	Тільки для дуже специфічних випадків

VPC Endpoints: Обхід NAT

Для трафіку до сервісів AWS (S3, DynamoDB, SQS тощо) вам часто взагалі не потрібен NAT. VPC Endpoints створюють приватне з’єднання з вашої VPC безпосередньо до сервісу AWS, тримаючи трафік у внутрішній мережі AWS:

Gateway Endpoint (S3, DynamoDB): Безкоштовно. Додає маршрут у вашу таблицю маршрутизації. Не потребує ENI.
Interface Endpoint (усе інше, через PrivateLink): Створює ENI у вашій підмережі. Коштує ~$0.01/год + плата за обробку даних.

Використання VPC Endpoints для сервісів з великим трафіком, як-от S3, може заощадити тисячі доларів на місяць на оплаті трафіку через NAT Gateway.

Мережева безпека: Security Groups vs NACL

AWS надає два окремі рівні захисту файрволом у межах VPC. Розуміння різниці є критичним для відлагодження проблем зі зв’язком — це одна з найпопулярніших тем на сертифікаціях AWS.

Security Groups (SG)

Security Groups діють як stateful файрволи на рівні екземпляра.

Приєднання: Приєднуються безпосередньо до мережевих інтерфейсів (ENI), таких як на екземплярах EC2, базах даних RDS, Lambda-функціях у VPC або вузлах ELB.
Збереження стану (Stateful): Якщо ви надсилаєте вихідний запит з екземпляра, вхідний трафік-відповідь дозволяється автоматично, незалежно від вхідних правил. Вам не потрібно думати про ефемерні порти.
Правила: Ви вказуєте тільки дозволяючі (Allow) правила. Будь-який трафік, не дозволений явно, забороняється неявно. У Security Group неможливо написати правило “Deny”.
Оцінка: Всі правила оцінюються разом перед прийняттям рішення про дозвіл (порядок не має значення).
Ланцюжки: Замість IP-адрес SG можуть посилатися на інші SG. Ви можете налаштувати SG бази даних так: “дозволити трафік на порт 3306 від веб-SG”, що автоматично підтримує автомасшабування без управління IP-адресами.
Ліміт: До 5 SG на один ENI. Кожна SG може мати до 60 вхідних + 60 вихідних правил.

Приклад: Архітектура ланцюжка Security Groups

Інтернет
    │
    ▼
┌───────────────────────────┐
│  Security Group для ALB   │
│  Вхід: 443 з 0.0.0.0/0    │
└─────────┬─────────────────┘
          │
          ▼
┌───────────────────────────┐
│  Security Group додатка   │
│  Вхід: 8080 з sg-alb      │
└─────────┬─────────────────┘
          │
          ▼
┌───────────────────────────┐
│  Security Group для БД    │
│  Вхід: 5432 з sg-app      │
└───────────────────────────┘

Кожен рівень довіряє тільки рівню безпосередньо над ним. Якщо зловмисник скомпрометує ALB, він все одно не зможе дістатися до бази даних напряму, бо SG бази даних дозволяє з’єднання тільки від sg-app, а не від sg-alb.

Network Access Control Lists (NACL)

NACL діють як stateless файрволи на рівні підмережі.

Приєднання: Приєднуються до межі підмережі. Увесь трафік, що входить або виходить з підмережі, повинен пройти через NACL перед тим, як потрапити до будь-якої Security Group.
Без збереження стану (Stateless): Трафік-відповідь має бути дозволений явно. Якщо ви дозволяєте вихідний HTTP-трафік в інтернет, ви повинні створити відповідне вхідне правило, що дозволяє трафік на ефемерних портах (1024-65535), щоб відповідь могла потрапити в підмережу.
Правила: Підтримують як Allow, так і Deny правила, що оцінюються по порядку згідно з їхніми номерами (менші номери оцінюються першими). Як тільки знайдено збіг, оцінка зупиняється.
NACL за замовчуванням: Кожна VPC має стандартний NACL, який дозволяє весь вхідний та вихідний трафік. Власні NACL спочатку забороняють усе.
Сценарій використання: В основному використовуються як другий рівень захисту, наприклад, для негайного блокування конкретного діапазону шкідливих IP-адрес на вході в підмережу.

Security Groups vs NACL: Повне порівняння

Функція	Security Group	Network ACL
Діє на рівні	Екземпляра (ENI)	Підмережі
Стан	Stateful (зберігає стан)	Stateless (без стану)
Тип правил	Тільки Allow	Allow ТА Deny
Оцінка правил	Усі разом	По порядку (від меншого номера)
Поведінка за замовч.	Забороняє вхід, дозв. вихід	Стандартний — все дозв., власні — все забор.
Трафік-відповідь	Дозволяється автоматично	Має бути дозволений явно (ефемерні порти!)
Застосовується до	Тільки призначених ресурсів	Усіх ресурсів у підмережі
Посилання на SG	Може посилатися на інші SG	Не може (тільки IP/CIDR)
Ліміт правил	60 вхідних + 60 вихідних	20 вхідних + 20 вихідних
Типове використ.	Основний файрвол для ресурсів	Блокування IP на рівні підмережі

Ешелонований захист: Спільна робота обох рівнів

                      Інтернет
                          │
                          ▼
              ┌───────────────────┐
              │  Інтернет-шлюз    │
              └─────────┬─────────┘
                        │
           ┌────────────▼────────────┐
           │    NACL (Рівень підмережі)│ ← Шар 1: Блокування поганих IP,
           │    Правило 10: DENY     │   загальна політика підмережі
           │      198.51.100.0/24    │
           │    Правило 100: ALLOW ALL│
           └────────────┬────────────┘
                        │
           ┌────────────▼────────────┐
           │  Security Group (ENI)   │ ← Шар 2: Гранулярний контроль
           │  Allow: 443 з 0.0.0.0/0 │   для кожного ресурсу
           │  Allow: 22 з 10.0.0.0/16│
           └────────────┬────────────┘
                        │
                        ▼
                  ┌───────────┐
                  │    EC2    │
                  └───────────┘

Повчальна історія: Молодший інженер змінив NACL приватної підмережі бази даних, забувши, що NACL працюють без збереження стану. Він додав вихідне правило, що дозволяло трафік до веб-підмережі, але забув додати вхідне правило для відповіді на ефемерних портах. Раптом веб-сервери почали повідомляти про масові помилки таймауту бази даних, хоча Security Groups були налаштовані ідеально. SG справно пропускали трафік (stateful!), але NACL тихо відкидав пакети-відповіді на межі підмережі. Знадобилося дві години дебагу, перш ніж хтось здогадався перевірити NACL. Stateful SG прощають помилки; stateless NACL вимагають ювелірної точності.

VPC Flow Logs: Бачити свій трафік

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

IP-адреси джерела та призначення.
Порти джерела та призначення.
Протокол (TCP, UDP, ICMP).
Кількість пакетів та байтів.
Чи був трафік дозволений (ACCEPT) чи відхилений (REJECT).
Дія, вчинена SG або NACL.

Flow Logs можна ввімкнути на трьох рівнях:

Рівень VPC — Фіксує трафік для всіх ENI у VPC.
Рівень підмережі — Фіксує трафік для всіх ENI в підмережі.
Рівень ENI — Фіксує трафік для конкретного мережевого інтерфейсу.

Логи можуть публікуватися у CloudWatch Logs, S3 або Kinesis Data Firehose.

Читання запису Flow Log

2 123456789012 eni-abc123 10.0.1.50 203.0.113.25 443 49152 6 25 5000 1620140761 1620140821 ACCEPT OK

Поле	Значення	Значення
Version	`2`	Версія Flow log
Account ID	`123456789012`	Акаунт AWS
ENI	`eni-abc123`	Мережевий інтерфейс
Source IP	`10.0.1.50`	Звідки прийшов трафік
Dest IP	`203.0.113.25`	Куди він ішов
Dest Port	`443`	HTTPS
Source Port	`49152`	Ефемерний порт (клієнт)
Protocol	`6`	TCP
Packets	`25`	Кількість пакетів
Bytes	`5000`	Усього байтів
Start	`1620140761`	Unix timestamp початку
End	`1620140821`	Unix timestamp кінця
Action	`ACCEPT`	Трафік було дозволено
Status	`OK`	Логування працює

Якщо ви бачите REJECT у полі action, ви знаєте, що або Security Group, або NACL заблокували трафік. Flow Logs — це ваша перша зупинка при пошуку відповіді на питання “Чому я не можу підключитися до X?”.

З’єднання VPC: Peering та Transit Gateway

У міру зростання інфраструктури ізоляція навантажень між кількома акаунтами AWS та кількома VPC стає стандартним архітектурним патерном. Як їх з’єднати?

VPC Peering

VPC Peering — це мережеве з’єднання “один-до-одного” між двома VPC, яке дозволяє маршрутизувати трафік між ними за допомогою приватних IPv4 або IPv6 адрес.

Трафік повністю залишається у внутрішній мережі AWS (ніякої маршрутизації через інтернет).
Працює між різними акаунтами та різними регіонами.
Не є транзитивним: Якщо VPC A має піринг з VPC B, а VPC B — з VPC C, то VPC A не може спілкуватися з VPC C через B. Ви повинні створити пряме з’єднання між A та C.
CIDR не повинні перетинатися: Ви не зможете створити піринг, якщо блоки CIDR цих VPC хоча б частково збігаються.

Нетранзитивний піринг:

  VPC-A ◄──піринг──► VPC-B ◄──піринг──► VPC-C
    │                                   │
    └──── Не може дістатися! ───────────┘
           (Потрібен прямий піринг)

Кількість з’єднань: Для N VPC у топології “кожен з кожним” (full mesh) вам знадобиться N*(N-1)/2 з’єднань. Для 5 VPC це 10 з’єднань. Для 20 VPC це вже 190. Саме тут піринг стає некерованим.

AWS Transit Gateway (TGW)

Коли у вас десятки або сотні VPC, управління мережею пірингів перетворюється на операційне жахіття. Transit Gateway діє як центральний хаб, що масштабується (віртуальний роутер). Ви підключаєте всі ваші VPC, VPN та Direct Connect до центрального TGW. Домени маршрутизації та таблиці маршрутів на TGW керують потоками трафіку, радикально спрощуючи топологію.

VPC Peering (Full Mesh):          Transit Gateway (Hub-and-Spoke):

  VPC-A ──── VPC-B                  VPC-A ──┐
    │ \      / │                    VPC-B ──┤
    │  \    /  │                    VPC-C ──┼── Transit Gateway
    │   \  /   │                    VPC-D ──┤
    │    \/    │                    VPN   ──┘
  VPC-C ──── VPC-D
                                    4 підключення замість 6 пірингів
  6 з'єднань пірингу                Центральне управління маршрутами
  6 оновлень таблиць у кожній VPC   Одне оновлення таблиці на VPC

Transit Gateway підтримує:

До 5 000 підключень на один TGW.
Кілька таблиць маршрутизації для сегментації мережі (напр., Prod VPC не можуть бачити Dev VPC).
Міжрегіональний піринг (TGW-to-TGW).
Пропускну здатність до 50 Гбіт/с на кожне підключення VPC.

DNS у VPC: Route 53 Resolver

Кожна VPC має вбудований DNS-сервер за адресою: база CIDR вашої VPC + 2 (наприклад, 10.0.0.2 для VPC 10.0.0.0/16). Це називається Amazon-provided DNS або AmazonProvidedDNS.

За замовчуванням цей DNS-сервер:

Резолвить публічні DNS-імена в публічні IP.
Резолвить записи приватних хостинг-зон (якщо enableDnsHostnames та enableDnsSupport встановлені в true).
Резолвить внутрішні імена екземплярів (напр., ip-10-0-1-50.ec2.internal).

Для гібридних середовищ (з’єднання VPC з локальним дата-центром) Route 53 Resolver надає:

Inbound Endpoints: Дозволяють локальним DNS-серверам резолвити записи у ваших приватних зонах VPC.
Outbound Endpoints: Дозволяють ресурсам VPC пересилати DNS-запити на ваші локальні DNS-сервери.

Чи знали ви?

Коли ви створюєте NAT Gateway, з вас стягується як погодинна оплата (~$0.045/год, або ~~$32/місяць), так і плата за кожен гігабайт оброблених даних (~~$0.045/ГБ). Команда, що передає 10 ТБ на місяць через NAT Gateway, заплатить ~$450 тільки за обробку даних, на додачу до погодинної оплати. Масивні передачі даних через NAT Gateway можуть швидко стати однією з найдорожчих статей вашого рахунку AWS. Використовуйте VPC Endpoints (PrivateLink) для трафіку до сервісів AWS (як S3 чи DynamoDB) через внутрішню мережу, щоб уникнути витрат на NAT.
Інтернет-шлюз (IGW) не є фізичним пристроєм або єдиною точкою відмови; це горизонтально масштабований, надлишковий і високонадійний керований компонент AWS без обмежень пропускної здатності. Вам ніколи не потрібно “підбирати розмір” IGW або хвилюватися про його вихід з ладу — AWS бере це на себе.
VPC Flow Logs можуть фіксувати інформацію про IP-трафік, що проходить через мережеві інтерфейси у вашій VPC. Ці дані є неоціненними для аналізу безпеки та діагностики того, чому трафік не доходить до екземпляра. Один запис Flow Log може сказати вам, чи був трафік дозволений або відхилений, миттєво звужуючи пошук проблеми до Security Group, NACL або таблиці маршрутизації.
Ви можете ділитися підмережами між різними акаунтами AWS у межах організації за допомогою AWS Resource Access Manager (RAM). Це дозволяє мати центральний “Мережевий акаунт”, який керує VPC та підмережами, тоді як прикладні команди розгортають екземпляри в ці підмережі зі своїх власних акаунтів. Цей патерн (VPC sharing) радикально зменшує кількість VPC, якими потрібно керувати, і усуває потребу в пірингу між командами в одному середовищі.

Типові помилки

Помилка	Чому це стається	Як виправити
Перетин блоків CIDR	Створення кожної VPC зі стандартним `172.31.0.0/16` або постійне використання `10.0.0.0/16`.	Ретельно плануйте стратегію IP-адресації перед створенням будь-яких VPC. Документуйте призначення CIDR. Ви не зможете створити піринг, якщо блоки CIDR перетинаються.
Бази даних у публічних підмережах	”Мені потрібно підключитися до неї з ноутбука через DBeaver.”	Розгортайте бази даних у приватних підмережах. Використовуйте AWS Systems Manager Session Manager (SSM) або бастіон-хост у публічній підмережі для безпечного тунелювання трафіку до бази.
Security Groups, що дозволяють `0.0.0.0/0` без розбору	Спроба швидко змусити додаток працювати, вимкнувши файрвол.	Практикуйте принцип найменших привілеїв. Обмежуйте вхідний трафік конкретними діапазонами IP або, ще краще, посилайтеся на конкретні SG вищого рівня (наприклад, SG балансувальника).
NAT Gateways у приватних підмережах	Припущення, що NAT іде “разом” із приватними екземплярами, які він обслуговує.	NAT Gateway ПОВИНЕН знаходитися в публічній підмережі, щоб мати маршрут до Інтернет-шлюзу. Таблиця маршрутів приватної підмережі вказує на NAT Gateway.
Забування про ефемерні порти в NACL	Думка, що stateless NACL працюють як stateful Security Groups.	Якщо ви впроваджуєте суворі NACL, завжди переконуйтеся, що у вас є правила, які дозволяють вхідний зворотний трафік на портах `1024-65535`. Без них пакети-відповіді будуть тихо відкинуті.
Використання пірингу для full-mesh топологій	Це добре працює для 3 VPC, але стає некерованим для 15.	Переходьте на AWS Transit Gateway при з’єднанні більше ніж кількох VPC, щоб спростити маршрутизацію та управління.
NAT Gateway в одній AZ	Розгортання одного NAT Gateway та маршрутизація всіх приватних підмереж через нього.	Розгортайте по одному NAT Gateway на кожну AZ для продуктових навантажень. Якщо AZ з єдиним NAT Gateway вийде з ладу, усі приватні підмережі втратять інтернет.
Вимкнені VPC Flow Logs	”Ми ввімкнемо їх, коли щось піде не так.”	Вмикайте Flow Logs з першого дня. Ви не зможете заднім числом отримати трафік, який уже пройшов. Коли станеться інцидент, вам знадобляться історичні дані. Надсилайте їх в S3 для економного зберігання.

Тест

Питання 1: Ви запускаєте екземпляр EC2 у підмережі, приєднуєте Elastic IP (публічну IP) і переконуєтеся, що Security Group дозволяє вхідний SSH (порт 22). Проте ваше SSH-з'єднання обривається за таймаутом. Яка найбільш імовірна архітектурна причина?

Підмережа, в якій знаходиться екземпляр EC2, є Приватною підмережею. Хоча екземпляр має публічну IP-адресу, Таблиця маршрутизації підмережі не має маршруту до Інтернет-шлюзу (IGW). Без маршруту до IGW інтернет-трафік не може увійти в підмережу або вийти з неї. Виправлення: додати маршрут 0.0.0.0/0 → igw-xxx до таблиці маршрутів підмережі або перемістити екземпляр у підмережу, яка вже має такий маршрут.

Питання 2: Додатку в приватній підмережі потрібно завантажити логи в Amazon S3. Ви хочете зробити це безпечно, без проходження трафіку через публічний інтернет і без оплати за обробку даних у NAT Gateway. Що слід налаштувати?

Вам слід налаштувати VPC Gateway Endpoint для Amazon S3. Це створить приватне з’єднання з вашої VPC до сервісу S3, тримаючи весь трафік у внутрішній мережі AWS. Gateway endpoints безкоштовні і вимагають оновлення таблиці маршрутів, на відміну від Interface endpoints (PrivateLink), які використовують ENI та мають погодинну оплату. Запис у таблиці маршрутів виглядатиме так: pl-xxxxx (список префіксів S3) → vpce-xxx.

Питання 3: Веб-серверу А потрібно спілкуватися з Базою даних Б на порту 5432. Який найнадійніший спосіб налаштувати Security Group, приєднану до Бази даних Б?

Додайте вхідне правило до Security Group Бази даних Б, яке дозволяє TCP порт 5432, де джерелом (source) вказано ID Security Group, приєднаної до Веб-сервера А (наприклад, sg-0abcd1234). Це гарантує, що тільки ресурси, які мають SG Веб-сервера А, зможуть підключитися. Це рішення автоматично масштабується при додаванні або видаленні веб-серверів без необхідності керувати IP-адресами. Ніколи не використовуйте 0.0.0.0/0 або навіть CIDR вашої VPC як джерело для доступу до бази даних.

Питання 4: У вас є три VPC: Dev, Test та Prod. Dev з'єднана пірингом з Test. Test з'єднана пірингом з Prod. Чи може екземпляр EC2 у Dev напряму пінгувати екземпляр у Prod?

Ні. VPC Peering не є транзитивним. З’єднання між Dev та Test не поширюється на Prod. Щоб дозволити Dev спілкуватися з Prod, ви повинні встановити явне пряме пірингове з’єднання між Dev VPC та Prod VPC (або використовувати Transit Gateway як центральний хаб, який підтримує транзитивну маршрутизацію).

Питання 5: NACL має Правило #100, що дозволяє весь трафік з 0.0.0.0/0, та Правило #50, що забороняє весь трафік з 10.0.0.5/32. Екземпляр з адресою 10.0.0.5 намагається надіслати трафік у підмережу. Що станеться і чому?

Трафік буде заборонено. Правила NACL оцінюються послідовно, починаючи з найменшого номера правила. Правило #50 явно забороняє трафік з 10.0.0.5. Як тільки знайдено відповідне правило, оцінка негайно зупиняється, тому дозволяюче правило #100 ніколи не буде оброблено для цього конкретного трафіку. Ось чому нумерація правил важлива — завжди ставте правила Deny перед правилами Allow.

Питання 6: Чому вважається найкращою практикою розгортати VPC у кількох зонах доступності?

Висока доступність та відмовостійкість. Зона доступності (AZ) — це один або кілька окремих дата-центрів із резервним живленням, охолодженням та мережевим зв’язком. Якщо ціла AZ вийде з ладу через масштабну аварію інфраструктури (таке траплялося), ресурси, розгорнуті в інших AZ тієї ж VPC, продовжать працювати, забезпечуючи доступність додатка. Найкраща практика — використовувати мінімум 2 AZ, а для продуктових навантажень рекомендовано 3 AZ.

Питання 7: У вас є приватна підмережа з NAT Gateway для доступу в інтернет. Ви перевіряєте VPC Flow Logs і бачите, що трафік від вашого екземпляра до зовнішнього API має статус ACCEPTED, але додаток повідомляє про таймаути з'єднання. Що слід перевірити?

Статус ACCEPT у Flow Log означає, що Security Group та NACL дозволили трафік, але це не означає, що трафік справді дістався пункту призначення. Перевірте:

Таблицю маршрутів: Чи маршрутизує приватна підмережа 0.0.0.0/0 на NAT Gateway? Чи маршрутизує публічна підмережа шлюзу NAT 0.0.0.0/0 на IGW?
Статус NAT Gateway: Чи знаходиться він у стані available? Чи все ще прив’язана до нього Elastic IP?
Зворотний трафік у NACL: Чи дозволені вхідні ефемерні порти (1024-65535) у NACL приватної підмережі?
Зовнішній API: Чи доступний зовнішній API взагалі? Чи не блокує він Elastic IP вашого NAT Gateway?

Питання 8: У чому різниця між VPC Gateway Endpoint та VPC Interface Endpoint?

Gateway Endpoint: Доступна тільки для S3 та DynamoDB. Вона додає маршрут у вашу таблицю маршрутизації, що вказує на сервіс. Вона безкоштовна (немає погодинної оплати або плати за трафік). Вона не використовує ENI.

Interface Endpoint (PrivateLink): Доступна для більшості сервісів AWS та власних сервісів. Вона створює Elastic Network Interface (ENI) з приватною IP-адресою у вашій підмережі. Вона коштує ~$0.01/год за кожну AZ плюс плата за обробку даних. Вона підтримує Security Groups і надає DNS-ім’я для доступу до сервісу.

Використовуйте Gateway Endpoints, коли це можливо (S3, DynamoDB), бо вони безкоштовні. Використовуйте Interface Endpoints для всього іншого.

Практична вправа: Архітектура VPC промислового рівня

У цій вправі ви використаєте AWS CLI для побудови повноцінної, готової до продакшну VPC: вона охоплюватиме дві зони доступності, матиме публічні підмережі для балансувальників, приватні — для серверів застосунків, шлюзи NAT для вихідного доступу, багаторівневі групи безпеки та обмежувальний NACL.

Що ви побудуєте:

┌─────────────────────────────────────────────────────────────────┐
│  VPC: 10.0.0.0/16 (Dojo-Prod-VPC)                              │
│                                                                 │
│  ┌─────────── AZ: us-east-1a ───────────┐                      │
│  │ Публічна: 10.0.1.0/24  [ALB, NAT-GW] │                      │
│  │ Приватна: 10.0.10.0/24 [App Servers] │                      │
│  └───────────────────────────────────────┘                      │
│                                                                 │
│  ┌─────────── AZ: us-east-1b ───────────┐                      │
│  │ Публічна: 10.0.2.0/24  [ALB, NAT-GW] │                      │
│  │ Приватна: 10.0.20.0/24 [App Servers] │                      │
│  └───────────────────────────────────────┘                      │
│                                                                 │
│  Безпека: ALB-SG → App-SG → DB-SG (ланцюжок)                   │
│  NACL: Блокування поганих CIDR у приватних підмережах          │
│  Інтернет: IGW → Публічні підмережі → NAT-GW → Приватні        │
└─────────────────────────────────────────────────────────────────┘

Завдання 1: Створення VPC та увімкнення DNS

Спочатку встановимо мережеву межу.

# 1. Створення VPC (10.0.0.0/16)
VPC_ID=$(aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --query 'Vpc.VpcId' \
  --output text)

# 2. Назва VPC
aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=Dojo-Prod-VPC

# 3. Увімкнення DNS hostnames (необхідно для VPC Endpoints та приватного DNS)
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-hostnames '{"Value":true}'
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-support '{"Value":true}'

# 4. Перевірка
aws ec2 describe-vpcs --vpc-ids $VPC_ID \
  --query 'Vpcs[0].{VpcId:VpcId, CIDR:CidrBlock, State:State}' \
  --output table

Завдання 2: Створення та приєднання Інтернет-шлюзу

# 1. Створення Інтернет-шлюзу
IGW_ID=$(aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' \
  --output text)

# 2. Приєднання його до VPC
aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID

# 3. Додавання тегу
aws ec2 create-tags --resources $IGW_ID --tags Key=Name,Value=Dojo-Prod-IGW

echo "IGW $IGW_ID приєднано до VPC $VPC_ID"

Завдання 3: Створення підмереж у двох AZ

Ми створимо чотири підмережі: дві публічні та дві приватні, розподілені між двома зонами доступності.

# Визначте зони доступності (змініть, якщо ваш регіон за замовчуванням інший)
AZ1="us-east-1a"
AZ2="us-east-1b"

# --- Публічні підмережі ---

PUB_SUB1_ID=$(aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.1.0/24 \
  --availability-zone $AZ1 \
  --query 'Subnet.SubnetId' --output text)
aws ec2 create-tags --resources $PUB_SUB1_ID --tags Key=Name,Value=Public-Subnet-AZ1

PUB_SUB2_ID=$(aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.2.0/24 \
  --availability-zone $AZ2 \
  --query 'Subnet.SubnetId' --output text)
aws ec2 create-tags --resources $PUB_SUB2_ID --tags Key=Name,Value=Public-Subnet-AZ2

# --- Приватні підмережі ---

PRIV_SUB1_ID=$(aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.10.0/24 \
  --availability-zone $AZ1 \
  --query 'Subnet.SubnetId' --output text)
aws ec2 create-tags --resources $PRIV_SUB1_ID --tags Key=Name,Value=Private-Subnet-AZ1

PRIV_SUB2_ID=$(aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.20.0/24 \
  --availability-zone $AZ2 \
  --query 'Subnet.SubnetId' --output text)
aws ec2 create-tags --resources $PRIV_SUB2_ID --tags Key=Name,Value=Private-Subnet-AZ2

# Перевірка всіх підмереж
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[*].{SubnetId:SubnetId, AZ:AvailabilityZone, CIDR:CidrBlock, Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table

Завдання 4: Налаштування публічної маршрутизації

Основна таблиця маршрутів за замовчуванням є приватною. Ми створимо окрему таблицю для публічних підмереж.

# 1. Створення публічної таблиці маршрутів
PUB_RT_ID=$(aws ec2 create-route-table \
  --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-tags --resources $PUB_RT_ID --tags Key=Name,Value=Public-Route-Table

# 2. Додавання маршруту до Інтернет-шлюзу для всього зовнішнього трафіку
aws ec2 create-route \
  --route-table-id $PUB_RT_ID \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id $IGW_ID

# 3. Асоціація публічної таблиці з обома публічними підмережами
aws ec2 associate-route-table --subnet-id $PUB_SUB1_ID --route-table-id $PUB_RT_ID
aws ec2 associate-route-table --subnet-id $PUB_SUB2_ID --route-table-id $PUB_RT_ID

# 4. Увімкнення авто-призначення публічних IP для публічних підмереж
aws ec2 modify-subnet-attribute --subnet-id $PUB_SUB1_ID --map-public-ip-on-launch
aws ec2 modify-subnet-attribute --subnet-id $PUB_SUB2_ID --map-public-ip-on-launch

# 5. Перевірка таблиці маршрутів
aws ec2 describe-route-tables --route-table-ids $PUB_RT_ID \
  --query 'RouteTables[0].Routes[*].{Destination:DestinationCidrBlock, Target:GatewayId||NatGatewayId}' \
  --output table

Завдання 5: Налаштування шлюзів NAT для приватних підмереж

Для продуктового середовища розгорнемо по одному шлюзу NAT на AZ для високої доступності.

# 1. Виділення Elastic IP для шлюзів NAT
EIP1_ALLOC=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)
EIP2_ALLOC=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)

# 2. Створення шлюзу NAT у публічній підмережі AZ1
NAT1_ID=$(aws ec2 create-nat-gateway \
  --subnet-id $PUB_SUB1_ID \
  --allocation-id $EIP1_ALLOC \
  --query 'NatGateway.NatGatewayId' --output text)
aws ec2 create-tags --resources $NAT1_ID --tags Key=Name,Value=NAT-GW-AZ1

# 3. Створення шлюзу NAT у публічній підмережі AZ2
NAT2_ID=$(aws ec2 create-nat-gateway \
  --subnet-id $PUB_SUB2_ID \
  --allocation-id $EIP2_ALLOC \
  --query 'NatGateway.NatGatewayId' --output text)
aws ec2 create-tags --resources $NAT2_ID --tags Key=Name,Value=NAT-GW-AZ2

echo "Очікування доступності шлюзів NAT (~60 секунд)..."
aws ec2 wait nat-gateway-available --nat-gateway-ids $NAT1_ID $NAT2_ID
echo "Шлюзи NAT готові."

# 4. Створення приватної таблиці маршрутів для AZ1
PRIV_RT1_ID=$(aws ec2 create-route-table \
  --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-tags --resources $PRIV_RT1_ID --tags Key=Name,Value=Private-Route-Table-AZ1
aws ec2 create-route --route-table-id $PRIV_RT1_ID --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $NAT1_ID
aws ec2 associate-route-table --subnet-id $PRIV_SUB1_ID --route-table-id $PRIV_RT1_ID

# 5. Створення приватної таблиці маршрутів для AZ2
PRIV_RT2_ID=$(aws ec2 create-route-table \
  --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-tags --resources $PRIV_RT2_ID --tags Key=Name,Value=Private-Route-Table-AZ2
aws ec2 create-route --route-table-id $PRIV_RT2_ID --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $NAT2_ID
aws ec2 associate-route-table --subnet-id $PRIV_SUB2_ID --route-table-id $PRIV_RT2_ID

Попередження про витрати: Кожен шлюз NAT коштує ~$0.045/год. Два шлюзи, що працюють цілодобово, обійдуться у ~$65/місяць без урахування плати за трафік. Видаліть їх після завершення вправи!

Завдання 6: Налаштування багаторівневих Security Groups

Створимо ланцюжок із трьох груп безпеки: ALB, Додаток та База даних.

# --- Security Group для ALB (публічна) ---
ALB_SG_ID=$(aws ec2 create-security-group \
  --group-name Dojo-ALB-SG \
  --description "Allow HTTP/HTTPS from internet" \
  --vpc-id $VPC_ID \
  --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id $ALB_SG_ID --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id $ALB_SG_ID --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 create-tags --resources $ALB_SG_ID --tags Key=Name,Value=Dojo-ALB-SG

# --- SG Додатка (приймає трафік тільки від ALB) ---
APP_SG_ID=$(aws ec2 create-security-group \
  --group-name Dojo-App-SG \
  --description "Allow port 8080 from ALB only" \
  --vpc-id $VPC_ID \
  --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id $APP_SG_ID --protocol tcp --port 8080 --source-group $ALB_SG_ID
aws ec2 create-tags --resources $APP_SG_ID --tags Key=Name,Value=Dojo-App-SG

# --- SG Бази даних (приймає трафік тільки від рівня додатка) ---
DB_SG_ID=$(aws ec2 create-security-group \
  --group-name Dojo-DB-SG \
  --description "Allow port 5432 from App only" \
  --vpc-id $VPC_ID \
  --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id $DB_SG_ID --protocol tcp --port 5432 --source-group $APP_SG_ID
aws ec2 create-tags --resources $DB_SG_ID --tags Key=Name,Value=Dojo-DB-SG

# Перевірка ланцюжка
echo "=== ALB SG ==="
aws ec2 describe-security-groups --group-ids $ALB_SG_ID \
  --query 'SecurityGroups[0].IpPermissions[*].{Port:FromPort, Source:IpRanges[0].CidrIp||UserIdGroupPairs[0].GroupId}' \
  --output table
echo "=== App SG ==="
aws ec2 describe-security-groups --group-ids $APP_SG_ID \
  --query 'SecurityGroups[0].IpPermissions[*].{Port:FromPort, Source:UserIdGroupPairs[0].GroupId}' \
  --output table
echo "=== DB SG ==="
aws ec2 describe-security-groups --group-ids $DB_SG_ID \
  --query 'SecurityGroups[0].IpPermissions[*].{Port:FromPort, Source:UserIdGroupPairs[0].GroupId}' \
  --output table

Завдання 7: Створення кастомного NACL для приватних підмереж

Додамо NACL, що блокує відомий шкідливий діапазон IP, дозволяючи решту трафіку.

# 1. Створення кастомного NACL
NACL_ID=$(aws ec2 create-network-acl \
  --vpc-id $VPC_ID \
  --query 'NetworkAcl.NetworkAclId' --output text)
aws ec2 create-tags --resources $NACL_ID --tags Key=Name,Value=Private-Subnet-NACL

# 2. Додавання правила Deny для шкідливого CIDR (оцінюється першим через малий номер)
aws ec2 create-network-acl-entry --network-acl-id $NACL_ID \
  --rule-number 50 --protocol -1 --rule-action deny \
  --ingress --cidr-block 198.51.100.0/24

# 3. Додавання правила Allow для решти вхідного трафіку
aws ec2 create-network-acl-entry --network-acl-id $NACL_ID \
  --rule-number 100 --protocol -1 --rule-action allow \
  --ingress --cidr-block 0.0.0.0/0

# 4. Додавання правила Allow для всього вихідного трафіку
aws ec2 create-network-acl-entry --network-acl-id $NACL_ID \
  --rule-number 100 --protocol -1 --rule-action allow \
  --egress --cidr-block 0.0.0.0/0

# 5. Асоціація з приватними підмережами
aws ec2 replace-network-acl-association \
  --association-id $(aws ec2 describe-network-acls \
    --filters "Name=association.subnet-id,Values=$PRIV_SUB1_ID" \
    --query 'NetworkAcls[0].Associations[?SubnetId==`'$PRIV_SUB1_ID'`].NetworkAclAssociationId' \
    --output text) \
  --network-acl-id $NACL_ID

aws ec2 replace-network-acl-association \
  --association-id $(aws ec2 describe-network-acls \
    --filters "Name=association.subnet-id,Values=$PRIV_SUB2_ID" \
    --query 'NetworkAcls[0].Associations[?SubnetId==`'$PRIV_SUB2_ID'`].NetworkAclAssociationId' \
    --output text) \
  --network-acl-id $NACL_ID

echo "Кастомний NACL $NACL_ID асоційовано з приватними підмережами"

Завдання 8: Увімкнення VPC Flow Logs

# Створення групи логів CloudWatch для Flow Logs
aws logs create-log-group --log-group-name /vpc/dojo-prod-flow-logs

# Увімкнення VPC Flow Logs (потребує IAM ролі з дозволами — див. примітку нижче)
# У продакшні ви б створили IAM ролю. Для цієї вправи можна використати доставку в S3:
FLOW_LOG_ID=$(aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids $VPC_ID \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/dojo-prod-flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/VPCFlowLogRole \
  --query 'FlowLogIds[0]' --output text)

echo "Flow Logs увімкнено: $FLOW_LOG_ID"

Примітка: Команда create-flow-logs вимагає IAM-ролі, яка дозволяє сервісу VPC Flow Log публікувати дані в CloudWatch Logs. Якщо у вас немає такої ролі, ви можете пропустити це завдання або надіслати логи в S3-бакет за допомогою --log-destination-type s3 --log-destination arn:aws:s3:::ім'я-вашого-бакета.

Очищення

Важливо: Видаляйте ресурси у зворотній послідовності залежностей, щоб уникнути помилок. Шлюзи NAT видаляються 1-2 хвилини.

# 1. Видалення Flow Logs
aws ec2 delete-flow-logs --flow-log-ids $FLOW_LOG_ID
aws logs delete-log-group --log-group-name /vpc/dojo-prod-flow-logs

# 2. Видалення шлюзів NAT (це займає ~60с)
aws ec2 delete-nat-gateway --nat-gateway-id $NAT1_ID
aws ec2 delete-nat-gateway --nat-gateway-id $NAT2_ID
echo "Очікування видалення шлюзів NAT..."
sleep 60

# 3. Вивільнення Elastic IP
aws ec2 release-address --allocation-id $EIP1_ALLOC
aws ec2 release-address --allocation-id $EIP2_ALLOC

# 4. Видалення Security Groups (порядок не має значення, бо вони посилаються одна на одну за ID)
aws ec2 delete-security-group --group-id $DB_SG_ID
aws ec2 delete-security-group --group-id $APP_SG_ID
aws ec2 delete-security-group --group-id $ALB_SG_ID

# 5. Видалення кастомного NACL (підмережі повернуться до стандартного NACL)
aws ec2 delete-network-acl --network-acl-id $NACL_ID

# 6. Видалення маршрутів із приватних таблиць, а потім самих таблиць
aws ec2 delete-route --route-table-id $PRIV_RT1_ID --destination-cidr-block 0.0.0.0/0
aws ec2 delete-route --route-table-id $PRIV_RT2_ID --destination-cidr-block 0.0.0.0/0
aws ec2 delete-route --route-table-id $PUB_RT_ID --destination-cidr-block 0.0.0.0/0

# 7. Видалення підмереж (це автоматично від'єднає таблиці маршрутів)
aws ec2 delete-subnet --subnet-id $PUB_SUB1_ID
aws ec2 delete-subnet --subnet-id $PUB_SUB2_ID
aws ec2 delete-subnet --subnet-id $PRIV_SUB1_ID
aws ec2 delete-subnet --subnet-id $PRIV_SUB2_ID

# 8. Видалення таблиць маршрутизації
aws ec2 delete-route-table --route-table-id $PUB_RT_ID
aws ec2 delete-route-table --route-table-id $PRIV_RT1_ID
aws ec2 delete-route-table --route-table-id $PRIV_RT2_ID

# 9. Від'єднання та видалення IGW, потім видалення VPC
aws ec2 detach-internet-gateway --internet-gateway-id $IGW_ID --vpc-id $VPC_ID
aws ec2 delete-internet-gateway --internet-gateway-id $IGW_ID
aws ec2 delete-vpc --vpc-id $VPC_ID

echo "Усі ресурси очищено."

Критерії успіху

Я створив VPC з блоком CIDR /16 та увімкнув DNS hostnames.
Я розділив VPC на 4 підмережі у 2 зонах доступності.
Я створив Інтернет-шлюз та таблицю маршрутів, щоб зробити дві підмережі публічними.
Я розгорнув шлюзи NAT у кожній публічній підмережі для відмовостійкого виходу в інтернет із приватних підмереж.
Я створив окремі приватні таблиці маршрутів для кожної AZ, кожна з яких вказує на свій шлюз NAT.
Я впровадив трирівневу архітектуру ланцюжка Security Groups (ALB -> App -> DB).
Я створив кастомний NACL, що блокує конкретний діапазон CIDR у приватних підмережах.
Я увімкнув VPC Flow Logs для видимості трафіку.
Я успішно очистив усі ресурси, щоб уникнути зайвих витрат.

Наступний модуль

Коли мережевий фундамент закладено, настав час розгортати сервери в цих підмережах. Переходьте до Модуля 1.3: EC2 та обчислення.