Настройка автоматического масштабирования (Auto Scaling Groups) AWS

Пиковые нагрузки могут привести к простоям и переплатам, если инфраструктура не масштабируется автоматически. Мы настраиваем Auto Scaling Groups в AWS, чтобы ваше приложение стабильно работало при любом наплыве пользователей. Наша команда реализует проект под ключ — от аудита текущей конфигурации до внедрения и последующей поддержки.
Часто задаваемые вопросы

Мы настраиваем Auto Scaling Groups в AWS, чтобы ваше приложение выдерживало пиковые нагрузки без простоев и переплат. Ошибки в конфигурации — десятки тысяч долларов в месяц или часы даунтайма. Правильная настройка ASG с использованием predictive scaling и Mixed Instance Policy снижает затраты на 60–70%. Наш опыт — более 50 успешных проектов по масштабированию, сертифицированные инженеры и гарантия результата. Свяжитесь с нами для оценки вашей инфраструктуры.

Типичная история: ASG настроена с policy по CPU. Нагрузка растёт — CPU поднимается до 70%, ASG запускает новый инстанс. Инстанс запускается 5 минут, проходит health check ещё 3 минуты — итого 8 минут до того, как новый инстанс начинает принимать трафик. За эти 8 минут CPU на существующих инстансах уже давно перевалил за 90%, и пользователи видят таймауты.

Решение — в predictive scaling и правильной warmup конфигурации. Но обо всём по порядку.

Launch Templates вместо Launch Configurations

Launch Configurations — legacy. Уже несколько лет AWS официально рекомендует Launch Templates для всего нового. Launch Templates поддерживают versioning (можно откатиться к предыдущей конфигурации инстанса), mixed instance policies (комбинирование разных типов в одной ASG), T-instance unlimited mode и другие новые фичи.

Пример Launch Template через Terraform
resource "aws_launch_template" "app" {
  name_prefix = "myapp-"
  image_id = data.aws_ami.app.id
  instance_type = "t3.medium"
  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }
  user_data = base64encode(templatefile("${path.module}/userdata.sh", {
    environment = var.environment
  }))
  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "myapp-${var.environment}"
    }
  }
  lifecycle {
    create_before_destroy = true
  }
}

Какие политики масштабирования выбрать?

Target Tracking — самый простой и рекомендуемый. Указываем целевое значение метрики, ASG сам считает, сколько инстансов нужно. Для CPU target 50% — ASG держит среднее CPU около 50%, автоматически добавляя или убирая инстансы.

resource "aws_autoscaling_policy" "cpu_target" {
  name = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 50.0
  }
}

Step Scaling — для более точного контроля. Разные шаги масштабирования в зависимости от величины превышения порога. CPU 60–75% → добавить 1 инстанс, CPU 75–90% → добавить 3 инстанса, CPU >90% → добавить 5 инстансов.

Scheduled Scaling — по расписанию, для предсказуемых пиков. Комбинируя эти подходы, можно добиться оптимальной реакции на нагрузку.

Тип политики Когда использовать Преимущества
Target Tracking Типовые web-нагрузки Простота, автоматическая корректировка
Step Scaling Неравномерные пики с критичностью Гибкость, точное управление
Scheduled Scaling Предсказуемые события (рабочее время, акции) Ресурсы готовы до начала пика

Как настроить health check grace period?

ASG проверяет здоровье инстансов через EC2 status checks или через ALB health checks. ALB health checks — лучший вариант для веб-сервисов: проверяют реальную отдачу приложения, а не просто доступность гипервизора.

health_check_grace_period — время, которое ASG даёт новому инстансу на инициализацию, прежде чем начнёт проверять health checks. Если grace period слишком маленький — инстанс будет признан нездоровым до того, как приложение стартовало, и ASG его убьёт. Если слишком большой — реально сломанный инстанс долго остаётся в ротации.

Для приложений с долгим cold start (Spring Boot, JVM) — grace period 300–600 секунд. Для лёгких Go/Node сервисов — 60–120 секунд.

