ℹ️ Оптимизация расходов на AWS SQS

Если вы используете AWS SQS с дефолтными настройками и у вас более миллиона сообщений в день, обратите внимание на параметр receive_wait_time_seconds.
По умолчанию его значение равно 0, что означает использование Short Polling.
При таком подходе AWS будет брать с вас плату за каждый API-запрос, даже если очередь пуста.
Что можно сделать:
Установите receive_wait_time_seconds = 20 в вашем Terraform-конфиге, чтобы включить Long Polling.
При этом режиме AWS будет удерживать соединение до 20 секунд в ожидании сообщений, что существенно сократит количество API-вызовов.
Результат:
В моём случае это снизило расходы примерно в 3 раза! Ваша экономия может отличаться в зависимости от паттерна использования очереди и частоты появления сообщений.
⚠️Важно:
Подходит для случаев, когда вам не критична минимальная задержка в получении сообщений.
Если ваш сценарий требует мгновенной обработки - оставьте Short Polling и платите больше.

#AWS #Terraform #CostOptimization

ℹ️Оптимизация расходов на AWS RDS Proxy и CloudWatch

Если у вас есть RDS MySQL с read replica и RDS proxy, то вы можете сильно сэкономить на CloudWatch логах.
Проблема:
- RDS Proxy по умолчанию отправляет ВСЕ логи уровня INFO в CloudWatch
- Это нельзя отключить через консоль или API
- Вы платите за:
1. Каждый входящий лог-ивент (PutLogEvent)
2. Хранение этих логов
- Большинство этих логов - просто информационные, не критичные для мониторинга
Решение:
1. Написать в AWS Support
2. Попросить изменить log level для RDS Proxy с INFO на ERROR
3. Profit!
Результат:
- Количество логов уменьшается в миллионы раз
- В нашем случае счёт за CloudWatch снизился на 170$ в месяц
Бонус-совет:
Даже если вам нужны некоторые логи, можно дополнительно уменьшить retention time в CloudWatch до 1 дня для экономии на хранении.

Да, это может показаться мелочью, но:
- Занимает 5 минут времени
- Требует только написать письмо
- Экономит реальные деньги, в моем случае аж $170 ежемесячно

#AWS #CostOptimization

Больше стал внедрять оптимизацию по ресурсам.
Понравилась утилита krr от робусты. Хотя саму робусту я, мягко говоря, недолюбливаю.
https://github.com/robusta-dev/krr
Использование простое, например вот так:

>./krr simple --history_duration=120

Оно показывает все рекомендации, как поправить CPU/Memory request/limits.
Исправляешь везде и скедулер куба работает точнее.
Не выделяются лишние ноды или наоборот не ощущается нехватка ресурсов с медленным скейлом нод.
Раз в квартал сделать оптимизации руками и всё ок.
У меня это встроено в скедулед пайплайн, который срабатывает раз в месяц, я прост смотрю отчёт.
В конечном итоге это нужно для оптимизации костов.

#kubernetes #CostOptimization

На всём времени моего опыта и пути для меня самым сложным оказалось работать с несколькими вещам, один из них это AWS Velocity mapping template.
Пока знания не обесценились, накидал простенькую статью на медиуме.
Вдруг кто тоже страдает этими болями.

https://medium.com/@kruchkov.alexandr/a-deep-dive-into-aws-api-gateway-velocity-mapping-templates-9a6c9f4ed742

#AWS #CostOptimization #SQS #Velocity

Перетащил на второй гравитрон пару старых кластеров.
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).

#AWS #CostOptimization

Самая удивительная особенность, которая обнаружилась после перехода RDS(8.0.mysql_aurora.3.08.0) на Gravitron v2, это способность на высокий утилизации CPU не снижать эффективность/производительность.
А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.

Когда был db.r5.2xlarge, при CPU usage 85-100% длительностью больше 10-15 минут начиналась небольшая, но деградация работы с базой данных.
Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для Debezium+Kafka для реалтайма)

