Cloudflare WAF proactively protects against React vulnerability

Post Syndicated from Daniele Molteni original https://blog.cloudflare.com/waf-rules-react-vulnerability/

Cloudflare has deployed a new protection to address a vulnerability in React Server Components (RSC). All Cloudflare customers are automatically protected, including those on free and paid plans, as long as their React application traffic is proxied through the Cloudflare Web Application Firewall (WAF).

Cloudflare Workers are inherently immune to this exploit. React-based applications and frameworks deployed on Workers are not affected by this vulnerability.

We strongly recommend that customers immediately update their systems to the most recent version of React, despite our WAF being designed to detect and prevent this exploit.

What you need to know

Cloudflare has been alerted by its security partners to a Remote Code Execution (RCE) vulnerability impacting Next.js, React Router, and other React frameworks (security advisory CVE-2025-55182, rated CVSS 10.0). Specifically, React version 19.0, 19.1, and 19.2, and Next.js from version 15 through 16 were found to insecurely deserialize malicious requests, leading to RCE.

In response, Cloudflare has deployed new rules across its network, with the default action set to Block. These new protections are included in both the Cloudflare Free Managed Ruleset (available to all Free customers) and the standard Cloudflare Managed Ruleset (available to all paying customers). More information about the different rulesets can be found in our documentation.

The rule ID is as follows:

Ruleset

Rule ID

Default action

Managed Ruleset

33aa8a8a948b48b28d40450c5fb92fba

Block

Free Ruleset

2b5d06e34a814a889bee9a0699702280

Block

Customers on Professional, Business, or Enterprise plans should ensure that Managed Rules are enabled  —  follow these steps to turn it on. Customers on a Free plan have these rules enabled by default.

We recommend that customers update to the latest version of React 19.2.1 and the latest versions of Next.js (16.0.7, 15.5.7, 15.4.8).

The rules were deployed at 5:00 PM GMT on Tuesday, December 2, 2025. Since their release until the publication of this blog and the official CVE announcement, we have not observed any attempted exploit.

Looking forward

The Cloudflare security team has collaborated with partners to identify various attack patterns and ensure the new rules effectively prevent any bypasses. Over the coming hours and days, the team will maintain continuous monitoring for potential attack variations, updating our protections as necessary to secure all traffic proxied via Cloudflare.


Security updates for Wednesday

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

Security updates have been issued by Debian (containerd, mako, and xen), Fedora (forgejo, nextcloud, openbao, rclone, restic, and tigervnc), Oracle (firefox, kernel, libtiff, libxml2, and postgresql), SUSE (libecpg6, lightdm-kde-greeter, python-cbor2, python-mistralclient-doc, python315, and python39), and Ubuntu (kdeconnect, linux, linux-aws, linux-realtime, python-django, and unbound).

A final stable kernel update for 5.4

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

Greg Kroah-Hartman has announced the release of the 5.4.302 stable kernel:

This is the LAST 5.4.y release. It is now end-of-life and should not
be used by anyone, anymore. As of this point in time, there are 1539
documented unfixed CVEs for this kernel branch, and that number will
only increase over time as more CVEs get assigned for kernel bugs.

For the curious, Kroah-Hartman has also provided
a list of the unfixed CVEs for 5.4.302.

Cloudflare’s 2025 Q3 DDoS threat report — including Aisuru, the apex of botnets

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-threat-report-2025-q3/

Welcome to the 23rd edition of Cloudflare’s Quarterly DDoS Threat Report. This report offers a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network. In this edition, we focus on the third quarter of 2025.

The third quarter of 2025 was overshadowed by the Aisuru botnet with a massive army of an estimated 1–4 million infected hosts globally. Aisuru unleashed hyper-volumetric DDoS attacks routinely exceeding 1 terabit per second (Tbps) and 1 billion packets per second (Bpps). The number of these attacks surged 54% quarter-over-quarter (QoQ), averaging 14 hyper-volumetric attacks daily. The scale was unprecedented, with attacks peaking at 29.7 Tbps and 14.1 Bpps.

Key insights

Other than Aisuru, additional key insights in this report include:

  1. DDoS attack traffic against AI companies surged by as much as 347% MoM in September 2025, as public concern and regulatory review of AI increases. 

  2. Escalating EU-China trade tensions over rare earth minerals and EV tariffs coincide with a significant increase in DDoS attacks against the Mining, Minerals & Metals industry as well as the Automotive industry in 2025 Q3.

  3. Overall, in the third quarter of 2025, Cloudflare’s autonomous defenses blocked a total of 8.3 million DDoS attacks. That’s an average of almost 3,780 DDoS attacks per hour. The number of DDoS attacks grew by 15% QoQ and 40% YoY. 

DDoS attacks in numbers

So far in 2025, and with an entire quarter to go until the end of the year, Cloudflare has already mitigated 36.2 million DDoS attacks. That corresponds to 170% of the DDoS attacks Cloudflare mitigated throughout 2024.


In the third quarter of 2025, Cloudflare automatically detected and mitigated 8.3 million DDoS attacks, representing a 15% increase QoQ and 40% increase YoY.


Network-layer DDoS attacks, accounting for 71% of the DDoS attacks in 2025 Q3, or 5.9 million DDoS attacks, increased by 87% QoQ and 95% YoY. However, HTTP DDoS attacks, accounting only for 29% of the DDoS attacks in 2025 Q3, or 2.4 million DDoS attacks, decreased by 41% QoQ and 17% YoY.


In the third quarter of 2025, Cloudflare mitigated an average of 3,780 DDoS attacks every hour.


Aisuru breaking records with ultrasophisticated, hyper-volumetric DDoS attacks

Disruptive force

Aisuru targeted telecommunication providers, gaming companies, hosting providers, and financial services, to name a few. It has also caused “widespread collateral Internet disruption [in the US]”, as reported by Krebs on Security, simply due to the amount of botnet traffic routing through the Internet Service Providers (ISPs). 

Let that sink in. If Aisuru’s attack traffic can disrupt parts of the U.S. Internet infrastructure when said ISPs were not even the target of the attack, imagine what it can do when it’s directly aimed at unprotected or insufficiently protected ISPs, critical infrastructure, healthcare services, emergency services, and military systems. 

Botnet-for-hire and DDoS stats

“Chunks” of Aisuru are offered by distributors as botnets-for-hire, so anyone can potentially inflict chaos on entire nations by crippling backbone networks and saturating Internet links, disrupting millions of users and impairing access to essential services — all at a cost of a few hundred to a few thousand U.S. dollars. 

Since the start of 2025, Cloudflare has already mitigated 2,867 Aisuru attacks. In the third quarter alone, Cloudflare mitigated 1,304 hyper-volumetric attacks launched by Aisuru. That represents an increase of 54% QoQ. These include the world record-breaking 29.7 Tbps DDoS attack and the 14.1 Bpps DDoS attack. 


The 29.7 Tbps was a UDP carpet-bombing attack bombarding an average of 15K destination ports per second. The distributed attack randomized various packet attributes in an attempt to evade defenses, but Cloudflare’s mitigation systems detected and mitigated all the attacks, including this one, fully autonomously. Read more on How Cloudflare mitigates hyper-volumetric DDoS attacks.


Attack characteristics

While the majority of DDoS attacks are relatively small, in Q3, the amount of DDoS attacks that exceeded 100 million packets per second (Mpps) increased by 189% QoQ. Similarly, attacks exceeding 1 Tbps increased by 227% QoQ. On the HTTP layer, 4 out of every 100 attacks exceeded 1 million requests per second. 

Furthermore, most attacks, 71% of HTTP DDoS and 89% of network-layer, end in under 10 minutes. That’s too fast for any human or on-demand service to react. A short attack may only last a few seconds, but the disruption it causes can be severe, and recovery takes far longer. Engineering and operational teams are then stuck with a complex, multi-step process to get critical systems back online, check data for consistency across distributed systems, and restore secure, reliable service to customers. 

The impact of short-lived DDoS attacks, whether hyper-volumetric or not, can extend well beyond the duration of the attack.


Top attack sources

Seven out of the ten top sources are locations within Asia, with Indonesia in the lead. Indonesia is the largest source of DDoS attacks, and it has been ranked number one in the world for an entire year (since 2024 Q3). Even prior to this, Indonesia has always been placed in the top lists of attack sources. In 2024 Q2, Indonesia was the second-largest source, after climbing up from lower ranks in previous quarters and years.

To illustrate the rise of Indonesia as a DDoS hub, in just five years (since 2021 Q3), the percentage of HTTP DDoS attack requests originating from Indonesia has increased by a staggering 31,900%. 


Top attacked industries

DDoS attackers go after rare Earth minerals

DDoS attacks against the Mining, Minerals & Metals industry significantly increased in the third quarter of 2025 as the 25th European Union–China trade summit saw rising tensions over Electric Vehicle (EV) tariffs, rare-earth exports, and cybersecurity issues, according to multiple news outlets. The BBC reported that “China also raised export controls on rare earths and critical minerals.” Overall, the Mining, Minerals & Metals industry surged 24 spots on the global ranking, making it the 49th most attacked industry in the world.

The Automotive industry saw the largest surge in DDoS attacks, leaping the industry by 62 spots in just one quarter, placing it as the sixth most attacked industry in the world. Cybersecurity companies also saw a significant increase in DDoS attacks. The Cybersecurity industry hopped by 17 spots, making it the 13th most attacked industry in the world.

DDoS attacks against AI surge by 347%

