WebinarTV searches the internet for public Zoom invites, joins the meetings, secretly records them, and publishes (alternate link) the recordings. It doesn’t use the Zoom record feature, so Zoom can’t do anything about it.
Предизборната кампания навлиза в острата си фаза, в която партиите изоставят неутралитета и започват да се конфронтират.
Докато служебната власт се опитва да се справи с ефекта от поскъпналите горива, купуването на вот и воя срещу двустранното Споразумение за сътрудничество в областта на сигурността между България и Украйна, мишените се сменят. Срещу служебното правителство открито се противопоставиха Радев, но и председателите на БСП и „Възраждане“ – Крум Зарков и Костадин Костадинов. Основният им аргумент е, че Андрей Гюров не може да поема такива международни ангажименти, защото е служебен министър-председател.
За прогресивния нов лидер Румен Радев приоритет е разграждането на олигархичния модел „Борисов–Пеевски“ и даже при посещението си в Крумовград и Момчилград заяви:
Искам вече веднъж завинаги да стане ясно: коалиция с Пеевски и с Борисов няма как да има.
А в действителност критиките му са фокусирани върху служебния кабинет и ПП–ДБ. Появата му след декемврийските протести също беше предизвикана (донякъде) от опасения, че ПП–ДБ могат да оберат значителна част от протестния вот и да обезсмислят излизането му на политическата сцена.
При обиколките си из страната сега Радев пусна отново в обращение няколко мантри от президентската си битност: първо, „сглобкаджиите“ (да се чете „ПП–ДБ“) трябва да бъдат наказани на изборите; второ, въвличат ни във война; трето, евтините руски енергийни суровини са наблизо – през Черно море, но угаждаме на ЕС, а цените галопират. Има и четвърто –
никой не ви попита за въвеждането на еврото.
Така Борисов и санкционираният за корупция от САЩ и Великобритания Пеевски стават фонов шум, докато огънят се насочва срещу ПП–ДБ.
В същото време водачът на „Прогресивна България“ в Кърджали – бившият вътрешен министър Иван Демерджиев, се опитва да нахъса избирателите, нахлувайки в офиса на ДПС – Ново начало. По-късно през Facebook покани за пехливански борби кмета на община Кърджали Ерол Мюмюн и лидера на ДПС – Ново начало Делян Пеевски. Видео го показва изправен срещу Мюмюн, и двамата като боксьори тежка категория – сцена, напомняща на мача от 1997 г., когато Майк Тайсън отхапа ухото на Ивендър Холифийлд.
Спортът сплотява и ни прави по-благородни и по-добри, а понеже явно няма да има политически дебат, гражданите на Кърджали ще могат да се насладят на спортен такъв.
Подобен сблъсък (почти) се състоя и в парламента – между Пеевски и съпредседателя на „Да, България“ Ивайло Мирчев в началото на декември миналата година.
Няма как, политиката неизбежно има и своята сценична част. Колко ефективно работи този тип комуникация за избирателите, ще стане ясно на 19 април, когато урните дадат своя отговор. Дотогава Румен Радев ще продължи да засилва евроскептичния си суверенистки и проруски наратив. Очевидно в щаба му добре разбират колко важна е автентичността за този тип послания – достатъчно, за да притиснат електорално формации като „Възраждане“, „Величие“ и МЕЧ, докато БСП с новия си лидер може да си позволи малка глътка въздух.
Тази генерална репетиция на Румен Радев за заседанията на Европейския съвет по-скоро разкрива ограничен потенциал за роля ала Виктор Орбан, който сам е изправен пред риск да загуби властта след изборите на 12 април. Ако не „троянски кон“ или инструмент за излизане от НАТО и ЕС, то със сигурност на Радев му се очертава друга роля: на руско „троянско пони“ в двора на Европа.
Ако Орбан падне, засега няма кой да го наследи като знаме на консерваторите и автокрацията в Европа, останала (до момента) бастионът на либералната демокрация.
За Унгария това не са обикновени парламентарни избори. Резултатите от тях ще имат последици не само за страната, но и за цяла Европа, тъй като ще очертаят границите на политическото влияние между Брюксел и Москва.
Доминиращата външнополитическа тема превръща изборите в референдум за геополитическата ориентация на страната. Не по-малко важен е и въпросът възможно ли е да бъде спрян преходът на Унгария към нелиберална държава, замислен, осъществен и ръководен от Орбан – с демонтаж на върховенството на закона, с насочване на публичните ресурси към лоялни олигарси, със заличаване на медийната свобода и на индивидуалните свободи, с държавен контрол.
Разследващият портал VSquare и журналистът Саболч Пани предупредиха за намеса на руското военно разузнаване (ГРУ) в изборния процес, за което говори и съперникът на Орбан – Петер Мадяр. Властта определи тези твърдения като фалшиви новини, но VSquare съобщи, че наблюдава модели на намеса, сравними с тези на изборите в Грузия, Молдова и Румъния, за които беше обвинена Русия. Същата платформа публикува телефонен разговор от август 2024 г. между „човека на Путин в ЕС“, както наричат унгарския външен министър Петер Сиярто, и руския първи дипломат Сергей Лавров.
Управляващият от 16 години Орбан и партията му „Фидес“ започнаха война с всички средства, които осигурява държавата с нейните институции, срещу Мадяр и създадената преди две години „Тиса“. В навечерието на кампанията Мадяр обяви, че е изнудван с незаконно направен запис, в който прави секс по взаимно съгласие с бившата си приятелка.
Скандалът се върти около предполагаема злоупотреба с власт от страна на правителството на Орбан. Според свидетелства на бившия служител Бенце Сабо пред унгарски разследващи медии, тайните служби са използвали измислено разследване (за детска порнография), за да атакуват ИТ специалисти, свързани с опозиционната партия „Тиса“, с цел да получат достъп до нейни данни. Това е станало чрез натиск, незаконно изземване на техника и копиране на информация, което вероятно е довело и до изтичане на лични данни на хиляди поддръжници. Властите отричат политически мотив и твърдят, че става дума за контраразузнавателна операция срещу „украински шпиони“, но не представят доказателства.
Орбан гради образ на опозицията като проводник на украински интереси, предупреждавайки, че евентуална победа на „Тиса“ ще въвлече страната във война с Русия и ще отклони ресурси към Киев. Дори стига по-далеч, обвинявайки Украйна в опит за намеса в изборите с „пари, натиск и агенти“, но и загадъчно предупреждава, че има
още няколко патрона в пълнителя.
От своя страна опозиционният лидер Мадяр насочва вниманието към връзките на властта с Москва. Той обяви, че ако спечели вота, ще разследва отношенията между Будапеща и Кремъл с фокус върху близостта на Орбан с руския президент Владимир Путин.
Петрол срещу отмяна на санкции?
Подхвърлянето на Радев за близостта на руския петрол ни връща към времената, когато той публично се противопоставяше на санкциите срещу Русия. Изявлението му идва в момент, в който инфлацията в България се впуска в галоп заради повишаващите се цени на горивата. Според изследване на „Алфа Рисърч“ 47% от българите посочват като първи проблем, с който да се заеме бъдещото редовно правителство, доходите и инфлацията, а за 33% най-важни са борбата с корупцията и реформата в съдебната система.
Европейската комисия отлага законодателното предложение за постоянна забрана на вноса на руски петрол като санкция заради войната на Русия с Украйна, както планираше. ЕС рязко намали вноса след инвазията през 2022 г. и за последното тримесечие на 2025 г. само 1% от петрола, който внася, е руски.
„Лукойл Нефтохим“ няма право да преработва руски петрол от 1 март 2024 г.
Москва се възползва от войната в Иран и блокирания Ормузки проток, за да предложи услугите си да облекчи пазара на петрол и петролни продукти.
Русия е готова да изиграе важна роля във формирането на новата архитектура на глобалната логистика и международната търговия на фона на проблемите в Ормузкия проток,
Εдинствено Унгария и Словакия внасяха руски петрол към 27 януари, когато Киев съобщи, че руски дрон е ударил съоръжения на нефтопровод в Украйна, прекъсвайки доставките. Двете страни обвиниха Украйна, че умишлено забавя възобновяването на петролните доставки, което предизвика политически спор и в резултат Унгария блокира заем за Киев от ЕС.
Председателката на Европейската комисия Урсула фон дер Лайен вече заяви, че сега не е моментът да се вдигат санкциите срещу Русия и това би било стратегическа грешка.
Какво би предложил Румен Радев, ако например представлява България като премиер на заседание на Европейския съвет в Брюксел?
Ясно е, че цените на горивата ще внасят инфлация, а българските финанси вече са на дефицит 1,2% за първото тримесечие, тоест почти половината от планираното превишение на разходите над приходите е изядено от януари до март. Ако дупката в бюджета се разширява с това темпо, има три варианта: орязване на разходи, вдигане на данъци, нови заеми. Партиите, които дават заявки за властта, трябва да са готови и с рецепта за неотложни мерки.
Според изводите в него Радев вече е спечелил изборите в социалните мрежи.
Данните от наблюдението във Facebook и TikTok показват ясен дисбаланс в онлайн видимостта на политическите сили. Съдържанието, свързано с бившия президент Румен Радев, доминира и в двете платформи, като обхватът и темповете му на растеж значително надвишават тези на конкурентите.
Войната на Русия срещу Украйна, както и новият конфликт в Близкия изток, осигуряват почти неизчерпаем поток от поляризирано и поляризиращо съдържание, което платформите са склонни да усилват. Случаят не е изолиран, а се вписва в по-широка европейска картина на избори, уязвими към дигитална манипулация, на фона на близки във времето изборни процеси в Унгария, Словения и България.
Не за първи път има обосновани предположения за руска намеса в избори в европейски държави. През 2024 г. например Европейският парламент изрази загриженост заради зачестилите руски опити за намеса в изборите в България на 9 юни. При гласуването на резолюцията обаче двама български евродепутати – Андрей Слабаков и Ангел Джамбазки (ВМРО/Партия на европейските консерватори и реформисти), се въздържаха.
Eвродепутатите изразиха „силна загриженост за съществуването на мрежа от агенти по дезинформация в социалните и традиционните медии, академичните среди, неправителствени организации и партии, както и че има руски контрол върху тази мрежа“. Опасенията бяха засилени и от множеството имоти на руската държава в България, които служат като центрове на влияние върху демократичните процеси.
За да противодейства на външна намеса в изборите, идваща от Русия, този път България поиска съдействие от ЕС. За страната ни е активирана системата за бързо реагиране, която е част от доброволен механизъм на ЕС за сътрудничество на подписалите Кодекса за поведение относно дезинформацията.
Макар и не в мащаба на Унгария, предстоящите парламентарни избори в България също са определящи за мястото ѝ в ЕС. Еврото е нашият паспорт за по-дълбока интеграция, но възходът на Румен Радев може да я възпре.
През 2000 г., на обръщалото на века, преведох половин книга от Джулиан Барнс. Бях наскоро завършила студентка, бях довършила чужд превод на „Дългът към удоволствието“ на Джон Ланчестър и ми дадоха да довърша и „История на света в 10 ½ глави“. В моята част се падна последната глава – „Сънят“. Може би я помните, Мариус имаше прочут моноспектакъл по нея, сега Йордан Славейков я поставя чудесно.
В „Сънят“ героят се събужда умрял. Неговата лична история е свършила и му предстои вечен рай. Малко по-рано пък Фукуяма беше обявил края на историята, завършила с победа на либералната демокрация. Разбира се, вечността не се оказва райска работа, дори да е скроена според всичките ти желания (у Борхес безсмъртните оскотяват…). Но и вечност не ни предстоеше. Барнс явно беше поприбързал с епилога – в следващите си книги продължи да разказва за приближаването към този „сън“. Още през 2004 г. заговори за старостта през „Лимони на масата“; през 2008-ма издаде „Няма нищо страшно“; после дойдоха „Пулс“ и „Предчувствие за край“, и „Нива на живот“ – за скръбта по съпругата му Пат.
През 2000 г. потъна „Курск“, на следващата самолетите се забиха в кулите близнаци, после дойдоха войните в Афганистан и Ирак, после Беслан, глобалната криза, Арабската пролет и Гражданската война в Сирия, анексирането на Крим, възходът на ИДИЛ… и за капак на всичко пандемията от ковид и трите големи войни. Очевидно проблемът ни е обратният: твърде много история, твърде бурна история се случва около нас. Все повече хора отбягват новините или гледат да ги дозират, за да не се побъркат. Какво прави писателят с такива читатели? Те не са жителите на провинциално градче, които отварят романче за малко драма. Тези читатели отварят книга, за да избягат от драмата. Дали?
В предговора на „Златният сън“ Шарл Нодие предписва като лек за смутни времена фантастичното. Склонни сме да му повярваме; той е живял по време на якобинския терор. Баща му бил инструмент на въпросния терор (като полицейски магистрат) и затова успявал някак да опази сина си въпреки непрестанните опити на момчето да помага на жертвите (защо това е опасно, можем да си отговорим, като си спомним сталинския терор). Шарл започнал още на 13 – заплашил да отнеме живота си, ако една жена бъде осъдена, задето изпращала пари на емигрант. Жената оцеляла, но бащата сметнал за благоразумно да предаде сина си на ментори, които да го занимават със старогръцки и други езици, както и с естествознание (единият бил виден фиколог, изследовател на водораслите).
И тъй, Нодие израснал между гражданската въвлеченост и ескейпизма – хем станал библиотекар (сравнително безопасно), хем скачал в защита на заподозрените (опасно); хем конфискацията на книжата му разкрила само труд по ентомология (безопасно), хем поседял в затвора, защото писал памфлет срещу Наполеон… След разни странствания се установил в Париж, където (вече по време на Реставрацията) станал библиотекар на Арсенала и създал прочут литературен салон, в който се навъртали младоците Виктор Юго, Ламартин, Алфред дьо Мюсе, Сент-Бьов, Нервал и пр. Един вид, таткото на френския романтизъм.
Нищо чудно, че предписва като хап фантастичното. „Златният сън“ е съвършена романтична история; в нея има екзотика (сцената е „Ориентът“), има притча, или по-скоро авторски сюжет, наметнал дрехата на древното предание; има прескачане от единичното към сюблимното. Имаме поредица от герои – изискан в разточителното си изящество гущер, млад глупав бедняк, мъдрец, разбойник и т.н. Попаднали един след друг на купчина жълтици, те кроят планове за богатството си (и двукраките „пречки“ пред него) – и заспиват под сянката на арчара, на огромното китно дърво. На смъртта. Всички са правили сметки без нея. И тъй, привиден ескейпизъм вместо политическите брожения на якобинска, Наполеонова и реставрационна Франция – „безвременния“ Ориент. От друга страна – опулване право в окото на дебнещата зад всеки сън смърт.
Интересно, че Веселин Праматаров, който в „На конци“ вече показа и художническо майсторство, и умение за подбор на тема, която хем е навременна, хем не е злободневна, тук е избрал за визуален език сецесиона, с видими препратки към неговото наследство. Това ми се струва подходящо както в едър план – този стил е видим наследник на романтизма, така и специфично в българската визуална история. Иван Милев например е силно белязан от военния си опит, който го разтърсва силно (и уврежда слуха му). И у Милев ще видим същия интерес към авторизираната легенда (например Ахинора). Праматаров добавя трети нюанс – изкуството на комикса за възрастни. Така книгата нарежда нашето време до якобинския терор и Първата световна война и някак казва: „Тези хора са живели близо до смъртта и вижте какво са създали, хайде по-смело.“
превод от английски Надежда Розова, София: изд. „Обсидиан“, 2026
В новата книга на Барнс срещата със смъртта не минава през притчи. Тя е доста фронтална – след толкова обговаряне в другите книги тук тя е буквална, медицинска: героят, а и самият писател, има рак. И Барнс не отвръща очи от реалността на тялото в медицинската машина – ту с почти смущаваща директност описва прегледа на простатата, ту с горчив смях коментира изливащите се в канала литри кръв (Барнс реколта…) Медицинският аспект на тази книга е странно успокоителен – за всеки преживял реалността, от която другите бягат.
Упадъкът на тялото е линеен и предизвестен. Но книгата се интересува от цикличността, от възвръщането. Най-явно това се вижда в любовния сюжет – двама приятели на героя, влюбени в студентските си години, се събират отново на старини и се женят. И в двата случая ги събира той. На пръв поглед историята следва холивудската формула „трагедия с щастлив край“. Само че щастливият край не е щастлив, защото не е край – историята продължава, трагедията продължава. Фукуяма за двойки. Но Барнс се интересува и от друга цикличност, от тази на спомена: повторната сватба между човека и преживяното от него. Споменът е изменчив, той лъже (както пише и Мария Степанова в погрешно „припомнената“ къща); освен това той бива редактиран (прочутата мадлена на Пруст в черновите е ту къшей хляб, ту суха бисквитка). Миналото, уж единственото ни останало владение на прага на смъртта, също ни се изплъзва – губейки паметта си, дали губим изцяло и себе си?
Странната утеха, предлагана от Джулиан Барнс, е не в края, а в началото на книгата. Също както в „Сънят“ той довежда до абсурд мечтата на човека за рай, тук представя колко страховита би била една вярна, неотлъчно следяща ни памет (като на Борхесовия Фунес?); как способността не просто да преразкажем, а да преживеем наново всеки изминал момент би била нетърпима, обсебваща.
Човек има правото да бъде забравен, чух веднъж от приятел. Мисля, че Барнс добавя: „Дори и от себе си.“
В емблематичната си колонка „Ходене по буквите“, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. В началото на 2020 г. той я пренесе в „Тоест“. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка. От края на 2021 г. по буквите тръгна Зорница Христова.
Активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на над 15 български издателства. Кои са те – вижте в условията на Читателски клуб „Тоест“.
На хората им е тъжно за Варна. Признават ми го често, когато посещават града, когато им разказвам за него, когато четат новините. Правят го по начин, който е различен от преди. Някога обвиняваха – къде с основание, къде без, че варненци сме твърде инертни и подозрително толерантни към властта на митичния ТИМ – първото, което идва наум, като се заговори по варненски теми. Всички бяхме подозирани, че сме се колаборирали с „голямото зло“ на основа постоянен адрес. Днес в тъгата по Варна има и голяма доза съчувствие – това е разликата.
Вече цяла България (от която половината е София) вижда, че гражданите на Варна правят каквото могат, изразяват позиция, протестират, гласуват, а резултатът – все по-голям упадък на града, който преди 30–40 години беше „най-европейският“, „лицето на държавата“ и т.н.
Никой обаче не е наясно с това повече от самите варненци.
Преди две десетилетия, когато започна да се прави новият Общ устройствен план на Варна, прогнозата за развитието на града беше фантастична. Нови булеварди и урбанизирани зони смело се чертаеха около една централна идея – населението ще расте. Според предвижданията към 2030 г. Варна трябваше да е половинмилионен град, а след още 20 години да е пораснала толкова, че да има нужда от метро.
Реалността се оказа друга. През 2012-та, когато с доста зор Планът беше най-сетне приет, във Варна живееха около 340 000 души. Според някои данни обаче през 2025-та населението не само не се е увеличило над тези стойности, а даже леко е намаляло. Все по-ясно е, че красиво обрисуваната „варненска мечта“, превърната в план със силата на закон, няма да се сбъдне.
Колкото по-голяма е амбицията, толкова по-болезнен е провалът
Идеите бяха наистина мащабни, но не стигнаха доникъде. На отворената обществена зона на пристанището трябваше да има концертна зала (нещо като Операта в Сидни), морски музей, аквариум (като в Барселона). В момента тя е запълнена с широка палитра от кръчми, лунапарк и автомивка.
Аспаруховият мост си остава единствен над канала море–езеро, поемайки самостоятелно целия трафик на Черноморието. Големият стадион все така се строи със скоростта на магистрала „Хемус“ и оптимистичната версия е, че след 20 години бавене най-накрая ще го има, макар и с двойно по-малък капацитет от някогашния „Юрий Гагарин“, който заслужено носеше титлата „национален“.
На този фон е очевидно едно – Варна е по-малък град, отколкото ни се иска, въпреки потенциала му, който винаги е бил огромен. Защо се получава така, е наистина дълга тема, в която са намесени сериозно и геополитически фактори. Нека припомним само, че тъкмо по времето на големите мечти и амбиции във Варненския залив военни кораби на България, Румъния, Украйна, Русия, Грузия и Турция правеха съвместни учения, а на Морска гара се извиваха опашки от семейства с деца, които чакаха да се качат на борда им и да се снимат за спомен с нагиздените в безупречно бели униформи чуждестранни моряци. Честите посещения на бойни кораби на САЩ и другите държави от НАТО също бяха атракция, не знак за някакво напрежение.
Руско-грузинската война и най-вече анексирането на Крим сложиха край на идиличната ситуация в Черно море и го превърнаха в рискова зона, което удари лошо Варна тъкмо когато тя беше намерила мястото си в тази оптимистична картинка. Няма ги днес десетките големи круизни кораби на сезон, няма ги красивите ветроходи от регатата „Тол Шипс“, която си остава най-престижното (и единственото) световно морско събитие не само за града, а и за цяла България. Липсва това, което караше и варненци, и туристи да въздъхват с възторг: „Ех, друго си е…“
Това, което има Варна днес, е имоти
Апартаменти – нови, стари, малки, големи, реновирани, санирани, в центъра, в комплексите, в курортите, които окончателно се превръщат в жилищни квартали. А има също и парцели, на които да изникнат още нови апартаменти, натъпкани в абсурдни сгради със съмнителни архитектурни и инженерни качества. На практика това вече не е град, а РЗП – разгърната застроена площ.
Не е ли абсурдно, че жилищата в един град растат като брой, а населението му намалява?
За мен е, но не и за пазара на имоти у нас. След като българите виждат в недвижимото едва ли не единствената възможна инвестиция, високите цени във Варна стават обясними. Все пак говорим за имот на морето. Да, не е гръцкото море, но все пак е нещо. А и по необясними за мен причини цените на имотите във Варна продължава да растат неудържимо, така че, ако си купил нещо преди няколко години, днес можеш да го продадеш с печалба. Или пък да събираш наеми, които също са диспропорционално високи на фона на състоянието на града и бизнеса в него.
Разбира се, жилища купуват не само българи, а и чужденци. Един пристанищен град винаги е отворен към света и вълните от преселения са напълно естествени. Руското присъствие във Варна често е най-яркият елемент на засилващата се тъга по развитието ѝ. Мнозина директно изказват притеснение, че тя е станала „руски анклав“; че по улиците не се чува българска реч. Това не е далеч от истината, но с една малка подробност.
„Руснаците“ във Варна не са само руснаци, а и украинци, молдовци, казахстанци. Варненците, дори и без филологическо образование, вече правят разлика между украински и руски говор, но това е, общо взето, новост – преди 2014-та никого не го беше грижа за това. Самите рускоговорещи пък се принудиха бързо да учат български, защото езикът им вече не е универсалното средство за комуникация от епохата на „вечната дружба“ с България. Преди дни магазинерка с характерен акцент ми обясни, че еди-коя си стока е „на него рафт“, което ме накара да се усмихна. Ясно, тя вече е от местните, вече си е варненка, независимо откъде е дошла.
За имигрантите „варненската мечта“ си е жива, защото им дава повече възможности за бизнес, за по-нормален живот, за повече свобода, ако щете.
По тази причина твърденията за „руски анклав“ са преувеличени и леко намирисват на ксенофобия, която няма как да просъществува в един пристанищен град, където и да е по света. Така че руснаците не са големият проблем на Варна.
Доста по-голям проблем е амбицията на местните управници да гонят „челни позиции“ за себе си и уж за града. Това води до грешки и безсмислици, които остават като паметници на глупостта, при това изключително трайни, защото в тях е налят бетон за милиони. Обектите, които се появиха в последните години с главна цел „усвояване“, са твърде много, за да бъдат изброени.
Емблематичен пример обаче е рибарското пристанище „Карантината“, заради което Европейската прокуратура повдигна обвинения за измама срещу бившия кмет Иван Портних и бившия областен управител Стоян Пасев, както и срещу други лица. Делото беше прекратено, а обвинението върнато от Софийския градски съд. Каквото и да е продължението на тази история, пристанището си остава на мястото, както и куриозният му проблем.
Оказа се, че то има вграден дефект от самото начало – точно на входа му се събират наноси и се образува плитчина, в която всеки по-голям плавателен съд може да заседне. При по-сериозно спадане на водното ниво плитчината се превръща в малко островче. Удълбочаването и изгребването на наносите, което не е евтино и не може да се прави постоянно, не решава проблема, защото теченията са такива, че пясъкът отново се натрупва на същото място. Грешката е в проекта, в който явно въпросните течения не са отчетени или нещо друго е сбъркано въпреки уверенията, че всичко е съгласувано със специалисти океанолози и всякакви други експерти, които би трябвало да предвидят тази „малка подробност“.
Днес „Карантината“ е пълна с малки лодки и яхти с по-малко газене, за които плитчината очевидно не е пречка, а шкиперите им са се научили да я заобикалят безпогрешно. Резултатът от инвестираните милиони обаче е много далеч от предвиденото.
Целта беше пристанището да се превърне в рибна борса, на която рибарските кораби да предлагат пресния си улов директно от морето при всички необходими условия. Но тъй като то е недостъпно за корабите им, това просто няма да го бъде, докато не се намери трайно решение за справяне с наносите. А то ще бъде сложно и скъпо.
Нещо подобно се случи и с Шишковата градинка в сърцето на града.
Целта беше тя да стане образец на модерна паркова архитектура, след като дълги години остарелият ѝ вид будеше съжаление. Изготви се красив проект, с амбициозен воден обект, наричан ту „водно огледало“, ту „водна стена“… Необходимите и за това милиони бяха намерени. След реконструкцията и с няколко години разлика Шишковата градинка изглежда точно толкова запусната, колкото и преди амбициозната намеса. Водното съоръжение бързо-бързо спря да работи и сега никой даже и не го забелязва, камо ли да помни било ли е красиво някога.
В крайна сметка стана така, че когато във Варна се започва нещо ново, това не буди някакво положително вълнение у гражданите, а по-скоро притеснение какво ще се обърка или скапе този път.
Новата коренна промяна, която очаква града, е свързана с Крайбрежната алея в района на буните. Там в момента са разчистени всички стари заведения, някои датиращи от 90-те, заради предстоящата реализация с огромно закъснение на проекта „Алея първа“ на „Холдинг Варна“ АД. По-младите поколения не помнят варненското крайбрежие в този вид и се чудят на радикалното разчистване.
Това отговарят многозначително варненците над средна възраст, защото е общоизвестно, че каквото и да се случва край морето, е свързано с икономическите структури, които местните наричат с това общо прозвище. И млади, и стари в крайна сметка стискат палци сега нещата да се получат поне прилично в този град, в който провалите са се превърнали в устойчива тенденция. Защото голямото богатство на Варна е едно – морето. В повечето случаи то е достатъчно, за да преглътнеш проблемите, с които градът те товари всекидневно. Но ако връзката на хората с него бъде нарушена, а не подобрена, вероятно Варна ще стане още по-малък град – и като население, и като значение.
By Renata Teixeira, Zhi Li, Reenal Mahajan, and Wei Wei
On January 26, 2026, we flipped an important switch for Live at Netflix: all Live events are now encoded using VBR (Variable Bitrate) instead of CBR (Constant Bitrate). It sounds like a small configuration change, but it required us to revisit some of the foundational assumptions behind how we deliver Live video at global scale.
VBR lets us tailor the bitrate to the actual complexity of the scene, instead of sending every second of video at roughly the same bitrate. When a scene is simple, VBR “shaves off” bits that wouldn’t improve what you see on screen; when a scene is complex, it spends more bits to preserve quality. (The more general idea is often referred to as capped variable bitrate, or capped VBR.) That makes our encodes more efficient and our network more scalable. But it also makes traffic much less predictable: large bitrate swings can overload servers and CDNs, and our old assumptions about “what bitrate equals what quality” no longer hold. As a result, we have to rethink both how we manage delivery and capacity, and which bitrates we offer for each version of the stream. In our live pipeline, we currently use AWS Elemental MediaLive, where this “capped” VBR is implemented using the QVBR (Quality‑Defined Variable Bitrate) setting.
| Why Move Live from CBR to VBR?
Our initial Live encoding pipeline used constant bitrate (CBR). For each encoded stream, we configured a resolution and a nominal bitrate — for example, a 1080p stream targeting 5 Mbps — and the actual bitrate stayed close to that target over time. This predictability made both capacity planning and day‑to‑day operations easier. If a server could safely deliver around 100 Gbps of Live traffic, and each stream averaged close to its nominal rate, we could admit on the order of twenty thousand concurrent sessions per server and be confident we were operating within limits. During an event, the total traffic sent by a server would change mainly when members joined or left; as long as concurrency was stable, traffic stayed relatively flat. The network saw a smooth, easy‑to‑reason‑about load profile, and large changes in throughput almost always reflected a real change in usage, not just a different scene on screen.
The problem is that content isn’t constant. A talking‑head segment in a studio or a simple animation is much easier to compress than a sequence of rapid camera moves and fast‑moving athletes in front of a highly detailed crowd. With CBR, both the easy and the hard segments get the same bitrate. In simple scenes, we spend more bits than we need; in complex scenes, we sometimes don’t spend enough.
VBR flips the objective. Rather than aiming for a fixed bitrate, the encoder aims for a target quality and is allowed to raise or lower the bitrate according to scene complexity. When the picture is easy to encode, VBR can drop the bitrate substantially below the old CBR level while keeping quality constant. When the action heats up, it can temporarily use more bits to avoid visible artifacts.
The figure below shows the per‑segment bitrate over time for the same episode of WWE RAW, encoded once with CBR and once with VBR at a nominal 8 Mbps. With CBR (blue), the bitrate wobbles a bit from segment to segment but stays close to the target; if you average it over a minute, it’s practically a straight line. We end up spending roughly the same number of bits on simple scenes, like the waiting room at the start of the stream (shaded region), as on complex scenes, like the confetti‑filled shot later in the show. With VBR (orange), the encoder can drop the bitrate for the waiting room to a small fraction of the nominal rate, while allowing the confetti‑filled shot to use a much higher bitrate to preserve quality.
Per-segment bitrate over a WWE RAW episode for CBR and VBR encodes at a nominal of 8 Mbps.“Waiting room” scene: visually simple and easy to compress, so VBR can safely use a low bitrate.“Confetti-filled” shot: visually complex and noisy, so VBR spends many more bits to maintain quality.
At Netflix scale, the shift to VBR has several important effects. The most important is efficiency on the network: we reduce the average number of bytes we need to deliver a full event, which in turn reduces the traffic needed to fill all of the servers in Open Connect, our content delivery network (CDN), and the traffic needed to serve segments to members. The second is quality of experience. Because VBR sends fewer bits for similar video quality, we see fewer rebuffers and lower start‑up delay. Across multiple A/B tests on different Live events, we observed about 5% fewer rebuffers per hour, while transferring roughly 15% fewer bytes on average and around a 10% reduction in traffic at the peak minute.
| When Efficiency Fights Stability
The central challenge with VBR for Live is not that bitrate varies at all (it does under CBR as well), but that VBR can have much deeper, longer dips in bitrate, tightly coupled to what’s happening in the content.
Under CBR, a 5 Mbps stream is effectively that: on a per‑minute basis, traffic is remarkably flat. A server that is comfortably handling, say, ten thousand such sessions now is likely to still be comfortable in a minute, barring a wave of new joins. It’s safe for our steering logic to look at current traffic, see plenty of headroom, and route additional sessions to that server.
Under VBR, the same stream behaves very differently. During a slow, easy sequence, the encoder might only generate 2 Mbps for the 5 Mbps stream — or even less — to maintain its target quality, and it can stay at that lower level for an extended period. The server then appears to have plenty of unused capacity: per‑session bitrate is low and aggregate traffic is well below its limits. Our steering systems naturally interpret this as a signal that the server is under‑utilized and can accept more sessions.
The problem surfaces when the content changes. A fight starts, confetti begins to fall, or the camera cuts to a highly detailed, fast‑moving shot. To preserve quality, VBR may increase the bitrate to 6, 7, or 8 Mbps on the very next segments. If the server has admitted many additional sessions during the preceding low‑bitrate period, the aggregate traffic can suddenly exceed what the network link or NIC can sustain. Latency rises, packets are dropped, and devices start to experience stalls or quality downshifts. In extreme cases, this pattern of “bitrate dips followed by spikes” can destabilize parts of the system.
| Making Servers Aware of Bitrate Variability
These long VBR bitrate dips are great for efficiency, but — as we just saw — they can trick our delivery systems into thinking servers are under‑utilized and safe to load up. Under CBR, that behavior was predictable enough that current traffic was a good proxy for how “full” a server was; under VBR, it isn’t.
Our fix was to change how we decide whether a server can take more sessions. Instead of basing that decision only on current traffic, we reserve capacity based on each stream’s nominal bitrate, not just what it happens to be using at that moment. Even if a VBR stream is currently in a very cheap, low‑bitrate phase, we still treat it as something that can quickly return to its nominal rate.
This keeps our traffic‑steering behavior consistent between CBR and VBR and avoids the key failure mode where a server accepts too many sessions during a long low‑bitrate period and then becomes overloaded when bitrate rises again.
| Tuning VBR Nominal Bitrates to Match CBR Quality
The WWE example above already hints at why this isn’t automatic. We looked at a single 8 Mbps stream, encoded once with CBR and once with VBR. Both encodes have the same nominal bitrate, but the figure shows how differently they behave. The CBR encode stays clustered around 8 Mbps with frequent short spikes, while the VBR encode often drops far below that level and only spikes up when the content gets complex. That’s more efficient, but it also means that “same nominal bitrate” does not imply “same average number of bits” anymore — so simply reusing our CBR settings risks giving VBR less bitrate on average and losing some quality.
In practice, of course, we don’t just encode a single stream; we produce a set of streams at different resolutions and nominal bitrates — often called a bitrate ladder — so devices can adapt to their current network conditions by switching between them. When we first applied VBR using the existing CBR ladder, offline analysis with VMAF (a perceptual video quality metric) confirmed the concern from the WWE example: time‑averaged quality dropped slightly on a few streams, especially at the lowest bitrates. Early A/B tests showed the same pattern: overall VMAF about one point lower than CBR, with most of the gap at the bottom of the ladder.
To fix this, we compared CBR and VBR encodes rung by rung and looked at per‑stream VMAF. Wherever VBR fell more than about one VMAF point below CBR, we increased its nominal bitrate just enough to close the gap. Higher‑bitrate streams, where VBR quality was already very close to CBR, were left largely unchanged, including the 8 Mbps stream from the figure.
The result is a VBR ladder with slightly higher nominal bitrates on a few low‑end streams, but lower overall traffic, because VBR still drops the bitrate on simple scenes. This lets us match the quality of our CBR ladder while keeping the efficiency and stability gains that motivated the switch to VBR in the first place.
| What’s Next for Live VBR
With VBR in production for all Live events, our focus now is on using it more intelligently.
First, we are testing how to use the actual sizes of upcoming segments in our adaptive bitrate algorithms on devices, instead of relying only on nominal bitrates. This should help devices pick streams that better match how VBR will behave in the next few seconds, not just how a stream is labeled on paper.
Second, we are experimenting with making our capacity reservation less conservative. Today we reserve based on nominal bitrates to keep servers safe; by carefully applying a “discount” informed by real VBR behavior, we hope to free up additional headroom without sacrificing stability.
This work was the result of a broad, cross‑team effort. We’d like to thank Mariana Afonso, Dave Andrews, Mark Brady, Jake Freeland, Te-Yuan Huang, Ivan Ivanov, Yeshwenth Jayaraman, Patrick Kunka, Zheng Lu, Anirudh Mendiratta, Chris Pham, David Pfitzner, Jon Rivas, Garett Singer, Brenda So, Stan Surmay, Bowen Tan, Devashish Thakur, and Allan Zhou for their many contributions to making Live VBR a reality at Netflix.
Amazon OpenSearch Service powers observability workflows for organizations, giving their Site Reliability Engineering (SRE) and DevOps teams a single pane of glass to aggregate and analyze telemetry data. During incidents, correlating signals and identifying root causes demand deep expertise in log analytics and hours of manual work. Identifying the root cause remains largely manual. For many teams, this is the bottleneck that delays service recovery and burns engineering resources.
We recently showed how to build an Observability Agent using Amazon OpenSearch Service and Amazon Bedrock to reduce Mean time to Resolution (MTTR). Now, Amazon OpenSearch Service brings many of these functions to the OpenSearch UI—no additional infrastructure required. Three new agentic AI features are offered to streamline and accelerate MTTR:
An Agentic Chatbot that can access the context and the underlying data that you’re looking at, apply agentic reasoning, and use tools to query data and generate insights on your behalf.
An Investigation Agent that deep-dives across signal data with hypothesis-driven analysis, explaining its reasoning at every step.
An Agentic Memory that supports both agents, so their accuracy and speed improve the more you use them.
In this post, we show how these capabilities work together to help engineers go from alert to root cause in minutes. We also walk through a sample scenario where the Investigation Agent automatically correlates data across multiple indices to surface a root cause hypothesis.
How the agentic AI capabilities work together
These AI capabilities are accessible from OpenSearch UI through an Ask AI button, as shown in the following diagram, which gives an entry point for the Agentic Chatbot.
Agentic Chatbot
To open the chatbot interface, choose Ask AI.
The chatbot understands the context of the current page, so it understands what you’re looking at before you ask a question. You can ask questions about your data, initiate an investigation, or ask the chatbot to explain a concept. After it understands your request, the chatbot plans and uses tools to access data, including generating and running queries in the Discover page, and applies reasoning to produce a data-driven answer. You can also use the chatbot in the Dashboard page, initiating conversations from a particular visualization to get a summary as shown in the following image.
Investigation agent
Many incidents are too complex to resolve with one or two queries. Now you can get the help of the investigation agent to handle these complex situations. The investigation agent uses the plan-execute-reflect agent, which is designed for solving complex tasks that require iterative reasoning and step-by-step execution. It uses a Large Language Model (LLM) as a planner and another LLM as an executor. When an engineer identifies a suspicious observation, like an error rate spike or a latency anomaly, they can ask the investigation agent to investigate. One of the important steps the investigation agent performs is re-evaluation. The agent, after executing each step, reevaluates the plan using the planner and the intermediate results. The planner can adjust the plan if necessary or skip a step or dynamically add steps based on this new information. Using the planner, the agent generates a root cause analysis report led by the most likely hypothesis and recommendations, with full agent traces showing every reasoning step, all findings, and how they support the final hypotheses. You can provide feedback, add your own findings, iterate on the investigation goal, and review and validate each step of the agent’s reasoning. This approach mirrors how experienced incident responders work, but completes automatically in minutes. You can also use the “/investigate” slash command to initiate an investigation directly from the chatbot, building on an ongoing conversation or starting with a different investigation goal.
Agent in action
Automatic query generation
Consider a situation where you’re an SRE or DevOps engineer and received an alert that a key service is experiencing elevated latency. You log in to the OpenSearch UI, navigate to the Discover page, and select the Ask AI button. Without any expertise in the Piped Processing Language (PPL) query language, you enter the question “find all requests with latency greater than 10 seconds”. The chatbot understands the context and the data that you’re looking at, thinks through the request, generates the right PPL command, and updates it in the query bar to get you the results. And if the query runs into any errors, the chatbot can learn about the error, self-correct, and iterate on the query to get the results for you.
Investigation and investigation management
For complex incidents that normally require manually analyzing and correlating multiple logs for the possible root cause, you can choose Start Investigation to initiate the investigation agent. You can provide a goal for the investigation, along with any context or hypothesis that you want to instruct the investigation. For example, “identify the root cause of widespread high latency across services. Use TraceIDs from slow spans to correlate with detailed log entries in the related log indices. Analyze affected services, operations, error patterns, and any infrastructure or application-level bottlenecks without sampling”.
The agent, as part of the conversation, will offer to investigate any issue that you’re trying to debug.
The agent sets goals for itself along with any other relevant information like indices, associated time range, and other, and asks for your confirmation before creating a Notebook for this investigation. A Notebook is a way within the OpenSearch UI to develop a rich report that’s live and collaborative. This helps with the management of the investigation and allows for reinvestigation at a later date if necessary.
After the investigation starts, the agent will perform a quick analysis by log sequence and data distribution to surface outliers. Then, it will plan for the investigation into a series of actions, and then performs each action, such as query for a specific log type and time range. It will reflect on the results at every step, and iterate on the plan until it reaches the most likely hypotheses. Intermediate results will appear on the same page as the agent works so that you can follow the reasoning in real time. For example, you find that the Investigation Agent accurately mapped out the service topology and used it as a key intermediary steps for the investigation.
As the investigation completes, the investigation agent concludes that the most likely hypothesis is a fraud detection timeout. The associated finding shows a log entry from the payment service: “currency amount is too big, waiting for fraud detection”. This matches a known system design where large transactions trigger a fraud detection call that blocks the request until the transaction is scored and assessed. The agent arrived at this finding by correlating data across two separate indices, a metrics index where the original duration data lived, and a correlated log index where the payment service entries were stored. The agent linked these indices using trace IDs, connecting the latency measurement to the specific log entry that explained it.
After reviewing the hypothesis and the supporting evidence, you find the result reasonable and aligns with your domain knowledge and past experiences with similar issues. You can now accept the hypothesis and review the request flow topology for the affected traces that were provided as part of the hypothesis investigation.
Alternatively, if you find that the initial hypothesis wasn’t helpful, you can review the alternative hypothesis at the bottom of the report and select any of the alternative hypotheses if there’s one that’s more accurate. You can also trigger a re-investigation with additional inputs, or corrections from previous input so that the Investigation Agent can rework it.
Getting started
You can use any of the new agentic AI features (limits apply) in the OpenSearch UI at no cost. You will find the new agentic AI features ready to use in your OpenSearch UI applications, unless you have previously disabled AI features in any OpenSearch Service domains in your account. To enable or disable the AI features, you can navigate to the details page of the OpenSearch UI application in AWS Management Console and update the AI settings from there. Alternatively, you can also use the registerCapability API to enable the AI features or use the deregisterCapability API to disable them. Learn more at Agentic AI in Amazon OpenSearch Services.
The agentic AI feature uses the identity and permissions of the logged in users for authorizing access to the connected data sources. Make sure that your users have the necessary permissions to access the data sources. For more information, see Getting Started with OpenSearch UI.
The investigation results are saved in the metadata system of OpenSearch UI and encrypted with a service managed key. Optionally, you can configure a customer managed key to encrypt all of the metadata with your own key. For more information, see Encryption and Customer Managed Key with OpenSearch UI.
The new agentic AI capabilities announced for Amazon OpenSearch Service help reduce Mean Time to Resolution by providing context-aware agentic chatbot for assistance, hypothesis-driven investigations with full explainability, and agentic memory for context consistency. With the new agentic AI capabilities, your engineering team can spend less time writing queries and correlating signals, and more time acting on confirmed root causes. We invite you to explore these capabilities and experiment with your applications today.
Agentic AI represents a qualitative shift in how software operates. Traditional software executes deterministic instructions. Generative AI responds to human prompts with output that humans review and use at their discretion. Agentic AI differs from both. Agents connect to software tools and APIs and uses large language models (LLMs) as reasoning engines to plan and execute sequences of actions autonomously—at machine speed—with real-world consequences. This shift raises new questions for information security. In January 2026, NIST’s Center for AI Standards and Innovation (CAISI) issued a Request for Information (RFI) seeking industry input on how to secure these systems. AWS submitted a response grounded in our experience building and operating agentic AI services. This post summarizes the four security principles at the heart of that response and the architectural building blocks that implement them.
The NIST agentic AI RFI
CAISI asked developers, deployers, and security researchers to weigh in on how the industry should secure AI systems that act autonomously. The RFI posed questions across five areas. What unique security considerations do agentic systems introduce, and how do those considerations change as systems gain more autonomy? What practices improve security during development and deployment? How do organizations assess the security of their agentic systems? How can deployment environments be constrained and monitored? And where should the industry focus future research?
Why this matters
Even a conservative risk/benefit analysis will conclude that the benefits of agentic AI clearly outweigh the risks in many domains. The rapid adoption of agentic technology across business and government confirms this. But agents are valuable precisely because of their autonomy and adaptability, and these same characteristics create the security challenge. An agentic system that carries out an unintended action can do so at machine speed, before a human can intervene. Unlike human actors who pause or escalate when something seems unusual, agents might not inherently recognize ambiguities that are evident to humans, nor intuitively grasp unstated policy boundaries.
The good news, however, is that the security response to agentic AI doesn’t need to start from scratch. Existing security frameworks, including the NIST Cybersecurity Framework, NIST AI Risk Management Framework, and the Secure Software Development Framework, remain relevant and should be extended for agent-specific considerations rather than replaced. The most important extension is architectural. Our response to NIST identified four foundational security principles that address how to make that extension.
Four security principles for agentic AI
These principles build on the premise that agentic AI doesn’t require a new security paradigm, but it does require existing practices to evolve. The first two principles address what carries forward; the second two address what is genuinely new.
Principle 1: Secure development lifecycle practices apply across system components. Agentic AI systems combine traditional software components (APIs, databases, orchestration logic) with AI elements such as foundation models, prompt templates, and retrieval pipelines. A secure development lifecycle must cover both sets of components. For traditional components, established practices such as code review, static analysis, dependency scanning, and threat modeling remain essential, keeping in mind that those practices are also in the process of being enhanced with AI-based tooling. For AI components, the challenge is different. Foundation models are probabilistic, which means traditional regression testing is necessary but not sufficient. Organizations must supplement it with behavioral testing, adversarial evaluation, and continuous monitoring to validate that AI components operate within expected parameters.
Regular re-evaluation is equally important for addressing behavioral drift. Models receive updates that can alter behavior. Prompt templates evolve as teams refine agent capabilities. New tools and data sources expand the agent’s operational surface. Each change can introduce new failure modes or potential security issues. Organizations must treat evaluation as an ongoing operational practice, not a one-time gate. This includes automated testing after model updates, red team exercises against deployed agents, and monitoring that detects behavioral drift over time.
Principle 2: Traditional security controls remain fully applicable. Agentic AI introduces new considerations, but it doesn’t render existing security risks obsolete. The full complement of traditional security controls still applies. An agentic AI system combines traditional software with the new LLM-plus-tools processing loop. Organizations must secure existing software, tools, and configurations against well-known risks to provide a sound foundation for the agentic elements.
Privilege escalation, confused deputy issues, session hijacking, code injection, and supply chain risks extend directly into agentic systems. Some of these risks increase in agentic contexts. Agents operate at greater scale and speed than human actors, which means excessive privileges carry more potential for unintended consequences. That means that applying principles of least privilege to access management in an agentic context is as important—if not more so—than in traditional systems. The supply chain surface is also broader. Agentic systems consume not only third-party code dependencies but also foundation models, plugins, tool servers, and data retrieval sources. Agents that invoke APIs, query databases, or generate code create new potential injection surfaces at tool boundaries. AI-specific controls must be additions to this foundational security, not replacements for it.
Principle 3: Deterministic external controls are the starting point for agentic security. This is the most important architectural principle for agentic AI security. Organizations should enforce security through deterministic, infrastructure-level controls external to the agent’s reasoning loop, not through the agent’s own reasoning, internal guardrails, or prompt-based instructions. The logic is straightforward. LLMs are probabilistic reasoning engines, not security enforcement mechanisms. Developers can instruct an LLM to refuse certain requests, but prompt injection techniques can override those instructions. An LLM can be told to respect access boundaries, but it has no reliable mechanism to enforce them. Attempting to constrain agent behavior only through prompting or alignment runs against the fundamental value proposition of agents, which is their ability to adapt dynamically to novel situations.
Effective security places fully specified, deterministic controls outside the agent that govern which tools it can access, what operations it can perform, and what data it can reach. Model manipulation cannot bypass these controls. We describe this as the security box. It’s external to the agent, deterministic in its enforcement, and comprehensive in its coverage. Every interaction between the agent and the outside world passes through it. The Agentic AI Security Scoping Matrix helps organizations calibrate the rigor of these controls based on their system’s autonomy level. Scopes range from systems that require explicit human approval before every action to fully autonomous systems that initiate their own activities based on external events.
The security box isn’t a limitation on the agent’s value. It’s the precondition for achieving that value responsibly. As agentic technology matures, the box itself will likely evolve to include agentic elements. Specialized AI agents designed to control the scope of other agents might replace some deterministic constraints over time, using new information and context to make more appropriate automated decisions than could be achieved by humans managing complex deterministic controls.
Principle 4: Greater autonomy should be earned through ongoing evaluation. Organizations should expand agent autonomy progressively based on demonstrated performance, not grant it by default. The starting point is human decision-making for high-consequence operations. When an agent encounters an action that could modify high-value production data, initiate financial transactions, or communicate sensitive information externally, a human makes the final decision. The agent recommends, and a human approves or rejects.
This approach carries a well-known risk. If every agent action requires human approval, the volume of decisions might overwhelm reviewers. Approval becomes reflexive rather than deliberate, shifting liability to humans who have been placed in a position to fail. Organizations must scope human oversight to genuinely high-consequence operations and resist the temptation to require human-in-the-loop designs for routine actions that carry low risk.
The path from human oversight to expanded autonomy runs through evaluation. As organizations systematically record what the agent recommended, what the human decided, and what actually happened, they build the evidence base for expanding autonomy. When data shows sustained alignment, organizations can shift from prior approval to after-the-fact review, and eventually to full autonomy for specific operation types. This progression should happen at the operation or workflow level, not across a broad range of unrelated tasks.
This progression isn’t one-way. Organizations should be prepared to reintroduce human oversight when evidence warrants it. Some deterministic boundaries likely remain permanent for the foreseeable future. These boundaries exist not because the agent hasn’t earned trust, but because the consequences of certain actions are unacceptable under a reasonable risk analysis. The overall model is one of earned autonomy through demonstrated competence, governed by evaluation, bounded by permanent constraints, and subject to continuous review. There might come a time with specialized boundary agents can provide better outcomes than purely deterministic controls, but that option can only emerge over time from experience and evaluation.
From principles to practice
The four principles define the goals. Achieving them requires specific architectural building blocks that compose the security box and the broader security architecture. Our response to NIST described these building blocks in greater detail. Here we provide a summary. AWS has implemented them in Amazon Bedrock AgentCore, a framework for building, deploying, and operating agentic AI systems with security built in from the ground up.
Compute isolation. Agent compute environments must isolate execution, prevent cross-agent data leakage, and contain agents within defined boundaries. Amazon Bedrock AgentCore runs agents on Firecracker, an open source virtual machine manager written in Rust. Firecracker provides lightweight micro-VMs backed by Linux KVM and hardware-based virtualization, delivering the speed of containers with the isolation properties of full virtual machines. Key security-critical elements of Firecracker have been formally verified by AWS teams, adding assurance beyond the memory safety that Rust provides.
Identity and access management. Agents require their own identities, secure credential storage, and least-privilege authorization enforced at the infrastructure level. AgentCore Identity provides machine identities for agents, manages OAuth and secure credential flows, and integrates with AWS Identity and Access Management (IAM) for fine-grained access control. It supports attribute-based access control and maintains traceable delegation chains so that the relationship between agent actions and the invoking user remains auditable.
Tool access and policy enforcement. Every tool an agent can access expands both its usefulness and its potential risk. Managing tool access individually across agents creates an unmanageable combinatorial explosion. AgentCore Gateway acts as a centralized intermediary between agents and tools, enforcing authentication and authorization at a single control point. It can inspect tool calls down to individual parameters, not just at the API level. AgentCore Policy, built on the open source Cedar authorization language, adds formally verified policy enforcement. Teams can author Cedar policies in natural language and then review them, combining the flexibility of LLMs with the rigor of formal methods.
Observability. Observability infrastructure must capture sufficient context for real-time monitoring and investigation, and it must be protected from the agents it monitors. Organizations wouldn’t allow employees to edit their own audit logs, and the same principle applies to agents. AgentCore provides observability through the AgentCore Gateway, session-level telemetry, and detailed traces that record internal state changes. These capabilities can extend to agents running outside of AgentCore as well.
Model execution environment. The security of the model execution environment matters as much as the security of the agent itself. Amazon Bedrock runs models in isolated network environments where neither AWS nor model providers access customer prompts and responses. When customers enable logging, those logs are encrypted at rest and protected by customer-managed encryption keys. This architectural isolation is a key reason government and enterprise customers have adopted Amazon Bedrock.
Deterministic external controls are complemented by controls within the AI processing loop. Amazon Bedrock Guardrails inspects prompts and responses using small AI models called classifiers that address challenges such as prompt injection. Automated Reasoning checks go further, so that developers can create a formal model of a knowledge domain and verify that LLM output conforms to it, producing results that are deterministic and provably correct.
Looking ahead
Agentic AI changes how software operates, but the security response builds on decades of established practice. Existing frameworks provide the right foundation. The task is to extend existing frameworks for agent-specific considerations. Organizations should apply secure development lifecycle practices to AI components and maintain traditional security controls. They should enforce security through deterministic controls external to the agent and earn greater autonomy through systematic evaluation.
These principles aren’t theoretical. They reflect the operational experience AWS has gained building and operating agentic AI services. They’re embedded in how we design our infrastructure. As NIST develops guidance based on industry input, we will continue to invest in helping customers build and operate agentic AI systems with confidence.
Since software updates to already-FCC-approved devices do not
require a new FCC approval, it appears the FCC is trying to move
beyond its usual authorization procedures to restrict what
manufacturers are allowed to push to existing routers. However, the
FCC notably does not restrict software changes made by owners of
routers in the U.S. In particular, there is no indication that updates
people make to their own routers, using software they have sourced
themselves, would run afoul of any past or present FCC rule.
As a result, we do not believe that this new FCC decision affects
whether and how people can run OpenWrt or other user-selected firmware
updates on routers they have already purchased. Not only is this an
important right in relation to our ownership and control of our own
devices, it also ensures that people can keep their routers secure for
far longer than the manufacturer may choose to provide security
updates, by allowing them to install up-to-date community software
that supports routers for 10, 15, or even more years after their
initial release date, as OpenWrt does for many devices.
He also notes that, as the OpenWrt One is already FCC-approved,
there should be no impact on its availability in the US. The SFC has
asked the FCC for clarification and plans to provide updates when they
receive a reply.
This is for new routers; you don’t have to throw away your existing ones:
The Executive Branch determination noted that foreign-produced routers (1) introduce “a supply chain vulnerability that could disrupt the U.S. economy, critical infrastructure, and national defense” and (2) pose “a severe cybersecurity risk that could be leveraged to immediately and severely disrupt U.S. critical infrastructure and directly harm U.S. persons.”
Any new router made outside the US will now need to be approved by the FCC before it can be imported, marketed, or sold in the country.
In order to get that approval, companies manufacturing routers outside the US must apply for conditional approval in a process that will require the disclosure of the firm’s foreign investors or influence, as well as a plan to bring the manufacturing of the routers to the US.
Certain routers may be exempted from the list if they are deemed acceptable by the Department of Defense or the Department of Homeland Security, the FCC said. Neither agency has yet added any specific routers to its list of equipment exceptions.
[…]
Popular brands of router in the US include Netgear, a US company, which manufactures all of its products abroad.
One exception to the general absence of US-made routers is the newer Starlink WiFi router. Starlink is part of Elon Musk’s company SpaceX.
Presumably US companies will start making home routers, if they think this policy is stable enough to plan around. But they will be more expensive than routers made in China or Taiwan. Security is never free, but policy determines who pays for it.
If you manage Apache Kafka today, you know the effort required to manage topics. Whether you use infrastructure as code (IaC) solutions or perform operations with admin clients, setting up topic management takes valuable time that could be spent on building streaming applications.
Amazon Managed Streaming for Apache Kafka (Amazon MSK) now streamlines topic management by supporting new topic APIs and console integration. You can programmatically create, update, and delete Apache Kafka topics using familiar interfaces including AWS Command Line Interface (AWS CLI), AWS SDKs, and AWS CloudFormation. With these APIs, you can define topic properties such as replication factor and partition count and configuration settings like retention and cleanup policies. The Amazon MSK console integrates these APIs, bringing all topic operations to one place. You can now create or update topics with a few selections using guided defaults while gaining comprehensive visibility into topic configurations, partition-level information, and metrics. You can browse for topics within a cluster, review replication settings and partition counts, and go into individual topics to examine detailed configuration, partition-level information, and metrics. A unified dashboard consolidates partition topics and metrics in one view.
In this post, we show you how to use the new topic management capabilities of Amazon MSK to streamline your Apache Kafka operations. We demonstrate how to manage topics through the console, control access with AWS Identity and Access Management (IAM), and bring topic provisioning into your continuous integration and continuous delivery (CI/CD) pipelines.
Prerequisites
To get started with topic management, you need:
An active AWS account with appropriate IAM permissions for Amazon MSK.
An existing Amazon MSK Express or Standard cluster using Apache Kafka version 3.6 and above.
Basic familiarity with Apache Kafka concepts like topics, partitions, and replication.
AWS CLI installed and configured (for command line examples).
Creating topics
The MSK console provides a guided experience with sensible defaults while still offering advanced configuration options when you need them.
Enter a topic name (for example, customer-orders).
Specify the number of partitions (use the guided defaults or customize based on your needs).
Set the replication factor. Note that Express brokers improve the availability and durability of your Amazon MSK clusters by setting values for critical configurations and protecting them from common misconfiguration. If you try to create a topic with a replication factor value other than 3, Amazon MSK Express will create the topic with a replication factor of 3 by default.
(Optional) Configure advanced settings like retention period or message size limits.
Choose Create topic.
The console validates your configuration and creates the topic. You can create multiple topics simultaneously with the same configuration settings. These topic API responses reflect data that updates approximately every minute. For the most current topic state after making changes, wait approximately one minute before querying.
Configuration considerations
When choosing configuration options, consider your workload requirements:
With Standard brokers you can improve durability by configuring higher replication factors, though this will increase your storage costs. Refer to “Build highly available clusters” in Best practices for Standard brokers for more information on replication factors.
Standard brokers support the full range of Apache Kafka topic configurations.
After you create topics, the MSK console provides comprehensive visibility into their configuration. When you select a specific topic, you will see detailed information:
Partitions tab: Shows the distribution of partitions across brokers, including leader assignments and in-sync replica status showcasing Broker IDs for leader and replicas.
Configuration tab: Displays all topic-level configuration settings.
Monitoring tab: Integrates with Amazon CloudWatch to show metrics like bytes in/out, message rates, and consumer lag.
Updating topic configurations
As your workload requirements evolve, you might need to adjust topic configurations. You can modify various topic settings depending on your cluster type. For example:
Retention settings: Adjust retention.ms (time-based) or retention.bytes (size-based) to control how long messages are retained.
Message size limits: Modify max.message.bytes to accommodate larger or smaller messages.
Compression: Change compression.type to optimize storage and network usage.
Configuration changes take effect immediately for new messages. Existing messages remain subject to the previous configuration until they age out or are consumed.
Deleting topics
Amazon MSK also provides APIs for deleting topics that are no longer in use. Before deleting a topic, verify that:
No active producers are writing to the topic
All consumers have finished processing messages
You have backups if you need to retain the data
Downstream applications won’t be impacted
Important: Topic deletion permanently removes all messages in the topic.
Control access with IAM
Beyond streamlining topic operations, you also need appropriate access controls. Access control uses IAM, so you define permissions using the same model that you apply to other AWS resources. Amazon MSK uses a two-level permission model:
Resource-level permissions: An IAM policy that enforces which operations the cluster will allow
Principal-level permissions: IAM policies attached to Roles or Users that enforce which operations a principal is allowed to perform on a cluster
With this separation, you can control access depending on your organizational needs and access patterns for your cluster. Refer to the IAM permissions documentation for IAM permissions required for topic management for the Amazon MSK cluster.
You can grant your operations team broad access to manage all topics and restrict application teams to manage only their own topics. The permission granularity that you need is available through standard IAM policies. If you’ve already configured IAM permissions for Apache Kafka topics, they work immediately with the new functionality without any migration or reconfiguration.
Here is a sample IAM policy definition that allows Describe Topic API
The policy is scoped to a specific cluster ARN and applies to all topics within that cluster using the wildcard pattern /*. Replace the placeholder Amazon MSK cluster ARN with your MSK cluster ARN.
Infrastructure as Code
If you manage infrastructure as code (IaC), you can now define topics alongside clusters in your CloudFormation templates:
This approach brings topic provisioning into your CI/CD pipelines.
Availability and pricing
The new Amazon MSK topic management experience is available today for Standard and Express Amazon MSK clusters using Apache Kafka version 3.6 and above in all AWS Regions where Amazon MSK is offered, at no additional cost.
Cleanup
To avoid incurring additional charges to your AWS account, ensure you delete all resources created during this tutorial, including:
Amazon MSK cluster
Any Kafka topics created
Associated AWS resources (security groups, VPCs, etc., if created specifically for this blog)
Remember to verify that all resources have been successfully removed to prevent ongoing costs.
Conclusion
Topic management has been a persistent pain point for Apache Kafka operations. The new integrated experience in Amazon MSK now reduces operational friction by bringing topic operations into the AWS tools that you use every day. You now have a consistent, streamlined way to handle these operations for all Apache Kafka topics across multiple MSK clusters. This capability reflects our commitment to reducing operational complexity in Apache Kafka. You get the reliability and performance of Apache Kafka without the operational overhead that traditionally comes with it. Your team spends less time on infrastructure maintenance and more time building streaming applications that drive your business forward.
Ready to start streamlining your topic management? Start managing your topics today through the Amazon MSK console or by visiting the Amazon MSK documentation.
Organizations are finding significant value using an integrated experience for all your data and AI with Amazon SageMaker Unified Studio. However, many organizations require strict network control to meet security and regulatory compliance requirements like HIPAA or FedRAMP for their data and AI initiatives, while maintaining operational efficiency.
In this post, we explore scenarios where customers need more control over their network infrastructure when building their unified data and analytics strategic layer. We’ll show how you can bring your own Amazon Virtual Private Cloud (Amazon VPC) and set up Amazon SageMaker Unified Studio for strict network control.
Solution overview
The solution covers complete technical know-how of a fully private network architecture using Amazon VPC with no public internet exposure. The approach leverages AWS PrivateLink through VPC endpoints to provide a secure communication between SageMaker Unified Studio and essential AWS services entirely over the AWS backbone network.
The architecture consists of three core components: a custom VPC named airgapped with multiple private subnets distributed across at least three Availability Zones for high availability, a comprehensive set of VPC interface and gateway endpoints for service connectivity, and the SageMaker Unified Studio domain configured to operate exclusively within this isolated environment. This design helps ensure that sensitive data never traverses the public internet while maintaining full functionality for data cataloging, query execution, and machine learning workflows.
By implementing this air-gapped configuration, organizations gain granular control over network traffic, simplified compliance auditing, and the ability to integrate SageMaker Unified Studio with existing private data sources through controlled network pathways. The solution supports both immediate operational needs and long-term scalability through careful IP address planning and modular endpoint architecture.
Prerequisites
The set up requires you to have an existing VPC (for this post, we’ll refer to the name as airgapped but in reality, it refers to the VPC you would like to securely set up SageMaker Unified Studio). If you don’t have an existing VPC, you can follow SageMaker Unified Studio domain quick create administrator guide to get started.
The high level steps to create a VPC meeting minimum requirements for SageMaker Unified Studio are as follows:
Once the domain is created, choose Open unified studio or use SageMaker Unified Studio URL under Domain details to access SageMaker Unified Studio.
Figure 2 – Amazon SageMaker Unified Studio URL Welcome Page
After logging in to SageMaker Unified Studio, create a project using the guided wizard.
Once the project is created, we need to add the necessary VPC endpoints to allow traffic from the project to communicate to AWS services.
S3 Gateway VPC endpoint was already selected as part of VPC creation step 5 in prerequisites and thus created by default. Now we must add two more VPC endpoints for Amazon DataZone and AWS Security Token Service as illustrated in following step.
These are the minimum set of VPC endpoints to allow using the tooling within SageMaker Unified Studio. For a list of other mandatory and non-mandatory VPC endpoints refer to the tables in the latter part of this post.
Create an interface endpoint
To create an interface endpoint, complete following steps:
Go to the SageMaker Unified Studio Project details page and copy the Project ID. Figure 3 – SageMaker Unifed Studio Project Details Page
Go to the VPC console and choose Endpoints.
Choose Create Endpoint.
Enter a name for the endpoint, for example, DataZone endpoint for SageMaker Unified Studio.
For AWS Services, enter DataZone.
Figure 4 – Interface Endpoint creation wizard for AWS Service datazone
Select Service Name = com.amazonaws.us-east-1.datazone from the available options.
Select the subnets in the airgapped-vpc that you created earlier.
Filter the Security Groups by pasting the copied Project ID.
Select the security group with Group Namedatazone-<project-id>-dev.
Choose Create Endpoint.
Repeat the same steps to create a VPC endpoint for AWS STS.
Once the VPC endpoints are created, validate connectivity in the SageMaker project by running a SQL query or using a Jupyterlab notebook.
For a successful domain and project which does not get into any service level usage, the mandatory VPC endpoints to be created are: S3 Gateway, DataZone, and STS interface endpoints. For other service usage dependent operations like authentication, data preview and working with compute, you would require other mandatory service specific endpoints explained later in this post.
Best practices for VPC set up for various use cases
When setting up SageMaker Unified Studio domain and project profiles, you need to specify the VPC network, subnets, and security groups. Here are some best practices around IP allocation, usage volume and expected growth to consider for different use cases within enterprises.
Production and enterprise use cases
If your organization require strict network control to meet security and compliance requirements for data and AI initiatives, consider following best practices in your production environment.
Use the bring-your-own (BYO) VPC approach to comply with company-specific networking and security requirements.
Implement private networking using VPC endpoints to keep traffic within the AWS backbone.
Use at least two private subnets across different Availability Zones.
Enable DNS hostnames and DNS Support.
Disable auto-assign public IP on subnets.
Plan IP capacity for at least 5 years. A prescriptive guidance for SageMaker Unified Studio is shared in VPC and Networking details section later in this post. Consider the following:
Number of users
Number of apps per user
Number of unique instance types per user
Average number of training instances
Expected growth percentage
Testing and non-production use cases
For development, testing, non-prod environment where use cases don’t have stringent security and compliance requirements, use automated setup for quick experiments. Use sample CloudFormation github templates as part of the SageMaker Unified Studio express set up, to automate domain and project creation. However, this includes an Internet Gateway which may not be suitable for security-sensitive environments.
Private networking use cases
VPCs with private subnets require essential service endpoints to allow client resources like Amazon EC2 instances to securely access AWS services. The traffic between your VPC and AWS services remains within AWS network avoiding public internet exposure.
Implement all mandatory VPC endpoints for core services (SageMaker, DataZone, Glue, and more).
Add optional endpoints based on specific service needs, like IPv4 endpoints, dual-stack endpoints, and FIPS endpoints to programmatically connect to an AWS service.
Work with network administrators for:
Preinstalling needed resources through secure channels like private subnets and self-referencing inbound rules in security groups to enable limited access.
Allowlisting only necessary external connections like NAT gateway IP and bastion host access in firewall rules.
Setting up appropriate proxy configurations if required.
External data source access use cases
Consider the following when working with external systems like third-party SaaS platforms, on-premises databases, partner APIs, legacy systems, or external vendors.
Consult with network administrators for appropriate connection methods.
Consider AWS PrivateLink integration where available.
Implement appropriate security measures for non-AWS data your source documents.
For High Availability:
Deploy across at least three different Availability Zones (at least two for AWS Regions with only two AZs).
Verify there’s a minimum of three free IPs per subnet.
Consider larger CIDR blocks (/16 recommended) for future scalability.
VPC and networking details
In this section, we provide details of each networking aspect starting with choice of VPCs, network connectivity details for integrated services to work, the basis of VPC and subnet requirements, and finally the VPC endpoints required for private service access.
VPC
At a high level, you have two options to supply VPCs and subnets:
Bring-your-own (BYO) VPC. This is typically the case for most customers, as most have company specific networking and security requirements to reuse an existing VPC, or to create a VPC that are compliant with those requirements.
Create VPC with the SageMaker quick set up template. When creating a SageMaker Unified Studio domain (DataZone V2 domain in CloudFormation) through the automated quick set up, you will be shown a Quick create stack wizard in CloudFormation which creates VPCs and subnets used to configure your domain.
Note: The quick create stack using template URL is not intended for production use. The template creates an Internet Gateway, which is not allowed in many enterprise settings. This is only appropriate if you are either trying out SageMaker Unified Studio or, running SageMaker Unified Studio for use cases that don’t have stringent security requirements.If you choose this option, you start with SageMaker console, navigate to domains and click Create domain button, followed by Create VPC button. You will navigate to CloudFormation and click on Create stack button to create a sample VPC named SageMakerUnifiedStudio-VPC with just one-click for trying out SageMaker Unified Studio.
Figure 6 – Create VPC button in SageMaker Unified Studio Create Domain Wizard
Cost estimation for recommended VPC set up
The exact cost depends on the configuration of your VPC. For more complex networking set ups (multi-VPC), you may need to use additional networking components such as a Transit Gateway, Network Firewall, and VPC Lattice. These components may incur charges, and cost depends on usage and AWS Region. Interface VPC endpoints are charged per availability zone. They also have a fixed and a variable component in the pricing structure. Use the AWS Pricing Calculator for a detailed estimate.
Network Connectivity
With regards to connectivity to the underlying AWS services integrated within SageMaker Unified Studio, there are two ways to enable connectivity (these are not Studio specific, these are standard ways to enable network connectivity within a VPC). This is an important security consideration that depends on your organization’s security policies.
Through the public Internet. Your traffic will traverse over the public Internet through an Internet Gateway in your VPC.
Your public subnet must have a NAT Gateway. In addition, your public subnet’s route table must have a default route (0.0.0.0 for IPv4) to the Internet Gateway. This route is what makes the subnet public.
Your private subnets must have a default route to the public subnet’s NAT Gateway.
Through the AWS backbone. Your traffic will remain within the private AWS backbone through PrivateLink (by provisioning Interface and Gateway endpoints for the necessary AWS services in each Availability Zone).
A list of all the AWS services integrated into Studio and the VPC endpoints required can be found in section VPC Endpoints covered later in this post.
For non-AWS resources, certain external providers of these services may offer PrivateLink integration. Check with each provider’s documentation and your network administrator to understand the most suitable way to connect to these external providers.
In a private networking scenario, you will need to consider whether you need connectivity to non-AWS resources in a way that’s compliant with your organization’s security policies. A few examples include the following:
If you need to download software in your remote IDE host (for example, command line programs, such as Ping and Traceroute)
If you have code that connects to external APIs.
If you use software (such as JupyterLab or Code Editor extensions) that rely on external APIs.
If you depend on software dependencies hosted in the public domain (such as Maven, PyPi, npm)
If you need cross-Region access to certain resources (such as access to S3 buckets in a different Region)
If you need functionality whose underlying AWS services do not have VPC endpoints in all Regions or any Region.
If you need to connect to data sources outside of AWS (such as Snowflake, Microsoft SQL Server, Google BigQuery) Enterprise network administrators must also complete either of the following prerequisites to handle private networking scenarios:
Preinstall needed resources through secure channels if possible. An example would be to customize your SageMaker AI image by installing dependencies, after they are code scanned, vetted technically and legally by your organization.
If AWS PrivateLink integration is not available for external providers, allowlist network connections to these external sources. Allow firewall egress rules, directly or indirectly, through a proxy in your organization’s network. Check with your network administrator to understand the most appropriate option for your organization.
VPC Requirements
When setting up a new SageMaker Unified Studio Domain, it’s necessary to supply a VPC. It’s important to note that these VPC requirements are a union of all the requirements from the respective compute services integrated into Studio, some of which are reinforced by validation checks during the corresponding blueprint’s deployment. If these requirements that have validation checks are not fulfilled, the resource(s) contained in that blueprint may fail to create on project creation (on-create), or when creating the compute resource (on-demand). This section will present a summary of these requirements, as well as relevant documentation links from which they originate.
Subnet requirements for specific compute in a VPC
This section lists the compute services integrated in SageMaker Unified Studio that require VPC/subnets when provisioning the respective compute resources.
Number of subnets: At least two private subnets. This requirement comes from Redshift Serverless.
Availability zones (AZs): At least two different AZs (for Regions with two AZs, two subnets are sufficient). This requirement comes from Redshift Serverless. For workgroups with Enhanced VPC Routing (EVR), you need three AZs.
Free IPs per subnet: At least three Ips per subnet. This requirement comes from Redshift Serverless without EVR. For detailed IP addresses requirement with EVR enabled workgroups, refer to Serverless usage considerations. Three is a minimum and may not be enough for your needs. For example, EMR cluster creation will fail if no subnets with enough IPs are found in the VPC. We recommend doing a forward-looking capacity planning exercise based on your use cases (for example, growth rate, users, compute needs) to project at least 5 years into the future. This helps to determine how many IPs are needed by the team using Studio and other services that use this VPC and come up with a ceiling for the CIDR block size.
Private or public subnets: We enforce that at least three private subnets be supplied, and recommend that only private subnets are chosen, with a few nuances. This requirement comes from SageMaker AI domain. A new SageMaker AI domain, when set up with VpcOnly mode, requires that all subnets in the VPC be private. This is the default networking mode in the Tooling blueprint. If you choose to use PublicInternetOnly mode, this restriction does not apply, you may choose public subnets from your VPC. To change the mode, modify the Tooling Blueprint parameter sagemakerDomainNetworkType.
Enable DNS hostname and DNS Support: Both must be enabled. This requirement comes from EMR. Without these VPC settings, enableDnsHostname and enableDnsSupport, connecting to the EMR Cluster using the private DNS name through the Livy Endpoint will fail. SSL Verification, which can only be done when connecting using the DNS name, not the IP.
Auto assign public IP: Disable. We recommend that this EC2 subnet setting (mapPublicIpOnLaunch) be disabled when using private subnets, because public IPs come at a cost and are a scarce resource in the total addressable IPv4 space.
VPC endpoints
If you choose to run SageMaker Unified Studio without public internet access, VPC endpoints are required for all services SageMaker Unified Studio needs to access. These endpoints provide secure, private connectivity between your VPC and AWS services without traversing the public internet. The following table lists the required endpoints, their types, and what each is used for.
Some endpoints may not show up directly in your browser’s network tab. The reason is that some of these services (such as CloudWatch) are transitively invoked by other services.
Mandatory endpoints
The following are required endpoints for SageMaker Unified Studio and supporting services to function properly. Gateway endpoints can be used where available, you can use interface endpoints for all other AWS services.
AWS service
Endpoint
Type
Purpose
Glue
com.amazonaws.${region}.glue
Interface
For Data Catalog and metadata management
STS
com.amazonaws.${region}.sts
Interface
Required for assuming IAM roles
S3
com.amazonaws.${region}.s3
Gateway
Required for datasets, Git backups, notebooks, and Git sync
SageMaker
com.amazonaws.${region}.sagemaker.api
Interface
Required for calling SageMaker APIs
com.amazonaws.${region}.sagemaker.runtime
Interface
For invoking deployed inference endpoints
DataZone
com.amazonaws.${region}.datazone
Interface
For data catalog and governance
Secrets Manager
com.amazonaws.${region}.secretsmanager
Interface
To securely access secrets
SSM
com.amazonaws.${region}.ssm
Interface
For secure command execution
com.amazonaws.${region}.ssmmessages
Interface
Enables live SSM sessions
KMS
com.amazonaws.${region}.kms
Interface
For decrypting data (volumes, S3, secrets)
EC2
com.amazonaws.${region}.ec2
Interface
For subnet and ENI management
com.amazonaws.${region}.ec2messages
Interface
Required for SSM messaging
Athena
com.amazonaws.${region}.athena
Interface
Required to run SQL queries
Amazon Q
com.amazonaws.${region}.q
Interface
Used by SageMaker Notebooks for enhanced productivity
Optional Endpoints
Only create these if the corresponding service is used in your environment.
AWS resources provisioned in your AWS accounts may incur costs based on the resources consumed. Make sure you do not leave any unintended resources provisioned. If you created a VPC and subsequent resources as part of this post, make sure you delete them.
The following service resources provisioned during this blog post need to be deleted:
IAM Identity Center users and groups.
Resources provisioned within your project using tooling configuration and blueprints within your domain.
The airgapped VPC.
Conclusion
In this post, we walked through the process of using your own existing VPC when creating domains and projects in SageMaker Unified Studio. This approach benefits customers by giving them greater control over their network infrastructure while using the comprehensive data, analytics, and AI/ML capabilities of Amazon SageMaker. We also explored the critical role of VPC endpoints in this set up. You now understand when these become necessary components of your architecture, particularly in scenarios requiring enhanced security, compliance with data residency requirements, or improved network performance.
While using a custom VPC requires more initial set up than the Quick Create option, it provides the flexibility and control many organizations need for their data science and analytics workflows. This approach provides a mechanism for your SageMaker environment to integrate with your existing infrastructure and adheres to your organization’s networking policies. Custom VPC configurations are a powerful tool in your arsenal for building secure, compliant, and efficient data science environments.
The kernel provides a number of ways for processes to communicate with each
other, but they never quite seem to fit the bill for many users. There are
currently a few proposals for interprocess communication (IPC) enhancements
circulating on the mailing lists. The most straightforward one adds a new
system call for POSIX message queues that enables the addition of new
features. For those wanting an entirely new way to do interprocess
communication, there is a proposal to add a new subsystem for that purpose
to io_uring. Finally, the bus1 proposal has made a return after ten years.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Figure 3 – SageMaker Unifed Studio Project Details Page
