Node.js 14.x + Lambda:

https://aws.amazon.com/blogs/compute/node-js-14-x-runtime-now-available-in-aws-lambda/

#Lambda

​​Бесплатные Amazon WorkSpaces до конца июля:

https://aws.amazon.com/workspaces/pricing/

В прошлом году была похожая раздача слонов. Потому, вдохновившись результатами, раздачу решили повторить:

https://aws.amazon.com/blogs/desktop-and-application-streaming/amazon-workspaces-free-tier-extension-2021/

В бесплатный пакет входит:

➡️ 50 стандартных Windows виртуалок 2 vCPU, 4 GB Memory, 80 GB + 50 GB, которые работают (только) в режиме AutoStop и общей численностью до 10 000 часов в месяц (суммируется на все регионы всех юзеров)

➡️ 1 более мощная Windows виртуалка 2 vCPU, 8 GB Memory, 80 GB + 100 GB на 200 часов 🔥

➡️ 1 слабая Windows виртуалка (на попробовать, видимо, подойдёт ли на будущее) 1 vCPU, 2 GB Memory, 80 GB + 10 GB на 200 часов

➡️ 2 Linux виртуалки 2 vCPU, 4 GB Memory, 80 GB + 50 GB на 400 часов

Пакет действует до 31 июля 2021 года для всех новых аккаунтов и только при работе в AutoStop Mode (AlwaysOn режим будет считаться по обычном биллингу).

Пробуйте, за всё уплочено!

#халява #WorkSpaces

50 оттенков реакций:

https://twitter.com/ow/status/1356978380198072321

#пятничное

Весёлый ролик от Corey Quinn не всем понятен, а весьма полезен. Потому далее расшифровка каждого пункта (моя версия).

💸 Managed NAT Gateway — популярная проблема, когда кажущиеся пустыми окружения жрут деньги из-за цены за NAT GW для private subnets.

💸 Amazon EBS — забытые неиспользуемые (не примонтированные) диски в разных аккаунтах жрут деньги, а в случае, если они Provisioned IOPS, то огромные деньги.

💸 Insecure S3 buckets - 450 independent "Security" researchers — в данном случае здесь, видимо, какая-то пародия на аудит безопасности, хотя при большом количестве данных расходы на S3 могут быть огромными. В помощь S3 Intelligent-Tiering и Amazon S3 Storage Lens.

💸 The Data Science team — так понимаю, команда резвящихся датасайенсистов стоит дорого.

💸 Cross AZ Data Transfer — малоприметная проблема пожирает незаметно деньги (и может большие), прикрытая общей уверенностью, что трафик внутри одного региона бесплатен.

💸 Your AWS Account Team — видимо шарж на команду AWS, которая лениво смотрит, как вы спонсируете их коктейли.

💸 RIs in the wrong region — про то, что Reserved Instances берутся на конкретный регион, иначе они просто проедают деньги. В помощь Savings Plans!

💸 CloudWatch Metrics и DataDog polling — одни из самых дорогих источников расходов на мониторинг, соревнующиеся в первенстве, кто дороже. Настраивайте нужные метрики с нужным интервалом. Как вариант – используйте Amazon Managed Prometheus.

💸 OverProvisioned IOPS — EBS диски с IOPS-ами дорогое удовольствие, потому не стоит привычно "брать с запасом", а руководствоваться адекватными метриками.

💸 Infrastructure in us-west-1 — регион N.California географически совсем рядом с Oregon (us-west-2), однако ресурсы в N.California на 20+ процентов дороже.

💸 Deployed Amazon Macie — первая версия Macie была (есть) негуманно дорогая. Используйте вторую.

💸 Amazon Redshift — серьёзные вещи стоят серьёзные деньги и требуют серьёзного отношения.

💸 AWS Marketplace Vendors — поставленные из Marketplace продукты могут стоить (больших) денег – нужно не забывать отписываться от ставшего ненужным.

💸 Extra Snowball days — за каждый день свыше 10 включённых изначально, списываются деньги за пользование Snowball и это могут быть большие деньги (от десятков до сотен долларов в день).

💸 Business support on Developer accounts — план техподдержки Business стоит 100 долларов в месяц и привязан к конкретному аккаунту. Если это аккаунт для разработки, то по сравнению с Developer планом за 29$ в месяц в нём нет ничего, кроме дополнительных коктейлей для AWS Account Team выше.

💸 No expiry configured - CloudWatch logs everywhere — логи, которые никогда не удаляются, вечные ненужные бэкапы, ECR образы и куча всего другого ­­- всё это пожирает деньги. Даже если не самые большие, но умноженное на всегда получается бесконечно много. Настраивайте lifecycle policy для всего.

