The Next Evolution of MDR: Preemptive Defense and Agentic Investigation

Post Syndicated from Mikayla Wyman original https://www.rapid7.com/blog/post/dr-the-next-evolution-mdr-preemptive-defense-agentic-investigation

For years, security operations followed a familiar sequence: detect suspicious activity, investigate what happened, and respond before it caused significant harm. That model developed in a threat landscape where defenders had considerably more time to establish the facts and decide what to do next. In 2019, the average data breach took 206 days to identify and another 73 days to contain, creating a total breach lifecycle of 279 days.

As the time between initial access and attacker movement continues to contract, security teams are being asked to operate within a much narrower window. AI is accelerating reconnaissance, vulnerability discovery, and campaign execution, while defenders are responsible for growing volumes of data across cloud, identity, endpoint, SaaS, and AI environments, often without equivalent growth in analyst capacity.

Managed detection and response is evolving to meet those conditions by connecting exposure intelligence, machine-speed investigation, and human expertise. This approach helps security teams identify credible risks sooner, understand their potential impact, and intervene earlier in the attack lifecycle.

MDR must move beyond alert-driven investigations

When suspicious activity generates an alert, traditional MDR typically moves into investigation mode. Analysts gather information about the affected asset or identity, correlate activity across security tools, establish the scope of the incident, and determine the appropriate response.

Although each step is necessary, much of the initial work involves finding and organizing information rather than applying expert judgment. Analysts can spend valuable time collecting asset details, checking vulnerabilities, validating signals, and reconstructing context before the investigation can progress.

Recent research conducted with Omdia found that 93% of security leaders agree AI improves analyst efficiency by automating repetitive tasks. Giving machines responsibility for routine evidence gathering and correlation allows analysts to focus their time on complex investigations, business impact, and response decisions.

Preemptive MDR connects exposure and detection

Exposure management and security operations often provide different views of the same environment. Exposure teams understand which vulnerabilities, assets, identities, and attack paths present risk, while detection and response teams see activity as it unfolds. Connecting these views gives analysts more context at the beginning of an investigation.

Preemptive MDR brings asset criticality, internet exposure, vulnerability data, and threat intelligence directly into the SOC workflow. When an alert appears, analysts can immediately see why the affected asset matters, which weaknesses may be involved, and whether the activity aligns with known attacker behavior.

The same context can also support action before an alert fires. Intelligence indicating stolen credentials or compromised sessions can be surfaced before an attacker uses them, while newly disclosed vulnerabilities can be assessed against the organization’s assets and business priorities. MDR teams can then guide remediation towards the exposures most likely to create a viable route into the environment.

By moving exposure intelligence closer to detection and response, investigations begin with a clearer understanding of what is happening and where action will have the greatest effect.

Agentic SOC capabilities accelerate investigation

By bringing security data together across the environment, connected context creates the foundation for agentic SOC capabilities. Security investigations require evidence gathering, correlation, validation, and scoping, with many of these tasks repeated across every alert.

AI agents can perform elements of that work in parallel by examining telemetry, connecting related activity, testing possible explanations, and presenting analysts with a structured account of what happened, what is at risk, and which actions are available. Analysts can then review the evidence and apply their understanding of the organization, its priorities, and the potential consequences of a response.

While AI can accelerate much of the investigation process, human oversight remains essential to the way this model operates. The same Omdia research found that 92% of security leaders believe analysts should retain responsibility for final decisions, while 90% view human oversight as essential to the accuracy and reliability of AI-driven processes.² Agentic SOC capabilities can support that balance by accelerating repeatable investigation work while keeping analysts responsible for decisions that require judgment and accountability.

Connected security data strengthens AI-driven MDR

Because security AI can only work with the data and context available to it, the quality of that foundation has a direct impact on the investigation. An investigation is more useful when the system can connect an alert to the affected user, asset, vulnerability, cloud resource, and wider attack path without requiring an analyst to search across several tools.

Rapid7’s data mesh brings together asset, cloud, configuration, exposure, event, and alert data in a normalized layer. This gives AI-driven investigations access to connected security context at the point of analysis and helps reduce the manual work involved in reconstructing it.

From faster response to continuous defense

Bringing exposure intelligence, connected security data, AI-driven investigation, and human expertise into the same operating model creates a continuous defense loop. Exposure context helps teams identify where attackers are most likely to find an opening, detection reveals how those risks are being used in practice, and response reduces the opportunities available to the next attacker.

This approach allows MDR to contribute beyond the investigation of individual alerts. Each incident can improve future detection and prioritization, while exposure insights can guide action before suspicious activity develops into a larger event. Analysts gain the context to make better decisions, and automation gives them more time to focus on the threats and business risks that require their expertise.

The next evolution of MDR will be defined by how effectively providers connect these capabilities. By combining preemptive insight with machine-speed investigation and accountable human decision-making, security teams can act earlier, investigate faster, and continuously strengthen their defenses as the threat environment changes.

Rapid7 will showcase upcoming investments in Preemptive MDR and Agentic SOC at Black Hat USA in Las Vegas, August 3–6, 2026.

Axon Is Another License Plate Surveillance Company

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/07/axon-is-another-license-plate-surveillance-company.html

Governments are switching, but I’m not sure it makes a difference:

…some municipalities, including Denver, Colorado, are ditching their Flock arrays. But keep in mind that if they’re only switching from Flock to another brand of license-plate readers, like Axon, it’s like a gambling addict trying to kick the habit by switching from FanDuel to DraftKings.

[…]

Despite what you may read on the Flock website, Axon cameras are pretty effective when it comes to hoovering up personal details that can go far beyond your license plate numbers. That means a municipality that opts for Axon cameras instead of Flock units won’t necessarily reduce the amount privacy its citizens lose through their use.

Bringing the global Bebras community together in Cambridge

Post Syndicated from Andrew Csizmadia original https://www.raspberrypi.org/blog/bringing-the-global-bebras-community-together-in-cambridge/

On 10–15 May, we welcomed the global Bebras community to Cambridge, UK for the 22nd Bebras International Task Workshop.

Full group photo

As organisers of the UK Bebras Challenge, we hosted this year’s annual Task Workshop, bringing together Bebras organisers, educators, and researchers from around the world to review and refine the computational thinking tasks in preparation for countries’ 2026 Bebras Challenges. The Bebras tasks young people see every November may look simple and playful, but each one has been carefully discussed, tested, debated, and improved by people who care deeply about helping young people develop problem-solving skills.

4 days, 101 delegates, 277 tasks

This May, we convened 101 delegates from 61 countries at the Møller Institute in Cambridge for the Bebras International Task Workshop, with more participants joining parts of the Task Workshop online to take part in the discussions, decisions, and community moments that make this annual gathering so special.

The meet and greet

277 tasks had been submitted by the Bebras community, including 4 by us. Over 4 intensive days, delegates worked in 8 working groups, considering everything about these proposed tasks: from clarity of wording and illustrations, to age suitability and accessibility, to the computational thinking involved. By the end of the workshop, 214 tasks including our 4 had been accepted.

Alex Parry from our team reflects:

“The effort that everyone put in was remarkable — the delegates who travelled from around the world, the sometimes slightly heated discussions about computational thinking and its wider implications, and the improvements to the tasks within the working groups.”

Promoting computational thinking around the world

These lively discussions are part of what makes the Bebras Challenge impactful. A Bebras task is more than simply a computational thinking puzzle and its answer. It invites curiosity, supports careful reasoning, and gives learners a fair opportunity to show how they think. Bringing together the perspectives of people from different countries and education systems makes the tasks richer, clearer, and more useful for teachers and learners everywhere.

The Bebras Challenge currently runs in schools in 78 countries. In 2025, more than 4 million students aged 6 to 19 took part, with an incredible 526,000 participants in the UK alone.

The Bebras tasks encourage logical reasoning, pattern recognition, abstraction, decomposition, and algorithmic thinking, often through engaging stories and visual puzzles.

Learning from a global community

Although the formal purpose of the Workshop is to review tasks, the event is also a valuable opportunity for the Bebras community to learn from one another. On the Wednesday evening, delegates took part in the Bebras marketplace, sharing posters, resources, ideas, and questions in a wonderful showcase of how creative and adaptable the community is.

The Bebras marketplace

We heard how Bebras is being delivered in countries where schools may have limited internet connectivity or access to computing hardware, including Ghana, Jamaica, Mexico, and Sri Lanka. We saw that many countries offer paper-based versions of the challenge to overcome technical barriers. We learned about Mexico’s work towards making the challenge accessible on smartphones.

There were also inspiring examples of countries extending computational thinking beyond the annual Challenge fortnight. Armenia has developed Bebras books, Brazil has a Bebras magazine, Indonesia is creating teacher training resources for all subjects, and Lithuania is using hands-on games to help learners explore computing concepts.

These examples are a powerful reminder that computational thinking does not require computers or programming skills: it can be explored through stories, games, puzzles, printed resources, teamwork, and discussion.

Laura Kirsop presenting

Thanks to Bebras, this is something we are bringing into other initiatives. Laura Kirsop, our Chief Technology and Product Officer, highlighted in the Workshop’s opening keynote how Bebras has influenced some of the Foundation’s educational products. For example, the unplugged Code Club resource Escape room: The jungle awakens uses previous years’ Bebras tasks in a new context to support clubs with access limitations.

Growing the Bebras community

Alongside the work of reviewing tasks, the Workshop also supports the continued growth of Bebras around the world. This year, 10 new provisional members — Bolivia, Cameroon, Ecuador, Ghana, Hong Kong and Macao, Luxembourg, Mongolia, Palestine, Sri Lanka, and Tanzania — were inducted, and 7 new full members were voted in: Armenia, Colombia, Greece, Jamaica, Mexico, Paraguay, and Puerto Rico.

Each new member country means more young people will have the opportunity to experience computational thinking in an accessible and engaging way, and more educators will be able to join the international conversation about how best to support learners.

Creating the conditions for collaboration

