Filtrar por género

AWS на русском

AWS на русском

Viktor Vedmich

Подкаст ”AWS на русском”. Говорим про использование облачных технологий, построение serverless приложений, развертывание kubernetes и внедрение ML/AI и не только. Лучшие практики и свежие новости из мира AWS в формате интервью на русском языке. Смотрите и слушайте #awsнарусском

72 - 072. Безопасность MCP: кто выдал агенту токен
0:00 / 0:00
1x
  • 72 - 072. Безопасность MCP: кто выдал агенту токен

    Одна из самых частых ошибок с MCP: один токен на всех агентов, без срока жизни и без проверок на бэкенде. По сути это admin-доступ, выданный модели, которая может ошибиться или выполнить чужую инструкцию. В новом выпуске подкаста «AWS на русском» говорим с Виолой Лыковой (AWS Community Builder) о безопасности MCP-серверов и AI-агентов: 🔹 Почему MCP из слоя интеграции превращается в новую границу доступа, как только агент начинает вызывать тулы🔹 Токены и scopes: отдельный ключ на каждого агента, TTL, почему токен не должен попадать в промпт🔹 RBAC для агентов: у каждого свой ID, audit trail и цепочка approval (кто сделал, кто одобрил, когда)🔹 Least privilege без wildcard, авторизация на уровне каждого тула, destructive actions только через human-in-the-loop🔹 Prompt injection и tool poisoning: почему description тула уже часть поведения агента 💡 RBAC теперь нужен не только людям, но и агентам: у каждого агента свой ID, а в логах видно, какой агент что сделал, кто это одобрил (человек или другой агент) и когда. 💬 Как вы ограничиваете агентов у себя: отдельные токены, allow-list тулов или пока YOLO-режим? #MCP #AIAgents #AISecurity #AWS #Подкаст #AWSнаРусском Ссылки из выпускаСтатья Виолы про безопасность MCP-тулов на AWS: https://dev.to/aws-builders/how-to-secure-mcp-tools-on-aws-for-ai-agents-with-authentication-authorization-and-least-privilege-50eaMCP Authorization (спецификация): https://modelcontextprotocol.io/specification/2025-11-25/basic/authorizationMCP Security Best Practices: https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practicesTool Poisoning Attacks (Invariant Labs): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacksAmazon Bedrock Guardrails: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-content-filters.html Навигация (Podbean)(0:00) Введение: тысячи MCP-серверов(2:07) Что такое MCP и откуда вопрос security(4:27) Кого ограничивать: MCP-сервер или агента(7:02) Токены: отдельный ключ на клиента, TTL(11:33) RBAC для агентов: сервисный аккаунт как в Kubernetes(14:25) Remote MCP: Streamable HTTP и lifecycle(18:25) Почему токен не должен попасть в промпт(19:02) mcp.json, GitHub scopes и 401 для агента(23:47) Кастомная авторизация: где начинается боль(25:06) Больше чем RBAC: бэкенд и OAuth 2.1(29:40) Guardrails в Bedrock против guardrails на бэкенде(32:32) Identity агента и audit trail(34:18) Prompt injection через фронтенд к базе(39:03) Чек-лист для своего MCP-сервера(40:12) Проверка агентов в CI/CD перед деплоем(44:10) Отдельные scopes: analysis-агент и ops-агент(45:38) Blast radius и авторизация на уровне тула(47:20) Least privilege без wildcard(49:01) Destructive actions и human-in-the-loop(53:33) Prompt injection через источники, tool poisoning(55:30) Tool description как часть поведения агента(56:51) Итоги: без YOLO, детерминированные guardrails Навигация (YouTube)00:00:00 – Введение: тысячи MCP-серверов00:02:07 – Что такое MCP и откуда вопрос security00:04:27 – Кого ограничивать: MCP-сервер или агента00:07:02 – Токены: отдельный ключ на клиента, TTL00:11:33 – RBAC для агентов: сервисный аккаунт как в Kubernetes00:14:25 – Remote MCP: Streamable HTTP и lifecycle00:18:25 – Почему токен не должен попасть в промпт00:19:02 – mcp.json, GitHub scopes и 401 для агента00:23:47 – Кастомная авторизация: где начинается боль00:25:06 – Больше чем RBAC: бэкенд и OAuth 2.100:29:40 – Guardrails в Bedrock против guardrails на бэкенде00:32:32 – Identity агента и audit trail00:34:18 – Prompt injection через фронтенд к базе00:39:03 – Чек-лист для своего MCP-сервера00:40:12 – Проверка агентов в CI/CD перед деплоем00:44:10 – Отдельные scopes: analysis-агент и ops-агент00:45:38 – Blast radius и авторизация на уровне тула00:47:20 – Least privilege без wildcard00:49:01 – Destructive actions и human-in-the-loop00:53:33 – Prompt injection через источники, tool poisoning00:55:30 – Tool description как часть поведения агента00:56:51 – Итоги: без YOLO, детермин

    Wed, 30 Sep 2026
  • 71 - 071. AI-DLC часть 1: от vibe-кодинга -> spec-driven к AI-DLC

    Миф: чем мощнее модель, тем меньше нужен процесс. Реальность: у vibe-кодинга есть «стеклянный потолок» - момент, после которого агент скорее портит код, чем помогает. У опытных разработчиков он наступает в первый час. В новом выпуске подкаста «AWS на русском» говорим с Михаилом Ишениным и Антоном Коваленко (Solutions Architects, AWS) про AI-DLC: методологию и фреймворк, которые переосмысливают жизненный цикл разработки под агентов. 🔹 Почему vibe-кодинг и spec-driven ускоряют одну фазу из семи, а на реальном спринте упираются в потолок оба, просто с разной скоростью🔹 AI-assisted против AI-managed: AI не просто пишет код, а сам ведёт процесс, собирает нужный контекст и валидирует его на каждом шаге🔹 Детерминированный оркестратор: движок на TypeScript без единой LLM не даёт перепрыгнуть стадию. В фреймворке был ключ --test-run, и модели нашли его сами, чтобы скипать обязательные шаги. Ключ убрали🔹 Knowledge и persistent memory: трейс от строки кода до бизнес-требования, ADR для агентов, дистилляция tribal knowledge из твоих правок🔹 Legacy и brownfield: reverse engineering старых репозиториев, причём сканируется минимальный нужный скоуп, а не всё подряд🔹 Три оси настройки - скоуп, глубина, стратегия тестирования: багфикс запускает 7-8 стадий из 32, enterprise-задача все. Это ручка стоимости и длительности прогона Будет полезно тимлидам и техлидам, которые упёрлись в потолок vibe-кодинга; архитекторам и продактам, которым нужен процесс, а не ещё одна тулза; инженерам на больших легаси-базах. Это первая часть. До фаз Inception, Construction и Operations не дошли - разберём их во второй. 💡 Сначала команда замедляется - ровно как при внедрении DevOps: вылезает всё, что было сломано в процессе, и это надо починить. И главное правило: don't steer your agents, feed your agents. Не рули агентом в реальном времени, а вкладывай в него контекст и фидбек, чтобы следующий прогон был лучше. 🎧 Доступно на любимой платформе:• YouTube, Podbean, Apple Podcasts, Яндекс Музыка, Spotify, RSS (ссылки ниже) 💬 А вы уже упирались в стеклянный потолок с агентами? На какой задаче он у вас наступает? #AIDLC #SpecDriven #AgenticAI #SDLC #AWS #Подкаст #AWSнаРусском Навигация (Podbean)(0:00) Введение и знакомство с гостями(1:29) От перфокарт до агентских инструментов(3:29) Vibe-кодинг: под какие задачи годится(5:08) Spec-driven: requirements, дизайн, задачи(8:04) Стеклянный потолок и почему spec-driven недостаточно(10:20) AI-assisted против AI-managed(11:29) Семь фаз SDLC и про какую все забывают(17:12) Компоненты AI-DLC: 5 фаз и 32 стадии(18:51) Детерминированный оркестратор и как модели читят(21:08) Knowledge: трейс от кода до требования(22:47) Persistent memory и tribal knowledge(25:09) Агенты как персоны и self-review(27:57) Работает ли на легаси: reverse engineering(29:25) Как начать: установка и поддерживаемые инструменты(31:04) Фаза инициализации(32:44) Три оси: скоуп, глубина, тестирование и цена прогона(38:01) Фаза Ideation: greenfield против brownfield(41:41) А сами-то используете? Frontier teams в Amazon(44:57) Итоги и AI-DLC как воркшоп Навигация (YouTube)00:00:00 – Введение и знакомство с гостями00:01:29 – От перфокарт до агентских инструментов00:03:29 – Vibe-кодинг: под какие задачи годится00:05:08 – Spec-driven: requirements, дизайн, задачи00:08:04 – Стеклянный потолок и почему spec-driven недостаточно00:10:20 – AI-assisted против AI-managed00:11:29 – Семь фаз SDLC и про какую все забывают00:17:12 – Компоненты AI-DLC: 5 фаз и 32 стадии00:18:51 – Детерминированный оркестратор и как модели читят00:21:08 – Knowledge: трейс от кода до требования00:22:47 – Persistent memory и tribal knowledge00:25:09 – Агенты как персоны и self-review00:27:57 – Работает ли на легаси: reverse engineering00:29:25 – Как начать: установка и поддерживаемые инструменты00:31:04 – Фаза инициализации00:32:44 – Три оси: скоуп, глубина, тестирование и цена прогона00:38:01 – Фаза Ideation: greenfield против brownfield00:41:41 – А сами-то используете? Frontier teams в

    Thu, 30 Jul 2026
  • 70 - 070. Pavel Veller - оставаться hands-on: от инженера до Chief Technologist

    Паша Веллер 20 лет рос в EPAM от инженера до Chief Technologist - и всё это время писал код руками.  В новом выпуске подкаста «AWS на русском» говорим с Пашей Веллером (Chief Technologist / VP AI, PandaDoc) и Вадимом Войтюком (Principal SA, AWS) про путь инженер → CTO → продукт → AI и как остаться hands-on: 🔹 Почему CTO должен продолжать пачкать руки в коде: перестал делать руками - быстро перестал быть адекватным технологом, которому клиент верит🔹 Три качества, которые двигают карьеру: инициатива, умение принимать решения и ответственность за них. Одно английское слово вбирает всё - agency🔹 Сервис против продукта как две кривые: consultancy - синусоида стресса (аврал → спад → аврал), продукт - прямая линия чуть ниже пиков (давление постоянное, но стабильное)🔹 AI в документообороте PandaDoc: 60 млн документов в год, а контракт не может быть правильным на 97% - нужно 100%. Вот где «AI пишет легко» заканчивается и начинается инженерия Будет полезно инженерам, которые растут в тимлидов и техлидов и боятся «потерять руки»; архитекторам; всем, кто адаптируется к AI-разработке и выбирает между сервисной и продуктовой карьерой. 💡 Раздели рабочий день на две части: полдня - митинги и коммуникация, полдня - работа руками в фокусе. Быть занятым легко, этого от тебя все хотят. Вопрос в другом: ты сегодня был занят или принёс пользу? 🎧 Доступно на любимой платформе:• YouTube, Podbean, Apple Podcasts, Яндекс Музыка, Spotify, RSS (ссылки ниже) 💬 Оставаться hands-on любой ценой или в какой-то момент честно отпустить код и уйти в стратегию? Где вы на этой кривой? #Career #EngineeringLeadership #AICoding #CTO #AWS #Подкаст #AWSнаРусском Навигация (Podbean)(0:00) Начало и представление гостей(1:25) Кто такой Паша Веллер: Минск → EPAM → США, 26 лет опыта(2:52) Может ли CTO оставаться hands-on и зачем(4:20) Доверие клиента строится через техническую глубину(6:13) Три качества роста: инициатива, решения, ответственность (agency)(11:49) Сервис vs продукт: для инженера и для лидера(14:45) Метафора двух кривых: синусоида против прямой линии(16:32) Тактика против стратегии: почему в продукте иначе(18:22) Выход из зоны комфорта(19:09) Есть ли в продукте «волны» под релизы (re:Invent)?(20:44) PandaDoc: vertical SaaS, continuous deployment, feature flags(23:37) Продакт-инженер и плотность таланта: 200 vs 60 000 человек(27:46) Почему инженеры меняют продукт на сервис и обратно(29:46) Что строит в PandaDoc: VP AI и внедрение AI в продукт(34:16) AI в документообороте: 87-97% против нужных 100%(37:46) Как решают точность: инженерное решение и evals(39:24) «Навайбкодить PandaDoc за вечер»? 60 млн документов в год(42:34) Типичный день Chief Technologist: день на две части(46:58) Maker vs manager schedule (Пол Грэм)(48:19) Быть занятым против приносить пользу (value)(50:44) «Перестал писать код руками в октябре»: жизнь после Sonnet 4.5(53:45) Когнитивная нагрузка: писать легче, читать сложнее(55:10) Кому больно терять ручной код и почему(58:40) Финал: один практический совет инженеру(1:02:59) Индустрии с высокой ценой ошибки (Starlink, медтех)(1:05:30) Итоги и прощание Навигация (YouTube)00:00:00 - Начало и представление гостей00:01:25 - Кто такой Паша Веллер: Минск → EPAM → США, 26 лет опыта00:02:52 - Может ли CTO оставаться hands-on и зачем00:04:20 - Доверие клиента строится через техническую глубину00:06:13 - Три качества роста: инициатива, решения, ответственность (agency)00:11:49 - Сервис vs продукт: для инженера и для лидера00:14:45 - Метафора двух кривых: синусоида против прямой линии00:16:32 - Тактика против стратегии: почему в продукте иначе00:18:22 - Выход из зоны комфорта00:19:09 - Есть ли в продукте «волны» под релизы (re:Invent)?00:20:44 - PandaDoc: vertical SaaS, continuous deployment, feature flags00:23:37 - Продакт-инженер и плотность таланта: 200 vs 60 000 человек00:27:46 - Почему инженеры меняют продукт на сервис и обратно00:29:46 - Что строит в PandaDoc: VP AI и внедрение AI в продукт00:34:16 - AI в документообороте: 87-97% против

    Thu, 23 Jul 2026
  • 69 - 069. AWS DevOps Agent: от реакции на инциденты до ревью кода

    Вы уже написали своего DevOps-агента в Kiro или Claude Code. И ещё тысяча ваших коллег - каждый своего, на 80% одинакового. Зачем тогда AWS выпустил готового frontier-агента? В новом выпуске подкаста «AWS на русском» разбираем AWS DevOps Agent с Фёдором Павловым и Антоном Коваленко: 🔹 Зачем готовый агент, если есть Kiro и Claude Code: у тысяч клиентов одни и те же болячки (observability, incident response), а возню с доступами, scope и хостингом («держать палец между крышкой ноута и клавиатурой») берёт на себя AWS🔹 Из чего он собран: space = IAM-роль (например, read-only на prod) + capabilities (логи, метрики, трейсы, GitHub/GitLab, кастомные MCP). Топология вашей инфраструктуры как «факт» против Terraform-«плана»🔹 Incident response и root cause: агент коррелирует данные из всех источников, выдаёт RCA и mitigation-план по шагам (validate → backup → change → validate → rollback)🔹 Proactive prevention: агент копит опыт как инженер, делает weekly refine и даёт рекомендации по 4 направлениям (observability, infrastructure, governance, code) - сразу с готовой спекой для фикса🔹 Ops → Dev: биллинг по секундам, триаж сотен алертов в одну первопричину, авто-создание support-тикета, а на Summit в Нью-Йорке (preview) - Release Readiness Review и Autonomous Release Testing Будет полезно DevOps/SRE, платформенным и backend-инженерам и архитекторам на AWS, а также всем, кто уже строит агентов в Kiro/Claude Code и думает, где выгоднее готовый frontier-агент. 💡 Доступ к CloudWatch даст и локальный Kiro. Уникальное у готового агента - накопленная история расследований и tribal knowledge: то, что инженеры проговорили у кофе-машины во время инцидента и чего нет ни в Confluence, ни в коде. 🎧 Доступно на любимой платформе:• YouTube, Podbean, Apple Podcasts, Яндекс Музыка, Spotify, RSS (ссылки ниже) 💬 Вы бы доверили managed frontier-агенту prod на запись или держали бы только read-only? Как разграничиваете доступы? #DevOpsAgent #AIAgents #SRE #IncidentResponse #AWS #Подкаст #AWSнаРусском Навигация (Podbean)(0:00) Introduction(0:24) Гости: Фёдор Павлов и Антон Коваленко(1:36) Что такое агент(2:26) Зачем готовый агент, если есть Kiro и Claude Code(4:39) Свой мониторинг против готового решения(7:39) Пример Kiro: spec-driven development и неизменяемый дизайн(10:11) Из чего состоит DevOps Agent: space и IAM-роль(11:25) Capabilities: логи, метрики, трейсы, Git(12:50) Что такое расследование и root cause(14:41) Доступ к инфраструктуре и топология(16:09) План против факта: Terraform и реальность(18:25) Как команда делает RCA вручную(19:41) RCA и mitigation-план по шагам с rollback(22:30) Proactive prevention: агент копит опыт(25:02) 4 типа рекомендаций и готовая спека для фикса(27:39) Что можно менять: скиллы, MCP, системный промпт(30:12) Sub-агенты: специализированный фокус(32:53) Токены и деньги: биллинг по секундам(33:43) Enterprise Support: кредиты на агента(34:22) Проблема на стороне AWS: авто-создание support-тикета(37:02) Триаж: сотни алертов и blast radius(40:49) Talk to your infrastructure(42:31) Tribal knowledge, которого нет в Confluence(43:54) Ops закрыли, а что с Dev?(45:23) Summit NY: Release Readiness Review и Autonomous Release Testing (preview)(48:13) Shift-left и quality gates(50:14) SDLC и тизер эпизода про AI DLC(51:44) Итоги и анонс Навигация (YouTube)00:00:00 - Начало00:00:24 - Гости: Фёдор Павлов и Антон Коваленко00:01:36 - Что такое агент00:02:26 - Зачем готовый агент, если есть Kiro и Claude Code00:04:39 - Свой мониторинг против готового решения00:07:39 - Пример Kiro: spec-driven development00:10:11 - Из чего состоит DevOps Agent: space и IAM-роль00:11:25 - Capabilities: логи, метрики, трейсы, Git00:12:50 - Что такое расследование и root cause00:14:41 - Доступ к инфраструктуре и топология00:16:09 - План против факта: Terraform и реальность00:18:25 - Как команда делает RCA вручную00:19:41 - RCA и mitigation-план по шагам с rollback00:22:30 - Proactive prevention: агент копит опыт00:25:02 - 4 типа рекомендаций и готовая с

    Thu, 09 Jul 2026
  • 68 - 068. Redis → Valkey в inDrive: история миграции 500 кластеров

    8 миллионов поездок в день, 500 кластеров Redis в 8 регионах AWS, и всё это смигрировали на Valkey силами двух инженеров за два месяца. История inDrive. В новом выпуске подкаста «AWS на русском» говорим с Vadym Voitiuk (Principal SA, AWS) и командой inDrive (Alexander Lisachenko, Solution Architect + Artem Gab, Engineering Manager) про Redis, Valkey и ElastiCache в масштабе ride-hailing: 🔹 inDrive в цифрах: 48 стран, 1000+ городов, 8M поездок в день и миллионы водителей в real-time телеметрии🔹 Каир-проблема: одна city_id = один hot slot. Почему m6g.24xlarge (96 ядер) не спасла, и как однопоточный Redis завалил прод🔹 H3 гексагоны от Uber как новый ключ шардирования: разблокировали горизонтальное масштабирование по shard🔹 Микросервисная архитектура: от коммунального Redis к Redis per microservice per region, blast radius сократили с мира до страны🔹 Миграция 500 кластеров OSS Redis -> Valkey: 2 инженера × 2 месяца × zero-downtime через AWS online engine migration, ~20% экономии подтверждено CUDOS Будет полезно SRE, DevOps и архитекторам, у кого Redis/Valkey под серьёзной geo-нагрузкой, и всем, кто думает про переезд с self-managed Redis на ElastiCache или с Redis OSS на Valkey. 💡 Обычный CPUUtilization врёт на Redis/Valkey: при outage может показывать «всё ок». Смотреть надо на EngineCPUUtilization. Redis однопоточный, и именно оно показывает загрузку того самого «золотого» ядра, которое работает с данными. 🎧 Доступно на любимой платформе:• YouTube, Podbean, Apple Podcasts, Яндекс Музыка, Spotify, RSS (ссылки ниже) 💬 А у вас Redis прячет свой «золотой» core? Какие метрики мониторите в ElastiCache на проде? #Redis #Valkey #ElastiCache #H3 #inDrive #AWS #Подкаст #AWSнаРусском Навигация (Podbean)(0:00) Introduction(0:57) Гость AWS - Вадим Войтюк(1:05) inDrive: Саша (SA) + Артём (Engineering Manager)(1:51) Что такое inDrive: ride-hailing с аукционом цены, 48 стран(4:28) Масштаб: 8M поездок в день и real-time телеметрия водителей(7:07) Почему Redis: геоиндексы для dispatch и Ленты(9:31) GEOADD, проекция Меркатора и геоподводные камни(10:27) Старый подход: city_id и hot slot на мегаполис(12:32) «Каир-проблема»: всё упирается в одно ядро(13:21) Redis на железе в виде «ёлочки»(16:27) Миграция в ElastiCache: один shard на 90% CPU(18:00) m6g.24xlarge не спас: Redis однопоточный(19:01) Нет контроля над распределением cluster slots(20:53) Первый rollback с production(22:14) Решение: H3 гексагоны от Uber(26:20) Временный Redis operator в EKS(28:50) Сейчас: ~500 кластеров × 8 регионов(29:52) Redis как hard dependency микросервиса(32:14) Engine CPU: ключевая метрика(34:33) Scale by shards vs by nodes(35:35) T-family baseline, кредиты, переход на M-family(38:37) Переезд на Valkey(39:06) 20% экономии по CUDOS(42:46) 500 кластеров × 2 инженера × 2 месяца(45:18) Online engine migration: zero-downtime(48:08) Graviton как дефолт для managed-сервисов(49:57) Топ метрик: engine CPU, memory, network(52:06) Секретная метрика Geospatial CMDS latency(53:00) Connection storming как предиктор cascade failure(55:46) TLS offloading + IO multiplexing на Valkey large+(58:55) Wish-list: network autoscaling + гибридный(1:00:23) Итоги   YouTube: https://youtu.be/LZLvJJvePSoPodbean: https://awsinrussian.podbean.com/Apple Podcast: https://podcasts.apple.com/by/podcast/aws-на-русском/id1600771698Яндекс.Музыка: https://music.yandex.ru/album/20088544Spotify: https://open.spotify.com/show/4kOoih4FvHqyK5mLF3E42JRSS: https://feed.podbean.com/awsinrussian/feed.xml

    Tue, 12 May 2026
Mostrar más episodios