Уявіть: команда запускає новий сервіс в AWS. Попереду розгортання застосунків, бази даних, внутрішні сервіси й інфраструктура, яка бажано має працювати не лише в день релізу. Тому, щоб усе було стабільно й безпечно, спершу потрібно збудувати надійний фундамент — мережу.
Перший ваш крок — створення приватного простору в AWS, а цей гайд стане надійним провідником у побудові мережевої архітектури.
1. Налаштування VPC
Що варто знати про VPC
VPC (Virtual Private Cloud) — це ізольована мережа всередині AWS, у якій можна розгортати й налаштовувати власну інфраструктуру: віртуальні машини, сервіси та правила доступу.
Після створення VPC ви отримуєте повний контроль над мережею та зможете:
- розділяти ресурси між public і private subnet;
- налаштовувати маршрутизацію між сервісами;
- керувати доступами до ресурсів усередині мережі;
- визначати, які сервіси матимуть вихід у зовнішню мережу;
- ізолювати внутрішні компоненти інфраструктури від зовнішнього трафіку.
Cтворюємо VPC
Перший важливий параметр під час створення VPC — CIDR block. Це діапазон IP-адрес, який використовуватиметься всередині мережі. Наприклад: 10.0.0.0/16.
Саме він стане основою для майбутньої структури subnet та всієї мережевої архітектури.
У більшості випадків AWS рекомендує використовувати приватні IPv4-адреси з маскою /16 або меншою — так мережу буде простіше масштабувати та ізолювати від зовнішнього трафіку.
Далі створимо VPC step by step:
- В AWS Console відкрийте вкладку Services та знайдіть сервіс VPC у секції Networking & Content Delivery.
- Після цього перейдіть у Your VPCs і натисніть кнопку Create VPC.
- На етапі створення мережі задайте її назву та вкажіть CIDR block — діапазон IP-адрес, який використовуватиметься всередині VPC. Наприклад: 10.0.0.0/16.
- Натисніть Create VPC, щоб завершити створення мережі.
- Після завершення AWS покаже ідентифікатор вашого VPC — VPC ID.
- Натисніть Close, щоб повернутися до списку VPC.
Тепер ваш VPC можна знайти у списку мереж у вкладці Your VPCs.
Уже на цьому етапі мережа отримує базові механізми для маршрутизації трафіку та контролю безпеки. Про їхні ролі ми ще поговоримо у цьому гайді.
2. Налаштування підмереж
VPC — це лише початок. Щоб мережа стала структурованою та керованою, її потрібно розділити на окремі підмережі (subnet).
Що варто знати про підмережі?
VPC охоплює всі зони доступу (availability zone) всередині обраного AWS регіону. Саме всередині цих зон і створюються підмережі — окремі сегменти з власним діапазоном IP-адрес.
Підмережі дозволяють розділяти ресурси всередині VPC, ізолювати сервіси та керувати тим, як між ними рухатиметься трафік.
Необхідно створити чотири підмережі оскільки:
- одна публічна;
- одна приватна;
- мережа працюватиме у двох availability zone, public і private subnet тому треба продублювати їх для кожної зони.
Підмережі розміщують у кількох зон доступу для відмовостійкості. Якщо одна із зон стане недоступною через збій у дата-центрі, інша продовжить роботу мережі.
Але перш ніж створювати підмережі важливо розуміти різницю між public і private subnet. Головна відмінність — робота з інтернет-трафіком:
- public subnet дозволяє сервісам взаємодіяти із зовнішньою мережею;
- private subnet ізольована від прямого інтернет-трафіку.
Створюємо підмережі
Для початку зробимо першу підмережу у зоні доступу A. Назвемо її private-a, щоб у майбутньому було простіше орієнтуватися в структурі мережі.
CIDR block 10.0.0.0/16 визначає діапазон IP-адрес, які можна використовувати всередині VPC.
Це означає, що всередині VPC можна використовувати IP-адреси у форматі 10.0.x.x.
Частину цього діапазону ми далі розіб’ємо між subnet, щоб кожна з них отримала власний набір IP-адрес.
Для цієї subnet використовується діапазон IP-адрес у форматі 10.0.0.x.
Тепер створимо її в AWS:
- У меню зліва відкрийте вкладку Subnets.
- Натисніть кнопку Create subnet.
- Оберіть потрібний VPC та вкажіть параметри підмережі.
- У полі IPv4 CIDR block задайте діапазон 10.0.0.0/24.
- Після цього натисніть Create subnet.
- AWS автоматично створить subnet та покаже її ідентифікатор — Subnet ID.
- Натисніть Close, щоб повернутися до списку subnet — нова підмережа вже з’явиться в інтерфейсі.
Після створення subnet AWS автоматично прив’яже до неї базові правила маршрутизації та мережевої безпеки. Детальніше розберемо їх трохи далі.
Тепер повторіть цей процес ще тричі та створіть:
- xx-private-b
- xx-public-a
- xx-public-b
Для кожної subnet потрібно вказати окремий CIDR block, щоб їхні діапазони IP-адрес не перетиналися між собою.
Тепер у вашому списку має відображатися чотири окремі мережі:
Поки що різниця між цими мережами полягає лише в їхніх діапазонах IP-адрес. Вони ще не стали повноцінно публічними чи приватними, адже для VPC поки не налаштовані шлюзи та правила маршрутизації трафіку.
3. Налаштування шлюзів
До цього моменту ваша мережа була закритою екосистемою. Тепер підключимо шлюз (gateway), який відкриє їй доступ до зовнішнього трафіку.
Що варто знати про шлюзи?
Gateway (шлюз) — це точка переходу між різними мережами. Він працює як міст між ізольованою мережею та зовнішнім світом, і допомагає правильно передавати трафік.
Для роботи із зовнішнім трафіком AWS використовує різні типи шлюзів:
- Internet Gateway відкриває VPC доступ до інтернету в обидві сторони — для вхідного та вихідного трафіку. Підтримує IPv4 та IPv6.
- Egress-Only Gateway дозволяє лише вихідний трафік із VPC без можливості підключення зовні. Він працює тільки з IPv6 і в окремих випадках може замінити NAT Gateway.
Створюємо шлюз
Ми створимо перший тип шлюза, який забезпечить двосторонню взаємодію мережі із зовнішнім трафіком.
- Відкрийте вкладку Internet Gateways у меню зліва.
- Натисніть Create internet gateway.
- Задайте назву для шлюза.
- Натисніть Create internet gateway для завершення створення.
- Після цього AWS покаже новий gateway — натисніть Close.
Досить просто, чи не так? Поки що шлюз існує окремо від VPC, тому в інтерфейсі він матиме статус detached.
Далі ми підключимо його до мережі:
- Відкрийте створений шлюз у списку ресурсів.
- У меню Actions оберіть Attach to VPC.
- Виберіть свій VPC зі списку доступних мереж.
- Натисніть Attach internet gateway, щоб завершити підключення.
Готово! Шлюз підключено.
4. Налаштування еластичної IP-адреси
Для подальшого налаштування шлюз потребує Elastic IP — статичну адресу, через яку маршрутизуватиметься зовнішній трафік.
Що варто знати про еластичний IP
Elastic IP — це публічна IPv4-адреса в AWS. Вона залишається закріпленою за вашим акаунтом доки ви самі її не звільните.
AWS автоматично призначає Elastic IP із власного набору адрес, тому вибрати конкретний IP або повернути старий після видалення не вийде.
Якщо ви створюєте NAT Gateway (Network Address Translation) в AWS, необхідно прив’язати його до Elastic IP. Ця адреса стає видимою для зовнішнього трафіку. Стабільний і незмінний IP особливо важливий для сервісів та мережевих фільтрів, де доступ налаштовується за конкретною адресою.
Cтворюємо еластичний IP
- Відкрийте вкладку Elastic IPs у меню зліва.
- Натисніть Allocate Elastic IP address.
- Підтвердьте створення кнопкою Allocate.
- Після цього нова Elastic IP-адреса з’явиться у списку доступних адрес.
5. Налаштування NAT-шлюза
Що варто знати про NAT
NAT — трансляція мережевих адрес — це технологія, яка допомагає внутрішнім ресурсам взаємодіяти із зовнішньою мережею через трансляцію IP-адрес.
В AWS механізм NAT наразі працює лише для IPv4. Щоб приватні підмережі могли безпечно взаємодіяти із зовнішньою мережею, AWS пропонує два варіанти:
- NAT Instance — звичайний EC2-instance у публічній підмережі через який маршрутизуватиметься трафік із приватної підмережі.
- NAT Gateway — готовий керований сервіс від AWS, який виконує ту ж роль, але автоматично масштабується та спрощує роботу з мережею.
Створюємо NAT
Тепер настав час створити NAT Gateway — посередника, через якого ізольовані підмережі зможуть працювати із зовнішнім трафіком без втрати приватності.
- Відкрийте вкладку NAT Gateways у меню зліва.
- Натисніть Create NAT gateway.
- Під час налаштування виберіть одну з ваших public subnet.
На цьому етапі AWS не підписує subnet як public чи private, тому тут стане у пригоді назва та структура мережі, яку ви налаштовували раніше.
- Підключіть створену еластичну IP-адресу до NAT-шлюзу та натисніть Create NAT gateway.
- AWS автоматично розгорне NAT-шлюз — це може зайняти кілька хвилин. Коли статус зміниться на Available, ним уже можна буде користуватися.
Але це ще не все. Наш NAT-шлюз працює та мережа все ще не є повністю відмовостійкою. Для повноцінної відмовостійкості одного NAT-шлюзу недостатньо. Якщо одна Availability Zone стане недоступною, приватні підмережі у цій зоні можуть втратити доступ до зовнішньої мережі.
Для стабільної роботи мережі у разі збою їх зазвичай створюють окремо для кожної зони.
Для цього:
- створіть ще одну Elastic IP-адресу;
- повторіть процес створення NAT-шлюзу;
- розмістіть його у другій публічній підмережі.
Так кожна зона доступу отримає власний NAT-шлюз і залишатиметься працездатною навіть у разі збою іншої зони.
6. Налаштування таблиці маршрутизації
Тепер мережі потрібно задати логіку руху трафіку: які subnet матимуть вихід в інтернет, а які залишаться ізольованими. Саме для цього потрібні table roats (таблиці маршрутизації).
Що варто знати про таблиці маршрутизації
У мережі трафік не вгадує маршрут навмання. Таблиці маршрутизації — такий собі навігатор, які підказує, куди саме необхідно передавати дані.
Хороші новини для тих, хто вже працював із мережевими концепціями поза AWS: логіка маршрутизації тут працює дуже схожим чином.
AWS автоматично прив’язує базову route table до вашого VPC та застосовує її до всіх subnet всередині мережі, як показано в інтерфейсі:
На цьому етапі потрібно налаштувати маршрут для кожної підмережі.
У результаті у вас мають бути:
- route table для private-a, яка спрямовуватиме зовнішній трафік через NAT-шлюз у зоні доступу A;
- route table для private-b, яка працюватиме через NAT-шлюз у зоні доступу B;
- route table для public-a з маршрутом до Internet Gateway;
- route table для public-b також із маршрутом до Internet Gateway.
Саме ці правила визначатимуть, які підмережі матимуть доступ до зовнішньої мережі, а які залишатимуться ізольованими.
Для публічної підмережі необов’язково створювати окремі таблиці маршрутизації — обидві мережі можуть використовувати одну спільну таблицю.
Але якщо ви плануєте масштабувати або ускладнювати інфраструктуру в майбутньому, краще одразу використовувати окремі route tables для кожної підмережі.
Важливо, щоб кожна приватна підмережа використовувала NAT-шлюз саме своєї зони доступу.
Тобто:
- private-a має працювати через NAT-шлюз зони доступу A;
- private-b — через NAT-шлюз зони доступу B.
Такий підхід допомагає зберігати відмовостійкість мережі та уникати зайвого міжзонального трафіку.
Створення таблиці маршрутизації
Тут варто бути особливо уважними: помилки в маршрутизації можуть призвести до непрацездатності мереж.
Далі налаштуємо route table для private-a:
- Відкрийте вкладку Route Tables у меню зліва.
- Натисніть Create route table.
- Задайте назву таблиці та оберіть потрібний VPC.
- Натисніть Create route table для завершення створення.
- Перейдіть у вкладку Subnet associations.
- Натисніть Edit subnet associations.
- Прив’яжіть subnet private-a до створеної route table. У підсумку конфігурація має виглядати приблизно так:
- Відкрийте вкладку Routes.
Ви побачите маршрут із позначкою Local — він відповідає за внутрішній трафік усередині VPC. Це означає, що всі ресурси в діапазоні 10.0.0.0/16 можуть взаємодіяти між собою всередині мережі.
Тепер додамо маршрут для виходу у зовнішню мережу:
- Натисніть Edit routes → Add route.
- У полі Destination введіть 0.0.0.0/0.
- Як Target виберіть NAT-шлюз Availability Zone A.
- Збережіть зміни кнопкою Save routes.
Запис 0.0.0.0/0 у маршрутизації означає «весь зовнішній IPv4-трафік».
Проте це не означає, що NAT-шлюз тепер оброблятиме весь трафік у мережі.
Route table працює як набір правил, які AWS перевіряє у певному порядку. Спочатку система аналізує найбільш конкретні маршрути, а вже потім переходить до більш загальних.
Саме тому правило Local для діапазону 10.0.0.0/16 спрацює раніше за маршрут 0.0.0.0/0. Завдяки цьому внутрішній трафік VPC залишатиметься всередині мережі й не потраплятиме до NAT-шлюзу.
Лише трафік, який не відповідає внутрішнім маршрутам VPC, буде спрямований через NAT.
Простими словами, AWS перевіряє маршрути приблизно за такою логікою:
- чи є точний маршрут для конкретної IP-адреси (/32);
- чи існує маршрут для subnet (/24);
- чи потрібно використати загальний маршрут 0.0.0.0/0.
У маршрутизації завжди перемагає найбільш точне правило.
Якщо ж пакет не підходить під жоден маршрут у route table, AWS просто не знатиме, куди його передати — і трафік буде відхилений.
Отже
Вітаємо — фундамент закладено! Тепер майбутнє вашої інфраструктури виглядає впевненіше, а головне безпечніше. Головна перевага структурованої мережі — передбачуваність. На нашому курсі AWS ми навчимо вас розуміти, як побудована мережа та як зміни впливають на систему.