Невидимият премиер

Post Syndicated from Емилия Милчева original https://www.toest.bg/nevidimiyat-premier/

Невидимият премиер

Европейският тур на Румен Радев със сигурност доказа едно – вторият Орбан още не се e родил, след като първият вече е история. Българският премиер не е политикът на големите битки, нито притежава политическата тежест и решителност за открит бунт срещу Европейския съюз. 

Първата му обиколка в чужбина като премиер показа, че е достатъчно умерен, за да е приемлив за Брюксел, но и критичен, за да запази образа си пред евроскептичната публика в България. Той имаше срещи с френския президент Макрон, с генералния секретар на НАТО Марк Рюте, с председателя на Европейската комисия Урсула фон дер Лайен и на Европейския съвет – Антонио Коща.

Радев не е човекът на големия разрив, а на голямото „да, но“. 

Да, България е част от ЕС, но не бива да помага на Украйна. Най-напред да гарантира стандарта на живот и сигурността на българските граждани и след това може да отделя средства за въоръжаване на чужди армии.

Да, Русия е проблем, но Европа трябвало „да преговаря“ и да бъде водеща. 

Европа трябваше да бъде водеща в тези преговори, да не допуска те да се изземват като инициатива от други, трети играчи. Това е важната мисия на Европа. Това, което лично мен ме притеснява, това е стремежът на Европа да постигне конвенционална победа над най-голямата ядрена сила, без да има възможности да прихваща и да противостои на съвременните хиперзвукови оръжия. Това е сериозен риск. Трябва да има смяна на цялостната политика на Европа по отношение на конфликта в Украйна. 

Тези изявления на Радев след срещата му с президента Макрон в Елисейския дворец звучат като „реторика за вътрешна употреба“, по определението на анализатора Веселин Желев. 

Във френските медии, отбелязва Желев, няма нито една публикация, нито един репортаж, нито дори кратка бележка за визитата на българския премиер. Радев е невидим за France-Presse, както и за водещите всекидневници и седмичници – Le Monde, Le Figaro, Libération, Journal du Dimanche, Le Point, L’Express – плюс сайтовете на основните телевизионни канали и France 24

Радев, ще удряш ли с юмрука?
Абсолютното мнозинство дава възможност за бързи решения без оправдания. Първият тест е кадровият – ВСС, главен прокурор, регулатори. От него ще се види към обещаната промяна ли се върви, или „юмрукът“ ще пренарежда същата система с други лица. От Емилия Милчева.
Невидимият премиер

В България обаче социологическата агенция „Маркет Линкс“ измери рекордните 56% одобрение за Румен Радев – компенсация за френското пренебрежение, на фона на 77% неодобрение за лидера на ГЕРБ Бойко Борисов.

В Брюксел и Париж Радев всъщност повтори една и съща политическа формула: България е лоялна на ЕС и НАТО, но Европа греши в най-важния си геополитически избор. Според президента континентът е избрал да търси „мир чрез сила“, да инвестира в превъоръжаване и дългосрочна подкрепа за Украйна вместо в преговори. Позиция, която той следва през последните години.

С Урсула фон дер Лайен Радев говори за върховенство на закона, за борба с корупцията и общи европейски решения. Тя пък, освен новината за размразените 370 млн. евро по Плана за възстановяване и устойчивост, отбеляза, че разчита на българската подкрепа за Украйна, както и за противодействие на хибридните атаки срещу ЕС.

В НАТО Румен Радев подчерта българския принос към сигурността на Алианса. Абсурдизмът в позициите му е, че поставя под съмнение самата логика на европейската политика към Украйна, а в същото време е повече от ентусиазиран за още инвестиции в отбраната и за развитие на потенциала на военната индустрия, в това число чрез инструмента SAFE.

Двойни стандарти

Симпатизантите на Радев не улавят тези противоречия. В действителност България е облагодетелствана от продължаващата четвърта година война в Украйна, взела близо 2 милиона жертви от двете страни.

За периода 2022–2025 г. военнопромишленият комплекс e изнесъл оръжие за над 6,65 млрд. евро. Въоръжението и боеприпасите са около 5,5% от целия експорт. Зад тези цифри стоят хиляди нови работни места и заплати, което пък означава ръст на потреблението и подкрепа и за други сектори на икономиката.

България укрепва отбранителните си способности, модернизирайки армията си. Постигната е целта за инвестиции в отбраната, равни на 2% от БВП и се върви към повишаване до 5%, потвърди самият Радев, бивш главнокомандващ Военновъздушните сили, преди да бъде избран за президент.

Мълчанието на Радев струва злато
Наблюдаваме феномена „Румен Радев на Шрьодингер“. Докато мълчи, той едновременно е срещу корупцията и мафията в правосъдието, за диалог с Русия, против еврото, за ЕС… Това ще свърши с обявяването на партийните му листи. И после? Коментар от Емилия Милчева.
Невидимият премиер

Специално внимание заслужава инструментът SAFE, който предвижда до 150 млрд. евро заеми за общи военни поръчки, развитие на европейската отбранителна индустрия и намаляване на зависимостта от американско оръжие.

Украйна не може да взема заеми по програмата „Действие за сигурност за Европа“, но пък е изцяло асоциирана със SAFE. Нейни компании могат да участват в производството и доставките. За да бъде финансиран даден проект, европейските правила изискват крайният продукт (например боеприпаси или бронирана техника) да съдържа поне 65% компоненти, произведени в ЕС, Европейската асоциация за свободна търговия или Украйна. 

Полша води инициативата с одобрен мащабен национален план на стойност 43,7 млрд. евро за 139 отбранителни проекта. Като гранична държава, голяма част от нейните съвместни поръчки са насочени към укрепване на източния фланг и интеграция с украинското производство.

Румъния се нарежда на второ място по обем на финансиране с одобрен план за 17 млрд. евро. Тя играе критична логистична и производствена роля в проектите, свързани с Украйна.

Балтийските държави (Естония, Латвия и Литва) първи получиха одобрение за своите планове и настояват за съвместни поръчки на артилерия и дронове, в които украинските компании участват като подизпълнители. България ще вземе 3,261 млрд. евро нисколихвени заеми по SAFE, като част от тези средства ще бъдат насочени към съвместно дружество между германския концерн Rheinmetall и държавните ВМЗ – Сопот. Целта е изграждане на завод за производство на 155-милиметрови артилерийски снаряди и барут по стандартите на НАТО.

Как неподкрепата за Украйна се съчетава с ползите от войната – икономически, индустриални и стратегически, е тема, която Радев не коментира. Защото България едновременно печели от европейското превъоръжаване, разширява военната си индустрия, модернизира армията си с европейски средства и участва в общата отбранителна архитектура на ЕС. В същото време премиерът продължава да говори така, сякаш подкрепата за Украйна е чужд, наложен отвън проект. 

Политиката, която демонстрира при срещите си с европейските лидери, не е на открит конфликт с ЕС, а постепенно отстъпление с внушението, че европейската решителност е опасна, а европейската солидарност – прекалено скъпа. 

Абсолютното мнозинство, което спечели в България обаче, притъпява остротата на политическите реакции. Липсваха коментари от парламентарно представените политически сили, с изключение на „Да, България“, част от „Демократична България“.

Не Украйна започна войната, а Русия, и не Украйна и Европа отказват преговори, както казва Румен Радев, но Русия иска капитулация… Ако не само символно, но и реално Радев започне да откъсва България от сърцето на Европа и застане срещу българския интерес, ще реагираме светкавично и остро.

Божидар Божанов, съпредседател на „Да, България“, пред Дарик радио

Засега премиерът показва двойни стандарти. От една страна, казва сбогом на оръжията за Украйна, от друга, одобрява инвестициите в отбрана, но не се осмелява да защити тази сигурност с ясна политическа позиция. Иска ЕС да плаща цената на сигурността си, без да има смелостта да назове откъде идва заплахата. 

Затова остава невидим за Европа и толкова удобен у дома.

Гласовете на Америка – брой 15

Post Syndicated from Йоанна Елми original https://www.toest.bg/glasovete-na-amerika-broy-15/

Гласовете на Америка – брой 15

Пролетта във Филаделфия е необичайно красива с топлите си кехлибарени изгреви и залези, с бързо преминаващите облаци, които понякога се превръщат в също толкова бързо преминаващи бури. С първите майски гръмотевици – точно като в София. Из улиците се веят транспаранти в чест на 250-годишнината от създаването на САЩ. Атмосферата е особено празнична в старата столица, където е подписана Декларацията за независимостта

Орди туристи се стичат не само от цял свят, но и от всички краища на Америка. Навсякъде има обяви за изложби и чествания. Когато се качвам в самолета от София, малко преди нас излитат няколко от черните самолети с надпис U.S. Airforce, които домуват на летище „Васил Левски“ от седмици насам. Накъде – мога само да гадая. Отвъд океана войните на Америка са просто новинарски поток, далечна приказка, риалити, което дори не тече по телевизията. По десетките екрани в баровете се върти спорт, метрото е пълно с хора, облечени в червено, които се връщат от мач на бейзболния отбор на Филаделфия. Апокалипсисът се случва навсякъде, но не и в Америка. Тя държи само правата за кинопродукцията. 

Гласовете на Америка – брой 15
Америка празнува. Улиците на Филаделфия със Залата на независимостта на заден план © Йоанна Елми

В осми брой на „Гласовете на Америка“ си взехме въздух от същия новинарски поток, но не през ескейпизма на хляба и зрелищата, а през музиката. В настоящия брой ще направим същото, но през три исторически важни стихотворения, които разказват и осмислят САЩ извън заглавията, извън новините, извън апокалипсисите, които са им така присъщи и в които така имаме навика да се губим, пропускайки същественото. 

Тези стихотворения може би ще ни успокоят, че и преди се е стъмвало – и може да бъде светло отново. 

Приятно четене. 

Виж, гаснат светлините 

Стоманеносиво, с петна от сенките на облаци,
морето попива последните вечерни светлини.
Гласът е мощен и пяната с цвят на олово,
и приливът поглъща пясъците.

Тук стой като древен камък
и виж как гаснат светлините, чуй гласа на океана.
Ненавист и мъка сграбчват Европа и Азия
и морският вятър е леден.

Настъпва нощ: нощта ще поиска всичко.
Светът не се е изменил, по-разголен е само:
силните се борят за власт, а слабите
топлят бедните си сърца с омраза.

Настъпва нощ: върви си вкъщи,
опитай се да хванеш по радиото новините.
Чуваш ли ги, гласовете на Америка: наивни,
властни, лицемерни и обречени.

Кога? След четири или четиридесет години?
Защо му е на камъка да рови бъдещето?
Стой на своя бряг, древни камъко,
и нека соленият вятър направи главата ти бяла.

Робинсън Джефърс, 1941 г., превод Николай Попов 

Стихотворението на Робинсън Джефърс вдъхновява името на този бюлетин. Американският поет пише основно в наративна и епична форма и е смятан за икона на природозащитното движение. Противоречивата му философия, която той нарича „нехуманизъм“ (inhumanism), е сред основните причини да бъде отхвърлен от канона и днес да не се нарежда по популярност до поети като Т. С. Елиът например. Живял и творил по време на две световни войни, Джефърс вярва, че човечеството е твърде антропоцентрично и претръпнало към красотата на света и живота. 

В една от своите поеми Джефърс предлага хората да децентрализират вниманието от самите себе си. Призивът е колкото странен, толкова и актуален с оглед на различни съвременни движения, включително и на идеите на британския артист и писател Джеймс Бридъл, който преосмисля концепцията за интелигентност във времената на изкуствения интелект и смята, че интелектът не е само човешко качество, а черта, присъща на всички живи организми. 

Решението според Джефърс е „отстраняване“ от конфликтите, а не заемане на морална позиция в тях. През 1948 г. той публикува няколко критични стихотворения за американското участие във Втората световна война и издателството му Random House цензурира част от произведенията му, като също добавя бележка, че позицията на Джефърс не е позицията на издателството. 

Становището на Джефърс е, че войната е безкрайна борба на империи за пазари и ресурси, а не морална битка, и че в нея няма победители, както и че прекаленото митологизиране и военна намеса на САЩ в чуждестранни войни ще унищожи републиката и ще ускори разпадането на държавата. Опасенията на Джефърс са, че в САЩ ще се загърби идеята за свободна република в полза на свръхамбициозна военизирана империя. 

Във „Виж, гаснат светлините“ се отличават основните теми от поезията на Джефърс: незначителността на човешките вражди и проблеми пред огромното безвремие и великолепие на естествения свят, гаснещите светлини на цивилизацията, нескончаемата човешка борба за власт и ресурси, безкрайният шум на новините, падащият мрак. Камъкът и океанът са сред основните символи в творчеството на Джефърс, който живее на калифорнийския бряг, където построява каменния замък „Тор“. Творчеството му повлиява върху Чарлз Буковски, полския поет Чеслав Милош (който превежда много от стиховете му), фотографа Ансел Адамс и др. Противоречив и гениален, Джефърс остава колкото философски недостижим и може би дори наивен, толкова и неволен пророк на времената, в които живеем. 

Гласовете на Америка – брой 15
Празнуване на Синко де Майо на една от основните артерии в града – „Саут Стрийт“ © Йоанна Елми 

Белият дом

Пред моето напрегнато лице
вратата ти затворена е здраво,
но имам смелост, имам дързостта
да нося гняв в сърцето си кораво.
Паважът под краката ми гори,
в гърдите сякаш зее грозна рана,
кръстосвам мълком булеварда бял,
загледан в портата ти обкована.
И твърдост в себе си безспирно диря,
и разум тук, пред тежките колони,
че нужна ми е свръхчовешка сила,
Бял дом, да спазвам твоите закони.

Клод Маккей, 1919 г., превод Николай Попов

Сонетът на ямайско-американския автор Клод Маккей е публикуван през 1922 г. в лявото издание The Liberator. Чернокожият автор заимства поетичните структури на Шекспировите сонети, присвоявайки си – донякъде скандално за времето – литературни и културни символи на бялата образована американска класа. По това време сонетът се смята за вече остаряла форма, така че изборът му е целенасочен. 

Маккей е основна фигура на Харлемския ренесанс и изгрява със стихотворението си „Ако ни чака смърт“, провокирано от „Червеното лято“ – вълна от линчове над чернокожи в САЩ след края на Първата световна война. Когато емигрира в САЩ през 1912 г., за да следва в Тъскиги, Алабама, Маккей е шокиран от дълбокия расизъм, на който става свидетел и мишена. Активната сегрегация му служи като катализатор и той започва да пише поезия, а цялата му кариера и живот са белязани от несправедливостта на институционализирания расизъм в САЩ. За съжаление, Маккей не доживява раждането и победата на движението за равни граждански права, но и до днес остава ключова фигура в историята на афроамериканците. 

След преместването си в Ню Йорк Маккей се включва в различни леви радикални сдружения, свързани с човешките права. Временно живее в Лондон, а през 1922 г. става част от руската болшевишка партия, мака да смята, че Комунистическата партия на САЩ не приоритизира достатъчно правата на чернокожите и дори че използва техните каузи за собствени цели. След кратко пребиваване в Русия Маккей осъзнава, че Коминтернът също го използва за собствените си пропагандни и геополитически цели, за което разсъждава в непубликувания си ръкопис „Харлемска слава“. 

По-късно в своята биография Маккей пише за причините, поради които в крайна сметка отказва членство в Комунистическата партия и избира изкуството пред ригидността на идеологията и партийната принадлежност. Пътят на Клод Маккей през литературата, идеологията и политиката разкрива напрежението между оформящите се тогава идеологически рамки – на комунизма и капитализма, – които ще застанат от двете страни на основната разделителна линия на XX век и ще намерят кулминация в Студената война. 

