Основные новые фичи коротко

• Приватные Hosted Zones с пересекающимися доменами
• Типы инстансов в EC2-консоли
• Тэги для сессий при переключении IAM ролей - для реализации новой схемы разделения доступа ABAC
• Логи RDS for Microsoft SQL Server в CloudWatch
• Helm чарты под App Mesh controllers для EKS
• Официальная поддержка CloudWatch в Grafana 6.5
• Ротация секретов в CloudFormation
• Test Reporting в CodeBuild
• DynamoDB и Kinesis эвенты для Лямбды
• Мониторинг состояния Лямбды
• Отправление результатов Лямбды в другие сервисы
• Статистика выполняющихся запросов в Performance Insights для Aurora PostgreSQL
• Service Action Events в ECS
• AWS PrivateLink для EC2 Auto Scaling, Application Auto Scaling и AWS Auto Scaling
• Восстановление дифференциального бэкапа и логов для Amazon RDS for Microsoft SQL
• IPv6 для Inter-Region VPC Peering
• Alexa Voice Service (AVS) Integration для AWS IoT
• Aurora Global Database совместимая с MySQL 5.7 для Aurora MySQL version 2.07+
• Ещё одно большое обновление CloudFormation

@aws_update

⁠Least Outstanding Requests (LOR) балансировка для ALB

При распределении запросов за ALB используется обычный Round-Robin. Теперь же можно задать Least Outstanding Requests (LOR) - маршрутизировать запросы сначала к тем, кто лучше пингуется:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm

То есть запросы будут получать инстансы с учётом значений RequestCount, TargetConnectionErrorCount и TargetResponseTime.

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

Включается в консоли в Target Groups или с помощью #aws_cli:

https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html

Удачных экспериментов!

#ALB

⁠Политики тэгирования - Tag Policies

Tag-Based access control (ABAC) продожает расширяться с взрывной скоростью.

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

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html

Т.е. теперь незачем постоянно менять ключи доступа в наказание за непростановку стандартных тэгов для создаваемых EC2-инстансов, а можно прописать политики тэгирования на уровне организации:

{
 "tags": {
  "env": {
    "tag_value": {
      "@@assign": [
        "dev",
        "test",
        "stage",
        "prod"
      ]
    }
  },
  "project": {
    "tag_value": {
      "@@assign": [
        "project1",
        "project2"
      ]
    }
  }
 }
}

И теперь придётся их проставлять в принудительном порядке, чтобы что-то запустить.

Список ресурсов, которые можно заставить тэгировать прилагается в редакторе Tag Policies, однако нужно понимать, что лучше выбирать по минимуму (точечно), чтобы не поломать работы каких-то сервисов.

#tags #ABAC #Organizations

⁠Обозначения регионов в консоли

Маленькое изменение, а кому-то большая радость. Кто никак не запомнил, теперь сразу с буквами и цифрами - не только (человеческое) название региона, но и (нечеловеческое) название региона.

#AWS_console

⁠re:Invent 2019 - Итоги

Анонсы продолжают сыпаться (за последние два дня больше сотни, чуть ли не половина - новые фичи), реинвент ещё не начался, но итоги уже можно подвести.

Нас будут развлекать говорящие тёти Алексы, всё более неотличимые от живых людей, ролики в 8k разрешении, быстрее-больше-удобней дашбордов-графиков-отчётов. Удобство управления доступом пройдёт под знаменем новой эры Amazon Attribute Based Access Control. Лямбды настолько прокачались, что из serverless перекочуют в functionless. Инфраструктурные вещи не будут столь выражены, т.к. почти всё уже было сделано. Продолжится централизация управления всем внутри и вокруг SSM. Ключи будут шифроваться и шифровать все сервисы подряд, а интеграция со сторонними вендорами по всяческим фичам множиться и шириться.

Но главное не это. Реинвент не просто подчеркнёт, а будет форсить новую тему - использование AI/ML функционала для простых девелоперов и админов, бизнес-аналитиков и менеджеров. Так что если вы завидовали патлатым и бородатым датасайнтистам за их умение разговаривать на непонятные нейронные темы - расслабьтесь, теперь не только они владеют священным знанием. Не поступили на кафедру искуственного интеллекта - так теперь и не надо.

Всё что нужно - покурить документацию новых фич Aurora, Athena, Quicksight. Они работают сами и позволят напрямую работать с моделями машинного обучения без дополнительных наворотов, предоставляя нужный функционал из коробки и чуть ли не прямо через SQL. Это новый тренд - ИИ от бессмысленных разговоров про завоевание человечества становится каждодневным инструментом в работе всё большего количества людей.

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

#тренды #прогнозы #мнения

⁠Beanstalk - есть и хорошие новости

Зря наезжал - #Beanstalk реабилитирован.

#праздничное

Подробности:
Спустя всего каких-то два года в Elastic Beanstalk появилась поддержка Amazon Linux 2.

Добавлено:
Это был нервный сарказм. В реальности у #Beanstalk-а действительно хорошие новости - он стал поддерживать Spot-ы.

