На север: Спасяването на хора в Исландия и у нас

Post Syndicated from Светла Стоянова original https://www.toest.bg/na-sever-spayavaneto-na-hora-v-islandiya-i-u-nas/

На север: Спасяването на хора в Исландия и у нас

Миналото лято се наложи да направя сърдечен масаж на мъж недалеч от хижата, в която работех. Щом научих за пострадалия, изтичах двата километра до мястото, където вече имаше скупчване от хора. Трима от тях се сменяха, за да правят сърдечен масаж. Наредих се и като дойде моят ред, сложих китка върху китка над слънчевия сплит на човека, изпънах лакти и направих 30 равномерни и силни натиска, както бях учила в школата по първа долекарска помощ в София. Жената на пострадалия направи два пъти обдишване уста в уста, после пак 30 натиска, 2 обдишвания, отново и отново. След известно време някой ме потупа по рамото и ми направи знак да се сменим.

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

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

Исландия е остров в Северния Атлантически океан с площ почти колкото България и с население приблизително колкото на Варна. Природата е сурова и там се намират едни от най-големите ледници в Европа, има чести вулканични изригвания, земетресения, свлачища, екстремни метеорологични условия, покосяващи ветрове и лавини и безброй други предизвикателства, с които исландците трябва да се справят. На острова армия няма, а бреговата охрана притежава едва няколко кораба и хеликоптера, затова е нужно да има спасителни екипи из цялата страна.

Исландската спасителна служба ICE – Search & Rescue Team играе значителна роля в превантивната и спасителната дейност. Хиляди доброволци са на разположение денонощно и мисията им е и да предотвратяват инциденти и да спасяват хора. В цялата страна има около 100 отряда. Всички преминават през двугодишно обучение, което дава задълбочени познания за особените условия и опасности както на сушата, така и в океана. Част от случаите може да са оказване на първа помощ на пострадали в планината, издърпване на затънали в снега или попаднали в реки хора и автомобили, издирване на избягали деца или възрастни, страдащи от суицидни мисли. Понякога хора са повличани от огромните океански вълни, пропадат в пропасти или ледникови цепнатини, биват погълнати от лавини или изгубени и изтощени в пустошта без ясна представа за посоките. През последните години спасителите дават дежурства покрай последните вулканични изригвания и следят за безопасността на хората в областта.

Исландската спасителна служба е с над 100-годишна история и днес наброява 4500 доброволци из цялата страна, тоест на всеки 100 жители има поне по един обучен спасител.

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

На север: Спасяването на хора в Исландия и у нас
На север: Спасяването на хора в Исландия и у нас

Джипове на ICE / Спасителен кораб на ICE © Светла Стоянова

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

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

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

Сред дейностите на Исландската спасителна служба е и превенцията –

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

На север: Спасяването на хора в Исландия и у нас
На север: Спасяването на хора в Исландия и у нас

Ледено катерене / Упражнение по спасяване на пострадали © Светла Стоянова

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

На север: Спасяването на хора в Исландия и у нас
На север: Спасяването на хора в Исландия и у нас

Упражнение по носене на пострадал в носилка © Светла Стоянова / Упражнение по спускане с въжета © Селена Кауфман

У нас най-голямата доброволна неправителствена организация, предоставяща помощ на уязвими хора в бедствени и кризисни ситуации, е Българският червен кръст (БЧК). С над 140-годишна история и посредством дейности в полза на обществото той допринася за облекчаване и предотвратяване на страданието във всичките му форми, закриля здравето и живота и осигурява уважение към човешката личност.

Част от БЧК е и Планинската спасителна служба (ПСС), която работи за предотвратяване на нещастия и оказване на помощ на пострадалите в планините. ПСС наближава своето първо столетие и се ръководи от опитни и изключително отдадени хора. Активните членове са над 500, а отрядите наброяват над 30 в цялата страна. От общуването ми с планински спасители съм оставала без думи от екстремните ситуации, в които се е налагало да извършват спасителни акции. Хората са подготвени да работят продължително време в тежки метеорологични и теренни условия, често с риск за собствения си живот и здраве, за да окажат помощ на пострадали – както медицинска, така и практическа, – що се отнася до изнасяне от труднодостъпни терени по най-безопасния и бърз начин.

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

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

Някои утвърдени школи по първа долекарска помощ у нас са:

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

Ето и някои основни принципи в критични ситуации:

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

2. Обадете се на 112 и кажете къде е станал инцидентът, какво се е случило, колко са пострадалите и какво е състоянието им. Изчакайте допълнителни въпроси.

3. Направете превръзки и обездвижвания. Сложете пострадалия в удобна поза и го завийте. Периодично проверявайте дали е в съзнание, дали диша и ако да, какъв е пулсът му.

4. Изчакайте Спешна помощ или следвайте насоките, дадени от 112.

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

The Intersection of Encryption and AI

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/the-intersection-of-encryption-and-ai.html

As part of their 20th Anniversary celebration, Dark Reading asked five cybersecurity industry leaders who wrote blogs or columns for them over the years to select their favorite piece and share their reflections on the topic today. This is my section.

Renowned technologist and author Bruce Schneier contributed a column on June 20, 2010, warning about cryptography’s inability to secure modern networks, a point he says he has been trying to argue since 2000.

“For a while now, I’ve pointed out that cryptography is singularly ill-suited to solve the major network security problems of today: denial-of-service attacks, website defacement, theft of credit card numbers, identity theft, viruses and worms, DNS attacks, network penetration, and so on.

“Recently, I talked to a former NSA employee at a conference. He told me that back in the 1990s, he had a copy of my book Applied Cryptography by his desk, as did many other cryptographers working at Ft. Meade. People were allowed to refer to it, but they were not allowed to cite it.

“The 1990s were an important decade for cryptography. This was before the internet went mass market, when cryptography was just emerging from a niche academic discipline to a mainstream engineering one. There wasn’t much that programmers could read. The NSA used my book for the same reason it became a bestseller: because it collected all the academic cryptography of the time in one place and made it understandable to people who weren’t mathematicians. They feared it for exactly the same reason.

“I’ve been thinking about that conversation as I revisit a 2010 essay I wrote for Dark Reading, ‘The Failure of Cryptography to Secure Modern Networks.’ Cryptography has inherent mathematical properties that greatly favor the defender. Adding a single bit to the length of a key adds only a slight amount of work for the defender but doubles the amount of work the attacker has to do. Doubling the key length doubles the amount of work the defender has to do (if that—I’m being approximate here) but increases the attacker’s workload exponentially. For many years, we have exploited that mathematical imbalance.

“Computer security is much more balanced. There’ll be a new attack, and a new defense, and a new attack, and a new defense. It’s an arms race between attacker and defender. And it’s a very fast arms race. New vulnerabilities are discovered all the time. The balance can tip from defender to attacker overnight, and back again the night after. Computer security defenses are inherently very fragile.

“That isn’t a new idea. I said much the same thing in the preface to my 2000 book, Secrets and Lies:

“‘Cryptography is a branch of mathematics. And like all mathematics, it involves numbers, equations, and logic. Security, real security that you or I might find useful in our lives, involves people: things people know, relationships between people, people and how they relate to machines. Digital security involves computers: complex, unstable, buggy computers.’

