Amazon SAP-C02: Оптимизация затрат и управление — Руководство по подготовке

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

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

Прозрачность, распределение и отчетность по затратам

Достижение истинной прозрачности затрат начинается с последовательного, принудительного распределения затрат и высокоточной отчетности. Разверните AWS Organizations с назначенным платежным аккаунтом и включите консолидированную оплату, чтобы централизовать счета, сохраняя при этом разделение списаний по аккаунтам. Активируйте AWS Cost and Usage Report (CUR) с почасовой гранулярностью, доставкой в S3 и интеграцией с Amazon Athena, чтобы вы могли выполнять специальные запросы и объединять записи о затратах с метаданными ресурсов. Внедрите строгую стратегию тегирования: определите обязательный набор тегов для распределения затрат (среда, проект, владелец, бизнес-подразделение и центр затрат) и обеспечьте их применение при предоставлении ресурсов с помощью CloudFormation StackSets, политик контроля сервисов (Service Control Policies) для ограничения создания ресурсов без тегов и правил AWS Config Rules, которые оценивают и автоматически исправляют отсутствующие теги. Используйте Cost Explorer в паре с отчетами по зарезервированным сущностям и оптимизации размеров, чтобы понимать тенденции расходов и простаивающие мощности. Распространенные ловушки включают неполное покрытие тегами, которое искажает взаиморасчеты, использование только консоли биллинга без аналитики CUR и неучет затрат на передачу данных между аккаунтами или регионами. Компромиссы часто сводятся к выбору между своевременностью и гранулярностью: включение почасовых отчетов CUR и Athena требует больших затрат на обработку, но обеспечивает точную атрибуцию, необходимую для принятия бизнес-решений, в то время как грубые ежемесячные сводки дешевле в эксплуатации, но скрывают кратковременные всплески и неэффективные ресурсы.

Обязательства по ценам, оптимизация размеров и стратегия закупок

Оптимизация расходов по обязательствам требует выбора между Savings Plans, Reserved Instances и динамическим ценообразованием, таким как Spot, при одновременном использовании оптимизации размеров для соответствия мощностей профилям нагрузки. Начните с анализа шаблонов использования из Cost Explorer и Compute Optimizer, чтобы определить базовые уровни постоянной нагрузки на CPU/память и возможности для смены семейств или размеров инстансов. Отдавайте предпочтение Compute Savings Plans, когда необходима гибкость рабочих нагрузок между типами инстансов и регионами, и используйте EC2 Instance Reservations, когда конкретные семейства инстансов и размещение в зонах доступности (AZ) оправдывают более глубокие скидки. Используйте Spot для отказоустойчивых пакетных и микросервисных нагрузок, но избегайте Spot для сервисов с состоянием (stateful) в одной зоне доступности без надежной системы контрольных точек (checkpointing). Оптимизация размеров должна сочетать автоматические рекомендации от Compute Optimizer и Trusted Advisor с ручной проверкой, чтобы избежать чрезмерно агрессивного уменьшения размеров, влияющего на производительность. Остерегайтесь ловушек, включая принятие избыточных обязательств по 3-летним RI при неопределенных бизнес-прогнозах, недостаточное использование Savings Plans из-за отсутствия тегов или изолированного использования в рамках одного аккаунта, а также предположение о взаимозаменяемости семейств инстансов без тестирования. Компромиссы обычно заключаются в выборе между стоимостью и операционной гибкостью: более глубокие долгосрочные скидки снижают стоимость за единицу, но добавляют бизнес-риск, если спрос упадет или архитектура изменится; и наоборот, Spot и on-demand предлагают гибкость при более высокой стоимости за единицу.

Управление, применение политик и автоматизированное исправление

Централизованное управление устанавливает ограничительные барьеры, которые предотвращают неконтролируемые расходы, позволяя командам работать автономно. Используйте AWS Control Tower или хорошо спроектированную базовую конфигурацию Organizations для предоставления аккаунтов с предварительно настроенными ограничительными барьерами и централизованным логированием. Применяйте политики контроля сервисов (Service Control Policies), чтобы ограничить использование дорогостоящих сервисов или неутвержденных регионов, и развертывайте правила AWS Config Rules для обнаружения несоответствующих требованиям конфигураций, таких как публичные бакеты S3, инстансы завышенного размера или отсутствие шифрования и тегов. Интегрируйте AWS Budgets с автоматизированными действиями: установите пороговые значения бюджета, которые запускают уведомления SNS и автоматизированное исправление через Lambda или Systems Manager (например, остановка/завершение простаивающих инстансов или уменьшение класса инстанса RDS). Trusted Advisor дополняет управление, выявляя проверки для оптимизации затрат, но не следует рассматривать его как единственный сигнал; бесплатные проверки Trusted Advisor ограничены, а для получения подробной информации требуется план поддержки Business или Enterprise. Распространенные ловушки включают слишком огранительное использование SCP, блокирующее легитимные операционные изменения, الاعتماد исключительно на уведомления без автоматизированного принудительного применения и предоставление избыточных привилегий IAM, позволяющих обходить политики. Оценивайте решения по управлению, взвешивая автономию бизнеса в сравнении с риском: более строгие контроли предотвращают бесконтрольный рост затрат, но могут замедлять скорость работы и требуют четко определенного процесса обработки исключений.

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

