This essay was written with Nathan E. Sanders, and originally appeared in The Guardian.
Opposition to AI data centers has emerged as a primary theme in US politics, one that—surprisingly—doesn’t fallalong party lines. We applaud people coming together for constructive debate on any issue, and agree that communities need to evaluate whether any economic benefits these data centers bring is worth their costs. Still, we worry that a focus on data centers obscures the larger impacts of AI on people’s lives: the concentration of power of AI companies, and their widespread political and financial influence.
Local data center opposition is grounded in legitimate concerns about misallocation of land resources when housing is at a premium, pressures on already higher energy prices, and localized environmental impact. Unlike other resource-consuming and polluting industrial facilities, data centers produce very few jobs. The fact that US opposition to data centers seems to be most fierce among lower-income communities reflects righteous indignation with an inequitable bargain, where tech companies and developers profit from exploiting local resources but offer little in return. On a global scale, their carbon footprint could grow unsustainably if usage accelerates. And all this is in aid of a technology that many fear will propagate misinformation, take their jobs, or even cause existential risks for humanity.
For some, data center opposition may feel like the only tangible mechanism for registering their concern, disapproval, or even anger about AI. The problem is that this may be exactly what the AI companies are banking on. They can overcome the protest when it matters to them, and live with a significant fraction of proposals being defeated. More importantly, focusing political opponents on the data center issue obscures the bigger prize they’re after.
While there is a staggering three-quarters of a trillion dollars being spent on data center infrastructure by US companies this year alone, this investment should be taken in perspective. The market for enterprise software, for example, is about twice this size. And it’s small compared with what these companies actually want.
AI companies have their eyes set on capturing all the value created by entire industries. The technology has arguably already conquered customer service and consumer sales. But on the horizon are bigger targets, such as enterprise software development, creative design, management and even legal services. In AI companies and their allies’ vision of the future, AI replaces teachers and doctors. The companies would rather spend time fighting resistance to how fast they are building computing infrastructure than dealing with issues of how their products should be used in those fields, or how those fields should be protected from their products.
And while data center opposition campaigns have been successful in building widespread appeal, their effectiveness in the US is mixed. They seem to be most successful when organizing against speculative, early-stage data center proposals that have a relatively low likelihood to ever see fruition. Meanwhile, advanced-stage, well-capitalized data center projects have proven to have the resources to overcome local opposition. An OpenAI- and Oracle-backed facility in Saline township, Michigan, is breaking ground on construction even after local officials voted to reject it. The developers sued the town of 3,000 and forced a settlement that involved their project going forward. Meanwhile, the Trump administration, a vigorous ally of corporate AI, has signaled its willingness to advance AI infrastructure development by overriding state objections and even using federal lands.
Also consider that rampant data center development may be a momentary spike rather than a longstanding concern. Demand for the centralized computing that data centers provide may well decline over time. The leading Chinese labs, such as Z.ai, are innovating in technical mechanisms to make frontier-class models smaller and cheaper to run. AI power users have become adept at miniaturizing open weight models, ones published free for anyone to download and use, to run locally on their own computers. Apple and Googleboth support infrastructure stacks for running AI models directly on mobile phones. It could be that the current mania for data centers will look like the fiber optic cable bubble from the early 2000s, as demand shifts to smaller models and AI usage on people’s own devices.
For those concerned primarily with affordability and environmental protection, singling out data center construction is misplaced. Energy rates and inflation today seem to be most visibly affected by the US-Iran war. The US is disinvesting in long-term energy security by ceding the renewable energy industry to China and actively cancelling climate commitments. Consider that 10% of global carbon emissions stem from heating buildings, which dwarfs energy use by AI and could be cut fivefold by using heat pumps powered by renewable energy. With respect to housing affordability, federal housing subsidies have changed little over three decades, in inflation-adjusted terms, even as housing costs have spiked and homeowners have enjoyed robust tax incentives.
As for AI itself, the concentration of power and wealth in these tech companies is the greatest existential risk facing society today. This means we must limit corporate power, especially corporations’ ability to exploit the public and manipulate our political system.
Opposing data centers should be just a starting point. We can advocate for states to regulate AI, to reject irresponsible uses of the technology, and shape corporate behavior. We can fight for AI computation to be taxed, so that the public can capture some of the profit of AI use while also forcing AI companies to internalize more of the energy and environmental consequences associated with its use. And we all can join the global movement for Public AI, an alternative ecosystem for AI that is developed under public control with an incentive structure to create public benefit rather than private profit.
The US midterm elections present ample opportunity for those seeking to control the AI political agenda. In the recent New York congressional Democratic primary, PACs linked to the dueling AI companies Anthropic and OpenAI spent millions of dollars lobbying for or against “AI safety“, the idea that we must urgently monitor and prevent people from using AI to cause catastrophic harms. We’re already seeing a similar dynamic play out in races in Massachusetts and other states.
Why would Anthropic and OpenAI—bitter industry rivals but fundamentally on the same side politically—support opposing viewpoints? Because they both ultimately profit from the mystique: the idea that their products are so powerful that controlling those products is the world’s most important challenge. Here’s the typical read on the dynamic. To one side (backed by OpenAI affiliates), “safety” comes from the appearance of US industry dominating AI innovation, under the slow-moving control of federal lawmakers (and without pesky state regulators in the way). To the other side (backed by Anthropic), “safety” means a heavier regulatory framework that plays to Anthropic’s posturing as the ethics- and compliance-focused AI vendor. In both cases, it’s more marketing than principled concern about safety.
Political organizers should call out and reject the AI companies’ framing of the debate, and reorient campaign agendas around populist resistance to corporate concentration of wealth and power. When AI companies pump millions into legislative races, the result should not be hyperbolic discussion of AI superintelligence. And when a plot of land in a small town is pitched as a data center site, the debate should be about more than the local costs and benefits. It should include out-of-control money in politics, and Citizens United-proof solutions to limit corporate influence like public financing and state regulation.
We all have a vested interest in what’s on the policy agenda, and what the outcomes are. Today, the greatest risk AI poses to society is the exacerbation of inequality and the concentration of wealth. The real problem is trillion-dollar AI companies and their trillionaire oligarchs cozying up to political power in Washington and governments worldwide, and using their money to enact their agenda over the popular will of the people. This is the issue we’d like to see put front and center, and it requires solutions much more extensive than slowing data center development.
Частната телевизия е като плод-зеленчук: „Отиваш сутринта, отваряш, хората купуват, ако са ти хубави продуктите; ако са лоши, не купуват.“ Така разказа бизнеса си един от собствениците на bTV – Красимир Гергов, в едно от малкото си интервюта по повод десетата годишнина на първата частна национална телевизия у нас. Петнайсет години по-късно телевизията е превърната в кебапчийница – поне ако се съди по меметата, украсили последния публичен скандал за цензура и произвол в една от все още най-големите медийни институции в държавата.
Всичко започва, след като 19-годишният Мартин Атанасов (автор на „Черна писта“ и „Диагноза България“), поканен за гост в предаването „Лице в лице“, публикува скрийншот от вътрешна комуникация в нюзрума на bTV, от който става ясно, че участието му е спряно с разпореждане отгоре. Той трябваше да сложи на тезгяха темата за течовете в здравеопазването, за които плащаме всички ние. Но тя се оказа „неважна“ – свалена еднолично с кратък текст от директора на отдел „Новини, актуални предавания и спорт“ Асен Иванов. Заради някаква си чаша.
Този с чашата ли .. никога Да ходи в Извън ефир .. може да го скрийшотнете и сложите в Фейса Този няма да стъпи в ефир на бтв, докато зависи от мен
разпорежда началството с високомерната безнаказаност на човек, който знае, че се отчита другаде, а не пред обществената санкция на социалните мрежи. Можем само да предполагаме, че на някого от участниците в разговора също му е преляла чашата и затова този вътрешен чат получи публичност. За съжаление, това е максималната степен журналистически бунт и несъгласие, които може да очакваме в момента.
Продуцентката, поканила госта, го връща, лъжейки вместо началника си и прикривайки предварителната цензура, на която тя, екипът и събеседникът са подложени. Ръководството на медията също застава зад документирания властови произвол с клишето „редакционно решение“.
Че това не е легитимно редакционно решение и защо една телевизия не може да си прави каквото си иска в новините дори когато е частна, ще стане дума след малко.
Преди това – какво разгневи Асена на „bTV Новините“? Да го наричам „директор новини“, макар и фактически вярно, ми се струва обидно за всеки останал професионалист в екипа на медията, както и за самата функция, която помни по-добри времена, лица и имена.
Кой е Асен Иванов?
Официалната му биография го представя като дългогодишен журналист на bTV – криминално-съдебен репортер, редактор и така до главен редактор. Завършил е право в Югозападния университет в Благоевград, а след това и национална сигурност във Военната академия. От официалната му биография обаче трайно е изпаднал един интересен епизод: между 2012 и 2017 г. Иванов работи в ТВ7 – финансираната от КТБ телевизия, превърната в политически инструмент на Цветан Василев, Делян Пеевски и Николай Бареков. Там се издига до изпълнителен продуцент. Но през 2017 г. се връща в bTV, поканен от Венелин Петков, въпреки вече ясното му осветяване като част от политически инженеринг в журналистиката.
История с чаша, но не за чаша
Историята с чашата вече е клише. Когато в края на миналата година Мария Цънцарова беше отстранена от ефира на bTV, официалното съобщение на медията посочи като повод именно някаква чаша, с която тя си позволила да се яви в ефир. Обяснението беше толкова несъстоятелно, че на момента се превърна във фолклор, а чашата с надпис „Време за истинска промяна“ – в символ на протест в подкрепа на свободната журналистика.
Горе-долу по това време с тази именно чаша се яви Мартин Атанасов в студиото на bTV при седналия в опразненото столче на Мария Цънцарова неин колега Росен Цветков. Подари му я и го призова да пази достойнството на професията.
Този жест явно е засегнал директора на новините достатъчно, за да го спомене в официалната си позиция от миналата седмица. В нея той признава, че лично е свалил гост от ефир, през главата на редакционния екип, заради „целенасочена провокация и неуважение към наш водещ“. И добавя:
Когато един гост използва ефира за предварително планирани демонстративни действия, това неизбежно поставя въпроси за доверието между него и редакцията, както и за целта на участието.
И тук вече личат дефицитите и на самия аргумент, и на човека, който го артикулира. Първо, това, че гостът идва с предварително подготвено обществено послание, не е доказателство за недобросъвестност. Напротив – подготовката на госта е знак за сериозно отношение както към медията, така и към публиката. Освен ако самото послание в защита на свободната журналистика не се приема като обида към екипа, но това вече казва повече за обидените, отколкото за намеренията на госта.
Отделно, медия, която е извела в свое мото „силата да бъдеш информиран“, не може и не трябва да очаква от своите събеседници само позиции, които са ласкателни за самата нея. Години наред същата тази телевизия твърдеше, че търси всички гледни точки. Включително на един критичен към медията гост, който впрочем не беше единствен в онези дни. Не е приятно преживяване, но със сигурност не е легитимен повод за задраскване на събеседници. Защото това не са корпоративни отношения между партньори.
Телевизията е партньор на зрителя. Него обслужва и заради него трябва да е готова да изслуша дори онези, които не харесва.
Няма такова доверие – между гости и редакция. Няма тест за лоялност, за да те показват по телевизора. Както впрочем няма и абсолютна лоялност на журналистите към собствениците и главните редактори. Това не е клуб по интереси, затворена Facebook група или мафиотска структура, в която да стъпва кракът само на проверени и доверени хора.
В едно свое интервю началникът на „bTV Новините“ споделяше с гордост, че телевизията му се гледа от хората с власт. И явно за него е достатъчно. Но не за това доверие работи шефът на новините. А за доверието между медията и публиката. То е валутата в този бизнес. Нещо като сертификат за качество или печат от ХЕИ, предполагам, за една кебапчийница.
Оттам и основната задача на шефа на новините: да избира и развива журналисти и формати, които се ползват с обществено доверие, и да им осигурява гръб, за да го поддържат. Толкова. Плюс щипка рейтинг. Това работят шефовете на новини в търговските телевизии. На теория.
На практика всички виждаме, че явно има абонамент с проверени гости за ефира не само на bTV. От сутрин до вечер гледаме едни и същи лица, които често говорят с чужди гласове. Те и затова са канени – пращани са от пресцентрове и политически пиари да изговарят теза от името на една или друга скрита сила зад безотговорността на „независим“ анализатор.
Това са проверените хора в медиите, които не застрашават доверието. Могат да идват с теми от частен интерес на един или двама души в държавата и да говорят „за хората“. И никакви обиди на никакви водещи не могат да спрат триумфа на тези говорители в ефира на bTV, а и на останалите големи телевизии. Така например когато лидерът на „Възраждане“ нападна с обиди Мария Цънцарова в собственото ѝ студио през 2024-та, медията мисли два дни и написа някакво съобщение в подкрепа, но клетва, че кракът му няма да стъпи повече, нямаше.
bTV не може да си кани когото си иска дори когато един Асен е шеф на новините
Телевизия като bTV, дори гледана като плод-зеленчук или скара-бира, работи с ограничен обществен ресурс – ефирната честота, предоставена ѝ с лиценз и срещу конкретни задължения към публиката. Това не я прави държавна, но я прави нещо повече от обикновена частна фирма.
лицензът не е нотариален акт за собственост върху ефира. Той е обществен договор. Срещу правото да използваш честоти и да печелиш милиони от вниманието на милиони хора приемаш задължението да им даваш качествена информация в техен интерес, добита чрез равен достъп и плурализъм на гледните точки, отстоявани през редакционна независимост.
Така bTV не може като продавачката в кварталната бакалия, разположена в собствен гараж, просто един ден да реши, че няма да обслужва хора с руса коса, примерно. Всъщност и в бакалията не може така, защото би било дискриминация. И понеже, за щастие, не живеем на ориенталски пазар, където „всеки сам си преценя“, а във все-още-уж-законова държава, има норми и регулатори, които би трябвало да следят да не се самозабравят онези, които вярват, че няма кой да ги накаже.
Любопитното е, че в онова интервю от 2010-та Красимир Гергов, изглежда, го разбира това:
Не може, както в другите фирми, идват и казват на собственика: „Направи така.“ Тук има свобода на словото.
На кого говори и дали това не е по-скоро публично оправдание за случващото се в ефира по онова време, можем само да гадаем. Но поне теорията беше вярна. Или поне се полагаше усилие да изглежда така, сякаш телевизията не е бащиния. Дори и ако това е било само „за пред хората“.
Законът за радиото и телевизията забранява политическата и икономическата намеса и цензурата в дейността на медиите (чл. 5). В същия закон е записано, че журналистът може да откаже възложена задача, когато тя противоречи на закона, на личните му убеждения или на професионалната му съвест (чл. 11). И макар българската рамка да оставя достатъчно удобни вратички за натиск и интерпретация, смисълът е ясен:
журналистът не е войник в казармата на директора.
От август 2025 г. това вече не е само пожелание от учебник по журналистика. Европейският акт за свободата на медиите е факт и трябва да се прилага пряко и в България, нищо че не сме разбрали това да се е случило. Той изисква медиите да предприемат реални мерки за независимостта на редакционните решения и да разкриват конфликтите на интереси, които могат да влияят върху тях. Европейският законодател специално посочва риска акционери и собственици да бъркат границата между стопанската си свобода и редакционната свобода.
С други думи:
да, директорът на новините има право да ръководи редакцията. Да определя стандарти, да приоритизира ресурси, да изисква проверка, да връща недостоверни материали, да носи отговорност за програмата.
И не, няма право да превръща личната или корпоративната си обида в редакционна политика, да наказва събеседник за публична позиция или да отменя вече взето професионално решение на екипа само защото „от него зависи“.
Едноличното „никога!“ не е редакционна корекция, а намеса. И понеже е записано черно на бяло, този път няма нужда да гадаем дали е имало натиск, дали някой се е обадил и дали всички просто са се разбрали по телепатия.
Редакционният екип, разбира се, също има право да каже „не“. Това, че един Асен е поискал да прогони събеседник, не превръща желанието му в задължителен мандат. В най-лошия случай могат да те уволнят. Което съвсем не е малко, особено в държава с миниатюрен медиен пазар и с години систематично прочиствана професия.
Защо няма съпротива отвътре?
Разбира се, лесно е отстрани да питаме защо продуцентката не е отказала, защо е излъгала госта, защо никой не е станал и метнал чаша в ефир. Повече съпротива би била добър знак за състоянието на професията. Но след дългогодишна негативна селекция и регулярна санитарна сеч в медиите един журналист трудно може да се окаже по-силен от цялата система. Особено когато няма институционална защита, няма гилдийна солидарност, а обществената подкрепа приключва с възмутен пост във Facebook. Затова днес споделянето на един вътрешен скрийншот минава за бунт.
Оставете дебатите на журналистическите факултети, те добре се справят с тая работа. Регулаторът работи друго: да проверява спазва ли лицензираната медия закона и европейските изисквания за редакционна независимост и ако не – да налага санкции. Задачата на СЕМ е да предпази журналистите от натиск, включително когато той идва не от политик пред асансьора, а от собствения им началник. И ако законът не дава достатъчно силни инструменти, поне да го каже ясно и да изиска такива. Свикнали сме с бездействието на регулатора в подобни случаи и не очакваме нищо по същество, но това е част от проблема. И опитите да се прикрие с часове безсмислено говорене само го доразобличават.
Има ли кой да ги накаже?
Сигурно. Американската публика например направи показно при кризата около ABC и Джими Кимъл. След политическия натиск и временното сваляне на предаването реакцията не остана само в социалните мрежи. Абонати и инвеститори насочиха гнева си към Disney – корпорацията, която реално държи парите и взема решенията. Кимъл се върна в ефир шест дни по-късно и записа най-високия си рейтинг от години. Не защото корпорациите внезапно са развили съвест. А защото някой е превел възмущението на хората на езика на парите.
Дори Джеф Безос, когато реши да наложи волята си над редакционната позиция на собствения си Washington Post и спря подготвената подкрепа за Камала Харис преди изборите през 2024 г., не успя да представи намесата като нормално редакционно решение без цена. Последваха оставки, открит бунт в редакцията и над 200 000 прекратени абонамента.
В нашия случай заформилият се опит за бойкот, струва ми се, не трябва да е насочен само към bTV – компрометирания медиен бранд в портфолиото на корпорацията майка. Призивите да не се ходи в студиата, обзаведени по правилата на асеновци, са симпатични, макар и доста лицемерни, а в най-добрия случай – тежко закъснели.
Ако изобщо ще се упражнява потребителски натиск, той би имал смисъл единствено ако е насочен към другите търговски активи на същата корпоративна група в България, като телекоми например. Там е касата.
Телевизията може да преглътне няколко отказани гостувания и ядосани поста в социалните мрежи, но златните яйца днес се снасят не в бизнеса с ефирните честоти, а по телекомуникационната вертикала. Там бойкотът може да се преведе на езика на бизнеса.
Но засега у нас сме по-силни в чашите, статусите и моралното превъзходство.
И тук влиза неудобният въпрос как въобще един Асен стига до позицията, от която може да разпорежда „този никога“ на цял редакционен екип. Вътрешният чат не е началото на историята, а моментът, в който един Асен излиза от гардероба. Де да беше само той…
Асеновците не падат от небето и не се самоназначават.
Те са ГМО производство на българската журналистика в големите медии. В конкретния случай въпрос има и към Венелин Петков, при чието ръководство Иванов се връща в bTV след ТВ7 и постепенно стига до управленски позиции.
По какви професионални критерии е върнат? С какви гаранции, че школата на ТВ7 е останала зад гърба му, а не е дошла с него в нюзрума?
Няма смисъл да се посочва един-единствен виновник. Асен е възможен, защото зад него има цяла система от назначения, премълчавания, компромиси и професионални амнистии. Система, която приоритизира лоялността пред моженето, гъвкавостта пред стандартите, съобразяването пред отстояването.
Ако се върнем към онова интервю с Красимир Гергов и плод-зеленчука и сравним казаното от него с изявите на днешните телевизионни господари, ще се наложи един очевиден извод: политически игри с телевизията винаги е имало, но нивото определено пада.
От онова интервю смятам, че несправедливо се запомни само цитатът със зарзавата, а от днешна гледна точка там има и доста по-ценни свидетелства:
Българските медии вече са доста големи деца, за да може някой да ги бие по дупето и да слушат каквото някой им каже отгоре. Така че ние винаги ще намерим начин, ако някой ни притиска, да излезем от ситуацията. Не смятам, че политиците са толкова глупави да налагат ежедневен контрол върху медиите, защото това ще бъде краят им.
Наивно, нали. През 2010 г. все още звучеше възможно.
Една друга сбъднала се прогноза от днешна гледна точка ми се струва много подценена. Интервюто е дадено малко преди медийният октопод на Пеевски с подкрепата на Цветан Василев да насочи пипалата си от вестниците към телевизиите.
След цифровизацията, казва Гергов тогава, ще се появят „много влиятелни и не толкова влиятелни“ хора, които ще се опитат да правят медия, използвана за влияние. „Това вече е страшното за обществото.“
И още:
Ако вие сте честни към това, което правите, и давате добър продукт и всички гледни точки, ще бъдете номер едно. Ако бъдете тенденциозни и изпълнявате всички поръчки на собственика, който, да кажем, се занимава с нещо си – приватизатор някакъв, да кажем, занимава се с кокошки – и вие по цял ден давате кокошки или хора, свързани с този бизнес, няма кой да гледа тези телевизии.
Наистина няма кой да ги гледа. Но вече няма и особено значение. Когато кокошарникът пише рейтингите или телевизията е станала витрина на други бизнеси, или сделката вече е кон за кокошка, за да продължим със селскостопанската метафора.
А всъщност телевизията не е нито зарзаватчийница – по чисто комерсиалния модел, нито кебапчийница – по модела „който плаща, той поръчва музиката“. Тя е пазар. Пазар на идеи (marketplace of ideas), ако използваме класическата либерална представа, развита най-ясно от Джон Стюарт Мил. Тържище, на което освен фактите свободно се конкурират различни интерпретации, аргументи и разкази за реалността. Така истината има най-голям шанс да победи – в свободен дебат и в състезание, дори и с лъжата.
Това, разбира се, не означава, че всяка идея е еднакво вярна или че всяка телевизия е длъжна да даде трибуна на всеки. Редакторите ежедневно правят професионален подбор. И това не се нарича цензура, когато критерият е журналистически: достоверност, обществен интерес, компетентност, плурализъм. В момента, в който достъпът до пазара на идеи започне да се определя не от професионални стандарти, а от лични сметки, симпатии или желание някой да бъде наказан, тогава идеята се чупи. Превръща се в затворен клуб, продължение на обръча от фирми. А обществото губи не защото е победила грешната идея, а защото състезанието е било нечестно.
Enterprise video surveillance is operating at an unprecedented scale as organizations across retail, banking, quick-service restaurants (QSR), convenience stores, and transportation networks generate petabytes of video data across thousands of distributed locations. As retention requirements grow and organizations seek to extract more operational insights from video, traditional on-premise storage models are becoming increasingly difficult and expensive to scale.
March Networks is a global provider of intelligent video surveillance and business intelligence solutions serving enterprises across banking, retail, quick-service restaurants, transportation, and other multi-site environments. With more than 25 years of experience in video technology, the company helps organizations transform video data into operational insights through cloud-based platforms, AI-powered analytics, and enterprise-scale video management.
Unlocking the power of video data
In this post, we show how March Networks built a scalable cloud architecture on Amazon Web Services (AWS) to support large-scale enterprise video storage and analytics. The solution uses Amazon Simple Storage Service (Amazon S3) and Amazon S3 Glacier to manage long-term video retention, while integrating with additional AWS services to support ingestion, lifecycle management, monitoring, and secure access. We also explore how this architecture enables advanced video analytics using technologies such as Amazon S3 Vectors and Amazon Bedrock, helping organizations store petabyte-scale video data more cost-effectively while accelerating investigations and operational insights.
The challenge: Managing enterprise video at scale
Historically, enterprise video has been stored on local network video recorders (NVRs) and on-premise servers deployed at each site. Although this model provides localized control, it creates fragmented storage environments that require frequent hardware expansion, ongoing maintenance, and inconsistent retention policies across locations. This also limits organizations’ ability to centrally access, analyze, and govern video data across their enterprise.
As organizations increase video retention periods for compliance, liability protection, and operational intelligence, infrastructure requirements grow rapidly. Adding local storage hardware across hundreds or thousands of sites increases operational complexity and introduces lifecycle management challenges.
The economic impact of cloud video storage
Cloud storage introduces a more flexible model by consolidating distributed video data into centralized, elastic storage infrastructure. Even partial migration (such as moving long-term retention or compliance archives to the cloud), can significantly reduce infrastructure overhead while enabling centralized data management and analytics.
The financial impact of this shift can be substantial. For example, one retail organization evaluated the benefit of moving to a hybrid cloud storage model to extend video retention for a period of up to 5 years — a common retention window driven by compliance standards and laws — without adding new on-premise hardware. This customer operated more than 580 cameras, generating approximately 5,600 TB of archived video. The total storage required depends on factors such as video bitrate and quality, camera count, and backup duration. Their estimated cloud storage cost using a third-party cloud provider was approximately $347,000 per year, compared to roughly $1.7 million annually to store the same volume of video on-premise. For long-term cloud storage, data is not expired or deleted; customers are notified as their storage quota approaches capacity and can purchase additional storage as needed. By retaining recent footage locally while archiving older video to a third-party cloud provider, the organization significantly reduced storage costs while maintaining access to archived footage when needed.
Solution overview: March Networks cloud storage on AWS
March Networks Cloud Storage is a cloud-based video storage solution built on AWS. It is designed for distributed enterprise environments such as retail chains, financial institutions, convenience stores, and transportation systems that operate thousands of cameras across geographically dispersed locations.
The solution leverages Amazon S3 and Amazon S3 Glacier to provide scalable and durable storage for large volumes of video data while integrating AWS services that support secure ingestion, lifecycle management, monitoring, and access control. By combining AWS cloud infrastructure with March Networks’ video surveillance expertise, organizations can modernize video retention strategies while maintaining operational flexibility.
The platform supports multiple deployment models that allow organizations to adopt cloud storage at their own pace. Hybrid architectures allow recent footage to remain on-site for immediate access while older video is archived to the cloud. In other deployments, organizations can move a majority of video storage into AWS to reduce on-premise infrastructure and simplify long-term retention management.
Because the platform is built on AWS, storage capacity scales automatically as organizations add cameras, extend retention periods, or onboard new sites. This allows customers to grow video storage environments without hardware planning, or infrastructure expansion.
Architecture deep dive
The Cloud Storage architecture integrates on-premise video infrastructure with AWS services that manage ingestion, storage, monitoring, and secure access to video data.
At a high level, the architecture connects local video systems, including NVRs, cameras, and client applications, to AWS cloud services through secure network connections. March Networks securely ingests video data into AWS storage infrastructure, where customers can retain, monitor, and retrieve it based on their defined policies.
Figure 1: March Networks Architecture on AWS.
Video ingestion and storage
March Networks securely uploads video recorded on local NVRs to Amazon S3 buckets using encrypted transmission protocols. Amazon S3 provides highly durable object storage designed to store large volumes of data while enabling efficient retrieval and lifecycle management.
Once stored, organizations can retain video data for active investigations or operational review. Organizations configure lifecycle management policies that automatically move older footage to lower-cost storage tiers based on their access patterns.
Tiered storage with Amazon S3 and Amazon S3 Glacier
Video storage requirements vary depending on how frequently footage must be accessed. The platform uses multiple Amazon S3 tiers to align performance and cost with real-world video access patterns.
Amazon S3 Standard and Amazon S3 Standard-Infrequent Access (S3 Standard-IA) support video that must remain readily accessible for investigations, operational review, or analytics. For long-term retention, the platform uses Amazon S3 Glacier storage tiers to provide ultra-low-cost archival storage for footage that must be preserved but is rarely accessed.
Lifecycle policies automatically transition videos between tiers according to customer-defined retention policies. This allows organizations to store high-value recent video on high-performance storage while archiving older footage economically.
Supporting AWS services
Several AWS services support the reliability, scalability, and operational visibility of the platform:
Amazon Simple Queue Service (Amazon SQS) manages asynchronous messaging between system components, enabling reliable communication between ingestion, processing, and storage services.
Amazon Simple Email Service (Amazon SES) provides notification capabilities for operational alerts and system events.
Amazon CloudWatch monitors system performance, logs activity, and provides operational visibility into cloud infrastructure.
AWS Security Token Service (AWS STS) enables secure authentication and temporary credentials for system components accessing cloud resources.
For metadata management and caching, the platform uses PostgreSQL and Amazon ElastiCache for Redis to maintain high-performance access to video metadata and system state.
Together, these services enable March Networks to deliver a secure, scalable cloud architecture capable of supporting petabyte-scale video workloads across distributed environments.
Outcomes and benefits
By building its video storage architecture on AWS, March Networks enables organizations to modernize video infrastructure while reducing operational complexity and long-term storage costs. This includes:
Reduced storage costs
Tiered storage using Amazon S3 and Amazon S3 Glacier allows organizations to align storage costs with actual video access patterns. Frequently accessed footage remains readily available, while older video can be archived at significantly lower cost.
Elastic scalability
AWS infrastructure enables organizations to scale video storage across hundreds or thousands of locations without adding on-premise hardware. As organizations add cameras or extend retention periods, storage capacity expands automatically.
Centralized investigations and governance
Cloud-based video storage enables security and operations teams to investigate incidents across multiple sites using a centralized platform. Organizations can apply consistent retention policies, maintain audit trails, and enforce standardized governance across all locations.
AI-driven analytics and search
Centralized video storage also enables advanced analytics capabilities. March Networks integrates AI-powered tools such as AI Smart Search, which allows users to locate relevant footage using natural-language queries across large video archives.
These capabilities leverage technologies, including Amazon S3 Vectors and Amazon Bedrock to support semantic search and AI-driven video intelligence across enterprise-scale datasets.
Conclusion
As organizations generate increasing volumes of video data, scalable cloud infrastructure becomes essential for managing long-term storage and enabling advanced analytics. By building its Cloud Storage platform on AWS, March Networks provides organizations with a durable, secure, and cost-efficient foundation for enterprise video retention.
Services such as Amazon S3, Amazon S3 Glacier, Amazon SQS, Amazon CloudWatch, and AWS Security Token Service support a scalable architecture capable of storing and managing petabytes of video data across distributed environments. This cloud-native approach allows organizations to modernize video infrastructure today while preparing for future AI-driven analytics and operational intelligence.
Insurance fraud remains a significant challenge for the insurance industry. Fraudulent claims can increase loss costs, reduce trust, and consume investigation capacity that could otherwise be focused on serving customers. Traditional fraud detection approaches typically rely on rules-based controls, manual investigation triggers, historical claim patterns, and structured-data-only analysis. These approaches are useful for known fraud patterns, but they can struggle to detect sophisticated fraud rings or hidden relationships across claimants, policies, vehicles, providers, addresses, and prior suspicious activities.
MAPFRE USA is a top-rated auto and home insurer in Massachusetts, serving customers in 11 states nationwide. Our coverage includes auto, home, motorcycle, watercraft, business insurance, and more. As part of MAPFRE Group, we’re a worldwide leader serving over 31.1 million customers in more than 100 countries with a team of 31,000 employees. In collaboration with AWS and Neo4j, MAPFRE USA modernized its fraud prevention capabilities by combining graph-based features with machine learning (ML) models deployed on AWS. This initiative focused initially on Massachusetts auto insurance and later expanded to home insurance. It has delivered significant business impact, exceeding $5 million in net present value (NPV) over five years, with realized savings already outperforming projections.
In this post, we share how MAPFRE USA designed and implemented this solution, highlight the technical architecture running on AWS, specifically the MAPFRE data platform called Atenea, and explore lessons learned that can apply to other industries facing complex fraud challenges.
Business challenge
Fraudulent claims aren’t always isolated events. They often involve hidden networks of policyholders, vehicles, providers, and prior suspicious activities. Detecting these complex relationships requires going beyond traditional structured data analysis.
MAPFRE set out with a clear goal:
Goal: Improve fraud detection accuracy and claims handling efficiency.
Key performance indicator (KPI): Identify fraudulent claims missed by traditional methods.
Approach: Develop several ML models using both traditional structured data and 54 graph-based features derived from claim relationships.
Deployment: Integrate with Guidewire Claims, so front-line adjusters automatically receive fraud alerts with explanations.
Each flagged claim exposure generates a Guidewire activity showing the top three model drivers, helping investigators understand why the claim was flagged and act quickly.
Technical solution on AWS (Atenea data platform)
The fraud detection platform is built on a modern data architecture on AWS, designed to scale efficiently and support long-term governance.
At its core, the solution uses Apache Iceberg tables stored on Amazon Simple Storage Service (Amazon S3), with metadata managed through the AWS Glue Data Catalog and access governed through AWS Lake Formation as part of the Atenea lakehouse governance model. The platform feature store is implemented through feature-store-managed Iceberg tables that manage model features, predictions, and Guidewire activities. The implementation is structured across three logical layers:
Silver layer: Iceberg tables that contain source data from each of the sources. Used as the initial consumption point of the platform.
Gold layer: Iceberg tables storing intermediate data, such as unified Guidewire activity logs, Auto features, and Home features.
Platinum layer: Feature Store-managed Iceberg tables containing encoded features and model predictions, making them reusable across models and ensuring strong metadata governance.
Processing pipelines are executed on Amazon EMR Serverless, with orchestration managed by Apache Airflow operators running on Amazon Managed Workflows for Apache Airflow (MWAA). This provides elastic, cost-efficient compute for both batch processing and fast-time scoring, while keeping orchestration, monitoring, and recovery centralized.
For graph enrichment, the platform connects to Neo4j using a dedicated driver, enabling advanced network-based features like suspicious claim linkages, provider fraud ratios, and centrality metrics.
This architecture supports efficient, reliable, and transparent production execution. It uses repeatable Airflow orchestration, environment-based continuous integration and continuous delivery (CI/CD) promotion, centralized monitoring, failure notifications, retry mechanisms, dead-letter queue handling for Guidewire integration, and controlled secret management. At the same time, the layered lakehouse design keeps the platform flexible enough to evolve with new business needs and fraud detection use cases.
The data sources here are policy, claims, vehicles, and notes (from AS400 and Guidewire), which are structured data. Derived features that capture entity relationships make up the graph data.
Let’s go through the architecture overview:
Data ingestion – Claim batch data is uploaded to Amazon S3. The data is standardized and materialized in Iceberg tables within the Silver layer.
Graph enrichment – Data processed to update Neo4j graph database hosted on AWS.
Model training and scoring – Batch scoring for several ML models.
Model orchestration – Unified orchestration for ingestion, training, and inference using Apache Airflow operators. CI/CD pipelines for promotion across environments.
Execution platform – Amazon EMR Serverless for cost-efficient Spark processing. Migration to Apache Iceberg plus AWS Glue Data Catalog for scalable metadata handling.
Integration with claims systems – Fraud predictions automatically create Guidewire activities, enriched with a description for investigators.
Secrets and security – AWS Secrets Manager securely stores credentials and tokens for Guidewire API integration, with environment-specific and region-specific access controls.
Monitoring and reliability – Amazon CloudWatch and Amazon Simple Notification Service (Amazon SNS) provide visibility into pipeline health and notify teams on failures. Data quality checks are executed at key stages of the pipeline to validate data availability, schema consistency, completeness, and business-rule expectations before outputs are consumed by models or sent to Guidewire.
Guidewire integration with MLOps on AWS
One of the most important parts of MAPFRE’s solution was closing the loop between ML predictions and the claims handling system. This required a resilient integration between the Atenea data platform on AWS and Guidewire Claims.
Integration flow:
When an ML use case finishes scoring, the results are written as JSON files into the S3 path: <bucket_name>/guidewire/.
An S3 event notification triggers the AWS Lambda function LambdaXXXInvokeGuidewireAPI.
This Lambda function:
Reads the JSON file.
Calls the Guidewire Predictive Model API.
Because Guidewire doesn’t support batch requests, the Lambda function sends each JSON payload individually. This keeps the integration compatible with Guidewire and isolates failures at the individual activity level, but it increases the number of API calls and makes retry, throttling, DLQ handling, and monitoring controls important.
If successful, the API responds with HTTP 201 (activity created).
If not, the Lambda retries up to two times.
Failed requests are sent to an SQS Dead-Letter Queue (DLQ) and an SNS notification is published to an SNS queue for monitoring.
Secrets are stored in AWS Secrets Manager and injected as Lambda environment variables, along with AWS Region-specific URLs for token retrieval and API endpoints.
Example JSON structure for Guidewire integration:
{
"method": "createPredictiveActivity",
"params": [
{
"claimNumber": "AUXXXXXXX",
"exposureNumber": 1,
"subject": "Fraud alert from ML model",
"description": "Claim flagged as potential fraud based on graph + ML features",
"shortSubject": "ML_Fraud_Flag",
"priority": "high",
"availableForClosedClaim": true,
"autoCloseOnExposureClosure": false,
"targetDays": 4,
"escalationDays": 6
}
]
}
Resilience – Built-in retries, DLQ handling, and SNS alerts keep failed events from being lost.
Security – Secrets and tokens are managed using AWS Secrets Manager, with strict environment separation (dev, pre, pro).
Scalability – Any new MLOps use case writes results into the S3 output path, automatically flowing into Guidewire.
This integration shows that fraud models don’t just exist in isolation but actively augment daily claim workflows in production. It connects Atenea’s MLOps pipelines on AWS directly with business decisioning systems, which is critical to realizing the fraud savings impact.
Data quality and resilience
For robustness, we apply data quality checks on ingestion pipelines and graph features. Automated validation detects anomalies early, monitoring dashboards track KPIs and model performance, and standardized recovery and promotion processes run across environments.
Visualization and investigative tools
Neo4j Bloom supports Special Investigations Unit (SIU) workflows by visually exploring entity relationships, such as a provider linked across multiple suspicious claims, accelerating fraud ring identification.
Conclusion
The fraud detection model for auto claims has enhanced MAPFRE USA’s ability to identify fraudulent activity, driving significant savings and improving overall claims efficiency.
During the pilot phase alone, savings exceeded projections by over half a million dollars, and in production the initiative has proven an NPV of more than $5M at current business volumes. These results confirm the business case and highlight the strength of combining structured data with graph-based features to uncover fraud networks that traditional approaches miss.
The results have been compelling:
Accuracy gains – detection improved by 50–135 percent compared to baseline methods.
Realized value – In 2025, MA Auto and MA Home claim savings reached a combined total of $6.81M, with $6.59M from MA Auto and $225K from MA Home.
Proven return on investment (ROI) – the project delivered an NPV of $4.7M at approval, and results are already exceeding expectations.
Cross-functional success – the initiative brought together Claims, IT Data, Advanced Analytics, and Neo4j teams in an agile, collaborative model.
Beyond the financial outcomes, several lessons emerged. First, cross-functional collaboration between groups like Claims, Data Engineering, Advanced Analytics, and technology partners like AWS and Neo4j was critical to success. Second, explainability proved essential. By presenting adjusters with the top model drivers directly in Guidewire, we increased trust and adoption of the system substantially. Finally, building resilience into the architecture through monitoring, retries, and data quality processes helped the models operate reliably in production.
Looking ahead, the platform is well-positioned to expand beyond fraud detection. New use cases such as underwriting anomaly detection, customer entity resolution, and retention modeling are already on the roadmap. With a robust architecture built on AWS using Amazon EMR Serverless, Apache Iceberg on Amazon S3 supported by AWS Glue Data Catalog and AWS Lake Formation, a custom-built Feature Store, and Neo4j, MAPFRE now has a scalable foundation to continue driving innovation and business impact.
To start building a similar solution, open the Amazon EMR console and review the AWS Architecture Center for reference patterns you can adapt to your own fraud detection and analytics workloads.
The 7.2-rc3 kernel prepatch is out for
testing. Linus said: “Things continue to look normal (the ‘new normal’
with slightly higher rates of commits, although I do get the feeling that
we’re seeing that slightly balanced out by people starting to go on summer
vacation)“.
In preparation for the Rubin Vera era, AIC was showing off its F2032-01-G6, a 2U JBOF storage system that can house up to 32 E3 SSDs. The box is designed to be paired with BlueField-4 DPUs, allowing it to be used as a key value caching appliance
Започвам този бюлетин с едно признание: не се интересувам от футбол. Но световното първенство по този спорт не е само футбол, както и „Евровизия“ не е само музика. И двете са и политика. Затова искрено се зарадвах на символната победа на Брюксел над Тръмп. Съвсем по диктаторски президентът на САЩ отмени наказание на футболист, като се обади по телефона на шефа на ФИФА (същата организация впрочем, която му беше връчила измислена награда за мир). Белгийците обаче въздадоха справедливост с честна игра.
Ала не беше толкова отдавна 2023 година, когато в САЩ етиката не беше празна дума, а Върховният съд прие първия си етичен кодекс. Поводът за него, припомня Емилия Милчева в статията си „Последният етаж на републиката“, е, че върховен съдия на име Кларънс Томас в продължение на 20 години е приемал подаръци от милиардер под формата на луксозни пътувания и почивки. Е, ще си кажете, след 20 години може и Конституционният съд да прозре проблема с евентуалните пътувания на Десислава Атанасова с Делян Пеевски. И че проблемът, както отбелязва Емилия, не започва с полетите. По-скоро полетите повдигат по-важния въпрос – как някой, чийто професионален опит като юрист (без да броим политическата кариера) се свежда до позицията на юрисконсулт в здравни заведения, става конституционен съдия?
Въпреки европейското футболно „натриване на носа“ на САЩ обаче не всичко в ЕС върви по мед и масло. Ясно е например, че разширяването е приоритет на Съюза, но кои страни да включи то? На тази тема е статията на Анахит Хачикян „На трапезата на европейското разширяване – домакини, гости и нежелани посетители“. Интересно е да се видят и разликите между средните стойности за ЕС и България по отношение на това кой е желан гост и кой – натрапник. А зад факта, че по-малко от една трета от българските граждани подкрепят перспективата за членство на Украйна, прозира дългата ръка на Русия.
Като стана дума за Русия, логично стигаме до статията на Александър Малинов „Не, националният ни интерес не сочи към Русия“. Александър привежда редица аргументи, за да докаже тезата си, ясно заявена още в заглавието. Той се позовава на Конституцията, на Стратегията за национална сигурност, на геополитическите стъпки на България през последните няколко десетилетия, най-важните от които са членството в ЕС и НАТО. И задава логичния въпрос: извършва ли Румен Радев държавна измяна, де факто работейки за най-опасния враг на България?
Междувременно Радев подписа декларация, която осъжда действията на Русия срещу Украйна и съдържанието ѝ е идентично с това на друга декларация, която пък неотдавна отхвърли с аргумента, че била „милитаристична“. Препоръчвам статията на „Свободна точка“ по темата. Тъй че премиерът понякога може да извършва държавна измяна (по Александър Малинов), понякога – не. На четни дни може да е европеец, на нечетни – русофил. Или обратното… обърках се вече.
Българската държава обаче си има по-сериозни грижи от геополитическата ориентация на министър-председателя си – например как да наложи на децата възможно повече забрани и наказания. „Прогресивна България“ и ГЕРБ се надпреварват с предложения. ПБ прегръща идеята на предишния образователен министър Красимир Вълчев от ГЕРБ за предмет религия и добродетели в училище, а настоящият образователен министър Георги Вълчев предлага и да се въведат оценки по дисциплина в училище. Така хем учебната програма ще продължи да е безинтересна за учениците и неадекватна на живота им, хем те ще бъдат наказвани за това. И разбира се, забрана на социалните мрежи за деца под 16 години. ГЕРБ не искат да останат по-назад и инициират… вечерен час за интернет за подрастващите.
Чудя се на коя политическа сила първа ще ѝ хрумне да се задължат непълнолетните да спят с ръце над завивката. За да ги предпази от ръкоблудство, което според някои схващания от едни отминали времена водело до ослепяване.
От авторите на „Тоест“ Димитри Захов най-скоро е бил във възрастта, която е обект на въжделенията за забрани на политиците. Той анализира как социалните мрежи измориха Gen Z. Докато чета статията му, си мисля как младите хора току-виж сами са се отказали от това, което политиците така усърдно са се запътили да им забранят. Защото социалните мрежи са загубили основната си функция – свързването на хората. Превърнали са се в място, където, казва Димитри, всеки се опитва да ти продаде нещо. А в ерата на ИИ дори не е нужно да се полагат усилия за това.
Докато някои от авторите ни са от поколението Z, други вече сме прехвърлили половин век на таз земя, та помним някои неща. Ето – аз помня как в началото на 90-те тогавашното правителство на Андрей Луканов ни вкара в измамната дилема между „плавния преход към пазарна икономика“ и „шоковата терапия“. Когато чух настоящата министърка на финансите да говори за „шокова консолидация“ и „плавна стабилизация“, получих дежавю. Та реших да резюмирам спомените си.
Литературните успехи на Ирена Иванова, подвизаваща се под псевдонима Рене Карабаш обаче, не са спомен, а настояще. С този изсмукан от пръстите преход скачам в полето на културата, на което са поникнали останалите статии в „Тоест“ тази седмица. Интервюто на Роси Михова с Рене Карабаш и със специалното участие на Пабло Неруда просто кърти (казано на не много културен език). Ако не вярвате, ето кратък откъс:
– Какво мислят рубините, когато видят сок от нар? – Че са на брега на Червено море.
– На какво се смее динята, докато я разсичаме до смърт? – На ножа. И на този, който го държи. Динята знае: и твоето време ще дойде.
– Кое е това, което дървото чува от земята и го казва на небето? – Нещо, което мисля, че трябва да остане в тайна.
– Какво прошепва пепелта на огъня, който гори наблизо? – Чакам те.
– Защо дърветата крият великолепието на своите корени? – Защото всеки трябва да крие и пази това, което му е най-ценно.
Продължаваме на вълната на съвременната българска литература, но се насочваме към поезията. В рубриката „По буквите“ Зорница Христова ни препоръчва три нови стихосбирки. Това са „Винаги умира някой друг“ от Димана Йорданова, „Искам да се обадя на майка по телефона“ от Мария Донева и „Очевидното“ от Владислав Христов. Първите две са издадени от „Жанет 45“, третата – от „Ерго“.
За десерт – и понеже това е последният ми бюлетин преди лятната ваканция на „Тоест“ – си оставих Езиковия наръчник за плажа на Павлина Върбанова. Ако досега не сте знаели, че ултраолинклузив, бийчбар и айслате се пишат слято (аз пък, понеже не пия кафе, дори не знаех, че има такова нещо като фредокапучино), вината не е ваша, а в противоречащите на интуицията правила за слято, полуслято и разделно писане. Повече за плажния правопис и граматика – от Павлина.
Докато се чудя какво да ви препоръчам за финал, почина певицата Бони Тайлър. И както ми домъчня, така се сетих за онзи смешен клип с кучето, което се завърта, когато чуе думите turn around от най-известната ѝ песен. Затова ми хрумна да ви препоръчам да почетем Бони Тайлър с нея. С тъга, но и с усмивка.
И разбира се, препоръчвам да ни подкрепите с месечно дарение, ако искате да продължавате да ни четете.
AI, it’s all you hear about nowadays and everyone’s got an opinion on it. Here at Metasploit, we care less about those opinions and more about the growing attack surface all this new software brings with it (yeehaw exploits!). Take for example the new Flowise CSV Agent Prompt Injection RCE brought to you by Takahiro Yokoyama and zdi-disclosures. Flowise is an open-source tool that lets you build AI apps and chatbots using a visual, drag-and-drop canvas and CVE-2026-41264 is an unauthenticated RCE run method of the CSV_Agents class in Flowise. The vulnerability exists due insufficient sandboxing and an incomplete list of disallowed inputs. It allows unauthenticated attackers to upload a .csv file containing arbitrary python code and execute it. One moment you’re using AI to help draft and email and the next moment you’re getting pwn’d, what a world we live in! Happy Friday and happy hacking everyone.
Description: Adds a new persistence module, exploits/linux/persistence/apache_htaccess, that plants wireghoul’s mod_cgi .htaccess web shell on a Linux Apache target.
Description: This adds a new exploit module for FlowiseAI Flowise (CVE-2026-41264). The CSV Agent feature evaluates LLM-generated Python code without proper sandboxing, allowing a prompt injection to achieve arbitrary code execution as the user running the server. Flowise versions 1.3.0 through 3.0.13 are affected. The module requires an API key with chatflows:create permission but does not require Flowise authentication to trigger the underlying flaw.
Description: This adds a new local privilege escalation module for macOS targeting CVE-2024-27822 in PackageKit.framework. When a PKG installer script uses a ZSH shebang, PackageKit runs it as root while inheriting the installing user’s environment, causing ZSH to source the user’s ~/.zshenv with root privileges. The module plants a payload in ~/.zshenv that fires only when running as root, then opens a minimal PKG with Installer.app; once the user approves the installation prompt and authenticates, the payload executes as root and a root session is returned. Affected versions are macOS 14.4, 13.6.6, 12.7.4, and 11 and earlier; the issue is patched in 14.5, 13.6.7, and 12.7.5.
Enhancements and features (5)
#21416 from g0tmi1k – This updates the Exploit::Remote::Ftp mixin to improve target fingerprinting. It now leverages recog to fingerprint targets from their banners and adds ftp_fingerprint and ftp_list_directory methods to assist with target enumeration.
#21436 from g0tmi1k – Improved UX for reloading of library files.
#21579 from zeroSteiner – This adds a few extra fields to some MCP Server tools to align with recent RPC changes in the framework. The msf_service_info tool now has resource and parents fields, the msf_vulnerability_info tool now has a resource field, the msf_note_info tool now has a data field, and the msf_credential_info tool now has new realm_key and realm_value fields.
#21580 from Pushpenderrathore – This adds a Certificate Signing Request (CSR) Trace to the CertificateTrace functionality. Users can now opt to see the CSR get printed when requesting certificates from AD CS.
#21637 from eve0805 – This adds improved levels of granularity to the KerberosTicketTrace functionality. Users can now choose to print the full kerberos trace output, only the tickets or only the metadata.
Bugs fixed (2)
#21588 from vinicius-batistella – Fix a bug in the format dispatcher where although we can generate AARCH64 windows exe files, we fail trying to do so because the dispatcher does not properly handle the request by the user.
#21651 from jheysel-r7 – This fixes a bug in the Role Based Constrained Delegation (RBCD) module that prevented Access Control Entries (ACEs) from being removed due to a type mismatch while comparing Security Identifiers (SIDs).
Documentation
You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.
Get it
As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:
AWS Outposts extend AWS infrastructure, services, APIs, and tools to on-premises locations for workloads that require low latency, local data processing, or data residency.
In this post, you learn how to configure instances running on an Outpost to support the required IOPS and throughput for your application. The actual IOPS available to an instance is determined by the Amazon Elastic Compute Cloud (Amazon EC2) instance type selected, Amazon Elastic Block Store (Amazon EBS) storage type, and number of volumes available. The lowest performing subsystem limits your overall IOPS and throughput. This post explains each subsystem’s performance impact and provides guidance on sizing Outpost EC2 instances and storage to deliver the target IOPS and throughput values. We focus on EBS-attached volumes rather than instances using EC2 instance store storage.
Performance considerations
When designing for IOPS and high throughput, consider two main drivers with the lower value taking precedence. The first is the performance of the EC2 instances and the second is the supported IOPS and throughput of the attached EBS volumes.
At the time of publishing, Outposts supports first-generation (c5, m5, r5, g4dn) and second-generation (c7i, m7i, r7i, c8i, m8i, r8i) instance families, which are all EBS-optimized instances. These instances provide dedicated bandwidth to the EBS volume I/O, minimizing traffic contention and ensuring optimal storage performance. When attached to an EBS-optimized instance, General Purpose SSD (gp2 and gp3) volumes deliver at least 90 percent of their provisioned IOPS performance 99 percent of the time each year. For detailed instance type specifications and features, see the Amazon EC2 Instance Types Guide.
The starting point for any design is to understand the performance capability of the selected EC2 instance. Looking at Amazon EBS specifications, the columns titled “Baseline / Maximum IOPS” and “Baseline / Maximum throughput” shows the performance of memory optimized R instance family.
1 These instances can sustain the maximum performance for 30 minutes at least once every 24 hours, after which they revert to their baseline performance.
However, your EC2 instance performance will be constrained if your attached EBS volume(s) have a lower baseline IOPS and throughput.
EBS performance
Outposts racks support two types of EBS storage: General Purpose gp2 only in first-generation Outposts racks, and General Purpose gp2 and gp3 volume types in second-generation Outposts racks. The gp2 storage type supports volumes of between 1 GiB and 16 TiB. Volumes 33.33 GiB and smaller are provisioned with the minimum of 100 IOPS, while volumes larger than 33.33 GiB are provisioned with 3 IOPS per GiB of volume size up to the maximum of 16,000 IOPS, which is reached at 5,334 GiB (3 IOPS X 5,334 GiB). See gp2 volume performance for details on how this is calculated. For gp2 volumes larger than 1,000 GiB, the baseline performance exceeds the burst performance, so burst performance becomes irrelevant. For consistent performance, we also recommend using a volume size of at least 334GiB to deliver a consistent bandwidth of 250 MiB/s, gp2 volumes deliver throughput between 128 MiB/s and 250 MiB/s depending on the volume size, with larger volumes delivering higher throughput up to maximum 250 MiB/s.
On Outposts, the gp3 storage type supports volume sizes up to 16 TiB, IOPS up to 16,000, and throughput up to 1,000 MiB/s. To reach the maximum IOPS provisioned at 500 IOPS per GiB of volume size for gp3, you must use at least a size 32 GiB volume with an EC2 instance that can also support up to 16,000 IOPS. To reach maximum throughput, your volume needs to provide at least 4,000 IOPS, which is achieved with a 8 GiB or larger volume.
Use AWS Identity and Access Management (AWS IAM) policies to control which principals can create, attach, detach, or delete EBS volumes. This is especially important when using multi-volume configurations where data spans across multiple volumes. On Outposts, Amazon EBS encryption is enabled by default — all EBS volumes are automatically encrypted at rest using AWS Key Management Service (AWS KMS) keys with no measurable impact on IOPS or throughput performance. Data is encrypted on the local NVMe storage using AES-256. For additional control, you can use AWS KMS customer-managed keys to manage the encryption keys for your volumes.
However, for the Amazon Relational Database Service (Amazon RDS) database engines supported on Outposts as well as EC2, database and EC2 instance storage is striped across multiple volumes providing several times the baseline throughput and the burst IOPS of a single volume. When small I/O operations are physically sequential, EBS attempts to merge them into a single I/O operation up to the maximum I/O size. Similarly, when I/O operations are larger than the maximum I/O size, EBS attempts to split them into smaller I/O operations. For the best performance, use larger packet sizes up to the maximum I/O size supported.
Calculating IOPS
When calculating the supported IOPS for your workload, start by choosing the instance type that supports your target IOPS, and then size the EBS both in terms of volume size and the number of attached volumes. To achieve maximum EBS performance, the combined IOPS of all attached volumes must meet or exceed the maximum IOPS supported by the instance. When selecting a general purpose EBS volume size, each GiB of EBS adds IOPS up to the maximum supported baseline IOPS (16,000 IOPS for gp2 and gp3). When designing high-performance workloads on Outposts, verify that your gp3 storage configuration is sized to meet the aggregate IOPS requirements of your workload.
As an example, the r7i.12xlarge delivers a maximum of 60,000 IOPS with an EBS throughput of 1,875 MB/s (see Figure 2). To reach this ceiling using gp2 EBS volumes — where each GiB provides 3 IOPS up to a maximum of 16,000 IOPS per volume — you would need to attach:
Three volumes of at least 5,334 GiB each (delivering 16,000 IOPS per volume = 48,000 IOPS combined)
One volume of at least 4,000 GiB (delivering the remaining ~12,000 IOPS)
This brings the total provisioned IOPS to 60,000, matching the instance’s maximum IOPS. By contrast, gp3 EBS volumes support a baseline IOPS performance of 3,000 included in the price of the storage, with the ability to provision additional IOPS up to the maximum supported 16,000 per gp3 volume on Outposts racks. IOPS are provisioned at a rate of 500 IOPS per GiB of volume size, so the maximum can be reached by provisioning a 32 GiB or larger volume as opposed to the 5,334 GiB volume required to get 16,000 IOPS with gp2. That means to deliver 60,000 IOPS of performance using an r7i.12xlarge instance with gp3 EBS storage, you would need to attach:
Three volumes of at least 32 GiB each (delivering 16,000 IOPS per volume = 48,000),
One volume of at least 24 GiB (delivering remaining ~12,000 IOPS).
This means only 56 GiB of gp3 EBS storage is required to meet performance requirements, instead of 20,002 GiB of gp2 EBS storage. For maximum performance, make sure the provisioned EBS volume(s) IOPS matches the bandwidth ceiling of your instance type. If you’re using EBS RAID configurations, note that arrays larger than 8 volumes often yield diminishing performance returns because of increased I/O overhead.
Calculating throughput
Throughput is equally important to IOPS for a performant architecture. Throughput measures the volume of read/write operations that can be processed per second. On Outposts, up to 1,000 MiB/s throughput per volume can be achieved using EBS gp3 storage, and EBS gp2 can provide up to 250 MiB/s throughput per volume. While gp2 and gp3 EBS storage on Outposts both provide up to 16,000 IOPS per volume, gp3 can provide up to 4x as much throughput, making it a better choice for high performance databases on second-generation Outposts racks.
Like IOPS, while gp2 throughput scales based on volume size, you can provision additional throughput for gp3 EBS volumes. EBS gp3 storage delivers a consistent baseline throughput performance of 125 MiB/s. You can provision additional throughput up to the 1,000 MiB/s maximum supported on second-generation Outposts racks at a ratio of 0.25 MiB/s per provisioned IOPS, which can be reached using an 8 GiB gp3 volume. To get the maximum supported IOPS and throughput performance using gp3 EBS storage with Outposts, use at least a 32 GiB volume. When designing high-performance workloads on Outposts, verify that your gp3 storage configuration is sized to meet the aggregate throughput requirements of your workload.
Refer to the earlier section on performance considerations to confirm your selected EC2 instance can provide as much throughput as your EBS storage volume(s) to avoid performance bottlenecks.
RDS IOPS considerations
At the time of publishing, Outposts racks support the RDS for SQL Server, RDS for MySQL, RDS for Oracle, and RDS for PostgreSQL database engines. Database instance performance varies depending on the EC2 instance type selected for the database, the EBS volume type selected for RDS database storage, the database engine selected, and the size of the RDS database storage. The following tables show expected IOPS for database instances using gp2 and gp3 EBS volume types respectively, as shown in the General Purpose SSD Storage section of the Amazon RDS user guide.
To calculate your database instance performance, consider all influencing factors. For example, if you wanted to support the maximum IOPS of 16,000 shown for the SQL Server RDS database engine, you would need:
32 GiB gp3 volume, OR
5,334 GiB gp2 volume.
At least an r5.4xlarge, which can provide a baseline 18,750 IOPS. If using a second-generation Outposts rack, r7i.4xlarge and r8i.4xlarge instances provide a baseline of 20,000 IOPS. However, they are constrained by the lowest performing subsystem, which would be the amount of I/O the database engine can support (16,000 for SQL Server).
The storage type and size have the biggest impact on IOPS performance. For high I/O databases, we recommend either purchasing additional gp2 storage for your first-generation Outpost rack (understanding you might need to provision more storage than needed to meet your IOPS requirements), or using second-generation Outposts racks which support the more performant gp3 EBS storage type for your database workloads. Also consider that Outposts racks have a fixed storage capacity, and aggregate workload IOPS should be reviewed.
Monitoring IOPS
To check that the infrastructure is sized correctly to meet your IOPS expectations, use Amazon CloudWatch EBS volume metrics. You can monitor your EBS volume performance and set CloudWatch Alarms if the values exceed, for example, 70% of the total. Metrics such as VolumeReadBytes and VolumeWriteBytes provide information on the read and write operations in a specified time period based on bytes, and likewise VolumeReadOps and VolumeWriteOps provide the same information based on completed operations. You can monitor the time taken for read and write operations for an Amazon EBS volume using the VolumeTotalReadTime and VolumeTotalWriteTime metrics respectively using the Average statistic. Use IAM policies to restrict who can view, create, or modify CloudWatch alarms and dashboards for your Outpost resources. This prevents unauthorized users from suppressing critical storage performance alerts.
You can also use the Latency Injection action in AWS Fault Injection Service to run controlled experiments to test your architecture and monitoring based on this metric to improve your resiliency to storage performance degradation. You can access real-time detailed performance statistics for Amazon EBS volumes that are attached to Nitro-based Amazon EC2 instances. You can combine these statistics to derive average latency and IOPS, or to check whether I/O operations are completing. You can also view the total amount of time that your application has exceeded your EBS volume’s or the attached instance’s provisioned IOPS or throughput limits. By tracking increases in these statistics over time, you can identify whether you need to increase your provisioned IOPS or throughput limits to optimize your application’s performance. The detailed performance statistics also include histograms for read and write I/O operations, which provide a distribution of your I/O latency by keeping track of the total number of I/O operations completed within a latency band. See Monitor your Outposts rack and Monitoring best practices for AWS Outposts for general Outposts monitoring guidance.
When running FIS experiments, follow the principle of least privilege by scoping IAM roles to specific resources, and always configure stop conditions to automatically halt experiments that exceed expected impact thresholds.
Conclusion
This post explains how to size EC2 instances and EBS storage on Outposts racks to meet your IOPS and throughput requirements, helping you avoid performance bottlenecks for database and application workloads. You can monitor EBS storage performance through CloudWatch and create alarms to alert you when your instance approaches its IOPS threshold. To learn more about Outposts and how to architect for IOPS and throughput performance for your workloads, reach out to your AWS account team, or visit the AWS Outposts contact page.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