Hosting an international event such as this involves much more than providing meeting rooms and a timetable. The Workshop needed to support focused work, lively discussion, social connection, and participation from delegates joining remotely via livestreams.

We were pleased that our efforts were successful and recognised by delegates. One person described the event as “a truly positive experience on all fronts”, while another commented: “The planning and execution was flawless.” And for an event built around international collaboration, one piece of feedback was especially welcome: “The WiFi connection was phenomenal!”

Workshop

You can’t get everything right though, as one delegate joked when we asked what could be improved about this year’s workshop: “Sorry, the weather could have been better :-)” We will take that as a challenge for our next time as hosts!

The 23rd Bebras International Task Workshop will be held in Uruguay in May 2027. We wish the Uruguay team every success as they begin planning the next gathering of this inspiring international community.

What’s next for UK Bebras?

We are now preparing the tasks for the next UK Bebras Challenge, working in collaboration with the Bebras teams from Australia, Ireland, Canada, and the USA.

Across the world, the Bebras Challenge takes place every November and is completed and automatically marked online. For students, it’s a range of fun and engaging computational thinking tasks, to be answered within 45 minutes. For educators, Bebras is a powerful way to introduce and practice computational thinking with their learners.

If you’re an educator in the UK, you can try out past Bebras tasks to get a taste, and register now to be ready to set up your classes from September. This year, the UK Bebras Challenge will take place between 8 and 20 November.

Learn more about the UK Bebras Challenge

The post Bringing the global Bebras community together in Cambridge appeared first on Raspberry Pi Foundation.

Rapid7 and Exclusive Networks expand partnership to modernize security operations and accelerate customer success

Post Syndicated from Claudia Zoon original https://www.rapid7.com/blog/post/c-exclusive-networks-partnership-accelerating-customer-success

Claudia Zoon is Senior Manager, Channel Sales at Rapid7.

Across Belgium, the Netherlands, and Luxembourg, organizations are accelerating digital transformation through AI, cloud adoption, and increasingly connected business operations. These investments are creating new opportunities for innovation, but also reshaping the cybersecurity landscape.

In this dynamic environment, Rapid7 is excited to announce an expanded strategic distribution partnership with Exclusive Networks across the Benelux region. Why now? Because as organizations grow,  so too do the expectations of security teams. As attack surfaces expand, more sophisticated AI-enabled threats emerge; as compliance requirements evolve, leaders expect security to scale right along with the business – all without adding unnecessary complexity.

In this chaotic environment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.

Supporting a rapidly evolving market

The Benelux region has long been at the forefront of digital innovation. As organizations continue modernizing their infrastructure, they’re also preparing for increasingly rigorous cybersecurity requirements through regulations such as NIS2 and DORA. Along these lines, operational resilience has become a board-level priority, making it more important than ever for security teams to simplify operations while maintaining visibility across their environments.

Meeting these expectations requires more than technology; it requires partners who understand the regional market, can provide specialist expertise, and help customers navigate an increasingly complex cybersecurity landscape.

Why specialist partnerships matter

Channel partners play a critical role in acting as trusted advisors who help organizations modernize security operations through technology evaluation, solution implementation, and long-term security strategy build-out.

Our expanded partnership with Exclusive Networks reflects Rapid7’s continued investment in supporting that partner ecosystem.

Exclusive Networks has established itself as one of the region’s leading specialist cybersecurity distributors, combining deep technical expertise with a partner-first approach that prioritizes enablement, collaboration, and long-term growth. Together, we’re making it easier for partners to access the technical resources, training, and support needed to deliver stronger outcomes for their customers.

Helping partners grow

Rapid7’s AI-powered cybersecurity operations platform helps organizations simplify security operations by unifying exposure management, threat detection and response, managed services, and security automation into one platform.

Combined with Exclusive Networks’ cybersecurity expertise, technical enablement, and regional support, partners are better positioned to expand managed security services, strengthen customer relationships, and deliver integrated cybersecurity solutions that reduce complexity and improve cyber resilience.

Looking ahead

Cybersecurity success increasingly depends on strong partnerships that combine innovative technology with local expertise and long-term collaboration.

Rapid7 and Exclusive Networks share a commitment to helping partners grow and enabling organizations across Belgium, the Netherlands, and Luxembourg to modernize security operations with confidence.

We’re excited about the opportunities ahead and look forward to working together to help partners build stronger cybersecurity practices and deliver measurable and positive outcomes for customers across the Benelux region.

Ready to grow with Rapid7? Learn more about the Rapid7 PACT Partner Program and discover how Rapid7 and Exclusive Networks are helping partners strengthen cybersecurity operations across the Benelux region.

Научни новини: Генетични редакции, ракети и сателити

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-genetichni-redaktsii-raketi-i-sateliti/

Генетичните редакции скоро ще са в Европа

Научни новини: Генетични редакции, ракети и сателити

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

Мерките като цяло следват предложението на Комисията и в тях са обособени две категории растения.

Първата обхваща растения, получени с помощта на новите геномни технологии, като CRISPR, в които няма големи намеси, например внасяне на ДНК от други видове или промяна на големи участъци от генома. В текста има няколко специфични ограничения: внасянето на ДНК може да става само когато то е достъпно и при класическа селекция (тоест от видове, които могат да се кръстосат) и промените не могат да са по-големи от 20 нуклеотида. За изтриването на участъци няма ограничение колко дълъг отрязък може да се премахне, но общият брой на всички промени също е ограничен до 20 броя.

Пречките и надеждите пред CRISPR

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

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

Важно уточнение е, че от тази категория се изключват растения, които са устойчиви на хербициди и неприятели. Към момента устойчивостта и на двете се получава чрез вмъкване на чужда ДНК (обикновено бактериална) в генома на растенията. Например глифозатът – активното вещество в популярния „Раундъп“, нарушава синтеза на някои аминокиселини в растенията, като засяга един от ензимите, отговорни за това. Този ензим не се среща при животните, поради което пръскането не е токсично за тях.

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

Научни новини: ГМО и глобално затопляне

Да си поговорим за ГМО и глобално затопляне. В случая ще говори Михаил Ангелов чрез своите научни новини. Този път е подбрал две големи теми – за генетичните манипулации и за затоплянето на планетата.

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

Приемането им като еквивалентни на конвенционалните води и до това, че 

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

Означение ще има само на посевния материал.

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

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

Тоест разговаряме – епизод 7

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

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

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

Наред с биологичната безопасност стои въпросът с икономическата.

Към момента в Европа е възможно патентоването на генетично модифицирани растения, стига промените да не са резултат от „естествен биологичен процес“. С оглед на новите правила такъв тип патенти обяснимо създават напрежение, предвид силната концентрация на семепроизводството в няколко световни гиганта – четири фирми (Bayer, Corteva, Syngenta и BASF) контролират над 50% от световния пазар. Това им дава значителна преднина, тъй като те вече имат големи отдели за разработка на сортове с помощта на новите инструменти за селекция. 

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

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

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

Редактиране на генома с CRISPR

Михаил Ангелов • В последните няколко десетилетия в света на биотехнологиите са направени редица открития. Последният революционен скок в способността ни да променяме света около нас е CRISPR – инструмент, който позволява бързо, достъпно и прецизно редактиране на генома.

По думите на докладчика Джесика Полфьорд 

това е историческа победа за европейските фермери и бъдещето на Европа. 

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

До появата на подобни продукти има още време – предстои официалното приемане на текста от Европейския парламент, след което промените ще бъдат публикувани в Официалния вестник на ЕС и ще влязат в сила 20 дни след това. Пълното прилагане ще започне след 24 месеца, през които ще бъдат изготвени различните правилници, протоколи за наблюдение и други методики. Практически ефектите ще се усетят след средата на 2028 г.

Приземяване на ракети, приземяване на акции

Връщането на ракети беше интересна идея, която SpaceX успя да реализира преди 10 години, намалявайки значително разходите по извеждане на сателити в орбита.

Благодарение на тази иновация компанията се разви значително и стана един от най-важните космически оператори. Компанията на Илон Мъск успя да върне възможността на NASA да изпраща астронавти към Международната космическа станция, за което САЩ разчиташе на Русия и нейните ракети „Съюз“ в продължение на 9 години. В тази връзка, след като САЩ наложи санкции на Русия, директорът на „Роскосмос“ Дмитрий Рогозин коментира, че американците могат да използват трамплин, за да изстрелват астронавтите си. Последва саркастичният отговор на Мъск след първия полет на SpaceX до станцията: „Трамплинът работи.“

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

Миналия ноември ракетата New Glenn на Blue Origin – компанията, финансирана от Джефри Безос, се приземи на баржа, по подобие на подхода на SpaceX, след като успешно изпрати към Марс два апарата за NASA. Това са Blue и Gold в мисията EscaPADE, които ще изучават магнитосферата на планетата и как слънчевият вятър почти изцяло е заличил атмосферата ѝ. 

Към момента компанията планира да използва всяка ракета за поне 25 полета, което значително ще намали тяхната стойност. Впечатление направи и по-големият размер на ракетата, която е с около 10 метра по-висока от тази на SpaceX. В средата на април New Glenn полетя отново, оборудван с нови двигатели. Приземяването му беше успешно, но спътникът, който беше на борда, се оказа в по-ниска от очакваната орбита.

В началото на месеца успешно приземяване, отново на баржа, направи и китайската Long March 10B.

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

Този пуск е важен за китайската космическа програма, тъй като е част от по-голямата цел на страната за човешко присъствие в Космоса. Пряк аналог на 10B е 10А, с разликата, че е предвидена да качва не товар, а хора до китайската космическа станция „Тиенгун“. Успешното приземяване значи, че това ще може да става по-често и евтино. Още по-амбициозна е идеята за съединяване на три такива ракети, които могат да изнесат в орбита горна степен, която има възможност да стигне до Луната.

Ще полети ли България в Космоса?

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

Не е изключено от Китай да дойдат още изненади, защото в края на миналата година една частна китайска компания направи неуспешен опит за приземяване, последван от друга разновидност на Long March – 12A.