Комунизмът и социализмът все още са обсъждана алтернатива на пазарния капитализъм в САЩ, защото историята на държавите от Източния блок остава слабо позната, от една страна, и поради силната марксистка традиция в американските университети, от друга. От възможни работещи алтернативи до различни версии на „червената заплаха“, войната на идеологиите е релевантна и в контекста на културните войни. Творчеството на Маккей успява да надскочи тези идеологически рамки и да говори за институционалната несправедливост, за различните Америки, обитавани от различните американци, и за безкрайната борба за граждански права, която продължава и днес. 

Гласовете на Америка – брой 15
„Без царе. Без ICE. Без страх. Имигрантите са добре дошли тук.“ Подобни знаци, стикери и табели украсяват целия град © Йоанна Елми 

Новият Колос

Не дръзкият гигант със древногръцка слава,
от бряг до бряг разкрачил войнствени нозе;
пред портите, окъпани от залез и море, ще спре
със огнен факел във ръце – могъществена, права,
светкавиците овладяла, тя името си разгласява:
Майка на Изгнаници. С десница като фар зове,
цял свят приютява и поглед мек ще разпростре
над мостовете от ефир на двата огледални града.
„Задръжте, вехти царства, славния разкош – извиква тя 
със устни неми. – На мене дайте уморени, бедни,
потъпканите бежанци, жадуващи за свобода,
окаяната сган от бреговете ви безредни.
Пратете тях, бездомни, корабокрушенци,
светилник аз издигам над златната врата!“

Ема Лазарус, 1883 г., неизвестен преводач 

Няколко строфи от „Новият колос“ са гравирани върху Статуята на Свободата. Ема Лазарус пише стиховете през 1883 г. като част от дарителската кампания за построяването на пиедестала на статуята – за тази дарителска кампания сме ви разказвали в шести брой на бюлетина. Историческият контекст на стиховете обаче далеч надминава стогодишнината на държавата и създаването на статуята. По това време писателката и поетеса Лазарус помага на еврейски бежанци в Ню Йорк, които бягат от погромите в Русия. Самата Лазарус също е потомка на евреи, дошли от Германия и Португалия. Тя превежда Шилер, Хайнрих Хайне, Александър Дюма и Виктор Юго и става разпознаваема със стиховете си и прозата си както в САЩ, така и в Европа. 

Гласовете на Америка – брой 6
Йоанна Елми посещава най-американския символ и островите Елис и Либърти, разказвайки ни по вълнуващ начин за историята на имиграцията в САЩ и за връзката между отговорността и свободата. Перфектното дълго лятно четиво, ако не ви е страх от нещо, задържащо вниманието повече от 3 секунди.
Гласовете на Америка – брой 15

Освен това краят на XIX век e време на ожесточен сблъсък между т.нар. нативисти и антинативисти, период на огромно политическо преосмисляне на въпроса кого да допускат САЩ на своя територия. Нативистите – основно протестанти от англосаксонски произход, изразяват тревога, че нашествието от нови имигранти ще размие американската култура, ще понижи заплатите и ще урони републиканските принципи и политическата система. На мушката са основно католици – ирландци и немскоговорящи, за които съществуват опасения, че са по-лоялни на папата, отколкото на държавното управление на САЩ и институциите на демокрацията. Огромна е и кампанията срещу южно- и източноевропейците: италианци, славяни, включително поляци, сред които има не само католици, но и православни; те се възприемат като бедни и културно различни, а също и като по-низши от расова гледна точка. На Западния бряг има изразена враждебност срещу китайските имигранти, които са обвинени, че крадат работни места от белите, и се твърди, че е невъзможно да се асимилират. 

Нативистите постигат огромна политическа победа през 1882-ра – година преди публикуването на поемата на Лазарус, с Указа за изключване на китайците, с който за първи път в историята на страната се забранява влизането в държавата на определена група хора на основата на националността и расовата принадлежност. Антинативистите, сред които индустриални предприемачи и хуманитарни активисти (като Лазарус), смятат, че Америка е убежище за низвергнатите и че имиграцията е необходимо гориво за бързо разрастващата се индустриална държава. Избирайки да илюстрира статуята не като символ на военни завоевания, а като майка на изгнаниците, Лазарус обръща курса на историята в особено красив поетичен бунт. 

Ксенофобската нативистка политика достига кулминацията си чак през 20-те години на новия век, когато се приемат още антиимиграционни закони, налагащи квоти за новопристигнали имигранти (включително българи). Тези политики се отменят чак след Втората световна война и имат негативни икономически последствия. През това време в страната има огромен недостиг на работна ръка, а индустриалният бум се забавя – изключването на китайските работници води до 62% спад в общото производство. През 1924 г. земеделският бизнес активно лобира да няма квоти за южноамерикански работници заради недостига на евтина работна ръка, която да събира реколтата от памук, захарно цвекло и плодове. Официалната политика между САЩ и Мексико води до наплив на 4,5 милиона мексикански работници. Много от южно- и източноевропейските работници във фабриките в Севера са заменени от афроамериканци и пуерториканци. 

Война, несправедливи закони, ксенофобия и антиимигрантски настроения – тъканта на САЩ е направена и от това. Докато вървях из улиците на Филаделфия, където са живели Джордж Вашингтон и Бенджамин Франклин; където Едгар Алън По измисля своите мрачни истории; където са свирили някои от най-добрите джаз музиканти в историята; и където от прозорците днес ме гледат плакати FUCK ICE, докато покрай мен минава огромен камион с черно-бял американски флаг със синя линия в подкрепа на полицията, си мисля, че въпреки горчилката някак продължавам да обичам тази страна. Страна на крайностите, страна на гения и на пълното отсъствие на интелект, страна на жестокостта и на безусловната, безгранична човешка щедрост, страна на риалити шоута и на мъдрото преосмисляне на историята, страна на стагнацията и страна на промяната. 

А иначе всичко ново е добре забравено старо. 


Абонирайте се, за да получавате този бюлетин на електронната си поща в момента, в който излезе!

Вече сте регистриран потребител на Toest.bg? Може директно от настройките на бюлетините в своя профил да изберете „Гласовете на Америка“ или да натиснете бутона по-долу:

Още нямате профил в Toest.bg? Регистрирайте се само с няколко клика:

Chilling Effects

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/chilling-effects.html

Younger Americans have soured on the second Donald Trump presidency, but they are not protesting it.

Despite an unpopular Iran war and an even more unpopular Trump administration, college campus protests nationwide have gone silent. And at many schools, student activism is virtually nonexistent.

This silence comes in the wake of a relentless Trump administration war on campus speech that has involved lawsuits, arrests, deportations and expulsions.

Reports cite a range of complicated factors for the restraint, from apathy to technology-induced incapacity. But as public policy and law and social science experts, we believe students aren’t protesting for a very simple reason: They are afraid. They are self-censoring and disengaging from campaign activism to avoid punitive measures.

In law and social science, we call this impact a chilling effect—the behavioral tendency for people in face of a threat to self-censor and restrain their activities for self-protection.

It’s increasingly clear to us that these impacts are not incidental or ancillary to Trump administration policy. Rather, the chilling effects are the point. This is the closest thing to a consistent governing strategy in Trump’s second term.

The broader chill of Trump threats

Chilling effects can be subtle, but today they are everywhere. And it’s not just students who are chilled by Trump administration threats.

Professors are censoring themselves in lectures and rewriting syllabuses. Researchers are stripping grant applications of words that might attract federal scrutiny, or abandoning the topics entirely. Media outlets are modifying their news coverage to avoid Trump lawsuits or sanctions.

Law enforcement and regulatory agencies are refusing to investigate Trump-aligned actors inside or outside government, and major national law firms are declining cases challenging Trump administration policies.

Publishers are “stepping back” from LGBTQ+ books and other progressive subjects. Many in targeted immigrant communities are afraid to leave home to go to work or school.

In most cases, these people and institutions are not being specifically targeted or threatened by Trump. But they are afraid, and their fear is doing the administration’s work for it. They stay silent, avoid attention and confrontation, and look the other way. In other cases, they change their speech and behavior to accommodate or conform to the administration’s worldview.

Of course, there are counterexamples, such as the winter protests in Minneapolis in response to brutality by agents with U.S. Immigration and Customs Enforcement, and the recent “No Kings” rallies. But even here, the broader but less visible trend—chilling effects—is evident.

For instance, in recent reporting on the latest No Kings rallies, many media outlets observed that students were noticeably missing, despite the Trump administration’s unpopularity among younger Americans.

A persistent strategy

We believe none of this is by accident.

In a new book, “Chilling Effects: Repression, Conformity, and Power in the Digital Age,” one of us—Jon Penney—explains how law, technology, and state and corporate power are weaponized to chill and repress, and the dangers this poses for the United States and other democratic societies. The other—Bruce Schneier—has extensively studied the security infrastructure enabling this.

What we see isn’t gratuitous government cruelty, chaos or vengeance. Instead, we see a persistent strategy to maximize fear and chilling effects in ways that are corrosive to freedom and democracy.

Research suggests that surveillance, personal threats, uncertainty and abuse of power are key factors in doing so. The federal government has a clear and systematic pattern of employing these very mechanisms across a number of domains far beyond campuses.

They are evident in militarized raids by Immigration and Customs Enforcement and in journalists being arrested and indicted for reporting on protests. They are made clear in the long list of political enemies the Trump administration has investigated or threatened, including the Federal Reserve chairman. And they can also be seen in the weaponization of technology, including ramping up surveillance to target critics and protestors.

Corrosive to freedom and democracy

History offers some guidance on impacts.

During the McCarthy era, overreaching laws, surveillance, and public and private sector reprisals ostensibly targeted alleged communists. But the real aim was often to suppress progressive journalists, trade unions and political opposition.

In the 1960s, these same tactics were reused by Southern states to chill the Civil Rights Movement. Historians have written about how the widespread fear and conformity of these periods reshaped American society in enduring ways, including the destruction of progressive political movements and both delaying and muting the Civil Rights Movement itself.

When such state threats are systematized, they can foment a broader climate of fear, self-censorship and conformity. In that climate, dissenting speech, political opposition, democratic mobilization and other checks on power become increasingly difficult, even dangerous. It is no surprise, for instance, that Trump critics regularly admit to self-censorship, fearing for their safety.

Chilling effects are thus not only repressive—causing self-censorship—but productive. They produce conforming and compliant speech and behavior, which can have longer-term social impacts. They not only undermine protected rights and suppress accountability but can promote social change—even without a popular mandate to do so.

This latter point is often missed. It explains Trump’s assaults on universities and cultural institutions such as the Kennedy Center for the Arts and the Smithsonian. Often dismissed as peculiar Trump obsessions, they are fully consistent with Project 2025—the sweeping policy blueprint for Trump’s second term authored by a coalition of conservative groups and its call to target the “institutions of American civil society” and “wield federal power” to “reverse” decades of progressive cultural advancements.

In the near term, this means an increasingly weakened democratic society, with the government and its patrons enjoying freedom to pursue their objectives. Over the long term, this can mean a changed society as more conformist and compliant speech and culture become more widely accepted and entrenched.

Not inevitable

In our view, this future is not inevitable, just as the McCarthy era “Red Scare” and violent civil rights era repression were not. In both cases, fear and chilling effects were resisted in law and civil society, as they can be today.

But the central mechanisms—surveillance, uncertainty, personal threats and abuse of power—would need to be addressed. For instance, new legislation could ensure justice for lawless government actors and constrain surveillance. Courts can block abuses of federal power, including illegal arrests, detentions and mass citizen databases.

The media, lawyers and civil society can hold the government accountable. And students, teachers, universities and cultural institutions can resist the tendency to self-censor and conform.

The citizen mobilization in Minnesota and the No Kings rallies are examples of that. But to resist chilling effects and their dangers over the long term, this would have to be the norm, not the exception.

This essay was written with Jon Penney, and originally appeared in The Conversation.

Научни новини: Зоонози, астероиди и „Вояджър“

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-zoonozi-asteroidi-i-voyadzhur/

Зоонозите – очакван риск

Научни новини: Зоонози, астероиди и „Вояджър“

В началото на месеца новинарските емисии започнаха да бълват информация за пасажерите на круизния кораб MV Hondius, който стана злополучно известен с пътниците си, заразени с хантавирус. За съжаление, няколко от тях починаха, а други проявиха симптоми по-късно. След опита, който натрупахме с COVID-19, повечето от нас сигурно са наострили уши и следят случващото се с известна тревога, особено след като пътниците от кораба бяха изпратени в държавите си.

Към момента има активни случаи в няколко страни в Европа. Повечето от пациентите са стабилни, с изключение на жена във Франция, чието състояние се описва като тежко. Макар че вирусът има потенциал за разпространение, тъй като някои от пасажерите напуснаха кораба, преди да се вземат активни мерки за ограничаване на възможните контакти, Световната здравна организация (СЗО) определя ситуацията като нискорискова. Такова е мнението и на българското Министерство на здравеопазването.

Хантавирусите са голяма група РНК вируси, разпространявани от гризачи, 

като в общия случай всеки вирус има строго специфичен резервоарен вид. Обикновено хората се заразяват при вдишване на частици, замърсени с екскременти, урина или слюнка на гризачи. В зависимост от типа хантавирус заболяванията са два вида. Вирусите, разпространени в Европа и Азия, предизвикват хеморагична треска с бъбречен синдром. Това заболяване се среща и у нас, като за ендемични се смятат планинските райони, но според изследване от 2016 г. разпространението може да е по-широко.

Американските щамове, от чиято група е вирусът на круизния кораб, имат друга симптоматика. Тя се изразява в белодробни и сърдечни проблеми – хантавирусен сърдечно-белодробен синдром (ХСБС), който е много по-сериозен и с по-висока смъртност. Конкретният вирус е тип Andes (ANDV) – открит е в Аржентина и е наречен на Андите. Освен че причинява значително по-тежко заболяване, той е по-опасен и поради способността му да се предава от човек на човек.

Глобално село: Епидемии
В края на годината се правят равносметки, а в началото на следващата се поставят нови цели. Ето например за Международното движение на Червения кръст и Червения полумесец приоритет №1 за 2019 г.
Научни новини: Зоонози, астероиди и „Вояджър“

За добро или лошо, нямаме много информация за този пренос, тъй като случаите до момента не са много, но от това, което знаем, 

вероятността вирусът да причини пандемия е ниска. 

Това се дължи на две основни негови особености. На първо място, той се предава по-трудно – нужен е продължителен контакт с носител на вируса и пренос на слюнка (директно или чрез капки), поради което дори обикновените маски са много подходящи да бъде спрян. Наред с това се смята, че носителите са заразни само ако активно проявяват симптоми. Тази комбинация драстично намалява риска от заразяване с вируса в сравнение с COVID-19.

Неприятна характеристика на вируса е широкият му инкубационен период, който е от 1 до 6 седмици, а в редки случаи достига до 8. Това означава, че всички потенциално контактни лица трябва да прекарат това време в карантина.

Тъкмо когато вълненията около хантавируса започнаха да се успокояват, СЗО излезе с

тревожно съобщение за епидемия от ебола 

в Демократична република Конго и Уганда. Огнището е в провинция Итури, район в Конго, намиращ се на границата с Уганда. Той е белязан от кървави конфликти между различни групировки, което значително затруднява работата на здравните работници. Оттам са проследени няколко случая на пренос към столиците Киншаса и Кампала, както и в други райони на Конго.

