Некоторые операции в AWS консоли требуют именно рута (т.е. нужно логиниться как #root_user). Чтобы не гуглить в поисках объяснения, почему у вас в консоли нет какой-то вещи, в то время, как в документации или какой-то статье она есть, то стоит периодически заходить сюда:

https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html

Например, это будет полезно, если вы вдруг захотите включить мегазащиту MFA Delete на свой бакет с нажитыми за долгие годы бесценными логами или срочно потребуется посмотреть в консоли Account Canonical User ID (он же #s3_canonical) — всё это также должно делаться из-под рута.

⁠#ECR-репозиторий имеет ограничение в 1000 образов максимум. Когда у вас активный процесс разработки, то этот кажущийся большим лимит очень даже быстро достигается и вы получаете много удовольствия от упражнений по изучению логов под названием "ну вчера же работало".

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

Светлая мысль "с этим что-то нужно делать" помноженная на гугление в попытках что-то найти и отсортировать в AWS консоли по работе с ECR докер-образами — очень скоро приведёт вас в уныние. Не расстраивайтесь, это не вы верблюд - там действительно не работает пэйджер (фильтры применяются лишь к одной странице). Пусть вас успокаивает факт, что они страдают точно также.

В общем смысл следующий - нужно настроить ECR LifecyclePolicy. Пишем правила, какие тэги сколько живут и добавляем каждому репозиторию, в результате порядок будет поддерживаться автоматически.

Если репозиторий один, то можно и потыкать ручками, однако если десятки? Тогда используем для этого секретную менюшку Edit JSON (на картинке внизу), откуда можно скопировать натыканное и размножить для других репозиториев.

Тяжело разбираться без примеров, потому вот реально используемый вариант #LifecyclePolicy:

{
 "rules": [
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "develop"
       ]
     },
     "description": "clean 'develop*' after 180 days",
     "rulePriority": 10
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "feature"
       ]
     },
     "description": "clean 'feature*' after 180 days",
     "rulePriority": 20
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 180,
       "tagStatus": "tagged",
       "tagPrefixList": [
         "hotfix"
       ]
     },
     "description": "clean 'hotfix*' after 180 days",
     "rulePriority": 30
   },
   {
     "action": {
       "type": "expire"
     },
     "selection": {
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 1,
       "tagStatus": "untagged"
     },
     "description": "clean Untagged after 1 day",
     "rulePriority": 40
   }
 ]
}

В дополнение к предыдущему посту по #ECR #LifecyclePolicy - в идеале такое должно быть автоматизировано с помощью #CloudFormation #templates.

Это не всегда реально: например, какой-то старый проект, нельзя пересоздать репозитории. Но если можно пересоздать - чтобы репозиторием рулил CloudFormation или для нового проекта, то это получается реально удобно. Создаём репозитории с помощью шаблона типа:

https://github.com/applerom/cloudformation-examples/blob/master/ecs/ecr-repo.yml

Как видно в шаблоне - LifecyclePolicy прописывается в чистом виде (JSON). Там же для удобства добавлен шаринг для других аккаунтов, что всегда требуется в случае #multi_account_strategy (если не нужен - просто комментируем). Всё легко кастомизируется под свои значения и любимые скрипты.

Если нужно быстро — просто ручками меняем шаблон и запускаем/обновляем стэк. В любом случае это правильней, чем тыкать через консоль, т.к. контролируемо: и через год, и даже не вы, а другой — сможет повторить процесс. В том числе такой подход позволяет выявить Drift — кто чего тут натыкал, пока вас не было.

#всё_под_контролем

При попытке восстановить #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.

Когда вы пишете условный pipeline/утилиту/скрипт, который будет работать (например, деплоить) с разными окружениями (dev/test/stage/prod), то часто возникает искушение использовать под каждое окружение свою ветку. Это кажется логичным и очевидным.

Однако это (branch-by-environment strategy) не лучший подход и вскоре вы можете столкнуться с трудностями - от неудобности внесения каких-то глобальных изменений, которые потребуют внесения одного и того же по всем веткам, до сложности что-то потестировать в отдельном окружении с последующим откатом.

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

• https://guides.github.com/introduction/flow/

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Амазоновцы таки отреагировали на народные чаяния и убрали из рекомендаций для #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