Cost Explorer — это не ответ

Недавно я запустил и начал распространять Руководство разработчика по AWS. Руководство разработчика по AWS — это мой проект с открытым исходным кодом, в котором я делюсь методами анализа биллинговых данных AWS с помощью SQL.

Отзывы, которые я получил от сообщества разработчиков, были просто невероятными. Я ценю время, которое люди потратили на то, чтобы проверить код и внести свой вклад в дорожную карту!

Если вам интересно следить за проектом и оставлять отзывы, вы можете проверить его на GitHub. Если вам понравился анализ, поставьте нам звезду ⭐️!


Почему не Cost Explorer?

Один из отзывов, который я получаю довольно регулярно, это: «Почему вы не можете просто использовать Cost Explorer?». (посмотрите эту тему на Reddit). Я решил обобщить свое мнение здесь, чтобы поделиться этим постом, а не объяснять причины каждый раз, когда я буду получать этот вопрос в будущем. 🤣

Немного истории обо мне: Я являюсь соучредителем компании Macroscope, а до этого я работал с компаниями, помогая финансовым и инженерным командам понять биллинг AWS. Одной из самых больших проблем для клиентов AWS является отсутствие реальной видимости затрат.

Дело в том, что ваши инженерные команды не могут понять и решить проблему затрат, если у них нет доступа к правильным данным. Я видел, как стартапы и многомиллиардные предприятия пытаются управлять своими затратами с помощью Cost Explorer, и вот некоторые из самых больших проблем, с которыми мы столкнулись:

  • Экспорт, экспорт и еще раз экспорт.
  • Что такое EC2-Other?
  • Где мои резервирования?

Экспорт, экспорт и еще раз экспорт

Единственным наиболее существенным недостатком Cost Explorer является отсутствие возможности фильтрации данных & визуализации по более чем одной переменной.

Допустим, у меня есть 10 учетных записей AWS, и я хочу понять свои расходы по требованию в разрезе служб AWS для каждой из 10 учетных записей. Я не смогу сделать это в одной визуализации Cost Explorer. Мои варианты таковы:

  1. Создать представления для каждой учетной записи AWS, сгруппированные по службам
  2. Создать представления для каждой службы, сгруппированные по учетной записи AWS.

Для этого простого примера пользователю придется создать как минимум 10 представлений, экспортировать их в CSV, объединить данные и сделать визуализацию. Этот процесс является огромной тратой инженерного времени, если сравнить всю эту работу с этим простым запросом из отчета о затратах и использовании:

##On-demand costs by Account, AWS Service
SELECT
    [lineItem/UsageAccountID],
    [lineItem/ProductCode],
    sum([lineItem/UnblendedCost])
FROM cur
GROUP BY
    [lineItem/UsageAccountID],
    [lineItem/ProductCode];
Войти в полноэкранный режим Выход из полноэкранного режима

Можете ли вы получить правильный ответ с помощью Cost Explorer? Да, в конечном итоге. Я буду спорить весь день, что создание этих представлений, экспорт данных и объединение отчетов в Excel не является ценным занятием для любого сотрудника вашей компании.


Что такое EC2-Other?

Мне нравится EC2-Other, потому что мы все были в конференц-залах, когда принимались плохие решения. Мне нравится думать, что EC2-Other обсуждался еще в 2006 году в качестве условного обозначения, и вот мы уже в 2022 году все еще пытаемся понять, что он означает.

Во-первых, полезно обсудить, какие расходы считаются EC2-Other. Я более подробно останавливаюсь на этой теме в своем первом руководстве по коду EC2, но вот краткое изложение:

  1. Тома EBS и моментальные снимки
  2. ресурсы Nat Gateway и плата за них
  3. Расходы на передачу данных

Итак, теперь, когда мы знаем, какие затраты нам нужны, как мы можем разбить эти категории затрат в Cost Explorer? Можно получить правильный ответ в Cost Explorer, если вручную отфильтровать поля ‘Usage Type’ и ‘Usage Type Group’ для каждого типа затрат EC2-Other. Затем необходимо повторить процесс: создать представления для каждой категории затрат, экспортировать данные из этих представлений в CSV и разработать визуализации по мере необходимости.

Чтобы обойти всю эту работу, я написал запросы для отчета Cost and Usage Report, которые разбивают различные категории расходов EC2-Other. Этот запрос является примером того, как изолировать расходы на EBS Snapshot:

#Subresource Costs
##Subresource costs for EBS Volume Snapshots
SELECT DISTINCT
    [lineItem/ResourceID],
    [lineItem/LineItemType],
    [lineItem/Operation],
    round(sum([lineItem/UnblendedCost]), 4) as subresource_cost
FROM CUR
WHERE
    [lineItem/ProductCode] is 'AmazonEC2'
    and [lineItem/ResourceId] LIKE '%snapshot%'
GROUP BY
    [lineItem/ResourceID],
    [lineitem/lineitemtype],
    [lineItem/Operation]
ORDER BY
    sum([lineItem/UnblendedCost]);
Войти в полноэкранный режим Выход из полноэкранного режима

К сожалению, EC2-Other никуда не денется. К счастью, используя CUR вместо Cost Explorer, мы можем обойти эту проблему и выяснить, за что на самом деле с нас берут деньги.


Где мои резервирования?

Одна из самых запутанных вещей, которую я видел, когда инженерные команды пытались преодолеть, — это отсутствие видимости того, где применяются их резервирования. Принятие обязательств в AWS — это один из немногих способов держать расходы на AWS под контролем. Эти обязательства бывают трех основных форм: EDPs, Reserved Instances и Savings Plans.

