Lambda Cost-Saving

Хорошая статья о реальном случае урезания костов проекта, активно использующего #Lambda:

https://medium.com/foxintelligence-inside/how-we-reduced-lambda-functions-costs-by-thousands-of-dollars-8279b0a69931

#cost_saving

⁠Дефолтные настройки создания RDS для Prod/Dev/Test

Информация больше для начинающих, но всё же.

Если вам дали задание создать #RDS инстанс для какого-то окружения и вы поднимаете для своего дохлого сайтика с полутора пользователями агрегат размером в db.r5.xlarge — скажу дипломатично, это не очень разумно.

Разберу популярные доводы (реальные кейсы) вышеописанного поведения.

«Так ведь там было написано» — на заборе тоже написано, а там дрова.

«У нас важный сайт, как бы чего не вышло» — совсем не повод выбирать Production-вариант из списка, особенно при этом чисто для тестов — это перебор капслоком в цикле. Равно как и выбор предлагаемого для Dev/Test даже если вам тействительно это нужно для Dev/Test.
В общем случае для Dev/Test почти всегда стоит начинать (да и заканчивать) вариантом типа db.t3.small. Вы же всегда сможете после (речь не о проде, хотя и для него тоже) изменить мощность RDS-инстанса. Пожалейте здравый смысл — звание почётного спонсора Амазона не даёт никаких привилегий.

«Ну там же рекомендуются эти значения - не будет же Амазон советовать плохого!» — Граждане, скажу коротко - не читайте советских газет!

⁠IE6 для фронта

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

https://www.microsoft.com/en-us/download/details.aspx?id=11575

Там скачать себе виртуалку с Internet Explorer 6 и после периодически просматривать через неё сайт, чтобы держать в бодрости фронтовых разработчиков, которые будут видеть людей, приходящих к ним с IE6.

Если вы и есть тот самый знакомый, который пилит свои сайты, то вышеописанный способ отлично подойдёт для сайтов ваших конкурентов — пущай бдят и не расслабляются!

#пятничное

Не существует такой угрозы насилием, которая бы заставила разработчиков не пихать свои пароли и прочие различные credentials в git. А, как известно, если с чем-то нельзя бороться, значит это нужно возглавить. Потому вот несколько способов, которые могут помочь обуздать девелоперское чревоугодие:

https://github.com/awslabs/git-secrets

Амазоновская утилитка проверит коммиты на наличие различных секретов.

https://github.com/Yelp/detect-secrets

Более продвинутая вещь с широким функционалом и плагинами.

https://pre-commit.com/

Ещё более навороченный фреймворк с поддержкой различных языков.

#security

⁠Доступ к бакету для всех аккаунтов организации

Бывает нужно быстро и просто расшарить какой-то бакет или его часть для всех, но не "для всех вообще", т.е. в интернете, а только "для своих всех".

В случае #multi_account_strategy данная задача преобразуется в "расшарить для всех аккаунтов организации". Для этого существует специальная опция PrincipalOrgID, которую и можно использовать:

{
 "Sid": "Full access to path /some-path for all of organization accounts",
 "Effect": "Allow",
 "Principal": {
   "AWS": "*"
 },
 "Action": "s3:*",
 "Resource": [
   "arn:aws:s3:::my-shared-bucket",
   "arn:aws:s3:::my-shared-bucket/some-path/*"
 ],
 "Condition": {
   "StringEquals": {
     "aws:PrincipalOrgID": "o-dtj1bor777"
   }
 }
}

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

#s3 #organization

⁠AWS vs Multi-cloud

В недавно объявленном пособии AWS Co-Branding Guide присутствуют прекрасные строчки:

Multi-cloud: AWS does not allow or approve use of the terms “multi-cloud,” “cross cloud,” “any cloud,” “every cloud,” or any other language that implies designing or supporting more than one cloud provider.

Дипломатичным комментарием к этому может быть только, что неправильно бороться с глобальными трэндами, один из которых — это использования multi-cloud стратегии, которая формируется благодаря уже сформированному трэнду под названием #kubernetes.

А недипломатичным — не надо ссать против ветра, товарищи.

#multi_cloud

⁠Подбор паролей с помощью AWS API Gateway

Граждане из Rhino Security Lab продолжают пугать амазоновский огород своими страшилками. На этот раз они показали, как из API и палок можно построить себе на free tier подбиралку ваших паролей:

