AWS: несколько советов, как избежать этих моментов «святого счета»

Облако потрясающее: почти 100% доступность, практически нулевое обслуживание, оплата по факту и, самое главное, бесконечно масштабируемая.

Но последние два могут легко откусить вас назад, превратив эту удивительность в платежный кошмар.

И иногда вы видите такие истории, как:

В течение недели мы накопили счет около 10 тысяч долларов.

И здесь я раскрываю несколько советов, которые мы извлекли из нашего не совсем гладкого пути по созданию первой в мире бессерверной IDE , которая может помочь другим избежать некоторых «интересных» ловушек.

Осторожнее с этим конфигом!

Одна вещь, которую мы узнали, это никогда не недооценивать силу конфигурации.

Если вы прочитаете вышеупомянутую связанную статью, вы заметите, что это была простая неправильная конфигурация: конфигурация ведения журнала CloudTrail, которая записывала журналы в одно из сегментов, которое уже отслеживалось.

Вы, конечно, могли бы придумать более сложные и креативные примеры создания «сервисных петель», приводящих к чёрным дырам в биллинге, но идея проста: AWS настолько же умён, насколько и человек, который его настраивает.

(Ну, в приведенном выше случае это был один из моих коллег, который настроил его, и я был тем, кто подтвердил это; так что вы можете остановиться здесь, если захотите;))

Поэтому, когда вы собираетесь отправить новое обновление конфигурации, попробуйте переосмыслить последствия. Вы не пожалеете об этом.

Это S3, а не твой чердак.

По оценкам AWS , 7% облачного биллинга тратится на «неиспользуемое» хранилище — пространство, занимаемое содержимым, не имеющим практического применения: устаревшими пакетами, временными загрузками, старыми хостингами и тому подобным.

Жизнь в ведре

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

Вероятно, по той же причине S3 предоставил конфигурации жизненного цикла — автоматическое планирование очистки на основе времени. Вы можете просто сказать «удалите это, если оно старше 7 дней», и оно исчезнет через 7 дней.

Это идеальный способ проверки временного хранилища (артефакты сборки, разовые ресурсы и т. Д.) Без помощи рук.

Конфигурации жизненного цикла также могут пригодиться, если вы хотите удалить огромный объем файлов из вашего ведра; вместо того, чтобы удалять отдельные файлы (что само по себе влечет за собой затраты API — хотя удаление бесплатное, а листинг — нет! ), вы можете просто настроить правило конфигурации жизненного цикла, чтобы срок действия истек через 1 день. Расслабьтесь и отдохните, пока S3 сделает всю работу за вас!

В качестве альтернативы вы можете переместить ненужные, но не совсем готовые к отпуску вещи в Glacier за небольшую часть стоимости хранения ; скажем, для вещи под подпуть в archived :

Но прежде чем сделать это …

Это версия!

(Вдохновленный истинными событиями.)

Я установил конфигурацию жизненного цикла, чтобы удалить около 3 ГБ журналов доступа к корзине (очевидно, миллионы файлов), и подумал, что все хорошо — пока через месяц я не получил тот же счет S3, что и в предыдущем месяце 🙁

Оказывается, в корзине было включено управление версиями, поэтому удаление на самом деле не удаляет объект .

Таким образом, при включенном управлении версиями необходимо явно указать логике жизненного цикла S3:

• отменить не текущие (удаленные) версии объекта и
• истекают старые маркеры удаления

чтобы полностью избавиться от «удаленного» контента и связанных с ним маркеров удаления .

Вот вам и «простой» сервис хранения;)

CloudWatch — ваш приятель

Всякий раз, когда вы хотите узнать общие размеры, занимаемые вашими сегментами, просто итерируйте пространство имен AWS/S3 CloudWatch Metrics . Там нет никакого способа — сюрприз, сюрприз — проверить размер ведра непосредственно из S3; даже приборная панель S3 использует CloudWatch, так почему бы не вы?

Быстрый фрагмент для просмотра всего? (использует aws-cli и bc на bash )

EC2: подмести мусор, закрой отверстия

EC2 упрощает управление вашими виртуальными машинами — вычислениями, хранилищами и сетями. Тем не менее, его простота также означает, что он может оставить след незаметного мусора и утечки счетов.

Выберите свой тип экземпляра