In September 2025, a Tony Blair Institute poll showed Britons view AI more as an economic risk than an opportunity, sparking major headlines about automation and trust. The UK Law Commission launched a review into AI use in government, making it a headline month for AI ethics, regulation, and generative-AI adoption. In September 2025, Cloudflare also saw MoM spikes as high as 347% in HTTP DDoS attack traffic against generative AI companies (based on a sample of leading generative AI services).

The top 10

In the third quarter of 2025, Information Technology & Services topped the list as the most attacked industry, followed by Telecommunications, and Gambling & Casinos. Notably, Automotive surged dramatically by 62 spots QoQ. Media, Production & Publishing also saw a sharp rise, preceded by the Banking & Financial Services industry, the Retail industry, and the Consumer Electronics industry.


Top attacked locations

There is a direct correlation between geopolitical events and DDoS attack activity.

Stop the Loot!

“Lootuvaifi” (Stop the Loot!) in Maldivian, became the rallying chant in the 2025 Maldivian protests as protesters took to the streets objecting the “perceived government corruption and democratic backsliding,” peaking with the “end of free speech” media bill, which the UN Human Rights Chief said will “seriously undermine media freedom and the right to freedom of expression for the people of the Maldives if not withdrawn.” The 2025 Maldivian protests were accompanied by a barrage of DDoS attacks. Correspondingly, the Maldives was the country that saw the highest increase in DDoS attacks. In the third quarter of 2025, the Maldives leaped by 125 spots, making it the 38th most attacked country in the world.

‘Block Everything’

The nationwide protest movement, “Block Everything,” or “Bloquons Tout” in French, was launched by French trade unions in September 2025 to oppose President Macron’s government over new austerity measures, pension system changes, and rising living costs. While trade unions called for coordinated strikes and transport blockades to paralyze the country, cyber threat actors targeted French websites and Internet services with waves of DDoS attacks. France jumped 65 spots QoQ, making it the 18th most attacked country in the world. 

‘Drawing the red line for Gaza in Brussels’

Increases in DDoS attacks were observed alongside protests in more countries. For example, Belgium jumped 63 places making it the 74th most attacked country in the world, as “tens of thousands of protesters drew the Red Line for Gaza in Brussels.”

The top 10

In the third quarter of 2025, China remained the most attacked, followed by Turkey in second, and Germany in third place. The most notable changes within this quarter was an increase in DDoS attacks against the United States, which leaped by 11 spots as the fifth most attacked country. The Philippines saw the largest increase within the top 10 – it jumped by 20 spots.


Attack vectors 

Network-layer DDoS attacks

The amount of UDP DDoS attacks, partially fueled by Aisuru attacks, increased by 231% QoQ making it the top attack vector at the network-layer. DNS floods came in second place, SYN floods in third, and ICMP floods in fourth — accounting for just over half of all network-layer DDoS attacks.

Although almost 10 years have passed since its first major debut, Mirai DDoS attacks are still quite common. Almost 2 out of every 100 network-layer DDoS attacks are launched by permutations of the Mirai botnet.


HTTP DDoS attacks

Nearly 70% of HTTP DDoS attacks originated from botnets already known to Cloudflare. This reflects one of the benefits that our customers gain from using Cloudflare. Once a botnet attacks one out of the millions of Cloudflare customers, everyone is automatically protected from that botnet.

Another ~20% of HTTP DDoS attacks originated from fake or headless browsers, or included suspicious HTTP attributes. The remaining ~10% were a combination of generic floods, unusual requests, cache busting attacks, and attacks that targeted login endpoints.


Why legacy DDoS solutions no longer suffice

We’ve entered an era where DDoS attacks have rapidly grown in sophistication and size — beyond anything we could’ve imagined a few years ago. Many organizations have faced challenges in keeping pace with this evolving threat landscape. 

Organizations relying on on-premise mitigation appliances or on-demand scrubbing center solutions may benefit from reviewing their defense strategy given the current threat landscape.

Cloudflare, with its vast global network and autonomous DDoS mitigation systems, is committed to providing free unmetered DDoS protection to all customers, no matter the size, duration, or quantity of the DDoS attacks they face.

Яна Делирадева: Този живот може да се изпее

Post Syndicated from Ина Иванова original https://www.toest.bg/yana-deliradeva-tozi-zhivot-mozhe-da-se-izpee/

Яна Делирадева: Този живот може да се изпее

Яна Делирадева е българска хорова диригентка, ръководителка на създадения през 1947 г. хор „Детска китка“ (ЦПЛР – ОДК – Пловдив). Пътят ѝ е оформен от българската и американската образователна традиция: Яна учи пиано в Националното училище за музикално и танцово изкуство „Добрин Петков“, защитава бакалавърска степен по музикална педагогика в Академията за музикално и танцово изкуство (АМТИИ) „Проф. Асен Диамандиев“, впоследствие специализира хорово дирижиране в Националната музикална академия „Панчо Владигеров“, а след това три години и в Уестминстърския хоров колеж в Принстън, САЩ, при проф. Джоузеф Флъмърфелт.

Паралелно с дирижирането на хор „Детска китка“ Яна е музикална педагожка и преподавателка в АМТИИ „Проф. Асен Диамандиев“ в Пловдив и вокална педагожка на вокална група „Академия госпожа Опера“.

„Аз съм научена да изграждам групов звук“

Да дирижираш хор и да създаваш единен звук от десетки отделни гласове се възпитава. Днес, във времето, в което фаворизираме индивидуалността,

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

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

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

Между колективното и индивидуалното

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

Като дете аз винаги съм смятала, че съм една от всички.

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

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

Професионално Яна Делирадева получава възможността да работи с големите диригенти на столетието: Рикардо Мути, Зденек Мацал, сър Колин Дейвис, Курт Мазур, Волфганг Савалиш.

Изпълнявала съм в „Карнеги Хол“, в „Айвъри Фишър хол“ (дом на Нюйоркската филхармония), във филхармониите на Филаделфия и Ню Джърси. Америка е толкова различна от България, че сякаш бях на друга планета. Ти просто свикваш да живееш в едната или в другата действителност, но няма мост между тях. Много съм благодарна на моя съпруг, че ме подкрепи безрезервно да замина тогава; по онова време бяхме само гаджета. Да, той има огромна роля за моето заминаване и много ми помагаше.

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

Елена Станева е първата ѝ учителка по пиано, за която казва, че е поставила не само музикантската ѝ база, а и човешката почтеност и търсенето на автентичност. Едва по-късно Яна разбира, че тя е отглеждала и собственото ѝ мнение:

Веднъж ми каза: „Не го свирят така този Скрябин етюд, но ти много хубаво го защити.“

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

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

Трима са преподавателите от САЩ, за които и до днес Яна мисли с вълнение: легендарният Джоузеф Флъмърфелт, комуто се носи славата, че казва нещата искрено и без заобикалки в култура, в която не е прието да се говори така; Андрю Макгил, който е готов да обяснява всичко колкото трябва пъти, докато бъде разбран – тази „технология“ Яна Делирадева се опитва да спазва в преподавателската си работа сега; и Джеймс Джордан, който прилага системата на танцьора Рудолф Лабан и неговата теория за движението – диригентите използват различни видове усилие и индивидуални движения на тялото, за да добият определен звук.

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

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

Но как се създава репертоар?

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

Глас и общност

Отскоро Яна е ангажирана и с каузата „Хорова академия за непрофесионалисти“, организирана от Sofia Art Institute по идея на Венета Нейнска.

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

На практика Венета Нейнска се погрижи за всичко покрай организацията и ни остави с Валентина Георгиева (хор „Черноморски звуци“) да се съсредоточим и да дадем най-доброто от себе си.

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

Ние с моя съпруг Манол (Пейков) отдавна искахме да направим хорово училище в Пловдив, след като видяхме през 2015 г. какво бяха постигнали в Швеция. Още повече че тук има млади колеги, с които се разбираме и подкрепяме. Но за да се случи това, се искат усилия и зала. В Пловдив няма подходяща зала.

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

Аз вярвам, че хората трябва да имат равен достъп. Затова и „Детска китка“ не е частен хор.

Яна е потомствена музикантка. И двамата ѝ родители са хорови диригенти, така че тя с основание се шегува, че е с фамилна обремененост, когато я питам дали това е призванието ѝ. Днес Яна води репетиции всяка вечер без петък и неделя. Хор „Детска китка“ има участия в повече от 20 международни фестивала: миналата година децата бяха на турне в Япония и една от изявите им там беше благотворителен концерт в подкрепа на пострадалите от земетресението в Ишикава.

Яна Делирадева вярва, че трябва да се работи за изграждането на общност. Работата ѝ с подрастващи е възможност да подобри качеството на живота около себе си, защото доброто е заразно.

Моите студенти и децата от хора оценяват, ако ги заведеш на добро място.

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

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


Хората, които тихо и кротко променят средата, формират общности и задават посоки, в които има смисъл да тръгнем заедно. Тук ви срещаме с тях. Това са „Тези хора“.

Announcing Rapid7’s Next-Gen SIEM Buyer’s Guide

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/dr-rapid7-next-gen-siem-buyers-guide

AI dominates headlines, yet one cornerstone of security operations keeps evolving to meet today’s threats. Security Information and Event Management (SIEM) has come a long way from basic logging. Modern platforms unify threat detection, investigation, and response with automation, context, and AI, so analysts can act faster and with confidence. That is the focus of our new Next-gen SIEM Buyer’s Guide.

Why this guide now

Many teams are still wrestling with legacy SIEMs that were built for storage and compliance, not for today’s hybrid environments or AI-enabled adversaries. The market is crowded and the language is inconsistent, which makes evaluation tough. This guide cuts through the noise with a practical definition of next-gen SIEM and a clear set of evaluation criteria grounded in outcomes, not buzzwords. It explains how a SIEM should help you see more, decide faster, and respond with precision, by pairing analytics with automation and exposure context.