https://rhinosecuritylabs.com/aws/bypassing-ip-based-blocking-aws/

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

#security

Паникуем кернел через aws-cli

Для любителей блюскринов (Windows) и kernel panic (Linux) есть возможность сделать это вручную, то есть через #aws_cli:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html

Ищем подходящую жертву:

aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,Tags[*]]"

Обновляем aws-cli до версии 1.16.218 или новей и запускаем команду send-diagnostic-interrupt:

aws ec2 send-diagnostic-interrupt --instance-id i-0ba0c34123549d451

В результате на пострадавшем инстансе получаем что-то типа (если Linux):

Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Uhhuh. NMI received for unknown reason 21 on CPU 0.
Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Do you have a strange power saving mode enabled?
Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Dazed and confused, but trying to continue

Хакеры в помощь

Бывает что-то пошло не так и нужно срочно найти созданное когда-то где-то кем-то окружение на неизвестно какой поддомен, вы не в зуб ногой, а на дворе пятница стынет. Понятно, что нужно было записывать, но что делать сейчас?

Тогда вспоминаем, что у хакеров, в отличие от вас, все ходы записаны. Идём на совершенно бесплатный сайтик:

https://dnsdumpster.com/

Вбиваем свой домен и смотрим, что они там о нас знают.

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

База построена на данных сервиса https://scans.io/ - да, это те, которые постоянно гадят в лог любого сервиса любой вашей виртуалки.

В любом случае очень полезно знать, что знают про вас — каждый день, каждый открытый порт. А вы и не знали, что забыли закрыть-удалить-обновить-пропатчить.

Так что теперь точно уж стоит это сделать. Нет, не сейчас, конечно - в понедельник, понятно. Сразу после того, как бросите курить, пойдёте в качалку и, наконец, запишетесь на курсы английского.

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

===

Добавлено (из комментариев в личку):
Если вы не курите, ходите в качалку и на английский, то значит без шансов — в понедельник.

Как добавить свою фичу в CloudFormation

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

Помните (или знайте), в Амазоне несколько есть глобальных долгоиграющих трендов.

1. "Тэгизация" всего — к любому ресурсу должна быть возможность добавить тэги. Это нужно для детального учёта стоимости, а также для tag-based схемы работы с #IAM.

2. "Параметризация" всего - максимальная интеграция сервисов Secrets Manager и SSM Parameter Store для возможности использования своих переменных оттуда.

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

https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/126

Запрос попадает в п.2 трендов, потому, думаю, не пройдёт и полгода, как такая фича появится. Засекаем время и ждём. А ждать, как много раз говорилось, все, кто использует CloudFormation — умеют и должны.

#время_пошло

AWS и доброта

Если вы случайно запустили какую-то вещь на Амазоне, которая сожрала *censored* сколько денег, то перед тем как пойти напиться и гуглить прайс на продажу органов, знайте про следующий лайфхак.

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

С большой долей вероятности вашу просьбу удовлетворят и через некоторое время в биллинге вы узрите человеческую цифру. А значит можно будет использовать вашу печень по прямому назначению — ведь сегодня пятница.

#доброта_спасёт_мир

Сustom CNAME для CloudFront со своим сертификатом

Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был environment. Порождённый богом CloudFormation он рос здоровым, занимался спортом, не курил, пользовался секретами и регулярно бэкапился. И всё у него было хорошо.

Но пришло лето и сказал царь - а давайте обновим вон того в углу, полгода не трогали, скукотища и, вообще, что-то давно мы уже два дня как не страдали. И достал дед Вопс свой пайплайн, и закинул его в бакет. Тянет-потянет - и вытянул чудо эдакое неведомое:

com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: The certificate that is attached to your distribution was not issued by a trusted Certificate Authority. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: 336e6167-b7a6-11e9-b5c2-3166fadb8c22)

Чешет темя дед — как же ж так, то ж зимой ещё работало, а теперича уже нет.
Полез дед в интернет, а там Амазон ему и говорит человеческим голосом:

Amazon CloudFront enhances the security for adding alternate domain names to a distribution

Для твоего добра, мол, стараюсь, тебя, глупого, от Змея от Горыныча боронить что б. Спасибо б лучше сказал и нечего тут в меня гуглом тыкать.