“I especially like how I phrased it in 2016: ‘Cryptography is harder than it looks, primarily because it looks like math. Both algorithms and protocols can be precisely defined and analyzed. This isn’t easy, and there’s a lot of insecure crypto out there, but we cryptographers have gotten pretty good at getting this part right. However, math has no agency; it can’t actually secure anything. For cryptography to work, it needs to be written in software, embedded in a larger software system, managed by an operating system, run on hardware, connected to a network, and configured and operated by users. Each of these steps brings with it difficulties and vulnerabilities.’

“It’s a lesson we have all learned over the decades. Cryptography is still necessary for cybersecurity—although I wouldn’t have used that word back then—but is not sufficient. There are particular attack and forms of mass surveillance that cryptography prevents. But as computers have infused throughout our lives, and networks have connected all those computers, those aspects of cybersecurity have become increasingly important, and vulnerable.

“Today, the cybersecurity world is changing yet again, this time due to the capabilities of artificial intelligence. AI isn’t advancing cryptography, but it’s changing cybersecurity. AI has demonstrated a superhuman ability to find vulnerabilities in software and to write exploits. A similar ability to write patches is probably coming. This has profound implications for both attackers and defenders, and it is unclear who will win the particular arms race in a world of what I call instant software.”

Microsoft Threatening Security Researcher

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/microsoft-threatening-security-researcher.html

An anonymous security researcher called “Nightmare Eclipse” has been publishing a series of significant security exploits against Microsoft Windows—including one that breaks BitLocker. Microsoft has threatened legal action against the researcher. Lots of recriminations are being traded back and forth.

Building confidence to teach AI in the classroom

Post Syndicated from Hayley McKechnie original https://www.raspberrypi.org/blog/building-confidence-to-teach-ai-in-the-classroom/

Hayley McKechnie is a computing lead at a primary school in the East of England, who shares in this blog how she supports her students and her fellow teachers to build confidence around artificial intelligence (AI). She developed her skills through training delivered by Parent Zone, our partner for Experience AI in the UK.

Artificial intelligence is part of everyday life for young people, but teaching students what AI is, how it works, and why it should be used responsibly can still be a challenge.

As a computing lead at a school in the East of England, the Experience AI programme has played a central role in building my confidence, as well as that of my colleagues, when it comes to teaching AI in the classroom.

Through professional development, practical classroom materials, and a strong focus on ethics, the programme has helped me bring AI to life in a way that feels accessible, age-appropriate, and responsible.

Building confidence through training

I began my AI education journey by attending training sessions hosted by Parent Zone to strengthen my own understanding of artificial intelligence. This felt like an important first step, because many teachers are learning about AI alongside their students.

Educator in the classroom with Experience AI

The training really helped me understand how AI actually works. That’s so important, because if you’re not confident in your own understanding, it’s very difficult to explain it clearly to children.

At first, I trialled one or two lessons with my students, introducing concepts gradually as AI tools became more visible in everyday life. As my confidence grew, I started using more of the materials, and this year I plan to deliver the full six-week unit as a dedicated part of our computing curriculum.

What I particularly like is how clear and straightforward the programme is. The training makes it easy for teachers to pick up, while still giving students a solid foundation in how AI works.

Before starting AI lessons, I always ground learning in familiar examples, such as voice assistants, search engines, and design tools. This helps students see that AI isn’t abstract; it’s already part of their everyday lives.

Making ethics central

One of the biggest strengths of the Experience AI training, in my view, is its strong emphasis on ethics and critical thinking. Rather than presenting AI as something to trust automatically, it encourages students to question and evaluate the technology they use.

Young learners in the classroom using Experience AI resoruces

I want my students to understand that AI can be helpful, but it isn’t infallible and shouldn’t be relied on blindly.

For example, I’ve shown students how AI-generated search results can sometimes be inaccurate. It’s a simple but effective way to demonstrate why human judgement still matters. These kinds of discussions help students understand both the potential and the limitations of AI, reinforcing the idea that technology should support thinking rather than replace it.

Learning alongside colleagues

Beyond my own classroom, I’ve also used Experience AI training to support other teachers. As part of my role coordinating computing across schools in my region, I organised a cluster meeting for 20 computing leads from across Essex, Suffolk, and Norfolk.

The session gave teachers the opportunity to share experiences, explore how AI could be introduced in age-appropriate ways, and discuss how to embed ethical considerations across the curriculum. A Parent Zone trainer led the session and helped deepen our understanding.

Many computing teachers are still getting to grips with AI themselves. The training helped me feel more confident, and that’s something I’ve been keen to pass on to others.

Feeling inspired?

You can access all of our AI literacy and safety resources for free via the Experience AI website. Start exploring today and discover classroom-ready lesson plans, slide decks, and activities. 

Interested in joining the next group of teachers to be trained on Experience AI? If you’re a UK teacher, visit Parent Zone’s website to enrol in the next cohort of educators. Or if you’re outside the UK, visit our Partners page to find out about teacher training sessions in your country.

The post Building confidence to teach AI in the classroom appeared first on Raspberry Pi Foundation.

По-късо майчинство? Защо не по-дълго бащинство?

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

bTV смениха свое заглавие, когато на Радевите хора им стана неудобно как изглеждат нещата. Става въпрос за статия към интервюто им с Владимир Николов, който вече е депутат от партията на Радев. Оригиналното заглавие е за по-късо платено майчинство и по обед са го сменили със сравнение с Гърция, което впрочем е само по себе си дори грешно. Кой ли се е обадил на кого, за да стане така? Или редакторите сами са се сетили? Някак си второто е по-лошо.

Смяна на заглавието на статията в bTV в рамките на няколко часа

Трябва ли да има по-късно майчинство?

Не, но… има две ключови мерки, които трябва да въведат.

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

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

Важна подробност – това е дългосрочна инвестиция и първите ще заработят чак след 2-3 години и то ако се намери достатъчно персонал и най-вече ако махнат безсмисленото изискването за медицински сестри в яслите. Т.е. за децата, които сега се раждат ще има обещание за повече ясли. Може би…

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

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

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

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

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

Иначе bTV явно са били информирани или са се сетили, че опита им за журналистика не е Радевоугодна и освен да сменят заглавието горе са изтрили и публикацията си във Facebook, където старото заглавие се пази. До края на деня други от Радевите вече говориха, че не планират намаляване на майчинските, а искали повече ясли. Как ще стане това обаче не става ясно та им давам свободно да използват моите предложения.

Intel Computex 2026 Keynote Live Coverage

Post Syndicated from Ryan Smith original https://www.servethehome.com/intel-computex-2026-keynote-live-coverage/

Closing out Computex’s day 2 keynotes is Intel, where CEO Lip-Bu Tan will be outlining Intel’s vision for the Intelligence Era and engineering AI hardware across multiple markets. Come join ServeTheHome for our live blog coverage of the keynote

The post Intel Computex 2026 Keynote Live Coverage appeared first on ServeTheHome.

Marvell Computex 2026 Keynote Live Coverage

Post Syndicated from Ryan Smith original https://www.servethehome.com/marvell-computex-2026-keynote-live-coverage/