💸 Frequent Glacier Retrievals — получение данных из Glacier – дорогая операция, не нужно увлекаться, а лучше использовать S3 Intelligent Tier Archive, который теперь умеет сам складывать в Glacier и забирать оттуда бесплатно.

💸 EMR without Spot fleets — использование Spot fleets для EMR существенно экономит, стоит их использовать.

💸 Creds leaked on Github — не нужно публиковать свои ключи доступа на GitHub, это может стоить дорого.

💸 AWS Contracts Team — вот это я не расшифровал, буду признателен объяснению в комментариях. 


p.s. Хороший пост про 10 простых и очевидных способов уменьшить стоимость вашей AWS инфраструктуры есть и на русском:

https://aws.amazon.com/ru/blogs/rus/10-things-you-can-do-today-to-reduce-aws-costs/

#cost_optimization

​​Утилита для формирования IAM политик по запросу с вашего компьютера:

https://github.com/iann0036/iamlive

Написана на Go, потому легко запускается на Linux/
В одном окошке запускаете один бинарник (написана на Go), в моём случае это:

iamlive --set-ini --profile=sf

(у вас может быть другой профиль или без него)

В другом окошке выполняем команду (для выбранного окружения/профиля):

aws --profile=sf s3 ls

В первом окошке для сделанного запроса отобразится IAM права для выполненного запроса:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    }
  ]
}

Полезно не только для изучения, но и для трассировки: с ключиком --fails-only можно получать лишь те политики, которые дали ошибку – прав на которые для выполнения команды у текущего пользователя/профиля нет.

#IAM

Telegram bot на Лямбде

Нужно решить простую задачу – запускать/останавливать виртуалку через Telegram бот. Для начала нужен сам Телеграм бот. Сделать это логично на Лямбде.

Из сохранённых ссылок у себя нашёл следующее:

🔹 Send and Receive Messages with the Telegram API
🔹 Running a Serverless Telegram Bot from AWS Lambda
🔹 Integrating Your Serverless Telegram Bot with AWS API Gateway

Вполне доступно и можно повторить, действительно понятно расписано.

Однако хотелось бы не тыкать в консоли, а какой-то готовый IaC, в идеале CloudFormaion или CDK, но можно SAM или под Terraform, лишь чтобы поновей.

Если вы недавно пилили своего Телеграм-бота и не жалко поделиться кодом – буду признателен. Либо ссылочку, где такое нашли – напишите, пожалуйста, в комментариях.

#Telegram_bot #Lambda #serverless #bot

Improving Observability with AWS App Mesh and Amazon ECS

Детальная статья как транскрипция видео с последнего реинвента – для тех, кому удобней читать, а не смотреть:

https://nathanpeck.com/improving-observability-with-aws-app-mesh-amazon-ecs/

#AppMesh #ECS

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

https://awsstash.com/

Стоит добавить в закладки. Особенно может помочь в случаях поиска каких-то вещей типа blue-green и прочих терминов из общеупотребимой лексики, которые сложно отфильтровать в обычном поисковике.

#info

Через 3 часа начнётся Митап AWS User Group Kazakhstan.

Присоединяйтесь прямо сейчас!

https://www.twitch.tv/awsporusski

Где же на самом деле выполняется Lambda@Edge?

Результаты опроса показали, что «регионалы» в полном проигрыше. Какой же правильный ответ?

Точного и конкретного ответа на этот вопрос в AWS документации нет.

Однако вот что про это пишет Serverless AWS Hero Yan Cui:

Lambda@Edge functions actually execute in a region closest to the edge location, not at the edge location itself. And the kicker is that their logs would be sent to CloudWatch Logs in that same region.

https://theburningmonk.com/2020/04/hit-the-6mb-lambda-payload-limit-heres-what-you-can-do/

В̶о̶т̶ ̶т̶е̶п̶е̶р̶ь̶ ̶и̶ ̶ж̶и̶в̶и̶т̶е̶ ̶с̶ ̶э̶т̶и̶м̶!̶ В общем, не всё так однозначно.

#Lambda

AWS Pricing Calculator – рассчёт стоимости AWS ресурсов:

https://calculator.aws

Pricing Calculator позволяет рассчитать стоимость отдельных ресурсов, для чего имеются прямые ссылки для различных сервисов, например:

🖥️ EC2 - https://calculator.aws/#/createCalculator/EC2
💾 S3 - https://calculator.aws/#/createCalculator/S3
...и другие сервисы, полный список (81 шт.) - https://calculator.aws/#/addService

#pricing

​​AWS сервисы и личности (и наоборот)

