[​​](https://telegra.ph/file/b7ccedaea5085a104cd05.jpg)Будь наготове

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

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

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

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

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

#ec2 #degradation #retirement #issue

⁠Об использовании доменов для внутренних нужд

Частая ошибка (проблема) - когда у вас один домен на всё. Т.е. есть корпоративный домен mydomain.com и всё из него создаётся как:

dev.mydomain.com
test.mydomain.com
stage.mydomain.com
wiki.mydomain.com
jenkins.mydomain.com
build.mydomain.com
vpn.mydomain.com

...

Это - всё на одном домене и куча поддоменов - очень плохая практика. Сейчас никуда без сертификатов (сплошной HTTPS) и не всегда можно использовать бесплатные амазоновские #ACM сертификаты (когда TLS в самом приложении), в результате один и тот же ключ на *.mydomain.com расползается по куче мест, в том числе девелоперским серверам, а потому обеспечить его безопасность крайне сложно (читай - невозможно).

В то время, как стоимость домена смешная по сравнению с другими расходами - 10-20 долларов в год (т.е. даже дешёвые виртуалки жрут на порядок больше). Потому хорошей практикой является использование отдельного домена (и/или доменов - ни в коем разе не жалея, если нужно!) для внутренних нужд.

Например, в моей многолетней практике на многих проектах для внутренних целей обычно используются домены из зоны *.net (как одни из дешёвых - $11/year) Более современные проекты используют новомодный *.cloud - тоже отличный вариант, который можно рекомендовать ($23/year). Ну а продовские и прочие корпоративные - это *.com, *.org и далее по списку.

Ещё одна ошибка - использовать корпоративные имена просто с разными доменах первого уровня. То есть:

mydomain.com
mydomain.net
mydomain.eu
mydomain.usa

...

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

Однако очень скоро выясняется, что одинаковое написание, отличающееся лишь концовкой вносит страшную путаницу, временами перерастающему в "промахнулся и невтуда задеплоил". Потому, опять же, незачем тут экономить копейки, заведите нормальные "отдельные" домены, т.е. отличающиеся написанием и первого и второго уровня.

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

#best_practices

Правило 80%

Когда-то очень давно в институте я занимался ремонтом телевизоров и всегда носил с собой в маленьком кармане джинсов плоскую мини-отвёртку. А всё потому, что в реальности 80% неисправностей (тогда ещё ЭЛТ) телевизоров решалось просто их настройкой, что делалось с помощью этой отвёртки. Без преувеличения, реальная статистика за многие годы.

Причём тут Амазон?

Это же правило распространяется на него: если вам говорят "у меня что-то не работает на AWS" — в 80% случаев это проблемы с #IAM. То бишь права юзеров, роли, бакет-полиси.

Помните про эти 80% и не начинайте проверку с оставшихся двадцати.

CloudFormation Roadmap

Наконец-то #CloudFormation обзавёлся человеческим роадмэпом:

https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/projects/1

Сделано по аналогии с #roadmap для #ECS:

https://github.com/aws/containers-roadmap/projects/1

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

Официальный пост об этом радостном событии:

https://aws.amazon.com/blogs/aws/aws-cloudformation-update-public-coverage-roadmap-cdk-goodies/

⁠Суровая правда

#пятничное

⁠Ошибка CloudFront - Status Code: 409; Error Code: CNAMEAlreadyExists

Одна из (не)весёлых ситуаций. Вы создаете себе #CloudFront на свой родной тёплый ламповый домен и вдруг #error:

One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution. You must update the DNS record to correct the problem. For more information, see https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: a679d06c-aaee-11e9-8a2d-edaa84658d9b)

Как? Что? Где? Когда??? Кто сидел на моей кровати?!? Мой домен — кто мог создать на него дистрибуцию???

Нервный гуглинг вас приведёт на официальную страницу данной проблемы:

https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/

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

3. After the TXT record is created and you've added an SSL certificate to the distribution, contact AWS Support.

— Што-а-а?!??? У вас косяк, а мне в саппорт?!?

И, кстати, да - это возможно лишь при наличии платной подписки. Занавес.

===

Расслабтесь. В Амазоне не всё работает как должно. Да оно вам и не должно.

Обозначенная проблема имеет простое решение, включать временно платную подписку для обращения в саппорт (да, так можно) не потребуется. Просто создайте дистрибуцию БЕЗ (совсем) CNAME. А после создания добавьте нужный CNAME. Всё - просто в два этапа, а не сразу (как, в принципе, должно и раньше могло работать).

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

#i_love_aws

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