Amazon SAA-C03: Вычислительные ресурсы, Auto Scaling и управление экземплярами — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Типы экземпляров EC2 и AMI

Выбор правильного семейства экземпляров EC2 — это основа хорошо спроектированного вычислительного уровня, поскольку семейство, поколение и размер вместе определяют архитектуру ЦП, соотношение памяти к vCPU, пропускную способность сети и доступные ускорители. Общего назначения (M6i, M7g, T-серия) подходят для сбалансированных веб-уровней и смешанных рабочих нагрузок. Оптимизированные для вычислений (C7i, C7gn) подходят для симуляций, кодирования, пакетной обработки и веб-фронтендов, ограниченных производительностью ЦП. Оптимизированные для памяти (R7i, X2idn) предназначены для баз данных в памяти и кешей. Оптимизированные для хранения (I4i, D3) предназначены для NoSQL, HDFS и хранилищ данных. С ускорителями (P5, G5, Trn1, Inf) предоставляют GPU или специализированные чипы для машинного обучения. Экземпляры Graviton (суффикс g), как правило, обеспечивают на 20–40% лучшее соотношение цены и производительности для горизонтально масштабируемых нагрузок, которые без проблем компилируются под ARM64.

Семейство T является «разгоняемым» (burstable) и по умолчанию работает в стандартном режиме, где кредиты ЦП накапливаются во время простоя и расходуются во время всплесков активности; когда кредиты исчерпаны, производительность ограничивается базовым уровнем. Для рабочих нагрузок с непредсказуемыми всплесками — небольших веб-уровней, сред разработки/тестирования или окружений Elastic Beanstalk, обслуживающих фронтенд с пиковой нагрузкой — экземпляры T-серии в неограниченном режиме позволяют заимствовать кредиты с небольшой доплатой за каждый vCPU-час превышения, избегая заметного для пользователя снижения производительности. Именно поэтому проблемы с кратковременной полной загрузкой ЦП в окружениях Beanstalk обычно решаются включением неограниченного режима, а не переходом на более дорогое семейство, оптимизированное для вычислений. Важно использовать T-серию только для действительно пиковых нагрузок с низкой средней утилизацией: постоянная высокая нагрузка на ЦП в стандартном режиме исчерпывает кредиты за считанные минуты.

Вертикальное масштабирование (переход на больший размер в рамках того же семейства) ограничено самым крупным доступным экземпляром, требует простоя для внесения изменений, создает единую точку отказа и не позволяет распределить нагрузку по нескольким зонам доступности. Когда нагрузка значительно меняется, правильным решением является горизонтальное масштабирование с помощью группы Auto Scaling.

«Золотые» AMI (Golden AMI) «запекают» код приложения, среду выполнения и зависимости в корневой снимок, обеспечивая быстрые и детерминированные запуски, что критически важно, когда Auto Scaling реагирует на всплеск нагрузки. Начальная загрузка через user-data при каждом запуске добавляет минуты задержки в самый неподходящий момент.

Выбор хранилища: Instance Store и EBS, снимки и Fast Snapshot Restore

Экземпляры предлагают два типа хранилищ: локальное хранилище (instance store) (эфемерное NVMe-хранилище, подключенное к физическому хосту) и Amazon EBS (сетевое блочное хранилище). Локальное хранилище обеспечивает минимально возможную задержку, но его данные уничтожаются при остановке, гибернации, завершении работы экземпляра или при сбое оборудования. Рассматривать его как долговечное хранилище — распространенная и опасная ошибка. Оно подходит только для временных файлов, буферов, кешей или реплицируемых данных, например, для узла данных HDFS, реплики которого существуют на других узлах. Долговечные данные следует хранить на EBS, создавая резервные копии в виде снимков, хранящихся в S3.

