Основы оптимизации затрат и устойчивого развития

Пиллар Cost Optimisation посвящён предотвращению ненужных расходов и получению максимальной ценности от затрат на AWS. Часто именно этот пиллар даёт наиболее ощутимый немедленный эффект, поскольку в облаке легко выделить избыточные ресурсы. Основные принципы проектирования: внедрите финансовое управление облаком — рассматривайте стоимость как ключевой показатель. Перейдите к модели потребления — платите только за используемые ресурсы. Измеряйте общую эффективность — отслеживайте стоимость единицы деловой ценности. Сокращайте расходы на недифференцируемую тяжёлую работу — используйте управляемые сервисы вместо самостоятельного управления инфраструктурой.

Оптимизация размеров — наиболее эффективное действие для снижения затрат: выявление и устранение избыточно выделенных ресурсов. Распространённый сценарий — запуск крупных инстансов при первоначальном развертывании без последующего пересмотра их параметров. AWS Compute Optimizer анализирует показатели использования и рекомендует оптимальный тип инстанса. Типичный результат анализа: инстанс m5.4xlarge, загруженный на 5% CPU, следует заменить на t3.medium, что позволяет сэкономить 80% затрат на вычисления. Оптимизация размеров применяется к EC2, Lambda (память), RDS и томам EBS.

Для рабочих нагрузок со стабильной интенсивностью использования тариф On-Demand является самым дорогим вариантом. Значительную экономию дают следующие варианты: Reserved Instances (1 или 3 года) — до 72% экономии для предсказуемых рабочих нагрузок. Savings Plans — гибкое обязательство (до 66% экономии), применяемое к разным семействам инстансов и регионам. Spot Instances — до 90% экономии для прерываемых рабочих нагрузок (пакетная обработка, CI/CD, без сохранения состояния). Типичный парк, оптимизированный по затратам, сочетает все три варианта: Savings Plans для базовой нагрузки, Spot для пиков и On-Demand для особых случаев.

Spot Instances используют свободные мощности AWS со скидкой до 90%, но могут быть прерваны с уведомлением за 2 минуты, когда AWS потребуется вернуть мощности. Spot хорошо подходит для: пакетной обработки (с сохранением контрольной точки и возобновлением), агентов сборки CI/CD, веб-серверов без состояния (за ALB; ELB направляет запросы в обход прерванных инстансов) и рабочих узлов EMR и EKS. Используйте Spot Fleet или ASG с несколькими типами инстансов и AZ, чтобы распределить нагрузку между пулами и снизить риск прерывания.

Затраты на хранилище S3 можно значительно сократить, выбрав подходящий класс хранения и автоматизировав переходы. S3 Intelligent-Tiering автоматически перемещает объекты между уровнями доступа в зависимости от характера обращений — это особенно удобно, когда характер обращений неизвестен. Правила жизненного цикла переводят объекты по расписанию: из Standard → Standard-IA через 30 дней → Glacier через 90 дней → Deep Archive через 180 дней. Также рассмотрите S3 Select, чтобы получать только необходимое подмножество данных объекта и сократить затраты на передачу и обработку данных.

Без правильного тегирования невозможно понять, сколько тратит каждая команда или проект. Теги распределения затрат позволяют разбивать затраты по команде, проекту, среде или любому определённому Вами измерению. Активируйте теги в консоли Billing, а затем используйте AWS Cost Explorer, чтобы фильтровать и группировать затраты по тегу. Обязательное тегирование можно настроить с помощью политик тегов в AWS Organizations, а правила AWS Config использовать для обнаружения ресурсов без тегов. Это обеспечивает showback (видимость затрат) и chargeback (отнесение затрат) на отдельные команды.

Pillar Sustainability (добавленный в 2021 году) направлен на минимизацию воздействия облачных рабочих нагрузок на окружающую среду за счёт снижения энергопотребления и повышения эффективности. Принципы проектирования: понимайте своё воздействие — измеряйте углеродный след рабочих нагрузок. Сформулируйте цели в области Sustainability. Максимально используйте ресурсы — оптимизируйте размеры, чтобы не допускать простоя ресурсов. Заранее учитывайте и внедряйте более эффективное оборудование — используйте новейшие поколения инстансов. Используйте управляемые сервисы — AWS эксплуатирует центры обработки данных эффективнее большинства организаций.

Процессоры AWS Graviton (на базе ARM) обеспечивают до 60% более высокую энергоэффективность и на 20–40% лучшее соотношение цены и производительности по сравнению с инстансами x86. Инстансы Graviton3/4 (семейства c7g, m7g, r7g, t4g) доступны для большинства рабочих нагрузок EC2, Lambda и Fargate. Переход с x86 на Graviton одновременно улучшает Pillar Sustainability и Pillar Cost Optimisation: на одно вычисление требуется меньше ватт, а цены на инстансы ниже. Большинство рабочих нагрузок (Linux, приложения в контейнерах, JVM) можно перенести с минимальными изменениями.

Крупным источником неоправданных затрат и потерь энергии являются простаивающие ресурсы: инстансы EC2 с загрузкой CPU на уровне 1%, не подключённые тома EBS, неиспользуемые эластичные IP-адреса и забытые среды разработки и тестирования, работающие круглосуточно. Настройте расписание остановки и запуска для сред, не относящихся к PRODUCTION, с помощью правил EventBridge и автоматизации Systems Manager: останавливайте инстансы разработки в 18:00 и запускайте в 8:00. Используйте AWS Trusted Advisor и Cost Explorer для выявления простаивающих инстансов, неиспользуемых томов EBS и недоиспользуемых Reserved Instances.

Бессрочное хранение данных приводит к напрасному расходу энергии. Pillar Sustainability рекомендует внедрять политики жизненного цикла данных, чтобы автоматически удалять или архивировать данные, которые больше не нужны. Используйте правила S3 Lifecycle с датами истечения срока действия, чтобы удалять объекты после периода хранения. Используйте DynamoDB TTL для автоматического удаления старых записей. Используйте политики хранения CloudWatch Logs, чтобы удалять группы журналов через заданный период. Удаление ненужных данных снижает как затраты на хранение, так и энергию, необходимую для их хранения и охлаждения.

Cost Optimisation иногда вступает в противоречие с другими Pillar. Multi-AZ RDS удваивает затраты на базу данных, но требуется для Pillar Reliability. Репликация между регионами повышает надёжность, но увеличивает затраты на хранение и передачу данных. Активно-активная конфигурация в нескольких регионах снижает задержку (Pillar Performance Efficiency), но обходится в 2–3 раза дороже. Well-Architected Framework не утверждает, что всегда нужно выбирать самый дешёвый вариант, — он требует осознанно находить компромиссы между Pillar и документировать обоснование. На экзамене проверяется способность выбрать наиболее экономичное решение, которое при этом соответствует указанным требованиям.

Проверьте понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что Cost Optimisation объединяет оптимизацию размеров, модели закупок (Reserved/Savings Plans/Spot) и управление жизненным циклом S3, Sustainability сосредоточена на максимальном использовании ресурсов, применении инстансов Graviton и внедрении политик жизненного цикла данных, а компромиссы по затратам с другими Pillar следует выбирать осознанно, исходя из бизнес-требований. Теги затрат обеспечивают showback и chargeback между командами. Далее мы рассмотрим Well-Architected Tool и процесс проверки.