Амазоновцы таки отреагировали на народные чаяния и убрали из рекомендаций для #SSM эту жирную политику AmazonEC2RoleForSSM, переведя её в статус deprecated.

Вместо неё теперь рекомендуется использовать #IAM #ManagedPolicy AmazonSSMManagedInstanceCore, которая обеспечивает базовый функционал SSM агента, докидывая уже своё по необходимости.

#справедливость #язнал #яверил

Прежде, чем пилить какую-то вещь на AWS (речь в первую очередь о #CloudFormation #templates, но не только) рекомендуется проверить уже имеющиеся готовые Решения AWS.

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

А чтобы не так было больно, есть испытанный метод:

https://www.youtube.com/watch?v=k2wzKVa0omU

#design #best_practices

Реализовать в #CloudFormation #templates зависимость значений от environment не очень сложно. Однако когда требуется переменное количество параметров (т.е. для одного окружения один набор переменных, а для другого - отличный), то для этого Амазон сделал в своё время Fn::Transform.

Однако из-за того, что это (Transform) суть костыльный костыль, реализуемый как надстройка в виде лямбды, которая запускается перед скармливанием CloudFormation конечного вида шаблона, то реальный опыт работы с Transform оказался весьма болезненный.

Потому совет: если можно не использовать Transform - лучше не использовать.

Альтернативой может быть использование #Conditions.

Например, вот реальный кейс. Потребовалось для multi environment шаблона реализовать логику различного набора переменных для #ECS #task_definition - на тестовом окружении требовалось задать другие переменные, при этом обычные не должны быть определены совсем, т.к. чувствительное приложение, написанное в давние времена, спотыкалось о них и падало.

В результате дефолтная таска была скопирована и создана ещё одна такая же, только с нужными переменными. И добавлен волшебный condition, который из двух этих тасок в сервисе подключал нужную:

https://github.com/applerom/cloudformation-examples/blob/master/ecs/task-definition-with-different-set-of-variables.yaml

По умолчанию логика ни для какого (уже ранее имеющегося) окружения не поменяется (т.к. по умолчанию UseTestVariables = 'no'), а для тестового сработает TaskDefinition: !If [ UseTest, !Ref ecsTaskTest, !Ref ecsTask ].

Итого - всё работает стандартно и без трансформатора.

Когда нужно быстро сориентироваться в вариантах решений/технологий/утилит:

https://landscape.cncf.io

Например, вот решения по части #CloudFormation - раздел Automation & Configuration, где живут #Terraform, #Pulumi, #Chef и далее по списку.

#info

Мало кто задумывается, что не все сервисы Амазона имеют #SLA. В частности, его нет у #CloudFormation, так что все ваши претензии, что он "тупит", "тормозит", "зачтомыбабкиплатим" и "вытамсовсемохренели" - можно смело слать в девнулл.

Полный список AWS сервисов с SLA можно глянуть по ссылке:

https://aws.amazon.com/legal/service-level-agreements/

Однако в ходе решения каких-то вопросов (например, по теме #compliance) может потребоваться более детальная информация.

Допустим, у вас активно используется #CloudTrail и #Config и требуется знать, какие сервисы он покрывает (или наоборот). Или ваш проект секретно секретный и нужно максимально использовать те сервисы, что имеют at-rest-encryption.

Для этого вам поможет следующая ссылка:

https://summitroute.github.io/aws_research/service_support.html

#info

Хронология важных патчей сервисов Амазона по датам:

https://aws.amazon.com/security/security-bulletins/

Обновляется с некоторым лагом, например, там пока нет самого свежего патча против Ping of Death, который выкатили вчера:

https://aws.amazon.com/security/security-bulletins/AWS-2019-005/

#security

⁠Выбор AWS региона

Пинг (latency)

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

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

https://www.cloudping.info/

Иначе выбор уже определяется другими факторами.

Стоимость

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

https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/

Сервисы

Не все сервисы представлены (появляются) сразу во всех регионах, если это важно, то сверяемся здесь:

https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/

===

Если же у вас нет особых предпочтений и требований, то совет:

В любой непонятной ситуации выбирай N.Virginia.

#aws_region #info

⁠О дефолтных ключах шифрования (AWS managed keys)

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

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

Как правило, в первую очередь речь заходит о базах данных, т.е. #RDS #Snapshot, где в конце концов вы таки прочитаете эти печальные слова:

You can't share a snapshot that has been encrypted using the default AWS KMS encryption key of the AWS account that shared the snapshot.

Дефолтные ключи шифрования можно использовать лишь внутри одного аккаунта. Их по доброте душевной итак уже сделал Амазон, за что, видимо, нужно быть благодарным (хотя у меня, вот, тогда не получилось). А для всех #cross_account операций нужны свои ключи - Customer managed keys - которые шарятся для использования в других аккаунтах.

===

Итого, совет. Если вы никогда не планируете и не будете использовать #multi_account_strategy (мои соболезнования), то #AWS_managed_keys - реально отличное решение, стильно-модно-безопасно.

В противном случае (который является рекомендуемым) - лучше сразу закладываться на свои ключи #Customer_managed_keys. С ними будет муторней и сложней, это правда. Но с ними можно всё.

#KMS #security #encryption

Если вы изучаете 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]

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

#хитрости