Существует множество настроек при создании нового экземпляра. Если нет особых требований к производительности, для большинства потребностей будет достаточно выбрать тип экземпляра класса T2 с хранилищем с эластичным хранилищем блоков (EBS) и 2-4 ГБ оперативной памяти.

Несмотря на то, что t2.micro имеет право на бесплатное использование уровня, t2.micro может быть PITA, если ваш сервер может в какой-то момент получать нагрузки, t2.micro или памяти; в этих случаях t2.micro имеет тенденцию просто t2.micro (вероятно, связано с t2.micro кредитов ЦП ?), вызывая больше проблем, чем оно того стоит.

Очистить AMI и снимки

Мы обычно склонны делать периодические снимки наших экземпляров EC2 в качестве резервных копий. Некоторые из них превращаются в образы машин (AMI) для повторного использования или обмена с другими пользователями AWS .

Мы легко забываем о других снимках.

Хотя снимки не оплачиваются по полному объему , с течением времени они могут привести к значительному мусору. Поэтому важно периодически посещать и очищать вкладку снимков EC2 .

Более того, создание новых AMI обычно означало бы, что старые становятся устаревшими; их также можно « отменить» на вкладке AMI .

Но…

Кто виноват — AMI или снимок?

Фактические расходы указаны на снимках , а не на самих AMI.

И это становится сложным, потому что отмена регистрации AMI автоматически не удаляет соответствующий снимок .

Обычно вам нужно скопировать идентификатор AMI, перейти к снимкам, найти идентификатор в поле описания и сбросить соответствующий снимок. Или, если вы смелы (и ленивы), выберите и удалите все снимки; AWS не позволит вам удалить те, которые используются AMI.

Аналогично, для случаев и объемов

Compute оплачивается во время работы экземпляра EC2; но его объем хранения постоянно оплачивается — вплоть до удаления.

Тома обычно обнуляются при завершении экземпляра; однако, если вы поиграли с настройками прикрепления громкости, есть вероятность, что отсоединенные тома останутся в вашем аккаунте. Хотя они не привязаны к экземпляру, они все еще занимают место; и поэтому AWS взимает за них плату.

Опять же, просто перейдите на вкладку томов , выберите тома в «доступном» состоянии и нажмите «Удалить», чтобы навсегда избавиться от них.

Пометьте свои вещи EC2: экземпляры, тома, снимки, AMI и еще много чего

Во время создания снимка очень легко забыть, какое состояние было в экземпляре. Или цель этого запущенного / остановленного экземпляра, который, кажется, никто не берет на себя или не несет ответственности.

Именование и пометка могут помочь избежать неприятных сюрпризов («С какой стати вы удалили этот последний снимок прошлого месяца ?!»); а также поможет вам быстро решить, что бросить («У нас уже есть мастер-снимок 11-05, поэтому просто удалите все, что старше»).

Вы перестаете использовать, и мы начинаем выставлять счета!

Иногда лорды AWS работают таинственным образом.

Например, эластичные IP-адреса (EIP) бесплатны, если они прикреплены к работающему экземпляру. Но они начинают заряжаться с каждым часом, как только экземпляр останавливается; или если они каким-то образом попадают в «отключенное» состояние (не привязанное к запущенному экземпляру).

Некоторые предварительные знания об услуге, на которую вы собираетесь подписаться, могут предотвратить некоторые неприятные сюрпризы этого способа. Быстрый поиск страницы цены или Google может нарушить условия сделки.

Плата за использование против платы за распределение

Многие сервисы AWS следуют одному или обоим вышеперечисленным шаблонам. Первое тривиально (вы просто платите за время / ресурсы, которые вы фактически используете, и остальное время наслаждаетесь нулевым счетом), и его трудно не заметить; но последнее может быть немного неясным и довольно легко остаться незамеченным.

Рассмотрим EC2: вы в основном платите за время выполнения экземпляра, но вы также платите за хранилище (тома, снимки, AMI) и распределение сети (например, неактивные эластичные IP-адреса), даже если ваш экземпляр был остановлен на месяцы.

Есть еще много примеров, особенно в безсерверном домене (с которым мы, кстати, более знакомы):

