AWS Notes

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

https://twitter.com/memenetes/status/1184444822892892160 #пятничное

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

⁠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

​​Даже Амазон не знает, кому это может быть нужно. 🤣 #WorkSpaces #пятничное

Последовательность блоков в #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

⁠Мда, судя по всему, с такими успехами, придётся делать посты к заметкам. :) 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

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

Скопировать с ECR-репозитория в другой нельзя ("напрямую" - через какую-то апишку/команду), можно лишь спулить и запушить. Но пилят регион-репликацию: https://github.com/aws/containers-roadmap/issues/140 Актуально для DR (Disaster Recovery) - ведь при падении региона может упасть и региональный #ECR (такого ещё не было, но это правильный подход).

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

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

⁠Beanstalk - есть и хорошие новости Зря наезжал - #Beanstalk реабилитирован. #праздничное

⁠re:Invent 2019 - Итоги Анонсы продолжают сыпаться (за последние два дня больше сотни, чуть ли не половина - новые фичи), реинвент ещё не начался, но итоги уже можно подвести. Нас будут развлекать говорящие тёти Алексы, всё более неотличимые от живых людей, ролики в 8k разрешении, быстрее-больше-удобней дашбордов-графиков-отчётов. Удобство управления доступом пройдёт под знаменем новой эры Amazon Attribute Based Access Control. Лямбды настолько прокачались, что из serverless перекочуют в functionless. Инфраструктурные вещи не будут столь выражены, т.к. почти всё уже было сделано. Продолжится централизация управления всем внутри и вокруг SSM. Ключи будут шифроваться и шифровать все сервисы подряд, а интеграция со сторонними вендорами по всяческим фичам множиться и шириться. Но главное не это. Реинвент не просто подчеркнёт, а будет форсить новую тему - использование AI/ML функционала для простых девелоперов и админов, бизнес-аналитиков и менеджеров. Так что если вы завидовали патлатым и бородатым датасайнтистам за их умение разговаривать на непонятные нейронные темы - расслабьтесь, теперь не только они владеют священным знанием. Не поступили на кафедру искуственного интеллекта - так теперь и не надо. Всё что нужно - покурить документацию новых фич Aurora, Athena, Quicksight. Они работают сами и позволят напрямую работать с моделями машинного обучения без дополнительных наворотов, предоставляя нужный функционал из коробки и чуть ли не прямо через SQL. Это новый тренд - ИИ от бессмысленных разговоров про завоевание человечества становится каждодневным инструментом в работе всё большего количества людей. В общем, звучит немного пафосно, но это факт. Так что если вы девопсите и верите в вечную жизнь IPv4, почивая на вершине пирамиды зарплат, помните - это уже в прошлом. #тренды #прогнозы #мнения

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

⁠Политики тэгирования - 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

⁠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

Основные новые фичи коротко • Приватные 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

​​100 EKS кластеров в одном регионе для тех, кто так и не освоил #multi_account_strategy: https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-eks-increases-limits-to-100-clusters-per-region/ #EKS

⁠ ABAC + AD FS Опять в продолжение Tag-Based access control (или официально ABAC - Attribute-Based Access Control) - очередные подробности, как и говорилось, о гибкой работе данной схемы с AD: https://aws.amazon.com/blogs/security/attribute-based-access-control-ad-fs-simplify-iam-permissions-management/ В примере показывается, как можно смапить свои атрибуты из AD на тэги, управляя таким образом доступом к ресурсам через них (tags), а не плодя несчисленное количество ролей под каждую нужду. #ABAC #AD

⁠Редактирование файлов прямо на S3 Если зачем-то нужно именно так, то уже оно есть: https://github.com/tsub/s3-edit Настраиваете credentials с помощью aws configure и запускаете s3-edit edit s3://mybucket/myfile.txt - откроется ваш дефолтный редактор. Сохранив - это будет сразу на S3. #s3