Когда переключили на db.r6g.2xlarge при ровно таких же жёстких нагрузках:
- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.

Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена c5->r6 или же невероятная магия ARM у Gravitron.

* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.

#AWS #CostOptimization

#aws #eks #sqs #CostOptimization
Материал уровня middle.

Снова про экономию.

У нас есть AWS SQS.
В него прилетает миллион вебхуков с полезным и важным payload.
Бывают пики, бывают нет.
У нас есть AWS EKS и приложение в POD-e, который вычитывает SQS, процессит и всё ок.
Нам надо настроить масштабирование не за счёт CPU/memory usage, а за счёт количества сообщений.
В этом нам помогает KEDA. Опустим этапы установки/настройки/прав и авторизации.
У нас есть готовый манифест scaledobject.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  cooldownPeriod: 300
  maxReplicaCount: 50
  minReplicaCount: 2
  pollingInterval: 30
  scaleTargetRef:
    name: application
  triggers:
  - authenticationRef:
      name: keda-aws-credentials
    metadata:
      awsRegion: us-east-1
      identityOwner: operator
      queueLength: "500"
      queueURL: https://sqs.us-east-1.amazonaws.com/123456789/sqsname
    type: aws-sqs-queue

Всё работает, всё скейлится, всё ок.
В HPA некрасиво выглядят цифры, хочется видеть точное количество мессаджем. Добавляем metricType

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
...
    metricType: Value

И теперь в kubectl get hpa blablabla видим точное количество мессаджей в TARGETS(а не системы счисления инопланетян).
Этого нам мало, нужна точная подстройка.
Читаем дальше доку, у нас есть адвансед настройки.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          policies:
          - periodSeconds: 15
            type: Pods
            value: 1
          stabilizationWindowSeconds: 300
        scaleUp:
          policies:
          - periodSeconds: 15
            type: Pods
            value: 1
          selectPolicy: Max
          stabilizationWindowSeconds: 60
... (остальное так же)

Теперь у нас всё динамически скейлится, прописаны все триггеры, трешхолды.
Всё отлично и бизнес ликует(не вру, прям ликует, сильно помогло).

Однако меня, как рьяного и верного пса девопс церкви, напрягает, что в период высокой нагрузки всё упирается в максимум реплик. Да, можно поставить не 50, а 100, но я думаю, что настройка неверная.
Углубляемся дальше в доку(вру, я ничо не понял и просто спросил ребят-гуру-AWS-технологий в телеге) и вспоминаем про визибл/анвизибл настройки у sqs.
https://keda.sh/docs/2.14/scalers/aws-sqs/
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Окончательно пилим манифест.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  advanced:
...(тут тоже самое)
    metadata:
...
      scaleOnInFlight: "false"   << - - вот это вот важное нам
...

Отлично. Теперь самая точная и потрясающая настройка.

#troubleshooting #billing #CostOptimization #newrelic

Внезапно вырос ценник на newrelic.
Заметили не сразу, не было настроены алерты по биллингу.
Увидели лишь в начале месяца, при выставлении счёта.

Я не сильно тогда был знаком с newrelic, этой штукой обычно пользовались коллеги-разработчики, я больше по инфре и стеку с VM/Prometheus/Grafana, но деньги есть деньги, надо разбираться.

Поковырявшись в интерфейсе и немного документации, обнаружил, что деньги начали списываться в раздел логирования.
А ведь это странно, все логи у нас пишутся в ELK стек в самом кубе, зачем ещё и в newrelic писать, а там за каждый чих деньги просят.

Первым делом смотрю в ньюрелике кто именно пишет логи - ага, одно единственное приложение.
Иду в git, захожу в раздел PR, вижу там миллиард PR, закрываю, ибо даже с поиском ничего не найти.
Клонирую репозиторий, смотрю локально.
Ага, у нас агент newrelic ставится через Dockerfile

