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

https://aws.amazon.com/events/

У кого ещё нет аккаунта, можно посмотреть какой-нибудь онлайн вебинар и совместить полезное с приятным - получить до 100$ кредитов на эксперименты.

#халява

⁠Тэги для AWS Account

C недавнего времени можно добавить #tags на весь AWS Account - это делается в консоли AWS #Organizations (см. картинку) или через командную строку. Если у вас активно используется #multi_account_strategy, то этим точно стоит воспользоваться.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tagging.html

AWS Control Tower

То, о чём так часто тут говорилось - #multi_account_strategy - наконец-то воплотилось в рабочий сервис у амазона. Встречаем AWS #Control_Tower:

https://aws.amazon.com/blogs/aws/aws-control-tower-set-up-govern-a-multi-account-aws-environment/

Однако те, кто уже использует AWS #Organizations будут грустить, ибо получат ошибку:

You tried to use an account that is a member of an organization in AWS Organizations. To set up your AWS Control Tower landing zone, use an account that is not a member of an organization.

Потому воспользоваться AWS Control Tower смогут лишь избранные 90%, кто до этого времени не успел ознакомиться со своим счастьем в виде AWS Organizations.

#строили_строили_и_наконец_построили

⁠RDS Performance Insights для старых БД

Если вы решили обновить свой #RDS инстанс, чтобы включить Performance #Insights, то не забывайте про то, что он доступен лишь для более свежих версий движков и условно вашему PostgreSQL 9.6 такое не грозит и именно поэтому вы не видите у себя в консоли такой опции:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html

⁠Лимиты Амазона - Service Quotas

Свежевышедший и весьма полезный Service Quotas показывает все #лимиты Амазоновских сервисов в одном месте, а также позволяет их увеличивать без челобитных в техподдержку.

Например, на скриншоте его работы приведена весьма полезная информация ограничений сервиса #CloudFormation, где несерыми кнопками отмечены те из них, которые можно оттуда изменить.

Кроме того доступна и #aws_cli для #service_quotas, где можно наглядно посмотреть, как это работает под капотом:

https://docs.aws.amazon.com/cli/latest/reference/service-quotas/index.html

⁠You reached the quota on quotas

У анонсированного ранее #service_quotas тоже есть свои #лимиты и потому при активных попытках повысить ваши текущие квоты, можно получить #error:

An error occurred (QuotaExceededException) when calling the RequestServiceQuotaIncrease operation: This account has reached the maximum number of open service quota increase (SQI) requests. Before opening another SQI request, wait for an open SQI request to be accepted or rejected.

#lim(lim)

S3 Transfer Acceleration

Для случаев, когда нужно загружать в бакет быстро-много-часто и со всего мира, то на загрузку можно включить ускорение (кушает некоторые деньги):

bucketUploads:
 Type: AWS::S3::Bucket
 Properties:
   BucketName: !Ref BucketUploads
   AccelerateConfiguration:
     AccelerationStatus: Enabled

https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html

#s3 #acceleration #CloudFormation #templates

S3 bucket naming

Придумывая имя для очередного бакета, чтобы не иметь проблем, настоятельно рекомендуется использовать следующие правила:

только маленькие буквоцифры и дефис

Например:

company1-some-project-us-west-2
myproject33-dev

Никаких нижних подчёркиваний или больших букв, неправильно:

SuperBucket98
my_storage

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

Также крайне нежелательно использовать разрешённые пока точки, очень-приочень не рекомендуется:

cool.site.net
some.domain6

Точки были актуальны в дикие времена нешифрованного HTTP. А теперь, когда везде требуется шифрование HTTPS, смысла использовать такие бакеты (с точками) для хостинга сайтов нет - всё равно придётся ради SSL-сертификата положить сверху #CloudFront.

Некоторые полезные вещи, например, вышеупомянутый #s3 #acceleration - не прокатит для бакета с точками. И другие вдруг потребовавшиеся в будущем. Потому - никаких точкобакетов!

Итого: правильный бакет — right-bucket-name-from-3-to-64-symbols-length

⁠Подключение к 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

⁠
Зоопарк обозначений EC2 инстансов

На картинке указаны не все варианты. Полный список по официальной ссылке:

https://aws.amazon.com/ru/ec2/instance-types/

#ec2 #info

CloudFormation development tool - Rain

Для тех, кто работает со стэками в командной строке - очередная попытка хоть как-то обустроить работу с #CloudFormation #templates:

https://github.com/aws-cloudformation/rain

Принцип работы можно понять по гифке в описании репозитория. Для простых вещей кому-то может оказаться полезно.

⁠Сообщения Амазона на дополнительный ящик

Когда возникает требование дублировать сообщения, которые Амазон шлёт на почту #root-юзера (например, вы передаёте аккаунт заказчику, а его нужно дальше сопровождать и, значит, продолжать получать сообщения), то для этого есть возможность добавить Alternate contacts в менюшке My Account:

https://aws.amazon.com/premiumsupport/knowledge-center/account-email-cc/

Несколько AWS аккаунтов на одну почту

Обычно очень неудобно плодить ящики.

Например, (не)вы (не)удачно закоммитили креды в публичный репозиторий и уже заметили, что кто-то поменял пароль — вы решили быстро удалить (закрыть) AWS аккаунт (будем считать, что он был чисто тестовый), то есть по сути "пересоздать" (закрытие аккаунта - самый быстрый/лучший способ "удалить всё"). Однако Амазон при регистрации нового аккаунт скажет, что почта уже используется.

