⁠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 #пятничное

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

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

Берёте сервер заказчика, переименовываете его в #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/

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

#пятничное