Kafka Connect для Amazon MSK = MSK Connect:

https://aws.amazon.com/blogs/aws/introducing-amazon-msk-connect-stream-data-to-and-from-your-apache-kafka-clusters-using-managed-connectors/

MSK Connect allows you to configure and deploy a connector using Kafka Connect with a just few clicks. MSK Connect provisions the required resources and sets up the cluster. It continuously monitors the health and delivery state of connectors, patches and manages the underlying hardware, and auto-scales connectors to match changes in throughput. As a result, you can focus your resources on building applications rather than managing infrastructure.
MSK Connect is fully compatible with Kafka Connect, which means you can migrate your existing connectors without code changes. You don’t need an MSK cluster to use MSK Connect. It supports Amazon MSK, Apache Kafka, and Apache Kafka compatible clusters as sources and sinks. These clusters can be self-managed or managed by AWS partners and 3rd parties as long as MSK Connect can privately connect to the clusters.

#MSK

​​Управление инцидентами с помощью SSM Incident Manager:

https://aws.amazon.com/blogs/security/how-to-automate-incident-response-to-security-events-with-aws-systems-manager-incident-manager/

In this post, I showed you how to use Incident Manager to monitor for security events and invoke a response plan via Amazon CloudWatch or Amazon EventBridge. AWS CloudTrail API activity (for a root account login), Amazon GuardDuty (for high severity findings), and AWS Config (to enforce policies like preventing public write access to an S3 bucket). I demonstrated how you can create an incident management and response plan to ensure you have used the power of cloud to create automations that respond to and mitigate security incidents in a timely manner.

#SSM #security

Параллелизация в Лямбде:

https://medium.com/@harrisaaron/multithreading-in-lambda-youll-need-to-use-this-much-memory-1ad7d257fbb3

#Lambda

Кому не хватает опросов, то здесь можно проголосовать за то, что важно на AWS для DevOps-инженеров.

​​Открытая база данных IAM политик:

https://permissions.cloud/

The permissions.cloud website uses a variety of information gathered within the IAM Dataset and exposes that information in a clean, easy-to-read format. It was built in order to provide an alternate, community-driven source of truth for AWS identity.

#IAM #security

AWS Authentication: Principals in AWS IAM

https://ben11kehoe.medium.com/principals-in-aws-iam-38c4a3dc322a

Лучшее, что читал по IAM аутентификции (да простит меня Карен), крайне рекомендую — ноль воды, чистые и современные (что важно) знания.

Сложно, но кратко и только по делу. Да и IAM — это, к сожалению, не про просто по определению. В закладки без вариантов.

#IAM

Как объединить сеть проектов в Azure и AWS с помощью managed решения:

https://techcommunity.microsoft.com/t5/fasttrack-for-azure/how-to-create-a-vpn-between-azure-and-aws-using-only-managed/ba-p/2281900

Отличная штука, чтобы не плодить свои костыли для соединения в общую сеть — полностью managed решение на базе сервисов Azure VPN Gateway и AWS Virtual Private Gateway. Особенно круто, что аналогично можно подключить и к AWS Transit Gateway.

#Azure #VPC

Вебинар по AWS Global Accelerator от Юрия Якубова, Solution Architect, AWS:

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

#Global_Accelerator

Более официальные модули terraform для AWS.
Судя по описанию:

Terraform modules on AWS were developed by HashiCorp Inc. in partnership with AWS. HashiCorp is an AWS Partner.

AWS docs:
https://aws.amazon.com/quickstart/architecture/terraform-modules-on-aws/

Terraform namespace:
https://registry.terraform.io/namespaces/aws-ia

GitHub:
https://github.com/aws-ia

37 способов запустить контейнеры на AWS

💥новинка💥 17 способов от Corey Quinn:

https://www.lastweekinaws.com/blog/17-more-ways-to-run-containers-on-aws/

И 20 способов, что здесь были перечислены раньше.

