Модуль 1.3: Elastic Compute Cloud (EC2) та основи обчислень

Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Модуль 1.2

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

Наприкінці 2021 року e-commerce стартап запустив свій довгоочікуваний розпродаж до Чорної п’ятниці. Вони побудували свій додаток на великих екземплярах EC2 і, очікуючи на великий трафік, вручну підготували двадцять масивних серверів напередодні ввечері. Проте сплеск трафіку виявився втричі більшим за очікуваний. Сервери досягли 100% використання CPU за лічені хвилини. До того часу, як інженерна команда увійшла в систему, вручну запустила нові екземпляри, встановила залежності додатка та зареєструвала їх у балансувальнику навантаження, минуло дві години. Веб-сайт не відповідав, кошики були покинуті, а стартап втратив приблизно два мільйони доларів продажів.

Цій катастрофі можна було повністю запобігти. Інженери ставилися до своїх хмарних серверів як до фізичного обладнання — статичного, дорогоцінного і такого, що потребує ручного догляду. Вони не змогли скористатися словом “Elastic” (еластичний) в Elastic Compute Cloud.

Amazon EC2 — це не просто віртуальні машини у хмарі; це програмована обчислювальна фабрика. При правильному використанні EC2 дозволяє вашій інфраструктурі динамічно розширюватися та стискатися залежно від попиту в реальному часі, гарантуючи, що у вас достатньо потужностей для обробки піків, і при цьому ви не платите за сервери, що простоюють у тихі періоди. У цьому модулі ви навчитеся автоматизувати підготовку серверів за допомогою AMI та User Data, зрозумієте механіку роботи сховищ EBS та об’єднаєте Auto Scaling Groups з Application Load Balancers для побудови самовідновлюваних, високонадійних обчислювальних кластерів, які масштабуються без втручання людини. Ви навчитеся ставитися до серверів як до ефемерних товарів, а не постійних “улюбленців”.

Будівельні блоки обчислень

Щоб запустити екземпляр EC2, ви повинні зробити низку конфігураційних виборів, які визначають його профіль продуктивності, вартість та життєвий цикл. Кожен вибір має свої компроміси. Розуміння цих компромісів — це те, що відрізняє того, хто “використовує EC2”, від того, хто проєктує архітектуру з його допомогою.

Типи та сімейства екземплярів

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

• Загального призначення (General Purpose, напр., t3, m6i): Збалансовані ресурси обчислень, пам’яті та мережі. Підходять для веб-серверів, репозиторіїв коду та баз даних малого та середнього розміру. Екземпляри серії T є “burstable” — вони накопичують CPU-кредити під час простою і витрачають їх під час навантажень. Якщо ваш додаток має стабільне помірне використання з періодичними сплесками, серія T може бути значно дешевшою за екземпляри з фіксованою продуктивністю.
• Оптимізовані для обчислень (Compute Optimized, напр., c6i, c6g): Високе співвідношення vCPU до пам’яті. Ідеальні для пакетної обробки, перекодування медіа, наукового моделювання, ініференсу машинного навчання та високопродуктивних веб-серверів, яким потрібна чиста потужність процесора.
• Оптимізовані для пам’яті (Memory Optimized, напр., r6i, x2idn): Розроблені для навантажень, що обробляють великі набори даних у пам’яті, таких як реляційні бази даних, кеші Redis/Memcached, аналітика в пам’яті та обробка великих даних у реальному часі за допомогою Apache Spark.
• Оптимізовані для зберігання (Storage Optimized, напр., i3, d3): Висока швидкість послідовного читання/запису великих наборів даних на локальних сховищах. Призначені для сховищ даних, розподілених файлових систем (HDFS) та систем обробки логів.
• Прискорені обчислення (Accelerated Computing, напр., p4d, g5): Використовують апаратні прискорювачі (GPU або кастомні чіпи) для обчислень із рухомою комою, обробки графіки або навчання моделей машинного навчання.

Декодування назви екземпляра

Назва екземпляра на кшталт m6i.xlarge слідує послідовній схемі іменування:

m    6    i    .    xlarge
|    |    |         |
|    |    |         +-- Розмір (nano, micro, small, medium, large, xlarge, 2xlarge...)
|    |    +------------ Додатковий атрибут (i = Intel, g = Graviton, a = AMD, d = local NVMe)
|    +----------------- Покоління (вище = новіше, краще співвідношення ціна/якість)
+---------------------- Сімейство (m = general, c = compute, r = memory, t = burstable)

Розуміння конвенції іменування дозволяє з одного погляду зрозуміти параметри будь-якого екземпляра, навіть того, з яким ви ніколи раніше не стикалися.

Таблиця порівняння типів екземплярів

У таблиці нижче порівнюються типи екземплярів, що найчастіше використовуються у чотирьох найпопулярніших сімействах. Наведені ціни є приблизними погодинними тарифами On-Demand у регіоні us-east-1 станом на 2025 рік і з часом будуть змінюватися.

Тип екземпляра	Сімейство	vCPUs	Пам’ять (GiB)	Мережа (Гбіт/с)	On-Demand $/год	Найкращі сценарії
t3.micro	Burstable GP	2	1	До 5	~$0.0104	Dev/test, мікросервіси, сайти з малим трафіком
t3.medium	Burstable GP	2	4	До 5	~$0.0416	Невеликі веб-додатки, CI/CD агенти, staging
t3.xlarge	Burstable GP	4	16	До 5	~$0.1664	Середні веб-додатки, невеликі БД, сервери додатків
m6i.large	General Purpose	2	8	До 12.5	~$0.096	Продакшн веб-сервери, середні БД, backend API
m6i.xlarge	General Purpose	4	16	До 12.5	~$0.192	Сервери додатків, корпоративне ПЗ, хости контейнерів
m6i.2xlarge	General Purpose	8	32	До 12.5	~$0.384	Великі сервери додатків, середні БД, вузли EKS
c6i.large	Compute Optimized	2	4	До 12.5	~$0.085	Пакетна обробка, білд-сервери, ігрові сервери
c6i.xlarge	Compute Optimized	4	8	До 12.5	~$0.170	Кодування відео, наукові обчислення, ML ініференс
c6i.2xlarge	Compute Optimized	8	16	До 12.5	~$0.340	Високопрод. обчислення, показ реклами, аналітика
r6i.large	Memory Optimized	2	16	До 12.5	~$0.126	Redis/Memcached, малі БД у пам’яті
r6i.xlarge	Memory Optimized	4	32	До 12.5	~$0.252	PostgreSQL/MySQL, середні кеші, аналітика
r6i.2xlarge	Memory Optimized	8	64	До 12.5	~$0.504	Великі реляційні БД, Elasticsearch, SAP HANA

