⁠Сертификаты-требования-стандарты — 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 #пятничное

Интересно наблюдать, как количество #нужны_поднобности сначала увеличивается, а потом уменьшается (увеличивая #интересно). Как говорится - человек "догнал".

Для тех, кому всё-таки подробности нужны - следующая идея для стартапа.

Берёте сервер заказчика, переименовываете его в #serverless. После рапортуете о внедрении модной технологии на проекте, а для потверждения скидываете скриншот. Профит.

Универсальная таблица оценки задач

изян - 1ч
изи - 2ч
просто - 4ч
вроде просто - 6ч
норм - 8ч
норм так - 12ч
хз - 16ч
хз как-то - 20ч
как-то сложно - 24ч
сложно - 30ч
очень сложно - 40ч
бля - 48ч
пиздец - 60ч
пиздец какой-то - 80ч
вроде изян - 100ч

первоисточник

#agile #субботничное

[​​](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