Снимки являются инкрементными и, после создания, независимыми, поэтому восстановление одного из них на новый том никогда не затрагивает источник. Канонический способ дублирования большого набора производственных данных в тестовую среду — это создать снимок исходного тома и создать новые тома из этого снимка. Однако тома, восстановленные из снимков, выполняют «ленивую» загрузку блоков из S3 при первом чтении, что вызывает значительную задержку ввода-вывода до тех пор, пока каждый блок не будет «прогрет» (hydrated). Та же «ленивая» загрузка влияет на новые экземпляры, запущенные из AMI с большими корневыми снимками — они могут работать медленно в течение нескольких минут после запуска.

EBS Fast Snapshot Restore (FSR) устраняет эту проблему. Включите FSR для снимка в тех зонах доступности, где группа ASG запускает экземпляры, и тома, созданные из него, будут немедленно обеспечивать полную заявленную производительность:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Это крайне важно, когда события горизонтального масштабирования должны добавлять емкость за секунды, а не за минуты.

Расширенные сетевые возможности с ENA и EFA

Заявленная пропускная способность сети масштабируется с размером экземпляра, но достижима только при наличии драйвера Elastic Network Adapter (ENA). ENA обеспечивает расширенные сетевые возможности на основе SR-IOV, поддерживая до 200 Гбит/с на новых экземплярах. Современные AMI (Amazon Linux 2, последние версии Ubuntu, Windows) поставляются с включенным ENA; проверить это можно с помощью команды:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Без ENA экземпляры незаметно переключаются на более низкую пропускную способность и более высокий джиттер, что сводит на нет любые усилия по созданию архитектуры с низкой задержкой, независимо от выбора группы размещения.

Для коллективных операций микросекундного масштаба — в гидродинамике (CFD), моделировании погоды, молекулярной динамике, обучении больших моделей — добавьте Elastic Fabric Adapter (EFA). EFA предоставляет транспорт с обходом ОС (OS-bypass) через Libfabric для MPI и NCCL, полностью избегая сетевого стека ядра. EFA дает преимущества только внутри кластерной группы размещения (cluster placement group) на поддерживаемых типах экземпляров (c7gn, hpc7a, p5) и требует наличия драйвера EFA, а также совместимой сборки MPI (Open MPI, Intel MPI) или NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Группы размещения (Placement Groups)

Группы размещения управляют физической топологией инстансов:

Неправильный выбор сводит на нет преимущества этой функции. Кластерная группа не может охватывать несколько AZ — по своей сути она работает в пределах одной AZ. Распределенная группа не может разместить сотню веб-серверов из-за потолка в семь инстансов на AZ. Для кластера Kafka из 40 узлов правильным инструментом является разделенное размещение (partition), а не распределенное (spread), поскольку оно согласовывает размещение реплик с доменами отказа. Для обеспечения общей высокой доступности не ограничивайте ASG одной группой размещения в одной AZ — распределяйте ASG по нескольким AZ.

Для потоковой аналитики или нагрузок MPI, требующих минимальной задержки между узлами, правильной комбинацией будет кластерная группа размещения плюс инстансы с поддержкой ENA; кластерная группа сокращает количество хопов, а ENA обеспечивает пропускную способность в пакетах в секунду, необходимую для реализации этого преимущества в задержке.

Группы Auto Scaling и шаблоны запуска

Группа Auto Scaling (ASG) — это исполнительный блок, который поддерживает заданное количество инстансов EC2 в одной или нескольких AZ. Она определяется тремя целочисленными значениями — MinSize, DesiredCapacity, MaxSize — и списком подсетей. Сама по себе ASG не описывает, что запускать; за это отвечает шаблон запуска (launch template) — современная замена конфигурациям запуска (launch configurations). Шаблоны запуска поддерживают версионирование, смешанные политики инстансов (mixed instance policies), сочетание Spot и On-Demand инстансов, принудительное использование IMDSv2, резервирование мощностей (capacity reservations) и T-инстансы в неограниченном режиме (unlimited-mode). Шаблон запуска ссылается на AMI, тип(ы) инстансов, группы безопасности (security groups), профиль инстанса IAM (IAM instance profile), пользовательские данные (user data) и сопоставления блочных устройств (block device mappings).