Короче, разобраться, что выбрать при таком многообразии, действительно сложно, особенно новичкам.

Рекомендация👉 В общем случае, если не знакомы с EKS/ECS/Fargate, проще использовать App Runner.

Официальный документ от производителя «Docker on AWS»:

https://d1.awsstatic.com/whitepapers/docker-on-aws.pdf

#containers

Выборочная репликация ECR репозиториев:

https://aws.amazon.com/blogs/containers/using-amazon-ecr-replication-rules-to-optimize-your-application-delivery-process/

Репликация ECR появилась ещё год назад, но была малоприменима, т.к. можно было реплицировать лишь сразу все репозитории в регионе оптом.

И вот теперь, наконец, её можно реально использовать — можно выбирать не только отдельный репозиторий, но и задать маску для билдов, которые будут реплицироваться!

В общем, реально востребованная вещь, многие костыли и велосипеды для различных Disaster Recovery сценариев можно будет выбросить.

#ECR

​​Новый AWS регион в 2024-м году — Окленд, Новая Зеландия:

https://aws.amazon.com/ru/blogs/aws/in-the-works-aws-region-in-new-zealand/

#AWS_Regions

​​В новых иконках от AWS добавили AWS Account:

https://aws.amazon.com/architecture/icons/

#Organizations #design

Если у вас есть лишние пять миллиардов долларов, то можно заказать себе AWS Region:

https://anz-resources.awscloud.com/new-aws-region-in-aotearoa-new-zealand/aws-investment-in-new-zealand-aws-economic-impact-study

Примерно во столько обойдётся по данной отчётности (в переводе с новозеландских) свежеобъявленный AWS регион в Новой Зеландии.

#AWS_Regions

​​К – качество.

#пятничное

«You Build It, You Run It» vs «Девопс-инженер – суровая правда жизни»

Умные люди здесь жарко дискутировали на сотню комментариев, что же правильней-реальней.

▪️ Точка зрения 1. DevOps — это (отдельный) человек (девопс-инженер или несколько, команда, несколько команд), который занимается CI/CD процессом.

▪️ Точка зрения 2. DevOps — это подход «You Build It, You Run It».

Кроме этого, конечно, к обоим можно добавить, что это культура, набор лучших практик и так далее.

Однако главный вопрос: девопс — это отдельные специально обученный человек (люди), который(-е) "делают девопс" или же при таком подходе это лишнее звено. А в "правильном варианте" практики девопса воплощают разные члены команды, в первую очередь сами разработчики (кто разрабатывает, тот же деплоит, обновляет, мониторит и так далее).

Я (категорически) придерживаюсь варианта «You Build It, You Run It», понимая, что в «обычном случае» это не так. Однако считаю, что нужно добавить "пока" плюс, опять же, всегда правильно помнить и напоминать, как оно должно быть.

Поделитесь, пожалуйста, своим взглядом на эту проблему («You Build It, You Run It — this is real DevOps») в комментариях.

⁉️ Опрос «DevOps — это (отдельный) человек (люди)» vs «You Build It, You Run It».

#devops

​​Статья про то, как автор пытался получить список удалённых секретов, однако полезна описанием работы AWS SDK:

https://alexwlchan.net/2021/07/listing-deleted-secrets/#how-the-language-specific-aws-sdks-work

How the language-specific AWS SDKs work
At time of writing, AWS has nine language-specific SDKs which have to support over 200 different services. Each SDK contains a client for each service, and the methods on those clients mirror the underlying HTTP APIs. It would be impractical to maintain those clients by hand – so they don’t.
Instead, AWS publish “service models” that describe each service. These models are JSON files that contain a complete description of the endpoints, the models, the documentation text, and so on. These models are used to autogenerate the service-specific clients in the SDKs, reducing the effort required to keep everything up-to-date. This approach has also allowed other people to write SDKs in languages that AWS don’t support, like Haskell and Clojure.

#SDK #Secrets #Python