Amazon CLF-C02: Облачные концепции — Руководство по подготовке

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Основные концепции облака и ценностное предложение AWS

Облачные вычисления переводят капиталоемкие задачи по планированию мощностей в операционную модель, где вычислительные ресурсы, хранилища и сетевые службы потребляются по требованию. AWS обеспечивает эластичность (автоматическое масштабирование для соответствия нагрузке), глобальный охват (регионы и зоны доступности для локализации и изоляции сбоев) и спектр управляемых сервисов, которые избавляют от недифференцированной тяжелой работы. Архитектурные концепции, такие как проектирование с расчетом на отказ, слабая связанность и неизменяемая инфраструктура, помогают командам использовать преимущества облака: ускорение вывода продуктов на рынок, экономика оплаты по факту использования и глобальный масштаб. Сетевые примитивы, такие как VPC, подсети и Internet Gateway, контролируют входящий и исходящий трафик для рабочих нагрузок, в то время как Direct Connect предлагает выделенный высокопроизводительный канал к локальным центрам обработки данных, когда требуется предсказуемая пропускная способность или более низкая задержка. Для очень крупных физических миграций или при прерывистом подключении устройства Snowball Edge обеспечивают безопасную офлайн-передачу данных и даже периферийные вычисления. Распространенные ловушки для практиков включают предположение, что “lift-and-shift” автоматически сократит расходы, недооценку платы за исходящий сетевой трафик и отказ от проектирования с учетом отказоустойчивости на уровне нескольких зон доступности (multi-AZ). Критерии принятия решений должны взвешивать требования бизнеса к доступности, гравитацию данных, ограничения по задержкам и долгосрочные операционные расходы перед выбором стратегий rehost, replatform или refactor.

Сервисы, паттерны миграции и архитектурные решения

Выбор правильного сервиса AWS зависит от того, нужны ли вам управляемые операции, контроль над обязанностями на уровне ОС или возможности для периферийных/офлайн-вычислений. Паттерны миграции включают rehost (lift-and-shift), replatform (внесение небольших оптимизаций) и refactor (перепроектирование под облачные технологии). Выбор хранилища отражает паттерны доступа: S3 для объектного хранения и озер данных, EBS для блочного хранения, подключаемого к EC2, EFS для общих файловых систем POSIX и варианты FSx для управляемых систем Windows или высокопроизводительных файловых хранилищ. Базы данных можно запускать как управляемые сервисы, такие как Amazon RDS и Amazon DynamoDB, которые снимают с вас административные задачи, или управлять ими самостоятельно на EC2, где клиент сохраняет ответственность за ОС, установку исправлений, резервное копирование и масштабирование. Для контейнеров управляемые опции снижают операционную нагрузку, предлагая при этом различные компромиссы:

Amazon ECS (тип запуска EC2): управляемая оркестрация, но вы управляете хостами EC2.
Amazon ECS / Fargate: бессерверные контейнеры без управления хостами.
Amazon EKS: управляемый control plane для Kubernetes; вы можете управлять узлами или использовать Fargate. Для быстрого развертывания приложений без ручного создания каждого ресурса AWS Elastic Beanstalk или шаблоны CloudFormation ускоряют доставку, обеспечивая при этом соблюдение стандартных архитектур. Ловушки для практиков включают недооценку операционных усилий по самостоятельному управлению базами данных или хостами контейнеров и забвение о необходимости прикреплять профили инстансов IAM к EC2 для безопасного доступа к сервисам.

Экономика облака: модели ценообразования и практики оптимизации затрат

AWS предлагает несколько моделей ценообразования, соответствующих предсказуемости рабочей нагрузки и устойчивости к прерываниям. On-Demand гибки и не требуют обязательств, Reserved Instances и Savings Plans предоставляют значительные скидки для стабильного использования, Spot Instances имеют очень большие скидки, но могут быть прерваны, а Dedicated Hosts отвечают нормативным или лицензионным требованиям. Прозрачность и контроль затрат основываются на тегировании, Cost Explorer, AWS Budgets и AWS Cost Anomaly Detection; инструменты для подбора оптимального размера (rightsizing), такие как AWS Compute Optimizer и рекомендации по ресурсам в Cost Explorer, помогают выявлять избыточно подготовленные инстансы EC2. Trusted Advisor выявляет возможности для оптимизации затрат и производительности и подсвечивает бесхозные ресурсы, в то время как AWS Budgets может инициировать оповещения SNS при превышении пороговых значений расходов. Распространенные ловушки включают покупку Reserved Instances или Savings Plans без анализа исторического использования, применение Spot Instances для критически важных, не допускающих прерываний рабочих нагрузок, и отказ от внедрения последовательного тегирования, что подрывает усилия по распределению затрат (chargeback) и оптимизации. Критерии принятия решений должны сочетать паттерны рабочей нагрузки, устойчивость к прерываниям и прогнозирование: используйте On-Demand для непредсказуемых нагрузок, Savings Plans или RI для устойчивой базовой нагрузки и Spot для гибких, отказоустойчивых вычислений.