Успешни тестове се провеждат и в Япония. Миналата година Honda направи демонстрация на „подскок“ (hop), при който ракетата излита и се изкачва до 300 метра височина, а после се спуска и се приземява. Сходен прототип показа преди броени дни и японската космическа агенция JAXA. Той се изкачи до няколко метра, след което се придвижи хоризонтално и се приземи. Макар и далеч по-малки по размери в сравнение с нормалните ракети носители, тези прототипи показват ясно, че скоро преизползването им ще стане рутинно за повечето космически агенции и компании.

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

Според подадените от SpaceX документи преди първоначалното публично предлагане на акциите ѝ само около 7% от стойността на компанията е свързана с космическата ѝ дейност и със сателитния интернет Starlink. От документите става ясно, че SpaceX, изглежда, основно е ИИ компания и високата цена за дял от нея отразява потенциала ѝ да извежда изчислителни центрове в Космоса. Илон Мъск не дава подробности как планира да изпълни тези обещания и да реши важните технически проблеми, които стоят пред реализирането на подобни изчислителни центрове. 

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

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

Близнаците от NASA и ключът към живота ни в Космоса

NASA събира десет изследователски екипа, които проучват промените в човешкото тяло след продължителен престой в Космоса. В изследването участват и еднояйчните близнаци Кели. Скот престоява в Космоса една година, а брат му Марк остава на Земята. Анастасия Орманджиева разказва повече.

От инженерна точка с много големи радиатори и подходяща конструкция на сателитите не е невъзможно идеята да се осъществи, но с наличните в момента технологии (включително микрочипове), изпълнението ще е много скъпо и ще изисква сглобяване на центровете в Космоса, подобно на Международната космическа станция. Алтернатива е изстрелването на повече по-малки изчислителни центрове, но това пък ще вдигне цената поради нуждата от повече ракети и повече шасита, а също така ще увеличи броя сателити в орбита. Последното не е за пренебрегване, защото астрономите вече се оплакват от голямата флотилия спътници, обслужващи Starlink.

Междувременно SpaceX направи поредно тестово изстрелване на Starship – Flight 13. Този път на борда като тестови товар имаше няколко нови сателита Starlink V3, които се отделиха успешно от ракетата, но на суборбитална траектория, като след това се очакваше да изгорят в атмосферата. Самият Starship се представи добре, като най-впечатляващи бяха обръщането му в атмосферата – своеобразна проверка как се държат топлинните му щитове, и последващото меко кацане в океана. В бъдеще тези кацания ще бъдат на ракетни площадки, така че ракетата да може да се преизползва. Носителят Super Heavy се справи с изнасянето на Starship към Космоса, но при кацането се задействаха само част от двигателите му и той направи „твърдо приземяване“ в океана. Този тест беше важен за компанията и за NASA, защото е част от програмата Artemis за изпращане на астронавти на Луната.

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

AWS Shield Advanced is embracing the AWS WAF Anti-DDoS managed rule group: What changes and how to prepare

Post Syndicated from Eitav Arditti original https://aws.amazon.com/blogs/security/aws-shield-advanced-is-embracing-the-aws-waf-anti-ddos-managed-rule-group-what-changes-and-how-to-prepare/

Application-layer distributed denial of service (DDoS) attacks are difficult to detect because they closely resemble legitimate traffic. HTTP request floods are now among the most common vectors targeting web applications, using valid-looking requests that blend in with normal user activity.

In June 2025, AWS launched the AWS WAF Anti-DDoS managed rule group, built specifically for application-layer (L7) DDoS protection. AWS Shield Advanced is adopting it as the default application-layer protection, and in time as the only one. On July 27, AWS Shield Advanced begins adding the Anti-DDoS managed rule group to eligible web access control lists (ACLs) in Count mode. It will not cause any interruption to your traffic alongside your existing L7 automatic mitigation and WAF rules. In this blog post, we provide details regarding the Anti-DDoS managed rule group and when the change is expected to reach your web ACLs. You will understand the phases and steps that you need to take before the finish date, including how the monitoring and metrics will change.

Anti-DDoS managed rule group features

The Anti-DDoS managed rule group builds on what Shield Advanced automatic mitigation already provides. It profiles your traffic, learns what normal traffic looks like for your application, and establishes a baseline in minutes rather than hours. When an attack starts, it reacts within seconds and there are no health checks to configure. The rule group adds a Challenge action to the Block and Count actions you already use. Challenge decisions are driven by the AMR labels that mark the suspicion level of each inspected request. One option is a silent browser challenge, which has a background verification that runs in the visitor’s browser with no interstitial page, so legitimate users are never interrupted while automated traffic is filtered out. You can also exclude workload paths that don’t support Challenge, which fall back to Block mitigations instead. Sensitivity is configurable to Low, Medium, or High, and you set it separately for Block and Challenge. Block and Challenge are tuned independently; meaning you can run Challenge at high sensitivity to catch more suspicious traffic while keeping Block low to avoid dropping legitimate requests or reverse it for a stricter posture.

The rest is about cost and visibility:

  • It uses less capacity than before. The rule group needs 50 web ACL capacity units (WCUs), down from the 150 the previous protection required, providing you with capacity for the rest of your rules.
  • The dashboard ships in the AWS Management Console for AWS WAF. It’s there now, showing live DDoS events, match metrics, and the top URIs, geographies, and IP addresses driving traffic.
  • It labels everything it inspects. Requests get labels for event-detected, graduated suspicion levels, and specific rules. Match on those labels in your own AWS WAF rules when you need logic the rule group doesn’t cover.
  • You don’t pay for the attack traffic. During active mitigation, blocked DDoS requests drop out of your monthly count. That exclusion covers AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges.

AWS Shield Advanced isn’t required to use any of these features. Shield Advanced subscribers get the rule group included with AWS WAF and any customer can turn it on independently. See AWS WAF pricing for more information on costs.

Implementation details

Shield Advanced upgrades application-layer DDoS protection in five phases. The following dates are when AWS will act automatically, not the earliest date when you can act. After the rule group is deployed in Count mode on July 27, 2026, you can begin migrating right away rather than waiting for the October auto-upgrade. There’s no window where protection lapses. Your current automatic mitigation stays active through every phase until the Anti-DDoS managed rule group takes over. That handoff happens in a single operation, with no cutover window and no gap for your traffic flows.

Phase 1: Anti-DDoS managed rule group deployed in Count mode (rolling out July 27–August 7, 2026)

AWS adds the Anti-DDoS managed rule group in Count mode to every web ACL eligible for this rollout. Eligible means any Shield Advanced web ACL with at least one resource using application-layer automatic mitigation that isn’t already running the Anti-DDoS rule group. This is a broader set than the web ACLs eligible for the October auto-upgrade (Phase 3), which applies a stricter test. The deployment rolls out gradually, starting July 27 and expected to finish by August 7, 2026, so different web ACLs might be updated on different days. There’s no impact to your traffic because the rule group watches and labels requests without acting on them while your existing automatic mitigation keeps running. Throughout the evaluation period, you receive DDoS events, metrics, and AWS WAF labels at no additional charge.

Phase 2: Free evaluation period (July 27–September 30, 2026)

The existing automatic mitigation and the Anti-DDoS managed rule group run side by side each detecting independently. Automatic mitigation continues to protect your resources while the rule group operates in Count mode. To compare their detection results, use the DDoSAttackRequests metric, AWS WAF labels, and the Anti-DDoS dashboard. All Anti-DDoS managed rule group charges are waived during this period, including the subscription fee, per-request fees, and WCU consumption costs for the eligible web ACLs from phase 1.

Phase 3: Auto-upgrade begins (October 1, 2026)

For eligible web ACLs, the auto-upgrade mirrors your existing automatic mitigation configuration. The rule group inherits your current setting, so a Block configuration comes up in Block mode and a Count configuration comes up in Count mode in a single, atomic operation. The rule group takes over in the same step that disables automatic mitigation, so protection never drops for an instant. This is a handoff rather than a cutover with no window where your resources are unprotected. If you’d rather not upgrade you can opt out by contacting AWS Support before the auto-upgrade date.

Phase 4: Guided migration (available July 27–December 31, 2026)

You don’t have to wait for the October auto-upgrade to migrate. As soon as the rule group is deployed in Count mode between July 27 and August 7, 2026, you can move to it on your own schedule. This is the path to use for web ACLs that aren’t eligible for the Phase 3 auto-upgrade, meaning mixed-mode web ACLs or ones with resources that don’t have automatic mitigation enabled. Work with your AWS account team and AWS Support at any point in this window to plan and complete the migration. Eligible web ACLs are also upgraded automatically starting October 1 (Phase 3), so guided migration is mainly for the web ACLs the auto-upgrade can’t cover.

Phase 5: Shield Advanced application-layer automatic mitigation sunset (January 1, 2027)

As of January 1, 2027, the Shield Advanced application-layer automatic mitigation feature will no longer be available. Resources that haven’t migrated to the Anti-DDoS managed rule group will lose automatic application-layer DDoS mitigation.

Capability

Shield Advanced application layer automatic mitigation

Anti-DDoS managed rule group (AWSManagedRulesAntiDDoSRuleSet)

Feature type

Shield Advanced automatic mitigation

AWS WAF managed rule group

Detection and mitigation speed

Requires a baseline period; mitigation varies per event

Enhanced detection and faster mitigation

Configuration scope

Per resource (Shield API)

Per web ACL (AWS WAF API)

Mitigation actions

Count, Block

Count, Block, and Challenge

Sensitivity controls

None

Low, Medium, and High for both Block and Challenge

Non-HTML path handling

N/A

URI regex exemptions for Challenge

WCU consumption

150 WCUs

50 WCUs

Health checks

Required (Amazon Route 53 health-based detection)

Not required, provides automatic traffic profiling

Availability

Shield Advanced only

AWS WAF and Shield Advanced (see pricing)

Observability