ENV NEWRELIC_VERSION 11.6.0.19
...
ADD https://download.newrelic.com/php_agent/archive/${NEWRELIC_VERSION}/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz /tmp/
RUN export NR_INSTALL_USE_CP_NOT_LN=1 NR_INSTALL_SILENT=1 \
    && tar -xf /tmp/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz -C /tmp \
    && /tmp/newrelic-php5-*/newrelic-install install \
    && rm -rf /tmp/*
...

Дальше ковыряюсь в конфигах самого приложения, но там ничего интересного.
Нет в явном виде "логирование енаблед тру" или подобного. Странно.
Ладно, ну поехали, смотрим через git кто когда вносил изменения в докерфайлэ, всё равно другой зацепки нет.

git log Dockerfile

И буквально через несколько коммитов вижу зацепку - коллега разработчик обновил версию newrelic.
Само собой нашёл и его PR и того, кто его аппрувил.
Но была обновлена только версия, больше ничего не менялось.
Херня какая.

Ладно, иду в POD, смотрю конфиг, а что внутри

cat /usr/local/etc/php/conf.d/newrelic.ini

и поиском вижу там нечто типа

newrelic.application_logging.enabled = true

Пилю себе ветку, в этой ветке делаю даунгрейд до старой версии newrelic, собираю имадж, смотрю в нём конфиг

newrelic.application_logging.enabled = false

Да бл.

Бегу в документацию и нахожу
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/

PHP agent version 10.1.0 lets you forward your PHP logs with APM logs in context. As of version 10.3.0, the logging metrics and agent log forwarding features are enabled by default. The value newrelic.application_logging.enabled controls whether or not the logs in context feature is active or inactive.

От суки, ладно, пилю быстрофикс (не удивлюсь, если он до сих пор там в докерфайле, лол).

RUN sed "s/^.*;newrelic.application_logging.enabled.*/newrelic.application_logging.enabled = false/" \
    -i /usr/local/etc/php/conf.d/newrelic.ini

Качу PR, аппрув, мерж, логи перестали идти в newrelic, прайс не растёт.

Ну а дальше как обычно: оповещение коллегам, ата-та так не делайте плиз, читайте доки перед апдейтом(да ладно, кому я вру, я бы тоже не читал), вот рут коз, вот фикс, вот ссылки, вот пруфы.
Все виновато покивали и сделали вид, что запомнили и не повторят ошибок. Да.

Потеря денег всего $460 за пару недель.
Идём работать дальше.

#aws #costoptimization #devops

А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.

Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.

Всё вышенаписанное лишь для того, чтобы подчеркнуть, что ничего нестандартного тут не было, всё как у всех.

Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.

Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг

Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.

Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.

Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.

Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.

В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.

Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.

#costoptimization #newrelic

И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"

"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".

Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц

Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим

Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing

Да, всё так и есть, лицензии и трафик.

Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.

Ingestion. Из чего ты состоишь?
https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.

Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.

На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу

SELECT bytecountestimate()/10e8 FROM `Span`, `SpanEvent` WHERE instrumentation.provider != 'pixie' FACET appName OR service.name OR entity.name LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ ивентов

SELECT bytecountestimate()/10e8 FROM `Transaction`, `TransactionError` FACET appName LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ метрик

SELECT bytecountestimate()/10e8 FROM `Metric` WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie' FACET CASES (WHERE newrelic.source = 'agent' AS 'Metric Time Slices', WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics') SINCE unixtimestamp UNTIL unixtimestamp

Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.

Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее

В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:

newrelic выезжает на дефолтах

Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.

Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование

newrelic.span_events.max_samples_stored       = 200   # was 2000

- в golang, например

NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED=200  # was 1000 (default)
NEW_RELIC_TRANSACTION_EVENTS_MAX_SAMPLES_STORED=2000  # was 10000 (default)
NEW_RELIC_APPLICATION_LOGGING_FORWARDING_ENABLED=false # was true (default)

+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.

Что же я сделал? Я уменьшил количество семплов в минуту.

Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.

Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.