Ключове спостереження: Зверніть увагу, що t3.medium та m6i.large обидва мають 2 vCPU — але m6i.large надає 8 GiB пам’яті (удвічі більше за 4 GiB у t3.medium при тій же кількості vCPU) і стабільну продуктивність без обмежень за кредитами. Для продуктових навантажень, що потребують надійної продуктивності, сімейство M зазвичай має більше сенсу, ніж burstable серія T, незважаючи на трохи вищу погодинну вартість.

Примітка щодо Graviton: Сімейства екземплярів, що закінчуються на ‘g’ (напр., m6g, c6g, r6g), використовують процесори AWS Graviton (архітектура ARM) замість x86. Вони зазвичай пропонують на 20-40% краще співвідношення ціна/якість порівняно з їхніми аналогами від Intel. Якщо ваш технологічний стек підтримує ARM (більшість Linux-навантажень, контейнери та інтерпретовані мови), екземпляри Graviton майже завжди є розумнішим вибором.

Варіанти купівлі

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

• On-Demand (За запитом): Сплата за обчислювальні потужності за секунду без довгострокових зобов’язань. Найдорожчий, але максимально гнучкий варіант. Використовуйте для непередбачуваних навантажень та додатків, роботу яких не можна переривати.
• Reserved Instances (RIs, Зарезервовані екземпляри): Зобов’язання використовувати конкретний тип екземпляра в конкретному регіоні протягом 1 або 3 років. Пропонує значні знижки порівняно з On-Demand. Стандартні RIs можна продати на ринку (Reserved Instance Marketplace), якщо ваші потреби зміняться.
• Savings Plans (Плани заощаджень): Більш гнучка альтернатива RIs. Замість зобов’язання щодо конкретного типу екземпляра, ви берете на себе зобов’язання щодо стабільного обсягу використання, виміряного в доларах за годину (наприклад, “обчислення на $10/год протягом 1 року”). Це зобов’язання поширюється на будь-яке сімейство екземплярів, розмір, ОС або регіон. Зазвичай це найкращий вибір за замовчуванням для стабільних навантажень.
• Spot Instances (Спотові екземпляри): Використання надлишкових обчислювальних потужностей Amazon EC2 з величезними знижками. Але є нюанс: AWS може відкликати екземпляр, попередивши про це за 2 хвилини, якщо потужність знадобиться деінде. Використовуйте для відмовостійких, гнучких навантажень без стану (stateless), таких як черги обробки зображень, ранери CI/CD, аналітика великих даних.
• Dedicated Hosts (Виділені хости): Фізичний сервер EC2, виділений суто для вашого використання. Необхідний для ліцензійних моделей, що потребують видимості на рівні сокетів або ядер (напр., Windows Server, Oracle Database), або для вимог комплаєнсу, що забороняють спільне використання заліза з іншими клієнтами.

Порівняльна таблиця варіантів купівлі

Варіант	Знижка vs On-Demand	Зобов’язання	Ризик переривання	Найкраще для
On-Demand	0% (база)	Немає	Немає	Непередбачувані навантаження, короткі проєкти
Savings Plan (1р)	~30-40%	$/год на 1 рік	Немає	Стабільні продуктові навантаження
Savings Plan (3р)	~50-60%	$/год на 3 роки	Немає	Довготривала стабільна інфраструктура
Reserved Instance (1р, All Upfront)	~40%	Конкр. екземпляр, 1 рік	Немає	Відомі навантаження фіксованого розміру
Reserved Instance (3р, All Upfront)	~60-72%	Конкр. екземпляр, 3 роки	Немає	Бази даних, основна інфраструктура
Spot Instances	~60-90%	Немає	ТАК (2 хв попер.)	Пакетні задачі, CI/CD, обробка даних
Dedicated Hosts	Варіюється	1 або 3 роки (або On-Demand)	Немає	Відповідність ліцензіям, ізоляція

Приклад вартості: Один m6i.xlarge, що працює цілодобово протягом року за тарифом On-Demand, коштує приблизно $0.192/год x 8 760 год = $1 682/рік. З 3-річним Savings Plan (повна передоплата) вартість того ж обчислення падає приблизно до $672/рік — економія 60%. При спотовому ціноутворенні (припускаючи середню знижку ~70%) аналогічне навантаження коштуватиме близько $504/рік, але ви повинні спроєктувати систему так, щоб вона витримувала переривання.

Золоте правило оптимізації витрат EC2: використовуйте Savings Plans для базового навантаження, On-Demand для непередбачуваних сплесків і Spot для всього, що може терпіти переривання. Ніколи не запускайте стабільне продуктове навантаження на чистому On-Demand довше кількох тижнів без оцінки зобов’язань.

Сховище: Elastic Block Store (EBS)

Хоча екземпляри мають тимчасове локальне сховище (Instance Store), для постійних даних потрібен Amazon EBS. Томи EBS — це мережеві блочні сховища, які існують незалежно від життєвого циклу екземпляра. Думайте про них як про USB-накопичувачі, які можна підключити до будь-якого сервера в тій же зоні доступності.