Първият предполагаем случай е от 24 април – мъж, починал след проява на характерни симптоми. След като на 5 май СЗО е информирана за предполагаема поява на ебола, тя изпраща екип на терен. Първите позитивни тестове идват чак на 14 май и са изненада – вирусът не е по-често срещаният заир, за който са тествали в началото, а бундибуджо. Ден по-късно са потвърдени стотици случаи на заболяването, което показва сериозно забавяне на реакцията на здравните служби. Към 22 май потвърдените случаи са 82, предполагаемите – 750, а починалите – 177, но най-вероятно мащабът е по-голям.

Поради това властите забраниха събирания на повече от 50 души, както и всички погребения. Тези мерки не се приемат добре и вече има случаи на нападения на медицински центрове. За съжаление, подобни атаки са често срещано явление по време на епидемии. С тези атаки военизираните групировки всяват допълнителен ужас, убивайки и отвличайки хора. Местните се отнасят скептично към здравните работници, защото много живеят в отдалечени райони и се сблъскват с лекари само по време на епидемии, така че понякога правят обратна причинно-следствена връзка, мислейки си, че лекарите ги заразяват нарочно.

Не на последно място, традициите за изпращане на мъртвите са много силни и в тях се вплитат религия и свръхествествено. Освен че служат за почитане на паметта на покойните, има поверия, че ако ритуалите не бъдат изпълнени, мъртвите ще прокълнат близките си или ще се върнат като зли духове. Лошото е, че погребенията са свързани с много контакти с тялото на мъртвия, което при ебола все още е силно заразно. Така вирусът много лесно се разпространява в семейните групи.

Засега единственият потвърден болен извън Африка е американски лекар, работещ в Демократична република Конго, който е дал положителен тест за вируса, но е в добро състояние. Той е транспортиран в болница в Берлин, която е специализирана в изследване на такива сериозни патогени и осигуряване на грижа за пациенти, заразени с тях. Членовете на семейството му, които са контактни, също са под наблюдение. 

Научни новини: Минилуни, комети, зоонози и фораминифери
Изстрелваме се в Космоса, слизаме в дълбините на Средиземно море и се разхождаме из пазара в Ухан благодарение на научните новини на Михаил Ангелов. Научните новини – по-добрите новини.
Научни новини: Зоонози, астероиди и „Вояджър“

Още един американски лекар е в Чехия – той е бил изложен на вируса, но към момента не проявява симптоми. И двамата са под строга карантина и не представляват риск за общественото здраве. Европа традиционно се включва при появата на ебола в ендемичните за вируса райони и има добре обучени за целта специалисти.

Американското правителство обяви, че ще финансира създаването на 50 полеви клиники, но това не покрива и малка част от програмите, които бяха спрени по време на втория мандат на Тръмп. След като USAID беше закрита и САЩ се оттеглиха от СЗО, бюджетът на Американските центрове за контрол на заболяванията (CDC) e намален. Намалена е и здравната помощ, която се отпуска на африканските държави. Тези мерки силно ограничиха възможността за рутинно следене и потушаване на огнищата още в началото на появата на вируса. 

Заболяването е описано сравнително скоро – първите регистрирани случаи са през 70-те години на миналия век. В началото симптомите са „стандартни“ – отпадналост, висока температура и болки в ставите. С напредване на болестта започват и повръщане и диария, които влошават общото състояние поради обезводняване. При част от пациентите се наблюдават и вътрешни и външни кръвоизливи (имайте предвид, че не са „ефектни“ като по филмите). Всички телесни течности са много заразни и трябва да се избягва контакт с тях.

След последната мащабна епидемия срещу по-често срещания вирус – заир, беше разработена ваксина, която вече е поставена на много хора в рисковите райони. За вируса в актуалното огнище все още няма ваксина и грижите за пациентите, както при повечето вирусни заболявания, са поддържащи. 

Обикновено след реакция на СЗО епидемиите се ограничават и огнищата се потушават без глобално разпространение на причинителя. Вирусът рядко напуска Африка и обикновено заразените са медицински лица, които са се сблъскали с него в работата си. Това не значи, че последствията не са трагични – в район, който така или иначе е разкъсван от конфликти и бедност, появата на ебола предизвиква неимоверно допълнително страдание. 

Уви, като всяка зооноза, това най-вероятно няма да е последната епидемия от ебола. Книгата на Дейвид Куамен Spillover остава гореща препоръка за всеки желаещ да научи повече за вирусите, които винаги ще бъдат наблизо и ще продължат да ни държат в напрежение.

Среща в ниска орбита

Наред с пандемиите, опасност в глобален мащаб са и големите скали, обикалящи из Космоса. Те имат потенциала да променят напълно облика на планетата ни, а по-сериозните сблъсъци могат да поставят оцеляването на човешкия вид под въпрос. Поради тази причина за търсенето и проследяването им се отделят значителни ресурси от повечето световни космически агенции.

Веднъж открити, те влизат в списъка на т.нар. потенциално опасни обекти (астероиди или комети) – тела, които прелитат близо до Земята и размерите им са достатъчни да причинят значителни щети. Повечето от тях са в стабилни и далечни орбити, така че не са непосредствена опасност дори в дългосрочен план. Но това не значи, че след време орбитите им няма да се променят и Земята няма да застане на техния път.

Научни новини: Астероиди, квантова математика, говорещи мишки и малко Марс
Астероиди летят към Земята, докато квантови компютри телепортират изчисления, а мишки си разговарят по важни житейски теми, например защо планетата Марс е червена. Всичко накуп в научните новини на Михаил Ангелов.
Научни новини: Зоонози, астероиди и „Вояджър“

Един от тези астероиди е Апофис, който на 13 април 2029 г. (пада се петък, разбира се) ще прелети на впечатляващите 31 000 км от нашата планета – по-близо от някои сателити. Той ще бъде видим от Европа и Африка с интензитет на средноярка звезда, но движейки се с около сантиметър в минута в небето. За България най-доброто време за наблюдение ще е около 00:45 на 14 април, така че може да отбележите в календара си това изключително рядко събитие.

Близкото прелитане ще даде възможност за изучаването на обекта, като към момента са планирани две мисии.

Европейската „Рамзес“ се движи по план, 

след като в началото на месеца беше подписано споразумение за съвместна работа с Японската агенция за аерокосмически изследвания (JAXA). Тя ще осигури слънчевите панели и инфрачервена камера за апарата, както и изстрелването му през 2028 г. на японската ракета H3. 

Десет месеца след изстрелването си „Рамзес“ ще доближи Апофис и ще го изпроводи по време на преминаването му покрай Земята. Тогава повърхността на астероида ще бъде заснета с висока разделителна способност в различни спектри и ще се следи за промени, причинени от гравитационните сили на планетата ни. Това ще обогати знанията ни за подобни обекти и за възможностите за отклоняването им, ако някой се окаже на път към нас. 

„Рамзес“ ще носи и два по-малки апарата, които също ще съберат информация от астероида. Единият от тях – „Фаринела“, ще опита да изследва прах от Апофис и ще проучи вътрешността му с помощта на радарна система. Другият – „Дон Кихот“, ще се приближи повече от „Рамзес“, за да заснеме по-детайлни кадри, и ще направи опит за кацане. Ако той е успешен, испанският апарат ще измери влиянието на прелитането покрай планетата върху сеизмичната активност на астероида, както и влиянието на земното магнитно поле.

От американска страна щафетата ще поеме апаратът OSIRIS-APEX. Това е прекръстеният OSIRIS-REx, който, след като успя да събере и върне материал от астероида Бенну, бе пренасочен така, че да може да се доближи до Апофис малко след прелитането му покрай Земята. Апаратът ще влезе в орбита около астероида, което ще позволи прецизни наблюдения за около 15 месеца. След това ще се доближи до повърхността на Апофис и използвайки двигателите си, ще вдигне прах, за да се разкрие материалът под нея. Това ще му даде възможност да събере данни и от силикатен астероид, след като вече извърши анализ на карбонатния Бенну. 

Заедно с „Рамзес“ на борда на ракетата H3 ще има и друг апарат, разработен от JAXA. DESTINY+ ще е малък и лек, с тънък алуминиев радиационен щит и ултралеки слънчеви панели. В Космоса той ще използва своите йонни двигатели, захранвани от слънчевите панели, за да се отправи на среща с астероида Фаетон. Това е обект с диаметър малко под 6 км, който прелита близо до Слънцето по орбита, сходна на орбитата на комета. 

Той преминава сравнително близо до Земята, поради което е класифициран като потенциално опасен, но пътят му е добре проучен и не се очаква скоро да създаде проблеми за нас. Следващото му най-близко прелитане ще е на около 7 лунни разстояния през 2093 г. За да достигне Фаетон, апаратът ще има нужда от две години. Йонните двигатели са много икономични, но тягата, която създават, е малка.

DESTINY+ не е първият такъв апарат на JAXA – той върви по стъпките на Hayabusa 1 и 2, които през 2010 и 2020 г. донесоха на Земята материал от астероидите Итокава и Рюго, също от групата на потенциално опасните обекти, преминаващи близо до Земята.

„Вояджър 1“ губи още един инструмент

В средата на миналия месец инженерите от NASA изключиха инструмента на „Вояджър 1“, засичащ заредени частици с ниска енергия. Същият уред на сестринския апарат „Вояджър 2“ беше изключен в началото на миналата година.

Двата апарата се захранват от три радиоизотопни генератора, които бавно губят своята мощност поради разпада на плутония в тях. Тъй като целта им е да напуснат Слънчевата система, използването на слънчеви панели е изключено, но дори и за мисии вътре в нея, след Сатурн те стават на практика неизползваеми. Това е причината, въпреки сравнително ниската им мощност, апаратите за далечни пътешествия да се оборудват с такива генератори.

„Вояджър 1“: Съдбата на самотния пътешественик
Идва краят на една много дълга песен. Едва ли някой е вярвал, че ще я слушаме толкова време. Космическият апарат „Вояджър 1“, който ни показа малката синя точка, побрала всичко обичано от нас, потъва все повече в необятното нищо. От Дъг Мюър.
Научни новини: Зоонози, астероиди и „Вояджър“

Изключването на уреда беше планирано за тази година, но беше направено по-рано от очакваното. Причината е рязък спад в мощността на генератора, забелязан след рутинна маневра на апарата. Били са доближени нивата, при които започва автоматичното изключване на инструменти с цел запазване на основната система. За да избегнат това, инженерите са взели решение да изключат детектора, което би удължило мисията с около година.

Така от десетте научни инструмента на „Вояджър 1“ активни остават само два – магнитометърът, измерващ магнитни полета, и двете антени, които засичат промените в плазмените вълни в космическото пространство. Същите са активни и на „Вояджър 2“ заедно с уреда, изследващ заредени частици, идващи от Слънцето и от междузвездното пространство.

Добрата новина е, че апаратите не са изоставени. 

Инженерите имат план за изключване на няколко големи консуматора и замяната им с по-енергоефективни алтернативи. Тъй като междузвездното пространство е много студено, част от системите трябва да работят, за да поддържат научните инструменти топли. Стратегията е наречена „Големият взрив“ и първо ще бъде изпробвана на „Вояджър 2“, тъй като той има повече мощност в генератора си и е по-близо до Земята. Ако тестовете са успешни, същият подход ще бъде приложен и на „Вояджър 1“.


Веднъж месечно Михаил Ангелов – биолог, агроном и любим нърд от нашия екип, ни представя най-интересните скорошни новини от различни сфери на науката и обяснява защо тези постижения са толкова значими за света и човечеството. Или най-малкото – любопитни и забавни.

Имотите на вероизповеданията в България

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/imoti-religii/

Според закона за вероизповеданията те са свободни и равноправни. Според същия закон източното православие е традиционно за България, но това в никакъв случай не му дава привилегии спрямо останалите. Също така, че изповядването на религия не може да бъде използвано за политически цели, срещу здравето и правата както на членовете им, така и на другите. Доста може да се каже за това как основните религии у нас нарушават чл. 7, особено що се отнася до публичното здраве и вмешателството в светското образование. Тук ще говорим за друго обаче.

Чл. 18 задължава Софийски градски съд да поддържа публичен регистър на вероизповеданията и юридическите лица свързани с тях. Такъв публичен регистър не може да бъде намерен на страницата на съда. Чл. 12 ал. 3 задължава дирекция към министерски съвет да поддържа регистър на храмовете. Дирекция „Вероизповедания“ на МС има регистър, но както ще стане дума след малко, с него има проблеми. Чл. 21 посочва, че вероизповеданията имат право на имоти, но регистър на тези няма.

Започнах да се ровя в темата покрай картата ми за собствеността на имотите в България. Тогава бях шокиран, че голяма част от Рила е собственост на Българската православна църква. Тогава започнах да събирам информация за собствеността им. Задачата се оказа доста трудна. Върнах се към нея наскоро след като припомних за защитените стари сгради на ул. Шишман в София, които БПЦ като съсобственик има намерение да събори и застрои с жилищни блокове.

Успях да събера информация за над 19 хиляди поземлени имоти, сгради и самостоятелни обекти собственост на всички 71 регистрирани в България вероизповедания. Това е т.н. КИД 94.91. За целта използвах комбинация от няколко източника – имотния и търговския регистър и кадастъра. Не използвах регистъра на храмовете поради простата причина, че 45% от съдържанието няма координати, а доста от останалите са грешни – например поставени върху улицата, а не сградата, където е офиса на фирма регистрирана като религия.

Методология

В събирането на данните и изготвянето на картата разчитам изцяло на публични източници. Доколкото се налагаше да изчиства голяма част от тях, както и да комбинирам данните по подходящ начин, възможно е да има грешки в представянето на информацията. Ако откриете такива, моля оставете коментар, за да ги оправя. Някои от поземлените имоти или обекти имат повече собственици и само един да е вероизповедание. Има случаи, в които са вписани взаимоотношения различни от собственост като договор за ползване. В доста случаи ще забележите, че на картата е отбелязан поземлен имот, а религиозна организация притежава само сграда или офис на това място. Затова в описанието съм описал точно за какъв обект и взаимоотношения става дума.

Имотен регистър

Събрах над 100 справки за имотното състояние на юридически лица регистрирани като вероизповедания. Някои от тях купих, други ми бяха изпратени от други, които са търсели информация по темата. Имотния регистър е най-точният източник предвид, че е т.н. system of records що се отнася до собствеността. Не е без своите проблеми. Най-очевидния са липсващи или унищожени актове, за което стана въпрос наскоро и дори се стигна до уволнения.

Не е нужно да има злоупотреба обаче. Сериозна част от актовете не са налични, тъй като никога не са били вписвани. Това става обикновено при прехвърляне или продажба. Макар да има записи дори от 1960 г., за голяма част от имотите в картата ми няма да намерите нищо там. Най-големият проблем е, че въобще се налага да се плащат тези справки особено за юридически лица. Има проблем и с формата – получаваме PDF, който изписва всякакви актове и всички замесени лица в тях. Това е полезна информация, но първо се обработва трудно, второ получаваме доста записи като уреждане на сервитути. В крайна сметка намерих начин да обработя информацията и да отделя само онези имоти, които конкретната проверявана фирма притежава.

Търговски регистър

Откакто отвориха данните им е значително по-лесно да се сверява информацията. В случая използвах един от многото сайтове предлагащи такава услуга, тъй като показваше архивирани юридически лица с прекъсната дейност. Търсейки по 94.91 открих 3843 юридически лица. 79 са с прекратена дейност. Открих също 39 фирми, които имат цялостна или частична собственост друго юридическо лице, което е регистрирано като вероизповедание. Доколкото в данните на търговския регистър по принцип няма данни за собственост, може да използваме събраният така списък с ЕИК за следващите стъпки.

