AWS Cloud Practitioner Essentials

Бесплатный курс от AWS для желающих разобраться в многообразии сервисов Amazon.

Материала должно быть достаточно (6 часов видео + полезные ссылки + потыкаться в консоль немного) для подготовки к первому экзамену AWS Cloud Practitioner.

👉 https://amzn.to/3sxmNG9

#aws #exam

Amazon EC2 — 15 лет! 🎉

https://aws.amazon.com/blogs/aws/happy-15th-birthday-amazon-ec2/

#EC2

Программа Amazon Bug Bounty — оплата за найденные уязвимости:

https://hackerone.com/amazonvrp

Недавно повысили расценки до 20 000 $ за самые критические дыры.

Если нашли – добавляйте свой случай. Тот редкий случай, когда не вы платите Амазону, а он вам.

Официальная ссылка:

https://aws.amazon.com/ru/security/vulnerability-reporting/

AWS COMMUNITY CHALLENGE

Вам необходимо придумать оригинальный (самый эффективный или самый быстрый, самый дешевый или самый сложный) способ развертывания WordPress в AWS.
Записать видео с процессом развертывания и показать его миру (и нам). Заявки принимаются до 7 сентября.

Детали участи можно узнать здесь

AWS Backup Audit Manager:

https://aws.amazon.com/ru/blogs/aws/monitor-evaluate-and-demonstrate-backup-compliance-with-aws-backup-audit-manager/

With AWS Backup Audit Manager, you can now continuously and automatically track your backup activity, such as changes to a backup plan or backup vault, and generate automatic daily reports. AWS Backup Audit Manager provides built-in, customizable, compliance controls.

#Backup

Николай Пойда - Live Demo WordPress в AWS
https://youtu.be/WeqRBfNRoqg

​​AWS Graviton2 - миграция на архитектуру ARM в облаке для оптимизации затрат:

https://www.youtube.com/watch?v=OmYsdnSzbvg

Доклад Михаила Голубева, AWS.

Что происходит при вводе урла в строке браузера - версия от AWS:

https://aws.amazon.com/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/

​​Кто виноват и что делать?

Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на 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 (в его подах) нет - всё должно проходить магическим образом. И если это не происходит, то понять почему крайне сложно.

В первой версии эта боль была связана с обязательным тэгированием подсетей (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. Проблема в том, что вы это делаете без уважения слишком быстро, а для отработки всех подкапотных процессов установки AWS Load Balancer Controller требуется 20+ секунд.

В результате, попытавшись задеплоить это сразу же, во время переходных процессов – получаем различные ошибки. В то время, как в следующий раз такого не будет и ошибка воспроизведётся лишь при пересоздании EKS кластера и/или переустановке AWS Load Balancer Controller. Потому такого обычно и не возникает при установке всего вручную. И потому вразумительных ответов в интернете на такие ошибки не найти.

В общем, для установки многих вещей в EKS, "внешних" по отношению к Kubernetes, нужно учитывать время на создание и переходные процессы. Причём это время плавает и может сильно – в зависимости от того, как себя чувствует AWS. Если ему нездоровится, то запросто увеличивается в разы. Потому, если скорость установки критична, потребуется обрабатывать ошибки установки – проверять статус и пробовать повторить установку.

#EKS

Для Serverless/Fullstack разработчика, который работает с AWS, что лучше сдавать — Developer или Solution Architect Assoсiate?

Понятно, что лучше и-и, но если лишь один выбор (например, какой первый), то что?

#опрос

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 #опрос

Использует ли GitHub GitHub для GitHub?

https://twitter.com/nachoiacovino/status/1425121702904836103

Cloud Security Orienteering

Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome такие, как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.

#aws #ops