Если вы умеете работать в #AWS_Console, но не умеете или лишь осваиваете #CloudFormation, то для вас #AWSConsoleRecorder может быть бесценной находкой.

https://github.com/iann0036/AWSConsoleRecorder

Вы делаете всё нужное в браузере с помощью плагина, а на выходе получаете готовый сценарий в виде команд, CloudFormation шаблона или других вещей, в частности #Terraform.

При попытке восстановить #RDS #Snapshot в #Shared_VPC получаем такую ошибку:

The specified VPC vpc-04bee1a347f431036 is a shared VPC, please explicitly provide an EC2 security group.

Пока через #AWS_Console это невозможно, т.к. нет возможности выбрать security group (её просто нет в параметрах).

Потому только через #aws_cli:

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier mydb \
    --db-snapshot-identifier my-snapshot \
    --db-instance-class db.t2.micro \
    --availability-zone us-east-1c \
    --db-subnet-group-name my-dbsubnetgroup \
    --no-multi-az \
    --no-publicly-accessible \
    --auto-minor-version-upgrade \
    --vpc-security-group-ids sg-0cf1206653f75d50d

Всё из-за последней строчки, которая появилась в последних версиях aws-cli, потребовавшейся с приходом Shared VPC.

⁠Подключение к EC2 виртуалкам

Для подключения по SSH к #EC2 инстансам #best_practices является ипользование #SSM #Session_Manager. Однако теперь это можно в некоторой степени дополнить использованием EC2 Instance Connect.

https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/

Предварительно установленный на виртуалку (к которой нужно подключиться) сервис #ec2_instance_connect позволяет прокинуть ваш публичный ключ в meta-data инстанса, где он будет жить 60 секунд и может быть использован для логина ssh-демоном.

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

Т.к. это происходит через AWS API, то коннектиться можно с приватных айпишников.

В отличие от SSM Session Manager, #ec2_instance_connect требует открытый 22 порт на входящие (хотя можно и рекомендуется его ограничить лишь амазоновскими айпишниками, т.к. соединение идёт через сервисы амазона).

Как было сказано, для работы с EC2 Instance Connect - его сначала нужно устанавливать. Предустановлен он лишь в Amazon Linux 2 - очередная причина, почему правильно его использовать (и именно AL2, а не первый).

#SSH

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

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

#AWS_console

⁠EC2 Console + Session Manager

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

Правая клавиша на инстансе (у которого стоит и настроен SSM agent), жмём Connect. (вверху картинки)

Далее, к сожалению, придётся ещё кликать, т.к. по умолчанию стоит инфо по подключению через SSH - меняем на Session Manager и снова жмём Connect. (в середине)

Открывается обычное терминальное окно SSM Session Manager - радуемся. (нижняя)

#SSM #EC2 #AWS_Console

⁠bare metal инстансы + AWS Console

Когда вы хотите выбрать bare metal инстансы (i3 или или другие *.metal), чтобы, например, соблюсти какие-то жёсткие требования для вашего окружения, то при выборе в консоли по-прежнему обнаружите менюшку Tenancy и Shared по умолчанию.

Ничего такого в реальности нет, никакие Shared неприменимы к bare metal типу инстансов, вы полностью работаете напрямую с железом, без гипервизоров (потому можно запустить свою виртуализацию, что не позволяют другие типы инстансов - на них не получится запустить условный Virtual Box, только на bare metal) и без каких-то "соседей".

Недоработка текущей версии AWS Console.

#AWS_Console #bare_metal #issue

⁠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

Понимаю, что уже понедельник, но это прекрасно:

https://twitter.com/ScribblingOn/status/1228758330769903618

Литературный перевод:

Никакой ваш предыдущий жизненный опыт не подготовит вас к использованию AWS консоли. Ни-ка-кой.

#AWS_Console

⁠AWS Simple Iconification Service

Простенькое расширение, добавляющее иконку на вкладки AWS Console (см. картинку). Просто и со вкусом, когда вкладок много — хоть как-то можно ориентироваться.

Chrome:

https://chrome.google.com/webstore/detail/aws-simple-iconification/edagjlhogddnlkbkllibfhbekpcdppbk

Firefox:

https://addons.mozilla.org/en-GB/firefox/addon/simple-iconification-service/

Исходники:

https://github.com/leepa/aws-simple-iconification-service

#AWS_Console

⁠Логин в AWS Console сменил дизайн (на человеческий)

Теперь, наконец, проще понять самому и объяснить другим - как попасть в консоль через юзера или рута (см. картинку).

#AWS_Console