AWS: Re:Invent recap на русском языке (RU):

https://youtu.be/qTJ2VCV3_bU?t=242

#reinvent #video

AWS: Re: Invent recap українською мовою (UA):

https://pages.awscloud.com/EMEA-field-OE-EEMRecaps-2021-reg-event.html

Починається прямо зараз – о 17:00 (GMT+2), приєднуйтесь!

Server Side Rendering для React на Лямбде:

https://aws.amazon.com/blogs/compute/building-server-side-rendering-for-react-in-aws-lambda/

This post is courtesy of Roman Boiko, Solutions Architect.

#Lambda #React

Персонажи в команде, часть 2

Володя

Володя самый старший в команде, поэтому связь с ним через почту. Слэк, Телеграм – нет, не слышали, зачем? Ведь у Володи совершеннолетний Скайп!

К Володе обращаются, когда всё. Прилетает срочный проект, никто не знает, что делать, лишь по логам понятно, что внутри шевелится что-то старое на Джаве и уже не работает, а очень надо. В общем, это к Володе. Володя пропадает на пару месяцев и возвращается с ожившим проектом и набором патчей для использованного в нём фреймворка. Однако патчи никому не нужны, т.к. фреймворк на гитхабе заброшен уже много лет как и Володя про это не знает, потому что какой ещё git, когда у него свой насиженный svn.

Володя не следит за трендами и не знает новых веяний. Но он настолько знает старые, что может сделать что угодно, главное правильно поставить задачу и не мешать. Как-то прилетел проект, где нужно было что-то переделать под докер, про который Володя тогда узнал впервые. Он лишь интеллигентно спросил, чем же не устраивает lxd. Удовлетворившись невразумительным ответом, уже через пару месяцев весь проект у него весело крутился на Docker Swarm.

Потом был какой-то древний монолит биллинга одного банка, который стал загибаться с наплывом клиентов. Одним из требований к решению был перевод на куберы. Володя разобрался с куберами, разделил монолит на части через кафку и переписав в монолите лишь драйвер очереди, вернул ошарашенным клиентам через полгода.

В середине нулевых Володе делал проект по защите от копирования какой-то суперсекретной информации для военных под Windows. В качестве подспорья для реализации ему достались утекшие в сеть исходники Windows 2000. Он полгода их анализировал и узнал, что подсистему кэширования для Windows написал какой-то гений с итальянской фамилией ещё в лохматом 1989-м году. После 1993-го упоминания итальянца в коде пропадают и по тому, что позже его код никто не трогает и не меняет, становится ясно, что никто не понимает, как он работает, и потому с тех пор он просто перекладывался из версии в версию. Володя же разобрался и на его основе сделал свою защиту, которая обходит любые системы, не видится никакими антивирусами и которая за последние пятнадцать лет была им подправлена лишь пару раз – с переходом на 64 бит и появлением Windows 8. Самая последняя Windows 10 беззащитна против его оружия на базе кода тридцатилетней давности.

Некоторые новички не верят, что Володя существует, потому раз в год он подключается в скайпе на видеоконференцию. Однако последние пару лет не получалось, потому что вечером, когда проходят такие сеансы, его ADSL модем не тянет видео и связь рвётся.

Никто не знает, когда Володя появился в компании. Главный рассказывал, что прежний CTO завещал ему Володю со словами "Береги Володю. Будет Володя - будет проект". Поэтому когда однажды возникли проблемы с перечислением денег, он лично бегал в банк и переводил ему из своих через Western Union в Винницу.

Да, Володя тоже из Винницы. Это благодаря ему Саша вернулся обратно. Правда на другой проект, т.к. прежний закрыли. После чего Саша, как и раньше, продолжает охранять используемый стэк технологий и имеющуюся архитектуру приложения. И всей душой ненавидеть новую звезду в команде, девушку разработчика Валерию, как и до этого её тёзку противоположного пола.

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

(часть 1)

#персонажи

Serverless Stack Toolkit - расширение для AWS CDK:

https://github.com/serverless-stack/serverless-stack

#CDK #serverless

​​Пошаговое руководство для создания простого микросервисного проекта на Lambda + APIGW + DynamoDB:

https://dev.to/tiamatt/aws-project-building-a-serverless-microservice-with-lambda-1pa3

В качестве деплоя используется AWS SAM.

#Lambda #serverless

Митап AWS User Group Kazakhstan
📆 10 февраля 18:00-20:00 Нур-Султан / 15:00-17:00 Москва
📍https://www.twitch.tv/awsporusski
👉 доклады на разные темы, вопросы-ответы и возможность пообщаться
📄 программа
1. Талгат Нурлыбаев, МУИТ - Академическая программа Amazon AWS в МУИТ и Казахстане.
2. Анатолий Макеев, RedPad Games - Личный опыт практического использование AWS в GameDev. Почему был выбран AWS. Описание принципов использования AWS в разработке игр, основная структура клиент сервера. А также рекомендации начинающим разработчикам.
3. Карен Товмасян, EPAM - Going Full Compliant (Абсолютное соответствие требованиям). Как с помощью AWS Config и AWS SSM обеспечить полный контроль над состоянием своей инфраструктурой и соответствие требованиям.
4. Василий Пантюхин, AWS - Конкурентный доступ к файлам, советы по использованию Amazon EFS. Поговорим о том, как и где можно использовать Amazon Elastic File System. Обсудим best practices и способы сэкономить.

Переименование CloudFormation стэка:

https://github.com/iann0036/cfn-stack-rename

Просто так CloudFormation стэк переименовать нельзя, потому утилита делает следующее:

1. Разобирает стэк на запчасти (ресурсы), запомнив их айдишники.
2. Удаляет стэк с флажком "оставить все ресурсы".
3. Собирает из ранее запомненных (импортирует) стэк с новым именем.

Назначение утилиты больше экспериментальное, стоит учесть.

#CloudFormation

Разбор падения 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

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