Lambda Cost-Saving
Хорошая статья о реальном случае урезания костов проекта, активно использующего #Lambda:
https://medium.com/foxintelligence-inside/how-we-reduced-lambda-functions-costs-by-thousands-of-dollars-8279b0a69931
#cost_saving
Хорошая статья о реальном случае урезания костов проекта, активно использующего #Lambda:
https://medium.com/foxintelligence-inside/how-we-reduced-lambda-functions-costs-by-thousands-of-dollars-8279b0a69931
#cost_saving
Medium
How We Reduced Lambda Functions Costs by Thousands of Dollars
Serverless Computing or FaaS is the best way to consume cloud computing. In this model, the responsibility for provisioning, maintaining…
Дефолтные настройки создания RDS для Prod/Dev/Test
Информация больше для начинающих, но всё же.
Если вам дали задание создать #RDS инстанс для какого-то окружения и вы поднимаете для своего дохлого сайтика с полутора пользователями агрегат размером в db.r5.xlarge — скажу дипломатично, это не очень разумно.
Разберу популярные доводы (реальные кейсы) вышеописанного поведения.
«Так ведь там было написано» — на заборе тоже написано, а там дрова.
«У нас важный сайт, как бы чего не вышло» — совсем не повод выбирать Production-вариант из списка, особенно при этом чисто для тестов — это перебор капслоком в цикле. Равно как и выбор предлагаемого для Dev/Test даже если вам тействительно это нужно для Dev/Test.
В общем случае для Dev/Test почти всегда стоит начинать (да и заканчивать) вариантом типа db.t3.small. Вы же всегда сможете после (речь не о проде, хотя и для него тоже) изменить мощность RDS-инстанса. Пожалейте здравый смысл — звание почётного спонсора Амазона не даёт никаких привилегий.
«Ну там же рекомендуются эти значения - не будет же Амазон советовать плохого!» — Граждане, скажу коротко - не читайте советских газет!
Информация больше для начинающих, но всё же.
Если вам дали задание создать #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.
Если вы и есть тот самый знакомый, который пилит свои сайты, то вышеописанный способ отлично подойдёт для сайтов ваших конкурентов — пущай бдят и не расслабляются!
#пятничное
Если у вас есть знакомые, которые сами пилят какие-то свои сайты и занимаются сеошным продвижением, а значит постоянно мониторят его статистику, то можно пройти по следующей ссылочке:
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
https://github.com/awslabs/git-secrets
Амазоновская утилитка проверит коммиты на наличие различных секретов.
https://github.com/Yelp/detect-secrets
Более продвинутая вещь с широким функционалом и плагинами.
https://pre-commit.com/
Ещё более навороченный фреймворк с поддержкой различных языков.
#security
GitHub
GitHub - awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories
Prevents you from committing secrets and credentials into git repositories - awslabs/git-secrets
Доступ к бакету для всех аккаунтов организации
Бывает нужно быстро и просто расшарить какой-то бакет или его часть для всех, но не "для всех вообще", т.е. в интернете, а только "для своих всех".
В случае #multi_account_strategy данная задача преобразуется в "расшарить для всех аккаунтов организации". Для этого существует специальная опция PrincipalOrgID, которую и можно использовать:
Это неидеальное решение с точки зрения безопасности, но точно лучше варианта сделать бакет публичным.
#s3 #organization
Бывает нужно быстро и просто расшарить какой-то бакет или его часть для всех, но не "для всех вообще", т.е. в интернете, а только "для своих всех".
В случае #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 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
Граждане из 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
Ищем подходящую жертву:
Для любителей блюскринов (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
Amazon
Send a diagnostic interrupt (for advanced users) - Amazon Elastic Compute Cloud
You can send a diagnostic interrupt to an unreachable or unresponsive Linux instance to manually trigger a kernel panic .
Хакеры в помощь
Бывает что-то пошло не так и нужно срочно найти созданное когда-то где-то кем-то окружение на неизвестно какой поддомен, вы не в зуб ногой, а на дворе пятница стынет. Понятно, что нужно было записывать, но что делать сейчас?
Тогда вспоминаем, что у хакеров, в отличие от вас, все ходы записаны. Идём на совершенно бесплатный сайтик:
https://dnsdumpster.com/
Вбиваем свой домен и смотрим, что они там о нас знают.
Совет - желательно, чтобы никто из руководства не стоял за спиной, а то вполне возможно, что от увиденных ваших достижений в области безопасности придётся прятаться или даже бежать.
База построена на данных сервиса https://scans.io/ - да, это те, которые постоянно гадят в лог любого сервиса любой вашей виртуалки.
В любом случае очень полезно знать, что знают про вас — каждый день, каждый открытый порт. А вы и не знали, что забыли закрыть-удалить-обновить-пропатчить.
Так что теперь точно уж стоит это сделать. Нет, не сейчас, конечно - в понедельник, понятно. Сразу после того, как бросите курить, пойдёте в качалку и, наконец, запишетесь на курсы английского.
#пятничное #security
===
Добавлено (из комментариев в личку):
Если вы не курите, ходите в качалку и на английский, то значит без шансов — в понедельник.
Бывает что-то пошло не так и нужно срочно найти созданное когда-то где-то кем-то окружение на неизвестно какой поддомен, вы не в зуб ногой, а на дворе пятница стынет. Понятно, что нужно было записывать, но что делать сейчас?
Тогда вспоминаем, что у хакеров, в отличие от вас, все ходы записаны. Идём на совершенно бесплатный сайтик:
https://dnsdumpster.com/
Вбиваем свой домен и смотрим, что они там о нас знают.
Совет - желательно, чтобы никто из руководства не стоял за спиной, а то вполне возможно, что от увиденных ваших достижений в области безопасности придётся прятаться или даже бежать.
База построена на данных сервиса https://scans.io/ - да, это те, которые постоянно гадят в лог любого сервиса любой вашей виртуалки.
В любом случае очень полезно знать, что знают про вас — каждый день, каждый открытый порт. А вы и не знали, что забыли закрыть-удалить-обновить-пропатчить.
Так что теперь точно уж стоит это сделать. Нет, не сейчас, конечно - в понедельник, понятно. Сразу после того, как бросите курить, пойдёте в качалку и, наконец, запишетесь на курсы английского.
#пятничное #security
===
Добавлено (из комментариев в личку):
Если вы не курите, ходите в качалку и на английский, то значит без шансов — в понедельник.
DNSDumpster.com
DNSDumpster - Find & lookup dns records for recon & research
Free domain research tool to discover hosts related to a domain. Find visible hosts from the attackers perspective for Red and Blue Teams.
Как добавить свою фичу в 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 — умеют и должны.
#время_пошло
Предпочитающим #CloudFormation кроме спокойствия и выдержки в ожидании добавления уже имеющегося в консоли, также посоветую следующий способ поделиться с амазонозаводчиками собственными чаяниями.
Помните (или знайте), в Амазоне несколько есть глобальных долгоиграющих трендов.
1. "Тэгизация" всего — к любому ресурсу должна быть возможность добавить тэги. Это нужно для детального учёта стоимости, а также для tag-based схемы работы с #IAM.
2. "Параметризация" всего - максимальная интеграция сервисов Secrets Manager и SSM Parameter Store для возможности использования своих переменных оттуда.
Потому, если не вам хватает чего-то из этих областей - смело пишите, оно наверняка будет реализовано (т.к. "в тренде"). Например, вот пару дней назад поданный запрос (хороший пример, как это оформлять):
https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/126
Запрос попадает в п.2 трендов, потому, думаю, не пройдёт и полгода, как такая фича появится. Засекаем время и ждём. А ждать, как много раз говорилось, все, кто использует CloudFormation — умеют и должны.
#время_пошло
GitHub
AWS::CodePipeline::Webhook - Secret Token as a non-string · Issue #126 · aws-cloudformation/aws-cloudformation-coverage-roadmap
Add non-string options for AWS::CodePipeline::Webhook-WebhookAuthConfiguration-Secret Token Quick Sample Summary: Title -> AWS::CodePipeline::Webhook-WebhookAuthConfiguration-Secret Token Sc...
AWS и доброта
Если вы случайно запустили какую-то вещь на Амазоне, которая сожрала *censored* сколько денег, то перед тем как пойти напиться и гуглить прайс на продажу органов, знайте про следующий лайфхак.
Откройте тикет в техподдержке (того аккаунта, где это было) и опишите ситуацию — что-когда-где было сделано, что в результате запустилось, какая ошибка, почему зациклилось и что вам не нужно было загружать миллион раз один и тот же файл. Можно добавить, что предпринято, дабы такого не произошло в будущем (зуб даю, мамой клянусь и типа того, только по-английски).
С большой долей вероятности вашу просьбу удовлетворят и через некоторое время в биллинге вы узрите человеческую цифру. А значит можно будет использовать вашу печень по прямому назначению — ведь сегодня пятница.
#доброта_спасёт_мир
Если вы случайно запустили какую-то вещь на Амазоне, которая сожрала *censored* сколько денег, то перед тем как пойти напиться и гуглить прайс на продажу органов, знайте про следующий лайфхак.
Откройте тикет в техподдержке (того аккаунта, где это было) и опишите ситуацию — что-когда-где было сделано, что в результате запустилось, какая ошибка, почему зациклилось и что вам не нужно было загружать миллион раз один и тот же файл. Можно добавить, что предпринято, дабы такого не произошло в будущем (зуб даю, мамой клянусь и типа того, только по-английски).
С большой долей вероятности вашу просьбу удовлетворят и через некоторое время в биллинге вы узрите человеческую цифру. А значит можно будет использовать вашу печень по прямому назначению — ведь сегодня пятница.
#доброта_спасёт_мир
Сustom CNAME для CloudFront со своим сертификатом
Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был environment. Порождённый богом CloudFormation он рос здоровым, занимался спортом, не курил, пользовался секретами и регулярно бэкапился. И всё у него было хорошо.
Но пришло лето и сказал царь - а давайте обновим вон того в углу, полгода не трогали, скукотища и, вообще, что-то давно мы уже два дня как не страдали. И достал дед Вопс свой пайплайн, и закинул его в бакет. Тянет-потянет - и вытянул чудо эдакое неведомое:
Чешет темя дед — как же ж так, то ж зимой ещё работало, а теперича уже нет.
Полез дед в интернет, а там Амазон ему и говорит человеческим голосом:
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
#сказка
Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был 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
#сказка
Amazon
Amazon CloudFront enhances the security for adding alternate domain names to a distribution
🔥1
SSM Session Manager + Port Forwarding
Очередной последний гвоздь в крышку Bastion схемы работы - теперь можно через SSM прокидывать на локальный комп нужный порт.
Потестируем. Как обычно, для всех новых фич обычно требуется последние версии всего. Смотрим версию #aws_cli:
aws --version
Для порт-форвардинга требуется 1.16.220 и новей, так что обновляем.
aws --version
Теперь 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"]}'
portNumber - это порт на инстансе, который будет форвардиться на наш локальный порт на компе localPortNumber.
Открываем в браузере 127.0.0.1:8080 и видим локально у себя локальное на удалённом инстансе. Либо доступ к базе, какому-то сервису - в общем, любому порту.
Поигравшись жмём CTRL-C и (с некоторым лагом) сессия оборовётся.
Итого - отличная штука, бесплатная (только за трафик) - точно стоит освоить и пользоваться.
#ssm #session_manager
Очередной последний гвоздь в крышку 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
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
Несмотря на то, что Амазоном я напрямую занимаюсь с 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
Amazon
AWS Certification exam preparation
Learn how to prepare for your AWS Certification exam. Find recommended resources for specific exams, including free digital training, classroom training, and exam readiness training from experts at AWS.
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.
Второй вариант вполне работоспособен на сегодня. Если бакет не в регионе
Кстати, такое поведение (редирект) "под капотом" может давать хитрые ошибки для свежесозданных бакетов. Это когда вы всё делаете через CloudFormation. В таком случае из-за того, что информация о редиректе созданного в другом регионе бакета обновляется не сразу (а окружение через CloudFormation может подняться/обновиться быстро), то вы получаете ошибку 307 — т.к. редирект уже есть, а записи куда редиректится ещё нет. Через некоторое время (до получаса) всё отработает как надо, но паника может наступить раньше очистки кэша.
3.
Третий вариант ранее работал наравне со вторым. Однако теперь это уже не так. В случае работы с новым регионом
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
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
Amazon
Use various origins with CloudFront distributions - Amazon CloudFront
You can use various different origins with Amazon CloudFront, including Amazon S3 buckets, Elastic Load Balancing load balancers, MediaStore containers, MediaPackage channels, and Amazon EC2 instances.
Хорошая картинка по всем базам данным и не только. Можно наглядно и быстро соотнести сервисы Амазона с другими решениями с классификацией по типу.
Первоисточник.
#info
Первоисточник.
#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 ещё не поддерживал
С приходом всеобщего докера, два-три года назад этот способ работы был захоронен и всё благополучно переехало в ECS. А нонче (не)благополучно мигрирует в EKS, т.к. куберы на текущий момент суть самый что ни на есть тру девопс-вэй.
И вот тут я читаю отзывы сдавших девопс-профи экзамен и узнаю, что мне придётся доставать из-под кровати запылившиеся кукбуки и ехать на дачу откапывать бинстолки.
Вы это серьёзно, да? Это по версии AWS экзаменаторов есть современный профи-девопс? То есть вот совсем без AWS Code-сервисов, без ECS, EKS и Лямбд???
В общем, мы с Амазоном тут не договоримся. Возможно для тех, кто работает в суровом энтерпрайзе и где вот это вот всё сплошняком, что нужно тянуть ещё десятилетиями, продолжая не доверять докеру, ибо хипстерный, в то время, как есть
Предположу, жавшие «DevOps Engineer - Professional» не знали (как и я до этого), что в результате им придётся здесь читать про Chef и что в ElasticBeanstalk спустя два года так и не завезли Amazon Linux 2 (в качестве основного образа используется только первый - фу два раза, Амазон). Что ж, теперь знаете (и можно пойти переголосовать).
Solutions Architect - Associate
Короче, я обожду, когда в Амазоне завяжут с курением, а пока перехожу к девопсу здорового человека, второму пункту: «Solutions Architect - Associate». Краем глаза глянул - вроде вопросы вменяемые и темы адекватные. Значит будем готовиться.
п.с. В поисках ссылок по использованию вышеозвученного, случайно обнаружил вот такую статью. Старая, но про войну (зачёркнуто) BeanStalk (снова зачёркнуто) девопс.
https://habr.com/ru/post/329840/
#AWS_Certification
Популярность вариантов сертификации 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
https://aws.amazon.com/getting-started/projects/break-monolith-app-microservices-ecs-docker-ec2/
#design
Amazon
Break a Monolith Application into Microservices | Introduction
In this tutorial, you will deploy a monolithic Node.js application to a Docker container, then decouple the application into microservices without any downtime. The Node.js application hosts a simple message board with threads and messages between users.
Вам достался монолит, который нужно развернуть на AWS EC2. Монолит имеет встроенную MongoDB, которой по документации на чтение требуется random I/O более 250 000
Какой из вариантов вы выберете?
#AWS_Certification #training
4КБ IOPS.Какой из вариантов вы выберете?
#AWS_Certification #training