Всичко това би следвало да е налично заедно с много друга информация на страницата на Софийски градски съд. Или аз не мога да го намеря, или наистина не е публичен както е изискването по закон. Това означава, че трябва да минаваме през Търговския регистър, както аз направих или да искаме информацията по ЗДОИ, от което чакам отговор от тях. Тази публичност е несъмнено важна за обществото. Така например разбрах, че преди 17 години собствениците на Артекс са участвали в основаването на строителна фирма в Габрово заедно с евангелистична църква.

Кадастър

Тук получаваме информация по няколко направления. В отворените данни на кадастъра намираме списък със собствеността на имотите. Коментирах вече проблемите с точността на тези данни. Знаем най-малкото, че вероятно не са актуални заради спецификите на вписването и липсата на свързаност между държавните регистри. Взимайки списъка с ЕИК номера, за които знаем, че са на вероизповедания, получаваме списък с имоти, за които кадастъра знае, че са тяхна собственост. Проблемът тук е, че за доста записи в кадастъра ЕИК номерата са объркани или са случайни, особено когато става дума за актове от преди повече от 20 години.

Отделно, в описанието на всеки имот има информация за вид собственост и тям е отбелязано когато е на „частна религиозна организация“. Може да използваме това категоризиране, за да съберем още имоти, които по една или друга причина не са намерени директно през ЕИК. Тук е важно да се повтори, че така получаваме информация не само за поземлени имоти, но и за сгради, магазини, офиси и жилища. Също така получаваме известната на кадастъра собственост за всякакви лица – не само търсените.

На последно място, взимам имотите отбелязани, че са на частни религиозни организации в кадастъра, взимам имената на юридически лица, за които кадастъра знае, че са собственици на имота. Изчистих тези, които видимо не са религиозни организации, а съсобственици или имат някакви други взаимоотношения. След това намерих всички имоти, които са собственост на фирми с точно тези имена. Правя това, защото както споменах има грешки с ЕИК номерата в кадастъра. Има обаче и грешки в изписването на името и това е просто защото се подава грешна информация. Този подход ми позволи да намеря още няколко стотин, за които нито има данни в имотния регистър, нито самия кадастър беше отбелязал че е на религиозна организация.

Един голям проблем тук е, че много села не са въведени в кадастъра. Стотици църкви в тези села не намират място на картата ми, тъй като просто не съществуват в кадастъра. Липсата на кадастриален идентификатор значи, че е практически невъзможно да бъдат намерени в имотния регистър дори да има информация за собственостт там.

Храмовете

Както споменах по-горе, не използвах този източник за търсене на имоти. Първо, координатите в регистъра или липсват, или са грешни за много от храмовете. Второ, това, че църква е в парк, не значи, че поземленият имот е на църквата. Възможно да е само сградата. Това обаче изисква да имам точни координати, за да открия полигоните на обекта. Все пак, добавих всички известни храмове на картата, за да може да съпоставяте информацията събирана от Министерски съвет, имотите и какво виждате на място.

Това, което получих от този регистър обаче е списъка вероизповеданията. Намира се във файл с номенклатурите. Впрочем сайта на дирекцията беше паднал за две седмици, но използвах архивно копие, което пазя. Този списък не може да замести регистъра задължение на СГС, тъй като липсват много детайли.

Представяне на данните

Комбинирайки цялата тази информация създадох карта на имотите на всички вероизповедания в България. За да е по-прегледна при разглеждайки големи площи като области или цялата страна, показвам в началото с шестограми къде има най-много такава собственост. При увеличение на ниво град вече се виждат отделните поземлени имоти. Колкото по-тъмен е цветът на шестограмите или имотите, толкова повече територия е на религиозни организации в първия случай или толкова по-надеждна е информацията. Например, справка в имотния регистър е по-надеждно от косвените данни в кадастъра.

Когато натиснете на някой поземлен имот ще видите данни за него, както и каква информация за какви обекти в него или самия него съм намерил. Понякога има еднакви записи както от имотния регистър, така и в кадастъра, защото съм засякъл, че юридическото лице е по КИД 94.91.

Горе вляво има бутон за добавяне на всички известни храмове на картата. Работи само когато се увеличили на ниво град и виждате отделни парцели. Ако натиснете някой маркер ще видите името и вида на църквата или джамията или каквото е, името на вероизповеданието и съобщеното ѝ състояние. С другия бутон над него може да смените на сателитни снимки на мястото.

Картата може да разгледате тук или на цял екран.

Така от картата виждаме няколко интересни неща. Първо, тук виждаме набралата известност сграда по Шишман отчасти собственост на настоятелството на Ал. Невски. За това разбираме както от имотния регистър, така и от проверка в данните на кадастъра след справка в търговския регистър за ЕИК. В съседство виждаме обаче апартамент собственост на църква, цяла сграда собственост на софийската митрополия, още един парцел със сграда собственост на друга църква, 18 апартамента възстановени от нотариален акт от 1981 на синода и още два парцела и обекти на евангелистична църква.

На тази снимка е илюстрирано това, което описах в методологията. На картата ще видите отбелязан цял парк – в случая този на ул. Опълченска в София, а в детайлите се вижда, че има собственост само на един обект – в случая църква.

Виждаме и доста големи масиви из България. Голяма част от Рила, заради която започнах всичко това, както и земите около Бачково, Орехово, Сатовча, Мелник, Чепеларе, Сливен и Бургас. Има още много други из страната, но тези ми направиха най-голямо впечатление.

На следващата снимка виждаме индикация защо за още много имоти нямаме данни. Това е центъра на София. Виждаме Невски и Св. София вдясно и джамията и снагогата горе вляво. Виждат се обаче няколко православни църки, които не са отбелязани, включително Св. Петка и руската църква. Виждат се два молитвени домове на евангелисти и адвентисти, за които не намирам данни за собственост никъде. За сметка на това виждаме премного апартаменти и офиси пръснати из града и собственост на вероизповедания.

Липса на прозрачност

Целта на тази карта, както и всички останали, които съм правил, е да разберем по-добре какво е положението. Даряват се стотици милиони в публични средства, имоти и преки дарения към вероизповеданията. Това е добре и така следва да бъде. Дали следва да се дават публични средства и имоти и какъв да е механизма е въпрос на дебат, който изглежда не сме говори да проведем. Има доста противоречиви данни за това колко религиозни са българите и какво разбираме под религиозност. Преди девет години писах за това с импровизирано изследване. Изглежда БПЦ специално се притесняват да се отвори такъв дебат, за да не се окаже, че ще пресъхнат субсидиите и даренията, тъй като за разлика от немците много малко българи биха искали да им се взимат 8-9% от заплата и да се дават на местния свещеник.

От другата страна притеснения будят действията на редица вероизповедания и особено БПЦ с безотчетната си дейност. Доколкото следва да декларират печалби от наеми и търговия и да плащат данъци за тях, журналистически разследвания показват, че това практически не се случва. Имотите имат огромна роля в това и съществуват съмнения, че са инструмент за пране на тъмни капитали. На този фон постоянно се въртят каси и кампании за дарения за ремонт и строеж на църкви, които после заедно с общински имоти да бъдат прехвърляни синода. Имоти, които са били паркове и градинки, а биха могли да бъдат градини и училища.

Липсата на прозрачност кои юридически лица могат да си спестяват данъци и да остават необезпокоявани от регулаторите е повече от притеснителна. Затвореният с цел приход за хазната имотен регистър освен, че не позволява да разкрием измеренията на проблемите и вероятно злоупотребите в Агенцията по вписванията, пречи да видим кои имоти се управляват от тези лица. Вместо да се отвори повече, имотният регистър беше наскоро още повече ограничен със зле прикритата цел да попречи именно на журналистически разследвания.

Фасадна вяра

В този контекст всички вопли специално на БПЦ срещу Sofia Pride, срещу конвенцията на Съвета на Европа за превенция и борба с насилието над жени и домашното насилие в комбина на съветниците на Радев, срещу светското образование чрез въвеждането на ефективно вероучение – всички тези са изглежда са само шум за отклонение на вниманието от същинската дейност на синода – да е най-голямата агенция за недвижими имоти в България.

Не виждам никакви сигнали от патриарха нещо от това, от ролексите и скъпите коли да се промени. Не виждам инициативи от тях за подпомагане на болни, гладни, уязвими, зависими, на строежа на градини и училища. Не виждам каквото и да е усилие от няколкото традиционни за държавата изповедания да дадат отпор на външни капитали финансиращи откровени секти експлоатиращи уязвими групи в обществото ни. Не виждам усилия, визия или дори интерес у висшия клир за връщане на доверието у вярващите в искреността на каквото и да е излизащо от устата на митрополитите.

А това доверие е крайно важно. Има хора, които имат нужда от вяра и някаква форма на организирана религия. В това няма нищо лошо. Липсата на доверие и деструктивната роля, която БПЦ специално има за правата, образованието и дори здравето на хората неизменно кара много да търсят тази вяра в първият, която им обърне повече внимание. За съжаление, нашумяха случаи, а и доста от нас имат познати, за които това не е свършвало въобще добре. Това в допълнение на опитите за политическо и социално влияние.

С действията и отказа си от основната си мисия БПЦ като най-масовата у нас религия има косвена вина за всичко това. Щом настояват да се занимават предимно с имотите си, значи следва и ние да се вгледаме повече в тях.

From decentralized Docs-as-Code to a centralized repository: Evolving Grab’s documentation strategy

Post Syndicated from Grab Tech original https://engineering.grab.com/evolving-documentation-strategy

Introduction: The journey of documentation at Grab

In early 2021, Grab adopted a Docs-as-Code approach to address gaps in our technical documentation processes, as illustrated in our blog post Embracing a Docs-as-Code. Inspired by the practices of other market leaders, we integrated documentation into our engineers’ workflows, making it part of the codebase.

This approach addressed our initial documentation challenges by creating a single source of truth for engineers to search and build knowledge, making documentation upkeep necessary and less of an afterthought. After four years of use, we transitioned to a centralized documentation repository. This change was not about abandoning Docs-as-Code but adapting it to meet new and growing organizational needs.

This post walks through the motivations, benefits, and lessons from each phase of this journey, showing how our documentation strategy evolved.

What is Docs-as-Code?

Docs-as-Code is an approach that manages documentation with the same tools and workflows engineers use for source code. Content is written in plain-text Markdown, which is easy to edit in any code editor. Markdown is a lightweight markup language that uses simple, readable symbols like # for headings and * for lists to format text, and can be rendered to HTML and other outputs. It lives in version-controlled repositories (e.g., GitLab), so documentation evolves alongside code. Updates go through the same merge request reviews and automated CI/CD checks.

This integrated model lets teams at Grab build, test, and publish documentation as part of a pipeline. We then surface it through a centralized internal developer portal for easier discovery and implement governance for quality assurance.

Ideal use case at Grab

Imagine an engineer responsible for maintaining documentation for a product or platform managed by their team. This engineer creates comprehensive documentation in Markdown, containing pages such as an overview, a getting-started guide, how-tos, troubleshooting, FAQs, and related references for a specific platform. The documentation is included in the merge request and published on the documentation portal immediately after the code is merged. This seamless integration fosters a sense of ownership over the documentation. However, while this scenario is ideal, implementing it in practice presents significant challenges.

Problems we solved with Docs-as-Code

Before adopting a Docs-as-Code model, documentation was often scattered across Google Docs, slide decks, wikis, and ad hoc text files, which led to version confusion, poor discoverability, and gaps in quality assurance. Centralizing documentation in version-controlled repositories next to the code creates a single source of truth, ties updates to the same pull/merge request reviews, and enables automated checks such as link validation, style linting, and preview builds.

Industry practice reflects this shift: Kubernetes maintains its documentation as Markdown on the Kubernetes website, uses GitHub as a repository, and builds the site with Hugo, encouraging doc updates alongside feature work.

When documentation is embedded with the code and flows through the same CI/CD pipeline, engineers are more likely to update it in tandem with code changes. This method keeps the content up to date and in sync with releases by default. The TechDocs team can also set standardized metrics to uphold quality across all documentation and implement quality gates and blockers to ensure each document meets quality standards.

The limits of decentralized repositories

As Grab’s engineering footprint expanded, our decentralized Docs-as-Code approach began to strain at scale, surfacing friction that made documentation harder to discover, maintain, and ship with confidence.

Fragmented user experience and uneven standards

When documentation is scattered across many repositories and managed independently by teams, information architecture, voice, terminology, and granularity diverge. Similar concepts end up with different names, pages follow inconsistent navigation and templates, and redundant or misaligned guidance proliferates.

Ultimately, the search experience becomes noisy and unreliable as multiple versions of “the truth” surface. The impact shows up as longer onboarding, more tech support escalations, slower incident response when runbooks differ by team, and eroding trust that eventually pushes people toward tribal knowledge.

For the TechDocs team, decentralization made it hard to enforce standard templates, formatting, and quality gates. With documentation spread across many repositories, each with different or no linters, CI setups, and conventions, running organization-wide automation (linters, link checkers, readability checks) or applying uniform review steps was unreliable. This resulted in limited oversight and persistent inconsistencies, which degraded the user experience and trust in the documentation.

Difficulty keeping pace and staying discoverable

A fast-moving platform means decentralized documentation ages quickly and becomes hard to find. Frequent infrastructure and framework releases introduce breaking changes and deprecations. Teams struggled to stay informed, leading to missed opportunities for optimization and potential security risks due to outdated practices.

Meanwhile, with content sprawled across many repositories, managing and tracking the content became increasingly challenging for the team overseeing TechDocs. When teams changed the location of their source repositories, they often failed to notify the managing team, making it difficult to keep track of newer and updated locations. This lack of coordination created significant hurdles in discovering relevant documentation and maintaining a centralized record, ultimately impacting productivity and delaying decision-making.

Why we transitioned to a centralized repository

A centralized repository allowed us to address these scaling challenges while keeping the benefits of Docs-as-Code:

AI-driven enhancements

We are no longer writing only for human engineers. As we integrate more AI tools into our developer experience, our documentation also serves as the knowledge base for internal agents. A centralized, Markdown-based format gives agents clean, readable content in one location, which supports better integration, faster comprehension, and more accurate responses.

Improved quality assurance

Centralizing our documentation enabled the managing team to run automated linters for quality checks across all content. This helped ensure consistent standards, reducing manual oversight and minimizing the risk of errors. Contributors were also required to use the appropriate template for each document type, ensuring a consistent structure by default.

Unified search experience

The unified search experience changes how engineers access information. They can search for any topic and find relevant documentation without navigating multiple repositories. A global search overlay combines two methods: fuzzy page-title search for quick navigation and Glean-powered search across all TechDocs content. Glean is an enterprise search and AI assistant platform that integrates with internal tools to help users find and use information more efficiently. This search capability saves time and helps engineers stay informed.

Streamlined contribution process

While the decentralized model allowed engineers to use the GitLab web IDE, local editors, and GitLab CLI commands for faster updates, the transition to a centralized system helped streamline this process by offering a consistent editing environment. Even with these advanced tools, the centralized repository provided a unified location for all documentation, reducing the need to navigate across multiple repositories.

Centralization also gives the TechDocs team clearer visibility into documentation behavior and health. After implementing a centralized repository, the team extracted statistics on user activity: a new update is merged roughly every 50 minutes, with roughly 27 commits per day, and approximately 63% of changes being small to medium improvements. These signals point to ongoing documentation maintenance, with frequent touch-ups that fix typos, clarify steps, and keep guidance current rather than sporadic bulk updates. The image below illustrates how Grabbers use the centralized repository in practice.

Reflecting on the evolution