In this guide you will learn the core capabilities that define a next-gen SIEM, including high-fidelity data ingestion, curated detections, AI-assisted triage, automation, and integrated exposure context. Next, you’ll better understand how to assess platforms for usability, scalability, and total cost of ownership without sacrificing effectiveness. Finally, we will offer some questions to ask vendors so you can separate claims from proof and align the solution to your team’s workflows and maturity. The guide also highlights where SIEM sits alongside adjacent tools and why data quality, context, and integrated workflows matter more than feature lists.

Who should read it

Security leaders and practitioners who are evaluating SIEMs, planning a modernization, or looking to improve analyst efficiency and overall SOC performance will find practical guidance they can use in vendor conversations and internal planning. If your goals include reducing false positives, accelerating investigation and response, and tying detections to business risk, this guide will help you level set your needs with the right requirements.

How Rapid7 approaches next-gen SIEM

Rapid7’s approach brings detection and response together in a single, streamlined experience that helps analysts identify, investigate, and contain threats faster. Rapid7’s next-gen SIEM delivers curated detections mapped to attacker behavior, reducing false positives and surfacing high-priority alerts with clear context. Integrated investigation and response workflows guide analysts from alert to action within one interface, linking threat intelligence, identity, and asset data to drive faster, more confident decisions. Built on the Rapid7 Command Platform, this unified approach consolidates visibility across endpoints, networks, cloud, and SaaS environments, enabling coordinated detection and response without tool sprawl.

Get the guide

Download Rapid7’s Next-Gen SIEM Buyer’s Guide to learn how to evaluate platforms that deliver measurable detection and response outcomes, not just more data. If you want to see how these principles show up in the product, explore the Rapid7 Command Platform.

HPE brings Juniper Networking into its AMD Helios Rack-Scale AI Orbit

Post Syndicated from Cliff Robinson original https://www.servethehome.com/hpe-brings-juniper-networking-broadcom-into-its-amd-helios-rack-scale-ai-orbit/

HPE announced it would use Juniper’s Broadcom-based networking for its AMD Helios rack-scale AI platforms in 2026

The post HPE brings Juniper Networking into its AMD Helios Rack-Scale AI Orbit appeared first on ServeTheHome.

Your Training Data Is Your Most Valuable IP

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/your-training-data-is-your-most-valuable-ip/

A decorative image showing different generic computer module icons.

AI training data is now a company’s most valuable intellectual property—often worth more than the models themselves. Models can be replicated and architectures become public knowledge, but the datasets that capture your domain expertise and years of careful curation are irreplaceable.

Yet as AI workflows become increasingly distributed, that data moves constantly between environments, increasing exposure while reducing visibility. According to IBM, “Forty percent of breaches involved data stored across multiple environments… highlighting the challenge of tracking and safeguarding data, including shadow data, and data in AI workloads.” Meanwhile MIT Sloan researchers have documented that AI training datasets are often inconsistently documented and poorly understood, creating exposure that extends beyond technical vulnerabilities into operational and compliance failures.

Yet many organizations still treat training datasets as just another storage bucket. But protecting data at rest is both a compliance requirement and a competitive necessity. The integrity of your datasets now determines the integrity of your models.

Free resource: Understand why object storage is a strategic driver

Download our free ebook to learn how object storage supports every stage of the AI pipeline—from data collection to model deployment.

Download the Ebook

Why training data is the new target

The attack surface for AI systems has fundamentally shifted. Rather than targeting models in production, sophisticated adversaries now focus on the training pipeline itself.

Data poisoning has emerged as an insidious threat

Attackers inject subtle changes like biased samples, mislabeled data, or adversarial examples that skew model outcomes or introduce hidden backdoors. Recent research reveals that 26% of organizations surveyed in the US and UK have been victims of AI data poisoning in the last year. These poisoned models can quietly undermine fraud detection, weaken cyber defenses, and corrupt business-critical decisions.

Intellectual property theft takes on new dimensions

When adversaries steal training datasets, they’re stealing the accumulated expertise that gives your models their edge. Your training data represents thousands of hours of curation and annotation that encodes institutional knowledge about your customers and market. A competitor with your datasets can replicate your capabilities in weeks rather than years.

Silent corruption poses an equally serious but less visible threat

Infrastructure failures, human errors, or gradual drift in data pipelines can corrupt training datasets without triggering alerts. For organizations in regulated industries such as healthcare, financial services, or autonomous systems, this creates a reproducibility crisis. How do you prove your model was trained on authentic, unaltered data when you can’t verify the data’s provenance?

The NIST AI Risk Management Framework emphasizes that maintaining the provenance of training data and supporting attribution of AI system decisions to subsets of training data can assist with both transparency and accountability. Regulators and customers increasingly expect verifiable proof of data integrity throughout the training lifecycle.

The takeaway? The trustworthiness of every model begins with the trustworthiness of its data.

The principles of a secure AI data foundation

A strong protection model rests on three pillars—immutability, encryption, and regional control—each reinforcing long-term integrity.

1. Immutability: Protect against tampering or deletion

Immutability means write-once, read-many (WORM) protection that prevents modification or removal. Once data is written, it becomes locked—no one can modify, overwrite, or delete it for a defined retention period, but it remains fully accessible for reading. This technical guarantee prevents data poisoning attacks, stops accidental deletion, and enables verifiable reproducibility.

CISA advisories recommend immutable backups to guard against ransomware, but the benefits extend much further for AI systems. When you lock a dataset snapshot before training begins, you guarantee the ability to reproduce that exact model state, which is critical for debugging, regulatory audits, and forensic investigations when models fail.

Object Lock capabilities enforce immutability at the storage layer for set retention periods. Each dataset version becomes permanently immutable, creating an unalterable record of your training history that no administrator or attacker can modify.

Implementation tip: Enable Object Lock at the bucket level and integrate it with your data-ingestion scripts to automatically lock datasets as they’re created.

2. Encryption: Safeguard confidential data

Training datasets contain extraordinary value—customer information, proprietary annotations, competitive intelligence embedded in data selection. Server-side encryption protects this data both in transit and at rest, defending against unauthorized access even if other security layers fail. The EU’s recent NIS2 technical guidance explicitly prescribes cryptography as a required control measure for compliance.

The key to practical encryption is simplicity. Solutions should integrate seamlessly into existing workflows without requiring separate key-management infrastructure or introducing performance overhead that disrupts training pipelines.

Implementation tip: Look for server-side encryption options (like SSE-B2 or SSE-C) that remain transparent to your applications while providing the protection regulators require.

3. Regional control: Ensure data sovereignty and availability

Where your data physically resides matters for compliance, latency, and operational resilience. GDPR and similar regulations often require that sensitive data remain within specific jurisdictions. Beyond compliance, regional placement affects training performance—positioning data near compute resources or using high-performance delivery mechanisms can reduce transfer delays when moving large datasets.

The critical factor is transparency. You need explicit control over region selection and assurance that data won’t be replicated to secondary regions without your knowledge. Ambiguous “regional” configurations that might span continents create compliance risk. 

Consider a U.S. biomedical AI startup working with patient-derived data. They need datasets stored exclusively in U.S. regions to satisfy HIPAA requirements, Object Lock enabled to prove data integrity for regulatory submissions, and encryption applied to protect sensitive patient information—all while maintaining the competitive advantage their proprietary data provides. Regional control with clear guarantees makes this achievable.

Implementation tip: Choose storage providers that let you explicitly select regions during bucket creation with clear guarantees about where data resides, including replication destinations.

Beyond security: Enabling trust and traceability

Immutable, encrypted, regionally contained object storage enables AI governance at a level traditional storage infrastructure cannot.

Each dataset snapshot becomes a verifiable record of model history. When a model behaves unexpectedly in production, you can trace back to the exact training data used to create it. This capability accelerates debugging and provides the evidence needed to explain model decisions to regulators, customers, or internal stakeholders.

Storage infrastructure with built-in immutability and access logging provides the verifiable evidence that auditors require. Instead of reconstructing data lineage from logs and documentation, you can demonstrate exactly what happened with cryptographic proof.

These capabilities transform storage from a passive repository into an active component of your AI governance framework.

Implementation snapshot: Putting it all together

Establishing these protections with Backblaze B2 follows a straightforward path:

  1. Create buckets in regions that match your compliance and latency requirements.
  2. Enable Object Lock and configure retention policies aligned with your model development lifecycle.
  3. Apply server-side encryption (SSE-B2 or SSE-C) to all training data buckets.
  4. Activate versioning to maintain a complete history of dataset evolution.
  5. Configure logging to track access patterns and enable lineage verification.
  6. Integrate with compute using standard S3 compatible tools.

For organizations running intensive training workloads, Backblaze B2 Overdrive provides high-throughput object storage with up to 1Tbps throughput speeds and unlimited free egress. This allows enterprises to perform large quantities of concurrent data operations without performance degradation, keeping compute resources—including expensive GPUs—from sitting idle while waiting for data transfers. B2 Overdrive maintains the same security and compliance capabilities as standard Backblaze B2 while enabling faster iteration on model development.

The bottom line: Trust begins with proven data

The datasets you’ve built represent years of institutional knowledge—far more difficult to replace than the models trained on them. Protecting that intellectual property requires more than access controls and perimeter security. You need to prove the integrity of your data to regulators who demand accountability, to customers who expect trustworthy AI, and to your own teams who need confidence in model reproducibility.

Immutability and encryption make that proof simple and reliable. With Backblaze B2, you gain a clear, verifiable foundation for protecting your training data with the same rigor you apply to your most critical assets. Learn more about where Backblaze B2 sits in the AI data pipeline, or talk to our cloud storage experts.

The post Your Training Data Is Your Most Valuable IP appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Announcing replication support and Intelligent-Tiering for Amazon S3 Tables

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/announcing-replication-support-and-intelligent-tiering-for-amazon-s3-tables/

Today, we’re announcing two new capabilities for Amazon S3 Tables: support for the new Intelligent-Tiering storage class that automatically optimizes costs based on access patterns, and replication support to automatically maintain consistent Apache Iceberg table replicas across AWS Regions and accounts without manual sync.

Organizations working with tabular data face two common challenges. First, they need to manually manage storage costs as their datasets grow and access patterns change over time. Second, when maintaining replicas of Iceberg tables across Regions or accounts, they must build and maintain complex architectures to track updates, manage object replication, and handle metadata transformations.

S3 Tables Intelligent-Tiering storage class
With the S3 Tables Intelligent-Tiering storage class, data is automatically tiered to the most cost-effective access tier based on access patterns. Data is stored in three low-latency tiers: Frequent Access, Infrequent Access (40% lower cost than Frequent Access), and Archive Instant Access (68% lower cost compared to Infrequent Access). After 30 days without access, data moves to Infrequent Access, and after 90 days, it moves to Archive Instant Access. This happens without changes to your applications or impact on performance.

Table maintenance activities, including compaction, snapshot expiration, and unreferenced file removal, operate without affecting the data’s access tiers. Compaction automatically processes only data in the Frequent Access tier, optimizing performance for actively queried data while reducing maintenance costs by skipping colder files in lower-cost tiers.

By default, all existing tables use the Standard storage class. When creating new tables, you can specify Intelligent-Tiering as the storage class, or you can rely on the default storage class configured at the table bucket level. You can set Intelligent-Tiering as the default storage class for your table bucket to automatically store tables in Intelligent-Tiering when no storage class is specified during creation.

Let me show you how it works
You can use the AWS Command Line Interface (AWS CLI) and the put-table-bucket-storage-class and get-table-bucket-storage-class commands to change or verify the storage tier of your S3 table bucket.

# Change the storage class
aws s3tables put-table-bucket-storage-class \
   --table-bucket-arn $TABLE_BUCKET_ARN  \
   --storage-class-configuration storageClass=INTELLIGENT_TIERING

# Verify the storage class
aws s3tables get-table-bucket-storage-class \
   --table-bucket-arn $TABLE_BUCKET_ARN  \

{ "storageClassConfiguration":
   { 
      "storageClass": "INTELLIGENT_TIERING"
   }
}

S3 Tables replication support
The new S3 Tables replication support helps you maintain consistent read replicas of your tables across AWS Regions and accounts. You specify the destination table bucket and the service creates read-only replica tables. It replicates all updates chronologically while preserving parent-child snapshot relationships. Table replication helps you build global datasets to minimize query latency for geographically distributed teams, meet compliance requirements, and provide data protection.

You can now easily create replica tables that deliver similar query performance as their source tables. Replica tables are updated within minutes of source table updates and support independent encryption and retention policies from their source tables. Replica tables can be queried using Amazon SageMaker Unified Studio or any Iceberg-compatible engine including DuckDB, PyIceberg, Apache Spark, and Trino.

You can create and maintain replicas of your tables through the AWS Management Console or APIs and AWS SDKs. You specify one or more destination table buckets to replicate your source tables. When you turn on replication, S3 Tables automatically creates read-only replica tables in your destination table buckets, backfills them with the latest state of the source table, and continually monitors for new updates to keep replicas in sync. This helps you meet time-travel and audit requirements while maintaining multiple replicas of your data.

Let me show you how it works
To show you how it works, I proceed in three steps. First, I create an S3 table bucket, create an Iceberg table, and populate it with data. Second, I configure the replication. Third, I connect to the replicated table and query the data to show you that changes are replicated.

For this demo, the S3 team kindly gave me access to an Amazon EMR cluster already provisioned. You can follow the Amazon EMR documentation to create your own cluster. They also created two S3 table buckets, a source and a destination for the replication. Again, the S3 Tables documentation will help you to get started.

I take a note of the two S3 Tables bucket Amazon Resource Names (ARNs). In this demo, I refer to these as the environment variables SOURCE_TABLE_ARN and DEST_TABLE_ARN.

First step: Prepare the source database

I start a terminal, connect to the EMR cluster, start a Spark session, create a table, and insert a row of data. The commands I use in this demo are documented in Accessing tables using the Amazon S3 Tables Iceberg REST endpoint.

sudo spark-shell \
--packages "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160" \
--master "local[*]" \
--conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \
--conf "spark.sql.defaultCatalog=spark_catalog" \
--conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog" \
--conf "spark.sql.catalog.spark_catalog.type=rest" \
--conf "spark.sql.catalog.spark_catalog.uri=https://s3tables.us-east-1.amazonaws.com/iceberg" \
--conf "spark.sql.catalog.spark_catalog.warehouse=arn:aws:s3tables:us-east-1:012345678901:bucket/aws-news-blog-test" \
--conf "spark.sql.catalog.spark_catalog.rest.sigv4-enabled=true" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-name=s3tables" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-region=us-east-1" \
--conf "spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO" \
--conf "spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider" \
--conf "spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled=false"

spark.sql("""
CREATE TABLE s3tablesbucket.test.aws_news_blog (
customer_id STRING,
address STRING
) USING iceberg
""")

spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust1', 'val1')")

spark.sql("SELECT * FROM s3tablesbucket.test.aws_news_blog LIMIT 10").show()
+-----------+-------+
|customer_id|address|
+-----------+-------+
|      cust1|   val1|
+-----------+-------+

So far, so good.

Second step: Configure the replication for S3 Tables

Now, I use the CLI on my laptop to configure the S3 table bucket replication.

Before doing so, I create an AWS Identity and Access Management (IAM) policy to authorize the replication service to access my S3 table bucket and encryption keys. Refer to the S3 Tables replication documentation for the details. The permissions I used for this demo are:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "s3tables:*",
                "kms:DescribeKey",
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}

After having created this IAM policy, I can now proceed and configure the replication:

aws s3tables-replication put-table-replication \
--table-arn ${SOURCE_TABLE_ARN} \
--configuration  '{
    "role": "arn:aws:iam::<MY_ACCOUNT_NUMBER>:role/S3TableReplicationManualTestingRole", 
    "rules":[
        {
            "destinations": [
                {
                    "destinationTableBucketARN": "${DST_TABLE_ARN}"
                }]
        }
    ]

The replication starts automatically. Updates are typically replicated within minutes. The time it takes to complete depends on the volume of data in the source table.

Third step: Connect to the replicated table and query the data

Now, I connect to the EMR cluster again, and I start a second Spark session. This time, I use the destination table.

S3 Tables replication - destination table

To verify the replication works, I insert a second row of data on the source table.

spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust2', 'val2')")

I wait a few minutes for the replication to trigger. I follow the status of the replication with the get-table-replication-status command.

aws s3tables-replication get-table-replication-status \
--table-arn ${SOURCE_TABLE_ARN} \
{
    "sourceTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test/table/e0fce724-b758-4ee6-85f7-ca8bce556b41",
    "destinations": [
        {
            "replicationStatus": "pending",
            "destinationTableBucketArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst",
            "destinationTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst/table/5e3fb799-10dc-470d-a380-1a16d6716db0",
            "lastSuccessfulReplicatedUpdate": {
                "metadataLocation": "s3://e0fce724-b758-4ee6-8-i9tkzok34kum8fy6jpex5jn68cwf4use1b-s3alias/e0fce724-b758-4ee6-85f7-ca8bce556b41/metadata/00001-40a15eb3-d72d-43fe-a1cf-84b4b3934e4c.metadata.json",
                "timestamp": "2025-11-14T12:58:18.140281+00:00"
            }
        }
    ]
}

When replication status shows ready, I connect to the EMR cluster and I query the destination table. Without surprise, I see the new row of data.

S3 Tables replication - target table is up to date

Additional things to know
Here are a couple of additional points to pay attention to:

  • Replication for S3 Tables supports both Apache Iceberg V2 and V3 table formats, giving you flexibility in your table format choice.
  • You can configure replication at the table bucket level, making it straightforward to replicate all tables under that bucket without individual table configurations.
  • Your replica tables maintain the storage class you choose for your destination tables, which means you can optimize for your specific cost and performance needs.
  • Any Iceberg-compatible catalog can directly query your replica tables without additional coordination—they only need to point to the replica table location. This gives you flexibility in choosing query engines and tools.

Pricing and availability
You can track your storage usage by access tier through AWS Cost and Usage Reports and Amazon CloudWatch metrics. For replication monitoring, AWS CloudTrail logs provide events for each replicated object.

There are no additional charges to configure Intelligent-Tiering. You only pay for storage costs in each tier. Your tables continue to work as before, with automatic cost optimization based on your access patterns.

For S3 Tables replication, you pay the S3 Tables charges for storage in the destination table, for replication PUT requests, for table updates (commits), and for object monitoring on the replicated data. For cross-Region table replication, you also pay for inter-Region data transfer out from Amazon S3 to the destination Region based on the Region pair.

As usual, refer to the Amazon S3 pricing page for the details.

Both capabilities are available today in all AWS Regions where S3 Tables are supported.

To learn more about these new capabilities, visit the Amazon S3 Tables documentation or try them in the Amazon S3 console today. Share your feedback through AWS re:Post for Amazon S3 or through your AWS Support contacts.

— seb

Amazon S3 Storage Lens adds performance metrics, support for billions of prefixes, and export to S3 Tables

Post Syndicated from Veliswa Boya original https://aws.amazon.com/blogs/aws/amazon-s3-storage-lens-adds-performance-metrics-support-for-billions-of-prefixes-and-export-to-s3-tables/

Today, we’re announcing three new capabilities for Amazon S3 Storage Lens that give you deeper insights into your storage performance and usage patterns. With the addition of performance metrics, support for analyzing billions of prefixes, and direct export to Amazon S3 Tables, you have the tools you need to optimize application performance, reduce costs, and make data-driven decisions about your Amazon S3 storage strategy.

New performance metric categories
S3 Storage Lens now includes eight new performance metric categories that help identify and resolve performance constraints across your organization. These are available at organization, account, bucket, and prefix levels. For example, the service helps you identify small objects in a bucket or prefix that can  slow down application performance. This can be mitigated by batching small objects or using the Amazon S3 Express One Zone storage class for higher performance small object workloads.

To access the new performance metrics, you need to enable performance metrics in the S3 Storage Lens advanced tier when creating a new Storage Lens dashboard or editing an existing configuration.

Metric category Details Use case Mitigation
Read request size Distribution of read request sizes (GET) by day Identify dataset with small read request patterns that slow down performance Small request: Batch small objects or use Amazon S3 Express One Zone for high-performance small object workloads
Write request size Distribution of write request sizes (PUT, POST, COPY, and UploadPart) by day Identify dataset with small write request patterns that slow down performance Large request: Parallelize requests, use MPU or use AWS CRT
Storage size Distribution of object sizes Identify dataset with small small objects that slow down performance Small object sizes: Consider bundling small objects
Concurrent PUT 503 errors Number of 503s due to concurrent PUT operation on same object Identify prefixes with concurrent PUT throttling that slow down performance For single writer, modify retry behavior or use Amazon S3 Express One Zone. For multiple writers, use consensus mechanism or use Amazon S3 Express One Zone
Cross-Region data transfer Bytes transferred and requests sent across Region, in Region Identify potential performance and cost degradation due to cross-Region data access Co-locate compute with data in the same AWS Region
Unique objects accessed Number or percentage of unique objects accessed per day Identify datasets where small subset of objects are being frequently accessed. These can be moved to higher performance storage tier for better performance Consider moving active data to Amazon S3 Express One Zone or other caching solutions
FirstByteLatency (existing Amazon CloudWatch metric) Daily average of first byte latency metric The daily average per-request time from the complete request being received to when the response starts to be returned
TotalRequestLatency (existing Amazon CloudWatch metric) Daily average of Total Request Latency The daily average elapsed per request time from the first byte received to the last byte sent

How it works
On the Amazon S3 console I choose Create Storage Lens dashboard to create a new dashboard. You can also edit an existing dashboard configuration. I then configure general settings such as providing a Dashboard name, Status, and the optional Tags. Then, I choose Next.


Next, I define the scope of the dashboard by selecting Include all Regions and Include all buckets and specifying the Regions and buckets to be included.


I opt in to the Advanced tier in the Storage Lens dashboard configuration, select Performance metrics, then choose Next.


Next, I select Prefix aggregation as an additional metrics aggregation, then leave the rest of the information as default before I choose Next.


I select the Default metrics report, then General purpose bucket as the bucket type, and then select the Amazon S3 bucket in my AWS account as the Destination bucket. I leave the rest of the information as default, then select Next.


I review all the information before I choose Submit to finalize the process.


After it’s enabled, I’ll receive daily performance metrics directly in the Storage Lens console dashboard. You can also choose to export report in CSV or Parquet format to any bucket in your account or publish to Amazon CloudWatch. The performance metrics are aggregated and published daily and will be available at multiple levels: organization, account, bucket, and prefix. In this dropdown menu, I choose the % concurrent PUT 503 error for the Metric, Last 30 days for the Date range, and 10 for the Top N buckets.


The Concurrent PUT 503 error count metric tracks the number of 503 errors generated by simultaneous PUT operations to the same object. Throttling errors can degrade application performance. For a single writer, modify retry behavior or use higher performance storage tier such as Amazon S3 Express One Zone to mitigate concurrent PUT 503 errors. For multiple writers scenario, use a consensus mechanism to avoid concurrent PUT 503 errors or use higher performance storage tier such as Amazon S3 Express One Zone.

Complete analytics for all prefixes in your S3 buckets
S3 Storage Lens now supports analytics for all prefixes in your S3 buckets through a new Expanded prefixes metrics report. This capability removes previous limitations that restricted analysis to prefixes meeting a 1% size threshold and a maximum depth of 10 levels. You can now track up to billions of prefixes per bucket for analysis at the most granular prefix level, regardless of size or depth.

The Expanded prefixes metrics report includes all existing S3 Storage Lens metric categories: storage usage, activity metrics (requests and bytes transferred), data protection metrics, and detailed status code metrics.

How to get started
I follow the same steps outlined in the How it works section to create or update the Storage Lens dashboard. In Step 4 on the console, where you select export options, you can select the new Expanded prefixes metrics report. Thereafter, I can export the expanded prefixes metrics report in CSV or Parquet format to any general purpose bucket in my account for efficient querying of my Storage Lens data.


Good to know
This enhancement addresses scenarios where organizations need granular visibility across their entire prefix structure. For example, you can identify prefixes with incomplete multipart uploads to reduce costs, track compliance across your entire prefix structure for encryption and replication requirements, and detect performance issues at the most granular level.

Export S3 Storage Lens metrics to S3 Tables
S3 Storage Lens metrics can now be automatically exported to S3 Tables, a fully managed feature on AWS with built-in Apache Iceberg support. This integration provides daily automatic delivery of metrics to AWS managed S3 Tables for immediate querying without requiring additional processing infrastructure.

How to get started
I start by following the process outlined in Step 5 on the console, where I choose the export destination. This time, I choose Expanded prefixes metrics report. In addition to General purpose bucket, I choose Table bucket.

The new Storage Lens metrics are exported to new tables in an AWS managed bucket aws-s3.


I select the expanded_prefixes_activity_metrics table to view API usage metrics for expanded prefix reports.


I can preview the table on the Amazon S3 console or use Amazon Athena to query the table.


Good to know
S3 Tables integration with S3 Storage Lens simplifies metric analysis using familiar SQL tools and AWS analytics services such as Amazon Athena, Amazon QuickSight, Amazon EMR, and Amazon Redshift, without requiring a data pipeline. The metrics are automatically organized for optimal querying, with custom retention and encryption options to suit your needs.

This integration enables cross-account and cross-Region analysis, custom dashboard creation, and data correlation with other AWS services. For example, you can combine Storage Lens metrics with S3 Metadata to analyze prefix-level activity patterns and identify objects in prefixes with cold data that are eligible for transition to lower-cost storage tiers.

For your agentic AI workflows, you can use natural language to query S3 Storage Lens metrics in S3 Tables with the S3 Tables MCP Server. Agents can ask questions such as ‘which buckets grew the most last month?’ or ‘show me storage costs by storage class’ and get instant insights from your observability data.

Now available
All three enhancements are available in all AWS Regions where S3 Storage Lens is currently offered (except the China Regions and AWS GovCloud (US)).

These features are included in the Amazon S3 Storage Lens Advanced tier at no additional charge beyond standard advanced tier pricing. For the S3 Tables export, you pay only for S3 Tables storage, maintenance, and queries. There is no additional charge for the export functionality itself.

To learn more about Amazon S3 Storage Lens performance metrics, support for billions of prefixes, and export to S3 Tables, refer to the Amazon S3 user guide. For pricing details, visit the Amazon S3 pricing page.

Veliswa Boya.

Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents

Post Syndicated from Danilo Poccia original https://aws.amazon.com/blogs/aws/amazon-bedrock-agentcore-adds-quality-evaluations-and-policy-controls-for-deploying-trusted-ai-agents/

Today, we’re announcing new capabilities in Amazon Bedrock AgentCore to further remove barriers holding AI agents back from production. Organizations across industries are already building on AgentCore, the most advanced agentic platform to build, deploy, and operate highly capable agents securely at any scale. In just 5 months since preview, the AgentCore SDK has been downloaded over 2 million times. For example:

  • PGA TOUR, a pioneer and innovation leader in sports has built a multi-agent content generation system to create articles for their digital platforms. The new solution, built on AgentCore, enables the PGA TOUR to provide comprehensive coverage for every player in the field, by increasing content writing speed by 1,000 percent while achieving a 95 percent reduction in costs.
  • Independent software vendors (ISVs) like Workday are building the software of the future on AgentCore. AgentCore Code Interpreter provides Workday Planning Agent with secure data protection and essential features for financial data exploration. Users can analyze financial and operational data through natural language queries, making financial planning intuitive and self-driven. This capability reduces time spent on routine planning analysis by 30 percent, saving approximately 100 hours per month.
  • Grupo Elfa, a Brazilian distributor and retailer, relies on AgentCore Observability for complete audit traceability and real-time metrics of their agents, transforming their reactive processes into proactive operations. Using this unified platform, their sales team can handle thousands of daily price quotes while the organization maintains full visibility of agent decisions, helping achieve 100 percent traceability of agent decisions and interactions, and reduced problem resolution time by 50 percent.

As organizations scale their agent deployments, they face challenges around implementing the right boundaries and quality checks to confidently deploy agents. The autonomy that makes agents powerful also makes them hard to confidently deploy at scale, as they might access sensitive data inappropriately, make unauthorized decisions, or take unexpected actions. Development teams must balance enabling agent autonomy while ensuring they operate within acceptable boundaries and with the quality you require to put them in front of customers and employees.

The new capabilities available today take the guesswork out of this process and help you build and deploy trusted AI agents with confidence:

  • Policy in AgentCore (Preview) – Defines clear boundaries for agent actions by intercepting AgentCore Gateway tool calls before they run using policies with fine-grained permissions.
  • AgentCore Evaluations (Preview) – Monitors the quality of your agents based on real-world behavior using built-in evaluators for dimensions such as correctness and helpfulness, plus custom evaluators for business-specific requirements.

We’re also introducing features that expand what agents can do:

  • Episodic functionality in AgentCore Memory – A new long-term strategy that helps agents learn from experiences and adapt solutions across similar situations for improved consistency and performance in similar future tasks.
  • Bidirectional streaming in AgentCore Runtime – Deploys voice agents where both users and agents can speak simultaneously following a natural conversation flow.

Policy in AgentCore for precise agent control
Policy gives you control over the actions agents can take and are applied outside of the agent’s reasoning loop, treating agents as autonomous actors whose decisions require verification before reaching tools, systems, or data. It integrates with AgentCore Gateway to intercept tool calls as they happen, processing requests while maintaining operational speed, so workflows remain fast and responsive.

You can create policies using natural language or directly use Cedar—an open source policy language for fine-grained permissions—simplifying the process to set up, understand, and audit rules without writing custom code. This approach makes policy creation accessible to development, security, and compliance teams who can create, understand, and audit rules without specialized coding knowledge.

The policies operate independently of how the agent was built or which model it uses. You can define which tools and data agents can access—whether they are APIs, AWS Lambda functions, Model Context Protocol (MCP) servers, or third-party services—what actions they can perform, and under what conditions.

Teams can define clear policies once and apply them consistently across their organization. With policies in place, developers gain the freedom to create innovative agentic experiences, and organizations can deploy their agents to act autonomously while knowing they’ll stay within defined boundaries and compliance requirements.

Using Policy in AgentCore
You can start by creating a policy engine in the new Policy section of the AgentCore console and associate it with one or more AgentCore gateways.

A policy engine is a collection of policies that are evaluated at the gateway endpoint. When associating a gateway with a policy engine, you can choose whether to enforce the result of the policy—effectively permitting or denying access to a tool call—or to only emit logs. Using logs helps you test and validate a policy before enabling it in production.

Then, you can define the policies to apply to have granular control over access to the tools offered by the associated AgentCore gateways.

Amazon Bedrock AgentCore Policy console

To create a policy, you can start with a natural language description (that should include information of the authentication claims to use) or directly edit Cedar code.

Amazon Bedrock AgentCore Policy add

Natural language-based policy authoring provides a more accessible way for you to create fine-grained policies. Instead of writing formal policy code, you can describe rules in plain English. The system interprets your intent, generates candidate policies, validates them against the tool schema, and uses automated reasoning to check safety conditions—identifying prompts that are overly permissive, overly restrictive, or contain conditions that can never be satisfied.

Unlike generic large language model (LLM) translations, this feature understands the structure of your tools and generates policies that are both syntactically correct and semantically aligned with your intent, while flagging rules that cannot be enforced. It is also available as a Model Context Protocol (MCP) server, so you can author and validate policies directly in your preferred AI-assisted coding environment as part of your normal development workflow. This approach reduces onboarding time and helps you write high-quality authorization rules without needing Cedar expertise.

The following sample policy uses information from the OAuth claims in the JWT token used to authenticate to an AgentCore gateway (for the role) and the arguments passed to the tool call (context.input) to validate access to the tool processing a refund. Only an authenticated user with the refund-agent role can access the tool but for amounts (context.input.amount) lower than $200 USD.

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool__process_refund",
  resource == AgentCore::Gateway::"<GATEWAY_ARN>"
)
when {
  principal.hasTag("role") &&
  principal.getTag("role") == "refund-agent" &&
  context.input.amount < 200
};

AgentCore Evaluations for continuous, real-time quality intelligence
AgentCore Evaluations is a fully managed service that helps you continuously monitor and analyze agent performance based on real-world behavior. With AgentCore Evaluations, you can use built-in evaluators for common quality dimensions such as correctness, helpfulness, tool selection accuracy, safety, goal success rate, and context relevance. You can also create custom model-based scoring systems configured with your choice of prompt and model for business-tailored scoring while the service samples live agent interactions and scores them continuously.

All results from AgentCore Evaluations are visualized in Amazon CloudWatch alongside AgentCore Observability insights, providing one place for unified monitoring. You can also set up alerts and alarms on the evaluation scores to proactively monitor agent quality and respond when metrics fall outside acceptable thresholds.

You can use AgentCore Evaluations during the testing phase where you can check an agent against the baseline before deployment to stop faulty versions from reaching users, and in production for continuous improvement of your agents. When quality metrics drop below defined thresholds—such as a customer service agent satisfaction declining or politeness scores dropping by more than 10 percent over an 8-hour period—the system triggers immediate alerts, helping to detect and address quality issues faster.

Using AgentCore Evaluations
You can create an online evaluation in the new Evaluations section of the AgentCore console. You can use as data source an AgentCore agent endpoint or a CloudWatch log group used by an external agent. For example, I use here the same sample customer support agent I shared when we introduced AgentCore in preview.

Amazon Bedrock AgentCore Evaluations source

Then, you can select the evaluators to use, including custom evaluators that you can define starting from the existing templates or build from scratch.

Amazon Bedrock AgentCore Evaluations source

For example, for a customer support agent, you can select metrics such as:

  • Correctness – Evaluates whether the information in the agent’s response is factually accurate
  • Faithfulness – Evaluates whether information in the response is supported by provided context/sources
  • Helpfulness – Evaluates from user’s perspective how useful and valuable the agent’s response is
  • Harmfulness – Evaluates whether the response contains harmful content
  • Stereotyping – Detects content that makes generalizations about individuals or groups

The evaluators for tool selection and tool parameter accuracy can help you understand if an agent is choosing the right tool for a task and extracting the correct parameters from the user queries.

To complete the creation of the evaluation, you can choose the sampling rate and optional filters. For permissions, you can create a new AWS Identity and Access Management (IAM) service role or pass an existing one.

Amazon Bedrock AgentCore Evaluations create

The results are published, as they are evaluated, on Amazon CloudWatch in the AgentCore Observability dashboard. You can choose any of the bar chart sections to see the corresponding traces and gain deeper insight into the requests and responses behind that specific evaluation.

Amazon AgentCore Evaluations results

Because the results are in CloudWatch, you can use all of its feature to create, for example, alarms and automations.

Creating custom evaluators in AgentCore Evaluations
Custom evaluators allow you to define business-specific quality metrics tailored to your agent’s unique requirements. To create a custom evaluator, you provide the model to use as a judge, including inference parameters such as temperature and max output tokens, and a tailored prompt with the judging instructions. You can start from the prompt used by one of the built-in evaluators or enter a new one.

AgentCore Evaluations create custom evaluator

Then, you define the scale to produce in output. It can be either numeric values or custom text labels that you define. Finally, you configure whether the evaluation is computed by the model on single traces, full sessions, or for each tool call.

AgentCore Evaluations custom evaluator scale

AgentCore Memory episodic functionality for experience-based learning
AgentCore Memory, a fully managed service that gives AI agents the ability to remember past interactions, now includes a new long-term memory strategy that gives agents the ability to learn from past experiences and apply those lessons to provide more helpful assistance in future interactions.

Consider booking travel with an agent: over time, the agent learns from your booking patterns—such as the fact that you often need to move flights to later times when traveling for work due to client meetings. When you start your next booking involving client meetings, the agent proactively suggests flexible return options based on these learned patterns. Just like an experienced assistant who learns your specific travel habits, agents with episodic memory can now recognize and adapt to your individual needs.

When you enable the new episodic functionality, AgentCore Memory captures structured episodes that record the context, reasoning process, actions taken, and outcomes of agent interactions, while a reflection agent analyzes these episodes to extract broader insights and patterns. When facing similar tasks, agents can retrieve these learnings to improve decision-making consistency and reduce processing time. This reduces the need for custom instructions by including in the agent context only the specific learnings an agent needs to complete a task instead of a long list of all possible suggestions.

AgentCore Runtime bidirectional streaming for more natural conversations
With AgentCore Runtime, you can deploy agentic applications with few lines of code. To simplify deploying conversational experiences that feel natural and responsive, AgentCore Runtime now supports bidirectional streaming. This capability enables voice agents to listen and adapt while users speak, so that people can interrupt agents mid-response and have the agent immediately adjust to the new context—without waiting for the agent to finish its current output. Rather than traditional turn-based interaction where users must wait for complete responses, bidirectional streaming creates flowing, natural conversations where agents dynamically change their response based on what the user is saying.

Building these conversational experiences from the ground up requires significant engineering effort to handle the complex flow of simultaneous communication. Bidirectional streaming simplifies this by managing the infrastructure needed for agents to process input while generating output, handling interruptions gracefully, and maintaining context throughout dynamic conversation shifts. You can now deploy agents that naturally adapt to the fluid nature of human conversation—supporting mid-thought interruptions, context switches, and clarifications without losing the thread of the interaction.

Things to know
Amazon Bedrock AgentCore, including the preview of Policy, is available in the US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland) AWS Regions . The preview of AgentCore Evaluations is available in the US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Sydney), and Europe (Frankfurt) Regions. For Regional availability and future roadmap, visit AWS Capabilities by Region.

With AgentCore, you pay for what you use with no upfront commitments. For detailed pricing information, visit the Amazon Bedrock pricing page. AgentCore is also a part of the AWS Free Tier that new AWS customers can use to get started at no cost and explore key AWS services.

These new features work with any open source framework such as CrewAI, LangGraph, LlamaIndex, and Strands Agents, and with any foundation model. AgentCore services can be used together or independently, and you can get started using your favorite AI-assisted development environment with the AgentCore open source MCP server.

To learn more and get started quickly, visit the AgentCore Developer Guide.

— Danilo

Build multi-step applications and AI workflows with AWS Lambda durable functions

Post Syndicated from Donnie Prakoso original https://aws.amazon.com/blogs/aws/build-multi-step-applications-and-ai-workflows-with-aws-lambda-durable-functions/

Modern applications increasingly require complex and long-running coordination between services, such as multi-step payment processing, AI agent orchestration, or approval processes awaiting human decisions. Building these traditionally required significant effort to implement state management, handle failures, and integrate multiple infrastructure services.

Starting today, you can use AWS Lambda durable functions to build reliable multi-step applications directly within the familiar AWS Lambda experience. Durable functions are regular Lambda functions with the same event handler and integrations you already know. You write sequential code in your preferred programming language, and durable functions track progress, automatically retry on failures, and suspend execution for up to one year at defined points, without paying for idle compute during waits.

AWS Lambda durable functions use a checkpoint and replay mechanism, known as durable execution, to deliver these capabilities. After enabling a function for durable execution, you add the new open source durable execution SDK to your function code. You then use SDK primitives like “steps” to add automatic checkpointing and retries to your business logic and “waits” to efficiently suspend execution without compute charges. When execution terminates unexpectedly, Lambda resumes from the last checkpoint, replaying your event handler from the beginning while skipping completed operations.

Getting started with AWS Lambda durable functions
Let me walk you through how to use durable functions.

First, I create a new Lambda function in the console and select Author from scratch. In the Durable execution section, I select Enable. Note that, durable function setting can only be set during function creation and currently can’t be modified for existing Lambda functions.

After I create my Lambda durable function, I can get started with the provided code.

Lambda durable functions introduces two core primitives that handle state management and recovery:

  • Steps—The context.step() method adds automatic retries and checkpointing to your business logic. After a step is completed, it will be skipped during replay.
  • Wait—The context.wait() method pauses execution for a specified duration, terminating the function, suspending and resuming execution without compute charges.

Additionally, Lambda durable functions provides other operations for more complex patterns: create_callback() creates a callback that you can use to await results for external events like API responses or human approvals, wait_for_condition() pauses until a specific condition is met like polling a REST API for process completion, and parallel() or map() operations for advanced concurrency use cases.

Building a production-ready order processing workflow
Now let’s expand the default example to build a production-ready order processing workflow. This demonstrates how to use callbacks for external approvals, handle errors properly, and configure retry strategies. I keep the code intentionally concise to focus on these core concepts. In a full implementation, you could enhance the validation step with Amazon Bedrock to add AI-powered order analysis.

Here’s how the order processing workflow works:

  • First, validate_order() checks order data to ensure all required fields are present.
  • Next, send_for_approval() sends the order for external human approval and waits for a callback response, suspending execution without compute charges.
  • Then, process_order() completes order processing.
  • Throughout the workflow, try-catch error handling distinguishes between terminal errors that stop execution immediately and recoverable errors inside steps that trigger automatic retries.

Here’s the complete order processing workflow with step definitions and the main handler:

import random
from aws_durable_execution_sdk_python import (
    DurableContext,
    StepContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import (
    Duration,
    StepConfig,
    CallbackConfig,
)
from aws_durable_execution_sdk_python.retries import (
    RetryStrategyConfig,
    create_retry_strategy,
)


@durable_step
def validate_order(step_context: StepContext, order_id: str) -> dict:
    """Validates order data using AI."""
    step_context.logger.info(f"Validating order: {order_id}")
    # In production: calls Amazon Bedrock to validate order completeness and accuracy
    return {"order_id": order_id, "status": "validated"}


@durable_step
def send_for_approval(step_context: StepContext, callback_id: str, order_id: str) -> dict:
    """Sends order for approval using the provided callback token."""
    step_context.logger.info(f"Sending order {order_id} for approval with callback_id: {callback_id}")
    
    # In production: send callback_id to external approval system
    # The external system will call Lambda SendDurableExecutionCallbackSuccess or
    # SendDurableExecutionCallbackFailure APIs with this callback_id when approval is complete
    
    return {
        "order_id": order_id,
        "callback_id": callback_id,
        "status": "sent_for_approval"
    }


@durable_step
def process_order(step_context: StepContext, order_id: str) -> dict:
    """Processes the order with retry logic for transient failures."""
    step_context.logger.info(f"Processing order: {order_id}")
    # Simulate flaky API that sometimes fails
    if random.random() > 0.4:
        step_context.logger.info("Processing failed, will retry")
        raise Exception("Processing failed")
    return {
        "order_id": order_id,
        "status": "processed",
        "timestamp": "2025-11-27T10:00:00Z",
    }


@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    try:
        order_id = event.get("order_id")
        
        # Step 1: Validate the order
        validated = context.step(validate_order(order_id))
        if validated["status"] != "validated":
            raise Exception("Validation failed")  # Terminal error - stops execution
        context.logger.info(f"Order validated: {validated}")
        
        # Step 2: Create callback
        callback = context.create_callback(
            name="awaiting-approval",
            config=CallbackConfig(timeout=Duration.from_minutes(3))
        )
        context.logger.info(f"Created callback with id: {callback.callback_id}")
        
        # Step 3: Send for approval with the callback_id
        approval_request = context.step(send_for_approval(callback.callback_id, order_id))
        context.logger.info(f"Approval request sent: {approval_request}")
        
        # Step 4: Wait for the callback result
        # This blocks until external system calls SendDurableExecutionCallbackSuccess or SendDurableExecutionCallbackFailure
        approval_result = callback.result()
        context.logger.info(f"Approval received: {approval_result}")
        
        # Step 5: Process the order with custom retry strategy
        retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0)
        processed = context.step(
            process_order(order_id),
            config=StepConfig(retry_strategy=create_retry_strategy(retry_config)),
        )
        if processed["status"] != "processed":
            raise Exception("Processing failed")  # Terminal error
        
        context.logger.info(f"Order successfully processed: {processed}")
        return processed
        
    except Exception as error:
        context.logger.error(f"Error processing order: {error}")
        raise error  # Re-raise to fail the execution

This code demonstrates several important concepts:

  • Error handling—The try-catch block handles terminal errors. When an unhandled exception is thrown outside of a step (like the validation check), it terminates the execution immediately. This is useful when there’s no point in retrying, such as invalid order data.
  • Step retries—Inside the process_order step, exceptions trigger automatic retries based on the default (step 1) or configured RetryStrategy (step 5). This handles transient failures like temporary API unavailability.
  • Logging—I use context.logger for the main handler and step_context.logger inside steps. The context logger suppresses duplicate logs during replay.

Now I create a test event with order_id and invoke the function asynchronously to start the order workflow. I navigate to the Test tab and fill in the optional Durable execution name to identify this execution. Note that, durable functions provides built-in idempotency. If I invoke the function twice with the same execution name, the second invocation returns the existing execution result instead of creating a duplicate.

I can monitor the execution by navigating to the Durable executions tab in the Lambda console:

Here I can see each step’s status and timing. The execution shows CallbackStarted followed by InvocationCompleted, which indicates the function has terminated and execution is suspended to avoid idle charges while waiting for the approval callback.

I can now complete the callback directly from the console by choosing Send success or Send failure, or programmatically using the Lambda API.

I choose Send success.

After the callback completes, the execution resumes and processes the order. If the process_order step fails due to the simulated flaky API, it automatically retries based on the configured strategy. Once all retries succeed, the execution completes successfully.

Monitoring executions with Amazon EventBridge
You can also monitor durable function executions using Amazon EventBridge. Lambda automatically sends execution status change events to the default event bus, allowing you to build downstream workflows, send notifications, or integrate with other AWS services.

To receive these events, create an EventBridge rule on the default event bus with this pattern:

{
  "source": ["aws.lambda"],
  "detail-type": ["Durable Execution Status Change"]
}

Things to know
Here are key points to note:

  • Availability—Lambda durable functions are now available in US East (Ohio) AWS Region. For the latest Region availability, visit the AWS Capabilities by Region page.
  • Programming language support—At launch, AWS Lambda durable functions supports JavaScript/TypeScript (Node.js 22/24) and Python (3.13/3.14). We recommend bundling the durable execution SDK with your function code using your preferred package manager. The SDKs are fast-moving, so you can easily update dependencies as new features become available.
  • Using Lambda versions—When deploying durable functions to production, use Lambda versions to ensure replay always happens on the same code version. If you update your function code while an execution is suspended, replay will use the version that started the execution, preventing inconsistencies from code changes during long-running workflows.
  • Testing your durable functions—You can test durable functions locally without AWS credentials using the separate testing SDK with pytest integration and the AWS Serverless Application Model (AWS SAM) command line interface (CLI) for more complex integration testing.
  • Open source SDKs—The durable execution SDKs are open source for JavaScript/TypeScript and Python. You can review the source code, contribute improvements, and stay updated with the latest features.
  • Pricing—To learn more on AWS Lambda durable functions pricing, refer to the AWS Lambda pricing page.

Get started with AWS Lambda durable functions by visiting the AWS Lambda console. To learn more, refer to AWS Lambda durable functions documentation page.

Happy building!

— Donnie

New capabilities to optimize costs and improve scalability on Amazon RDS for SQL Server and Oracle

Post Syndicated from Matheus Guimaraes original https://aws.amazon.com/blogs/aws/amazon-rds-for-oracle-and-rds-for-sql-server-add-new-capabilities-to-enhance-performance-and-optimize-costs/

Managing database environments demands a balance of resource efficiency and scalability. Organizations need flexible options across their entire database lifecycle, spanning development, testing, and production workloads with diverse storage and compute requirements.

To address these needs, we’re announcing four new capabilities for Amazon Relational Database Service (Amazon RDS) to help customers optimize their costs as well as improve efficiency and scalability for their Amazon RDS for Oracle and Amazon RDS for SQL Server databases. These enhancements include SQL Server Developer Edition support and expanded storage capabilities for both RDS for Oracle and RDS for SQL Server. Additionally, you can have CPU optimization options for RDS for SQL Server on M7i and R7i instances, which offer price reductions from previous generation instances and separately billed licensing fees.

Let’s explore what’s new.

SQL Server Developer Edition support
SQL Server Developer Edition is now available on RDS for SQL Server, offering a free SQL Server edition that includes all the Enterprise Edition functionalities. Developer Edition is licensed specifically for non-production workloads, so you can build and test applications without incurring SQL Server licensing costs in your development and testing environments.

This release brings significant cost savings to your development and testing environments, while maintaining consistency with your production configurations. You’ll have access to all Enterprise Edition features in your development environment, making it easier to test and validate your applications. Additionally, you’ll benefit from the full suite of Amazon RDS features, including automated backups, software updates, monitoring, and encryption capabilities throughout your development process.

To get started, upload your SQL Server binary files to Amazon Simple Storage Service (Amazon S3) and use them to create your Developer Edition instance. You can migrate existing data from your Enterprise or Standard Edition instances to Developer Edition instances using built-in SQL Server backup and restore operations.

M7i/R7i instances on RDS for SQL Server with support for optimize CPU
You can now use M7i and R7i instances on Amazon RDS for SQL Server to achieve several key benefits. These instances offer significant cost savings over previous generation instances. You also get improved transparency over your database costs with licensing fees and Amazon RDS DB instances costs billed separately.

RDS for SQL Server M7i/R7i instances offer up to 55% lower costs compared to previous generation instances.

Using the optimize CPU capability on these instances, you can customize the number of vCPUs on license-included RDS for SQL Server instances. This enhancement is particularly valuable for database workloads that require high memory and input/output operations per second (IOPS), but lower vCPU counts

This feature provides substantial benefits for your database operations. You can significantly reduce vCPU-based licensing costs while maintaining the same memory and IOPS performance levels your applications require. The capability supports higher memory-to-vCPU ratios and automatically disables hyperthreading while maintaining instance performance. Most importantly, you can fine-tune your CPU settings to precisely match your specific workload requirements, providing optimal resource utilization.

To get started, select SQL Server with an M7i or R7i instance type when creating a new database instance. Under Optimize CPU select Configure the number of vCPUs and set your desired vCPU count.

Additional storage volumes for RDS for Oracle and SQL Server
Amazon RDS for Oracle and Amazon RDS for SQL Server now support up to 256 TiB storage size, a fourfold increase in storage size per database instance, through the addition of up to three additional storage volumes.

The additional storage volumes provide extensive flexibility in managing your database storage needs. You can configure your volumes using both io2 and gp3 volumes to create an optimal storage strategy. You can store frequently accessed data on high-performance Provisioned IOPS SSD (io2) volumes while keeping historical data on cost-effective General Purpose SSD (gp3) volumes, which balances performance and cost. For temporary storage needs, such as month-end processing or data imports, you can add storage volumes as needed. After these operations are complete, you can empty the volumes and then remove them to reduce unnecessary storage costs.

These storage volumes offer operational flexibility with zero downtime and you can add or remove additional storage volumes without interrupting your database operations. You can also scale up multiple volumes in parallel to quickly meet growing storage demands. For Multi-AZ deployments, all additional storage volumes are automatically replicated to maintain high availability.

You can add storage volumes to new or existing database instances through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDKs.

Let me show you a quick example. I’ll add a storage volume to an existing RDS for Oracle database instance.

First, I navigate to the RDS console, then to my RDS for Oracle database instance detail page. I look under Configuration and I find the Additional storage volumes section.

You can add up to three additional storage volumes and each must be named according to a naming convention. Storage volumes can’t have the same name and you must choose between rdsdbdata2, rdsdbdata3, and rdsdbdata4. For RDS for Oracle database instances, I can add additional storage volumes to the database instance with the primary storage volume size of 200 GiB or higher.

I’m going to add two volumes, so I choose Add additional storage volume and then fill in all the required information. I choose rdsdbdata2 as the volume name and give it 12000 GiB of allocated storage with 60000 provisioned IOPS on an io2 storage type. For my second additional storage volume, rdsdbdata3, I choose to have 2000 GiB on gp3 with 15000 provisioned IOPS.

After confirmation, I wait for Amazon RDS to process my request and then my additional volumes are available.

You can also use the AWS CLI to add volumes during creation of database instances or when modifying them.

Things to know
These capabilities are now available in all commercial AWS Regions and the AWS GovCloud (US) Regions where Amazon RDS for Oracle and Amazon RDS for SQL Server are offered.

You can learn more about each of these capabilities in the Amazon RDS documentation for Developer Edition, optimize CPU, additional storage volumes for RDS for Oracle and additional storage volumes for RDS for SQL Server.

To learn more about the unbundled pricing structure for M7i and R7i instances on RDS for SQL Server, visit the Amazon RDS for SQL Server pricing page.

To get started with any of these capabilities, go to the Amazon RDS console or learn more by visiting the Amazon RDS documentation.

Introducing Database Savings Plans for AWS Databases

Post Syndicated from Betty Zheng (郑予彬) original https://aws.amazon.com/blogs/aws/introducing-database-savings-plans-for-aws-databases/

Since Amazon Web Services (AWS) introduced Savings Plans, customers have been able to lower the cost of running sustained workloads while maintaining the flexibility to manage usage across accounts, resource types, and AWS Regions. Today, we’re extending this flexible pricing model to AWS managed database services with the launch of Database Savings Plans, which help customers reduce database costs by up to 35% when they commit to a consistent amount of usage ($/hour) over a 1-year term. Savings automatically apply each hour to eligible usage across supported database services, and any additional usage beyond the commitment is billed at on-demand rates.

As organizations build and manage data-driven and AI applications, they often use different database services, engines and deployment types, including instance-based and serverless options, to meet evolving business needs. Database Savings Plans provide the flexibility to choose how workloads run while maintaining cost efficiency. If customers are in the middle of a migration or modernization effort, they can switch database engines and adjust deployment types, such as from provisioned to serverless as part of ongoing cost optimization, while continuing to receive discounted rates. If a customer’s business expands globally, they can also shift usage across AWS Regions and continue to benefit from the same commitment. By applying a consistent hourly commitment, customers can maintain predictable spend even as usage patterns evolve and analyze coverage and utilization using familiar cost management tools.

New Savings Plans
Each plan defines where pricing applies, the range of available discounts, and the level of flexibility provided across supported database engines, instance families, sizes, deployment options, or AWS Regions.

The hourly commitment automatically applies to all eligible usage regardless of Region, with support for Amazon Aurora, Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB (with MongoDB compatibility), Amazon Neptune, Amazon Keyspaces (for Apache Cassandra), Amazon Timestream, and AWS Database Migration Service (AWS DMS). As new eligible database offerings, instance types, or Regions become available, Savings Plans will automatically apply to that usage.

Discounts vary by deployment model and service type. Serverless deployments provide up to 35% savings compared to on-demand rates. Provisioned instances across supported database services deliver up to 20% savings. For Amazon DynamoDB and Amazon Keyspaces, on-demand throughput workloads receive up to 18% savings, and provisioned capacity offers up to 12%. Together, these savings help customers optimize costs while maintaining consistent coverage for database usage. To learn more about the pricing and eligible usage, visit the Database Savings Plans pricing page.

Purchasing Database Savings Plans
AWS Billing and Cost Management Console helps you choose Savings Plans and guides you through the purchase process. You can get started from the AWS Management Console or use the AWS Command Line Interface (AWS CLI) and the API. There are two ways to evaluate Database Savings Plans purchases, in the Recommendations view and in the Purchase Analyzer.

Recommendations – are automatically generated from your recent on-demand usage. To reach the Recommendations view in the Billing and Cost Management console, choose Savings and Commitments, Savings Plans, and Recommendations in the navigation pane. In the Recommendations view, select Database Savings Plans and configure the Recommendation options. AWS Savings Plans recommendations analyze your historical on-demand usage to identify the hourly commitment that delivers the highest overall savings.

The Purchase Analyzer – is designed for modeling custom commitment levels. If you want to purchase a different amount than the recommended commitment on the Purchase Analyzer page, select Database Savings Plans and configure Lookback period and Hourly commitment to simulate alternative commitment levels and see the projected impact on Cost, Coverage, and Utilization.

This way is preferred if your purchasing strategy includes smaller, incremental commitments over time or if you expect future usage changes that could affect your ideal purchase amount.

After reviewing the recommendations or running simulations in Savings Plans Recommendations or Savings Plans Purchase Analyzer, choose Add to cart to proceed with your chosen commitment. If you prefer to purchase directly, you can also navigate to the Purchase Savings Plans page. The console updates estimated discounts and coverage in real time as you adjust each setting, so you can evaluate the impact before completing your order.

You can learn more about how to choose and purchase Database Saving Plans by visiting the Savings Plans User Guide documents.

Now available
Database Savings Plans are available in all AWS Regions outside of China. Give them a try and start shaping your database strategy with more flexibility and predictable costs.

– Betty

The collective thoughts of the interwebz