У меня есть некоторый стойкий набор ассоциаций: амазоновский сервис — какая-то личность и наоборот.

AWS CloudFormation ­— Карен Товмасян, в англоязычном — Ian Mckay
Amazon S3 — Василий Пантюхин
AWS Amplify — Димка Реактнативный, в англоязычном Nader Dabit

Это не полный список, что вспомнилось с ходу. Понятно, что можно перечислить всех популярных AWS Hero и так далее, однако интересны ваши личные предпочтения, особенно из русскоговорящих спикеров.

Поделитесь в комментариях своими сочетаниями, пожалуйста.


p.s. Наверное, можно также без прямой привязки к сервису, а, например, к области:
Scott Piper — AWS Security.
Или даже не напрямую к AWS (но связанное с AWS):
Антон Бабенко — Terraform.

#пятничное

Загруженные с помощью S3 multipart upload части файла остаются в S3 такими же "кусками", как были туда загружены. Потому, если после их скорость скачивания критична, то стоит выбирать размеры multiparts, оптимальные для скачивания:

If objects are PUT using a multipart upload, it’s a good practice to GET them in the same part sizes (or at least aligned to part boundaries) for best performance.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-guidelines.html#optimizing-performance-guidelines-get-range

Последующая "дефрагментация" (на какие-то более оптимальные значения, если были выбраны неоптимальные размеры частей) загруженного файла на S3 невозможна. Хотя можно отправить файл в Glacier Deep Archive и после восстановить – он будет пересобран из мелких частей.

Также не стоит забывать, что недозагруженные "запчасти" занимают место и жрут какие-никакие деньги, потому для бакетов, где активно практикуется S3 multipart upload, нужно настраивать lifecycle политики:

https://aws.amazon.com/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/

#S3

​​Superwerker

Кто про что, а в̶ш̶и̶в̶ы̶й̶ ̶п̶р̶о̶ ̶б̶а̶н̶ю̶ я про AWS Organizations. Которой в этом году исполнится пять лет. И, значит, уже пятый год мы живём без гуманной процедуры удаления аккаунта, без временных аккаунтов.

За это время использование #multi_account_strategy стало обязательной практикой, в помощь чему появился сервис Control Tower, который в прошлом году обзавёлся возможностью работать в том числе и в существующей организации.

Однако порог входа для начала работы с лучшими практиками, которые даёт Organizations, пока по-прежнему высок. В попытке его снизить, намедни появился новый open source инструмент – superwerker:

https://github.com/superwerker/superwerker

Хороший набор #security #best_practices, правда, хороший – самое основное, что нужно иметь. Идеи по управлению аккаунтами в том числе позаимстованы из AWS Account Controller от Ian Mckay. Модный event-driven подход, (практически) бесплатные Лямбды.

Если бы хотел начать – точно бы обратил внимание. Заявленные фичи действительно самые нужные-востребованные:

▪️ Control Tower
▪️ AWS SSO
▪️ GuardDuty+dashboards
▪️ Security Hub+dashboards
▪️ AWS Backup
▪️ AWS Budgets
▪️ SCP guardrails
▪️ SSM+OpsCenter
▪️ CloudWatch dashboard

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

Установка Superwerker официально доступна в качестве AWS Quick Start:

https://aws.amazon.com/quickstart/architecture/superwerker/

Хорошая штука, в общем. Можно рекомендовать.

#Organizations

Запись митапа AWS User Group Kazakhstan:

https://www.youtube.com/watch?v=YU8Kq8tg3Sc

00:00​​ Вступление
02:16​ Талгат Нурлыбаев — Академическая программа Amazon AWS в МУИТ и Казахстане
14:50​ Анатолий Макеев — Личный опыт практического использование AWS в GameDev
49:21​ Карен Товмасян — Абсолютное соответствие требованиям
01:17:16​ Василий Пантюхин — Конкурентный доступ к файлам, советы по использованию Amazon EFS

Митап состоялся 2021.02.10.

#video

🔸AWS Service Control Policies (SCPs)

Nice overview page of SCPs by Marco Lancini covering what they are, what they can’t do, and example policies like denying API calls from root users, denying the ability to disrupt CloudTrail or GuardDuty, and more.

https://cloudsecdocs.com/aws/devops/resources/scps/

#aws

​​Kubernetes 1.19 для EKS:

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html

Спустя официального релиза 1.19 прошло чуть менее полугода.

Сделанный в прошлый раз прогноз на эту версию был неточен на три недели, что много, а значит команда EKS продолжает ускоряться в своей поддержке новых версий. С учётом этого можно предположить, что версия 1.20 на Амазоне появится 22 мая.

#EKS