Загрустил дед, что ж ему с сертификатом-то своим самоподписанным делать, как теперь его в CloudFront запихать?

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

Взял дед правильный сертификат, сервисом ACM выпущенный да запихал его в CloudFront. И не подавился тот, съел да не поморщился. А опосля, хитрый дед, уже вторым заходом, сменил его на свой собственный, с гербом и печатью. И получилось как раньше было.

И пошёл к царю, рассказать про битву страшную и показать зелье сваренное супротив Амазона хитрого. И сказал ему царь - ну, спасибо, тебе, дед, заколебались тебя ждать, где так долго шлялся-то?

===

Мораль из этой сказки следующая. Даже правильные вещи, сделанные правильно по всем правильным правилам #best_practices могут перестать работать. Амазон постоянно ужесточает правила работы и требования к безопасности. То, что раньше делалось, сегодня уже даст ошибку. При этом предыдущие вещи сделанные по каким-то правилам продолжат работать, но вот создать новые так же (или обновить работающие) уже не получится.

===

п.с. Итого. Создать Custom CNAME для #CloudFront со своим сертификатом нельзя (теперь). Однако проверка "трастовости" сертификата происходит лишь при создании CNAME. А значит можно сначала создать с "нормальным", а потом поменять на свой.


Ссылки по теме:

• https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/
• https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-invalid-viewer-certificate/
• https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-distributions.html

#сказка

⁠SSM Session Manager + Port Forwarding

Очередной последний гвоздь в крышку Bastion схемы работы - теперь можно через SSM прокидывать на локальный комп нужный порт.

Потестируем. Как обычно, для всех новых фич обычно требуется последние версии всего. Смотрим версию #aws_cli:

aws --version
aws-cli/1.16.218 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.208

Для порт-форвардинга требуется 1.16.220 и новей, так что обновляем.

aws --version
aws-cli/1.16.228 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.218

Теперь 1.16.228 - можно двигать дальше. Проверяем и ставим, если ещё не ставился session-manager-plugin.

Проверяем версию агента (на картинке снизу) - не самая свежая, но можно и древней (2.3.672.0 и новей).

Значит можно запускать. В моём случае запуск в другом аккаунте, потому используется флажок --profile:

aws --region=us-east-1 --profile=openfs ssm start-session \
--target i-08a829418da3d9b15 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"],"localPortNumber":["8080"]}'

Starting session with SessionId: botocore-session-1567069474-007a8050d8e22a3ed
Port 8080 opened for sessionId botocore-session-1567069474-007a8050d8e22a3ed

portNumber - это порт на инстансе, который будет форвардиться на наш локальный порт на компе localPortNumber.

Открываем в браузере 127.0.0.1:8080 и видим локально у себя локальное на удалённом инстансе. Либо доступ к базе, какому-то сервису - в общем, любому порту.

Поигравшись жмём CTRL-C и (с некоторым лагом) сессия оборовётся.
^CTerminate signal received, exiting.

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

#ssm #session_manager

Амазоновский прайс на домены (одним файлом, по прямой ссылке, без смс и регистрации):

https://d32ze2gidvkk54.cloudfront.net/Amazon_Route_53_Domain_Registration_Pricing_20140731.pdf

#info

AWS Certification

Несмотря на то, что Амазоном я напрямую занимаюсь с 2012-го года, никакой сертификации не проходил. Не было (да и нет) надобности плюс английский - далеко не мой конёк. Однако устав читать регулярный пятничный срач по теме сертификации на @AWS_ru, решил попробовать подготовиться и сдать (тоже хочу участвовать в сраче).

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

Популярная пятёрка сертификатов следующая:

Certified Solutions Architect – Associate
Certified Developer – Associate
Certified SysOps Admin – Associate
Certified DevOps – Professional
Certified Solutions Architect – Professional

Подробности по официальной ссылке:

https://aws.amazon.com/certification/certification-prep/

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

#AWS_Certification

CloudFront и формат написания S3 бакета

1. В уже совсем древние времена все бакеты адресовались как:

s3.amazonaws.com/my-bucket

2. Потом формат мигрировал в "поддоменный" вариант:

my-bucket.s3.amazonaws.com

3. После активного размножения регионов добавился "региональный" формат:

my-bucket.s3.some-region.amazonaws.com

===

