AWS Notes

​​Безоткатный режим CloudFormation --disable-rollback: 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 анонсировали альфу для Kotlin SDK. Если тут найдутся потенциальные пользователи, будем рады обратной связи. Спасибо. https://aws.amazon.com/blogs/developer/aws-sdk-for-kotlin-alpha-release/

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

Практикум по 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.

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

Использует ли GitHub GitHub для GitHub? https://twitter.com/nachoiacovino/status/1425121702904836103

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

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

Миграция на 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

​​Кто виноват и что делать? Наверняка все знают эту картинку (внизу поста). Кто не знает, обязательно стоит изучить, т.к. это база для понимания как работает доступ на 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: https://aws.amazon.com/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/

​​AWS Graviton2 - миграция на архитектуру ARM в облаке для оптимизации затрат: https://www.youtube.com/watch?v=OmYsdnSzbvg Доклад Михаила Голубева, AWS.

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