Архітектура в дії. Як створити «вендинговий апарат» для AWS-акаунтів

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, спільното! Сьогодні я хочу поділитися досвідом створення платформи, яку ми в команді називаємо «вендинґовим апаратом» для AWS-акаунтів. Це система, що вможливлює на вимогу створювати ізольовані, безпечні та контрольовані за бюджетом «пісочниці» для навчання та експериментів. І найголовніше: попри архітектурну складність, весь цей досвід ви можете відтворити самотужки.

Цей проєкт стартував як pet-проєкт, що намагався відповідати цілком конкретним вимогам безпеки: ми припускали, що студенти точно скомпрометують інфраструктуру. Кожне рішення, яке ми впроваджували, було спробою створити простий та ефективний інструмент, що діятиме як «вимикач», цілковито відсікаючи доступ та знищуючи дані.

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

Цю статтю збазовано на моєму вебінарі «Architecture in Action», де я докладніше розповідаю про кожен етап розроблювання з позиції архітектора. Рекомендую переглянути його для глибшого занурення в тему.

Проблема: хаос у навчальних середовищах

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

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

Нам потрібна була система, яка б завтоматизувала цей процес, забезпечила повну ізоляцію, ґарантувала безпеку та тримала витрати під жорстким контролем.

Етап 1. Вимоги та аналіз — що будувати?

Наша мета — створити безпечну self-service платформу для створення, за запитом, ізольованих хмарних «пісочниць».

Основні вимоги:

• Self-Service Портал. Інтуїтивний інтерфейс для замовлення та керування.
• Завтоматизований життєвий цикл. Цілковито автоматичне створювання та видаляння середовищ з обмеженим часом життя (напр, 2 год).
• Безпека та ізоляція. Кожна «пісочниця» — це окремий AWS-акаунт з політиками безпеки (guardrails).
• Контролювання бюджету. Жорсткі ліміти на витрати з автоматичним вимкненням.

Ми дослідили наявні рішення, такі як AWS Control Tower Account Factory та опенсорсний проєкт Sandbox Accounts for Events, але жоден із них не задовольняв наших специфічних вимог. Тому було ухвалено — створювати власне рішення.

Етап 2. Дизайн та архітектура — креслення системи

В основі нашої архітектури — концепція пулу акаунтів, що якими керують через AWS Organizations. Ми розділили акаунти на кілька організаційних одиниць (OU — Organizational Unit): Management, Security, Sandbox та Account Pool.

Видавання акаунта:

1. Користувач через навчальний портал робить запит на старт лабораторної роботи.
2. Наша система бере вільний акаунт з пулу (Pool OU).
3. Акаунт переміщують до відповідної OU для конкретної лабораторної (Lab OU).
4. До акаунта застосовуються специфічні Service Control Policies (SCP), що обмежують доступ до сервісів та дій.
5. Створюють бюджет з лімітом та налаштовуються сповіщення.
6. Користувач отримує тимчасові дані для доступу.
7. По закінчення часу (або перевищення бюджету) система ініціює процес очищування.
8. Акаунт цілковито очищають від усіх ресурсів за допомогою aws-nuke і повертають до пулу.

Етап 3. Від PoC до MVP — утілення ідеї в життя

Ми почали з Proof of Concept (PoC) на базі AWS Lambda, щоб перевірити основні гіпотези. Для Minimum Viable Product (MVP) ми залишили Lambda для коротких завдань, але для очищення акаунтів стикнулися з проблемою.

Чому не Lambda для очищення?

Процес aws-nuke може тривати доволі довго. Він послідовно перебирає API кожного сервісу в кожному регіоні, враховує залежності між ресурсами і валідує видалення.

Максимального часу виконання Lambda (15 хвилин) для цього катастрофічно не вистачає.

Альтернатива: AWS Batch та Fargate

Ми прагнули цілковито керованого рішення, тому ідеальним вибором став AWS Batch, який запускає контейнери з aws-nuke на AWS Fargate. Це дало нам гнучкість, масштабованість і позбавило потреби керувати серверами.

Етап 4. Event-Driven Architecture та FinOps у реальному часі

В основі нашої системи контролю лежить подійно-зорієнтована архітектура (EDA). Вона потрібна, оскільки стандартні інструменти, як-от AWS Budgets, працюють із затримкою. Білінґ рахується детерміновано, умовно тричі на день. Це означає, що CloudWatch spending alarm чи AWS Budget спрацюють, коли гроші вже витрачено.

Наш підхід інший:

1. Перехоплення подій. Миттєво реагуємо на події створення ресурсів. У кожен акаунт та дозволений регіон за допомогою AWS CloudFormation StackSets автоматично встановлюються правила Amazon EventBridge.
2. Централізоване обробляння. Усі події згідно з концепцією Landing Zone стікаються в окремий Logging Account. Цікавий факт: Organisation CloudTrail та Org EventBridge не працюють один без одного. Доки ви не увімкнете доступ до організаційних івентів, організаційні логи будуть порожніми.
3. Миттєвий розрахунок. Спеціальний сервіс аналізує подію та через AWS Cost and Usage API розраховує потенційну вартість.
4. Негайна реакція. Якщо студент замість двох t4g.micro інстансів запустив 22, система миттєво це побачить і запустить процес очищення акаунта.

Водночас найпотужнішим проактивним інструментом залишаються SCP. Проте важливо розуміти їхні обмеження. Наприклад, в SCP неможливо заборонити вимкнення termination protection для EC2. І хоча ChatGPT може згенерувати вам таку політику, вона не спрацює. Це підкреслює, чому для цілковитого контролю потрібен наш другий, подійно-орієнтований механізм.

Ще один лайфхак з практики — будьте готові до сюрпризів з івентами в CloudTrail. Їх неймінг — це окремий біль. Ви можете натрапити на івенти на кшталт CreateFunction20150331.

Так, це ілюстрація принципу «так історично склалося» через зворотну сумісність. Це лише доводить, як важливо уважно аналізувати документацію та реальні дані при роботі з API AWS.

Шлях студента. Як це виглядає на практиці

По тому як ми дали раду з архітектурі, погляньмо, як все виглядає для кінцевого користувача.

1. Реєстрація. Студент реєструється на курс, наприклад, на майбутній AWS Challenge, що ми проводимо в рамках AWS User Group Kharkiv.
2. Отримання доступу. У навчальному порталі з’являється завдання з описом, цілями та кнопкою «Start task».
3. Робота в «пісочниці». Після натискання кнопки система за кілька хвилин видає тимчасові дані для доступу до AWS Management Console. Студент виконує завдання в цілковито відізольованому, ефемерному середовищі.
4. Перевірка та зворотній зв’язок. Після виконання завдання студент натискає «Verify». Система автоматично перевіряє правильність конфігурації ресурсів, показуючи результат.

Уроки, висновки та погляд на AI

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

Як AWS Ambassador я повинен адвокувати правильне використання сервісів та дотримання Well-Architected Framework. Коли ми почали онбордити наявні лабораторні, стало зрозуміло, що часто їх готують вчорашні джуніори, які не є архітекторами. У діалозі з ними, показуючи найкращі практики, я часто посилався на офіційні вимоги AWS до партнерських рішень, які звучать так:

Найкращі практики. Архітектурні діаграми мають відображати, що партнер дотримувався AWS Well-Architected Framework... Діаграма має бути побудована таким чином, щоб її було легко зрозуміти... Архітектурна діаграма, в якій відсутні іконки AWS або ясність створеного для клієнтів середовища, навряд чи буде прийнята...

І от, шукаючи для них наочні приклади в AWS Solutions Library, я випадково натрапив на дуже схоже рішення Innovation Sandbox on AWS — яке розробив університет, що спеціалізується на застосуванні AI в освітньому процесі. Поверхневий аналіз показує, що в ньому не враховано багато проблем, з якими ми зіткнулися (обмеження Organizations, SCP, робота з подіями), але воно дуже структуроване і є чудовою референсною архітектурою.

Це підводить нас до теми AI. Якість пропозицій від AI прямо залежить від якості навчальних матеріалів. Я спробував розв’язати нашу задачу за допомогою AWS Kiro, який дозволяє програмувати за специфікаціями. І це певною мірою революція — він дозволяє передбачити проблеми до того, як ви з ними зіткнетеся. На відміну від нього, AI IDE типу GitHub Copilot залишаються лише помічниками. Якби я починав проєкт зараз, я б так само робив його руками, але значно швидше — за узгодженими специфікаціями в Kiro. І, звісно, не витрачаючи купу часу на дебаг лямбд, що ми всі так не полюбляємо.

Результати та майбутнє

На сьогодні наша платформа продемонструвала вражаючі результати:

• Створено AWS-акаунтів: 213.
• Видано «пісочниць»: > 30 000.
• Поточне навантаження: Близько 1000 сендбоксів на тиждень тільки для внутрішнього навчання.
• Вартість однієї сесії: Кілька центів.

Ми отримали високу оцінку від AWS і рухаємося у двох напрямках:

1. Розвиток навчальної платформи. Якщо мова йде про навчання AI, ми плануємо додавати сервіси, як-от AWS WorkSpaces. Це дасть змогу надавати студентам цілковито готове середовище для розробки з AI IDE.
2. Вихід на AWS Marketplace. Ми бачимо величезний попит на подібні рішення. Тому плануємо вивести на ринок як SaaS рішення, платформу для навчання так і саме систему для роботи з акаунтами — нашу «вендингову машину» — як окремий продукт.

Сподіваюся, наш досвід буде вам корисний.