Другой пример: клиент AWS с 1 учетной записью управления и 9 учетными записями участников резервирует использование EC2. Это резервирование производится в учетной записи управления, поэтому экономия затрат может быть применена ко всем учетным записям AWS. Как это на самом деле отображается в Cost explorer?

  • Ежемесячные затраты на резервирование приходятся на управляющую учетную запись, даже если резервирование используется учетной записью участника.
  • Любое использование резервирования в учетных записях участников отображается как $0.

Это серьезная проблема для контроля затрат инженеров. За одну ночь расходы одних инженеров снизятся на $0, а другие не получат никакой выгоды от приобретения зарезервированных экземпляров. Единственным решением этой проблемы с помощью Cost Explorer было бы извлечение часов работы экземпляров EC2 по типам экземпляров для каждого аккаунта и обратная разработка ставки $/час, которую можно применить к использованию EC2. Я уже делал это раньше, и это ужасно.

Гораздо более простым решением будет использование этого запроса на вашем CUR. Этот запрос разбивает использование по типам экземпляров и регионам для каждой из моделей ценообразования EC2 (по требованию, спот, зарезервированный экземпляр и сберегательные планы).

#Total existence cost for EC2
##Total existence cost by resource ID
WITH on_demand_existence AS (
    SELECT
        [lineItem/ResourceId],
        round(sum([lineItem/UnblendedCost]), 4) as existence_cost
    FROM CUR
    WHERE
        [lineItem/ProductCode] = 'AmazonEC2'
        and [product/instanceType] <> ""
        and [lineItem/LineItemType] is 'Usage'
        and [lineItem/UsageType] LIKE '%BoxUsage%'
        and [lineItem/Operation] LIKE 'RunInstances%'
    GROUP BY
        [lineItem/ResourceId]
)
, spot_existence AS (
    SELECT
        [lineItem/ResourceId],
        round(sum([lineItem/UnblendedCost]), 4) as existence_cost
    FROM CUR
    WHERE
        [lineItem/ProductCode] = 'AmazonEC2'
        and [product/instanceType] <> ""
        and [lineItem/LineItemType] is 'Usage'
        and [lineItem/UsageType] LIKE '%SpotUsage%'
        and [lineItem/Operation] LIKE 'RunInstances%'
    GROUP BY
        [lineItem/ResourceId]
)
, reserved_existence AS (
    SELECT
        [lineItem/ResourceId],
        round(sum([reservation/EffectiveCost]), 4) as existence_cost
    FROM CUR
    WHERE
        [lineItem/ProductCode] = 'AmazonEC2'
        and [product/instanceType] <> ""
        and [lineItem/LineItemType] is 'DiscountedUsage'
    GROUP BY
        [lineItem/ResourceId]
)
, savings_plan_existence AS (
    SELECT 
        [lineItem/ResourceId],
        round(sum([savingsPlan/SavingsPlanEffectiveCost]), 4) as existence_cost
    FROM CUR
    WHERE
        [lineItem/ProductCode] = 'AmazonEC2'
        and [product/instanceType] <> ""
        and [lineItem/LineItemType] is 'SavingsPlanCoveredUsage'
    GROUP BY 
        [lineItem/ResourceId]
)
SELECT
    CUR.[lineitem/ResourceId],
    CUR.[product/instanceType],
    CUR.[product/region],
    COALESCE(on_demand_existence.existence_cost, 0) as on_demand_existence_cost,
    COALESCE(spot_existence.existence_cost, 0) as spot_existence_cost,
    COALESCE(reserved_existence.existence_cost, 0) as reserved_existence_cost,
    COALESCE(savings_plan_existence.existence_cost, 0) as savings_plan_existence_cost,
    (COALESCE(on_demand_existence.existence_cost, 0) + COALESCE(spot_existence.existence_cost, 0) + COALESCE(reserved_existence.existence_cost, 0) + COALESCE(savings_plan_existence.existence_cost, 0)) AS total_existence_cost
FROM CUR
LEFT JOIN 
    on_demand_existence
    ON on_demand_existence.[lineItem/ResourceId] = CUR.[lineItem/ResourceId]
LEFT JOIN 
    spot_existence
    ON spot_existence.[lineItem/ResourceId] = CUR.[lineItem/ResourceId]
LEFT JOIN 
    reserved_existence
    ON reserved_existence.[lineItem/ResourceId] = CUR.[lineItem/ResourceId]
LEFT JOIN 
    savings_plan_existence
    ON savings_plan_existence.[lineItem/ResourceId] = CUR.[lineItem/ResourceId]
WHERE 
    CUR.[lineItem/ProductCode] is 'AmazonEC2'
    and CUR.[product/instanceType] <> ""
    and CUR.[lineitem/ResourceId] <> ""
GROUP BY
    CUR.[lineitem/ResourceId],
    CUR.[product/instanceType],
    CUR.[product/region]
ORDER BY
    total_existence_cost;
Вход в полноэкранный режим Выход из полноэкранного режима

Заключительные размышления

Cost Explorer не удовлетворяет потребности инженерных команд в понимании затрат. Три примера, рассмотренные в этом блоге, представляют собой три значительных препятствия, которые создают ненужную работу для инженерных команд.

Любой инженер может легко и бесплатно заменить Cost Explorer, создав отчет о затратах и использовании и выполнив собственный SQL-анализ. Если у вашей команды есть конкретные проблемы с затратами, дайте мне знать в комментариях, и я добавлю анализ в проект Developer’s Guide to AWS Costs!

Оцените статью
devanswers.ru
Добавить комментарий