Или вы захотели попробовать #multi_account_strategy, а для каждого аккаунта ведь нужна почта - снова плодить сущности? А как было бы удобно иметь все аккаунты такой организации на один ящик.

Выход есть. Возможно кто-то пропустил, но уже десять лет как можно добавлять плюсик в почту, получая разные почтовые адресы, при этом имея один ящик. Например, такое точно есть у Google или Яндекс.

Т.е. при регистрации нового аккаунта можно разработать свою схему, к примеру, вот такие варианты:

[email protected]
[email protected]
[email protected]
[email protected]

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

#хитрости

Использование T2/T3 инстансов в проде

Можно ли использовать T2/T3 для #EC2, #RDS и прочих сервисов в продовских окружениях? Запросто. Нужно лишь помнить и учитывать моменты, которые отличают их от "полноценных" инстансов. Это baseline (нагрузка) и сеть (задержки).

Baseline (нагрузка)

Если у вас постоянная/долговременная нагрузка на проде выше #baseline (правая колонка):

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

То он будет тормозить. Что плохо, точней, обычно недопустимо, потому ставим "полные" c4/c5/m4/m5 и т.д.

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

Сеть (задержки)

Если с первым (загрузкой) более-менее всем понятно, то вот второй фактор многие не учитывают - скорость сети у T2/T3 инстансов не только ниже, а временами хромает, ковыляет, страдает и даже просто, бывает, лежит. Дипломатично в документации это называется "не гарантирована".

Для каких-то сервисов это может быть не столь критично, а вот лаги RDS на T2/T3 могут стать неприятным откровением. В таком случае активно используйте кэширование, мониторинг и здравый смысл.

Реальную скорость сетевого интерфейса и её катастрофу, когда кончаются бурсты - можно посмотреть по следующей полезной ссылке:

https://cloudonaut.io/ec2-network-performance-cheat-sheet/

Итого

Не умеешь - не обгоняй. Боишься, деньги казёные или лень разбираться - ставь "полные версии".

Хочешь (нужно) сэкономить, протестировано, мониторинг, кэширование и прочий фарш помноженный на рассудок - смело используем T2/T3, в том числе на проде.

#t2 #t3 #prod

⁠SSM Session Manager + SSH

Вслед за недавно появившимся EC2 Instance Connect, прокачался идеологически правильный способ коннекта к виртуалке - через #Session_Manager. Теперь он умеет туннелировать SSH и SCP.

Настройка SSH Session Manager Sessions (отличное название, чуваки, снимаю шляпу) по официальной ссылке:

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html

У кого уже стоит Session Manager plugin - нужно обновить до версии 1.1.23.0 или более новой.

⁠SSH туннелирование через SSM Sessions Manager

Куда

На виртуалке, куда мы хотим коннектиться должен быть установлен SSM агент. Правильные пацаны юзают Amazon Linux 2, где он стоит по умолчанию на новых версиях. Однако даже на только что поднятых из консоли виртуалках стоит не самая последняя версия (фу, Амазон), потому запускаем стандартный установочный однострочник:

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

Для неудачников на своих Убунтах и прочих некошерных линуксах - двигаем по ссылке первоисточника.

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

Для всех (т.е. 0.0.0.0/0 - обязательно) открываем порт 22 (укоряюще смотрит на всех безопасников Амазона).

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

Откуда

На виртуалке (компьютере), откуда будем коннектиться на подготовленную ранее виртуалку, требуется #aws_cli (само собой разумеется) и должен быть установлен Session Manager Plugin.

Правим файл SSH-конфига (который в домашнем каталоге ~/.ssh/config), добавляя для хостов, куда хотим коннектиться запуск ProxyCommand - см. официальную ссылку.

Всё, должно работать:

ssh -i /root/.ssh/ttt19 ec2-user@i-016de9a622dfd5430

(см. картинку)

===

#multi_account_strategy

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

Для примера, вот полная версия реального файла /root/.ssh/config:

# CodeCommit
Host git-codecommit.*.amazonaws.com
 User ADDAJA5W7IDY5CHX3YKK
 IdentityFile ~/.ssh/codecommit_devops-user

# SSH over Session Manager
host i-* mi-*
 ## single account
 #ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

 ## multi account (stage account)
 ProxyCommand sh -c "aws --profile=stage ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

#tutorial

Deployless - быстрей, чем vim на проде

Только пытаетесь освоить #serverless? Забудьте, это же прошлый век! Нонче на острие прогресса #deployless — все ваши изменения на проде быстрей, чем вы поняли, что прочитали! Или написали.

https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671

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

#пятничное

Кому интересны подробности по #deployless, то их есть тут:
• https://waterbear.cloud/2019/07/06/waterbear-cloud-goes-open-source
• https://waterbear.cloud/2019/06/07/the-semantic-cloud-a-new-vision-for-infrastructure-as-code-projects
• https://www.reddit.com/r/aws/comments/cblkgx/new_semantic_declarative_infrastructureascode
• https://news.ycombinator.com/item?id=20395228

⁠Amazon CloudFront announces new Edge location.

⁠Увеличение EC2 диска

Просто увеличить размер диска (#EBS #Volume) через AWS Console не составляет труда. Для пущей безопасности в любом случае лучше сделать перед этим снэпшот.

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

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

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