AWS Notes

⁠CloudFormation StackSets + AWS Organizations StackSets получили возможность автодеплоя для всех аккаунтов в организации. До этого был похожий функцилонал (можно было выбирать аккаунты-регионы), но не было возможности именно автодеплоя для вновь добавленных аккаунтов. https://aws.amazon.com/blogs/aws/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/ Теперь есть возможность применять общие вещи ко всем аккаунтам организации централизованно или к выбранным OU. Фича как бы относится ко всей организации, но вы не найдёте её на очевидной страничке Organizations → Settings (кстати, почему?? ). Чтобы включить такую возможность, нужно зайти в CloudFormation консоль мастер аккаунта, где на вкладке StackSets появится кнопка Enable trusted access (на картинке), нажав которую, CloudFormation Stacksets получит право деплоя в любой аккаунт организации. Незаметной и важной фичей тут нужно отметить следующую вещь: If your stack set targets a parent OU, the stack set also targets any child OUs. Казалось бы - логично, что вложенные OU и все их аккаунты вы тоже бы хотели обрабатывать автоматически, указав "родительский" OU. Так вот - нет, не логично. Дефолтный функционал AWS Organizations не обрабатывает вложенные OU (и их аккаунты). Этот баг в своё время назвали фичей, а теперь, вот, пришлось тут править, чтобы удобно было пользоваться. В общем, действительно важная и обязательно рекомендуемая фича в мульти-аккаунт стратегии. #CloudFormation #Organizations

Well-Architected для Serverless Для сторонников Serverless-подхода, и тех, кто желает к ним переметнуться, теперь можно удобно прямо в консоли поотвечать на вопросы и получить готовые рекомендации, насколько желаемое соответствует #best_practices по части Serverless: https://aws.amazon.com/blogs/aws/new-serverless-lens-in-aws-well-architected-tool/ Кто не в курсе, что такое AWS Well-Architected Tool - это такая простая возможность провести аудит ваших подходов к дизайну архитектуры, получив консультацию и рекомендацию от самого Амазона. Очень стоит ознакомиться, особенно тем, кто принимает решения по архитектуре ваших приложений и вообще всего окружения. #design #well_architected

⁠OrganizationAccountAccessRole При создании нового аккаунта можно указать роль, через которую можно будет в него переключиться. Если в поле IAM role name ничего не указать, то по умолчанию создастся роль с именем OrganizationAccountAccessRole. Обычно такое название устраивает и оно уже давно прописано в различных настройках. Но если аккаунты создаются не так часто, то можно забыть - создастся ли эта роль или аккаунт канет в бездну недоступности? В интерфейсе текущей версии AWS Console для Organizations организации нет чётких подсказок на этот счёт. Потому, в том числе для себя в будущем, напоминаю: If you don't specify a name, AWS Organizations gives the role a default name of OrganizationAccountAccessRole. То есть, да, если оставить это поле (IAM role name) пустым, то создастся аккаунт с ролью OrganizationAccountAccessRole. Просто редко делаю через консоль — всё через скрипты, CloudFormation или командную строку, а там очевидно. Надеюсь, теперь запомню. #Organizations #AWS_Console

AWS CLI v2 Некоторое время назад в preview, а теперь полноценная замена: https://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/ Чтобы поставить поверх текущей - нужно удалить ссылку предыдущей (первой) версии: aws --version aws-cli/1.16.300 Python/2.7.16 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.13.36 which aws /usr/local/bin/aws rm -rf /usr/local/bin/aws curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install aws --version aws-cli/2.0.0 Python/3.7.3 Linux/4.14.97-90.72.amzn2.x86_64 botocore/2.0.0dev4 Кто ставит не в дефолтную юзеровскую директорию (использует ключики -i и -b), обратите внимание, изменилась логика работы второго параметра -b, его нужно указывать без aws на конце - первая версия предполагает полный путь, а вторая лишь каталог для ссылки. Т.е. для первой нужно было, например: sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/bin/aws То для второй версии: sudo ./aws/install -i /usr/local/aws-cli -b /usr/bin Иначе (если указать для второй аналогичное /usr/bin/aws) увидите после установки: You can now run: /usr/bin/aws/aws --version #aws_cli

Beanstalk + ALB + CloudFormation По умолчанию в Elastic Beanstalk создаётся ALB, если делать это через консоль: By default, Elastic Beanstalk creates an Application Load Balancer for your environment when you enable load balancing with the Elastic Beanstalk console or the EB CLI. А через CloudFormation - с классическим ELB! (Здравствуй, логика.) Из-за этого в документации не найти примеров кода для создания Beanstalk в CloudFormation. Cервис старый и все примеры в интернете обычно лишь для классического (старого) ELB. И документация из-за старости и сложности (под капотом) сервиса, весьма неочевидна. Вот главная ссылка, что всегда требуется при создании шаблона для Beanstalk: https://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/command-options-general.html А вот пример кода, как заставить создать Beanstalk + ALB через CloudFormation:

- Namespace:  aws:elasticbeanstalk:environment
  OptionName: LoadBalancerType
  Value:      application
- Namespace:  aws:elbv2:listener:443
  OptionName: Protocol
  Value:      HTTPS
- Namespace:  aws:elbv2:listener:443
  OptionName: SSLCertificateArns
  Value: !Ref AcmCertificateArn
- Namespace:  aws:elbv2:listener:443
  OptionName: DefaultProcess
  Value:      default
- Namespace:  aws:elbv2:loadbalancer
  OptionName: SecurityGroups
  Value: !ImportValue sgVpc4Web
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: Port
  Value: !Ref InstancePort
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: Protocol
  Value:      HTTP
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: StickinessEnabled
  Value:      true
- Namespace:  aws:elasticbeanstalk:environment:process:default
  OptionName: HealthCheckPath
  Value: !Ref HealthCheckPath

Переменные нужно поменять на свои, главная оставить LoadBalancerType - application. #Beanstalk #CloudFormation #templates

​​Картинок знаний для девопсов много, очередная найденная также будет полезной: https://roadmap.sh/devops Удобно - просто присмотревшись можно и увидеть свои дыры в знаниях, и наметить план собеседования (и, наоборот, подготовиться), быстро выбрать недостающий инстумент для какого-то процесса или просто помечтать, когда найдётся время начать всё это учить. #info #devops

Хотите работать в AWS? У вас отличный шанс прямо сейчас: https://media.thinknum.com/articles/amazon-job-openings-top-36000-yes-36-thousand/ Амазон прямо сейчас ищет 36 тысяч (реально) новых сотрудников! Например, самые многочисленные вакансии: • девелоперы — 10 000+ • архитекты (SA) — 3 000 • опсы — 2 000+ • PM-ы — 2 000+ • сэйлзы — 2 000 • machine learning — 500 • железячники — 500 Так что не мешкайте, не сомневайтесь и пробуйте. У вас всё получится! #пятничное (но правда)

Временные аккаунты в AWS Если коротко - их нет. Ждём-с. А пока есть проект, где группа энтузиастов попыталось такое реализовать уже сейчас: https://github.com/Optum/dce Работает в схеме с AWS Organizations — вы закидываете в pool свои аккаунты, которые после можно легко выдавать в работу, под капотом отрабатывает терраформ, который делает базовые настройки аккаунта, а по окончании использования в аккаунте с помощью aws-nuke удаляются все ресурсы и он вновь отправляется в pool свободных для использования. Хорошая идея реализации "одноразовой инфраструктуры". Которую, не будем показывать пальцем, всё ещё не сделали, хотя надо и давно. Могу лишь добавить, что есть некоторая информация о новых фичах AWS Organizations и, возможно, как раз вскоре выкатят удаление аккаунтов, на которое так часто жалуюсь (что его нет). В общем - ждите настойчиво и дождётесь! #Organizations

Хорошее практически-прикладное видео по Amazon EventBridge: https://www.youtube.com/watch?v=ea9SCYDJIm4 Коротко (9 мин.), понятно, на простом примере работы с эвентами для S3. Кто ещё не познакомился с Amazon EventBridge - очень советую. А всем, кто работает с Event Driven архитектурой - просто must know. #EventBridge

Подробности. Надпись на фото: «Друзья, не позволяйте друзьям строить датацентры». Когда есть AWS — незачем строить свои датацентры — когда есть AWS!

⁠Друзья! Будьте друзьями с друзьями! #AWS #friends

Single-Table Design with DynamoDB Хорошая разъясняющая статья по #best_practices архитектуры для DynamoDB: https://www.alexdebrie.com/posts/dynamodb-single-table/ Подробно описаны свойства и преимущества single-table архитектуры, а также случаи, когда это неуместно. #DynamoDB #design