The existing automatic mitigation and the Anti-DDoS managed rule group use separate Amazon CloudWatch namespaces and metric structures. The rule group gives you three tiers of observability: tier 1 tells you an attack is happening, tier 2 shows which requests it flagged and why, and tier 3 shows what it did about them. You don’t need all three on day 1 because most customer teams start at tier 1 to confirm detection is working, then add the others as they tune.

Tier 1: Event detection alarms

You can detect DDoS events using two CloudWatch metrics, each with its own namespace.

DDoSDetected (Shield)

DDoSAttackRequests (Anti-DDoS managed rule group)

Namespace

AWS/DDoSProtection

AWS/WAFV2

Requires Shield Advanced

Yes

No

Scope

L3, L4, and L7 events

L7 events only

Value during event

Binary (0 or 1)

Count of requests observed

Value outside event

Reported once daily (keeps metric alive)

Absent (no data points)

Dimensions

ResourceArn

Resource, ResourceType

What this means for your existing alarms:

  • After the application-layer automatic mitigation feature is sunset, DDoSDetected still fires for infrastructure layer 3 and layer 4 events, so your existing network layer and transport layer alarms remain valid. For the full list, see AWS Shield Advanced metrics.
  • DDoSAttackRequests is the Anti-DDoS managed rule group equivalent for application-layer event detection. Alarm on Sum >= 1 to detect any event, or set a volume threshold (for example, more than 10,000 requests per minute) for severity-based alerting.
  • During the evaluation period, both metrics fire independently and you can validate detection parity before migrating your application-layer alarms.
  • Because DDoSAttackRequests is absent when there are no active DDoS events, set treat-missing-data to missing or notBreaching for alarms on this metric.

Tier 2: Detection labels for custom monitoring

Every request the Anti-DDoS managed rule group evaluates gets a label. Where tier 1 tells you an attack started, tier 2 shows which requests looked suspicious and how confident the rule group was. The labels surface as AWS WAF metrics in the AWS/WAFV2 namespace: AllowedRequests, BlockedRequests, and CountRuleMatch. Each carries the LabelName and LabelNamespace dimensions under the awswaf:managed:aws:anti-ddos: namespace.

  • event-detected – Requests observed during a detected DDoS event
  • ddos-request – Requests identified as part of the attack
  • low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request – Graduated suspicion levels
  • challengeable-request – Requests eligible for browser challenge

Chart suspicion-level trends on a CloudWatch dashboard to see how an attack builds. Match on the labels in your own AWS WAF rules or dig into them in your AWS WAF logs with CloudWatch Logs Insights or Amazon Athena when you need to understand a specific event after the fact.

Tier 3: Mitigation action metrics

Where tier 2 shows what the rule group flagged, tier 3 shows what it did about those requests during an event. You’ll find these metrics as ChallengeRequests, BlockedRequests, and CountRuleMatch, each scoped by the rule label that produced it.

  • ChallengeAllDuringEvent – Requests challenged during an active event
  • ChallengeDDoSRequests – Suspected DDoS requests challenged based on suspicion level
  • DDoSRequests – Requests blocked (or counted in Count mode)

Watch these during a live event to see whether mitigation is keeping up. If you’re challenging far more requests than you’re blocking, your configuration might be too cautious, and you can raise the sensitivity level after you trust the numbers.

Observability summary

Tier

Automatic mitigation

Anti-DDoS managed rule group

Event alarm

DDoSDetected in AWS/DDoSProtection (binary, L3/L4/L7)

DDoSAttackRequests in AWS/WAFV2 (request count, L7)

Detection labels

None

event-detected, ddos-request, suspicion levels, challengeable-request

Mitigation actions

Not visible (Shield-managed rule group metrics not exposed)

ChallengeAllDuringEvent, ChallengeDDoSRequests, DDoSRequests

Dashboard

Shield console event history

Shield console and Anti-DDoS dashboard in the AWS WAF console

Historical analysis

Shield event history only

AWS WAF logs (CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), Amazon Data Firehose)

Billing

Your Shield Advanced subscription includes the Anti-DDoS managed rule group for up to 50 billion requests per month, counted across your whole organization at the payer account level. For most customers that ceiling is well above normal traffic, so you won’t see a line item here unless you’re operating at very high volume. For the exact rates, see AWS WAF pricing and Shield Advanced pricing.

You aren’t charged for DDoS traffic while the Anti-DDoS managed rule group is actively mitigating, which means Block or Challenge mode rather than Count. This applies to AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges. Leaving the rule group in Count mode past the evaluation period costs you the protection without the billing relief, so avoid staying in Count mode longer than you need to validate.

During the evaluation period (July 27 to September 30, 2026), the eligible web ACLs AWS auto-enrolled don’t incur per-request fees or WCU consumption, even when configured in Count mode.

The Anti-DDoS managed rule group works at the web ACL level, so every resource you associate with a web ACL shares that coverage. Before assuming a single resource accounts for the whole cost, look at how many resources sit behind each web ACL. A web ACL fronting 20 resources bills differently from one fronting 2, so check that count first and familiarize yourself with the workload protected by each web ACL.

Adding the Anti-DDoS managed rule group to a web ACL yourself isn’t part of the upgrade path, so standard pricing applies from the moment you enable it. The same is true for any resource that was already running the rule group before the rollout. To get the free evaluation, let the automatic rollout reach your web ACLs rather than adding the rule group ahead of it. There’s no penalty for adding it yourself; you just don’t receive the waiver on that web ACL.

Update your infrastructure as code

If you manage web ACLs with AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform, or other infrastructure as code (IaC), the auto-upgrade changes your infrastructure configuration outside your templates. Your code is still the source of truth, so you need to do two things. First, change where the protection is declared. Today you enable application-layer automatic mitigation through the Shield API (EnableApplicationLayerAutomaticResponse), configured per protected resource. The Anti-DDoS managed rule group is configured through the AWS WAF API instead (CreateWebACL and UpdateWebACL), as a managed rule group statement inside the web ACL, scoped per web ACL rather than per resource. In IaC terms, you remove the Shield automatic-response block (for example, Terraform’s aws_shield_application_layer_automatic_response) and add the WAF managed rule group statement shown in the following section. Second, pull the upgraded web ACL back into your tooling before your next deploy, or your pipeline will try to revert the change.

For the full statement in Terraform, CloudFormation, and the AWS CDK, plus how to sync state after the auto-upgrade (terraform plan, CloudFormation drift detection, cdk diff), see the iac-webacl-examples helper.

Update your AWS Firewall Manager policy

If you run a Shield Advanced policy in AWS Firewall Manager today, that policy is what enabled application-layer automatic mitigation across your accounts. To keep that protection, add the Anti-DDoS managed rule group to an AWS WAF Firewall Manager policy. Your Shield Advanced policy still handles L3 and L4, while the application-layer piece moves to the AWS WAF policy. The migration is straightforward: add or reuse an AWS WAF Firewall Manager policy, put the Anti-DDoS managed rule group in it, and scope it to the same accounts and resources your Shield Advanced policy covers.

You can’t add the rule group from the Shield console or by editing an account-level web ACL directly, because Firewall Manager owns the web ACLs it creates and overwrites local edits. Instead, add the rule group to the AWS WAF policy and Firewall Manager pushes it to every in-scope account.

You can make this change in the console or as code. If you manage your Firewall Manager policies as code, don’t edit them in the console: add a new AWS WAF policy or update an existing one in your templates with the Anti-DDoS managed rule group included, and deploy it using the following Firewall Manager policies using IaC steps. Otherwise, use the console.

In the console, follow Creating an AWS Firewall Manager policy for AWS WAF to create the policy and reach the Edit policy rules page. Add the Anti-DDoS rule group, listed there as AWS AntiDDoS Protection for Layer 7 attacks (AWSManagedRulesAntiDDoSRuleSet), as a new rule group under First rule groups so it evaluates before your other managed groups, but below any Allow custom rules you use to fast-path known-good traffic.

If you protect CloudFront distributions, make this change in your Global policy, and repeat it in each AWS Regional policy for regional resources. Save the policy, and Firewall Manager rolls the change out to in-scope accounts, which can take a few minutes.

After being added, the rule group appears as the first rule group in the policy, as shown in the following screenshot:

Figure 1: AntiDDoS enabled

Figure 1: AntiDDoS enabled

Firewall Manager policies using IaC

If you manage Firewall Manager policies as code, make the change in your template instead of the console. The Anti-DDoS managed rule group goes into the AWS WAF policy’s ManagedServiceData, a WAFV2 policy definition carried as a JSON string, added to the first rule groups so it evaluates early. For the ManagedServiceData JSON with CloudFormation, Terraform, and AWS CDK examples, see the firewall-manager-examples helper.

Whichever path you take, scope the policy to the same accounts and resources your Shield Advanced policy already covers, so no resource loses application-layer protection during the move.

Getting started

Between July 27 and August 7, 2026, AWS will add the Anti-DDoS managed rule group in Count mode to Shield Advanced web ACLs that have resources using application layer automatic mitigation but not yet the Anti-DDoS rule group. After it reaches your web ACL, you can evaluate it, and migrate whenever you’re ready, without waiting for the October auto-upgrade.

  • Review the Anti-DDoS dashboard in the AWS WAF console. The dashboard shows real-time DDoS events, match metrics, and top traffic sources.
  • Compare event detection side by side. During Count mode, both systems detect independently. Check the DDoSDetected metric in AWS/DDoSProtection alongside DDoSAttackRequests in AWS/WAFV2 to validate detection parity for your resources. You can deploy the CloudWatch comparison dashboard from the AWS Samples repository to view both systems on a single dashboard.
  • Explore AWS WAF labels. Enable AWS WAF logging and query for labels in the awswaf:managed:aws:anti-ddos: namespace. Look at suspicion levels (low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request), event-detected, and challengeable-request to see per-request visibility into detected events.
  • Start with Low sensitivity for Block actions during evaluation to minimize false positive risk. Tune up as you gain confidence from the Anti-DDoS dashboard and AWS WAF label data.
  • Plan your configuration. Review sensitivity levels, URI exemptions for non-HTML paths, and web ACL priority placement. The Anti-DDoS managed rule group should run at the highest priority in your web ACL, or right below any custom rules with the Allow action.
  • Sync your IaC templates. After the auto-upgrade adds the Anti-DDoS managed rule group to your web ACL, fetch the current state into your IaC tooling (Terraform refresh, CloudFormation drift detection, AWS CDK import) before your next deployment.