• Кинезис заряжается в час шарда — даже если все ваши осколки бездействуют
• DynamoBB взимает плату за хранение и чтение / запись в единицах «емкости» — к счастью, существует бесплатный уровень с неограниченным сроком действия!
• RDS (очень похоже на EC2) взимает плату за время выполнения экземпляра, независимо от того, занят ли он или находится в режиме ожидания ( Aurora Serverless, похоже, пытается изменить это до некоторой степени)
• KMS взимает фиксированную плату за каждый ключ, управляемый клиентом (CMK) , используете ли вы его или нет

Между тем, некоторые службы тайно настраивают свои собственные объекты мониторинга, резервного копирования и другие «служебные» объекты. Это, хотя (вероятно!) Предназначено для пользы, может тайно просочиться в ваш счет:

• DynamoDB устанавливает CloudWatch Alarms ; они остаются даже после удаления соответствующих таблиц (по крайней мере, при управлении через CloudFormation).
• RDS автоматически создает моментальные снимки томов экземпляра как при завершении, так и во время ежедневного обслуживания (особенно при развертывании через «облачные» конфигурации CloudFormation ; они могут легко накапливаться в квотах хранилища).

Это основные виновники, которые часто появляются в наших счетах AWS; Конечно, есть лучшие примеры, но вы понимаете.

CloudWatch (да, снова)

Многие сервисы уже — или могут быть настроены — сообщать метрики использования в CloudWatch. Следовательно, имея некоторую информацию о том, какие метрики сопоставляются с каким компонентом биллинга (например, стоимость хранения S3 представлена ​​суммированием метрики BucketSizeBytes для всех записей пространства имен AWS/S3 ), вы можете создать полное решение для биллинга и мониторинга с помощью CloudWatch. Метрики (или делегировать работу стороннему сервису, такому как DataDog ).

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

API биллинга

Хотя в AWS есть отдельная панель Billing Dashboard , вход в систему и проверка ее каждый день — это не то, что вы бы добавили в свою повестку дня (по крайней мере, для таких людей, как вы и я).

К счастью, AWS предлагает API биллинга, с помощью которого вы можете получить довольно детальное представление текущего платежного поручения за любой предпочтительный период времени — с разбивкой по услугам или фактическим операциям API.

Заметьте, этот API не бесплатный: каждый вызов стоит вам 0,01 доллара. Конечно, это незначительно — учитывая риск того, что придется платить нескольким десяткам — или даже сотням или тысячам в некоторых случаях — стоит иметь монитор выставления счетов за $ 0,30 в месяц, чтобы отслеживать любые аномалии, пока не стало слишком поздно.

Пища для размышления: с поддержкой Chrome без функций , предлагаемой для облачных функций Google , можно настроить рабочий процесс без сервера, который входит в панель управления AWS и проверяет счет за вас. Что-нибудь, чтобы попробовать в свободное время (если некоторые гениальные люди еще не взломали это вместе).

Оповещения о выставлении счетов

Как ни странно (а может и нет;)) AWS не предлагает способ установить жесткий лимит для выставления счетов; несмотря на многочисленные запросы пользователей и тревожные сообщения об инцидентах по всей сети. Вместо этого они предлагают предупреждения для различных «уровней» выставления счетов; Вы можете подписаться на уведомления, такие как «счет в x% от лимита» и «превышение лимита», по электронной почте или SNS (удобно для автоматизации через Lambda !).

Мой совет: это необходимо для каждой учетной записи AWS. Если бы у нас был один на месте, мы уже могли бы сэкономить более тысячи долларов на сегодняшний день.

Организационные счета

Если вы хотите делегировать доступ к AWS третьим сторонам (командам тестирования, разработчикам на основе контрактов, демо-пользователям и т. Д.), Было бы неплохо создать дополнительную учетную запись, преобразовав вашу корневую учетную запись в организацию AWS с включенным консолидированным биллингом. ,

(Хотя с помощью пользователя IAM можно сделать почти то же самое, это не обеспечит изоляцию ресурса; все будет помещено в одну учетную запись, и кропотливо сложные политики IAM могут потребоваться для изоляции объектов между пользователями.)

Наш генеральный директор и коллега Асанха написал об этом достаточно подробно, поэтому я остановлюсь на этом.

И наконец: монитор. Монитор. Монитор.

Нет необходимости подчеркивать это — мои бесконечные разговоры уже должны были передать его важность.

Итак, удачи в этом!