Amazon SAP-C02: Вычисления и Auto Scaling — Руководство по подготовке

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Проектирование, хранилище и сеть для экземпляров EC2

Проектирование экземпляров EC2 начинается с сопоставления характеристик рабочей нагрузки с семействами экземпляров, балансируя vCPU, память, сеть и локальное хранилище. Выбирайте типы, оптимизированные для вычислений (C), для работы с памятью (R/X), для хранения данных (I/D) или с GPU (P/G), основываясь на профилировании. Используйте экземпляры на базе Nitro и ENA/SR-IOV для высокой пропускной способности сети и низкой задержки. Для временных данных, чувствительных к задержкам или требующих высоких IOPS, рассмотрите instance store (эфемерное хранилище) на I3/I4 или Nitro SSD; для постоянного блочного хранилища используйте EBS с Provisioned IOPS (io2/io2 Block Express) и включите шифрование EBS с помощью KMS для управления ключами. Когда экземпляры находятся в VPC за Application Load Balancers, убедитесь, что ALB, доступные из интернета, размещены в публичных подсетях, а целевые экземпляры (targets) — в приватных; неправильное размещение ALB или неверная настройка групп безопасности — распространенная ошибка. Используйте Placement Groups (cluster для HPC с низкой задержкой, partition для крупномасштабных распределенных систем с состоянием, spread для изоляции от сбоев), чтобы влиять на размещение, но принимайте компромиссы: cluster обеспечивает наилучшую производительность, но снижает отказоустойчивость на уровне AZ. Для шифрования данных при передаче используйте TLS с терминированием на ALB или сквозное шифрование TLS с NLB passthrough. Критерии принятия решений взвешивают стоимость и производительность: более плотные типы экземпляров снижают затраты, но могут увеличить радиус поражения (blast radius) и расходы на лицензирование; предпочитайте правильный подбор размера (right-sizing) на основе данных CloudWatch, AWS Compute Optimizer и нагрузочных тестов, а не общих правил.

Группы Auto Scaling, политики и управление жизненным циклом

Группы Auto Scaling (ASG) следует проектировать для эластичности, отказоустойчивости и экономической эффективности, используя комбинацию шаблонов запуска (launch templates), политик смешанных экземпляров (mixed-instances policies), хуков жизненного цикла (lifecycle hooks) и политик масштабирования. Используйте шаблоны запуска для версионирования AMI, переопределения типов экземпляров, конфигураций EBS и пользовательских данных (user-data); политики смешанных экземпляров с распределением Spot-экземпляров по принципу capacity-optimized или диверсифицированной стратегией снижают риск прерываний и уменьшают затраты. Для управления масштабированием предпочитайте политики отслеживания целевого значения (target-tracking) для предсказуемых метрик (CPU, количество запросов на цель) и пошаговое масштабирование (step-scaling), когда требуются многоэтапные действия на основе пороговых значений; прогнозное масштабирование (predictive scaling) может заранее подготавливать мощности для известных суточных циклов. Реализуйте хуки жизненного цикла для выполнения пользовательской инициализации или задач по выводу из эксплуатации (drain tasks) перед завершением работы экземпляра; комбинируйте их с теплыми пулами (warm pools) для сокращения времени до начала обслуживания запросов и с масштабированием по расписанию (scheduled scaling) для установки базовой нагрузки в рабочие часы. Проверки состояния (health checks) должны интегрировать проверки состояния ELB и EC2, чтобы избежать преждевременной замены экземпляров. Остерегайтесь таких ловушек, как постоянное уменьшение и увеличение группы (scale-in churn) из-за агрессивных периодов восстановления (cooldowns), неправильное взвешивание экземпляров в смешанных ASG и отсутствие учета времени на «прогрев» приложения. Для сервисов с состоянием избегайте быстрого уменьшения масштаба (scale-in), которое приводит к потере кэшей в памяти; в вопросе стоимости против отказоустойчивости, использование Spot-мощностей с переключением на On-Demand в качестве резерва предлагает экономию, но требует обработки прерываний, в то время как 100% On-Demand максимизирует предсказуемость при более высокой стоимости.

Контейнеры и оркестрация: выбор между ECS, EKS и Fargate

Выбор между Amazon ECS, EKS и Fargate зависит от операционной модели, потребностей в контроле и характера рабочей нагрузки. Fargate избавляет от необходимости управлять узлами и идеально подходит для команд, которые ценят простоту эксплуатации, но имеет более высокую цену за vCPU и ограничения на эфемерное хранилище; он поддерживает Fargate Spot для экономии средств. ECS обеспечивает тесную интеграцию с AWS и простоту для клиентов, которым нужна оркестрация контейнеров без сложностей Kubernetes. EKS подходит, когда требуется экосистема Kubernetes, переносимость или расширенные возможности планирования; рассмотрите управляемые группы узлов (managed node groups) или Self-Managed + Karpenter для динамического подбора размера (right-sizing). Сетевые ограничения (плотность ENI/подов) и поведение CNI влияют на плотность подов и размер узлов; в EKS использование IAM Roles for Service Accounts и EBS CSI для постоянных томов (persistent volumes) уменьшает разрастание учетных данных и позволяет выделять хранилище для каждого пода. Для общих файловых систем используйте EFS (NFS) или FSx (Lustre) в зависимости от требований к пропускной способности и задержке; избегайте использования контейнеров с хранилищем на базе NFS для операций с большим количеством метаданных — предпочитайте EFS с режимами пропускной способности, настроенными под рабочую нагрузку. Внедряйте cluster autoscaler или Karpenter для масштабирования узлов и автоматическое масштабирование сервисов с помощью метрик ALB/ECS service. Распространенные ошибки включают игнорирование бюджетов на прерывание работы подов (pod disruption budgets), недооценку квот control plane Kubernetes и избыточное выделение ресурсов узлов вместо использования стратегий плотной упаковки (bin-pack); выбор должен основываться на компромиссах между контролем, стоимостью и операционными издержками.