The transition was not without its hurdles. To bridge the gap left by decentralized Docs-as-Code workflows, we implemented:

  • Automated syncs: We synchronized critical content from service and platform repositories into a central hub to prevent gaps, while keeping the overlap period short to avoid two sources of truth and missed updates as legacy repos were retired.

  • Training sessions: We ran hands-on workshops to help engineers navigate the new platform and understand its benefits.

  • Continuous feedback: We set up surveys and regular check-ins to refine tooling and processes based on real-world usage.

Conclusion: choosing what works for your context

Docs-as-Code with decentralized and centralized repositories are not mutually exclusive; they excel in different contexts and can be combined. Decentralized authoring works well when engineers are the primary contributors and documentation naturally ships with code. Centralization becomes valuable when you optimize for organization-wide discoverability, consistency, governance, and analytics. We conclude with these findings from our shift to a centralized Docs-as-Code repository:

  • Use decentralized Docs-as-Code when teams need autonomy and documentation is tightly coupled to services.
  • Use a centralized repository when you need a single source of truth for discovery, standardized templates and style, consistent CI checks, ownership metadata, and clearer compliance and review gates.
  • Consider a hybrid approach: authors create documentation in service repos and publish to a central portal with shared templates, ownership metadata, automated quality checks, and centralized discovery and governance.

At Grab, decentralized Docs-as-Code fostered strong ownership early on. As we scaled and our audience broadened, a centralized repository and unified discovery surface became essential to maintain consistency, improve findability, and support diverse user needs. Documentation strategies evolve with the organization. The goal is not picking one model forever, but recognizing the signals to pivot and adapting so engineers can reliably find the right information at the right time.

Join us

Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Silicon Motion’s SM2524XT is a New PCIe Gen5 DRAM-less SSD Controller for AI PCs

Post Syndicated from Vic A original https://www.servethehome.com/silicon-motions-sm2524xt-is-a-new-pcie-gen5-dram-less-ssd-controller-for-ai-pcs/

The new Silicon Motion SM2524XT is a quad core Arm SSD controller for newer faster DRAM-less PCIe Gen5 SSDs

The post Silicon Motion’s SM2524XT is a New PCIe Gen5 DRAM-less SSD Controller for AI PCs appeared first on ServeTheHome.

Why and how to migrate to a Transit Gateway-attached AWS Network Firewall

Post Syndicated from Frank Phillis original https://aws.amazon.com/blogs/security/why-and-how-to-migrate-to-a-transit-gateway-attached-aws-network-firewall/

AWS Network Firewall now supports native attachment to AWS Transit Gateway. Customers commonly use Transit Gateway to route traffic from Amazon Virtual Private Cloud (Amazon VPC) networks to a centralized inspection VPC (a VPC dedicated to hosting firewall endpoints for traffic inspection) where their network firewall endpoints are deployed. This centralized deployment model reduces the need to have Network Firewall endpoints in each VPC, optimizing costs and providing a centralized point of network security control.

Customers deploying Network Firewall in a centralized deployment model using Transit Gateway have traditionally set up a dedicated inspection VPC with firewall subnets and managed the associated routing to direct traffic through the firewall. With native attachment, Network Firewall attaches directly to Transit Gateway, eliminating the need for the inspection VPC and enabling capabilities such as flexible cost allocation through Transit Gateway metering policies.

In this post, we explain what a Transit Gateway-attached network firewall is, the technical capabilities it unlocks, reasons to migrate to it, and how to perform the migration. For detailed step-by-step guidance on how to perform the migration using Terraform, AWS CloudFormation, or manually in the AWS Management Console, see the accompanying migration guide repository.

What is a Transit Gateway-attached network firewall?

A Transit Gateway-attached network firewall simplifies your network architecture by eliminating the need for a dedicated inspection VPC. Instead of creating an inspection VPC with firewall subnets and configuring the associated routing, you create your network firewall and specify which Transit Gateway instance you want to attach it to. AWS deploys the firewall endpoints into an AWS-managed VPC on your behalf. You don’t own or manage that VPC. From your perspective, the firewall appears as a Transit Gateway network function attachment that you route traffic to, similar to other Transit Gateway attachments.

Why migrate to a Transit Gateway-attached network firewall?

You might want to migrate to a Transit Gateway-attached network firewall for the following reasons:

  • Access to flexible cost allocation: With native attachment, you can use Transit Gateway metering policies to charge back account owners for traffic they send through the centralized firewall. Flexible cost allocation for Network Firewall traffic over a Transit Gateway is only available with a Transit Gateway-attached firewall. Without native attachment, you can only allocate Transit Gateway data processing charges, not the Network Firewall charges.
  • Reduced architectural complexity: You can eliminate the inspection VPC, leaving one less VPC to manage along with its associated routing tables and subnets.

Preparing for the change

Before migrating to a Transit Gateway-attached network firewall, gather the following information and keep these key considerations in mind.

Prerequisites

When you create your new Transit Gateway-attached network firewall, you will need:

  • Transit Gateway ID: The ID of the Transit Gateway instance you will attach your network firewall to.
  • Logging configuration: Create a new logging configuration (such as new Amazon CloudWatch log groups) for the new firewall. During migration, you will be running both firewalls simultaneously. Keeping the logs separate simplifies monitoring and troubleshooting each firewall during the migration period. After migration is complete, you can point the new firewall to your existing logging destinations.
  • Firewall policy: Create a new firewall policy for the new firewall rather than reusing your existing one. During the migration period, a separate policy lets you make changes to the new firewall’s policy without affecting the existing firewall while both are running simultaneously. After migration is complete, you can attach your existing production policy to the new firewall.

Key considerations

There are some important considerations to address while planning for this change.

  • Transit Gateway encryption: Check if you’re using Transit Gateway encryption support. If encryption is enabled and required for your security posture, native attachment to Network Firewall doesn’t currently support this capability. You will need to continue using your current firewall configuration.
  • NAT gateway Elastic IPs: If you need to maintain the same public IPs (for example, for partner allowlisting), plan for this during migration. For more information, see the Preserving your NAT gateway Elastic IPs during migration section later in this post.
  • Maintenance window: Plan to perform this migration during a dedicated maintenance window. Brief network outages will occur during parts of the process, such as when swapping Transit Gateway route table associations and replacing NAT gateways.

Performing the migration

Leave your existing Network Firewall setup unchanged while setting up the new Transit Gateway-attached firewall. With this approach, you can minimize potential downtime and test the new configuration before migrating production traffic.

The migration process varies depending on your current architecture. The following sections walk through the two most common centralized Network Firewall architectures and the high-level migration process for each. For detailed step-by-step guidance on how to perform the migration using Terraform, CloudFormation, or manually in the console, see the migration guide repository.

Architecture 1: Dedicated inspection VPC with separate egress VPC

In this architecture, shown in the following diagram, you have a dedicated inspection VPC with your network firewall endpoints, and a separate dedicated egress VPC with your NAT gateways.

Figure 1: Centralized egress traffic inspection with Network Firewall and Transit Gateway, with inspection and egress separated into two VPCs.

Figure 1: Centralized egress traffic inspection with Network Firewall and Transit Gateway, with inspection and egress separated into two VPCs.

The high-level migration process for this architecture is:

  1. Deploy a new egress VPC with a temporary NAT gateway. Creating a new VPC lets you leave the existing deployment unchanged while working on the migration.
  2. Create your new network firewall with native attachment to your Transit Gateway.
  3. Configure three new Transit Gateway route tables to define the traffic path through the new firewall: an inspection route table (associated with the new firewall), an egress route table (associated with the new egress VPC), and a temporary migrated spoke route table (for testing individual spoke VPCs on the new path).
  4. Test the new firewall by moving a single spoke VPC to the new path. Verify connectivity and confirm the firewall is inspecting traffic by checking the alert logs for layer 7 (application layer) details. Layer 7 information in the alert logs indicates the firewall is seeing both directions of the traffic flow. If asymmetric routing were occurring, the firewall would only see one direction and would not be able to perform application-layer inspection, so the presence of layer 7 details confirms traffic is flowing symmetrically through the new firewall.
  5. Migrate the remaining spoke VPCs. You can migrate VPCs incrementally, or when you’re confident in the new firewall deployment, update the default route in your existing spoke route table to point to the new Network Firewall network function attachment, which moves all remaining spokes that share that route table at once.
  6. Optionally, preserve your original NAT gateway Elastic IPs by re-routing traffic back to your existing egress VPC (see Preserving your NAT gateway Elastic IPs during migration).
  7. Decommission old resources after you’ve verified that traffic is flowing correctly. Which VPCs you remove depends on whether you preserved your original EIPs (see Preserving your NAT gateway Elastic IPs during migration).
Figure 2: Post-migration architecture for Architecture 1, with the inspection VPC eliminated and traffic flowing through the Transit Gateway-attached Network Firewall to a dedicated egress VPC.

Figure 2: Post-migration architecture for Architecture 1, with the inspection VPC eliminated and traffic flowing through the Transit Gateway-attached Network Firewall to a dedicated egress VPC.

For the complete walkthrough of how to perform this migration:

Architecture 2: Combined inspection and egress VPC

In this architecture, shown in the following diagram, you have a single VPC that contains both your network firewall endpoints and your NAT gateways.

Figure 3: Centralized egress traffic inspection with Network Firewall and Transit Gateway, with inspection and egress combined in one VPC.

Figure 3: Centralized egress traffic inspection with Network Firewall and Transit Gateway, with inspection and egress combined in one VPC.

The migration process for this architecture follows the same high-level steps as Architecture 1.

  1. Deploy a new dedicated egress VPC with a temporary NAT gateway. Creating a new VPC lets you leave the existing deployment unchanged while working on the migration.
  2. Create your new network firewall with native attachment to your Transit Gateway.
  3. Configure three new Transit Gateway route tables to define the traffic path through the new firewall: an inspection route table, an egress route table, and a temporary migrated spoke route table.
  4. Test the new firewall by moving a single spoke VPC to the new path. Verify connectivity and confirm the firewall is inspecting traffic by checking the alert logs for layer 7 (application layer) details. Layer 7 information in the alert logs indicates the firewall is seeing both directions of the traffic flow. If asymmetric routing were occurring, the firewall would only see one direction and would not be able to perform application-layer inspection, so the presence of layer 7 details confirms traffic is flowing symmetrically through the new firewall.
  5. Migrate the remaining spoke VPCs. You can migrate VPCs incrementally, or once you are confident in the new firewall deployment, update the default route in your existing spoke route table to point to the new Network Firewall network function attachment, which moves all remaining spokes that share that route table at once.
  6. Optionally, preserve your original NAT gateway Elastic IPs by transferring them to the new egress VPC.
  7. Decommission the old combined VPC after you’ve verified that traffic is flowing correctly.
Figure 4: Post-migration architecture for Architecture 2, with the combined VPC eliminated and traffic flowing through the Transit Gateway-attached Network Firewall to a dedicated egress VPC.

Figure 4: Post-migration architecture for Architecture 2, with the combined VPC eliminated and traffic flowing through the Transit Gateway-attached Network Firewall to a dedicated egress VPC.

For the complete walkthrough of how to perform this migration, see:

Differences between the two migrations

Both architectures deploy the same new resources and use the same phased cutover approach. The differences are in the starting Transit Gateway routing structure (Architecture 1 has three route tables across two VPCs, Architecture 2 has two route tables in one VPC) and what you clean up at the end (two old VPCs instead of one). Both architectures converge to the same end state. For a detailed comparison, see the migration guide repository.

Minimizing downtime and testing your migration

Regardless of which architecture you’re migrating from, follow these best practices to minimize risk.

The migration guide repository includes starting architecture CloudFormation and Terraform templates for both architectures, so you can deploy the exact starting environment in a development or test account and run through the entire migration process before touching production.

Test before you migrate. Create your new Transit Gateway-attached firewall in parallel with your existing setup. Use a test VPC to validate the new configuration. Verify that logging is working correctly and that the firewall alert logs show layer 7 traffic details, which confirms there is no asymmetric routing. Test both allowed and blocked traffic scenarios before migrating production traffic.

Migrate in phases. Start with a single, non-critical workload VPC. Update only that VPC’s routes to use the new firewall attachment. Monitor and verify application behavior and performance with the application owner before proceeding. When planning your migration order, migrate spoke VPCs that have east-west traffic between each other at the same time. During the phased migration, spokes on different firewall paths will have their east-west traffic traverse two stateful firewalls. Because each stateful firewall independently tracks connection state, traffic that enters through one firewall and returns through another appears as untracked, causing the firewalls to drop or incorrectly handle the return traffic. When you’re confident in the new firewall deployment, you can update the default route in your existing spoke route table to point to the new firewall, which moves all remaining spokes that share that route table at once. Keep your old firewall configuration active until all traffic is migrated.

Prepare a rollback plan. Document your current route table configurations before making changes. Keep your existing firewall and inspection VPC active during migration. If issues arise, revert the route table changes to restore the previous configuration. Decommission old resources after you’ve verified applications are operating as expected.

Preserving your NAT gateway Elastic IPs during migration

An important consideration during migration is maintaining your existing NAT gateway Elastic IP addresses. Many organizations have these IPs allowlisted with external partners, third-party services, or in firewall rules. Changing these IPs would require coordination with multiple stakeholders and could disrupt business operations.

During migration, you need both your old and new deployments to operate simultaneously, so you can validate the new setup without impacting production traffic. This means creating temporary NAT gateways with temporary Elastic IPs in the new egress VPC.

After you’ve confirmed the new firewall deployment is stable and production traffic has been successfully migrated, you can restore your original Elastic IPs. The process differs depending on your architecture:

  • For Architecture 1 (separate inspection and egress VPCs), your existing egress VPC and its NAT gateways are independent of the inspection VPC being decommissioned. You can keep them by re-associating the existing egress VPC’s Transit Gateway attachment with the new egress route table and updating the inspection route table to route traffic there instead of the temporary egress VPC. This is a Transit Gateway routing change that takes seconds, doesn’t require deleting or creating any NAT gateways, and doesn’t increase in complexity with the number of Availability Zones. After the re-association, you delete the temporary egress VPC.
  • For Architecture 2 (combined inspection and egress VPC), the old VPC contains both the firewall endpoints and the NAT gateways. The simplest path is to decommission it and move the Elastic IPs to the new egress VPC. To do this, you delete the old NAT gateways to free the Elastic IPs, then create new NAT gateways in the new egress VPC with the original Elastic IPs. This requires a brief maintenance window while the new NAT gateways provision and must be repeated for each Availability Zone.

For the detailed step-by-step procedure, see the EIP preservation steps in the migration guide repository.

Conclusion

In this post, we explained what a Transit Gateway-attached network firewall is and how it differs from the traditional inspection VPC model, the reasons to migrate including reduced architectural complexity and flexible cost allocation, what to prepare before starting, and the high-level migration process for the two most common centralized inspection architectures. We also covered best practices for minimizing downtime, handling east-west traffic between spokes during phased migration, and preserving your existing NAT gateway Elastic IPs.

With a Transit Gateway-attached network firewall, AWS manages the firewall endpoints and the underlying VPC on your behalf, eliminating the inspection VPC from your architecture and enabling flexible cost allocation through Transit Gateway metering policies. The phased migration approach covered in this post lets you run both firewalls in parallel, validate the new path with a single spoke VPC, and cut over the rest of your traffic when you are ready.

For detailed step-by-step guidance using Terraform, CloudFormation, or the AWS Management Console for both architectures covered in this post, see the migration guide repository. The repository includes starting architecture templates so you can practice the full migration end-to-end in a test account before migrating your production environment.

If you have feedback about this post, submit comments in the Comments section below.


Frank Phillis

Frank Phillis