Conclusion

The Anti-DDoS managed rule group profiles your traffic within minutes and mitigates within seconds, where the automatic mitigation it builds on established its baseline over hours, and it gives you granular visibility into what it’s doing. The evaluation period exists so you can watch both systems run on your own traffic before anything changes. Spend the first few weeks in Count mode confirming the new detection matches what you see today, then move your alarms over and pick a sensitivity level you’re comfortable with. If you run a web ACL across several resources, or you manage rules through AWS Firewall Manager, contact AWS Support before you start so you don’t have to unwind anything later. The Shield Advanced application-layer automatic mitigation feature retires on January 1, 2027, and anything still relying on it needs to be migrated by then.

Resources

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

    Eitav Arditti

    Eitav is a Senior Solutions Architect at AWS and a technology leader with over 15 years of experience in the tech industry. He specializes in edge computing, serverless, and platform engineering, and works with engineering teams to design secure, globally scalable architectures on CloudFront and AWS WAF. His current focus is on internet-scale systems—from global content delivery to edge security.

    Andrew Chen

    Andrew is a Senior Product Manager focused on DDoS protection at AWS. He leads the AWS Shield product line, helping safeguard both AWS infrastructure and customers from volumetric and network-layer threats. Andrew works closely with security and networking teams to strengthen internet safety.

    Justin Kurpius

    Justin is a Security Go-to-Market Specialist at AWS, based in Chicago, IL. He focuses on AWS edge and security services, including Amazon CloudFront, AWS WAF, AWS Shield, and AWS Firewall Manager, helping customers architect scalable, resilient web application defenses. Justin works across monetization strategy, ISV partnerships, and field enablement to accelerate adoption of the AWS edge security portfolio.

    [$] Hazard pointers for the kernel

    Post Syndicated from corbet original https://lwn.net/Articles/1084015/

    The kernel’s read-copy-update (RCU) subsystem ensures that data will not be
    deleted until it is known that there are no threads holding references to
    it. RCU works well and is widely used throughout the kernel, but it can
    increase memory use and add significant delays before unused kernel objects
    are cleaned up. Hazard pointers are
    an alternative approach to lockless data updates that offers better
    performance, for some situations at least. The kernel community is
    currently considering a
    hazard-pointer implementation     by Mathieu Desnoyers and Paul McKenney.

    Announcing the Cloud Security Alliance on AWS Compliance Guide

    Post Syndicated from Juan Rodriguez original https://aws.amazon.com/blogs/security/announcing-the-cloud-security-alliance-on-aws-compliance-guide/

    AWS Security Assurance Services is announcing the release of the Cloud Security Alliance (CSA) Compliance Guide on Amazon Web Service (AWS), a new resource that maps the 17 control domains and 207 control objectives of the Cloud Controls Matrix v4.1 (CCM) to AWS services and recommended implementation practices. The guide is intended to help organizations using AWS plan, implement, and evidence the controls relevant to their CCM scope, including those pursuing or maintaining CSA STAR certification.

    What is the Cloud Controls Matrix?

    The Cloud Security Alliance is a not-for-profit organization dedicated to defining and raising awareness of best practices for cloud security. AWS maintains CSA STAR Level 2 certification, which couples the requirements of ISO/IEC 27001:2022 with the CCM. The CSA STAR documentation and the AWS Consensus Assessments Initiative Questionnaire (CAIQ) are available to AWS customers through AWS Artifact.

    The CSA Cloud Controls Matrix is a cybersecurity controls framework developed by the CSA that provides a detailed set of security controls mapped across multiple domains (such as audit and assurance, identity and access management, and encryption and key management) specifically designed to assess and manage security risks in cloud computing environments. The CCM is cloud agnostic, designed to be applicable to any cloud service provider or deployment model, such as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), regardless of the underlying technology or vendor, providing universal security controls that organizations can apply across cloud platforms.

    Responsibility models

    CCM defines its own Shared Security Responsibility Model (SSRM) with three categories: Cloud service provider (CSP)-owned, customer-owned, and shared (independent or dependent). The guide recommends using the SSRM together with the AWS Shared Responsibility Model. For controls that AWS owns, the guide points to AWS attestations available through AWS Artifact (for example, SOC reports, ISO certificates, and the CSA STAR attestation) as inherited evidence. For controls that customers own or share, the guide describes how to implement and evidence them using AWS services. Using a CSA STAR–certified AWS service doesn’t by itself make a customer workload compliant. Customers remain responsible for configuring services, managing access, protecting data, and implementing additional controls based on their environment, risk assessments, and regulatory obligations. The guide is informational and doesn’t replace the AWS compliance documentation and certifications available through AWS Artifact.

    What’s inside the guide

    For each control, the guide states applicability, describes how organizations can implement the control on AWS, identifies common pitfalls, and lists examples that can be used as evidence during an assessment.

    Related resources

    Download available: Here

    For further assistance, contact AWS Security Assurance Services. If you have feedback about this post, submit comments in the Comments section below.

    Juan Rodriguez

    Juan is a Security Assurance Consultant at AWS, where he works with Strategic Services and customers to assess and secure cloud environments against frameworks including CMMC, FedRAMP, GovRAMP, and NIST based practices. He holds his CMMC Certified Professional and AWS Certified Security – Specialty certifications. Juan pairs technical expertise with a research-driven mindset to help organizations strengthen and architect their security posture and align with federal and industry standards.

    Max Schiessl

    Max Schiessl

    Max is an Assurance Consultant with AWS Security Assurance Services (SAS), focusing on multiple international cybersecurity and compliance frameworks. He combines a decade of experience as an IT auditor and certified penetration tester and has contributed to the development and implementation of cybersecurity regulations at the European national level. He works closely with customers, partners, and AWS teams to help organizations achieve and maintain their compliance goals in the cloud.

    Meg Winn

    Meg Winn

    Meg is a Sr. Security Assurance Consultant at Amazon Web Services with over a decade of experience in cybersecurity governance, risk and compliance, cloud security strategy, and compliance engineering. She holds multiple industry and AWS certifications and advises enterprise clients on achieving and sustaining audit readiness across multiple standards. Meg partners with executive stakeholders in highly regulated industries to prepare and guide clients through successful audit outcomes at scale.

    Satish Uppalapati

    Satish is an Associate Assurance Consultant with AWS Security Assurance Services (SAS) and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to align cloud environments with multiple frameworks. Satish helps organizations build security and governance programs that meet regulatory objectives while supporting business operations. He also focuses on advancing governance for AI systems, including emerging standards.

    Ted Tanner

    Ted Tanner

    Ted is a Principal Assurance Consultant and PCI DSS Qualified Security Assessor with AWS Security Assurance Services, and has more than 25 years of IT and security experience. He leverages this to provide AWS customers with guidance on compliance and security, and build and optimize their cloud compliance programs.

    Building a scalable personalized recommendation system on AWS: From batch to real-time

    Post Syndicated from Shraddha Anil Naik original https://aws.amazon.com/blogs/big-data/building-a-scalable-personalized-recommendation-system-on-aws-from-batch-to-real-time/

    Amazon.com receives millions of visits every day, and behind every product recommendation on our website is a system that needs to process customer signals, run machine learning (ML) models, and deliver results before the next visit. Doing this across global marketplaces for millions of customers at tens of thousands of requests per second, while keeping experimentation fast and infrastructure costs bounded, is an orchestration challenge as much as a machine learning one.

    Our team built a system that addresses this challenge. This post shows how we did it using a batch-first architecture with AWS Lake Formation, Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon Athena, AWS Glue, Amazon SageMaker, and Amazon DynamoDB, and how we later extended it with Amazon MemoryDB for real-time vector similarity search when we needed to incorporate more real-time signals.

    Architecture overview

    Data flow from the Lake Formation data lake and Athena through Airflow-orchestrated pipelines using Glue and SageMaker into DynamoDB for batch serving and MemoryDB for real-time inference

    Data flows from the centralized data lake (Lake Formation and Athena) through Airflow-orchestrated pipelines using Glue for processing and SageMaker for ML workloads, into DynamoDB for batch serving and MemoryDB for real-time inference

    The data lake foundation: Centralized access with Lake Formation

    Every recommendation pipeline starts with data. We built a centralized data lake to create a single source of truth that any pipeline or consumer can access without duplicating data or building bespoke extract, transform, and load (ETL) pipelines.

    Golden datasets: Shared once, used everywhere

    Before the data lake, each recommendation pipeline independently extracted and transformed its own copy of product catalog, transaction history, and embeddings. This led to subtle inconsistencies: one pipeline might use a slightly different join logic or a stale snapshot, making it difficult to compare model performance or debug discrepancies across pipelines.

    Now, we publish curated, validated datasets once, and every consumer (Airflow DAGs, ML notebooks, analytics dashboards) reads from the same tables through the same governed access. This means:

    • New pipelines start faster. A new recommendation model does not need its own data extraction logic. It queries the existing golden datasets from day one.
    • Consistency across models. When we compare model A to model B, we know both models are trained and inferred on the same underlying data.
    • Cross-team collaboration. Multiple teams share the same tables as a single source of truth.
    • Two-way data flow. The data lake serves as both source and destination. Our pipelines read golden datasets as inputs and write computed outputs (model scores, feature sets, intermediate results) back to the lake, where they become inputs for other pipelines. This creates a compounding effect: each new pipeline enriches the lake for the next one.

    Why Lake Formation?

    Our data is stored in Amazon Simple Storage Service (Amazon S3), partitioned by marketplace. Our data consumers (Airflow pipelines, ML notebooks, analytics tools) live in separate AWS accounts from the data producers. We chose AWS Lake Formation because it adds governance on top of S3 without requiring data migration:

    • Fine-grained cross-account access. Grant table-level permissions per consumer role, without managing bucket policies manually.
    • Schema governance through AWS Glue Data Catalog. Scheduled Glue crawlers infer schemas from files in S3, keeping the catalog current as data evolves.
    • Multi-Region consistency. We deploy identical infrastructure across multiple AWS Regions using AWS Cloud Development Kit (AWS CDK), each Region serving its local marketplaces.

    Orchestration: Amazon Managed Workflows for Apache Airflow (Amazon MWAA)

    We chose Amazon Managed Workflows for Apache Airflow (Amazon MWAA) as our orchestration layer. MWAA removes the operational burden of managing Airflow infrastructure: automatic scaling of workers, built-in high availability, and managed upgrades mean our team focuses on pipeline logic rather than cluster maintenance. MWAA lets us define complex multi-step workflows with rich dependencies in Python code, and its operator model lets us encapsulate team-specific conventions into reusable building blocks.

    Each recommendation pipeline follows a consistent pattern:

    The consistent recommendation pipeline pattern moving from data extraction through model training, batch inference, vector search, ranking, and publishing

    We built a library of reusable custom Airflow operators, each encapsulating one of our core compute engines. This reduced new pipeline development from weeks to days in our team’s experience.

    Athena and AWS Glue: Data access and processing

    Amazon Athena is how our pipelines read from Lake Formation. Our custom operator runs SQL queries against the Glue Data Catalog and automatically runs UNLOAD to write results to S3: serverless, no infrastructure to manage, and integrated with the Lake Formation permission model.

    AWS Glue handles compute-intensive data transformations through PySpark: joining datasets, filtering, deduplication, aggregation, and formatting ML outputs into final recommendation lists. We configure Glue with Auto Scaling worker pools (for example, 2–50 workers of G.8X type) so jobs scale with data volume per marketplace. All jobs run ephemerally: they read from S3, write to S3, and require no long-running clusters.

    Amazon SageMaker powers the ML-intensive stages of our pipelines across three workload types, all orchestrated as steps within our Airflow DAGs:

    Training

    We use SageMaker Training Jobs to train our recommendation models on GPU instances (for example, ml.g5). Training data is prepared by upstream Glue jobs and staged in S3. Our custom Airflow operator submits the training job, monitors its progress, and registers the resulting model artifact in S3. Once training completes, the artifact is immediately available for batch inference or endpoint deployment within the same DAG run. This means a single DAG can go from raw data to trained model to deployed inference without manual handoffs, and we can retrain it on fresh data every pipeline cycle with zero operator intervention.

    Batch inference

    SageMaker Batch Transform runs our trained models at scale, generating the outputs that feed into downstream ranking and publishing steps. Our batch inference operator handles job submission, polls for completion, and writes the output location to the DAG’s S3 convention so the next Glue step can pick it up automatically. Batch Transform lets us run inference without provisioning persistent infrastructure, and we can scale instance count and type independently for every pipeline based on data volume.

    Generating recommendations for millions of customers requires searching across hundreds of thousands of candidate products per customer. Exact search at this scale is prohibitively expensive, so we use approximate nearest neighbor (ANN) search using FAISS to find similar products efficiently, run as SageMaker Processing Jobs.

    The workflow:

    1. Build a FAISS index over the candidate catalog.
    2. Query the index with per-customer vectors to find top-K nearest neighbors.
    3. Return ranked candidate lists per customer.

    We distribute query vectors across the SageMaker Processing fleet using S3-based sharding (ShardedByS3Key). Each instance receives the full candidate index but only a fraction of the query vectors. Every instance builds an identical FAISS index, searches its shard of queries, and writes results to S3. The downstream Glue step merges all shards into the final recommendation lists. This lets us scale horizontally by adding instances without changing any code.

    Why SageMaker inside MWAA?

    Running SageMaker jobs as MWAA tasks (rather than standalone) gives us:

    • End-to-end lineage. Every model training run, inference job, and vector search is tracked as part of a DAG execution. We can trace a recommendation in DynamoDB back to the exact training run, data snapshot, and ANN search that produced it.
    • Retry and failure handling. If a SageMaker job fails (spot instance preemption, transient capacity errors), Airflow retries it automatically with backoff. No manual re-runs.
    • Resource sequencing. Training must finish before inference, inference before ANN search. The Airflow dependency model handles this naturally without polling scripts or step function state machines.
    • Unified monitoring. One Airflow dashboard shows the health of all pipelines: Glue ETL, SageMaker training, SageMaker inference, and DynamoDB publishing. No context-switching between consoles.

    Putting it together: A complete pipeline example

    Our recommendation generation pipeline illustrates the full flow:

    The complete recommendation generation pipeline: data lake extraction, model training, batch inference, vector search, merge and rank with Glue, and publishing to DynamoDB

    Note that the operators shown (GlueSQLOperator, VectorSearchOperator, and others) are custom internal operators built on top of the Airflow AWS provider, not open-source libraries. Here is a simplified version of what this looks like in code:

    from airflow import DAG
