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

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

Кому удобней читать (и комментировать) в Facebook - есть такая страничка:

https://www.facebook.com/aws.notes

Все материалы из этого канала портируются и туда. С некоторыми дополнениями, исправлениями и улучшениями (насколько это возможно - разные форматы).

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

Подписывайтесь или просто поставьте лайк странице. :)

#facebook

Transit Gateway vs VPC Peering

AWS Transit Gateway действительно удобный способ объединения VPC и он рекомендован как современный подход к реализации VPC peering.

Однако не нужно забывать, что халява - это не про Амазон и просто так один сервис не заменяет другой, будучи при этом более продвинутым и архитектурно правильным. Отгадка находится по официальной ссылке:

https://aws.amazon.com/transit-gateway/pricing/

Если присмотреться, то по сравнению с #VPC_peering, где вы платите лишь за трафик по стандартному ценнику $0.02/GB, добавляется ещё и часовая составляющая — по 5 центов с носа каждой #VPC. При этом VPC минимум две, а значит $0.1 в час или условная m5.large виртуалочка, что для многих может оказаться роскошью.

А когда у вас аккаунтов (а значит и VPC) больше, то сумма за #Transit_Gateway будет кратно более ощутимой. Понятно, что для крупной организации это не те расходы. Однако стоит про них знать, учитывать и ещё крепче любить старый добрый VPC peering.

#pricing

Цены на трафик в Амазоне

Дополняя предыдущий пост по стоимости трафика - расширенная картинка где, чего и сколько стоит.

#pricing

Вертикальное масштабирование EC2

#Вертикальное_масштабирование EC2 - это изменение типа виртуалки, а не количества виртуалок в autoscaling group (что есть горизонтальное масштабирование).

Некоторые задачи невозможно, проблемно или просто неудобно горизонтально масштабировать. Не всё и не все ещё докеризировались, а при этом нужно, чтобы мощность менялась. Мощность зависит от типа виртуалки.

Можно делать это руками - останавливая, докидывая мощи и самому стартуя виртуалку, например, придя на работу.

А можно это доверить готовому решению AWS Ops Automator. Как его приготовить под такую задачу, есть тут:

https://aws.amazon.com/ru/blogs/architecture/aws-ops-automator-v2-features-vertical-scaling-preview/

#AWS_Solutions #Ops_Automator

⁠Сертификаты-требования-стандарты — Compliance

Когда вам вдруг потребовалось разобраться с вашим приложением на Амазоне и его соответствия каким-то сертификатам/требованиям/стандартам (в русском языке нет простого и точного соответствия, потому лучше использовать #compliance), то прежде, чем гуглить и википедить, стоит пройти по официальной ссылочке:

https://aws.amazon.com/compliance/programs/

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

https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

Наличие в этом списке ничего не гарантирует, однако вы хотя бы сможете сформулировать "может соответствовать".

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

#аудит_своими_руками

Проверочная опция --dryrun при работе с S3

Если вы боитесь или не уверены в том, что произойдёт с вашим #s3 бакетом после запуска команды aws s3 sync или aws s3 cp, то не забывайте про иногда спасительный ключик --dryrun, добавив который, увидите, как бы вы всё поломали, если бы его не добавили:

aws s3 sync --dryrun ./my-folder s3://my-bucket/some-path
(dryrun) upload: my-folder/my-cert.crt to s3://my-bucket/some-path/my-cert.crt
(dryrun) upload: my-folder/my-cert.key to s3://my-bucket/some-path/my-cert.key

В строчках добавлено (dryrun), обозначающее, что команда бы сделала без этого ключика. А так ничего не происходит.

Опция --dryrun покажет проблемы #IAM доступа (правильно ли прописаны #bucket_policy), т.е. даст такую же ошибку как и с "нормальной" командой.

Особенно --dryrun помогает, когда вы хотите залить большой объём данных в "пересекающиеся" директории важного объёмного бакета, которые после упаритесь вылавливать-исправлять (или не сможете совсем). Тут можно было бы посоветовать скопировать данные в другой бакет, но часто это многие гигабайты или просто невозможно.

В общем, --dryrun сэкономит ваши нервы и время. Даже если у бакета включено #versioning.

Защита root-аккаунта или тысяча первое китайское предупреждение

Спички детям не игрушка, мойте руки перед едой, используйте двухфакторную авторизацию и не давайте #root-доступ в #root-аккаунт:

https://medium.com/@victoryteam/nightmare-scenario-employee-deletes-aws-root-account-29e28af15436

p.s. Обсуждение на реддите:

https://www.reddit.com/r/aws/comments/cgty96/nightmare_scenario_employee_deletes_aws_root/

#плач_Ярославны

⁠Проблемы NLB + TCP Health Checks

Когда требуется реализовать end-to-end шифрование, то логично выбирать #NLB для подобной задачи. Т.е. это когда не подходит терминация #SSL трафика на ALB, а вы хотите прямиком доставить ваш #TLS до каждого инстанса.

При реализации такой очевидной схемы с NLB можно наткнуться на нестабильную работу TCP Health Check - у вас точно открыты порты, а Health Check не прокатывает, совершенно случайные ошибки, лаги с ответами и прочие странности.

В таком случае не забывайте про ELB (Classic Elastic LoadBalancer). Он прекрасно умеет TCP forwarding и пока его окончательно не списали с большой долей вероятности решит ваш вопрос. С ним не будет никакой магии с HealthCheck-ами.

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

В любом случае помните, что большинство задач на Амазоне всегда можно решить несколькими способами и решить хорошо.

AWS Secrets Manager secrets - вставляем в окружение и сохраняем на диск

Достойные "напосмотреть" утилитки для работы с секретами — одна позволяет инжектировать их в окружение:

https://github.com/sgreben/aws-secretsmanager-env

А другая — в файлы:

https://github.com/sgreben/aws-secretsmanager-files

Нет возможности работы в мульти-аккаунте - вещь свежая, наверняка допилят. Кто любит #Go - может понравиться.

#Secrets

#serverless #пятничное