1.
Первый вариант уже давно depricated и если у вас старый код, который достался в наследство и его нужно завести - смотрите связанные с этим проблемы. Для нового его использовать нельзя.

2.
Второй вариант вполне работоспособен на сегодня. Если бакет не в регионе us-east-1 (N.Virgina - дефолтный регион), то амазон сам определит где он и средиректит запрос в нужный регион, т.е. переделает его в формат третьего варианта.

Кстати, такое поведение (редирект) "под капотом" может давать хитрые ошибки для свежесозданных бакетов. Это когда вы всё делаете через CloudFormation. В таком случае из-за того, что информация о редиректе созданного в другом регионе бакета обновляется не сразу (а окружение через CloudFormation может подняться/обновиться быстро), то вы получаете ошибку 307 — т.к. редирект уже есть, а записи куда редиректится ещё нет. Через некоторое время (до получаса) всё отработает как надо, но паника может наступить раньше очистки кэша.

3.
Третий вариант ранее работал наравне со вторым. Однако теперь это уже не так. В случае работы с новым регионом me-south-1 (Bahrain) работает только третий вариант.

my-dubai-bucket.s3.me-south-1.amazonaws.com

Аналогично будет с Италией и всеми последующими новыми регионами.

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

Первоисточник:

Another option might be to use the following more general format, but be aware that this format doesn't work for Regions launched in 2019 or later


#CloudFront #S3 #AWS_Region

⁠Хорошая картинка по всем базам данным и не только. Можно наглядно и быстро соотнести сервисы Амазона с другими решениями с классификацией по типу.

Первоисточник.

#info

⁠Девопс здорового человека

Популярность вариантов сертификации AWS (по версии читалей этого канала):

1. DevOps Engineer - Professional (52 голоса)
2. Solutions Architect - Associate (22 голоса)
3. Solutions Architect - Professional (13 голосов)
4. SysOps Administrator - Associate (4 голоса)
5. Developer - Associate (1 голос)

Итого по результатам. Девелоперами и админами быть не модно. Модно быть архитектом, а ещё популярней девопсы, которые обогнали обоих архитектов даже по сумме.

Что я имею сказать по этому поводу. Повинуясь воле большинства, загуглил я вопросы на девопс-профи. И вот теперь буду молвить.

DevOps Engineer - Professional

В далёком и страшном прошлом, когда CloudFormation ещё не поддерживал Yaml, я много и славно шаблонил ElasticBenstalk-и. Это было прикольно, удобно и быстро. Правда, когда мало и ненадолго. А если вдлинную, серьёзно и с использованием только кошерных сервисов, то всё обрастало OpsWorks. Строго по рекомендациям лучших амазонозаводчиков, по мере усложнения: EB → OpsWorks → CloudFormation.

С приходом всеобщего докера, два-три года назад этот способ работы был захоронен и всё благополучно переехало в ECS. А нонче (не)благополучно мигрирует в EKS, т.к. куберы на текущий момент суть самый что ни на есть тру девопс-вэй.

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

Вы это серьёзно, да? Это по версии AWS экзаменаторов есть современный профи-девопс? То есть вот совсем без AWS Code-сервисов, без ECS, EKS и Лямбд???

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

Предположу, жавшие «DevOps Engineer - Professional» не знали (как и я до этого), что в результате им придётся здесь читать про Chef и что в ElasticBeanstalk спустя два года так и не завезли Amazon Linux 2 (в качестве основного образа используется только первый - фу два раза, Амазон). Что ж, теперь знаете (и можно пойти переголосовать).

Solutions Architect - Associate

Короче, я обожду, когда в Амазоне завяжут с курением, а пока перехожу к девопсу здорового человека, второму пункту: «Solutions Architect - Associate». Краем глаза глянул - вроде вопросы вменяемые и темы адекватные. Значит будем готовиться.


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

https://habr.com/ru/post/329840/

#AWS_Certification

Как разбить монолит на микросервисы - рекомендация от Амазона с картинками и описанием:

https://aws.amazon.com/getting-started/projects/break-monolith-app-microservices-ecs-docker-ec2/

#design

Вам достался монолит, который нужно развернуть на AWS EC2. Монолит имеет встроенную MongoDB, которой по документации на чтение требуется random I/O более 250 000 4КБ IOPS.

Какой из вариантов вы выберете?

#AWS_Certification #training