Канонический паттерн для веб-приложений без состояния: AMI + Launch Template + ASG + ALB. AMI обеспечивает быструю загрузку; ALB (или NLB для TCP/UDP) распределяет трафик и выполняет проверки состояния; ASG автоматически регистрирует новые инстансы в целевой группе (target group) и завершает работу неработоспособных. Развертывание в нескольких AZ (минимум две AZ, три для систем с кворумом) является обязательным — ASG, привязанная к одной подсети, не сможет пережить сбой AZ, поскольку сама ASG не сможет запустить замену, пока AZ неисправна.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Политики масштабирования: Target Tracking, Step, Scheduled, Predictive

Масштабирование ASG имеет четыре режима, каждый из которых решает свою задачу:

• Отслеживание целевого значения (Target tracking) выбирает метрику и поддерживает ее около заданной точки (например, ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Этот режим самонастраивающийся — AWS управляет оповещениями (alarms) и регулирует скорость масштабирования по мере отклонения метрики. Этот вариант следует выбирать по умолчанию.
• Пошаговое масштабирование (Step scaling) добавляет или удаляет мощности градуированными шагами в зависимости от того, насколько метрика вышла за пределы диапазона. Полезно, когда величина реакции должна зависеть от серьезности оповещения.
• Простое масштабирование (Simple scaling) — это устаревший метод: одна корректировка на одно оповещение, блокировка во время периода восстановления (cooldown). Его не следует выбирать для новых архитектур.
• Масштабирование по расписанию (Scheduled scaling) изменяет MinSize/DesiredCapacity/MaxSize в заданное по cron-выражению время.
• Прогнозное масштабирование (Predictive scaling) использует машинное обучение на основе истории за период до 14 дней для прогнозирования следующих 48 часов, заранее подготавливая мощности до всплеска нагрузки.

Динамическое масштабирование по своей природе запаздывает — оно реагирует только после того, как метрика превысит порог, а новым инстансам затем требуются минуты на загрузку, регистрацию и «прогрев». Для корпоративного приложения, где все пользователи приходят в 09:00 и сталкиваются с замедлением на 2–3 часа, пока ASG «догоняет» нагрузку, одно лишь динамическое масштабирование — неверное решение. Используйте действия по расписанию (scheduled actions) перед пиком нагрузки, чтобы увеличить MinSize и DesiredCapacity до того, как спрос возрастет:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Затем позвольте отслеживанию целевого значения (target tracking) справляться с остаточной изменчивостью нагрузки. Прогнозное масштабирование — правильный выбор, когда форма пика нагрузки стабильна, но его точное время меняется изо дня в день. Для предсказуемых отключений непроизводственных сред (например, сред разработки на ночь и выходные) действие по расписанию, устанавливающее desired=0, min=0 в пятницу вечером и возвращающее значения утром в понедельник, является решением с наименьшими накладными расходами — сама ASG выступает в роли планировщика, не требуя связующего кода на Lambda или EventBridge.

Выбор метрики так же важен, как и выбор политики. CPU подходит для веб-нагрузок, ограниченных производительностью процессора, но для обработчиков, управляемых очередью (backlog-driven workers), которые забирают сообщения из SQS, вы должны масштабироваться по глубине очереди, а не по CPU: обработчик, заблокированный на операциях ввода-вывода, может показывать 10% загрузки CPU, в то время как в очереди накапливаются миллионы сообщений. Используйте ApproximateNumberOfMessagesVisible на инстанс, предоставляемую как пользовательскую метрику (custom metric) или через встроенный целевой показатель SQSQueueBacklogPerInstance:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Аналогично, чувствительные к задержкам HTTP-уровни должны отслеживать TargetResponseTime или RequestCountPerTarget; приложения, ограниченные памятью, диском или задержками нижестоящих сервисов, должны публиковать пользовательскую метрику, которая отражает реальное узкое место. Масштабирование по CPU, когда CPU не является ограничением, приводит именно к тому сценарию сбоя, когда инстансы не масштабируются, очереди неограниченно растут, а ALB возвращает ошибки 5xx.

Проверки состояния и хуки жизненного цикла

По умолчанию ASG используют проверки состояния EC2, которые отслеживают сбои гипервизора, но не сбои приложения. Включение проверок состояния ELB для ASG делегирует решение о замене инстанса проверкам на уровне приложения, выполняемым балансировщиком нагрузки, что крайне важно, когда ОС в порядке, но процесс завис. Установите HealthCheckGracePeriod на достаточно долгий срок, чтобы скрипты user data успели выполниться; иначе новые инстансы будут постоянно терминироваться в процессе начальной загрузки.

Выбор балансировщика нагрузки влияет на то, что считается «работоспособным» состоянием:

HTTP-приложение за NLB, выполняющим только TCP-проверки состояния, продолжит получать трафик на инстанс, который принимает соединения, но возвращает 500-е ошибки. Переключитесь на ALB или настройте HTTP-проверки на NLB, чтобы восстановить осмысленную передачу сигналов о состоянии.

Хуки жизненного цикла (Lifecycle hooks) приостанавливают инстансы в состояниях Pending:Wait или Terminating:Wait, чтобы внешняя автоматизация могла выполнить необходимые действия. При запуске хук позволяет зарегистрировать инстанс в системе управления конфигурациями, прогреть кэши или получить секреты до того, как ALB начнет отправлять на него трафик. При терминировании хук позволяет корректно завершить сессии (drain sessions), сбросить логи и отменить регистрацию в service mesh. Хуки генерируют события в EventBridge; обработчики должны вызвать CompleteLifecycleAction, иначе хук завершится по таймауту с действием по умолчанию (CONTINUE или ABANDON).

Теплые пулы и гибернация

Время холодного запуска — это реальная проблема для приложений, которые загружают большие модели, прогревают кэши или выполняют JIT-компиляцию перед началом работы. Теплый пул (warm pool) — это предварительно инициализированный резерв, прикрепленный к ASG: инстансы запускаются, выполняют начальную настройку (bootstrap), а затем останавливаются, продолжают работать или переводятся в режим гибернации, ожидая в пуле, пока ASG не потребуется масштабироваться. Взятие инстанса из пула позволяет пропустить минуты загрузки.

Гибернация приостанавливает работу ОС, сохраняя ее состояние в зашифрованный корневой том EBS, так что куча JVM, веса ML-моделей и страничный кэш ОС восстанавливаются при возобновлении работы. Требования: зашифрованный корневой том, достаточно большой для хранения содержимого RAM, объем RAM инстанса ≤ 150 ГБ на поддерживаемом семействе и HibernationOptions.Configured = true при запуске. Теплый пул с PoolState: Hibernated сочетает оба подхода — инстансы ничего не стоят с точки зрения вычислений, пока остановлены, и возобновляют работу за секунды с уже заполненной памятью. Это правильный паттерн для ситуаций, когда приложению «требуется много времени на загрузку данных в память, прежде чем оно станет продуктивным».

Автоматическое восстановление для немасштабируемых нагрузок

Не все рабочие нагрузки масштабируются горизонтально. Устаревшие приложения с лицензиями, привязанными к MAC-адресу, блокировками на основе файлов или состоянием сессии в памяти без общего хранилища не могут работать более чем на одном инстансе — запуск дополнительных узлов приводит к повреждению данных или нарушению лицензии. Для них отказоустойчивость достигается за счет автоматического восстановления, а не горизонтального масштабирования.

Работают два паттерна. Оповещение CloudWatch по метрике StatusCheckFailed_System в паре с действием восстановления EC2 сохраняет ID инстанса, частный IP, Elastic IP и подключенные тома EBS при сбое нижележащего хоста. Еще проще: ASG с MinSize=MaxSize=1, охватывающая несколько зон доступности, заменяет сбойный инстанс и, в отличие от действия восстановления, может пережить сбой всей зоны доступности — при условии, что состояние вынесено за пределы корневого тома или AMI можно пересобрать.

Балансировщики нагрузки и размещение в подсетях

ALB работает на L7, терминируя HTTP/HTTPS, предлагая маршрутизацию на основе хоста/пути/заголовка, HTTP/2, WebSockets, интеграцию с WAF/Cognito/OIDC. NLB работает на L4, сохраняет IP-адрес клиента, поддерживает статические IP-адреса и сквозную передачу TLS (passthrough), PrivateLink и выдерживает миллионы соединений в секунду. Gateway Load Balancer встраивает сторонние устройства (файрволы, IDS) в путь прохождения трафика.

Размещение в подсетях — это то, на чем чаще всего ломаются архитектуры. ALB, доступный из интернета, должен быть подключен к публичным подсетям — подсетям с маршрутом 0.0.0.0/0 к Internet Gateway — по одной в каждой зоне доступности, где находятся целевые инстансы (targets). Сами целевые инстансы остаются в частных подсетях. Если ALB размещен в частных подсетях или в «публичных» подсетях отсутствует маршрут по умолчанию к IGW, клиенты будут сталкиваться с таймаутами соединения. Для доступности целевых инстансов требуется, чтобы их группа безопасности разрешала входящий трафик от группы безопасности ALB на целевой порт; NAT-шлюз между ALB и целевыми инстансами в одном VPC не нужен.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Включите проверки состояния ELB для ASG, чтобы неработоспособные целевые инстансы заменялись, а не просто отменяли свою регистрацию. Межзоновая балансировка нагрузки (включена по умолчанию для ALB, опциональна для NLB) выравнивает распределение запросов независимо от количества инстансов в каждой зоне доступности. Route 53 должен разрешать доменное имя в адрес ALB через запись типа alias (или через взвешенную/основанную на задержке политику для нескольких ALB) — никогда не направляйте Route 53 на IP-адреса отдельных EC2, потому что сбойный инстанс будет продолжать получать трафик до истечения TTL, а замененный ASG инстанс будет иметь другой IP.

Модели закупки и смешанные парки экземпляров

Выбор модели закупки — это самый мощный рычаг для сокращения расходов на EC2, независимо от архитектурного шаблона.

Рациональная стратегия: базовая нагрузка на зарезервированных экземплярах (Reserved Instances) или с планом экономии (Savings Plan), всплески — на экземплярах по требованию (On-Demand), отказоустойчивые задачи — на спотовых (Spot). В ASG это выражается через политику смешанных экземпляров:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Диверсификация типов экземпляров увеличивает пул спотовых ресурсов и снижает вероятность коррелированных прерываний. Стратегия price-capacity-optimized (или capacity-optimized) балансирует цену и глубину пула, чтобы экземпляры с меньшей вероятностью были отозваны.

Спотовые экземпляры подходят для stateless-задач (без сохранения состояния), с возможностью создания контрольных точек, повторного выполнения или с горизонтальным резервированием: веб-воркеры за ALB, задания Batch с автоматическим повтором, исполнители Spark, CI-раннеры. Они не подходят в качестве единственной мощности для критически важных, постоянно работающих сервисов, stateful-баз данных или ведущих узлов без механизма восстановления — двухминутное уведомление не может гарантировать безопасное завершение работы, а коррелированный отзыв всех экземпляров определенного типа в парке является реальным сценарием сбоя. Если требование гласит «работа не должна прерываться», Spot-экземпляры исключаются.

Обратная ловушка — применять RI или Savings Plans к действительно переменным нагрузкам: вы платите за почасовое обязательство независимо от использования, поэтому рабочая нагрузка, работающая 40 часов в неделю при 168-часовом обязательстве, тратит впустую 76% резервирования. Когда важна сама мощность, а не цена (всплески, вызванные событиями, аварийное восстановление), используйте On-Demand Capacity Reservation: это чистая гарантия мощности в пределах одной зоны доступности (AZ) по тарифам On-Demand, которую можно комбинировать с Savings Plan для получения скидки.

Бессерверные вычисления: Lambda и Fargate

Бессерверные технологии переносят управление мощностями на платформу. Lambda подходит для краткосрочных задач, управляемых событиями: триггеры S3 ObjectCreated, потоки DynamoDB Streams, потребители SQS с низким объемом, бэкенды API Gateway, связующая логика (glue logic). Память (128 МБ – 10 240 МБ) выделяет ЦП пропорционально, поэтому увеличение памяти часто снижает стоимость за счет сокращения времени выполнения. Жесткие ограничения определяют область ее применения: максимальное время выполнения 15 минут, 10 ГБ памяти, 10 ГБ в /tmp, 250 МБ развернутого кода в несжатом виде (или 10 ГБ через образ контейнера), 6 МБ полезной нагрузки при синхронном вызове. Использовать Lambda для 30-минутного транскодирования видео, многочасового ETL-процесса или обучения на GPU архитектурно неверно — функция прервется по таймауту в середине работы, а логика повторных попыток только умножит потери. Для путей, чувствительных к задержкам, смягчайте холодные запуски и время инициализации ENI при подключении к VPC с помощью Provisioned Concurrency.

Fargate запускает контейнеры без управления хостами EC2. Это правильный выбор, когда задачи длятся более 15 минут, требуют кастомных сред выполнения или подходят для оркестрации ECS/EKS, но команда не хочет управлять мощностями. Fargate дороже в расчете на vCPU-час, чем EC2 Spot, поэтому при высокой и предсказуемой постоянной утилизации смешанный ASG со Spot-экземплярами на ECS будет дешевле. Для пиковых или непредсказуемых нагрузок выигрывает посекундная тарификация Fargate.

Для оркестрации множества Lambda-функций Step Functions предпочтительнее, чем их связывание через SNS/SQS, поскольку он предоставляет визуальную историю выполнения, семантику повторных попыток, централизованную обработку ошибок и сохраняемое состояние. Стандартные рабочие процессы (Standard workflows) тарифицируются за каждый переход состояния и могут выполняться до года; экспресс-процессы (Express workflows) оптимизированы для обработки большого объема коротких событий.

Для веерного распределения тысяч параметризованных контейнерных заданий — геномика, Монте-Карло, ETL — AWS Batch управляет очередями, разрешением зависимостей, повторными попытками и выделением ресурсов на управляемых EC2, Spot или Fargate. Задания ссылаются на определение задания (контейнер + vCPU/память + IAM-роль), и Batch плотно упаковывает их на экземпляры подходящего размера. Step Functions часто оркестрирует Batch, Lambda и ECS в рамках одного конечного автомата.

Elastic Beanstalk

Beanstalk — это управляемая PaaS, которая разворачивает ALB, ASG, экземпляры EC2 и, опционально, RDS из пакета приложения. Он поддерживает скользящие (rolling), скользящие с дополнительной партией (rolling-with-additional-batch), неизменяемые (immutable) и сине-зеленые (blue/green) развертывания с интеграцией CloudWatch. Политики масштабирования доступны как опции окружения (метрика, пороговые значения, min/max). Поскольку Beanstalk по умолчанию использует экземпляры с переменной производительностью (burstable), включение режима T-unlimited — это простое решение для кратковременной пиковой нагрузки на ЦП. Запланированные действия по масштабированию привязываются к управляемой Beanstalk группе ASG, как и к любой другой. Выбирайте Beanstalk, когда команде нужна стандартная топология веб-приложения без ручного написания CloudFormation и когда скользящие обновления и версионированные пакеты соответствуют циклу релизов.

Управление парком инстансов с помощью Systems Manager

Схемы с использованием SSH и бастион-хостов хрупки и дороги в обеспечении безопасности. AWS Systems Manager приходит им на смену. Всё, что нужно, — это SSM Agent (предустановлен на Amazon Linux 2, Ubuntu, Windows) и профиль инстанса с правами AmazonSSMManagedInstanceCore.

• Run Command выполняет команды shell/PowerShell на парках инстансов, отфильтрованных по тегам, с консолидированным выводом.
• Session Manager открывает интерактивные сессии через AWS API — без входящего порта 22, без бастиона, с полной аутентификацией через IAM, а сессии логируются в S3 или CloudWatch Logs.
• Patch Manager устанавливает патчи ОС по расписанию, используя окна обслуживания.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Автоматизация запуска и остановки по расписанию

Для непроизводственных инстансов EC2 и RDS, которые должны быть выключены в нерабочее время, простая в обслуживании схема — это EventBridge Scheduler → Lambda. Правило cron (cron(0 19 ? * MON-FRI *)) вызывает Lambda-функцию, которая останавливает ресурсы с определёнными тегами; второе правило в 07:00 запускает их.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Это бессерверное решение, не требующее обслуживания парка серверов, и оно масштабируется по тегам. Решение AWS Instance Scheduler работает аналогичным образом. Нюанс: остановленный инстанс RDS автоматически запускается через семь дней, поэтому расписание остановки должно повторяться, чтобы снова его остановить. В сочетании с ASG, где запланированные действия обнуляют ёмкость на выходных, стоимость в часы простоя приближается к нулю.

Сетевые ловушки при масштабировании вычислительных ресурсов

Размещение NAT Gateway. NAT-шлюз располагается в одной зоне доступности (AZ). Парк инстансов, охватывающий три AZ, который маршрутизирует весь исходящий трафик через один NAT-шлюз в us-east-1a, будет платить за межзоновую передачу данных для каждого пакета из us-east-1b/us-east-1c и полностью потеряет доступ в интернет при деградации us-east-1a. Правильная схема — по одному NAT-шлюзу на каждую AZ, при этом таблица маршрутизации каждой частной подсети указывает на NAT-шлюз в своей же AZ. Это локализует трафик и устраняет отказ из-за сбоя в одной AZ.

NAT-инстансы. Один NAT на базе EC2 становится узким местом по пропускной способности и количеству пакетов в секунду (PPS) по мере роста парка инстансов, а также является единой точкой отказа (SPOF). Управляемые NAT Gateways масштабируются до 100 Гбит/с на шлюз. Для трафика к сервисам AWS VPC-эндпоинты (Gateway для S3/DynamoDB, Interface для остальных) позволяют полностью обойти NAT, сокращая затраты и устраняя риск перегрузки во время событий масштабирования.

Типичные ошибки проектирования

• ASG в одной зоне доступности не переживут сбой AZ — всегда подключайте подсети как минимум из двух AZ (из трёх для систем, требующих кворума) и поддерживайте MinSize ≥ 2.
• Предположение, что любая нагрузка масштабируется горизонтально. Приложения, хранящие состояние, с одним пишущим процессом или с некластеризуемыми лицензиями работают хуже под управлением ASG. Сначала используйте автоматическое восстановление или проведите рефакторинг.
• Реактивное масштабирование для предсказуемых пиков приводит к симптому «вялой работы в первые 2–3 часа». Используйте масштабирование по расписанию или предиктивное масштабирование для предварительного «прогрева».
• Масштабирование по CPU, когда CPU не является узким местом. Публикуйте метрику, отражающую реальное узкое место — глубину очереди, время ответа, количество соединений.
• Simple scaling и launch configurations — это устаревшие подходы; предпочитайте target tracking и launch templates.
• Проверки работоспособности только по TCP для HTTP-приложений оставляют неработающие инстансы в ротации. Используйте HTTP-проверки (через ALB или проверки NLB в режиме HTTP).
• Использование Spot для нагрузок, хранящих состояние, или тех, работа которых не должна прерываться — Spot требует воркеров, которые можно заменять и состояние которых можно сохранять (checkpointable).
• Использование Reserved Instances или Savings Plans для действительно переменных нагрузок — неиспользованные обязательства это пустая трата денег; вместо этого снижайте затраты за счёт подбора правильного размера инстансов (right-sizing) и использования Spot.
• Направление Route 53 на IP-адреса отдельных инстансов EC2 — направляйте трафик на alias ALB, чтобы DNS отражал изменения в составе парка.
• Отношение к instance store как к постоянному хранилищу — данные исчезают при остановке, терминировании или сбое хоста.
• Игнорирование задержек из-за «ленивой загрузки» (lazy-load) после восстановления из снимка или запуска AMI — включите Fast Snapshot Restore в целевых AZ.

Все домены · Контейнеры и оркестрация →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →