Интеграция Cloud Custodian в Control Tower:

https://aws.amazon.com/blogs/opensource/continuous-deployment-of-cloud-custodian-to-aws-control-tower/

AWS Control Tower имеет ограниченный набор SCP-политик (guardrails), которые можно расширить с помощью Cloud Custodian – популярной утилиты в сфере безопасности.

#security #Control_Tower

​​Jeff Bezos уходит с поста CEO:

https://www.aboutamazon.com/news/company-news/email-from-jeff-bezos-to-employees

Перевод на русском можно прочитать здесь:

https://xn--r1a.website/addmeto/3868

p.s. Картинка шуточная из внутреннего чата AWS.

​​PrivateLink для S3:

https://aws.amazon.com/blogs/aws/aws-privatelink-for-amazon-s3-now-available/

Актуально для доступа с on-prem на S3. Раньше для этого прикручивали свои прокси, т.к. S3 был доступен лишь через Gateway VPC endpoint. Теперь же ещё и через "обычный" Interface VPC endpoint (PrivateLink).

Pricing

Стоит учесть, что в отличие от Gateway VPC endpoint для S3, трафик в случае PrivateLink тарифицируется по центу за каждый гигабайт.

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

Потому при перекачке многих десятков терабайт и более, можно получить непривычный биллинг, ориентируясь, что раньше такое не увеличивало цену (трафик от прокси на EC2 к S3 бесплатен).

#PrivateLink #S3

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