Frank is a Senior Solutions Architect (Security) at AWS. He enables customers to get their security architecture right. Frank specializes in cryptography, identity, and incident response. He’s the creator of the popular AWS Incident Response playbooks and regularly speaks at security events. When not thinking about tech, Frank can be found with his family, riding bikes, or making music.

Lawton Pittenger

Lawton Pittenger

Lawton is a Worldwide Security Specialist Solutions Architect at AWS, based in New York City. He specializes in helping customers design and implement effective network security controls. At AWS, he works with customers at scale and collaborates closely with service teams to drive continuous improvement in security services based on customer needs and feedback. Outside of work, his interests include skateboarding, snowboarding, and spending time in nature.

Introducing the next generation of AWS Resilience Hub for generative AI-based SRE resilience journey

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-aws-resilience-hub-for-generative-ai-based-sre-resilience-journey/

Today, we’re announcing the next generation of AWS Resilience Hub with a significantly expanded experience that brings together a new application model, dependency discovery assessment, generative AI-powered failure mode analysis, modular resilience policies, and organization-wide reporting.

Organizations running hundreds of applications share a common challenge: availability is a top concern, yet there is no consistent way to set resilience goals, measure progress, or prove compliance across a portfolio. Teams set different standards, use different tools, and struggle to exchange information about whether applications actually meet expectations.

The next generation of AWS Resilience Hub changes this by giving Site Reliability Engineers (SREs) and development teams a structured way to align on resilience policy expectations, help application teams achieve them, and demonstrate compliance through testing. With integration into AWS Organizations, teams can now evaluate resilience at scale, identify failure modes, discover hidden dependencies, and report on progress across the enterprise.

The next generation of Resilience Hub walks you through your resilience journey and to help you there are the following concepts built into it.

  • Resilience policy: You can define your resilience expectations through modular, composable requirements. Rather than choosing a single rigid policy type, you construct policies by selecting the requirements that matter to your application, such as service level objective (SLO), multi-AZ and multi-Region disaster recovery, and data recovery requirements.
  • Business-level understanding: You can use new application modeling through critical end-user paths that map directly to business outcomes. Systems represent a business application, user journeys describe critical business paths, and services are the deployable units comprising AWS resources, code, and observability. Resilience Hub automatically discovers and maps them into a topology showing how resources connect.
  • AI failure mode assessments: You can run generative AI-powered assessments that analyze your services against your defined resilience policies, AWS Well-Architected best practices, and the AWS Resilience Analysis Framework. These assessments identify potential failure modes and provide actionable recommendations.
  • Dependency discovery assessment: You can automatically discover AWS services, internal endpoints, and third-party endpoints that your services depend on. This dependency assessment uses DNS query log analysis to identify dependencies you may not know about—including unexpected cross-region calls or critical third-party dependencies.

The next generation of AWS Resilience Hub in action
To get started, you configure a resilience policy, set up your first system and service, run a failure mode assessment, review the results, and implement the findings.

Before you begin, you should set up the invoker IAM role, which grants Resilience Hub read-only access to your AWS resources, cross-account roles (if not using AWS Organizations), or service-linked roles (SLRs) with AWS Organizations. Resilience Hub also integrates with AWS Organizations to enable organization-wide resilience management from a single delegated administrator account. This eliminates the need to log in to individual accounts to assess resilience posture across your enterprise. To learn more, visit For prerequisite details in the AWS Resilience Hub User Guide.

To configure a resilience policy, choose Create policy in the Policies menu through the AWS Resilience Hub console. Enter a policy name, description, and choose resilience requirements. For example, you can create a reusable policy for multi-Region disaster recovery used in financial applications—including 99.95% availability SLO, 15-minutes RTO, 5-minutes RPO for multi-Region disaster recovery, and disaster recovery approach that aligns with your RTO and RPO requirements.

If you choose data recovery requirements, you can define the data recovery time objective for restoring from backups for each service associated with this policy.

To create your first system representing your business application, choose Create a system in the Systems menu. Optionally, you can enable AWS Organizations account access for this system.

Now you can create a service that represents a deployable unit, like one of your microservices, and associate it with your system, and tell Resilience Hub where to find your resources. Enter a service name, for example, stock-exchange-service, choose your resilience policy and invoker AWS IAM role name. You can choose service Regions, service resources such as your resource tags, AWS CloudFormation stack, Terraform state file location, or Amazon EKS cluster and namespace.

When you enable dependency discovery for this service, AWS examines your VPC query logs for the VPCs associated with the resources in your service. You can disable this feature anytime from the dependency discovery settings in the service details page.

Now, you can run your first assessment with the service creation complete and a policy applied. Choose Run failure mode assessment in your service page and wait for the assessment to complete.

During the assessment, Resilience Hub assumes your invoker role, reads resources from your configured input sources, identifies parent-child relationships, queries the application topology service to map connections between resources, and builds a topology showing data flow, containment, and permissions.

By choosing Service topology, you can see service resources grouped by service functions in the graph, table, or JSON format.

By choosing Failure mode guidance, you can add assertions used to guide the agents while performing the failure mode assessment. Assertions are either generated by the agent or added by users. You can update them to improve assessment accuracy.

Once the assessment is complete, you can review findings and recommendations in the Assessment tab of your service page. Each finding tells you what the failure mode is, why it matters for your architecture, how to fix it, and which policy requirement it relates to.

You can choose Mark as resolved to implement the recommendation or Mark as irrelevant if the finding doesn’t apply to your use case.

If you’re an existing Resilience Hub customer, Resilience Hub provides migration APIs to simplify the transition of your previous applications. These APIs convert your previous assessment policies to new resilience policies, map your previous applications to the new model, such as multiple related applications to one system with multiple services.

For more information about new features, visit the AWS Resilience Hub User Guide.

Now available
The next generation of AWS Resilience Hub is now generally available in AWS commercial Regions where Resilience Hub is available. For Regional availability and the future roadmap, visit the AWS Capabilities by Region.

Resilience Hub uses a new service-based pricing model. Pricing includes two failure mode assessments per month for services, and optionally automated dependency assessment. You can try AWS Resilience Hub free. For pricing details, visit the AWS Resilience Hub pricing page.

Give the new AWS Resilience Hub a try in the Resilience Hub console and send feedback to AWS re:Post for Resilience Hub or through your usual AWS Support contacts.

Channy

Simplifying policy management with URL and Domain Category filtering on AWS Network Firewall

Post Syndicated from Lawton Pittenger original https://aws.amazon.com/blogs/security/simplifying-policy-management-with-url-and-domain-category-filtering-on-aws-network-firewall/

Network administrators face a persistent challenge: maintaining domain blocklists and allowlists that keep pace with the internet. New websites and services emerge daily, and keeping these lists current requires constant manual updates that leave gaps in coverage. This challenge intensifies when managing access to rapidly evolving categories like AI services, where new tools launch on a regular basis.

AWS Network Firewall is a managed, stateful network firewall and intrusion detection and prevention service for fine-grained control of your virtual private cloud (VPC) network traffic. With URL and domain category filtering, security teams can use predefined categories to control access instead of managing individual domains. AWS-managed URL and domain categories stay current automatically as new domains are registered, removing the need for manual list maintenance.

This feature is especially useful for organizations navigating AI governance. Instead of manually tracking every new AI service, you can control access to the entire Artificial Intelligence and Machine Learning category while creating exceptions for approved services. The same approach works for social media, streaming sites, gambling, and dozens of other categories, all with built-in audit trails for compliance reporting.

In this post, we walk through URL and domain category filtering configurations for AWS Network Firewall, from basic rules to exception handling and monitoring strategies that give you visibility into how your workloads interact with external services.

Streamlined policy management with predefined categories

With URL and domain category filtering, you control website access using predefined categories instead of individually specifying sites in a domain list rule group. You can select from AWS-managed categories such as Social Networking, Gambling, or Artificial Intelligence and Machine Learning to implement and maintain filtering policies. AWS keeps these categories current automatically, so you don’t need to update firewall policies when new domains are registered.

Network Firewall offers two category filtering options. Domain category filters by domain name using the TLS Server Name Indication (SNI) field, with no decryption required. URL category filters by the full URL path, which requires TLS inspection for HTTPS traffic. To keep things straightforward, this post focuses on domain category filtering. To set up URL category filtering with TLS inspection, see Creating a TLS inspection configuration in Network Firewall.

Prerequisites

To follow the steps in this post, start by making sure that you have the following prerequisites in place:

  1. An existing Network Firewall deployment: This walkthrough assumes you have an existing Network Firewall deployment to filter egress traffic flows from your Amazon Virtual Private Cloud (Amazon VPC) in place. If you aren’t already using Network Firewall, see Getting started with AWS Network Firewall to set up your firewall before proceeding.
  2. The HOME_NET variable set correctly at the firewall policy level: The rules in this post use the $HOME_NET variable to scope traffic to your internal network. In the AWS Management Console for Amazon VPC, select your firewall policy under the Firewall policies tab, select the Details tab, and check the policy variables section under HOME_NET variable override values. We recommend setting this to all RFC 1918 private IP address ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. When you set $HOME_NET at the policy level, all rule groups associated with that policy inherit the value automatically. Network Firewall automatically maps $EXTERNAL_NET to the inverse of $HOME_NET, so configuring HOME_NET correctly also configures $EXTERNAL_NET.
Figure 1: Firewall policy details tab showing the HOME_NET variable override values set to RFC 1918 private IP address ranges

Figure 1: Firewall policy details tab showing the HOME_NET variable override values set to RFC 1918 private IP address ranges

Create a category rule using the console rule builder

To get started quickly, you can create a domain category rule using the console’s built-in rule builder. In this example, we create a single alert rule for the Artificial Intelligence and Machine Learning category.

  1. Open the AWS Management Console, search for and open the Amazon VPC console.
  2. In the left navigation, scroll to Network Firewall and select Rule groups.
  3. Choose Create rule group.
  4. For Rule group type, select Stateful rule group.
  5. For Rule group format, select Standard stateful rules.
  6. For Rule evaluation order, select Strict order. Choose Next.
    Figure 2: Create Network Firewall rule group page showing Stateful rule group type, Standard stateful rules format, and Strict order evaluation selected

    Figure 2: Create Network Firewall rule group page showing Stateful rule group type, Standard stateful rules format, and Strict order evaluation selected

  7. Enter Domain-Category-Rules for the Name, Domain Category Rules for the Description, and 50 for the Capacity. Choose Next.
  8. In the rule group editor, select the Category Matching radio button.
  9. Under Category Matching, select Match all selected categories.
  10. Under AWS category type, select Domain Category from the dropdown.
  11. Under Categories, select Artificial Intelligence and Machine Learning.
  12. For Protocol, select TLS.
  13. For Source, select Custom, then enter $HOME_NET in the dialog box.
  14. Set the Destination IP to Any.
  15. For Action, select Alert.
  16. Choose Add rule to add this rule to the rule group. Choose Next.
    Figure 3: Completed category matching rule showing TLS protocol, $HOME_NET source, Any destination, and Alert action added to the rule group

    Figure 3: Completed category matching rule showing TLS protocol, $HOME_NET source, Any destination, and Alert action added to the rule group

  17. Under Customer managed key, leave the default setting (Customize encryption settings should remain unchecked).
  18. Under Add tags – optional, leave the default setting of no tags.
  19. Choose Next, then Create rule group.

This rule generates an alert log entry each time a connection matches a domain in the Artificial Intelligence and Machine Learning category. It doesn’t block traffic. To block traffic, change the action to Drop or Reject in step 15.

Creating the same rule using Suricata compatible rule strings

The console rule builder is a quick way to get started, but we recommend using Suricata compatible rule strings for production deployments. Suricata rules give you full control over rule options, make rules straightforward to copy, edit, share, and back up, and support the majority of the Suricata engine. For more information, see Limitations and caveats for stateful rules in AWS Network Firewall.

The following walkthrough creates the same alert rule you built with the console rule builder, this time using a Suricata rule string.

In the Amazon VPC console, navigate to Network Firewall, then select Network Firewall rule groups.

  1. Choose Create rule group.
  2. For Rule group type, select Stateful rule group.
  3. For Rule group format, select Suricata compatible rule string.
  4. For Rule evaluation order, select Strict order. Choose Next.
    Figure 4: Create Network Firewall rule group page showing Stateful rule group type, Suricata compatible rule string format, and Strict order evaluation selected

    Figure 4: Create Network Firewall rule group page showing Stateful rule group type, Suricata compatible rule string format, and Strict order evaluation selected

  5. Enter Suricata-Domain-Category-Rules for the Name, Suricata Domain Category Rules for the Description, and 50 for the Capacity. Choose Next.
  6. Leave the Rule variables section empty. The $HOME_NET variable is inherited from the firewall policy, as configured in the prerequisites.
  7. Leave IP set references empty.
  8. Paste the following rule into the Suricata compatible rule string editor:
    alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Artificial Intelligence and Machine Learning Category"; aws_domain_category:Artificial Intelligence and Machine Learning; sid:1000001;)

  9. Choose Next.
    Figure 5: Suricata compatible rule string editor with the domain category alert rule pasted in and the rule variables section left empty

    Figure 5: Suricata compatible rule string editor with the domain category alert rule pasted in and the rule variables section left empty

  10. Under Customer managed key, leave the default setting (Customize encryption settings should remain unchecked).
  11. Under Add tags – optional, leave the default setting of no tags. Choose Next.
  12. Choose Create rule group.
  13. After creating the rule group, return to your firewall policy and add it under Stateful rule groups. We recommend associating new rule groups in a development or test environment first to validate behavior before deploying to production.

The following table explains each component of this rule:

alert Action: generate an alert log entry when the rule matches. Other actions include pass, drop, and reject.
tls Protocol: inspect TLS traffic, matching against the SNI field in the TLS Client Hello.
$HOME_NET any -> $EXTERNAL_NET any Source and destination: match traffic from any internal IP address (HOME_NET) and port to any external IP address (EXTERNAL_NET) and port. The HOME_NET variable defines your internal network ranges, and the EXTERNAL_NET variable is automatically set to the inverse.
msg:”Artificial Intelligence and Machine Learning Category” The message written to the alert log when this rule is triggered.
aws_domain_category:Artificial Intelligence and Machine Learning The AWS-managed domain category to match against. The firewall looks up the destination domain in the category database and matches if the domain belongs to this category.
sid:1000001 A unique signature ID for this rule. Each rule in a rule group must have a unique SID.

Managing exceptions for approved services

You can manage exceptions to keep business-critical websites accessible. For example, say you need to allow access to OpenAI while blocking all other AI and ML traffic. To do this, return to the Suricata-Domain-Category-Rules rule group you created earlier and replace the basic alert rule with the following ruleset. Select the Suricata-Domain-Category-Rules rule group, under the Rules section, choose Edit.

Figure 6: Selecting Suricata-Domain-Category-Rules rule group to edit with new rules

Figure 6: Selecting Suricata-Domain-Category-Rules rule group to edit with new rules

Paste in the following rules and choose Save rule group.

# Allow OpenAI (TLS)
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over TLS"; sid:1000001;)

# Allow OpenAI (HTTP)
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over HTTP"; sid:1000002;)

# Block all other AI/ML category traffic (TLS)
reject tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over TLS"; aws_domain_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000003;)

# Block all other AI/ML category traffic (HTTP)
reject http $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over HTTP"; aws_url_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000004;)

Figure 7: Suricata compatible rule string editor with the exception-based ruleset containing pass rules for OpenAI and reject rules for the AI/ML category

Figure 7: Suricata compatible rule string editor with the exception-based ruleset containing pass rules for OpenAI and reject rules for the AI/ML category

With strict order evaluation, the firewall evaluates rules in the order you define them. The pass rules for OpenAI appear first, so matching traffic is allowed before the broader category block rules run.