Marvell’s keynote address will lead off day 2 of Computex 2026, where CEO Matt Murphy is taking the stage to discuss the need for and future of connectivity in AI data centers. Come join ServeTheHome for our live blog coverage of the keynote

The post Marvell Computex 2026 Keynote Live Coverage appeared first on ServeTheHome.

Scaling oncology patient support: How New York Cancer and Blood Specialists transformed customer experience with AWS and Pronetx, now part of Caylent

Post Syndicated from Muni T. Bondu original https://aws.amazon.com/blogs/architecture/scaling-oncology-patient-support-how-new-york-cancer-and-blood-specialists-transformed-customer-experience-with-aws-and-pronetx-now-part-of-caylent/

As one of the United States’ leading oncology and hematology providers, the goal of New York Cancer and Blood Specialists (NYCBS) is to provide comprehensive and compassionate care to patients. The organization handles more than 250,000 patient calls every year across over 100 specialized queues and wanted to optimize its manual call handling process.

This post details how NYCBS partnered with Amazon Web Services (AWS) and AWS partner Pronetx (now part of Caylent) to migrate to Amazon Connect Customer, the AWS cloud contact center service. The migration delivered a 54 percent improvement in patient enrollment and transformed the way NYCBS connects with the patients who need them most.

Solution overview

NYCBS chose to migrate to a dedicated Amazon Connect Customer instance with the help of Pronetx, an AWS partner specializing in Amazon Connect Customer. The 13-week engagement covered three phases: discovery and foundation (2 weeks), build and implementation (8 weeks), and acceptance testing and go-live (3 weeks).

This solution uses Amazon Connect Customer as the core contact center service. At the heart of the customer experience infrastructure lies the call routing and patient communication logic. Within this infrastructure, several key components work together to deliver HIPAA-compliant patient care.

Architecture

The architecture has three main layers, as shown in the following diagram. Each layer is designed to handle a specific aspect of the customer experience operations of NYCBS while maintaining HIPAA compliance throughout.

Architecture diagram showing the three-layer NYCBS contact center solution built on Amazon Connect. The diagram illustrates: (1) CTR management microservice with Amazon API Gateway, AWS Lambda, and Amazon DynamoDB; (2) core contact center services with Amazon Connect instance, AWS Secrets Manager, Amazon Polly, and IVR Lambda functions; (3) call recording and AI/ML pipeline with Amazon S3, Amazon Transcribe, and Amazon Lex. Shared AWS services include AWS CloudFormation, AWS IAM, AWS KMS, Amazon CloudWatch, and Amazon SNS. External integrations include Microsoft Intune ID and NYCBS on-premises systems.

Figure 1: NYCBS customer experience solution architecture on Amazon Connect, showing the CTR management microservice, core contact center services, and call recording and AI/ML pipeline layers, integrated with shared AWS services and external systems.

CTR management microservice

This layer handles contact trace record (CTR) processing through Amazon API Gateway as the entry point. The microservice uses AWS Lambda functions (Get Disposition Code and Update CTRs) to retrieve and process call disposition codes, with Amazon DynamoDB storing disposition code data for quick retrieval.

Core contact center services

The central Amazon Connect Customer instance manages incoming agent flows and call routing across more than 100 specialized queues. AWS Secrets Manager securely stores credentials and sensitive configuration. Amazon Polly provides text-to-speech capabilities for automated voice responses. Configuration is managed through DynamoDB configuration tables and configuration Lambda functions, with IVR Integration Lambda functions handling IVR workflows.

Call recording and AI/ML pipeline

Call recordings and artifacts are stored in Amazon Simple Storage Service (Amazon S3). A dedicated Lambda function handles voicemail processing, with Amazon Transcribe converting voicemails to text. A subsequent Lambda function then creates cases from transcribed voicemails. AI capabilities are powered by Amazon Lex for conversational chatbots and other AWS AI services for intelligent automation, with OMS Lookup providing Order Management System integration.

Shared services and integrations

The architecture integrates with external systems including Microsoft Intune ID for identity management and the on-premises systems of NYCBS. Shared AWS services provide the foundation:

Together, these components helped NYCBS reduce patient enrollment time by 54 percent. The reduction came through automated multi-language routing in English, Spanish, Russian, and Mandarin. NYCBS also added specialty-based queue prioritization for urgent cases and real-time agent monitoring across the more than 250,000 annual patient calls. The implementation maintains HIPAA compliance through role-based access controls, encryption with AWS KMS, and secure credential storage.

Technical highlights

A key engineering decision was moving from a shared multi-tenant environment to a dedicated Amazon Connect Customer instance. This architectural shift helped NYCBS implement several capabilities that had previously been unavailable:

  • Multi-language routing (English, Spanish, Russian, and Mandarin) through language-detection flows.
  • Specialty-based queue prioritization for urgent oncology cases.
  • After-hours coverage logic with automated callback options.
  • HIPAA-compliant call recording with role-based access controls.
  • Real-time agent monitoring and performance dashboards.

Key takeaways

A dedicated Amazon Connect Customer instance gives healthcare organizations the flexibility, security, and native feature access that multi-tenant environments can’t match, including the following:

  • Multi-language, specialty-based routing (English, Spanish, Russian, Mandarin) directly improved patient access to the right care team.
  • Migrating from manual workflows to automated IaC-driven continuous integration and continuous delivery (CI/CD) deployment removed third-party management fees and reduced operational costs.
  • HIPAA compliance was maintained throughout using AWS KMS encryption, role-based access controls, and AWS Secrets Manager for credential storage.
  • A 54 percent improvement in patient enrollment shows that modernizing contact center operations delivers measurable clinical and business outcomes.

Results

Within the 13-week implementation window, NYCBS achieved a 54 percent improvement in patient enrollment, which reflects not only operational efficiency, but also improved access to care. The organization removed third-party management fees through direct AWS consumption, reducing operational costs. NYCBS gained real-time visibility into call quality through Operata and the conversational analytics capabilities of Amazon Connect Customer. In addition, the team established a rapid CI/CD pipeline that deploys new features safely and quickly without disrupting patient services.

Conclusion

If your healthcare organization manages complex, high-volume contact center operations, you can apply what NYCBS achieved. A dedicated Amazon Connect Customer instance provides the flexibility, security, and native feature access that healthcare-specific workflows demand. We recommend the following next steps to get started:

Learn more

AWS Partner spotlight

Pronetx, now part of Caylent, an AWS Premier Tier Services Partner, specializes in Amazon Connect. Pronetx helps organizations design, migrate, and operate customer engagement systems on AWS, with a focus on resilience and AI-driven customer experience.

Contact Pronetx | Partner Overview | AWS Marketplace

Get started with OpenAI GPT-5.5, GPT-5.4 models, and Codex on Amazon Bedrock

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/get-started-with-openai-gpt-5-5-gpt-5-4-models-and-codex-on-amazon-bedrock/

As we previewed in What’s Next with AWS 2026, we’re announcing the general availability of OpenAI GPT-5.5, GPT-5.4 models, and Codex on Amazon Bedrock, giving you access to frontier models and a coding agent for software development.