Паттерны бессерверных вычислений, ограничения Lambda и событийно-ориентированное проектирование

Бессерверные вычисления (Serverless) снижают операционную нагрузку, но требуют архитектурных паттернов, которые учитывают параллелизм, состояние и ограничения нижестоящих систем. Lambda отлично подходит для кратковременных, событийно-ориентированных задач, бэкендов API через API Gateway или ALB, а также для асинхронной обработки с помощью SQS или SNS. Используйте Step Functions для оркестрации длительных рабочих процессов и DynamoDB или RDS Proxy для доступа к базам данных, чтобы смягчить шторм подключений (connection storms). Помните о накладных расходах на холодный старт Lambda в VPC, вызванных созданием ENI; смягчайте их с помощью provisioned concurrency для чувствительных к задержкам эндпоинтов или используйте VPC endpoints и RDS Proxy для ограничения подключений. Реализуйте паттерн fan-out/fan-in через SNS + SQS или Kinesis/MKS для упорядоченной потоковой обработки; используйте очереди недоставленных сообщений (dead-letter queues) SQS и идемпотентные обработчики для управления повторными попытками и дубликатами. Ограничения параллелизма (concurrency limits), зарезервированный параллелизм (reserved concurrency) и троттлинг (throttling) следует планировать, чтобы избежать каскадных сбоев; проектируйте с учетом противодавления (backpressure), используя троттлинг, повторные попытки с джиттером (jitter) и прерыватели цепи (circuit breakers) (в API Gateway или кастомные). Компромиссы между стоимостью и производительностью очевидны: Lambda экономически эффективна для пиковых, кратковременных нагрузок, в то время как Fargate или EC2 лучше подходят для длительных задач с высокой загрузкой ЦП или долго выполняющихся процессов. Распространенные ловушки включают в себя зависимость от синхронных повторных попыток, которые перегружают нижестоящие системы, хранение состояния в локальном каталоге /tmp в расчете на его постоянство, и отсутствие подготовки к холодным стартам в критически важных к задержкам потоках.

Практическая задача: миграция контакт-центра NovaTel Enterprise

Сценарий: NovaTel Enterprise управляет гибридным контакт-центром с локальной маршрутизацией вызовов и подключением Direct Connect к AWS. Они используют брокеры сессий на EC2 в двух зонах доступности (Availability Zones) и хотят перейти на управляемый AWS контакт-центр с высокой доступностью и предсказуемой задержкой между локальной PBX и облачными сервисами.

Задача: Им требуется подключение с низкой задержкой для SIP-трафика, масштабируемый вычислительный уровень для обработки голоса, устойчивый к прерываниям спотовых инстансов (spot interruptions), и стратегия аварийного восстановления (DR) между регионами без увеличения операционной сложности.

Рекомендуемый подход:

Развернуть Amazon Connect для функциональности контакт-центра и использовать Site-to-Site VPN или Direct Connect с AWS Transit Gateway для SIP-транкинга с низкой задержкой, терминируя трафик на NLB с TLS passthrough перед брокерами сессий.
Запускать компоненты обработки сессий в смешанной Auto Scaling Group с шаблонами запуска (launch templates), используя оптимизированные по емкости спотовые инстансы (capacity-optimized Spot) с резервным переключением на инстансы по требованию (On-Demand), и использовать группы размещения (Placement Groups) типа spread для изоляции сбоев критически важных брокеров.
Для медиаданных вызовов с отслеживанием состояния, требующих эфемерного хранилища с низкой задержкой, использовать инстансы на базе instance store (Nitro) для буферизации медиа и реплицировать метаданные сессий в DynamoDB или ElastiCache с репликацией multi-AZ; использовать RDS (Multi-AZ) или Aurora Global DB для постоянных данных с межрегиональными репликами чтения (cross-Region read replicas) для аварийного восстановления (DR).
Внедрить хуки жизненного цикла (lifecycle hooks) и теплые пулы (warm pools) для минимизации холодного старта брокеров, использовать взвешенную маршрутизацию (weighted failover) в Route 53 для межрегионального аварийного восстановления (DR), и CloudWatch + SNS/SQS для оповещений и автоматизированных сценариев аварийного переключения (runbooks).

Обоснование: Использование управляемых сервисов контакт-центра снижает операционную нагрузку, в то время как смешанные ASG со спотовыми инстансами (Spot) оптимизируют затраты; изоляция эфемерных медиаданных на instance stores сохраняет производительность, а репликация постоянного состояния в DynamoDB/ElastiCache плюс multi-AZ RDS/Aurora обеспечивает отказоустойчивость и быстрое аварийное переключение в соответствии с лучшими практиками профессиональной архитектуры.

← Безопасность · Все домены · Хранение и управление данными →

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