To verify the rules are working as expected, test from a host that routes traffic through your network firewall. These commands suppress the response body and check the exit code of the curl request. If curl completes a TCP connection, it prints CONNECTION ALLOWED. If the firewall resets the connection, curl exits with a non-zero code and prints CONNECTION BLOCKED.

A request to openai.com should succeed because it matches the pass rule:

curl -s -o /dev/null https://openai.com && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"

Result: CONNECTION ALLOWED

A request to chat.mistral.ai should be rejected because it matches the broader AI/ML category block rule:

curl -s -o /dev/null https://chat.mistral.ai && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"

Result: CONNECTION BLOCKED

How to monitor category usage

When you add a domain category rule to your firewall policy, Network Firewall performs a category lookup for every connection that matches the rule’s protocol and IP specifications. The rules in this post match on $HOME_NET any -> $EXTERNAL_NET any, which means the firewall looks up the category for all outbound traffic originating from your internal network. This is why it’s important to have the $HOME_NET variable configured correctly at the firewall policy level. With this configuration, a single category rule is enough for category metadata to appear in your firewall logs across all matching connections, not just connections that match the specific category in your rule.

Each log entry includes an aws_category field containing a JSON array of all categories the destination domain belongs to. A single domain can map to multiple categories. For example, a request to chat.mistral.ai produces a log entry with “aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]” because that domain belongs to both categories.

You can access firewall logs through Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3), and Amazon Data Firehose. These logs show which categorized websites your workloads access, helping you track usage patterns and enforce acceptable use policies.

The following sample log entry shows what a blocked request to chat.mistral.ai looks like using the exception-based rules from the previous section. The alert.signature field contains the rule’s msg value, and the aws_category field lists all categories the destination domain belongs to:

{ 

     "firewall_name": "egress-and-east-west-firewall", 

     "availability_zone": "us-east-1a", 

     "event_timestamp": "1775599146", 

     "event": { 

          "aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]", 

          "tx_id": 0, 

          "app_proto": "tls", 

          "src_ip": "10.1.1.100", 

          "src_port": 58664, 

          "event_type": "alert", 

          "alert": { 

                    "severity": 3, 

                    "signature_id": 1000003, 

                    "rev": 1, "signature": 

                    "Block non-approved AI/ML sites over TLS", 

                    "action": "blocked", 

                    "category": "" 

          }, 

          "flow_id": 763153567844057, 

          "dest_ip": "172.66.2.203", 

          "proto": "TCP", 

          "verdict": { 

                    "action": "drop", 

                    "reject-target": "to_client", 

                    "reject": [ 

                         "tcp-reset" 

                    ] 

          }, 

          "tls": { 

               "sni": "chat.mistral.ai", 

               "version": "UNDETERMINED" 

          }, 

          "dest_port": 443, 

          "pkt_src": "geneve encapsulation", 

          "timestamp": "2026-04-07T21:59:06.906761+0000", 

          "direction": "to_server" 

     } 

} 

The aws_category field shows the domain belongs to both the “Social Networking” and “Artificial Intelligence and Machine Learning” categories. The verdict field confirms the connection was dropped with a TCP reset sent to the client.

Traffic that matches a pass rule with the alert keyword also generates a log entry with the aws_category field populated. For example, a connection to chat.openai.com that matches the OpenAI exception rule from the earlier section produces a log entry with alert.action set to “allowed” and the same category metadata. This means your queries capture both blocked and allowed traffic.

Querying logs with CloudWatch Logs Insights

If you send your firewall logs to Amazon CloudWatch Logs, you can use CloudWatch Logs Insights to analyze category traffic patterns. A single connection can generate multiple log entries (for example, a reject rule log and a default action log for the same flow), so the following queries deduplicate by flow_id to count each connection only once. Because a single domain can belong to multiple categories, results are grouped by category combination. For example, traffic to a domain categorized as both “Social Networking” and “Artificial Intelligence and Machine Learning” appears as a single combined entry.

To get started, navigate to the CloudWatch console. In the left navigation pane under Logs, select Logs Insights. Under Query scope, leave Log group name selected, then select your AWS Network Firewall alert logs log group. For the time window, we recommend starting with the default of 1 hour to keep the queries light. Enter each of the following queries into the editor and choose Run query to review the results. Note that CloudWatch Logs Insights queries incur charges based on the amount of data scanned. See Amazon CloudWatch pricing for details.

Most accessed categories

This query shows which category combinations your workloads connect to most frequently:

fields @timestamp, event.aws_category, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories by event.flow_id
| stats count(*) as connections by categories
| sort connections desc
| limit 20

Figure 8: CloudWatch Logs Insights query results showing the most frequently accessed category combinations sorted by connection count

Figure 8: CloudWatch Logs Insights query results showing the most frequently accessed category combinations sorted by connection count

Least accessed categories

This query reverses the sort order to surface category combinations with the fewest connections, helping you identify categories that might not be relevant to your environment or that warrant further investigation:

fields @timestamp, event.aws_category, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories by event.flow_id
| stats count(*) as connections by categories
| sort connections asc
| limit 20

Figure 9: CloudWatch Logs Insights query results showing the least frequently accessed category combinations sorted by connection count ascending

Figure 9: CloudWatch Logs Insights query results showing the least frequently accessed category combinations sorted by connection count ascending

Most accessed categories, allowed traffic only

The event.verdict.action field indicates the actual outcome of each connection:drop for blocked traffic and alert for allowed traffic. This query shows which category combinations have the most allowed connections:

fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
| filter verdict = "alert"
| stats count(*) as connections by categories
| sort connections desc
| limit 20

Figure 10: CloudWatch Logs Insights query results showing the most accessed category combinations filtered to allowed traffic only

Figure 10: CloudWatch Logs Insights query results showing the most accessed category combinations filtered to allowed traffic only

Most accessed categories, blocked traffic only

The same query filtered to blocked connections. Change the verdict filter to drop:

fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
| filter verdict = "drop"
| stats count(*) as connections by categories
| sort connections desc
| limit 20

Figure 11: CloudWatch Logs Insights query results showing the most accessed category combinations filtered to blocked traffic only

Figure 11: CloudWatch Logs Insights query results showing the most accessed category combinations filtered to blocked traffic only

Drill down into a specific category

This query uses a like filter to find all traffic where the aws_category field contains a specific category, regardless of what other categories the domain also belongs to. In this example, the query returns all domains your workloads have connected to that map to the Artificial Intelligence and Machine Learning category, broken down by domain and verdict. Replace the category name in the like filter to investigate any category.

fields @timestamp, event.tls.sni, event.aws_category, event.verdict.action, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category like /Artificial Intelligence and Machine Learning/
| stats latest(event.tls.sni) as sni, latest(event.verdict.action) as verdict by event.flow_id
| stats count(*) as connections by sni, verdict
| sort connections desc
| limit 20

Figure 12: CloudWatch Logs Insights query results showing a drill down into the Artificial Intelligence and Machine Learning category with connections broken down by domain and verdict

Figure 12: CloudWatch Logs Insights query results showing a drill down into the Artificial Intelligence and Machine Learning category with connections broken down by domain and verdict

Bandwidth consumption by category

This query shows which category combinations consume the most egress bandwidth. It correlates flow logs (which contain byte counts) with alert logs (which contain category data) using the shared flow_id field. To run this query, select both your alert log group and your flow log group in CloudWatch Logs Insights.

fields @timestamp
| filter ispresent(event.netflow.bytes) or ispresent(event.aws_category)
| stats sum(event.netflow.bytes) as flowBytes, latest(event.aws_category) as categories by event.flow_id
| filter ispresent(categories) and categories != "[]"
| stats sum(flowBytes) as totalBytes by categories
| sort totalBytes desc
| limit 20

Figure 13: CloudWatch Logs Insights query results showing bandwidth consumption by category combination sorted by total bytes descending

Figure 13: CloudWatch Logs Insights query results showing bandwidth consumption by category combination sorted by total bytes descending

These queries help you identify which categories your workloads access by volume, surface blocked and allowed traffic patterns, and pinpoint where the bulk of your egress bandwidth is going.

Conclusion

In this post, you walked through how to set up URL and domain category filtering on AWS Network Firewall, from creating your first category rule using both the console rule builder and Suricata compatible rule strings, to managing exceptions for approved services and monitoring category traffic patterns with CloudWatch Logs Insights. With AWS-managed categories that stay current automatically, you can control access to broad classes of websites without maintaining individual domain lists, and the built-in aws_category log field gives you the visibility to track how your workloads interact with external services.

This feature is available in all AWS commercial regions where AWS Network Firewall is supported.

To learn more, visit the AWS Network Firewall product page and the feature documentation.

Lawton Pittenger

Lawton Pittenger

Lawton is a Worldwide Security Specialist Solutions Architect at AWS, based in New York City. He specializes in helping customers design and implement effective network security controls. At AWS, he works with customers at scale and collaborates closely with service teams to drive continuous improvement in security services based on customer needs and feedback. Outside of work, his interests include skateboarding, snowboarding, and spending time in nature.

Sofia Aluma

Sofia Aluma-Santos

Sofía is a Sr. Security Specialist leading Network Security Go-To-Market and strategy. She helps customers build scalable, secure, resilient networks.

Eric Fortenbery

Eric Fortenbery

Eric is an AWS Solutions Architect based in Atlanta, GA who helps EdTech customers architect secure, scalable platforms.

Mostafa Elkhouly

Mostafa Elkhouly

With over a decade of experience in networking technologies and security, I’m your go-to tech enthusiast! When I’m not jet-setting or tinkering with the latest gadgets, I thrive on empowering customers to harness the full potential of AWS services.

Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-amazon-opensearch-serverless-for-building-your-agentic-ai-applications/

Today, we’re announcing the next generation of Amazon OpenSearch Serverless, a fully managed search and vector engine designed for customers building AI agents. The next generation of OpenSearch Serverless scales from zero to thousands of requests per second and back to zero when idle, offering up to 60% cost savings compared to the cost of OpenSearch Service clusters provisioned for peak capacity.

The next generation of OpenSearch Serverless creates resources in seconds and scales capacity up to 20 times faster than the previous generation. With instant resource creation and native integrations with AI development platforms like Vercel and Kiro, you can deploy production-ready search and vector backends for your AI agents in minutes without managing infrastructure.

The next generation of OpenSearch Serverless in action
To get started with the next generation of OpenSearch Serverless, choose Create collection in the Serverless menu in the Amazon OpenSearch Service console.

Create NextGen collection with instant auto scaling and scale-to-zero for cost optimization. At launch, we support full-text search and vector search only for the collection type. If you want to use the existing OpenSearch Serverless infrastructure, choose Switch to Classic.

Choose Express create, the fastest way to create collection. No configuration is required—the default settings and matching security policies are applied automatically. Some configuration options can be changed later.

When you choose Create collection, OpenSearch Serverless will provision resources in seconds.

You can also create a collection of OpenSearch Serverless with AWS Command Line Interface (AWS CLI) or AWS SDKs. Here is a sample CLI command to create a collection group.

aws opensearchserverless create-collection-group \
    --name channy-nextgen-group \
    --standby-replicas ENABLED \
    --generation NEXTGEN \
    --description "My NextGen collection group" \
    --capacity-limits '{
        "maxIndexingCapacityInOCU": 10,
        "maxSearchCapacityInOCU": 10,
        "minIndexingCapacityInOCU": 0,
        "minSearchCapacityInOCU": 0
    }' \
    --region "us-east-1"

Now, you can create a collection that inherits the generation from its parent collection group. Supported collection types: SEARCH and VECTORSEARCH.

aws opensearchserverless create-collection \
    --name channy-nextgen-collection \
    --type SEARCH \
    --collection-group-name channy-nextgen-group \
    --standby-replicas ENABLED \
    --description "My collection in NextGen group" \
    --region "us-east-1"

To learn more about managing the next generation of OpenSearch Serverless, visit the Amazon OpenSearch Serverless documentation.

Building your agents faster with OpenSearch Serverless
To support building production-ready agent applications in Vercel, you can now create a new OpenSearch collection or connect your existing OpenSearch Serverless collection within the Vercel console. Create a search backend in seconds and add features on-demand as your application grows. To learn more, visit AWS for Vercel.

You can go from idea to working prototype in minutes using Claude Code, Cursor, and Kiro. OpenSearch Agent Skills provide a repository of skills that bring OpenSearch intelligence directly into your agent. Each skill encapsulates domain knowledge, best practices, and multi-step execution logic for a specific workflow–so your agent not only gets results, but understands how they were achieved. You can also use the OpenSearch Launchpad in Kiro Powers to accelerate search applications with guided, end-to-end architecture planning.

Now available
The next generation of Amazon OpenSearch Serverless is generally available today and is available in all AWS commercial Regions where Amazon OpenSearch Serverless is currently available.

The next generation of OpenSearch Serverless charges for the compute you use in OpenSearch Compute Units (OCUs) for indexing, search, and GPU acceleration. You are charged separately for storage in GB-month. For more information, see Amazon OpenSearch Service Pricing.

Give it a try and send feedback to the AWS re:Post for Amazon OpenSearch Service or through your usual AWS Support contacts.

Channy

The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents

Post Syndicated from Sohaib Katariwala original https://aws.amazon.com/blogs/big-data/the-next-generation-of-amazon-opensearch-serverless-built-from-the-ground-up-for-agents/

Audience note: This is the deep-dive technical launch post. For a shorter overview of what changed and why, see the related post on the AWS News Blog.

Today, we are announcing a ground-up re-architecture of Amazon OpenSearch Serverless that delivers up to 20 times faster autoscaling, scale to zero, and up to 60% lower cost than provisioning clusters for peak load. Amazon OpenSearch Service is a fully managed, open source retrieval engine that unifies vector, lexical, hybrid, and agentic search, delivering low-latency, accurate and relevant results. Amazon OpenSearch Serverless is an automatically scaled deployment option.

Modern workloads are increasingly dynamic and unpredictable. An ecommerce platform sees a 10x traffic spike during a flash sale. An artificial intelligence (AI) agent triggers hundreds of concurrent vector queries while reasoning through a multi-step task, then goes idle. A multi-tenant SaaS application serves dozens of tenants with wildly different activity patterns. These workloads need infrastructure that scales up to meet demand and releases resources when demand drops.

That is why we rebuilt the Amazon OpenSearch Serverless architecture from the ground up. The new architecture decouples compute from storage. The service provisions infrastructure in seconds instead of minutes, and scales compute all the way to zero when your application is idle. In this post, we walk through the new architecture, what it means for your applications, and how to get started with a hands-on tutorial.

With this launch, Amazon OpenSearch Serverless introduces two named architectures. Existing collections are now referred to as
Classic collections. The new architecture is called
NextGen and is now the default when you create a new collection via the AWS Console. You can use NextGen architecture in the API by specifying
--generation NEXTGEN in the CLI. To continue using the Classic architecture, specify
--generation CLASSIC in the CLI or omit the optional
--generation parameter.

What this means for your applications

The new architecture delivers improvements across three pillars: performance, cost, and a simplified user experience.

Performance: Autoscaling in seconds

An OpenSearch Compute Unit (OCU) is the unit of compute capacity that powers your indexing and search workloads. Amazon OpenSearch Serverless now provisions additional OCUs in seconds. When traffic arrives, the service adds resources in line with demand instead of reacting after a worker is already under pressure. The same mechanism scales the infrastructure back down quickly when traffic drops. The new architecture scales capacity up to 20 times faster than the previous architecture, so your users experience consistent performance during traffic surges, and you stop paying for capacity when you no longer need it.

Cost efficiency: Pay only for what you use

Indexing, search, storage, and Vector Index GPU-Acceleration are metered and billed independently, so you can see and optimize each dimension of your workload separately.