Почему Lifecycle Hooks критичны для деплоев?

Lifecycle Hooks — механизм выполнения действий при запуске или завершении инстанса, с паузой процесса ASG до завершения хука. Согласно документации AWS, AWS Lifecycle Hooks позволяют:

  • autoscaling:EC2_INSTANCE_LAUNCHING: дождаться полной инициализации приложения, зарегистрировать инстанс в consul/etcd, загрузить конфигурацию из S3.
  • autoscaling:EC2_INSTANCE_TERMINATING: дождаться завершения текущих запросов, дерегистрация из service discovery, отправка метрик последнего состояния.

Без terminating хука — при scale-in ALB получает сигнал убрать инстанс из rotation, но сам инстанс уже убивается ASG через 30 секунд. Активные соединения обрываются. С хуком — инстанс сначала drain connections (до 5 минут), потом сигналит хуку о завершении.

Как сэкономить с Mixed Instance Policy?

Для снижения стоимости — Mixed Instance Policy: часть capacity на On-Demand (base), остальное на Spot. Spot инстансы в 10 раз дешевле On-Demand при правильном выборе стратегии.

mixed_instances_policy {
  instances_distribution {
    on_demand_base_capacity = 1
    on_demand_percentage_above_base_capacity = 20
    spot_allocation_strategy = "price-capacity-optimized"
  }

  launch_template {
    launch_template_specification {
      launch_template_id = aws_launch_template.app.id
      version = "$Latest"
    }

    override {
      instance_type = "t3.medium"
    }

    override {
      instance_type = "t3a.medium"
    }

    override {
      instance_type = "t2.medium"
    }
  }
}

Стратегия price-capacity-optimized — Spot инстансы из пулов с наибольшей доступностью и минимальной ценой. Снижает вероятность прерывания. Правильное сочетание On-Demand и Spot может сократить затраты на 60-70% по сравнению с полным On-Demand.

Характеристика On-Demand Spot (Mixed Instance Policy)
Цена 100% до 10% от On-Demand
Гарантия доступности 99.99% до 99.5% (зависит от типа)
Прерывание нет возможно (при высоком спросе)
Использование критичные сервисы отказоустойчивые, batch, stateless

Как настроить Auto Scaling Group? Пошаговая инструкция

  1. Создайте Launch Template с указанием AMI, типа инстанса, user data и тегов.
  2. Создайте Auto Scaling Group, выбрав Launch Template и указав VPC и подсети.
  3. Настройте политику масштабирования: Target Tracking для CPU или Request Count.
  4. Подключите ALB и настройте health check grace period (300–600 с для тяжёлых приложений).
  5. Добавьте Lifecycle Hooks для graceful shutdown (EC2_INSTANCE_TERMINATING).
  6. Настройте Mixed Instance Policy для экономии.
  7. Протестируйте масштабирование с помощью нагрузочного тестирования.

Что входит в работу

  • Аудит текущей конфигурации ASG и рекомендации
  • Проектирование Launch Templates с учетом security и user data
  • Настройка одной или нескольких политик масштабирования (target tracking, step, scheduled)
  • Интеграция с ALB и настройка health checks
  • Реализация Lifecycle Hooks для graceful shutdown
  • Mixed Instance Policy для оптимизации стоимости
  • Мониторинг (CloudWatch, Prometheus) и алерты
  • Документация и обучение вашей команды
  • Гарантия на настройки — 1 месяц

Сроки и стоимость

Базовая настройка ASG с target tracking policy и ALB интеграцией — от 1 дня. Полная конфигурация с lifecycle hooks, mixed instances, scheduled scaling и мониторингом — 2–4 дня. Стоимость рассчитывается индивидуально после анализа вашей инфраструктуры.

Закажите аудит текущей конфигурации ASG — сэкономьте до 70% на облачных расходах. Получите консультацию инженера AWS с 7+ лет опыта. Мы гарантируем, что ваше масштабирование будет надёжным, экономичным и управляемым.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1393
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1368
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    815
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1139