Налаштування AWS VPC і мережевої ізоляції під ключ

Чому налаштування AWS VPC ламається при зростанні навантаження

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

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

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

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

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

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

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

Вимірний ефект керованої мережевої ізоляції

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

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

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

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

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

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

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

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

Варіанти ізоляції: одна VPC, окремі акаунти, гібрид

Вибір режиму ізоляції — це відповідь на питання, де проходять межі довіри між середовищами.

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

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

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

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

Етапи проєктування й впровадження ізоляції

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

1. Інвентаризація трафіку. Збираємо журнали потоків за два-чотири тижні, розмічаємо джерела, напрямки й порти, знаходимо забуті тунелі та прямі звернення з інтернету до внутрішніх сервісів.
2. Проєктування підмереж. Публічний контур — лише балансувальники й периметр, застосунки та дані — у приватних підмережах, керуючі сервіси — окремо. Діапазони адрес беремо із запасом під зростання.
3. Матриця правил доступу. Зводимо зв’язки в таблицю «джерело — призначення — порт» і переносимо її в групи безпеки та мережеві списки. Зайві дозволи закриваємо відразу, а не «на потім».
4. Пілот на стенді. Піднімаємо копію топології, проганяємо типові сценарії, перевіряємо, що відмова однієї підмережі не тягне за собою сусідні. Тут же знімаємо заміри затримок до й після.
5. Міграція без простою. Переносимо сервіси хвилями: трафік тимчасово йде двома контурами, перемикання — за метриками, відкат — за хвилини на будь-якому кроці.
6. Перевірка правил доступу. Скануємо периметр і звіряємо фактичні зв’язки з матрицею: усе, що відкрилося за фактом, а не за проєктом, вичищаємо до передачі.
7. Передача в експлуатацію. Віддаємо схему адресації, матрицю доступу, регламент змін і порядок підключення нового сервісу — щоб команда далі сама керувала схемою.

Артефакти, які передаємо після впровадження

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

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

• Документація схеми мережі — діаграми за зонами й підмережами, план адресації, точки виходу в інтернет і до внутрішніх сервісів, таблиці маршрутизації з поясненням, навіщо потрібен кожен маршрут.
• Карта залежностей сервісів — який сервіс у якій підмережі живе, з ким спілкується і в якому напрямку; за нею видно, що станеться із системою при вимкненні конкретного правила.
• Політики доступу — ролі й права, розподіл за середовищами, хто власник ресурсу і хто має право змінювати мережеві правила. Принцип мінімальних привілеїв зафіксовано явно, а не «історично склався».
• Матриця потоків — джерело, призначення, порт, призначення зв’язку. Слугує і регламентом для нових сервісів, і чек-лістом при розборі інциденту.
• Регламент змін — як правка мережевого правила проходить перевірку в окремому середовищі, погодження, вікно застосування й відкат. Зміни перестають бути усною домовленістю між двома інженерами.
• Інструкція чергової зміни — типові сценарії: зник зв’язок між сервісами, відмовив зовнішній канал, помилка в маршруті. З покроковими діями, діагностичними командами й точками ескалації.
• Порядок іменування й міток — єдиний принцип, за яким ресурс знаходиться за хвилину, а власник і призначення визначаються без дзвінків автору налаштування.
• Точки інтеграції з моніторингом — які події мережі й куди йдуть у вигляді оповіщень, які пороги вважаються штатними.

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

Кейс: сегментація продуктового контуру й доступів

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

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

Як розвели середовища й доступи

Контур розділили за середовищами: у продакшну, тесту й розробки окремі акаунти AWS зі своїми мережами та діапазонами адрес, що не перетинаються.

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

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

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

Показники до й після

Що робити, якщо контур уже розгорнутий і працює?

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

Інвентаризація дає список потоків, які не можна розривати ні на хвилину, і показує, які сегменти допустимо ізолювати першими.

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

Сумісність із партнерами тримається на незмінності адрес: для зовнішніх підключень виділяються окремі точки входу з попередніми адресами, вихідні адреси узгоджуються заздалегідь.

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

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

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

Технічні питання щодо мережевої ізоляції

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

Чи сумісна ізоляція з нашими сервісами?

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

Якщо сервісу потрібен доступ до панелі керування, виводимо його через приватну точку, а не через публічну мережу.

Що із супроводом, коли мережу здано?

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

Де межа відповідальності?

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

Обговоримо задачу й повернемося з планом робіт

Щоб оцінка спиралася на факти, а не на припущення, на вході потрібен мінімум: перелік акаунтів і регіонів, чинна схема адресації підмереж, список сервісів, які зобов’язані залишитися доступними зовні, і вимоги до розмежування доступу між командами.

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

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

Оцінка проєкту йде вилкою за трудомісткістю, і ми відразу називаємо, що може її зсунути: зняття ізоляції між контурами, перенесення наявних підмереж, вимоги аудиту.

Що підготувати з вашого боку:

• Схему поточної мережі: віртуальні мережі, підмережі, таблиці маршрутизації, шлюзи, точки стику з офісом.
• Інвентар сервісів: що спілкується назовні, що лише всередині, які порти й напрямки зобов’язані працювати.
• Вимоги до ізоляції: які контури не повинні бачити одне одного, де потрібен спільний вузол виходу в інтернет, де власний.
• Регламенти: вікна обслуговування, вимоги аудиту, хто погоджує зміни в продуктивному середовищі.
• Допустимий час простою і чи потрібен резервний регіон із реплікацією даних.
• Відповідальних з вашого боку: власник інфраструктури і той, хто приймає результат за етапами.

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