Decoupled compute and storage: OpenSearch Serverless now has full decoupling between compute and storage, allowing OCUs to scale up and down irrespective of the amount of data stored in a collection. This is powered by a new storage layer that is accessible to both indexing and search OCUs. You can now have multiple indices with data indexed in them but not pay any compute costs if you are not actively indexing or searching data. For workloads with significant idle time, the new architecture can reduce infrastructure costs by up to 60% compared to the cost of provisioning OpenSearch Service domains for peak capacity.

Scale to zero: When no requests arrive within the idle timeout window (10 minutes), the service releases compute resources and your OCU usage scales to 0. When traffic resumes, capacity is back in approximately 10 seconds. During this window, the service queues incoming requests and serves them once capacity is available; it does not drop them. If you anticipate a burst of traffic, for example before a scheduled batch job or a marketing campaign, you can send a lightweight query (such as a match_all with size=1) to warm the collection before your application starts sending production traffic. This reduces the latency your users experience on the first real request. Indexing and search scale independently. If you have no search requests, search OCUs scale to zero, even while OpenSearch Serverless maintains indexing OCUs for indexing requests, and vice versa.

GPU acceleration for vector workloads: For vector collections created in the new architecture, OpenSearch Serverless automatically uses GPU-backed compute to accelerate Hierarchical Navigable Small World (HNSW) vector index construction, significantly reducing indexing time compared to CPU-only builds. GPU acceleration kicks in automatically whenever there is an opportunity to leverage GPUs to reduce overall indexing time and cost. In the Classic architecture, you had to opt in or out of GPU acceleration at the collection level through the API. If you want to disable GPU acceleration for NextGen collections for a specific index, you can
turn off the remote index build setting at the index level. GPU usage appears as a separate line item on your bill, so you have full visibility into when acceleration was active and what it cost. For more details on how GPU acceleration works and performance benchmarks, refer to
Build billion-scale vector databases in under an hour with GPU acceleration on Amazon OpenSearch Service.

Simplified experience: Fewer steps to production

We also simplified the day-to-day experience of running OpenSearch Serverless:

With the new architecture, you can provision a collection and start sending requests in seconds. There is no need for capacity planning, no sizing decisions, and no waiting for infrastructure to warm up. This makes Amazon OpenSearch Serverless a natural fit for agentic workloads, where an AI agent can spin up a vector search or retrieval step on demand and expect a response without delay.

To make getting started even faster, we have introduced Express Create on the console. You supply a collection name and a collection type, choose Express Create, and your collection is active in seconds with no upfront network, encryption, or access policies to configure. You can add those later if your workload requires them.

Collection groups and collections can also be created programmatically using the AWS Command Line Interface (AWS CLI) and AWS SDKs. AWS CloudFormation support is coming soon.

The new architecture introduces two endpoint formats on the on.aws domain. The per-collection endpoint (<collectionId>.aoss.<region>.on.aws) works the same way as before with one endpoint per collection. The per-account Regional endpoint (<accountId>.aoss.<region>.on.aws) is new: it serves all of your collections through a single hostname, with the target collection identified in each request using the x-amz-aoss-collection-name or x-amz-aoss-collection-id header. This means one connection pool, one Transport Layer Security (TLS) session, and one endpoint to manage regardless of how many collections you have — a significant improvement for multi-tenant workloads where each tenant maps to its own collection. Both endpoints use standard AWS PrivateLink, so you create virtual private cloud (VPC) endpoints from the VPC console or the EC2 API just like any other AWS service. Private Domain Name System (DNS) is configured automatically, eliminating the Amazon Route 53 Private Hosted Zones, forwarding rules, and custom DNS infrastructure that were required with the original architecture. Cross-VPC, cross-account, and on-premises access all work using standard vpce-* DNS names with no additional setup.

Collection groups are the new unit of organization for your collections. You can share compute capacity across multiple collections with Collection Groups, which reduces cost for smaller collections that have complementary traffic patterns. You can also assign different AWS Key Management Service (AWS KMS) keys to collections within the same group, so you get both cost efficiency and per-collection encryption isolation. Collection groups are required when creating collections with the new architecture.

You also get the benefits of OpenSearch open-source releases without needing to manage versions and upgrades. The service tracks upstream releases automatically.

Amazon OpenSearch Serverless is also available on the Vercel Marketplace, making it straightforward for developers to add search infrastructure directly from their Vercel projects. You can link an existing AWS account through delegated access, or get started through a Limited Scope Account with USD $100 in AWS credit if you are new to AWS.

The integration creates a collection with sensible defaults, scale-to-zero billing, public endpoints, and AWS-managed encryption, and automatically sets connection details as environment variables in your Vercel project. You can choose from Search or Vector Search collection types depending on your use case, whether that is full-text search or semantic and AI-powered search.

How the architecture works

The new Amazon OpenSearch Serverless architecture separates compute from storage entirely. OCUs are stateless and read from and write to a distributed shared storage layer that is accessible to both indexing and search OCUs. The storage layer is designed for high durability, keeping your data available independently of the compute nodes that process it.

Architecture diagram showing OpenSearch Serverless NextGen with stateless indexing and search OCUs reading from and writing to a shared distributed storage layer

This design has two practical consequences:

  1. Fast provisioning. New OCUs start serving requests in seconds because there is no local disk to bootstrap. The OCU mounts the shared storage layer and begins processing immediately.
  2. Efficient scale down. Idle capacity can be released with no impact to your stored data, because the data never lived on the OCU. When traffic subsides, compute resources are released and your cost drops accordingly.

Architecture comparison

The following table summarizes the key differences between the original and new architectures:

Capability Classic Architecture NextGen Architecture
Minimum capacity 2 OCUs (always on) 0 OCUs (scale to zero)
Scaling speed Minutes Seconds
Storage Local storage per compute node Distributed shared storage (decoupled)
Collection organization

Individual collections (Default)

Collection groups (Optional)

Collection groups (required)
Cold start from zero N/A (always on) ~10 seconds
Endpoint Per-collection endpoint Regional endpoint (static per account)
Cost vs. OpenSearch Service domain Baseline Up to 60% lower cost
Scaling speed (vs. Classic) Baseline Up to 20 times faster than baseline

Walkthrough: Create a vector collection and observe scale to zero

In this walkthrough, you create a vector search collection with Express Create, index a few sample documents with embeddings, run a k-nearest neighbor (k-NN) query, and watch the collection scale to zero in Amazon CloudWatch. The entire process takes about 10 minutes.

Prerequisites

  • An AWS account with permissions to create Amazon OpenSearch Serverless collections.
  • AWS Command Line Interface (AWS CLI) configured with appropriate credentials.
  • curl 7.75 or later (for built-in --aws-sigv4 support).

Step 1: Configure security policies

Create encryption, network, and data access policies. These must exist before the collection can be created.

# Create an encryption policy
aws opensearchserverless create-security-policy \
    --name product-vectors-encryption \
    --type encryption \
    --policy '{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]}],"AWSOwnedKey":true}' \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

# Create a network policy (public access for this tutorial)
aws opensearchserverless create-security-policy \
    --name product-vectors-network \
    --type network \
    --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]},{"ResourceType":"dashboard","Resource":["collection/product-vectors"]}],"AllowFromPublic":true}]' \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

# Get your principal ARN
PRINCIPAL_ARN=$(aws sts get-caller-identity --query 'Arn' --output text)

# Create a data access policy
aws opensearchserverless create-access-policy \
    --name product-vectors-data \
    --type data \
    --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/product-vectors/*\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\"]}],\"Principal\":[\"\${PRINCIPAL_ARN}\"]}]" \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

Note: If you use the AWS console’s Express Create workflow, these policies are created automatically.

Important: After creating the data access policy, wait approximately 30 to 60 seconds for the policy to propagate before making API calls to the collection. If you receive a 403 Forbidden error, wait and retry.

Step 2: Create a collection group and collection

Create a collection group with scale-to-zero capacity limits, then create a vector search collection within it.

# Create a collection group with scale-to-zero enabled (min OCU = 0)
aws opensearchserverless create-collection-group \
    --name product-search-cg \
    --generation NEXTGEN \
    --standby-replicas ENABLED \
    --capacity-limits "minIndexingCapacityInOCU=0,maxIndexingCapacityInOCU=4,minSearchCapacityInOCU=0,maxSearchCapacityInOCU=4" \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

# Create a vector search collection in the group
aws opensearchserverless create-collection \
    --name product-vectors \
    --type VECTORSEARCH \
    --collection-group-name product-search-cg \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

The collection status transitions to ACTIVE within seconds.

Step 3: Create a vector index

Retrieve the collection endpoint and create a k-NN index using 3-dimensional vectors:

ENDPOINT=$(aws opensearchserverless batch-get-collection \
    --names product-vectors \
    --query 'collectionDetails[0].collectionEndpoint' \
    --output text \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2")

awscurl --service aoss --region us-east-2 \
    -XPUT "${ENDPOINT}/items" \
    -H "Content-Type: application/json" \
    -d '{
      "settings": {"index.knn": true},
      "mappings": {
        "properties": {
          "description": {"type": "text"},
          "embedding": {"type": "knn_vector", "dimension": 3,
            "method": {"name": "hnsw", "space_type": "cosinesimil", "engine": "faiss"}}
        }
      }
    }'

Note: If the collection has scaled to zero, the first request might take a few seconds while capacity scales up. If the request times out, wait 10 to 15 seconds and retry.

Step 4: Index sample documents with embeddings

awscurl --service aoss --region us-east-2 \
    -XPOST "${ENDPOINT}/items/_bulk" \
    -H "Content-Type: application/json" \
    -d '
{ "index": { "_id": "1" } }
{ "description": "Wireless noise-cancelling headphones", "embedding": [0.8, 0.2, 0.1] }
{ "index": { "_id": "2" } }
{ "description": "Portable Bluetooth speaker", "embedding": [0.7, 0.3, 0.2] }
{ "index": { "_id": "3" } }
{ "description": "Over-ear studio monitor headphones", "embedding": [0.9, 0.1, 0.05] }
'

Step 5: Run a k-NN query

Search for the two nearest neighbors to a query vector. Wait 30 seconds after indexing to allow the vector index to build before running this query:

awscurl --service aoss --region us-east-2 \
    -XGET "${ENDPOINT}/items/_search" \
    -H "Content-Type: application/json" \
    -d '{
      "query": {
        "knn": {
          "embedding": {
            "vector": [0.85, 0.15, 0.08],
            "k": 2
          }
        }
      }
    }'

The response returns the two most similar items, in this case, the headphone documents whose embeddings are closest to your query vector.

You can also run this query in OpenSearch UI by navigating to your collection in the Amazon OpenSearch Service console and choosing the OpenSearch UI Application URL. Then follow the steps outlined in this blog to create a workspace. Then navigate to Dev Tools and paste and run the following query.

GET items/_search
{
  "query": {
    "knn": {
      "embedding": {
        "vector": [0.85, 0.15, 0.08],
        "k": 2
      }
    }
  }
}

Step 6: Observe scale to zero

After a period of inactivity (no indexing or search traffic), the collection group scales down to 0 OCU. Verify with:

aws opensearchserverless batch-get-collection-group \
    --names product-search-cg \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

In the response, currentCapacity.search.capacityInOcu and currentCapacity.indexing.capacityInOcu will show 0 after the collection has scaled down.

You can also navigate to the Collection groups page in the Amazon OpenSearch Service console. Choose your collection group, then scroll down to the Monitoring section. Here you can see two charts: Indexing capacity (OCUs) and Search capacity (OCUs). After 10 minutes of idle time (no indexing or search requests), both metrics drop to zero, confirming that the service has released all compute resources for your collection.

CloudWatch monitoring charts in the Amazon OpenSearch Service console showing indexing and search capacity dropping to zero OCUs after 10 minutes of idle time

Clean up

To avoid ongoing charges, delete the resources you created in this walkthrough when you are done. Delete the collection first so the collection group becomes empty, then delete the group, then remove the security and access policies.

# Look up the collection ID, then delete the collection
COLLECTION_ID=$(aws opensearchserverless batch-get-collection \
    --names product-vectors \
    --query 'collectionDetails[0].id' \
    --output text \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2")

aws opensearchserverless delete-collection \
    --id "${COLLECTION_ID}" \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

# Look up the collection group ID, then delete the collection group
GROUP_ID=$(aws opensearchserverless batch-get-collection-group \
    --names product-search-cg \
    --query 'collectionGroupDetails[0].id' \
    --output text \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2")

aws opensearchserverless delete-collection-group \
    --id "${GROUP_ID}" \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

# Delete the security and access policies
aws opensearchserverless delete-security-policy \
    --name product-vectors-encryption \
    --type encryption \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

aws opensearchserverless delete-security-policy \
    --name product-vectors-network \
    --type network \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

aws opensearchserverless delete-access-policy \
    --name product-vectors-data \
    --type data \
    --endpoint-url "https://aoss.us-east-2.amazonaws.com" \
    --region "us-east-2"

Upgrading existing collections

To move to the new architecture, create a new collection group and collection, then reindex your data into it. For a step-by-step walkthrough of the reindexing process, refer to Perform reindexing in Amazon OpenSearch Serverless using Amazon OpenSearch Ingestion. Your queries and index mappings remain the same. Only the collection endpoint changes. With the new static Regional endpoint, that is a one-time update.

The new architecture supports SEARCH and VECTORSEARCH collection types. TIMESERIES is not supported at launch.

Conclusion

The new Amazon OpenSearch Serverless architecture is available today. You can create your first OpenSearch Serverless collection in seconds with Express Create, scale it to handle production traffic, and your OpenSearch Serverless compute costs drop to zero when it sits idle.

To learn more:

  1. Amazon OpenSearch Service documentation.
  2. Amazon OpenSearch Service console.
  3. Amazon OpenSearch Service pricing page.

If you have questions or feedback, open a support case or reach out through your AWS account team. We look forward to seeing what you build.


About the authors

Sohaib Katariwala

Sohaib Katariwala

Sohaib is a Senior Specialist Solutions Architect at AWS focused on Amazon OpenSearch Service based out of Chicago, IL. His interests are in all things data and analytics. More specifically he loves to help customers use AI in their data strategy to solve modern day challenges.

Raj Ramasubbu

Raj Ramasubbu

Raj is a Senior Analytics and AI Specialist Solutions Architect at AWS, focused on big data, analytics, and AI/ML. He partners with customers to architect and build highly scalable, performant, and secure cloud-based solutions.

Arjun Nambiar

Arjun Nambiar

Arjun is a Product Manager with Amazon OpenSearch Service. He focuses on ingestion technologies that enable ingesting data from a wide variety of sources into Amazon OpenSearch Service at scale. Arjun is interested in large-scale distributed systems and cloud-centered technologies, and is based out of Seattle, Washington.

Górny: why Gentoo?

Post Syndicated from jzb original https://lwn.net/Articles/1075148/

Gentoo developer Michał Górny has written a lengthy
article
explaining the philosophy and purpose of the Gentoo Linux
distribution, in response to a
thread on Mastodon
:

Gentoo is a source-first distribution, which means the primary
method of installing software is to build it from source. Of course,
that doesn’t mean manually building stuff, following some kind of
how-to: finding all the dependencies, installing them manually, going
through a series of magical incantations, and eventually ending up no
better than if we were installing a binary package. The package
manager takes care of all the necessary steps and more, making package
installs easy; well, at least unless something fails. But I’m
digressing…

[…] We try to build a friendly and welcoming community around Gentoo,
and we truly want using Gentoo be an enjoyable experience. We want it
to be a system that doesn’t betray you.

The collective thoughts of the interwebz