SCP для запрещения обновления CloudFormation стэков Если вы деплоите всё с помощью CloudFormation и используете мульти-аккаунт схему, то очень удобно в конце отработки процесса создания/обновления для требующих защиты окружений (читай - prod) накладывать на аккаунт следующее SCP:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "cloudformation:CreateChangeSet",
       "cloudformation:CreateStack",
       "cloudformation:CreateStackInstances",
       "cloudformation:CreateStackSet",
       "cloudformation:CreateUploadBucket",
       "cloudformation:DeleteChangeSet",
       "cloudformation:DeleteStack",
       "cloudformation:DeleteStackInstances",
       "cloudformation:DeleteStackSet",
       "cloudformation:ExecuteChangeSet",
       "cloudformation:SetStackPolicy",
       "cloudformation:UpdateStack",
       "cloudformation:UpdateStackInstances",
       "cloudformation:UpdateStackSet",
       "cloudformation:UpdateTerminationProtection"
     ],
     "Resource": [
       "*"
     ]
   }
 ]
}

В списке запрещены именно изменяющие действия, просто запретить cloudformation:* неудобно, т.к. тогда не получится зайдя в этот аккаунт посмотреть текущее состояние CloudFormation стэков. А так внешне ничего не меняется, только CI/CD утилиты получат отказ при случайном (или намерянном) запуске - прод в безопасности. #SCP

⁠SSE-S3 (AES 256) - что даёт? У многих возникает вопрос - что за такое шифрование, которое просто галку поставил и всё типа зашифровано. В чём его смысл, если ничего не нужно делать и все запросы автоматически отдаются, если есть к бакету доступ? Это никакой не развод (да и бесплатно), смысл в соблюдении различных compliance. Условно говоря, если есть требование, что данные зашифрованы и что враги не могут взорвать датацентр, утащить оттуда винчестеры и скопировать с них ваши данные - поставили эту галочку и compliance выполнены. Да и просто душу греет - данные не просто там бесхозно лежат, а зашифрованы. Не ленитесь поставить - полезно, несложно, на халяву да и сразу же даёт хоть какое-то ощущение безопасности. #S3 #security

14 февраля в Минске пройдёт конференция https://delex-conf.com/, где в том числе планировалось, что буду я с докладом, но, к сожалению, у меня в это время не получается. Однако заявленная тема "CI/CD на AWS" не пропадёт и вместо меня её подхватит и расскажет Пётр Сальников, который выступал с докладами на декабрьском AWS митапе в Минске. Так что если вы планировали пойти на delex-конференцию - не пропустите его доклад (15 февраля) про AWS! Ну, а кто из минчан не хочет ждать и не любит крупные мероприятия, то есть группа AWS Friday, в которой мы договариваемся, где собираться в очередную пятницу, чтобы отдохнуть, поесть и заодно обсудить какую-то тему. Например, в ближайшую будет небольшой доклад и обсудим новые фичи Transit Gateway + Shared VPC и их влияние на пересмотр сетевой архитектуры в AWS.

​​Что делать, если утекли ключи: https://aws.amazon.com/pt/blogs/security/what-to-do-if-you-inadvertently-expose-an-aws-access-key/ Т.е. в общем случае бежим в IAM консоль скомпроментированного аккаунта и деактивируем всё, что деактивируется. Время полного отключения ключей занимает 1-2 минуты (глобально) после нажатия Make inactive. Предупреждён - значит вооружён.

⁠bare metal инстансы + AWS Console Когда вы хотите выбрать bare metal инстансы (i3 или или другие *.metal), чтобы, например, соблюсти какие-то жёсткие требования для вашего окружения, то при выборе в консоли по-прежнему обнаружите менюшку Tenancy и Shared по умолчанию. Ничего такого в реальности нет, никакие Shared неприменимы к bare metal типу инстансов, вы полностью работаете напрямую с железом, без гипервизоров (потому можно запустить свою виртуализацию, что не позволяют другие типы инстансов - на них не получится запустить условный Virtual Box, только на bare metal) и без каких-то "соседей". Недоработка текущей версии AWS Console. #AWS_Console #bare_metal #issue

Инструкция по выбору облака. #пятничное в понедельник

Видео с прошедшей 30 января встречи в компании IDT, где попросили выступить с докладом по AWS мульти-аккаунтам, который переделал, чтобы не повторять тот, что был на предыдущем митапе. https://www.youtube.com/watch?v=tCN2D35E6xQ Самое полезное - это вторые полчаса обсуждения, где было много вопросов. К большому сожалению, самих вопросов, в том числе дискуссии вопрошавших, не слышно. #video

⁠Session Duration Time Люди, кто мучается при переключении аккаунтов, из-за сессии, подло истекающей через 1 час и сбрасывающей недоделанную в консоли работу в самый неподходящий момент — не мучайтесь, пожалуйста, зайдите и поставьте себе 12 часов session duration time! https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters Просто дефолтное значение именно 1 час. Аналогично для SSO: https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html Поставь себе 12 часов - и работай спокойно! #лайфхак #IAM #SSO