• gp3 (General Purpose SSD): Варіант за замовчуванням для більшості навантажень. Забезпечує базу в 3 000 IOPS та 125 МіБ/с пропускної здатності з можливістю незалежно докуповувати до 16 000 IOPS та 1 000 МіБ/с. Це відокремлення продуктивності від об’єму — велика перевага над попереднім gp2.
• gp2 (General Purpose SSD, застарілий): Попереднє покоління. IOPS масштабуються разом із об’ємом тома (3 IOPS на 1 ГіБ). Все ще широко використовується, але gp3 майже завжди дешевше та гнучкіше для нових розгортань.
• io2 Block Express (Provisioned IOPS SSD): Для критично важливих, високонадійних баз даних, що потребують затримки менше мілісекунди та до 256 000 IOPS. Дорого, але необхідно для інтенсивних транзакційних навантажень.
• st1 (Throughput Optimized HDD): Дешеве магнітне сховище, оптимізоване для великих послідовних навантажень, таких як обробка логів, сховища даних та стрімінг. Не може бути завантажувальним томом.
• sc1 (Cold HDD): Найдешевший варіант для даних, до яких рідко звертаються. Не може бути завантажувальним томом.

EBS Snapshots (Знімки)

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

Ключові можливості:

• Між AZ: Використовуйте знімок для створення нового тома у будь-якій AZ у межах того ж регіону.
• Між регіонами: Копіюйте знімок в інший регіон для аварійного відновлення.
• Спільний доступ: Діліться знімками з іншими акаунтами AWS.
• Fast Snapshot Restore (FSR): “Прогрівайте” знімок, щоб томи, створені з нього, одразу видавали повну продуктивність без початкової затримки при першому зверненні.

# Створення знімка тома EBS
aws ec2 create-snapshot \
    --volume-id vol-0123456789abcdef0 \
    --description "Daily backup - production DB" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=prod-db-daily}]'

# Список ваших знімків
aws ec2 describe-snapshots --owner-ids self \
    --query 'Snapshots[*].[SnapshotId,VolumeId,StartTime,State]' \
    --output table

# Створення тома зі знімка в іншій AZ
aws ec2 create-volume \
    --snapshot-id snap-0123456789abcdef0 \
    --availability-zone us-east-1b \
    --volume-type gp3

Автоматизація процесу завантаження: AMI та User Data

Якщо ви входите на сервер, щоб запустити apt-get install або змінити конфігураційні файли вручну — ви створюєте “улюбленця” (pet). У хмарній архітектурі нам потрібна “худоба” (cattle) — сервери, які ідентичні і легко замінні. Різниця колосальна: коли улюбленець хворіє, ви його лікуєте; коли хворіє одиниця худоби — ви замінюєте її на здорову. Автомасшабування працює тільки тоді, коли кожен екземпляр є взаємозамінним.

Amazon Machine Images (AMI)

AMI містить інформацію, необхідну для запуску екземпляра: операційну систему, архітектуру (x86 або ARM) та знімок кореневого тома.

Замість того, щоб щоразу налаштовувати сервер з нуля, популярним патерном є “Golden Image” (золотий образ):

1. Запускаєте базову AMI Linux.
2. Встановлюєте ваш додаток, агентів безпеки та залежності.
3. Створюєте власну AMI з цього екземпляра.
4. Запускаєте всі майбутні сервери з вашої кастомної AMI — вони завантажуються за секунди вже повністю налаштованими.

# Пошук останньої AMI Amazon Linux 2023
aws ssm get-parameters \
    --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
    --query 'Parameters[0].Value' --output text

# Пошук останньої AMI Ubuntu 22.04
aws ec2 describe-images \
    --owners 099720109477 \
    --filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*" \
    --query 'sort_by(Images, &CreationDate)[-1].ImageId' \
    --output text

# Створення власної AMI з працюючого екземпляра
aws ec2 create-image \
    --instance-id i-0123456789abcdef0 \
    --name "MyApp-GoldenImage-$(date +%Y%m%d)" \
    --description "App v2.3 with security agents" \
    --no-reboot

# Список ваших кастомних AMI
aws ec2 describe-images --owners self \
    --query 'Images[*].[ImageId,Name,CreationDate]' \
    --output table

Конвеєр Golden Image на практиці: Професійні команди автоматизують це за допомогою HashiCorp Packer або EC2 Image Builder. CI/CD конвеєр створює нову AMI щоночі (або при кожному релізі програми), тестує її та оновлює Launch Template. Потім ASG поступово замінює старі сервери на нові з поточною AMI.

User Data та Cloud-Init

Якщо ви не хочете створювати кастомну AMI для кожної дрібної зміни конфігурації, використовуйте User Data.

При запуску екземпляра ви можете передати shell-скрипт у поле User Data. Сервіс cloud-init, що працює на екземплярі EC2, виконає цей скрипт із правами root на фінальних етапах першого завантаження. Це ідеальне місце для того, щоб підтягнути останній код з S3, запустити сервіси або зареєструвати сервер в інструменті управління конфігураціями.

#!/bin/bash
# Приклад скрипта User Data
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Розгорнуто через User Data</h1>" > /var/www/html/index.html

Більш професійний скрипт, що отримує конфігурацію з Parameter Store та логує процес:

#!/bin/bash
set -euo pipefail

# Логування всього процесу для дебагу
exec > >(tee /var/log/user-data.log) 2>&1
echo "User Data скрипт розпочато: $(date)"

# Встановлення додатку
yum update -y
yum install -y httpd aws-cli jq

# Отримання конфігурації з Parameter Store
APP_VERSION=$(aws ssm get-parameter --name /myapp/version --query 'Parameter.Value' --output text --region us-east-1)
DB_ENDPOINT=$(aws ssm get-parameter --name /myapp/db-endpoint --query 'Parameter.Value' --output text --region us-east-1)

# Завантаження коду з S3
aws s3 cp "s3://my-deploy-bucket/releases/${APP_VERSION}/app.tar.gz" /tmp/
tar -xzf /tmp/app.tar.gz -C /var/www/html/

# Запис файлу конфігурації
cat << CONF > /var/www/html/config.json
{
    "db_endpoint": "$DB_ENDPOINT",
    "app_version": "$APP_VERSION"
}
CONF

# Запуск веб-сервера
systemctl start httpd
systemctl enable httpd

echo "User Data скрипт успішно завершено: $(date)"

Порада для дебагу: Якщо ваш User Data скрипт мовчки не спрацював, увійдіть на сервер через SSH і перевірте файл /var/log/cloud-init-output.log. Він містить вивід stdout та stderr вашого скрипта.