Выбор архитектуры существенно влияет на текущие затраты. Перенесите раздачу больших объёмов контента и глобальное распространение на Amazon CloudFront, чтобы сократить количество запросов к источнику в S3 и плату за исходящий трафик (egress charges); используйте S3 Transfer Acceleration только тогда, когда выигрыш в задержке оправдывает более высокую стоимость передачи данных. Для архитектур, охватывающих несколько зон доступности (cross-AZ) и регионов (cross-Region), помните, что за передачу данных между зонами доступности (inter-AZ) может взиматься плата; по возможности проектируйте систему так, чтобы трафик оставался в пределах одной зоны доступности (intra-AZ), или агрегируйте трафик через региональные сервисы. Для распространения больших файлов рассмотрите использование Amazon S3 с многочастной загрузкой (multipart upload) и политиками жизненного цикла, S3 Intelligent-Tiering для данных с непредсказуемым доступом и EFS One Zone для рабочих нагрузок в одной зоне доступности, где компромисс в отказоустойчивости позволяет снизить затраты. При миграции контейнерных рабочих нагрузок сравните Fargate с ECS/EKS на базе EC2: Fargate упрощает эксплуатацию и снижает накладные расходы на управление кластером, но обычно стоит дороже в расчёте на vCPU/память, чем плотно укомплектованные группы узлов на базе EC2 Spot. Распространённые ошибки включают недооценку стоимости межрегиональной репликации, размещение логов с высокой частотой записи в классах хранения для нечастого доступа и предположение, что эндпоинты VPC бесплатны — они экономят на исходящем трафике NAT, но добавляют почасовую оплату и плату за гигабайт. Критерии принятия решений должны учитывать «гравитацию данных» (data gravity), требования SLA по задержке и потребности в долговечности: выбирайте более дешёвые хранилища или вычислительные ресурсы только там, где это позволяют требования к отказоустойчивости и производительности.

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

Сценарий: Acme Global Enterprises управляет зрелой средой AWS с 18 аккаунтами-участниками в рамках AWS Organizations, централизованным платящим аккаунтом и рабочими нагрузками в трёх регионах. У них частично внедрено тегирование, работает несколько долгоживущих парков EC2, и они активно используют S3 для аналитических данных.

Задача: Им необходимо сократить ежемесячные расходы на AWS на 20% в течение шести месяцев, сохраняя при этом SLA по производительности и позволяя автономным командам развёртывать новый функционал.

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

Включите Cost and Usage Report (CUR) с почасовой гранулярностью для выгрузки в S3 и интегрируйте его с Amazon Athena; создайте отчёты по зарезервированным инстансам и оптимизации размеров (rightsizing) в Cost Explorer за последние 6–12 месяцев.
Разверните Compute Optimizer и проанализируйте использование инстансов со стабильной нагрузкой; приобретите комбинацию Compute Savings Plans для широкого покрытия и однолетних Convertible RI для предсказуемых рабочих нагрузок, привязанных к определённому семейству инстансов.
Внедрите принудительное тегирование с помощью CloudFormation StackSets и правил AWS Config с автоматическим исправлением отсутствующих тегов; направляйте отчёты о затратах в разрезе тегов владельцам бизнес-подразделений и создайте AWS Budgets с автоматическим оповещением через SNS и исправлением через Lambda при превышении пороговых значений.
Перенесите статический и глобально распространяемый контент на Amazon CloudFront, переведите редко используемые данные в S3 Intelligent-Tiering с переходами по жизненному циклу и определите пакетные задания, подходящие для инстансов Spot с сохранением состояния (checkpointing), чтобы перевести их с мощностей по требованию (on-demand).

Обоснование: Централизованная видимость (CUR + Athena) выявляет конкретные возможности для оптимизации размеров (rightsizing) и покупки зарезервированных мощностей, в то время как автоматизированные средства контроля (Config, StackSets, Budgets) обеспечивают распределение затрат и предотвращают регрессии; комбинирование Savings Plans с выборочными RI позволяет сбалансировать глубину скидки и гибкость для надёжного сокращения затрат без ущерба для производительности.

← Отказоустойчивость · Все домены · Развертывание →

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