AWS Graviton2 - миграция на архитектуру ARM в облаке для оптимизации затрат:
https://www.youtube.com/watch?v=OmYsdnSzbvg
Доклад Михаила Голубева, AWS.
https://www.youtube.com/watch?v=OmYsdnSzbvg
Доклад Михаила Голубева, AWS.
Forwarded from Nikolay
Amazon
Join us for AWS Storage Day 2021 – the 3rd annual AWS Storage Day | Amazon Web Services
Thursday, September 2, 2021, 8:30 AM – 3:00 PM PT | 11:30 AM – 6:00 PM ET Register and join us on September 2, 2021 for the 3rd annual and completely free-to-attend AWS Storage Day! Last year’s Storage Day was filled with big announcements, and this year…
Что происходит при вводе урла в строке браузера - версия от AWS:
https://aws.amazon.com/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/
https://aws.amazon.com/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/
Amazon
What happens when you type a URL into your browser? | Amazon Web Services
This article was written by Jenna Pederson. Every day you open up your browser and navigate to your favorite websites — whether it be social media, news, or e-commerce sites. You go to this page by typing in a url or clicking on a link to the page. Have you…
Кто виноват и что делать?
Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на AWS.
Когда возникает проблема доступа и вы получаете отлуп access denied от IAM, то проблема может быть результатом запрета доступа на любой из стадий с картинки (куда ещё нужно мысленно добавить политики S3 buckets и VPC endpoints).
И нет способа однозначно понять, кто же заблочил доступ, нужно держать в голове все варианты, итерационно перебирать, от того, что прописано в IAM до того, что доступно лишь админу на уровне Organizations - запрета от SCP.
Но теперь выход есть, то есть будет очень скоро!
https://aws.amazon.com/blogs/security/aws-introduces-changes-to-access-denied-errors-for-easier-permissions-troubleshooting/
Мы, наконец, сможем получать конкретный отчёт — что же стало результатом IAM
🔹 SCP
🔹 Resource-based policies (S3 buckets, ECR, ES etc)
🔹 IAM permissions boundaries
🔹 Session policies
🔹 IAM policies
🔹 VPC endpoint policies
Очень круто, это огромное облегчение для дебага проблем доступа. Так долго ждал этого, как говорится, не прошло и десять лет! (а вот и нет - прошло 😄)
В общем, ждём сентября.
#IAM #SCP #debug
Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на AWS.
Когда возникает проблема доступа и вы получаете отлуп access denied от IAM, то проблема может быть результатом запрета доступа на любой из стадий с картинки (куда ещё нужно мысленно добавить политики S3 buckets и VPC endpoints).
И нет способа однозначно понять, кто же заблочил доступ, нужно держать в голове все варианты, итерационно перебирать, от того, что прописано в IAM до того, что доступно лишь админу на уровне Organizations - запрета от SCP.
Но теперь выход есть, то есть будет очень скоро!
https://aws.amazon.com/blogs/security/aws-introduces-changes-to-access-denied-errors-for-easier-permissions-troubleshooting/
Мы, наконец, сможем получать конкретный отчёт — что же стало результатом IAM
access denied, в первой версии это будут следующие варианты: 🔹 SCP
🔹 Resource-based policies (S3 buckets, ECR, ES etc)
🔹 IAM permissions boundaries
🔹 Session policies
🔹 IAM policies
🔹 VPC endpoint policies
Очень круто, это огромное облегчение для дебага проблем доступа. Так долго ждал этого, как говорится, не прошло и десять лет! (а вот и нет - прошло 😄)
В общем, ждём сентября.
#IAM #SCP #debug
Миграция на AWS Load Balancer Controller v2
Первую версию, которая была лишь для ALB и потому называлась AWS ALB Ingress Controller v1, задеприкейтили в конце 2020-го года, потому рекомендуется переходить на вторую версию. Уже пора, да. 😀
Переход, в принципе, хорошо описан у @setevoy4:
https://rtfm.co.ua/aws-migraciya-aws-alb-ingress-controller-v1-na-aws-load-balancer-controller-v2/
Добавлю лишь описание некоторых подводных камней, т.к. дебажить AWS Load Balancer Controller всегда проблема из-за того, что логов на стороне EKS (в его подах) нет - всё должно проходить магическим образом. И если это не происходит, то понять почему крайне сложно.
В первой версии эта боль была связана с обязательным тэгированием подсетей (
https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/1773
Другая проблема - изменившиеся (по сравнению с первой версией) IAM permissions, необходимые для работы. В документации везде лишь чистый JSON и его применение из командной строки. Если нужен готовые IAM policy для CloudFormation шаблона, то можно скопировать отсюда:
https://github.com/applerom/cloudformation-examples/blob/master/eks/eks-with-aws-load-balancer-controller-v2.yml#L179-L342
Ну, и третья, возможно для кого-то самая большая боль. Сложнодетектируемая проблема, когда сам AWS Load Balancer Controller ставится без проблем, но при создании Ingress с его аннотациями получаем странную ошибку типа:
Она может происходить непериодическим (однократным) образом, чем особенно ставит в тупик.
Искать смысл в сообщении бессмысленно, исследовать CloudTrail в попытках понять, почему в какой-то момент времени не срабатывает
Дело в том, что у вас всё правильно. 😀 Вы наверняка используете IaС и CI/CD, который автоматически ставит AWS Load Balancer Controller (например, через Helm чарт) и после создаёт Ingress. Проблема в том, что вы это делаетебез уважения слишком быстро, а для отработки всех подкапотных процессов установки AWS Load Balancer Controller требуется 20+ секунд.
В результате, попытавшись задеплоить это сразу же, во время переходных процессов – получаем различные ошибки. В то время, как в следующий раз такого не будет и ошибка воспроизведётся лишь при пересоздании EKS кластера и/или переустановке AWS Load Balancer Controller. Потому такого обычно и не возникает при установке всего вручную. И потому вразумительных ответов в интернете на такие ошибки не найти.
В общем, для установки многих вещей в EKS, "внешних" по отношению к Kubernetes, нужно учитывать время на создание и переходные процессы. Причём это время плавает и может сильно – в зависимости от того, как себя чувствует AWS. Если ему нездоровится, то запросто увеличивается в разы. Потому, если скорость установки критична, потребуется обрабатывать ошибки установки – проверять статус и пробовать повторить установку.
#EKS
Первую версию, которая была лишь для ALB и потому называлась AWS ALB Ingress Controller v1, задеприкейтили в конце 2020-го года, потому рекомендуется переходить на вторую версию. Уже пора, да. 😀
Переход, в принципе, хорошо описан у @setevoy4:
https://rtfm.co.ua/aws-migraciya-aws-alb-ingress-controller-v1-na-aws-load-balancer-controller-v2/
Добавлю лишь описание некоторых подводных камней, т.к. дебажить AWS Load Balancer Controller всегда проблема из-за того, что логов на стороне EKS (в его подах) нет - всё должно проходить магическим образом. И если это не происходит, то понять почему крайне сложно.
В первой версии эта боль была связана с обязательным тэгированием подсетей (
role/internal-elb, kubernetes.io/role/elb), во второй версии (начиная с 2.1.2) это делать не нужно (не обязательно): https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/1773
Другая проблема - изменившиеся (по сравнению с первой версией) IAM permissions, необходимые для работы. В документации везде лишь чистый JSON и его применение из командной строки. Если нужен готовые IAM policy для CloudFormation шаблона, то можно скопировать отсюда:
https://github.com/applerom/cloudformation-examples/blob/master/eks/eks-with-aws-load-balancer-controller-v2.yml#L179-L342
Ну, и третья, возможно для кого-то самая большая боль. Сложнодетектируемая проблема, когда сам AWS Load Balancer Controller ставится без проблем, но при создании Ingress с его аннотациями получаем странную ошибку типа:
Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s": no endpoints available for service "aws-load-balancer-webhook-service"Она может происходить непериодическим (однократным) образом, чем особенно ставит в тупик.
Искать смысл в сообщении бессмысленно, исследовать CloudTrail в попытках понять, почему в какой-то момент времени не срабатывает
kms:CreateGrant для aws:elasticloadbalancing тоже незачем (не поможет).Дело в том, что у вас всё правильно. 😀 Вы наверняка используете IaС и CI/CD, который автоматически ставит AWS Load Balancer Controller (например, через Helm чарт) и после создаёт Ingress. Проблема в том, что вы это делаете
В результате, попытавшись задеплоить это сразу же, во время переходных процессов – получаем различные ошибки. В то время, как в следующий раз такого не будет и ошибка воспроизведётся лишь при пересоздании EKS кластера и/или переустановке AWS Load Balancer Controller. Потому такого обычно и не возникает при установке всего вручную. И потому вразумительных ответов в интернете на такие ошибки не найти.
В общем, для установки многих вещей в EKS, "внешних" по отношению к Kubernetes, нужно учитывать время на создание и переходные процессы. Причём это время плавает и может сильно – в зависимости от того, как себя чувствует AWS. Если ему нездоровится, то запросто увеличивается в разы. Потому, если скорость установки критична, потребуется обрабатывать ошибки установки – проверять статус и пробовать повторить установку.
#EKS
RTFM: Linux, DevOps и системное администрирование | DevOps-инжиниринг и системное администрирование. Случаи из практики.
AWS: миграция AWS ALB Ingress Controller (v1) на AWS Load Balancer Controller (v2)
Миграция AWS ALB Ingress Controller (v1) на AWS Load Balancer Controller (v2) - IAM-политики, ServiceAccount, Ansible, Helm и автоматизация.
Для Serverless/Fullstack разработчика, который работает с AWS, что лучше сдавать — Developer или Solution Architect Assoсiate?
Понятно, что лучше и-и, но если лишь один выбор (например, какой первый), то что?
#опрос
Понятно, что лучше и-и, но если лишь один выбор (например, какой первый), то что?
#опрос
Самые важные AWS сервисы, которые нужно знать Serverless/Fullstack-разработчику.
(можно выбрать несколько вариантов)
#опрос
(можно выбрать несколько вариантов)
#опрос
Anonymous Poll
16%
Aurora Serverless
56%
API Gateway
34%
DynamoDB
16%
EventBridge
66%
Lambda
53%
S3
31%
SNS
43%
SQS
1%
Другой (более важный, чем какой-то из восьми выше)
27%
Посмотреть результаты
Важные AWS сервисы, которые нужно знать Serverless/Fullstack-разработчику (вторая восьмёрка).
(можно выбрать несколько вариантов)
#опрос
(можно выбрать несколько вариантов)
#опрос
Anonymous Poll
17%
Amplify
10%
AppSync
40%
CloudFront
20%
Fargate
46%
IAM
9%
RDS Proxy
7%
SAR (Serverless Application Repository)
32%
Step Functions
0%
Другой (более важный, чем какой-то из первой и второй восьмёрки выше)
33%
Посмотреть результаты
AWS сервисы, которые желательно знать Serverless/Fullstack-разработчику (третья восьмёрка).
(можно выбрать несколько вариантов)
#опрос
(можно выбрать несколько вариантов)
#опрос
Anonymous Poll
9%
Cloud9
47%
CloudWatch
31%
Cognito
27%
EC2
19%
RDS
40%
Route53
24%
VPC
19%
X-Ray
0%
Другой (более важный, чем какой-то из всех выше)
32%
Посмотреть результаты
Top 20 AWS services for Serverless/Fullstack Development
С вашей помощью получился следующий список AWS сервисов, который Serverless/Fullstack-разработчику обязательно нужно знать / стоит знать / можно рекомендовать для изучения (по убыванию важности):
1️⃣ Lambda
2️⃣ API Gateway
3️⃣ S3
4️⃣ SQS
5️⃣ DynamoDB
6️⃣ SNS
7️⃣ IAM
8️⃣ CloudFront
9️⃣ Step Functions
🔟 CloudWatch
11. Route53
12. EventBridge
13. Aurora Serverless
14. Fargate
15. Amplify
16. AppSync
17. RDS Proxy
18. Cognito
19. EC2
20. VPC
p.s. Ранее было аналогичное для бэкенда и фронта.
#top #serverless #fullstack #опрос
С вашей помощью получился следующий список AWS сервисов, который Serverless/Fullstack-разработчику обязательно нужно знать / стоит знать / можно рекомендовать для изучения (по убыванию важности):
1️⃣ Lambda
2️⃣ API Gateway
3️⃣ S3
4️⃣ SQS
5️⃣ DynamoDB
6️⃣ SNS
7️⃣ IAM
8️⃣ CloudFront
9️⃣ Step Functions
🔟 CloudWatch
11. Route53
12. EventBridge
13. Aurora Serverless
14. Fargate
15. Amplify
16. AppSync
17. RDS Proxy
18. Cognito
19. EC2
20. VPC
p.s. Ранее было аналогичное для бэкенда и фронта.
#top #serverless #fullstack #опрос
Telegram
aws_notes
Самые важные AWS сервисы, которые нужно знать Serverless/Fullstack-разработчику.
(можно выбрать несколько вариантов)
#опрос
Aurora Serverless / API Gateway / DynamoDB / EventBridge / Lambda / S3 / SNS / SQS / Другой (более важный, чем какой-то из восьми…
(можно выбрать несколько вариантов)
#опрос
Aurora Serverless / API Gateway / DynamoDB / EventBridge / Lambda / S3 / SNS / SQS / Другой (более важный, чем какой-то из восьми…
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Cloud Security Orienteering
Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome такие, как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.
#aws #ops
Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome такие, как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.
#aws #ops
tl;dr sec
Cloud Security Orienteering
How to orienteer in a cloud environment, dig in to identify the risks that matter, and put together actionable plans that address short, medium, and long term goals.
Практикум по AWS CDK — 31 Августа 19.00 МСК
1. Что такое AWS CDK, сравнение с другими решениями IaaS
2. Особенности AWS CDK
3. Пример развертывания инфраструктуры
https://rebrainme.com/webinars/devops-rebrain-and-luxoft-ep-3/
Вебинар проведёт Антон Коваленко - Lead cloud solutions architect, Luxoft.
1. Что такое AWS CDK, сравнение с другими решениями IaaS
2. Особенности AWS CDK
3. Пример развертывания инфраструктуры
https://rebrainme.com/webinars/devops-rebrain-and-luxoft-ep-3/
Вебинар проведёт Антон Коваленко - Lead cloud solutions architect, Luxoft.
Открытый практикум DevOps by REBRAIN
Вебинары by REBRAIN
DevOps, Kubernetes, Docker, обучение DevOps, корпоративное обучение DevOps, обучение Kubernetes, обучение Docker, корпоративное обучение Docker, корпоративное обучение Kubernetes
Forwarded from RV
Terminology change - AWS KMS is replacing the term customer master key (CMK) with AWS KMS key and KMS key. The concept has not changed. To prevent breaking changes, AWS KMS is keeping some variations of this term. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
Forwarded from Anton Arhipov
День добрый. AWS анонсировали альфу для Kotlin SDK. Если тут найдутся потенциальные пользователи, будем рады обратной связи. Спасибо.
https://aws.amazon.com/blogs/developer/aws-sdk-for-kotlin-alpha-release/
https://aws.amazon.com/blogs/developer/aws-sdk-for-kotlin-alpha-release/
Amazon
Announcing new AWS SDK for Kotlin alpha release | Amazon Web Services
We’re excited to announce the alpha release of the new AWS SDK for Kotlin! Kotlin is one of the most-loved languages amongst developers and now the AWS SDK for Kotlin makes it easy to call AWS services using idiomatic Kotlin APIs. You can use the native Kotlin…
Безоткатный режим CloudFormation --disable-rollback:
https://aws.amazon.com/blogs/aws/new-for-aws-cloudformation-quickly-retry-stack-operations-from-the-point-of-failure/
Дождались, однако. Очень нужная фича, критическая для многих ситуаций.
На картинке видно, что если выбрать безоткатный режим, то созданные до ошибки ресурсы не удаляются (зелёные) и можно поробовать исправить ситуацию - поменять шаблон (или параметры в нём) и повторить апдейт либо же откатить по обычной схеме.
#CloudFormation
https://aws.amazon.com/blogs/aws/new-for-aws-cloudformation-quickly-retry-stack-operations-from-the-point-of-failure/
CloudFormation allows you to disable the automatic rollback, keep the resources successfully created or updated before the error occurs, and retry stack operations from the point of failure. In this way, you can quickly iterate to fix and remediate errors and greatly reduce the time required to test a CloudFormation template in a development environment.Дождались, однако. Очень нужная фича, критическая для многих ситуаций.
На картинке видно, что если выбрать безоткатный режим, то созданные до ошибки ресурсы не удаляются (зелёные) и можно поробовать исправить ситуацию - поменять шаблон (или параметры в нём) и повторить апдейт либо же откатить по обычной схеме.
#CloudFormation
День знаний AWS
Знаниями нужно делиться. Делюсь своими знаниями про источники знаний по AWS в Telegram.
⚠️ Далее список из моей ленты, каналы, которые постоянно сам читаю. Не реклама (с авторами оных не согласовывал — надеюсь, они не против😀). Кроме AWS, в списке в основном по devops тематике.
Обозначение:
🔥 - активные и маст хэв каналы/чаты для того, чтобы следить за AWS (и просто хорошие)
🇺🇦 - на украинском языке (или в том числе)
Каналы по AWS:
@aws_notes 🔥
@aws_history
@awscommunitybuilders
@aws_ua_notes 🇺🇦
@yaawschannel
@fluffy_clouds_aws
Ленты по AWS:
@awsfeed
@aws_doc_update
Чаты по AWS:
@aws_ru 🔥
@aws_minsk 🔥
@aws_kz 🔥
@awsNSK
@aws_notes_chat 🔥
@awsamplify
@aws_ua 🇺🇦
@aws_friday
Викторины по AWS:
@awsec
@cloudandcybersecurity
Боты по AWS:
@Awstatus_bot
Каналы, где много пишут в том числе по AWS:
@devopsengineer
@devopslibrary 🔥
@devops_talks
@SysadminNotes
@sysadmin_tools 🔥
@bykvaadm
@count0_digest
@kazarin_online 🔥
@tech_b0lt_Genona 🔥
@sec_devops 🔥
@DevOops
@catops 🔥
@devopsminsk
@manandthemachine 🔥
@oleg_log 🔥
Чаты, где часто обсуждают AWS:
@devops_ru 🔥
@catops_chat 🔥 🇺🇦
@terraform_ru 🔥
@CNCFMinskChat
@DevOpsMinskChat
Просто хорошие каналы (где не так часто, но бывают посты по AWS):
@webapparch 🔥
@dataplace
@devops4ua
@response418
@deep_thought_aas
@monitorim_it
@CloudTechRU
@RoToRoCloud
@devops_deflope
Если знаете каналы/чаты/боты/итп, которых нет в списке выше и которые пишут/обсуждают темы AWS - поделитесь, пожалуйста, своими знаниями в комментариях!
#AWS #devops
Знаниями нужно делиться. Делюсь своими знаниями про источники знаний по AWS в Telegram.
⚠️ Далее список из моей ленты, каналы, которые постоянно сам читаю. Не реклама (с авторами оных не согласовывал — надеюсь, они не против😀). Кроме AWS, в списке в основном по devops тематике.
Обозначение:
🔥 - активные и маст хэв каналы/чаты для того, чтобы следить за AWS (и просто хорошие)
🇺🇦 - на украинском языке (или в том числе)
Каналы по AWS:
@aws_notes 🔥
@aws_history
@awscommunitybuilders
@aws_ua_notes 🇺🇦
@yaawschannel
@fluffy_clouds_aws
Ленты по AWS:
@awsfeed
@aws_doc_update
Чаты по AWS:
@aws_ru 🔥
@aws_minsk 🔥
@aws_kz 🔥
@awsNSK
@aws_notes_chat 🔥
@awsamplify
@aws_ua 🇺🇦
@aws_friday
Викторины по AWS:
@awsec
@cloudandcybersecurity
Боты по AWS:
@Awstatus_bot
Каналы, где много пишут в том числе по AWS:
@devopsengineer
@devopslibrary 🔥
@devops_talks
@SysadminNotes
@sysadmin_tools 🔥
@bykvaadm
@count0_digest
@kazarin_online 🔥
@tech_b0lt_Genona 🔥
@sec_devops 🔥
@DevOops
@catops 🔥
@devopsminsk
@manandthemachine 🔥
@oleg_log 🔥
Чаты, где часто обсуждают AWS:
@devops_ru 🔥
@catops_chat 🔥 🇺🇦
@terraform_ru 🔥
@CNCFMinskChat
@DevOpsMinskChat
Просто хорошие каналы (где не так часто, но бывают посты по AWS):
@webapparch 🔥
@dataplace
@devops4ua
@response418
@deep_thought_aas
@monitorim_it
@CloudTechRU
@RoToRoCloud
@devops_deflope
Если знаете каналы/чаты/боты/итп, которых нет в списке выше и которые пишут/обсуждают темы AWS - поделитесь, пожалуйста, своими знаниями в комментариях!
#AWS #devops
S3 Intelligent-Tiering — отмена ограничений для маленьких файлов (меньше 128КБ) и минимального срока хранения 30 дней:
https://aws.amazon.com/blogs/aws/amazon-s3-intelligent-tiering-further-automating-cost-savings-for-short-lived-and-small-objects/
Полезное изменение, которое делает S3 Intelligent-Tiering существенно более эффективным, т.к. снимает одну из самых популярных причин, что часто делало просто невыгодным его использование.
#S3
https://aws.amazon.com/blogs/aws/amazon-s3-intelligent-tiering-further-automating-cost-savings-for-short-lived-and-small-objects/
To date, S3 Intelligent-Tiering was intended for objects larger than 128 KB stored for a minimum of 30 days. As of today, monitoring and automation charges will no longer be collected for objects smaller than 128 KB — this includes both new and already existing objects in the S3 Intelligent-Tiering storage class. Additionally, objects deleted, transitioned, or overwritten within 30 days will no longer accrue prorated charges.Полезное изменение, которое делает S3 Intelligent-Tiering существенно более эффективным, т.к. снимает одну из самых популярных причин, что часто делало просто невыгодным его использование.
#S3
Amazon
Amazon S3 Intelligent-Tiering – Improved Cost Optimizations for Short-Lived and Small Objects | Amazon Web Services
In 2018, we first launched Amazon S3 Intelligent-Tiering (S3 Intelligent-Tiering). For customers managing data across business units, teams, and products, unpredictable access patterns are often the norm. With the S3 Intelligent-Tiering storage class, S3…