Open Source replacements for OpenAI Operator:
https://github.com/browser-use/browser-use
https://github.com/browserbase/open-operator
#AI #OpenSource
  
  https://github.com/browser-use/browser-use
https://github.com/browserbase/open-operator
#AI #OpenSource
GitHub
  
  GitHub - browser-use/browser-use: 🌐 Make websites accessible for AI agents. Automate tasks online with ease.
  🌐 Make websites accessible for AI agents. Automate tasks online with ease. - browser-use/browser-use
❤4👍2👀2
  А давайте будем клепать тулы с одинаковыми названиями, чтобы все страдали? А давайте!
Встречайте — Microsoft DocumentDB:
https://github.com/microsoft/documentdb
Microsoft DocumentDB (не путать с Amazon DocumentDB) — это Open Source NoSQL база данных на базе PostgreSQL, которая используется в Azure под капотом Azure Cosmos DB for MongoDB.
В полку конкурентов прибыло и теперь обновлять сравнение MongoDB Atlas vs Amazon DocumentDB:
https://www.mongodb.com/lp/cloud/atlas/compare-mongodb-vs-documentdb
#DocumentDB #NoSQL #MongoDB #Azure
  
  Встречайте — Microsoft DocumentDB:
https://github.com/microsoft/documentdb
Microsoft DocumentDB (не путать с Amazon DocumentDB) — это Open Source NoSQL база данных на базе PostgreSQL, которая используется в Azure под капотом Azure Cosmos DB for MongoDB.
В полку конкурентов прибыло и теперь обновлять сравнение MongoDB Atlas vs Amazon DocumentDB:
https://www.mongodb.com/lp/cloud/atlas/compare-mongodb-vs-documentdb
#DocumentDB #NoSQL #MongoDB #Azure
GitHub
  
  GitHub - documentdb/documentdb at news.itsfoss.com
  MongoDB-compatible database engine for cloud-native and open-source workloads. Built for scalability, performance, and developer productivity. - GitHub - documentdb/documentdb at news.itsfoss.com
🥴14🤷♂6😁2🔥1🙈1
  
  AWS Notes
Как активный пользователь OpenAI, Perplexity + Claude и Google Gemini не могу не поделиться впечатлениями от новой версии китайской модельки от DeepSeek:  https://chat.deepseek.com/  В шоке от скорости и качества. Как для самой последней с reasoning DeepSeek…
Новый понедельник, новая китайския моделька от DeepSeek — Janus Pro 7B для создания картинок:
https://github.com/deepseek-ai/Janus
Janus Pro по бенчмаркам вровень или лучше OpenAI DALL-E 3 и Stable Diffusion. Тоже Open Source, так что можно пользоваться:
https://huggingface.co/deepseek-ai/Janus-Pro-7B
#AI
  
https://github.com/deepseek-ai/Janus
Janus Pro по бенчмаркам вровень или лучше OpenAI DALL-E 3 и Stable Diffusion. Тоже Open Source, так что можно пользоваться:
https://huggingface.co/deepseek-ai/Janus-Pro-7B
#AI
🤣2❤1
  SwiftChat — референс-проект от AWS для создания AI-чата:
https://github.com/aws-samples/swift-chat
React + Bedrock, поддержка Ollama, DeepSeek, OpenAI, Nova.
#Bedrock
  
https://github.com/aws-samples/swift-chat
React + Bedrock, поддержка Ollama, DeepSeek, OpenAI, Nova.
#Bedrock
👍7
  Forwarded from Make. Build. Break. Reflect.
Самая удивительная особенность, которая обнаружилась после перехода RDS(
А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.
Когда был
Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для
Когда переключили на
- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.
Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена
* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.
#AWS #CostOptimization
8.0.mysql_aurora.3.08.0) на Gravitron v2, это способность на высокий утилизации CPU не снижать эффективность/производительность.А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.
Когда был
db.r5.2xlarge, при CPU usage 85-100% длительностью больше 10-15 минут начиналась небольшая, но деградация работы с базой данных.Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для
Debezium+Kafka для реалтайма)Когда переключили на
db.r6g.2xlarge при ровно таких же жёстких нагрузках:- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.
Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена
c5->r6 или же невероятная магия ARM у Gravitron.* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.
#AWS #CostOptimization
🔥18👍6💯3
  DeepSeek-R1-Distill-Llama + Bedrock:
https://github.com/aws-samples/amazon-bedrock-samples/blob/main/custom-models/import_models/llama-3/DeepSeek-R1-Distill-Llama-Noteb.ipynb
#Bedrock
  
  https://github.com/aws-samples/amazon-bedrock-samples/blob/main/custom-models/import_models/llama-3/DeepSeek-R1-Distill-Llama-Noteb.ipynb
#Bedrock
GitHub
  
  amazon-bedrock-samples/custom-models/import_models/llama-3/DeepSeek-R1-Distill-Llama-Noteb.ipynb at main · aws-samples/amazon-bedrock…
  This repository contains examples for customers to get started using the Amazon Bedrock Service. This contains examples for all available foundational models - aws-samples/amazon-bedrock-samples
🔥4👍1
  DeepSeek — что за шум, простыми словами
DeepSeek — китайская компания, выпустившая в конце января Open Source модель DeepSeek-R1:
https://github.com/deepseek-ai/DeepSeek-R1
R1 — это "думающая" (reasoning) модель, прямой конкурент OpenAI o1, условно самой крутой на сегодняшний момент.
Собственно она и наделала столько шуму, потому что показала очень близкие результаты, где-то даже лучше. При этом она Open Source и резко выбивается из общего ряда способом "размышления" и потрясающей скоростью работы. А также ценой, которая в десятки раз меньше текущих на рынке.
При этом месяцем раньше компания выпустила DeepSeek-V3 — прямой конкурент GPT-4o:
https://github.com/deepseek-ai/DeepSeek-V3
Она круче его на голову, но все дружно проигнорили это, т.к. Claude 3.5 Sonnet тоже лучше и все давно привыкли, что тут ничего нового.
К модели R1 прилагается детальный процесс, как она была получена из которого следует, что стоимость обучения модели на порядок меньше, чем у OpenAI сотоварищи.
Как же им это удалось? Если говорить максимально упрощённо, они тупо пропустили самый дорогой и долгий этап проверки результатов работы модели живыми людьми. Берём запрос, генерируем ответ, смотрим, чтобы он был не хуже того, что генерит OpenAI или Claude. Если хуже, переделываем. Всё.
Нет людей, машины учатся у машин.
Можно сравнить с AlphaGo, которая сначал обучалась на партиях профи, а после тренировалась сама с собой методом проб и ошибок.
Ну, а дальше уже подключились политические аспекты противостояния USA-China, что отразилось и на рынке, вызвав резкое снижение акций NVIDIA.
Из некоторых сообщений можно было сделать вывод, что какая-то неизвестная компания с минимальными ресурсами уделала лидеров рынка, что приведёт к крушению AI индустрии вообще и NVIDIA в частности.
Это не так. Любое удешевление технологии приводит к увеличению спроса на железо, а не уменьшению. Все хотят этим воспользоваться, так что DeepSeek это спонсор NVIDIA, просто в будущем.
Касаемо ресурсов, то известно, что материнская компания DeepSeek владеет многими десятками тысяч карт AI ускорителей от NVIDIA, которые при этом запрещено экспортировать в Китай.
Подытожу, DeepSeek получил такую вирусность благодаря тому, что это Open Source. Почему такое эффективное решение сделали сделали Open Source, это уже второй вопрос. И время для этого получилось очень удачное — Lllama 4 ещё не вышла и на сейчас R1 на вершине хайпа.
R1 прямо сейчас уже есть и в AWS, и в Perplexity Pro.
Все спешат его поставить, можно даже поставить и себе локально на компьютер, ведь это Open Source.
Open Source is the way!
#AI #OpenSource #DeepSeek
  
  DeepSeek — китайская компания, выпустившая в конце января Open Source модель DeepSeek-R1:
https://github.com/deepseek-ai/DeepSeek-R1
R1 — это "думающая" (reasoning) модель, прямой конкурент OpenAI o1, условно самой крутой на сегодняшний момент.
Собственно она и наделала столько шуму, потому что показала очень близкие результаты, где-то даже лучше. При этом она Open Source и резко выбивается из общего ряда способом "размышления" и потрясающей скоростью работы. А также ценой, которая в десятки раз меньше текущих на рынке.
При этом месяцем раньше компания выпустила DeepSeek-V3 — прямой конкурент GPT-4o:
https://github.com/deepseek-ai/DeepSeek-V3
Она круче его на голову, но все дружно проигнорили это, т.к. Claude 3.5 Sonnet тоже лучше и все давно привыкли, что тут ничего нового.
К модели R1 прилагается детальный процесс, как она была получена из которого следует, что стоимость обучения модели на порядок меньше, чем у OpenAI сотоварищи.
Как же им это удалось? Если говорить максимально упрощённо, они тупо пропустили самый дорогой и долгий этап проверки результатов работы модели живыми людьми. Берём запрос, генерируем ответ, смотрим, чтобы он был не хуже того, что генерит OpenAI или Claude. Если хуже, переделываем. Всё.
Нет людей, машины учатся у машин.
Можно сравнить с AlphaGo, которая сначал обучалась на партиях профи, а после тренировалась сама с собой методом проб и ошибок.
Ну, а дальше уже подключились политические аспекты противостояния USA-China, что отразилось и на рынке, вызвав резкое снижение акций NVIDIA.
Из некоторых сообщений можно было сделать вывод, что какая-то неизвестная компания с минимальными ресурсами уделала лидеров рынка, что приведёт к крушению AI индустрии вообще и NVIDIA в частности.
Это не так. Любое удешевление технологии приводит к увеличению спроса на железо, а не уменьшению. Все хотят этим воспользоваться, так что DeepSeek это спонсор NVIDIA, просто в будущем.
Касаемо ресурсов, то известно, что материнская компания DeepSeek владеет многими десятками тысяч карт AI ускорителей от NVIDIA, которые при этом запрещено экспортировать в Китай.
Подытожу, DeepSeek получил такую вирусность благодаря тому, что это Open Source. Почему такое эффективное решение сделали сделали Open Source, это уже второй вопрос. И время для этого получилось очень удачное — Lllama 4 ещё не вышла и на сейчас R1 на вершине хайпа.
R1 прямо сейчас уже есть и в AWS, и в Perplexity Pro.
Все спешат его поставить, можно даже поставить и себе локально на компьютер, ведь это Open Source.
Open Source is the way!
#AI #OpenSource #DeepSeek
GitHub
  
  GitHub - deepseek-ai/DeepSeek-R1
  Contribute to deepseek-ai/DeepSeek-R1 development by creating an account on GitHub.
🔥24👍9❤4
  Выбор AWS региона в Европе
В Stockholm
https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-ec2-c8g-instances-aws-europe-stockholm
Теперь в Европе уже целый набор регионов и если у вас проект для EU, то не всегда очевидно, что ж выбрать. Понятно, что если только одна страна и/или требования хранить данные локально, то тут понятно, где нужно, тот и регион. Но если просто EU/UK или вообще Европа? Вот некоторые критерии.
Исторически самый первый регион — Ireland. Многие по привычке считают, что это самый дешёвый и что там больше всего разных типов виртуалок. Уже нет. Для старых ещё актуально, для новых нет.
Самый дешёвый регион (речь про EC2) — Stockholm. Дешевле самого дорогого Frankfurt
Второй по дешевизне (чуть-чуть дешевле Ireland или столько же) и при этом наличии современных типов виртуалок — Spain
Эти четыре региона — Ireland, Frankfurt, Stockholm, Spain рекомендую рассматривать в первую очередь при прочих равных.
#AWS_Regions #EC2 #cost_optimization
  
  В Stockholm
eu-north-1 завезли Graviton 4 C8g инстансы. Как обычно, самые дешёвые в Европе.https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-ec2-c8g-instances-aws-europe-stockholm
Теперь в Европе уже целый набор регионов и если у вас проект для EU, то не всегда очевидно, что ж выбрать. Понятно, что если только одна страна и/или требования хранить данные локально, то тут понятно, где нужно, тот и регион. Но если просто EU/UK или вообще Европа? Вот некоторые критерии.
Исторически самый первый регион — Ireland. Многие по привычке считают, что это самый дешёвый и что там больше всего разных типов виртуалок. Уже нет. Для старых ещё актуально, для новых нет.
Самый дешёвый регион (речь про EC2) — Stockholm. Дешевле самого дорогого Frankfurt
eu-central-1 на 10-15%. Однако несмотря на цену, Frankfurt очень важный (особенно по части сети и локальных зон) и, скажем так, "передовой" регион, куда и сервисы завозят быстрее и виртуалки новые.Второй по дешевизне (чуть-чуть дешевле Ireland или столько же) и при этом наличии современных типов виртуалок — Spain
eu-south-2.Эти четыре региона — Ireland, Frankfurt, Stockholm, Spain рекомендую рассматривать в первую очередь при прочих равных.
#AWS_Regions #EC2 #cost_optimization
Amazon
  
  Amazon EC2 C8g instances now available in AWS Europe (Stockholm) - AWS
  Discover more about what's new at AWS with Amazon EC2 C8g instances now available in AWS Europe (Stockholm)
👍31🔥8❤1
  Стыд и скрам:
https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak
#security
  
  Within minutes, we found a publicly accessible ClickHouse database linked to DeepSeek, completely open and unauthenticated, exposing sensitive data. It was hosted at oauth2callback.deepseek.com:9000 and dev.deepseek.com:9000.
https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak
#security
wiz.io
  
  Wiz Research Uncovers Exposed DeepSeek Database Leaking Sensitive Information, Including Chat History | Wiz Blog
  A publicly accessible database belonging to DeepSeek allowed full control over database operations, including the ability to access internal data. The exposure includes over a million lines of log streams with highly sensitive information.
🤡24🤣2😱1🗿1
  Forwarded from Ant
r8g RDS PG полет прекрасный. r6g>r7g было улучшение, теперь такое же улучшение r7g>r8g
  Знаю, что устали, но нужно ж закрыть гештальт:
https://aws.amazon.com/blogs/aws/deepseek-r1-models-now-available-on-aws/
#Bedrock #Sagemaker #DeepSeek
  
  https://aws.amazon.com/blogs/aws/deepseek-r1-models-now-available-on-aws/
#Bedrock #Sagemaker #DeepSeek
Amazon
  
  DeepSeek-R1 models now available on AWS | Amazon Web Services
  DeepSeek-R1, a powerful large language model featuring reinforcement learning and chain-of-thought capabilities, is now available for deployment via Amazon Bedrock and Amazon SageMaker AI, enabling users to build and scale their generative AI applications…
😁14
  
  AWS Notes
🆕 Kube Resource Orchestrator (kro)  https://kro.run  🔸Single ResourceGroup for multiple resources 🔹Resource dependencies 🔹Configuration management 🔹Controller deployment 🔹Lifecycle management  AWS Blog:  https://aws.amazon.com/blogs/opensource/introducing…
kro выиграл. Helm всё. Они договорились.https://cloud.google.com/blog/products/containers-kubernetes/introducing-kube-resource-orchestrator
GCP, AWS и Azure поставили на
kro:https://github.com/kro-run/kro
#Kubernetes #kro #OpenSource
Google Cloud Blog
  
  Introducing Kube Resource Orchestrator, or kro | Google Cloud Blog
  Google worked with AWS, and Azure on kro, a Kubernetes-native, cloud-agnostic way to define groupings of Kubernetes resources.
👎18🤔1💩1
  Работает — не трогай.
Авторство: AI от https://lovable.dev/ (самый быстрорастущий AI-стартап от авторов gpt-engineer).
Source.
#AI #пятничное
😁11🤣3😱1
  Forwarded from Make. Build. Break. Reflect.
Есть база данных AWS RDS(
К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.
Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".
Большее обсервабилити, большая детализация. Больше SRE👏 
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
Мне показался туповатым.
❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.
- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
- создаем новые rds proxy endpoint для каждого из приложений/юзера
- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения
Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.
Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.
Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.
#AWS #observability #cloudwatch
8.0.mysql_aurora.3.08.0) + RDS Proxy.К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.
Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".
Большее обсервабилити, большая детализация. Больше SRE
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
SELECT usename, count(*)
FROM pg_stat_activity
GROUP BY usename;
Мне показался туповатым.
❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.
- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
resource "aws_db_proxy" "this" {
...
  auth {
    auth_scheme               = "SECRETS"
    iam_auth                  = "DISABLED"
    client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
    secret_arn                = aws_secretsmanager_secret.user1_credentials.arn
  }
  auth {
    auth_scheme               = "SECRETS"
    iam_auth                  = "DISABLED"
    client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
    secret_arn                = aws_secretsmanager_secret.user2_credentials.arn
  }
...
}- создаем новые rds proxy endpoint для каждого из приложений/юзера
resource "aws_db_proxy_endpoint" "this" {
...
  db_proxy_endpoint_name = "${var.project}-${var.environment}-user1"
  target_role            = "READ_WRITE"
...
}resource "aws_db_proxy_endpoint" "this" {
...
  db_proxy_endpoint_name = "${var.project}-${var.environment}-user2"
  target_role            = "READ_WRITE"
...
}- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения
Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
- ClientConnections
- DatabaseConnections
- AvailableConnectionPercent
- ConnectionAttempts
- QueryRequests
- QueryRequestsPerSec
Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.
Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.
Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.
#AWS #observability #cloudwatch
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍26❤2
  Preventing Data Leaks in RAG Pipelines with Bedrock
🔹 Securing the RAG Ingestion Pipeline
https://aws.amazon.com/blogs/security/securing-the-rag-ingestion-pipeline-filtering-mechanisms/
🔹 Hardening the RAG Chatbot Architecture
https://aws.amazon.com/blogs/security/hardening-the-rag-chatbot-architecture-powered-by-amazon-bedrock-blueprint-for-secure-design-and-anti-pattern-migration/
🔹 Building Secure and Scalable RAG Applications with Bedrock
https://aws.amazon.com/blogs/machine-learning/building-scalable-secure-and-reliable-rag-applications-using-amazon-bedrock-knowledge-bases/
#Bedrock #security
  
  🔹 Securing the RAG Ingestion Pipeline
https://aws.amazon.com/blogs/security/securing-the-rag-ingestion-pipeline-filtering-mechanisms/
🔹 Hardening the RAG Chatbot Architecture
https://aws.amazon.com/blogs/security/hardening-the-rag-chatbot-architecture-powered-by-amazon-bedrock-blueprint-for-secure-design-and-anti-pattern-migration/
🔹 Building Secure and Scalable RAG Applications with Bedrock
https://aws.amazon.com/blogs/machine-learning/building-scalable-secure-and-reliable-rag-applications-using-amazon-bedrock-knowledge-bases/
#Bedrock #security
Amazon
  
  Securing the RAG ingestion pipeline: Filtering mechanisms | Amazon Web Services
  Retrieval-Augmented Generative (RAG) applications enhance the responses retrieved from large language models (LLMs) by integrating external data such as downloaded files, web scrapings, and user-contributed data pools. This integration improves the models’…
👍3
  
  AWS Notes
But the prices are totally inadequate.
Too slow, but OK.
https://aws.amazon.com/about-aws/whats-new/2025/02/amazon-guardduty-malware-protection-s3-price-reduction/
$0.60 → $0.09 per GB
#GuardDuty
  
  https://aws.amazon.com/about-aws/whats-new/2025/02/amazon-guardduty-malware-protection-s3-price-reduction/
$0.60 → $0.09 per GB
#GuardDuty
Amazon
  
  Amazon GuardDuty Malware Protection for S3 announces price reduction - AWS
  Discover more about what's new at AWS with Amazon GuardDuty Malware Protection for S3 announces price reduction
👍1