AWS Notes

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

Где же на самом деле выполняется 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

Присоединяйтесь прямо сейчас! https://www.twitch.tv/awsporusski

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

Сборник информации по AWS — видео, блоги, подкасты, репозитории, слайды и не только. Поиск с учётом уровня сложности, спикера, году публикации. https://awsstash.com/ Стоит добавить в закладки. Особенно может помочь в случаях поиска каких-то вещей типа blue-green и прочих терминов из общеупотребимой лексики, которые сложно отфильтровать в обычном поисковике. #info

Improving Observability with AWS App Mesh and Amazon ECS Детальная статья как транскрипция видео с последнего реинвента – для тех, кому удобней читать, а не смотреть: https://nathanpeck.com/improving-observability-with-aws-app-mesh-amazon-ecs/ #AppMesh #ECS

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

https://aws.amazon.com/blogs/opensource/set-up-cross-region-metrics-collection-for-amazon-managed-service-for-prometheus-workspaces/ Prometheus + VPC peering: those interesting parts.

​​Утилита для формирования 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

Весёлый ролик от 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

AWS Cost CoreyQuinnization #пятничное

50 оттенков реакций: https://twitter.com/ow/status/1356978380198072321 #пятничное

​​Бесплатные 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

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

​​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

​​Jeff Bezos уходит с поста CEO: https://www.aboutamazon.com/news/company-news/email-from-jeff-bezos-to-employees Перевод на русском можно прочитать здесь: https://t.me/addmeto/3868 p.s. Картинка шуточная из внутреннего чата AWS.

Интеграция 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

Разбор падения Slack от 4 января: https://slack.engineering/slacks-outage-on-january-4th-2021/ Весьма полезное чтиво – хронология, детали, выводы. Кроме ставшего классическим /proc/sys/fs/file-max, есть и специфичные амазоновские причины. Масштабирование AWS Transit GateWay (TGW) TGW менеджится Амазоном, потому повлиять на него мы не можем. В то время, как часть проблем у Slack возникла из-за того, что резко возросший трафик через их корневой TGW, через который завязаны их окружения, давал ошибки, не успевая масштабироваться, добавляя проблем во время падения Slack. Амазоновцы вручную боролись с этой ситуацией: However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually. Чтобы такого избежать, нужно "прогревать" TGW, аналогично тому, как такое предусмотрено для ELB: https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/#pre-warming Shared VPC vs different VPCs Другой момент – отрицательные стороны от использования отдельных VPC. Если бы у Slack использовалась Shared VPC – и для окружения, и для мониторинга, то трафик бы не упёрся бы в узкое горлышко TGW (его скорости масштабирования), через который и соединяются отдельные VPC. #TGW #Shared_VPC #design