Безопасность, модель разделения ответственности и лучшие практики эксплуатации

Безопасность в AWS основана на модели разделения ответственности: AWS обеспечивает безопасность облачной инфраструктуры (оборудование, сеть, регионы, зоны доступности и базовые сервисы), а клиенты отвечают за безопасность в облаке. Это включает в себя данные, контроль доступа, шифрование на уровне приложений, установку исправлений для ОС и ПО в моделях IaaS, а также федерацию удостоверений. Используйте IAM-роли, прикрепленные к профилям экземпляров EC2, для предоставления временного доступа к сервисам, таким как S3, с минимальными привилегиями; избегайте встраивания долгосрочных учетных данных в экземпляры. Функции защиты данных включают версионирование и Object Lock в S3 для хранения, шифрование на стороне сервера (SSE) и шифрование на стороне клиента для конфиденциальных записей. Мониторинг и аудит обеспечиваются с помощью CloudTrail для логирования API-вызовов, AWS Config для контроля соответствия конфигураций, Amazon Inspector для оценки уязвимостей в рабочих нагрузках EC2, GuardDuty для обнаружения угроз и Amazon Macie для поиска конфиденциальных данных в S3. Well-Architected Framework служит руководством по вопросам эксплуатации, безопасности, надежности, производительности и затрат; распространенные ошибки специалистов включают чрезмерное использование корневого аккаунта, пренебрежение автоматическим резервным копированием и отказ от реализации архитектур с несколькими зонами доступности (multi-AZ) или планов аварийного восстановления (Disaster Recovery). При принятии эксплуатационных решений следует отдавать приоритет автоматизации, принципу минимальных привилегий и централизованному сбору логов для снижения человеческих ошибок и ускорения реагирования на инциденты.

Практическая задача: Пример использования

Сценарий: Компания Acme Analytics запускает сезонный конвейер обработки данных в одном регионе AWS. Их среда включает экземпляры EC2 для вычислений, локальный архив (on-premises) и озеро данных на S3. Им необходимо каждый сезон загружать 50 ТБ данных из локальной среды, обеспечивать высокую доступность во время работы и контролировать затраты в межсезонье.

Задача: Массовая передача 50 ТБ данных при ограниченной пропускной способности сети с необходимостью надежной и аудируемой загрузки; вычислительные ресурсы должны быть высокодоступны в течение двухмесячного окна обработки и экономичны в периоды простоя.

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

Заказать Amazon Snowball Edge для безопасного импорта 50 ТБ данных в Amazon S3, используя периферийные вычисления (edge compute), если требуется предварительная обработка.
Хранить загруженные данные в бакете S3 с включенным версионированием и применить S3 Object Lock для удержания исходных записей.
Выполнять обработку в группах Auto Scaling с экземплярами EC2, распределенными по нескольким зонам доступности, или использовать AWS Batch/ECS Fargate для управляемого масштабирования в течение двухмесячного периода.
Внедрить Cost Explorer, AWS Budgets с оповещениями и применять Savings Plans или Reserved Instances только для базовых постоянных ресурсов; останавливать или сокращать вычислительные мощности после окончания сезона.

Обоснование: Snowball Edge минимизирует время передачи и сетевые затраты при крупных разовых импортах, в то время как S3 обеспечивает надежное и аудируемое хранилище. Использование Auto Scaling или управляемых вычислительных сервисов в пиковые месяцы обеспечивает доступность и требует затрат только во время обработки, а инструменты управления затратами предотвращают непредвиденные расходы.

Все домены · Глобальная инфраструктура AWS →

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