Заметки по AWS, которые я когда-то решил сюда перенести из своих гуглошитов, копятся с угрожающей скоростью. Так и остались неразобранными нескольколетней давности. А теперь остаётся по десять страниц в месяц. И это без реинвента, который переваривать ещё не один месяц.

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

Однако такое занимает много времени. В то время как многие (а скорей - большинство) заметки больше просто "полезности", в одну строку. На министатейку не потянет, т.к. актуально лишь для себя. Наверное.

Это и банальности и непроверенные моменты, которые с большим жирным шрифтом проверить, попробовать, посмотреть, обязательно посмотреть так и сгинут в этих гуглошитах, став неактуальными.

В общем, буду такое теперь также скидывать сюда - формат заметок в прямом смысле.

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

Скопировать с ECR-репозитория в другой нельзя ("напрямую" - через какую-то апишку/команду), можно лишь спулить и запушить. Но пилят регион-репликацию:

https://github.com/aws/containers-roadmap/issues/140

Актуально для DR (Disaster Recovery) - ведь при падении региона может упасть и региональный #ECR (такого ещё не было, но это правильный подход).

Тестировать DR нужно 1-2 раза в год, т.к. приложение меняется и может не отработать или будет разворачиваться с большим RTO.

⁠Мда, судя по всему, с такими успехами, придётся делать посты к заметкам. :)

DR - общеупотребительное сокращение для Disaster Recovery, что в контексте AWS обозначает возможность развернуть проект в другом его регионе. Например, работает в Oregon-e us-west-2, а DR plan (тоже устойчивый термин - план восстановления работоспособности) предусматривает подъём в Калифорнии us-west-1, Виржинии us-east-1 или даже на другом континенте (обычно Ирландия eu-west-1), если приложение такое подразумевает.

RPO (Recovery Point Objective) - время от последнего бэкапа до катастрофы.

RTO (Recovery Time Objective) - время от катастрофы до восстановления работоспособности.

Если тема DR интересна (она важная с переходом в принциальная, но предполагает высокий уровень понимания) и вы почему-то про неё ещё не читали и смотрели (например, вот хорошее видео с позапрошлого реинвента 2017 про говорящую Алексу, плохо, но таки запускающую CloudFormation стэки DR восстановления) - жмите подробности, про неё я могу писать долго, много и ещё раз долго.

#DR

Последовательность блоков в #CloudFormation #templates можно менять (сначала ресурсы или даже вывод, остальное ниже):

Outputs:
 ecrRepository:
  Value: !Ref ecrRepository
Resources:
 ecrRepository: 
  Type: AWS::ECR::Repository
  Properties: 
   RepositoryName: !Ref RepositoryName
Parameters:
 RepositoryName:
  Type: String
  Description: Name of ECR repository
  Default: some-repo
Description: ECR repository

​​Даже Амазон не знает, кому это может быть нужно. 🤣

#WorkSpaces #пятничное

⁠S3 и кодировка файлов

При сохранении в S3 не происходит никакая "перекодировка" файла и возможность задать Content Type в этом не поможет.

Пример. Имеем файл 1.csv:
file -i 1.csv
1.csv: text/plain; charset=us-ascii

Сохраняем его на S3 и указываем "нужную" кодировку, наприме, UTF-16:

aws s3api put-object --content-type="application/csv;charset=UTF-16" --bucket my-bucket --key u16.csv --body 1.csv

Файл сохранится и в метаданных будет указанное значение (см. картинку).

Однако S3 не имеет отношения к тому, что в реальности внутри, это лишь метадата и потому, когда мы скачаем файл:

aws s3api get-object --bucket my-bucket --key u16.csv u16.csv

Кодировка останется той же:

file -i u16.csv
u16.csv: text/plain; charset=us-ascii

Чтобы реально поменять кодировку, нужно изменить содержимое файла, который указывается в --body. В Linux для этого есть команда iconv:

# iconv --from-code=us-ascii --to-code=utf-16 1.csv --output=16.csv
# file -i 16.csv
16.csv: text/plain; charset=utf-16le

И теперь всё будет корректно.

Отдельно стоит добавить, что "конвертировать" US-ASCII в UTF-8 не получится (незачем) и в результате будет всегда показываться кодировка как us-ascii, т.к. она "включена" (является подвидом, совпадает по битам) кодировки UTF-8.

#s3

Тэгирование есть документирование вашей системы.

Дайте шанс самому себе же через год и добавьте временно поднимаемой виртуалке тэг description со значением can be deleted at any time, чтобы после не расспрашивать всех, что за враг что-то создал и не убрал за собой, а просто тихонечко удалить.

Дорогие читатели, запись моего доклада для Highload++ 2019 - https://youtu.be/BEZKub1BYCE

Таймкоды к видео Нормально делай - нормально будет:

0:17 - Кому хорошо спится по ночам
2:36 - Зачем нанимают амазонщиков
3:07 - Least Privilege Principle (LPP)
4:40 - Метод обезьянки для борьбы с LPP
5:54 - В любой непонятной ситуации берите M-тип виртуалок
6:34 - Горизонтальное масштабирование против вертикального
8:08 - Только Spot, только хардкор!
9:13 - Проблема next-next-next-finish.
9:50 - Идентификатор зоны доступности и его отличие от имени зоны доступности
11:50 - Не используйте AWS Console вообще! (штоа?!?)
12:25 - Infrastructure As Code и экстремалы из Ansible
14:53 - cfn-lint (линтер, который не валидатор)
16:54 - AWS Trusted Advisor - сервис-советчик
17:54 - AWS Config - история изменения ресурсов с проверкой Compliance
18:51 - RDK (Rule Development Kit) для AWS Config Custom Rules
21:15 - Well-Architected Framework
22:08 - Well-Architected Tool
24:20 - Multi-Account Strategy
28:50 - Расчёт оценки решения
30:51 - Эксплуатационные издержки
32:42 - Делайте нормально и спите хорошо!

Вопросы:

33:36 - Как вы относитесь к Фаргейту (спойлер - очень положительно)
34:37 - Когда будут реализованы persistent volumes для Фаргейта (спойлер - следующий вопрос)
35:07 - Когда Карен напишет книжку «Стандарты разработки Serverless приложений» (спойлер - в раздумьях)
36:30 - В каких случаях стоит использовать Serverless (спойлер - отталкивайтесь от проблемы)
38:05 - Serverless - это не лямбда, а подход (ответ из зала)
39:17 - Преобразование одного аккаунта с продом в мультиаккаунт схему (без спойлера)
40:32 - Terrafom vs CloudFormation (спойлер - CloudFormation более надёжный)
44:23 - Подводные камни у Route53 (спойлер - не поддерживает DNSSEC)

п.с. Удалось дважды попасть в кадр на 10:12 и 24:25.

⁠В̵с̵помнить всё

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

И вот сегодня примерно-показательно выяснилось, что и сам такой же. Кому лень читать лог чата, то коротко - посоветовал вариант решения, предполагая, что Access Control по тэгам объектов в S3 невозможен, а потому нужно использовать другой подход, в то время, как это давно реализовано.

То есть вот писал про тэги тут сто раз, понимая и рассказывая их важность, а не знал вещей 2013-го года розлива.

Задумался, как же так. После потужился и вспомнил, таки читал в документации, но не встречая реальных примеров использования-обсуждения таких проблем и это ушло на задний план. А после, видимо, было окончательно отторгнуто логикой "это ж ведь расходы какие на каждый запрос к объекту - вряд ли значит так может быть".


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

Другой: делайте внешний аудит ваших решений, какие бы профи у вас не работали (в том числе вы лично или я).

Ну и третий - проходите сертификацию, сдавайте на сертификаты. Писал, что не получал сертификатов за ненадобностью, как считал. И на выходе, вот, прорехи в обороне. Надеюсь, что сдача на сертификат позволит структурировать знания и закрыть такие бреши.

#учиться #учиться #учиться

Инструменты для получения минимальных прав (Least Privilege Principle), что требуются приложению с помощью CloudTrail:

https://medium.com/netflix-techblog/introducing-aardvark-and-repokid-53b081bf3a7e

https://github.com/duo-labs/cloudtracker

Это в дополнение к видео выше.

Где задать вопрос по AWS

Официальный форум:
https://forums.aws.amazon.com/
Официальный, англоязычный, требуется аккаунт в AWS.

Reddit:
https://www.reddit.com/r/aws/
Большой и популярный англоязычный форум, короче - Reddit.

Slack og-aws (каналы #questions #cloudformation
#ecs и другие) - требуется инвайт.
Инвайт можно получить на https://og-aws-slack.lexikon.io/ , большое количество каналов по Амазону, известные AWS-гуру обитают тут, потому вопросы предполагают какой-то достаточный уровень. Задавать вопросы сразу в нескольких каналах не принято. Если не знаете точно темы - задавайте в #questions. Англоязычный.

Slack hangops (канал #aws) - требуется инвайт.
Инвайт можно получить на https://signup.hangops.com/ , живенький AWS-чат, вопросы предполагают некоторый уровень, англоязычный.

Телеграм:
AWS_ru
AWS Minsk Community
AWS@NSK
AWS User group Kazakhstan

Чат AWS_ru - самый большой и самый популярный русскоязычный чат по AWS.

Его преимущества - очень много народу, можно получить с большой вероятностью качественный комментарий, т.к. его читают и в нём отвечают представители AWS. Задать вопрос можно любого уровня и при этом не побьют.

Его минусы - когда много народу спрашивает, лента бежит быстро и на ваш вопрос могут так и не ответить, даже если кто-то мог и хотел.

Поэтому, если вы из Минска-Новосибирска-Казахстана-поблизости - старайтесь задавать вопрос в своих сообществах. Везде есть профи, только местные точно увидят ваш вопрос и с удовольствие ответят. Кроме того представители AWS мониторят и эти каналы, потому также смогут прокомментировать.

Facebook:
https://www.facebook.com/groups/aws.notes/
Юзер-группа канала aws_notes, требуется аккаунт в Facebook. Народу нет совсем, но если кто спросит - я точно отвечу. :) Копирую туда новости из этого канала для тех, кому удобней читать и комментировать в Фейсбуке.

#info