from airflow.models.baseoperator import chain
from airflow.utils.task_group import TaskGroup

dag = DAG("recommendation_generator", schedule="0 18 * * 4")  # Weekly
task_groups = []

for marketplace in [...]:  # global marketplaces
    with TaskGroup(group_id=marketplace, dag=dag) as group:

        # Step 1: Extract data from lake
        candidates = GlueSQLOperator(
            task_id="select_candidates",
            tables=[f"{marketplace}.catalog", f"{marketplace}.products"],
            sql="select_candidates.sql", dag=dag)

        customer_history = GlueSQLOperator(
            task_id="select_customer_history",
            tables=[f"{marketplace}.transactions"],
            sql="select_customer_vectors.sql", dag=dag)

        customers = AthenaSQLOperator(
            task_id="select_customers", database=marketplace,
            query="select_customer_cohort.sql", dag=dag)

        # Step 2: Train model
        train = ModelTrainingOperator(
            task_id="train_model",
            training_input={"task_id": customer_history.task_id},
            instance_type="ml.g5", dag=dag)

        # Step 3: Batch inference
        inference = BatchInferenceOperator(
            task_id="batch_inference",
            model={"task_id": train.task_id},
            input_data={"task_id": candidates.task_id}, dag=dag)

        # Step 4: Vector search via SageMaker Processing Job
        ann_search = VectorSearchOperator(
            task_id="ann_search",
            index_input={"task_id": inference.task_id},
            query_input={"task_id": customer_history.task_id},
            k=60, instance_count=10, dag=dag)

        # Step 5: Merge and rank with Glue
        merge_and_rank = GlueSparkOperator(
            task_id="merge_and_rank",
            script="merge_results.py", dag=dag)

        # Step 6: Publish to DynamoDB
        publish = DynamoDBPublishOperator(
            task_id="publish_recommendations",
            table_name="Recommendations", dag=dag)

        # Task dependencies
        [candidates, customer_history] >> train >> inference
        [inference, customers] >> ann_search >> merge_and_rank >> publish

    task_groups.append(group)

chain(*task_groups)  # Execute marketplaces sequentially

    Key patterns in this DAG

    • Marketplace isolation. Each marketplace runs in its own TaskGroup. A failure in one does not block the others.
    • Parallel data extraction. Independent Athena/Glue queries run concurrently before converging at the training step.
    • Sequential marketplace execution. chain() runs marketplaces one at a time to avoid resource contention across large SageMaker and Glue jobs.
    • Reusable operators. We built custom operators like GlueSQLOperator, VectorSearchOperator, and DynamoDBPublishOperator that encode our team’s conventions (cross-account access, S3 staging, retry logic, metrics) into shared building blocks. New pipelines are mostly configuration rather than infrastructure code, and these operators are shared across dozens of pipelines.
    • Implicit data passing. Each operator writes its output to a convention-based S3 path and downstream operators automatically resolve the upstream output location. No hard-coded paths between steps.

    This pattern powers hundreds of pipelines across global marketplaces, with each marketplace as an isolated TaskGroup in the DAG.

    Serving layer: DynamoDB + ECS

    Our Java-based Amazon Elastic Container Service (Amazon ECS) service reads pre-computed recommendations from Amazon DynamoDB at request time:

    1. Receive request with customer ID, marketplace, customer context, and page context.
    2. Read pre-computed recommendations from DynamoDB.
    3. Apply real-time filters (availability, eligibility constraints).
    4. Re-rank based on real-time context signals.
    5. Return the response.

    Amazon DynamoDB is designed to provide single-digit millisecond reads at our scale and time-to-live (TTL) for automatic cleanup of stale recommendations.

    Extending to real-time

    In recommendation system terms, our batch pipeline handles the retrieval stage offline. Although this covers the majority of our traffic, we identified scenarios where weekly freshness was not enough to capture what customers are doing right now. The real-time extension adds an online retrieval and ranking path for signals that cannot wait for the next batch cycle.

    To address these, we extended our system with Amazon MemoryDB (which now supports Valkey as its open-source engine) for real-time vector similarity search and SageMaker real-time endpoints for on-demand embedding generation. The same Airflow pipelines that publish to DynamoDB also publish product vectors to MemoryDB (through our MemoryDB publish operator), and the same model in our batch pipeline is deployed to a SageMaker endpoint for single-item inference at request time.

    At serving time, when we want to incorporate fresh signals, the service calls the SageMaker endpoint to generate an embedding on the fly, then queries MemoryDB for the nearest neighbors. These fresh signals include recent search queries, cart additions, and other in-session activity that changes faster than our weekly batch cycle. In our workloads, this gives us sub-millisecond vector search latency without re-running the full batch pipeline. Critically, the batch pipeline keeps the MemoryDB product index fresh. Our Airflow DAG includes a MemoryDB publish operator that refreshes the full product vector index weekly, so real-time queries always search against an up-to-date index.

    Batch and real-time are not competing approaches: batch handles slow-moving signals (purchase history, catalog relationships) while real-time handles fast-moving ones (current session, new arrivals, trending items). Both paths share the same models, the same data lake, and the same serving service.

    For a detailed deep-dive on this real-time architecture, see Real-time personalized recommendations with Amazon SageMaker and Amazon Managed Valkey.

    Security and access control

    Security is a foundational concern for a system that spans multiple AWS accounts, processes customer behavioral data, and runs across multiple AWS Regions.

    Cross-account access: Lake Formation grants are issued to consumer-account AWS Identity and Access Management (IAM) roles, ensuring consumers can query tables without direct S3 bucket access. Each consumer role receives only the permissions it needs for its specific tables.

    IAM execution roles: Each compute engine (MWAA, Glue, SageMaker) runs under a dedicated least-privilege IAM role.

    Network isolation: MWAA environments and the ECS serving layer are deployed within virtual private clouds (VPCs), with separate VPC configurations per Region.

    Reliability and failure handling

    Regional isolation: Each AWS Region runs an independent copy of the system. DynamoDB tables are regional, each populated by the local batch pipeline. MemoryDB clusters are regional, with the product vector index refreshed by the local Airflow DAG. This means a regional failure or pipeline delay in one Region does not affect other Regions.

    Batch pipeline failures: If a pipeline fails mid-run, the previous DynamoDB data remains live and continues serving recommendations until the next successful run. Airflow retries failed tasks automatically with configurable backoff. TTL on DynamoDB records bounds how long stale data persists. Failed pipeline runs trigger automated alerting so the on-call engineer can investigate.

    Real-time path resilience: MemoryDB is deployed in a multi-AZ configuration with automatic failover. The real-time path is an extension of the batch system, and batch recommendations from DynamoDB remain available regardless of real-time path availability.

    Lessons learned

    1. Start batch, add real-time incrementally. Batch pipelines are easier to debug, cheaper to operate, and sufficient for most recommendation scenarios. Add real-time path only when you have clear indication that specific customer signals (for example, in-session activity, search queries) need sub-hour freshness to remain relevant.
    2. Match the serving path to signal velocity. Not every signal needs real-time processing. Categorize your signals by how quickly they change, and route accordingly: batch for slow signals, real-time for fast ones, re-ranking for in-between.
    3. Freshness does not always require re-computation. A batch-generated candidate set remains largely valid between runs. What changes is relative relevance. Re-ranking at serving time with recent customer activity gives the impression of real-time without the cost of real-time candidate generation.
    4. A centralized data lake accelerates everything. Golden datasets eliminated weeks of per-pipeline data extraction work, made model comparisons trustworthy, and let new team members ship their first pipeline in days instead of weeks. The upfront investment in Lake Formation governance paid for itself within the first quarter.
    5. Invest in reusable operators. Custom Airflow operators encapsulating Athena/Glue/SageMaker patterns let teams ship new pipelines in days. The operators encode best practices (retry logic, cross-account access, metrics) so pipeline authors can focus on business logic.
    6. Separate compute from storage. S3 as the universal intermediate layer + ephemeral Glue/SageMaker jobs means you pay only for active computation. No idle clusters between weekly pipeline runs.

    Conclusion

    We built this system because every customer interaction is an opportunity to surface the right product at the right time. Serving tens of thousands of requests per second across millions of customers in global marketplaces, our batch-first architecture uses AWS Lake Formation for governed data access, Amazon MWAA for orchestration, Amazon Athena for data lake queries, AWS Glue for distributed processing, Amazon SageMaker for training, inference, and vector search, and Amazon DynamoDB for low-latency serving. When we needed to incorporate more real-time signals, we added Amazon MemoryDB vector search paired with SageMaker real-time endpoints for on-demand embedding generation, extending into real-time without replacing the batch foundation.

    The architecture choices we have made, batch for efficiency and real-time for freshness, all serve the goal of helping customers discover what they need faster. If you are building personalized experiences at scale, we hope these patterns give you a useful starting point.

    This would not have been possible without the Everyday Essentials engineering team, whose collective effort turned these ideas into a production system serving customers every day. We are also grateful for the support and guidance from Sam Heyworth, Nirav Desai, and Ankur Datta, and the broader Everyday Essentials leadership team.

    About the authors

    Shraddha Anil Naik

    Shraddha Anil Naik

    Shraddha is a Senior Software Engineer on the Everyday Essentials team at Amazon. She specializes in retrieval and recommendation infrastructure that powers personalized experiences for millions of customers.

    Sergii Oborskyi

    Sergii Oborskyi

    Sergii is a Senior Software Engineer on the Everyday Essentials team at Amazon. He builds online recommendation services that serve product recommendations to millions of customers at high throughput and low latency.

    Shawn Liu

    Shawn is a Senior Machine Learning Engineer on the Everyday Essentials team at Amazon. He develops and evaluates recommendation models on Amazon SageMaker that power personalized product discovery for millions of customers.

    Walter Wong

    Walter Wong

    Walter is a Software Development Manager in the Everyday Essentials Science org at Amazon. His work focuses on customer understanding and personalization, improving product recommendations for millions of customers across Amazon’s everyday essentials catalog.

    ASRock Rack 4U16X-GNR2 NVIDIA HGX B300 8-GPU Server Review

    Post Syndicated from Patrick Kennedy original https://www.servethehome.com/asrock-rack-4u16x-gnr2-nvidia-hgx-b300-8-gpu-server-intel-zutacore-review/

    We review the ASRock Rack 4U16X-GNR2, an 8x NVIDIA HGX B300 server with enormous network bandwidth and two liquid-cooling options

    The post ASRock Rack 4U16X-GNR2 NVIDIA HGX B300 8-GPU Server Review appeared first on ServeTheHome.

    AWS Weekly Roundup: Local Zone in Athens, Claude Opus 5 on AWS, Lambda durable execution for .NET, and more (July 27, 2026)

    Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-july-27-2026/

    Last week I had the privilege of spending three days in São Paulo with technical builders from across Latin America, brought together for a regional tech event full of deep-dive sessions, hands-on workshops, and conversations with customers and partners. What struck me most wasn’t any single session, it was the energy of a technical community that so rarely gets to be in the same room. People traded architecture ideas over coffee, sketched out solutions on whiteboards, and left with a longer list of things to try than they arrived with. It’s a good reminder that, for all the tooling we build, the community around it is what makes the technology stick.

    That community spirit connects nicely to the week’s biggest infrastructure news, which is all about bringing AWS closer to where builders actually are.

    Now, let’s get into this week’s AWS news…

    Headlines
    AWS Local Zone in Athens, Greece: AWS has opened a new Local Zone in Athens, Greece, the second Local Zone in EMEA with support for Amazon S3 and Amazon EBS Local Snapshots, so you can store and process data within Greece to help meet local data residency requirements. The Athens Local Zone supports Amazon EC2 (C7i, M7i, and R7i instances), Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS, and Amazon ECS.

    Athens, Greece skyline

    AWS Local Zones place AWS infrastructure much closer to large population and industry hubs, enabling applications that require single-digit millisecond latency, such as real-time gaming, media production, and financial services, to run where end users actually are. For builders in Greece, you can now run latency-sensitive workloads locally while connecting seamlessly to the nearest AWS Region for services that don’t require low latency, giving you the flexibility to architect hybrid, latency-optimized applications without managing your own data center infrastructure. To learn more, visit AWS Global Infrastructure and Sustainability Blog post.

    Last week’s launches
    Here are some launches and updates from this past week that caught my attention:

    • Claude Opus 5 on AWS: You can use Anthropic’s Claude Opus 5, the most advanced Opus model yet, matching Claude Fable 5’s top-tier intelligence in many domains at Opus-tier pricing. Amazon Bedrock offers Claude Opus 5 with zero data retention (ZDR) enabled by default, giving you Opus’ top-tier intelligence while meeting your data governance requirements unlike Claude Fable 5. You have two ways to access Claude Opus 5: Amazon Bedrock and Claude Platform on AWS. To learn more, visit the deep dive blog post.
    • AWS Lambda durable execution SDK for .NET is now generally available: You can now build resilient, long-running workflows in C# using Lambda durable functions, without implementing custom progress tracking or integrating an external orchestration service. The SDK is a natural fit for multi-step applications like payment processing pipelines, AI agent orchestration, and human-in-the-loop approvals, it checkpoints progress automatically and can pause execution for up to a year. If you’re a .NET developer building serverless workflows, this removes a lot of the plumbing you used to write by hand.
    • Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group: Amazon Bedrock AgentCore now delivers agent traces and prompts to the same Amazon CloudWatch log group as your agent’s logs. Previously, telemetry was split across destinations, trace spans went to a shared log group while prompts, inputs, and outputs went to a separate one, so debugging a single agent invocation meant searching in multiple places. You can now debug an invocation in one place, and apply fine-grained access control and customer-managed key (CMK) encryption at the individual agent level.
    • Amazon Connect delivers more natural agentic voice experiences: Amazon Connect now supports more natural, human-sounding agentic voice experiences across 50+ languages, including Portuguese, Spanish, French, Italian, Japanese, Korean, and Thai, with over 100 new voice options and conversational improvements that make AI interactions sound more fluid. Connect’s agentic self-service lets AI agents understand, reason, and take action across voice and digital channels, adapting to a customer’s tone and sentiment. You can now build contact center experiences that feel natural to callers in far more of the languages your customers actually speak.
    • Amazon SageMaker Unified Studio now supports Amazon OpenSearch: You can now query and analyze your search and log analytics data from Amazon OpenSearch directly alongside other data assets in Amazon SageMaker Unified Studio. With this connection, you can combine operational search data in OpenSearch with data from sources like Amazon Redshift, Amazon S3, and relational databases, all within a single, governed environment. It’s especially useful when you need to correlate analytical and operational workloads, such as joining application logs with transactional data to uncover insights.
    • Amazon CloudWatch announces coding agent insights: Amazon CloudWatch now gives engineering leaders visibility into how AI coding tools are driving value across their organization. Coding agent insights integrates with the Claude apps gateway for AWS to collect telemetry from Claude Code without additional instrumentation, and also supports agents like Codex and GitHub Copilot. As teams scale AI coding adoption, you can now measure the return on that investment with metrics built on OpenTelemetry, no custom instrumentation required.

    For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

    Other AWS news
    Here are some additional posts and resources that you might find interesting:

    Upcoming AWS events
    Check your calendar and sign up for upcoming AWS events:

    • AWS Summits: AWS Summits are free events that bring the cloud and AI community together to connect, learn, and explore the latest technologies. Browse the full calendar to find a Summit near you in the second half of 2026.
    • AWS Community Days: Community-led conferences where content is planned, sourced, and delivered by community leaders. If you’re in Latin America, don’t miss AWS Community Day Belo Horizonte on August 22, registration is open at awscommunityday.com.br.

    Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

    That’s all for this week. Check back next Monday for another Weekly Roundup!

    This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

    Security updates for Monday

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

    Security updates have been issued by Debian (chromium, hplip, and linux-6.1), Fedora (firefox, GitPython, google-osconfig-agent, lego, libgit2, libreswan, libwebsockets, moby-engine, p11-kit, pam, python-idna, rust-libgit2-sys, skopeo, systemd, trafficserver, webkitgtk, and xrdp), Mageia (giflib, graphite2, libnfs, vorbis-tools, wget, and yelp), Red Hat (firefox, thunderbird, and webkit2gtk3), and SUSE (amazon-ecs-init, chromedriver, ffmpeg-7, ffmpeg-8, firefox, google-osconfig-agent, gpg2, java-17-openjdk, java-25-openjdk, kernel, libsrt1_5, nginx, perl-HTTP-Date, perl-XML-Bare, proftpd, python-pyasn1, python-soupsieve, python313-astropy, python313-urwid, systemd, thunderbird, and trivy).

    We’re open sourcing our privacy proxy CLI

    Post Syndicated from Hannah Wang original https://blog.cloudflare.com/open-sourcing-our-privacy-proxy-cli/

    Debugging privacy-preserving protocols is hard. Oblivious HTTP has several different steps across four different parties, not to mention binary HTTP encoding and details spread across many draft RFCs. We've taken what we've learned operating protocols like Oblivious HTTP at the scale of millions of requests per second, and wrapped it up in a nice, clean CLI tool — that we are open sourcing today.

    We call it our privacy-client, or pvcli. We’re releasing it under the Apache-2.0 License, and it is open for contributions.

    Here’s a single line of code that executes a full Oblivious HTTP request with a relay, gateway and origin. Don't worry if you don't know what that means, we'll cover it below.

    We’ll explain why we built this tool, and show just how handy it can be.

    Why privacy protocols can be hard to debug

    Let’s take a closer look at our motivation for creating pvcli. Over time, the Privacy team’s product suite and customer base grew. We added products like Privacy Proxy and Privacy Gateway, which power Apple’s Private Relay, Microsoft’s Edge Secure Network VPN, Flo Health’s Anonymous Mode, and more. With it came an increasing amount of special customer requirements, domain knowledge, and complexity. As a result, we saw increased friction in development and incident response.

    To see this in action, let’s look at how one of our products implements Oblivious HTTP, also known as OHTTP. First, a quick primer. OHTTP provides users with a privacy guarantee: no one can know both who made a request and what they’re requesting. To achieve this, OHTTP requires two servers, a relay and a gateway, operated by two non-colluding parties. 

    Below is a sequence diagram of OHTTP, where our customer owns the relay and Cloudflare owns the gateway. At a high level, OHTTP can be broken down into these steps:

    1. Client gets public key from the gateway.
    2. Client encrypts the request and sends it to the relay.
    3. Relay removes “who” the client is from the encrypted request, and sends it to the gateway.
    4. Gateway decrypts the request, and sends it to the target.
    5. Target processes the request, and sends a response to the gateway.
    6. Gateway encrypts the response, and sends it to the relay.
    7. Relay sends the encrypted response to the client.
    8. Client decrypts, and gets the plaintext response.

    It involves quite a bit of back-and-forth, as you can see: 

    Each step is a potential point of failure that we have to consider while debugging!

    In particular, we saw certain kinds of problems when debugging OHTTP.

    • Customers asked for ways to test the live system from their end, and we often wrote one-off, custom clients for our customers specific deployments.
    • Figuring out which step caused an issue was time-consuming. Was the root cause a bug in our system or our customer’s system?
    • Examining raw bits was tedious and highly prone to human error. OHTTP builds on binary HTTP, which is a binary encoded HTTP request. Anytime we needed to check the binary encoding, we were painstakingly going through raw bits.

    As a result, we decided to place all of our privacy protocols in one tool. It has a clean interface that’s already familiar, displays every single step of the protocol in order, and is flexible enough to support new protocols and architectures.

    To see the difference this makes, let’s see an OHTTP debugging scenario — before and after pvcli.

    Debugging without pvcli

    Say we operate an OHTTP relay that sits in front of a customer's gateway. The customer has asked us to do an end-to-end test with a request:

    Recall the OHTTP steps from earlier. The first step is to fetch the public key from the gateway. We use curl to fetch it from the customer gateway and get this back:

    That’s a big binary string in hex. To make sense of it, we look at OHTTP RFC 9458 §3 and parse it manually:

    • 0029 is 41 in decimal, telling us this public key entry has 41 bytes associated with it.
    • 55 is the public key ID.
    • 0020 identifies the asymmetric encryption method we can use. In this case, DHKEM(X25519, HKDF-SHA256).
    • b9bb667e2230dc01c6d6cc047f94a1083beb185c63e50ec09f7692a5a0832540 is the public key.
    • 0004 tells us there are 4 bytes of symmetric cryptographic IDs that follow.
    • 0001 and 0001 identify the symmetric encryption methods we can use: HKDF-SHA256 and AES-128-GCM.

    We repeat this process for however many public keys are in the binary string.

    Next, we convert our original HTTP request into binary HTTP, referencing RFC 9292. We manually craft the binary with the help of some bespoke scripts:

    We verify each field:

    • 02 means it's an indeterminate-length request
    • 04504f5354 is POST
    • 056874747073 is https
    • 117461726765742e6f687474702e696e666f is target.ohttp.info
    • and so on

    Finally, we form a wrapper HTTP request that will hold our OHTTP request. To do so, we spend some more time writing another makeshift script that encrypts the binary HTTP request in the manner OHTTP specifies, using the public key from earlier. We create a header, which is the concatenation of public key ID, asymmetric encryption method ID, and symmetric encryption method IDs. Then, we concatenate header and encrypted binary HTTP request, resulting in:

    We put those bytes into the body of our wrapper HTTP request, and send it to our relay. We get back a response.

    What does that mean? We reach out to the customer to ask if they can share logs from their gateway. In the meantime, we double-check the bits we've crafted. The decoded public keys look fine. The binary HTTP request… Oh! We see:

    BHTTP is length prefixed. That means we specify a length (0x0a is 10 in decimal), and then 10 bytes follow. But here, 11 bytes follow. There is an extra 20 before the 00. 20 represents a space character, so we must have accidentally added that when building the body. We remove the extra character, resend, and it works!

    Debugging with pvcli

    With pvcli, all of that is now a single command:

    It handles all the binary parsing and encrypting for us, and prints logs in case we want to dive deeper:

    What used to be a fragile process — involving manipulating bits, gluing together scripts, and referencing long RFCs — is now one command.

    What pvcli can do

    To install:

    pvcli takes a lot of inspiration from curl. We designed it with the “principle of least surprise” in mind. As a result, a lot of the arguments are the same as curl’s! Try a quick GET request to our cdn-cgi endpoint:

    If you’re curious about what is happening under the hood, you can use -v to get detailed logs:

    Now, about that OHTTP command from earlier: you use –ohttp to tell pvcli to construct an OHTTP request. You pass in the relay as the –first-hop and the gateway as the –proxy. The target will be an echo server, so you can see what the target would see. In this command, we filled in the arguments with a relay, gateway, and target from ohttp.info.

    Try running the command yourself!

    We’ve encountered many cases where we wanted to pass headers to the relay, rather than the target. You are able to do that with --first-hop-header:

    Similarly, we’ve also had cases where we wanted to authenticate to the relay with mTLS, to ensure that the correct client is talking with the correct relay. To do that, you can use –first-hop-client and --first-hop-key.

    And it just works. Need to test a full Oblivious HTTP request with a relay, a gateway, arbitrary headers, and mTLS? Or perhaps only request through a gateway? Or maybe you just want to see the OHTTP key configuration? pvcli can do it with a single command, debugging included.

    Why build our own tool?

    There are some great tools for OHTTP that already exist. Martin Thomson’s Rust implementation and Chris Wood’s Go implementation were incredibly helpful when we built out our original OHTTP implementation a few years ago. But pvcli is not only focused on OHTTP. We’re looking to add as many privacy-preserving protocols as we can to the tool. So while there are other OSS tools out there for debugging OHTTP, nothing combines OHTTP, CONNECT proxying, MASQUE and Privacy Pass (coming soon) all in one place.

    Contribute to pvcli

    Oblivious HTTP is an amazing protocol, and we would love to see you use it. We hope that this tool helps people debug OHTTP and write their own OHTTP implementations. 

    We are accepting contributions! To get started, clone the repo at https://github.com/cloudflareresearch/pvcli, and submit a pull request. 

    If you're looking for ways to contribute, here are some things on our to-do list. For MASQUE, we plan to add support for proxying TCP over HTTP/3, and UDP and/or IP over HTTP/2 and HTTP/3. For OHTTP, we plan to support post-quantum cryptography, add timing/latency information, support Chunked OHTTP, and improve logging.

    Contact us if you are interested in using Cloudflare’s OHTTP Relays and Gateways.

    The collective thoughts of the interwebz