⁠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/

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

#пятничное

⁠Ошибка 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