According to OpenAI, GPT-5.5 and GPT-5.4 models are excellent for coding, reasoning, agentic workflows, and complex professional work. You can use GPT-5.5 for the hardest customer workloads and GPT-5.4 for the best price-performance. You can call them through Responses API on Amazon Bedrock’s next-generation inference engine built for high performance, reliability, and security.

Codex is the OpenAI coding agent for AI-powered software development. According to OpenAI, more than 4 million developers use Codex every week to write, refactor, debug, test, and validate code across large codebases. With GPT-5.5 powering inference, Codex introduces a new class of intelligence optimized for complex, long-horizon developer workflows. You can use the Codex App, the Codex CLI, and IDE integrations with Visual Studio Code, JetBrains, and Xcode, with all model inference routed through the Responses API on Amazon Bedrock.

For customers with data residency requirements, all processing stays within the Bedrock Region you select. You pay per token with no seat licenses and no per-developer commitments.

GPT-5.5 and GPT-5.4 models on Bedrock in action
You can access the model programmatically using the OpenAI Responses API to call the bedrock-mantle endpoints through the OpenAI SDK, command-line tools such as curl.

Let’s start with OpenAI SDK for Python. Install OpenAI SDK.

pip install -U openai

Set the environment variables for authentication.

export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1"
export OPENAI_API_KEY="<BEDROCK_API_KEY>"
export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5"

Here is a sample Python code to call GPT-5.5 model on Bedrock:

import os
from openai import OpenAI
 
client = OpenAI(
    base_url=os.environ["OPENAI_BASE_URL"],
    api_key=os.environ["OPENAI_API_KEY"],
)
 
response = client.responses.create(
    model=os.environ["BEDROCK_OPENAI_MODEL_ID"],
    input=[
        {
            "role": "developer",
            "content": "You are a software engineer with excellent AWS cloud knowledge. Be concise and practical.",
        },
        {
            "role": "user",
            "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions.",
        },
    ],
    reasoning={"effort": "medium"},
    text={"verbosity": "low"},
)
 
print(response.output_text)

You can call directly the model endpoint using curl.

curl "$OPENAI_BASE_URL/responses" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "openai.gpt-5.5",
    "input": [
      {
        "role": "developer",
        "content": "You are a software engineer with excellent AWS cloud knowledge."
      },
      {
        "role": "user",
        "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
      }
    ],
    "reasoning": {"effort": "medium"},
    "text": {"verbosity": "low"}
  }'

You can use the Responses API when you want to use model-managed multi-turn state, need hosted tools, function tools, or richer tool orchestration, and run background or long-running work. To learn more, visit the OpenAI Cookbook Responses examples.

Using OpenAI Codex with GPT-5.5 on Amazon Bedrock
You can download Codex CLI, Codex App or Codex VS Code extension and get started with the Bedrock for model inference. Codex supports two Bedrock authentication pathways: Amazon Bedrock API key or AWS SDK credential chain. If you set AWS_BEARER_TOKEN_BEDROCK, Codex uses it first; otherwise Codex falls back to AWS SDK credential chain.

Set AWS_BEARER_TOKEN_BEDROCK in the environment that Codex will read:

export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key>

Then, configure your preferred Region and set the model ID to openai.gpt-5.5 in ~/.codex/config.toml, which is required for Bedrock API-key authentication. You can also choose openai.gpt-5.4, openai.gpt-oss-120b, or openai.gpt-oss-20b. For the desktop app or VS Code extension, put any environment variables the app needs in ~/.codex/.env.

model = "openai.gpt-5.5"
model_provider = "amazon-bedrock"
[model_providers.amazon-bedrock.aws]
region = "us-east-2"

Restart the desktop app or VS Code extension after changing ~/.codex/config.toml or ~/.codex/.env. In Codex CLI, you should see a /status tab that looks like this:

In Codex App, you can use GPT-5.5 model through Amazon Bedrock inference.

Things to know
Let me share some important technical details that I think you’ll find useful.

  • Model latency: OpenAI model information positions GPT-5.5 as fast and GPT-5.4 as medium speed, but customer-perceived latency depends on reasoning effort, output length, tool calls, background mode, Region, quotas, throttling, prompt size, and cache hits. Start GPT-5.5 at medium effort. Start GPT-5.4 with effort set explicitly rather than relying on its none default.
  • Scaling and capacity: Bedrock’s new inference engine is designed to rapidly provision and serve capacity across many different models. When accepting requests, we prioritize keeping steady state workloads running, and ramp usage and capacity rapidly in response to changes in demand. During periods of high demand, requests are queued, rather than rejected.

Now available
OpenAI GPT models and Codex on Amazon Bedrock are available today: GPT-5.5 model in the US East (Ohio) Region, GPT-5.4 model in the US East (Ohio) and US West (Oregon) Regions. Check the full list of Regions for future updates. To learn more, visit the OpenAI on Amazon Bedrock page and the Amazon Bedrock pricing page.

Give GPT-5.5, GPT-5.4 models, and Codex on Amazon Bedrock a try today and send feedback to AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

— Channy

Ombredanne: An AI agent ported our codebase from Python to Rust

Post Syndicated from jake original https://lwn.net/Articles/1075832/

Over on the AboutCode blog, lead
maintainer Philippe Ombredanne writes
about an agentic LLM system porting the ScanCode
Toolkit to Rust. In the process, the LLM (or the people behind it)
infringed the ScanCode trademark, stripped copyright and license notices,
“and started an outreach campaign, without ever engaging the AboutCode
community“. Ironically, the toolkit is used to scan source code and binaries in
order to figure out licensing and copyright information; it also reports on
package
dependencies, vulnerabilities, and more.

This is worth repeating: A comprehensive test suite, decent documentation, and curated datasets is what makes automated porting possible. It is also what makes a codebase easier to replicate without understanding it.

The agent’s initial approach, using an existing Rust license-detection library, failed to match ScanCode’s output quality. The agent then did what any translator would do when a loose paraphrase fails: it copied the original more closely. The final port reproduces ScanCode’s core algorithms, code organization, and data-driven architecture in Rust, not because the agent understood them, but because it had enough training data and test feedback to converge on equivalent code.

Multi-Region event-driven failover architecture with Amazon EventBridge and Route 53

Post Syndicated from Napoleone Capasso original https://aws.amazon.com/blogs/compute/multi-region-event-driven-failover-architecture-with-amazon-eventbridge-and-route-53/

Multi-Region Event-Driven Failover Architecture with Amazon EventBridge and Route 53

Event-driven architectures enable applications to respond to events in real-time, providing scalability and loose coupling between components. However, ensuring high availability across multiple AWS regions requires careful design of failover mechanisms. This post demonstrates how to build a resilient multi-region event-driven architecture using Amazon EventBridge, Amazon API Gateway, and Amazon Route 53 health-based failover.

Overview

Organizations building event-driven applications need to achieve high availability and disaster recovery capabilities. This architecture provides automatic failover between AWS regions while maintaining regional independence for event processing. The solution uses Amazon Route 53 health checks to monitor regional Amazon API Gateway endpoints and automatically routes traffic to healthy regions without manual intervention.