Golden Image vs User Data: Коли що використовувати?

Підхід	Час завантаження	Гнучкість	Обслуговування	Найкраще для
Golden AMI	Швидко (секунди)	Низька — треба перезбирати	Потрібен AMI pipeline	Стабільна база, рідкі зміни
Тільки User Data	Повільно (хвилини)	Висока — міняйте при запуску	Простий скрипт	Швидка ітерація, dev/test
Гібрид (рекоменд.)	Середньо	Збалансована	Обидва пайплайни	AMI для бази + User Data для конфігу

Гібридний підхід використовує більшість досвідчених команд. В AMI “запікають” ОС, агентів безпеки та середовище виконання (те, що рідко змінюється). А через User Data підтягують актуальну версію коду та специфічні для оточення налаштування (те, що змінюється часто).

Масштабування флоту: ASG та ALB

Один екземпляр EC2 — це єдина точка відмови. Сучасні архітектури розподіляють навантаження між групою серверів. Поєднання Application Load Balancer (ALB) та Auto Scaling Group (ASG) — це фундаментальний патерн для високонадійних обчислень в AWS.

Огляд архітектури

                          Інтернет
                             |
                    +--------+--------+
                    | Application     |
                    | Load Balancer   |
                    | (ALB)           |
                    +--------+--------+
                             |
             +---------------+---------------+
             |               |               |
     +-------+------+ +-----+------+ +------+-------+
     | Target Group | | Target     | | Target       |
     | Екземпляр A  | | Group      | | Group        |
     | (AZ-1a)      | | Екземпляр B | | Екземпляр C  |
     |              | | (AZ-1b)    | | (AZ-1a)      |
     +--------------+ +------------+ +--------------+
             |               |               |
             +---------------+---------------+
                             |
                    +--------+--------+
                    | Auto Scaling    |
                    | Group (ASG)     |
                    |                 |
                    | Min: 2          |
                    | Desired: 3      |
                    | Max: 10         |
                    |                 |
                    | Launch Template |
                    | - AMI           |
                    | - Instance Type |
                    | - Security Grp  |
                    | - User Data     |
                    +-----------------+

    Політика масштабування (CloudWatch):
    - CPU > 70% протягом 3 хв  --> Додати 2 екземпляри
    - CPU < 30% протягом 10 хв --> Видалити 1 екземпляр

Application Load Balancer (ALB)

ALB працює на рівні 7 (HTTP/HTTPS). Він отримує вхідний трафік і розподіляє його між цілями (як-от екземпляри EC2) у кількох зонах доступності. Самі ALB також є високонадійними — AWS запускає їх у кількох AZ “за лаштунками”.

Ключові особливості:

• Health Checks (Перевірки стану): ALB постійно опитує певний ендпоінт (напр., /health) на ваших серверах. Якщо сервер не відповідає, ALB припиняє надсилати йому трафік, доки він не відновиться.
• Маршрутизація на основі шляхів (Path-Based): ALB може перевіряти URL і направляти /api/* на одну групу серверів, а /images/* — на іншу.
• Маршрутизація на основі хостів (Host-Based): Один ALB може обслуговувати api.example.com та app.example.com, направляючи їх на різні групи серверів залежно від заголовка Host.
• Sticky Sessions (Липкі сесії): Дозволяє прив’язувати користувача до конкретного сервера на час сесії за допомогою кукі. Корисно для додатків зі станом, але краще виносити стан сесій у зовнішні сховища типу ElastiCache.
• Connection Draining (Витікання з’єднань): При видаленні сервера ALB чекає завершення активних запитів перед тим, як повністю відключити його. Типове значення — 300 секунд.

# Створення групи цілей (Target Group) з налаштуваннями health check
aws elbv2 create-target-group \
    --name MyApp-TG \
    --protocol HTTP --port 80 \
    --vpc-id vpc-0123456789abcdef0 \
    --health-check-path /health \
    --health-check-interval-seconds 15 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3 \
    --query 'TargetGroups[0].TargetGroupArn' --output text

# Перевірка стану серверів у групі
aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyApp-TG/abc123 \
    --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State,TargetHealth.Description]' \
    --output table

Auto Scaling Groups (ASG)

ASG — це логічна група екземплярів EC2 для автоматичного масштабування та управління.

Ви визначаєте Launch Template (шаблон запуску: AMI, тип сервера, групи безпеки, user data) і приєднуєте його до ASG.

ASG стежить за здоров’ям серверів і підтримує заданий стан:

• Самовідновлення (Desired Capacity): Якщо ви встановили ціль у 3 сервери, і один із них “впав”, ASG автоматично запустить новий, щоб знову стало 3.
• Динамічне масштабування: Можна налаштувати політики на основі метрик CloudWatch. Наприклад: “Якщо середній CPU вище 70% протягом 3 хвилин — додай 2 сервери. Якщо впав нижче 30% — видали один”.
• Прогнозне масштабування (Predictive Scaling): AWS аналізує історію трафіку і заздалегідь масштабує флот перед очікуваним сплеском, а не реагує постфактум.
• Масштабування за розкладом: Якщо ви знаєте, що о 9 ранку по буднях трафік зростає — ви можете запланувати розширення заздалегідь.

Коли ASG з’єднана з ALB, нові сервери автоматично реєструються в балансувальнику, як тільки проходять перевірку стану.

Політики масштабування

# Створення політики Target Tracking (найпростіша та найпопулярніша)
# Ця політика триматиме середній CPU на рівні ~60%, автоматично додаючи/видаляючи сервери
aws autoscaling put-scaling-policy \
    --auto-scaling-group-name DojoWebASG \
    --policy-name TargetCPU60 \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 60.0,
        "ScaleInCooldown": 300,
        "ScaleOutCooldown": 60
    }'

# Перегляд поточної активності масштабування
aws autoscaling describe-scaling-activities \
    --auto-scaling-group-name DojoWebASG \
    --query 'Activities[*].[StartTime,StatusCode,Description]' \
    --output table --max-items 5

Важливість періодів остигання (Cooldown): ScaleOutCooldown (типово 300с) заважає ASG запускати лавину нових серверів, доки перша порція ще не встигла завантажитися і розвантажити систему. Занадто мале значення призведе до хаотичних запусків, занадто велике — до повільної реакції на навантаження. Для веб-додатків 60-120 секунд для розширення та 300 секунд для звуження — гарна точка старту.

Управління життєвим циклом EC2 через CLI

Крім запуску та видалення, AWS CLI дає повний контроль. Ось операції, які ви будете використовувати постійно:

# Запуск одного екземпляра з детальною конфігурацією
aws ec2 run-instances \
    --image-id ami-0123456789abcdef0 \
    --instance-type t3.medium \
    --key-name my-keypair \
    --security-group-ids sg-0123456789abcdef0 \
    --subnet-id subnet-0123456789abcdef0 \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer-01},{Key=Environment,Value=Production}]' \
    --user-data file://userdata.sh \
    --iam-instance-profile Name=WebServerRole \
    --query 'Instances[0].InstanceId' --output text

# Список запущених серверів із корисними деталями
aws ec2 describe-instances \
    --filters "Name=instance-state-name,Values=running" \
    --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,PrivateIpAddress,PublicIpAddress,Tags[?Key==`Name`].Value|[0]]' \
    --output table

# Зупинка сервера (дані EBS зберігаються, публічна IP звільняється, якщо це не Elastic IP)
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

# Запуск зупиненого сервера
aws ec2 start-instances --instance-ids i-0123456789abcdef0

# Зміна розміру сервера (спочатку треба зупинити)
aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute \
    --instance-id i-0123456789abcdef0 \
    --instance-type '{"Value": "m6i.xlarge"}'
aws ec2 start-instances --instance-ids i-0123456789abcdef0

# Видалення сервера (назавжди — кореневий EBS видаляється за замовчуванням)
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

# Підключення до сервера через SSM (ключі SSH та відкритий порт 22 не потрібні)
aws ssm start-session --target i-0123456789abcdef0

Сервіс метаданих екземпляра (IMDS)

Кожен екземпляр EC2 має доступ до спеціального HTTP-ендпоінта за адресою 169.254.169.254, який надає інформацію про сам екземпляр. Це незамінно для скриптів автоматизації, яким треба знати “хто я?” і “де я?”.

# IMDSv2 (на основі токенів, більш безпечний — завжди використовуйте його)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Отримання базових даних про ідентичність
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-type
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-ipv4

# Отримання креденшалів IAM-ролі (ніколи не хардкодьте ключі — використовуйте це)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/MyInstanceRole

Зауваження щодо безпеки: Завжди вимагайте використання IMDSv2 і вимикайте IMDSv1. Стара версія IMDSv1 вразлива до атак SSRF, через які стався великий витік даних у Capital One у 2019 році. Зловмисник використав помилку в конфігурації WAF, щоб зробити запит до сервісу метаданих і викрасти ключі IAM-ролі.

# Примусове використання IMDSv2 на існуючому сервері
aws ec2 modify-instance-metadata-options \
    --instance-id i-0123456789abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

Чи знали ви?

1. Екземпляри Amazon EC2 Mac насправді використовують фізично немодифіковані комп’ютери Apple Mac mini, інтегровані безпосередньо в систему AWS Nitro. Це дозволяє розробникам запускати macOS нативно у хмарі для збірки iOS-додатків. Ви орендуєте весь фізичний Mac mini мінімум на 24 години.
2. Якщо ви використовуєте Elastic IP (EIP) і вона приєднана до запущеного екземпляра — вона безкоштовна. Але якщо ви зарезервували EIP і вона просто стоїть (не приєднана), AWS нараховує погодинну плату, щоб запобігти “захопленню” IPv4 адрес. З лютого 2024 року AWS також бере плату $0.005/год за кожну публічну IPv4 адресу, навіть якщо вона приєднана — ця зміна змусила багато команд переглянути свою мережеву архітектуру.
3. Система AWS Nitro — це поєднання виділеного заліза та полегшеного гіпервізора. Вона переносить мережеві, дискові та безпекові функції на окремі кастомні чіпи, віддаючи майже всі ресурси процесора та пам’яті сервера безпосередньо вашим екземплярам. До появи Nitro (напр., серії m4, c4) гіпервізор з’їдав 5-10% ресурсів.
4. Одна Auto Scaling Group може використовувати різні типи серверів та різні варіанти купівлі одночасно. Ви можете налаштувати ASG так, щоб 60% були On-Demand (для стабільної бази), а 40% — Spot (для економії на сплесках), причому AWS обиратиме найдешевші доступні спотові варіанти з кількох сімейств. Така стратегія диверсифікації радикально зменшує ймовірність того, що всі ваші спотові сервери вимкнуться одночасно.

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

Помилка	Чому це стається	Як виправити
Втрата даних при видаленні	За замовчуванням кореневий EBS видаляється при термінації сервера. Інженери плутають “Stop” і “Terminate”.	Зберігайте критичні дані на додатковому томі з DeleteOnTermination=false, або проєктуйте stateless додатки, що зберігають стан в RDS або S3.
Жорстко прописані IP-адреси	Старі додатки очікують статичних IP, або розробники записують IP серверів у файли конфігурації.	В середовищі Auto Scaling IP-адреси постійно змінюються. Використовуйте внутрішні балансувальники, сервіс-дискавері (Cloud Map) або приватні зони Route 53.
Зберігання AWS-ключів на EC2	Розробники кладуть ~/.aws/credentials на сервер, щоб працювали скрипти, або “запікають” ключі в AMI.	Це величезний ризик. Завжди приєднуйте IAM-роль (Instance Profile) до сервера, щоб він отримував безпечні тимчасові ключі, що ротуються автоматично.
Ігнорування Spot-екземплярів	”Ми просто використовуємо On-Demand, бо так простіше”.	Білд-агенти, пакетна обробка та воркери черг — це навантаження, які можна переривати. Spot-екземпляри для таких задач можуть скоротити витрати на 60-90%.
Секрети в AMI	Запис паролів або API-ключів під час створення образу, бо “так простіше”.	Кожен, хто запустить цей AMI, отримає доступ до секретів. Впроваджуйте секрети під час запуску через User Data, отримуючи їх із Secrets Manager.
Не налаштовані ASG health checks	ASG покладається на статус EC2, який каже лише, чи працює віртуалка, а не чи живий сам додаток всередині.	Налаштуйте ASG на використання ELB Health Checks. Якщо веб-сервер “завис”, а віртуалка працює — ASG все одно пересоздасть такий екземпляр.
Використання IMDSv1	Це старий стандарт, який працює без токенів “із коробки”. Команди просто не оновлюють налаштування.	Примусово вмикайте IMDSv2 (http-tokens required) на всіх серверах та в Launch Templates. IMDSv1 вразливий до крадіжки IAM-ключів.
Відсутність пільгового періоду (Grace Period)	ASG починає перевіряти здоров’я сервера одразу після запуску, поки додаток ще завантажується.	Встановіть --health-check-grace-period мінімум на час роботи вашого User Data скрипта (зазвичай 120-300 секунд). Інакше ASG почне вбивати здорові сервери, що просто ще грузяться.

Тест

Питання 1: Вам потрібно спроєктувати архітектуру для рендерингу відео. Завдання беруться з черги SQS. Якщо сервер вимкнеться під час роботи, завдання просто повернеться в чергу і буде підхоплене іншим сервером. Рендеринг потребує багато CPU, але бюджет обмежений. Який варіант купівлі EC2 буде найкращим?

Spot Instances. Оскільки навантаження повністю stateless, відмовостійке і працює через чергу, воно ідеально підходить для спотових екземплярів із їхнім 2-хвилинним попередженням про вимкнення. Це дасть доступ до потужних CPU-ресурсів (напр., серії C6i) за частку вартості On-Demand. Для мінімізації ризиків налаштуйте групу серверів на використання кількох типів екземплярів (c6i, c5, c5a, c6g) у різних AZ.

Питання 2: Ви запустили сервер EC2 зі скриптом User Data, який оновлює ОС та встановлює Node.js. Через годину ви зупинили сервер (Stop) і знову його запустили (Start). Чи виконається скрипт User Data вдруге?

Ні. За замовчуванням скрипт `cloud-init` User Data виконується лише один раз за весь життєвий цикл екземпляра — під час найпершого завантаження. Зупинка та повторний запуск сервера не тригерять його знову. Якщо вам потрібно, щоб скрипт працював при кожному завантаженні, треба використовувати спеціальний boothook або розмістити скрипт у папці `/var/lib/cloud/scripts/per-boot/`.

Питання 3: Ваша Auto Scaling Group має Minimum: 2, Maximum: 10 та Desired capacity: 4. У одній зоні доступності стався збій, через що два ваших сервери "впали". Що зробить Auto Scaling Group?

Перевірки стану ASG помітять, що два екземпляри вийшли з ладу. Оскільки цільова кількість (Desired) встановлена в 4, ASG автоматично запустить два нові сервери в тих зонах доступності, що залишилися здоровими, щоб відновити флот. Також ASG робить ребалансування: коли проблемна зона відновиться, наступні операції масштабування можуть запустити сервери саме там для рівномірного розподілу.

Питання 4: Ви приєднали том EBS до сервера в `us-east-1a` і зробили його знімок (snapshot). Через кілька днів сервер видалили. Чи можна використати цей знімок, щоб створити новий том для сервера в `us-east-1b`?

Так. Хоча томи EBS прив'язані до конкретної зони доступності, знімки (snapshots) зберігаються на рівні регіону в Amazon S3. Ви можете використати знімок, зроблений в `us-east-1a`, щоб миттєво створити новий том в `us-east-1b` (або в будь-якій іншій AZ регіону `us-east-1`). Ви навіть можете скопіювати знімок в інший регіон взагалі.

Питання 5: Яка головна операційна перевага використання Launch Template замість старого Launch Configuration для Auto Scaling Group?

Launch Templates підтримують версійність. Ви можете створити нову версію шаблону (наприклад, оновити ID AMI на нову пропатчену версію) і переключити ASG на неї, або налаштувати ASG так, щоб вона завжди брала "Latest" версію. Старі Launch Configuration були незмінними: щоб щось змінити, треба було створювати нову конфігурацію і оновлювати ASG. Також шаблони підтримують нові фічі типу змішування типів екземплярів та спотових/on-demand варіантів.

Питання 6: Application Load Balancer направляє трафік на групу серверів. Один із серверів раптом почав повертати HTTP 500 через витік пам'яті в додатку. Як на це зреагує ALB?

Якщо перевірка стану (health check) налаштована на очікування відповіді HTTP 200 за певним шляхом, ALB помітить, що сервер перестав проходити перевірку. Як тільки буде перевищено поріг помилок, ALB позначить цей сервер як "Unhealthy" і негайно перестане направляти на нього трафік нових користувачів, розподіляючи його між здоровими серверами. Якщо для ASG увімкнені перевірки стану від ELB, група масштабування видалить цей сервер і запустить заміну.

Питання 7: У вас є веб-додаток на екземплярах m6i.large. Трафік дуже передбачуваний: низький вночі, зростає о 8 ранку, пік о 12 дня і спадає о 6 вечора. Яку стратегію масштабування обрати?

Використовуйте комбінацію Scheduled Scaling (за розкладом) та Target Tracking (за ціллю). Налаштуйте заплановані дії: розширити флот перед 8 ранку (напр., з 2 до 6 серверів о 7:45) і звузити після 6 вечора. Зверху накладіть політику Target Tracking (ціль 60% CPU), щоб вона обробляла будь-які непередбачувані відхилення від графіка. Розклад обробляє базу, трекінг — варіативність.

Питання 8: Розробник створив власну AMI зі своїм додатком і поділився нею з іншим акаунтом AWS. Другий акаунт намагається запустити сервер з цієї AMI, але отримує помилку "snapshot not found". Що пішло не так?

AMI посилається на знімки EBS. При спільному використанні AMI між акаунтами ви повинні також відкрити доступ до базових знімків EBS, на яких вона побудована. Якщо знімки не розшарені (або якщо вони зашифровані ключем KMS, на який у другого акаунта немає прав), запуск не вдасться. Треба розшарити і AMI, і її знімки, а у випадку шифрування — надати права на використання ключа KMS.

---

Практична вправа: Автомасшабований веб-флот

У цій вправі ми створимо Launch Template зі скриптом підготовки, розгорнемо його за Application Load Balancer за допомогою Auto Scaling Group. Потім ми згенеруємо навантаження, щоб побачити масштабування в дії.

(Примітка: Вам знадобляться VPC та Subnet ID з Модуля 1.2. Ми припускаємо використання стандартної default VPC, якщо ви видалили ті ресурси).

Завдання 1: Створення скрипта User Data та груп безпеки

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

# Отримання Default VPC
VPC_ID=$(aws ec2 describe-vpcs --filter "Name=isDefault,Values=true" --query 'Vpcs[0].VpcId' --output text)
echo "VPC: $VPC_ID"

# Створення Security Group для ALB (дозволяємо порт 80 з інтернету)
ALB_SG=$(aws ec2 create-security-group \
    --group-name DojoALB-SG \
    --description "Allow HTTP to ALB" \
    --vpc-id $VPC_ID \
    --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress \
    --group-id $ALB_SG --protocol tcp --port 80 --cidr 0.0.0.0/0

# Створення Security Group для веб-серверів (дозволяємо порт 80 ТІЛЬКИ від ALB SG)
WEB_SG=$(aws ec2 create-security-group \
    --group-name DojoWeb-SG \
    --description "Allow HTTP from ALB only" \
    --vpc-id $VPC_ID \
    --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress \
    --group-id $WEB_SG --protocol tcp --port 80 --source-group $ALB_SG

echo "ALB SG: $ALB_SG"
echo "Web SG: $WEB_SG"

# Створення скрипта підготовки
cat << 'USERDATA' > userdata.sh
#!/bin/bash
set -euo pipefail
exec > >(tee /var/log/user-data.log) 2>&1

yum update -y
yum install -y httpd stress-ng

# Увімкнення та запуск Apache
systemctl start httpd
systemctl enable httpd

# Отримання метаданих екземпляра (IMDSv2)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/instance-id)
AZ=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/placement/availability-zone)
INSTANCE_TYPE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/instance-type)

# Створення сторінки, яка ідентифікує конкретний сервер
cat << HTML > /var/www/html/index.html
<!DOCTYPE html>
<html>
<head><title>KubeDojo EC2 Lab</title></head>
<body style="font-family: Arial; padding: 40px; text-align: center;">
    <h1>Привіт з EC2!</h1>
    <table style="margin: auto; text-align: left;">
        <tr><td><strong>Instance ID:</strong></td><td>$INSTANCE_ID</td></tr>
        <tr><td><strong>Availability Zone:</strong></td><td>$AZ</td></tr>
        <tr><td><strong>Instance Type:</strong></td><td>$INSTANCE_TYPE</td></tr>
        <tr><td><strong>Boot Time:</strong></td><td>$(date)</td></tr>
    </table>
</body>
</html>
HTML

# Створення ендпоінта для перевірки здоров'я
echo "OK" > /var/www/html/health

echo "User Data успішно завершено: $(date)"
USERDATA

Завдання 2: Створення Launch Template

Launch Template — це креслення для нашої групи серверів.

# Пошук останньої AMI Amazon Linux 2023
AMI_ID=$(aws ssm get-parameters \
    --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
    --query 'Parameters[0].Value' --output text)
echo "AMI: $AMI_ID"

# Підготовка даних шаблону (кодування userdata в base64)
cat << EOF > template-data.json
{
    "ImageId": "$AMI_ID",
    "InstanceType": "t3.micro",
    "SecurityGroupIds": ["$WEB_SG"],
    "UserData": "$(base64 -i userdata.sh)",
    "MetadataOptions": {
        "HttpTokens": "required",
        "HttpEndpoint": "enabled"
    },
    "TagSpecifications": [
        {
            "ResourceType": "instance",
            "Tags": [
                {"Key": "Name", "Value": "DojoWeb"},
                {"Key": "Project", "Value": "KubeDojo-EC2-Lab"}
            ]
        }
    ]
}
EOF

# Створення Launch Template
aws ec2 create-launch-template \
    --launch-template-name DojoWebTemplate \
    --version-description "v1-initial" \
    --launch-template-data file://template-data.json

Завдання 3: Створення інфраструктури балансувальника

Перед створенням ASG нам потрібна група цілей (target group) та сам ALB.

# Отримання ID підмереж для Default VPC (треба мінімум 2 AZ)
SUBNETS=$(aws ec2 describe-subnets \
    --filters "Name=vpc-id,Values=$VPC_ID" "Name=default-for-az,Values=true" \
    --query 'Subnets[0:2].SubnetId' --output text)
SUBNET_1=$(echo $SUBNETS | awk '{print $1}')
SUBNET_2=$(echo $SUBNETS | awk '{print $2}')
echo "Subnet 1: $SUBNET_1"
echo "Subnet 2: $SUBNET_2"

# Створення Target Group з кастомною перевіркою здоров'я
TG_ARN=$(aws elbv2 create-target-group \
    --name DojoWebTG \
    --protocol HTTP --port 80 \
    --vpc-id $VPC_ID \
    --health-check-path /health \
    --health-check-interval-seconds 15 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3 \
    --query 'TargetGroups[0].TargetGroupArn' --output text)
echo "Target Group: $TG_ARN"

# Створення ALB (публічний)
ALB_ARN=$(aws elbv2 create-load-balancer \
    --name DojoWebALB \
    --subnets $SUBNET_1 $SUBNET_2 \
    --security-groups $ALB_SG \
    --query 'LoadBalancers[0].LoadBalancerArn' --output text)
echo "ALB: $ALB_ARN"

# Очікування активації ALB (займає ~2 хв)
echo "Очікування активації ALB..."
aws elbv2 wait load-balancer-available --load-balancer-arns $ALB_ARN

# Створення слухача (Listener)
aws elbv2 create-listener \
    --load-balancer-arn $ALB_ARN \
    --protocol HTTP --port 80 \
    --default-actions Type=forward,TargetGroupArn=$TG_ARN

# Отримання DNS імені ALB
ALB_DNS=$(aws elbv2 describe-load-balancers \
    --load-balancer-arns $ALB_ARN \
    --query 'LoadBalancers[0].DNSName' --output text)
echo "ALB DNS: http://$ALB_DNS"

Завдання 4: Створення Auto Scaling Group

Зв’язуємо Launch Template з Target Group.

# Створення ASG на дві підмережі, початкова кількість — 2
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name DojoWebASG \
    --launch-template LaunchTemplateName=DojoWebTemplate,Version='$Latest' \
    --min-size 2 --max-size 6 --desired-capacity 2 \
    --vpc-zone-identifier "$SUBNET_1,$SUBNET_2" \
    --target-group-arns $TG_ARN \
    --health-check-type ELB \
    --health-check-grace-period 180 \
    --tags Key=Name,Value=DojoWeb-ASG,PropagateAtLaunch=false

# Додавання політики Target Tracking (масштабування за CPU)
aws autoscaling put-scaling-policy \
    --auto-scaling-group-name DojoWebASG \
    --policy-name DojoTargetCPU50 \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 50.0,
        "ScaleInCooldown": 300,
        "ScaleOutCooldown": 60
    }'

echo "ASG створено. Очікування запуску серверів..."

Завдання 5: Перевірка та тестування

# Перевірка статусу (почекайте ~2 хвилини, поки завантажаться)
aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names DojoWebASG \
    --query 'AutoScalingGroups[0].[DesiredCapacity,Instances[*].[InstanceId,HealthStatus,AvailabilityZone]]' \
    --output table

# Перевірка здоров'я цілей в ALB
aws elbv2 describe-target-health \
    --target-group-arn $TG_ARN \
    --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State]' \
    --output table

# Тест ендпоінта ALB (запустіть кілька разів, щоб побачити різні ID серверів)
curl http://$ALB_DNS
curl http://$ALB_DNS
curl http://$ALB_DNS

Відкрийте DNS-ім’я в браузері. Оновіть сторінку кілька разів, щоб побачити, як трафік балансується між серверами — ви повинні бачити різні Instance ID та зони доступності у відповідях.

Завдання 6: Тригер автомасшабування (Опційно)

Щоб побачити масштабування в дії, увійдіть на один із серверів (через SSH або SSM) і згенеруйте навантаження на CPU:

# Всередині сервера EC2, генеруємо стрес на 5 хвилин
stress-ng --cpu 2 --timeout 300s

# На локальній машині спостерігаємо за реакцією ASG (запускайте кожні 30 секунд)
watch -n 30 "aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names DojoWebASG \
    --query 'AutoScalingGroups[0].[DesiredCapacity,Instances[*].[InstanceId,HealthStatus]]' \
    --output table"

# Лог активності масштабування
aws autoscaling describe-scaling-activities \
    --auto-scaling-group-name DojoWebASG \
    --query 'Activities[*].[StartTime,StatusCode,Description]' \
    --output table --max-items 5

За кілька хвилин після того, як навантаження перевищить 50%, ви побачите, як ASG автоматично запускає додаткові сервери.

Завдання 7: Тест самовідновлення

Вручну видаліть один із серверів і подивіться, як ASG його замінить:

# Отримання ID одного сервера з групи
INSTANCE_TO_KILL=$(aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names DojoWebASG \
    --query 'AutoScalingGroups[0].Instances[0].InstanceId' --output text)

echo "Видалення $INSTANCE_TO_KILL для перевірки самовідновлення..."
aws ec2 terminate-instances --instance-ids $INSTANCE_TO_KILL

# Спостерігаємо, як ASG помічає проблему і запускає новий сервер
watch -n 15 "aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names DojoWebASG \
    --query 'AutoScalingGroups[0].Instances[*].[InstanceId,HealthStatus,LifecycleState]' \
    --output table"

ASG повинна помітити видалений сервер протягом 1-2 циклів перевірки і автоматично запустити новий, щоб підтримувати бажану кількість (2).

Очищення

Важливо: Завжди очищуйте ресурси, щоб не платити за них.

# Крок 1: Видалення ASG (force-delete видалить усі сервери)
aws autoscaling delete-auto-scaling-group \
    --auto-scaling-group-name DojoWebASG --force-delete
echo "Видалення ASG розпочато. Очікування вимкнення серверів..."
sleep 30

# Крок 2: Видалення ALB та Listener (слухач видаляється разом із балансувальником)
aws elbv2 delete-load-balancer --load-balancer-arn $ALB_ARN
echo "Очікування видалення ALB..."
sleep 30

# Крок 3: Видалення Target Group (треба дочекатися видалення ALB)
aws elbv2 delete-target-group --target-group-arn $TG_ARN

# Крок 4: Видалення Launch Template
aws ec2 delete-launch-template --launch-template-name DojoWebTemplate

# Крок 5: Видалення груп безпеки (дочекайтеся повного вимкнення серверів)
echo "Очікування завершення термінації серверів перед видаленням груп безпеки..."
sleep 60
aws ec2 delete-security-group --group-id $WEB_SG
aws ec2 delete-security-group --group-id $ALB_SG

# Крок 6: Видалення локальних файлів
rm -f userdata.sh template-data.json

echo "Очищення завершено!"

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

• Я успішно створив окремі Security Groups для ALB та веб-серверів (ешелонований захист).
• Я створив Launch Template з User Data, вимогою IMDSv2 та правильними тегами.
• Я створив ALB із Target Group, що використовує кастомний шлях /health.
• Я створив Auto Scaling Group із політикою Target Tracking.
• Я перевірив DNS балансувальника в браузері і підтвердив, що User Data скрипт правильно налаштував сервери (ID серверів змінюються при оновленні).
• Я побачив самовідновлення ASG після ручного видалення сервера.

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

Тепер, коли у вас є обчислювальні ресурси без стану, вам потрібне місце для зберігання масивів неструктурованих даних. Переходьте до Модуля 1.4: S3 та об’єктне сховище.