#costoptimization #newrelic

Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.

В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/

Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами

Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.

#costoptimization #aws #cloudwatch #одинденьизжизни

"Алекс, у нас снова траты по амазон, глянь по биллингу, чего можно скостить".

Иду в billing, выбираю последний месяц.
Дааа, много всего опять зачарджило. Чего можно убрать?
О, в топ 10 есть клаудвоч. Начну с него. Почему так много? Почти $2000+.
Смотрю что не так.
Внезапно много идет за графу

$0.01 per 1,000 metrics requested using GetMetricData API - US East (Northern Virginia)

200.000.000+ реквестов.
Читаю что это.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html

Ага. Какой-то сторонний механизм/утилита, которая при помощи кредов/роли подключается к AWS API и вытягивает данные по метрикам из клаудвоч.

Из известного мне есть такие два инструмента:
- https://github.com/prometheus/cloudwatch_exporter
- https://github.com/prometheus-community/yet-another-cloudwatch-exporter

Оба эти категории инструмента подключаются к AWS API, дергают метрики, экспортируют в удобный формат, чтобы можно было в victoria metrics/prometheus/grafana видеть эти новые метрики.
Почему новые? Они берут оригинальное название метрики, добавляют префикс и получается новая метрика в нашем хранилище.

Далее поиском по всем репозиториям(гит, арго, хелм) внутри компании ищу - есть ли они у нас.
Да, есть, у нас YACE.

Как оптимизировать? Мне ничего в голову не приходит, как сделать следующее:
- подключаюсь к service через порт форвард

kubectl port-forward svc/yet-another-cloudwatch-exporter 5000:5000

- вытягиваю все метрики в файл

curl localhost:5000/metrics > metrics.txt

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

Ага, у нас 54.000+ метрик. Это много.
Иду в конфиг в гите, там нечто типа

config: |-
    apiVersion: v1alpha1
    discovery:
      exportedTagsOnMetrics:
        AWS/NetworkELB:
          - tenant-id
          - type
          - cluster
      jobs:
        - type: AWS/NetworkELB
          regions:
            - us-east-1
...
            - eu-central-1
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveFlowCount
              statistics: [Average, Minimum, Maximum]
            - name: ActiveFlowCount_TLS
              statistics: [Average, Minimum, Maximum]
...
            - name: UnHealthyHostCount
              statistics: [Average, Minimum, Maximum]
            - name: PortAllocationErrorCount
              statistics: [Sum]
...
        - type: AWS/TransitGateway
          regions:
            - us-east-1
...
          period: 300
          length: 300
          metrics:
            - name: BytesIn
              statistics: [Average, Minimum, Maximum, Sum]
            - name: BytesOut
              statistics: [Average, Minimum, Maximum, Sum]
            - name: PacketsIn
              statistics: [Average, Minimum, Maximum, Sum]
...
        - type: AWS/NATGateway
          regions:
            - us-east-1
...
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveConnectionCount
              statistics: [Maximum, Sum]
            - name: BytesInFromDestination
              statistics: [Sum]
...

И такого там много.

По частоте опроса вроде ок - 300 секунд, около бест практис для клаудвоч экспортёров.
А чего подрезать-то тогда?
Нужен ли max? Min? Avg?
Следим ли мы за натгейтвеем?

А всё просто.
- при том же bash скрипте расписываем все уникальные метрики и их итоговое название.
- идём все репозитории с алертингом и мониторингом (alertmanager, grafana irm, vmalert, grafana dashboards etc)
- если метрика нигде в observability не используется - мы её просто убираем из конфига. Где-то только min, где-то max, где-то полностью всю метрику со всеми значениями

Даже если удастся убрать хотя бы 50% неиспользуемых метрик - это минус 50% от биллинга, а это $1000+
Пулл реквест, ревью, аппрув, раскатываем.
Всё, в следующем месяце ждём снижения костов на клаудвоч на 50%+