The architecture delivers several key benefits. Regional independence reduces latency by processing events in the same region where they originate. Amazon DynamoDB global tables provide automatic data replication across regions, ensuring data availability during regional failures. The solution provides robust failover capabilities while maintaining architectural simplicity.

Organizations with strict availability requirements can find this solution particularly valuable. All event processing remains within AWS regions, and failover occurs automatically based on health check results. The architecture supports both planned maintenance windows and unplanned regional outages, providing flexibility for operational needs.

Solution overview

The solution implements an active-passive multi-region architecture where events flow through Amazon API Gateway to regional Amazon EventBridge buses. Amazon Route 53 health checks monitor the primary region and automatically route traffic to the secondary region during failures. Each region processes events independently, while Amazon DynamoDB Global Tables replicate data across regions.

The following diagram provides an overview of the solution:

The above diagram depicts the multi-region architecture running across two AWS regions. The Route 53 DNS service serves as the main entry point for the application, with health checks monitoring both regions. Each region contains an identical stack with Amazon API Gateway, Amazon EventBridge, Amazon SQS, and AWS Lambda. The Amazon DynamoDB Global Table replicates data between regions automatically.

Solution deployment

To deploy this solution, follow the instructions in the GitHub repository and clone the repository. The solution deploys in two AWS regions. Ensure valid SSL certificates exist in AWS Certificate Manager (ACM) in both regions for the custom domain.

Prerequisites

For this walkthrough, the following resources are needed:

  • AWS Account: An AWS account with permissions to create and manage Amazon API Gateway, Amazon EventBridge, Amazon SQS, AWS Lambda, Amazon DynamoDB, Amazon Route 53, AWS IAM, and AWS CloudFormation resources
  • AWS Serverless Application Model (SAM): The AWS SAM CLI installed, as the templates use the SAM transform for Lambda and API Gateway resource definitions
  • Domain Name: A registered domain with a Route 53 hosted zone- SSL Certificates: ACM certificates for the custom domain in both deployment regions
  • AWS CLI: The AWS CLI installed and configured with credentials for the target AWS account
  • Region Selection: Two AWS regions for deployment

Walkthrough

The AWS CloudFormation templates from the sample GitHub repository create a secure, multi-region architecture that provides automatic failover for event-driven applications. The templates provision regional API Gateway endpoints, EventBridge buses, SQS queues, Lambda functions, and an Amazon DynamoDB Global Table. The solution establishes health monitoring through Route 53 health checks and configures DNS failover routing. The templates use AWS Serverless Application Model (SAM) transform to simplify Lambda and API Gateway resource definitions.

Step 1: Deploy the primary stack

The primary stack creates the foundational resources in the primary region. This includes the Amazon EventBridge bus, Amazon API Gateway with custom domain, health check, AWS Lambda function, Amazon SQS queue, and Amazon DynamoDB Global Table. The stack creates an EventBridge bus that receives events from API Gateway:

EventBus: 
Type: AWS::Events::EventBus 
Properties: 
Name: !Ref EventBusName

The API Gateway uses AWS service integration to forward events directly to EventBridge:

x-amazon-apigateway-integration: 
type: "aws" 
uri: !Sub "arn:aws:apigateway:${AWS::Region}:events:path//" 
credentials: !GetAtt ApiGatewayEventBridgeRole.Arn 
httpMethod: "POST"

The health check monitors the API Gateway endpoint to determine regional availability:

DomainHealthCheck: 
Type: AWS::Route53::HealthCheck 
Properties: 
HealthCheckConfig: 
Type: HTTPS 
ResourcePath: /Prod/health FullyQualified
DomainName: !Sub ${Api}.execute-api.${AWS::Region}.amazonaws.com 
Port: 443 
RequestInterval: 30 
FailureThreshold: 3

The Route 53 DNS record configures failover routing with the PRIMARY designation:

ApiDnsRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref HostedZoneId
Name: !Ref CustomDomainName
Type: A
SetIdentifier: primary-region
Failover: PRIMARY
HealthCheckId: !Ref DomainHealthCheck

The DynamoDB Global Table creates replicas in both regions:

DataTable: 
Type: AWS::DynamoDB::GlobalTable 
Properties: 
BillingMode: PAY_PER_REQUEST 
Replicas: 
- Region: !Ref AWS::Region 
- Region: !Ref SecondaryRegion

Note the `DataTableName` output value for use in the secondary stack deployment. The `CustomDomainURL` output provides the endpoint to invoke the solution.

Step 2: Deploy the secondary stack

The secondary stack creates identical resources in the secondary region , except for the Amazon DynamoDB table which references the existing Global Table. The secondary stack creates its own Amazon EventBridge bus, Amazon API Gateway, health check, AWS Lambda function, and Amazon SQS queue. The Route 53 DNS record uses the SECONDARY designation

Step 3: Event processing flow

Events flow through the processing pipeline in each region. API Gateway receives events and forwards them to EventBridge using the PutEvents API. EventBridge evaluates event rules and routes matching events to SQS queues. Lambda functions poll the SQS queues and process events in batches. AWS Lambda writes processed data to the DynamoDB Global Table, which replicates across regions.

The Lambda function processes events from the queue and writes to DynamoDB:

def handler(event, context): 
for record in event.get('Records', []): 
body = json.loads(record['body']) 
detail = body.get('detail', {}) 
event_id = body.get('id', '') 
item = { 'id': event_id, 'detail': detail, 'timestamp': datetime.utcnow().isoformat() } 
table.put_item(Item=item)

Testing

Fetch the custom domain URL and test it by sending an event:

curl -X POST https://api.example.com \-H "Content-Type: application/json" \ -d '{ "Detail": { "IsHelloWorldExample": "true" }, "DetailType": "POSTED", "Source": "demo.event" }' -v

The response includes an `X-Region` header indicating which region processed the request. Under normal conditions, this shows the primary region.

To test failover:

  1. Remove the base path mapping for the primary region:
aws apigateway delete-base-path-mapping \ --domain-name api.example.com \ --base-path '(none)' \ --region {primary-region}
  1. Delete the primary API Gateway stage:

aws apigateway delete-stage \ --rest-api-id <primary-api-id> \ --stage-name Prod \ --region {primary-region}

  1. Wait 2-3 minutes for the health check to fail. The Route 53 health check performs checks every 30 seconds with a failure threshold of 3, requiring 90 seconds to detect the failure.
  2. Send another request to the API endpoint:
curl -X POST https://api.example.com \-H "Content-Type: application/json" \ -d '{ "Detail": { "IsHelloWorldExample": "true" }, "DetailType": "POSTED", "Source": "demo.event" }' -v
  1. Verify the failover: The `X-Region` header now shows the secondary region, confirming successful failover.

Verify event processing in the secondary region:

  1. Check the Lambda logs for successful processing:

aws logs tail /aws/lambda/<secondary-lambda-name> --region {secondary region}

You should see log entries similar to:

Processing message: 
{"version":"0",
"id":"abc12345-...",
"source":"demo.event",
"detail-type":"POSTED",...} 
Event Source: demo.event
Detail Type: POSTED
Successfully wrote item to DynamoDB: abc12345-... 
Successfully read item from DynamoDB: 
{'id': 'abc12345-...', 
'source': 'demo.event', 
'detailType': 'POSTED', 
'detail': 
{'data': {'IsHelloWorldExample': 'true'}, 
...}, 
'timestamp': '2025-01-15T18:30:00.000000', 
'processed': True}
  1. Verify the data in Amazon DynamoDB:

aws dynamodb scan \ --table-name <table-name> \ --region {secondary region}```

The scan results should include items with the event details:

{ "Items": 
[ { "id": {"S": "abc12345-..."}, 
"source": {"S": "demo.event"}, 
"detailType": {"S": "POSTED"},
"detail": 
{"M": {"data": 
{"M": 
{"IsHelloWorldExample": 
{"S": "true"}}}}}, 
"timestamp": {"S": "2025-01-15T18:30:00.000000"},
"processed": {"BOOL": true} } ], 
"Count": 1 }
  1. Restore the primary region – recreate the stage:

aws apigateway create-stage \ --rest-api-id <primary-api-id> \ --stage-name Prod \ --deployment-id <deployment-id> \ --region {primary region}

  1. Restore the primary region – recreate the base path mapping:

aws apigateway create-base-path-mapping \ --domain-name api.example.com \ --rest-api-id <primary-api-id> \ --stage Prod \ --region {primary region}

You can find the “deployment-id” by running: aws apigateway get-deployments \ --rest-api-id <primary-api-id> \ --region {primary region}

After 2-3 minutes, the health check passes and Route 53 routes traffic back to the primary region.

Cleanup

To remove the solution and avoid ongoing charges, delete the CloudFormation stacks in the correct order. Delete the secondary stack first, then the primary stack. This order is important because the Amazon DynamoDB Global Table is owned by the primary stack. Warning: Deleting these stacks permanently removes all resources including the Amazon DynamoDB global table and any event data stored in it. Back up any data you need before proceeding. This action cannot be undone. The following resources incur costs while deployed:

  • Amazon API Gateway (REST API)
  • Amazon Route 53 health checks and DNS records
  • Amazon DynamoDB global table (with cross-region replication)
  • AWS Lambda function invocations and duration
  • Amazon SQS queue operations
  • Amazon CloudWatch Logs storage

Delete the secondary stack:

aws cloudformation delete-stack --stack-name secondary-stack --region {secondary region}

Wait for the secondary stack deletion to complete:

aws cloudformation wait stack-delete-complete --stack-name secondary-stack --region {secondary region}

Delete the primary stack:

aws cloudformation delete-stack --stack-name primary-stack --region {primary region}

Wait for the primary stack deletion to complete:

aws cloudformation wait stack-delete-complete --stack-name primary-stack --region {primary region}

This removes all resources including the Amazon EventBridge buses, Amazon API Gateways, AWS Lambda functions, Amazon SQS queues, Amazon DynamoDB Global Table, Amazon Route 53 health checks, DNS records and IAM roles.

Conclusion

This post demonstrates how to establish a resilient multi-region architecture for event-driven applications using Amazon EventBridge, Amazon API Gateway, and Amazon Route 53. The solution uses Route 53 health-based failover, a powerful capability that automatically routes traffic to healthy regions based on health check results. This architecture significantly enhances application availability by providing automatic failover during regional outages while maintaining regional independence for event processing.

[$] Representing the true signatures of kernel functions

Post Syndicated from daroc original https://lwn.net/Articles/1073762/

Optimizing compilers can, under some circumstances, infer when a parameter to a
function is not needed, and remove it. This is all well and good until the
kernel’s tracing or BPF subsystems need information on how to call the function
or where its arguments are stored.
Alan Maguire and Yonghong Song spoke at the 2026

Linux
Storage, Filesystem, Memory-Management, and BPF Summit about their work on
recording information regarding changed function signatures in the kernel’s BTF debugging
information, to better support tracing such functions.

NVIDIA Computex 2026 News Bytes: Vera Rubin Now In Production, DGX Station Gets Windows

Post Syndicated from Ryan Smith original https://www.servethehome.com/nvidia-computex-2026-news-bytes-vera-rubin-now-in-production-dgx-station-gets-windows/

At Computex 2026, NVIDIA announced that its next-gen Vera Rubin platform is now in full production. The company is also bringing Windows to its high-end DGX Station systems, which will be available in Q4

The post NVIDIA Computex 2026 News Bytes: Vera Rubin Now In Production, DGX Station Gets Windows appeared first on ServeTheHome.

How we reduced core unit boot time from hours to minutes

Post Syndicated from Giovanni Pereira Zantedeschi original https://blog.cloudflare.com/optimizing-core-unit-boot-time/

Cloudflare’s core is the centralized data centers that run our control plane, billing, and analytics — distinct from the globally distributed edge that handles user traffic. Core servers are bare metal, and when issues happen during reboot, the consequences can cascade fast. 

Their boot sequence is orchestrated by UEFI, the modern firmware standard that initializes hardware and hands off control to the operating system. Small quirks in that handoff can have outsized consequences.

After a routine firmware update, some of our core servers were taking four hours to come back online, rather than just minutes as they did before. What should have been a one-day fleet-wide rollout was stretching into multi-day slogs. New nodes faced the full timeout gauntlet on their very first boot. Maintenance windows ballooned. Engineering teams had to babysit upgrades that should have run unattended. 

This issue affected the entire Gen12 fleet — nearly 2,000 units. Every unexpected failure mid-upgrade meant restarting the entire cycle, and new capacity sat idle waiting for the timeout gauntlet to clear.

This is the story of how we tracked the cause to a firmware quirk and an over-eager linear search through every available network boot interface, and how we cut total boot and upgrade time from hours back down to minutes. Along the way, we’ll share what we learned about UEFI internals, vendor-specific quirks, and the automation strategies that ultimately solved the problem.

The network boot interface

A network boot interface allows a server to boot its operating system over the network instead of from local storage. This is critical for centralized, automated, and scalable control over how machines start up,  especially across a globally distributed fleet serving different workloads. Since our servers are located in different environments and serve different purposes, they have different requirements for a specific network boot interface. The two primary interfaces are the Preboot Execution Environment (PXE) and Unified Extensible Firmware Interface (UEFI) HTTPS boot. 

As part of our reboot process, our servers usually go through PXE for various automation reasons. At Cloudflare, we use the open-source iPXE, an open-source network boot firmware that supports modern protocols like HTTP and HTTPS. This allows computers to boot operating systems directly from web servers, the cloud, or enterprise storage networks with significantly faster speeds and greater reliability.

For organizations, iPXE turns the boot process into a programmable workflow. It offers advanced scripting capabilities that allow IT teams to automate complex deployments, such as provisioning servers based on specific hardware configurations or managing secure, diskless workstations. 

Some of our hardware supports HTTPS-based UEFI network boot, which enables the computer’s motherboard firmware to natively download operating system files securely.

The linear search

Our tale begins with that fateful firmware update. Following the update, the first reports came through our internal channels: servers weren’t coming back online. Monitoring dashboards showed machines stuck in a pre-OS state for far longer than expected. Our initial suspicion was a firmware regression: perhaps the update itself had introduced a bug that was hanging the boot process.

To rule that out, we pulled up the serial console on an affected machine and watched a boot cycle in real time. The firmware Power On Self Test (POST) completed normally and hardware initialization looked healthy. But then, instead of quickly reaching the network boot stage and pulling down an OS image, the server sat waiting. And waiting. 

The console output told the story: the system was attempting an IPv4 HTTPS network boot, timing out after several minutes, then trying IPv4 iPXE, timing out again, then repeating both — all before finally reaching the IPv6 HTTPS boot interface that would actually succeed.

Every failed network boot attempt burned roughly five minutes waiting for a timeout response. With four attempts stacking up before the correct interface was reached, a single boot cycle wasted around twenty minutes. For a routine reboot, that’s painful. For firmware upgrade automation, which requires multiple sequential reboots, one per component, those twenty-minute penalties compounded into nearly four hours of idle waiting per server. 


No searching games: Declare my boot interface

After tracing the boot sequence and isolating the timeout pattern, the root cause became clear: the servers were blindly searching through every available network boot interface, one by one, waiting for each to fail before moving on. The fix was to eliminate the guesswork entirely — declare the correct boot interface upfront so the system never wastes time on interfaces that will never respond.

But putting this into practice was far from straightforward. As we explain next, we hit several obstacles: the order of our boot automation workflow, a setting we were blocked from changing, and differing string formats from our different network interface card vendors.

Our boot automation workflow

Our boot automaton flow is in three broad stages: firmware initialization, pre-boot, and kernel startup. After power on, the UEFI firmware does some hardware and peripheral initialization followed by the PXE pre-boot environment. The pre-boot sets up the network card and executes a small program called bootloader, which kickstarts the kernel. It’s in this PXE stage that various network interfaces are probed for the right one. On first boot, firmware upgrades are included in our boot automation workflow. 

And because each firmware upgrade requires a reboot (and its attendant network boot attempt sequence), that’s how we got to the situation where the total boot time took close to four hours. 


By restructuring the automation sequence to declare the network boot interface order early on in the pre-boot PXE stage for each hardware/use-case, we were able to cut the total time by about an hour, since the boot process no longer needed to spend 20 minutes probing for each firmware upgrade. 


Attempting to declare the network boot interface order introduced two specific constraints:

  1. Legacy Support: Boot ordering is not supported on older UEFI versions

  2. Persistence: Configuration settings are often reset following a UEFI firmware upgrade

To address these edge cases, we implemented a state validation step. The firmware automation now validates the configuration post-change: if it detects that settings have been modified, it re-applies the config and triggers a reboot.

Although the first boot may take slightly longer, this change drastically reduces the time required for all future start-ups from about 20 minutes to less than a minute per subsequent boot. 

Setting the boot order disabled by the vendor

The internal data structure of the Network Boot settings is an EFI_IFR_REF3 data structure that was being lazy loaded, meaning the data is not instantiated until it is explicitly accessed via a GUI callback:

typedef struct _EFI_IFR_REF3 {
  EFI_IFR_OP_HEADER          Header;
  EFI_IFR_QUESTION_HEADER    Question;
  EFI_QUESTION_ID            QuestionId;
  EFI_GUID                   FormSetId;
} EFI_IFR_REF3;

While this is standard industry practice to accelerate BIOS boot times, it rendered the “Network Boot Interface” invisible to our programmatic scans. Because the structure hadn’t been “loaded” yet, our automation couldn’t discover the priorities.

We worked with our vendors to enable specific tokens within the fixed “Boot Order Module.” This forces the discovery of the Network Boot Interface during the boot sequence without requiring manual GUI interaction.

The UEFI from our equipment manufacturers had an immutable setting, Force Priority Httpv4 Httpv6 Pxev4 Pxev6, that was preventing us from changing the boot order.

This required a new BIOS version from our vendor and a debug session when setting the boot order.

Different strings from different network interface card vendors

Depending on the network interface card (NIC) vendor, the strings would be different, causing a mismatch when configuring the boot order through iPXE.

Examples:

UEFI: HTTPS IPv4 Ethernet Network Adapter XXX-XXX-Y for OCP 3.0 P1
UEFI: HTTPS IPv4 Network Adapter - 50:00:E6:8F:4F:32 P1

In order to work around this issue, we had to implement an additional feature to the CfHIIConfig_App tool, allowing it to set the config without having the full string:

.*HTTP.*IPv4.*P1

The config would then be matched against the accepted config strings and would select the correct boot order. We are currently working with our UEFI vendors to standardize the network interface strings to only make use of the relevant information (e.g. protocol, transfer type, port number, and physical slot index) and drop the product details like the MAC address. The product details, if needed, can be read from the embedded vital product detail information of the network interface card. That way we eliminate both configuration drift and the use of wildcards.

Inability to check the config via iPXE 

Since iPXE reads this variable as HEX, it was reading the string output as hex. To check if the network boot setting was modified and to reduce boot time (so we don’t have to print the variables before setting them), we implemented a boolean flag, uefi-same-hex, to indicate whether a configuration changed.

This enabled us to run a single set command instead of first running show to compare, and then set if the configuration was not in the desired state.

This enabled us to run a single set command instead of first running show to compare, and then set if the configuration was not in the desired state.

# construct path to read the update variable
set buffer-var-guid 91468514-75bc-4bb5-8f33-91efff9e9b1f
set var-upd-path efivar/CfHIIVarUpd-${buffer-var-guid}

#Run the config change command
imgexec <signed CF UEFI configuration App> set ${uefi-setting}=${uefi-value}

#Compare the update variable with the expected value if it has changed.
#If it has changed, set the local variable to reboot the system
iseq ${uefi-same-hex} ${${var-upd-path}} || set has-changed ${uefi-diff-hex}

The result: a more dynamic system

By eliminating the guesswork from our network boot sequence, we turned a four-hour ordeal back into a 3-minute process. The result is a system where changes are dynamic and no manual BIOS interactions are needed. A single BIOS firmware image serves all SKUs, configuration updates deploy at scale through our existing release pipeline, and the entire workflow operates from iPXE.

Metric

Before ordering change

After ordering change

Firmware Upgrade Automation

Nearly 4 hours

3 minutes

Subsequent Single Boot

About 20 minutes

Less than a minute

None of this would have been possible without digging deep into UEFI internals, collaborating closely with our OEM vendors to unlock capabilities like programmatic boot order control, and leveraging open-source tools like iPXE to build scalable automation.

With each passing day, Cloudflare’s OpenBMC team continues to learn about, experiment with, and optimize the boot process across our core fleet. If you are managing bare-metal infrastructure and struggling with slow server boot times, we hope this post has given you a practical framework for identifying and eliminating unnecessary delays in your own network boot sequence. For those interested in learning more about iPXE and network boot automation, check it out here!

Vulnerability Disclosure in the Age of AI

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/vulnerability-disclosure-in-the-age-of-ai.html

New article: “Responsible Disclosure in the Age of AI: A Call for Urgent Action,” by Melissa Hathaway.

Abstract: Artificial intelligence is fundamentally reshaping the balance between vulnerability discovery and remediation. Frontier AI models are now capable of autonomously identifying exploitable software vulnerabilities at unprecedented speed and scale. This development exposes decades of accumulated technical debt created by a software industry that prioritized rapid deployment over secure-by-design engineering practices. Drawing on the evolution of software assurance, vulnerability disclosure frameworks, and U.S. cyber policy, this perspective argues that the current moment represents a strategic inflection point for governments, industry, and critical infrastructure operators. The author examines the growing tension between offensive and defensive equities in cyberspace, the emergence of AI-enabled vulnerability discovery capabilities in both the U.S. and China, and the increasing risks posed by unsupported legacy systems and AI-assisted code generation practices. Responsible disclosure can no longer remain a reactive or fragmented process, but must become a coordinated national and international resilience effort involving governments, software vendors, infrastructure operators, and emergency response organizations. The article concludes with an urgent call for accelerated remediation, large-scale patch management coordination, and sustained investment in automated vulnerability repair capabilities before adversaries exploit this rapidly narrowing window of opportunity.

Building a scalable user search layer on top of Amazon Cognito

Post Syndicated from Philip Chen original https://aws.amazon.com/blogs/architecture/building-a-scalable-user-search-layer-on-top-of-amazon-cognito/

Imagine a teammate who needs to find a user across thousands of accounts with only a partial email address, a last name, and a known access level. How quickly can your team respond? If your use case involves straightforward searches on standard Amazon Cognito attributes, the built-in ListUsers API is likely all you need. But for advanced scenarios involving custom attributes, fuzzy matching, complex filtering, and sub-second response times, a dedicated search layer is the right investment.

Amazon Cognito provides robust user authentication and management capabilities for modern applications. As applications scale, development teams typically implement advanced search functionality to find users by partial email match, segment group membership, or audit across multiple custom attributes.

In this post, we show how to build a comprehensive scalable user search layer on top of Amazon Cognito using AWS Lambda, Amazon DynamoDB, and Amazon OpenSearch Service.

Solution overview

This solution extends Amazon Cognito with advanced search capabilities using AWS Lambda, Amazon DynamoDB, and Amazon OpenSearch Serverless.

Key capabilities:

  • Multiple search types: Exact match, prefix match, and fuzzy search
  • Complex filtering: Query across email, phone, groups, and registration date simultaneously
  • High performance: Sub-second response times at any scale
  • Automatic synchronization: Real-time updates as users authenticate or update profiles
  • API-driven: RESTful API with pagination support

The architecture uses Cognito Lambda triggers to capture user data during authentication, stores it in DynamoDB, and indexes it in OpenSearch Serverless through DynamoDB Streams. The following architecture diagram illustrates how these components work together.

Figure 1: Solution architecture for Searchable Cognito Users

Walkthrough

The solution architecture demonstrates two flows: Ingestion flow and Search flow.

Ingestion flow

The ingestion flow captures and indexes user data through two paths: Cognito Lambda triggers and AWS CloudTrail. Together, these paths maintain synchronization between the search index and Cognito without requiring manual intervention or scheduled batch jobs.

1. Cognito Lambda triggers

This path captures user data during authentication events using a Cognito trigger Lambda function that handles two trigger types: Post-confirmation and Pre-token generation. The post-confirmation trigger creates the initial user record on sign-up, while the pre-token generation trigger tracks login activity and app client information on each subsequent authentication. The pre-token generation trigger also provides access to the user’s group membership in the event payload, which is indexed as a searchable field. The flow operates through the following steps:

  1. Client initiates sign-up or login — User submits authentication request to Amazon Cognito.
  2. Post-confirmation trigger — On sign-up, Cognito invokes the Cognito trigger Lambda which creates the initial user record in the DynamoDB user table with profile attributes (email, name, groups).
  3. Pre-token generation trigger — On each login, Cognito invokes the Cognito trigger Lambda which updates the user’s login timestamp and app client information in the DynamoDB user table.
  4. Stream processing — DynamoDB Streams detects the new or updated record and triggers the OSS ingest Lambda.
  5. Index updated — OSS ingest Lambda processes the stream event and indexes the user data in OpenSearch Serverless.

Note: The Cognito Lambda triggers are deployed in a VPC. Cognito enforces a 5-second timeout on trigger functions. If you’re extending these triggers with additional functionality or already using post-confirmation or pre-token generation triggers, ensure the combined execution time stays well within this limit. Consider provisioned concurrency if cold starts are a concern.

Figure 2: User Data Ingestion via Cognito Lambda Triggers

2. CloudTrail

This path captures admin-initiated user changes that occur outside the authentication flow, such as creating users using the Cognito console or CLI. These actions don’t trigger Cognito Lambda triggers, so CloudTrail and EventBridge bridge the gap. The flow operates through the following steps:

  1. Admin action performed — User performs an admin action in Amazon Cognito (for example, create user, update attributes, add to group, disable user).
  2. API call logged — AWS CloudTrail captures the Cognito admin API call.
  3. EventBridge rule matched — An Amazon EventBridge rule matches the Cognito admin event.
  4. CloudTrail event Lambda invoked — EventBridge invokes the CloudTrail event consumption Lambda, which reads the current user state from Cognito and upserts the profile in the DynamoDB user table.
  5. Stream change event — DynamoDB Streams emits the change event.
  6. Invoke OSS Lambda — The stream event triggers the OSS ingest Lambda.
  7. Index user data — OSS ingest Lambda indexes the updated user data in OpenSearch Serverless.

Figure 3: User Data Ingestion via CloudTrail

Figure 4: Data model for indexed user attributes in Amazon DynamoDB

Search flow

With the search flow, authorized users can query the indexed user directory:

  1. Query submission — Authenticated user submits search query through the UI.
  2. Request validation — API Gateway receives the request with the Cognito JWT token and validates it using the Cognito authorizer.
  3. Search execution — Upon successful validation, the search Lambda function is invoked with the search parameters.
  4. OpenSearch query — Lambda assumes a read-only role for OpenSearch Service access and executes the query against the OpenSearch Serverless index.
  5. Results returned — Lambda formats and returns the query results to the frontend, where the UI displays them in a paginated format.

Figure 5: Search Flow Sequence Diagram

Figure 6: Demo UI user search integration on multiple properties

Figure 7: Demo UI user search integration on auto-suggest

Try it yourself

Ready to see this solution in action? The repository includes everything you need to deploy a complete working implementation in your own AWS environment.

The source code for this solution is available on GitHub at: https://github.com/aws-samples/sample-user-search-layer-for-cognito.

The repository includes everything you need: AWS CDK infrastructure code, Lambda function implementations, a React frontend, and documentation. You can have a fully functional searchable user directory running in your account in under 20 minutes. When you’re finished testing, clean up all resources to avoid ongoing charges.

Conclusion

In this post, you learned how to extend Amazon Cognito with advanced search capabilities. By combining OpenSearch Serverless, DynamoDB Streams, and Lambda functions, you can build a scalable, event-driven architecture that automatically maintains a searchable user directory with sub-second query performance.

This pattern unlocks powerful use cases: support teams can quickly locate users across thousands of accounts, administrators can segment users by group membership for targeted communications, and compliance teams can audit user attributes with complex filtering.

To dive deeper into the AWS services powering this solution:

About the authors

The collective thoughts of the interwebz