Cloudflare named a Strong Performer in Email Security by Forrester

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/cloudflare-named-a-strong-performer-in-email-security-by-forrester/

Today, we are excited to announce that Forrester has recognized Cloudflare Email Security as a Strong Performer and among the top three providers in the ‘current offering’ category in “The Forrester Wave™: Email, Messaging, And Collaboration Security Solutions, Q2 2025” report. Get a complimentary copy of the report here. According to Forrester:

“Cloudflare is a solid choice for organizations looking to augment current email, messaging, and collaboration security tooling with deep content analysis and processing and malware detection capabilities.”

Cloudflare’s top-ranked criteria

In this evaluation, Forrester analyzed 10 Email Security vendors across 27 different criteria. Cloudflare received the highest scores possible in nine key evaluation criteria, and also scored among the top three in the current offering category. We believe this recognition is due to our ability to deliver stronger security outcomes across email and collaboration tools. These highlights showcase the strength and maturity of our Email Security solution:

Antimalware & sandboxing

Cloudflare’s advanced sandboxing engine analyzes files, whether directly attached or linked via cloud storage, using both static and dynamic analysis. Our AI-powered detectors evaluate attachment structure and behavior in real time, enabling protection not only against known malware but also emerging threats.

Malicious URL detection & web security

URLs are analyzed at delivery and again at click-time using Cloudflare’s global network. Our OCR and machine learning models extract and analyze metadata and page behavior to determine the maliciousness of a URL. Customers can also isolate suspicious links in remote browser sessions preventing user compromise. We continuously monitor URLs and retroactively remediate messages if the risk changes.

Threat intelligence

With over 4.4 trillion signals ingested daily across DNS, HTTP, and email layers, Cloudflare operates one of the most comprehensive real-time threat intelligence ecosystems. Campaigns observed via our DNS or HTTP layers are used to preemptively block related email threats well before traditional feeds.

Content analysis & processing

Cloudflare uses an ensemble of large language models (LLMs), natural language processing (NLP) techniques, and machine learning (ML) classifiers to analyze message tone, thread behavior, QR codes, and invoice language. These models detect indicators of fraud, business email compromise (BEC), and social engineering that legacy engines often miss.

Reporting & dashboards

Cloudflare’s unified Zero Trust dashboard gives SOC teams full visibility across email, web, cloud, data events. Analysts can pivot across user activity in just a few clicks and export data when needed. 

User quarantine

Our quarantine workflow is designed to minimize disruption. Customers can choose several ways to get notifications to users about messages that have been quarantined. 

Email authentication

Cloudflare enforces SPF, DKIM, and DMARC alignment automatically. We also offer a free DMARC reporting tool that gives customers visibility into email authentication failures and helps them take control of email brand protection.

Product security

Security is core to Cloudflare’s DNA. All services undergo continuous penetration testing, adhere to SOC 2 Type II and ISO 27001 standards, and operate on Cloudflare’s own infrastructure.

Partner ecosystem

Cloudflare integrates natively with Splunk, Microsoft Sentinel, Palo Alto XSOAR, and ServiceNow, making it easy to bring Cloudflare Email Security into existing SOC workflows. We also partner with leading human risk and awareness platforms to give organizations a more user-centric view of risk and behavior.

These strengths reflect Cloudflare’s commitment to building a comprehensive email security platform, one that’s designed to protect email inboxes and workspaces. 

Our email vision

We agree with Forrester’s perspective on where the email security market is headed. Across our customer base, from Fortune 100 enterprises to fast-growing startups, we’ve seen a clear evolution:

Phishing is no longer confined to the inbox.

Attackers are increasingly luring users into external apps, unaudited chat platforms, or legitimate third-party services, bypassing traditional security controls. This shift is forcing SOC teams to think beyond just email and adopt a more holistic approach to workspace security.

Cloudflare was one of the first vendors to position email security as part of a broader SASE and Zero Trust strategy, securing not just messages, but the entire user surface. Looking ahead, we’re doubling down on this integrated vision of workspace security to give SOC teams simpler investigations and faster response.

What’s next: our strategic focus

We will continue to:

  • Build AI-driven automation
    Reduce alert fatigue and manual triage by using LLMs to summarize incidents, auto-label threats, and recommend next steps, allowing junior analysts to act with senior-level confidence.

  • Deepen integrations across the Cloudflare ecosystem
    Continue to unify signals across email, web, cloud, and data to give security teams a single view of user behavior driving faster remediations.

  • Enhance real-time user coaching
    Deliver contextual guidance at the moment of risk, whether via banners, isolation flows, or in-app warnings, to help users make safer and more informed decisions.

  • Develop best-in-class detections
    Continue investing in advanced models detecting new and novel phishing campaigns by leveraging global telemetry from our network edge to stop novel threats faster.

Cloudflare has always approached email security not as a standalone point solution, but as a core pillar of unified threat protection, deeply integrated across the modern enterprise security stack.

Ready to enhance your email security?

We provide all organizations (whether a Cloudflare customer or not) with free access to our Retro Scan tool, allowing them to use our predictive AI models to scan existing inbox messages. Retro Scan will detect and highlight any threats found, enabling organizations to remediate them directly in their email accounts. With these insights, organizations can implement further controls, either using Cloudflare Email Security or their preferred solution, to prevent similar threats from reaching their inboxes in the future.

If you are interested in how Cloudflare can help secure your inboxes, sign up for a phishing risk assessment here. 

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester’s objectivity here .

Seeing Is Securing: How Surface Command Expands MDR Visibility and Impact

Post Syndicated from Conner Goldstein original https://blog.rapid7.com/2025/05/30/seeing-is-securing-how-surface-command-expands-mdr-visibility-and-impact/

Seeing Is Securing: How Surface Command Expands MDR Visibility and Impact

Imagine hiring a professional security team to guard your home — only to discover they’re doing so by monitoring camera feeds from only the front of the house — securing the front door but blissfully unaware of the unlocked window in the back. That’s what many organizations face today when relying on Managed Detection and Response (MDR) services without full visibility across their digital environments.

Shadow IT, orphaned assets, internet-facing exposures, and unmanaged cloud services are all part of an expanding attack surface. And, according to Enterprise Strategy Group, 76% of organizations have experienced some type of cyberattack involving an unknown or unmanaged internet-facing asset(1) — the kind of risk that stems from gaps in visibility. The result? A critical mismatch between the Attack Surface (what adversaries can reach) and the Detection Surface (what MDR services are configured to see and respond to).

To maximize the effectiveness of security operations, MDR must continually evolve. Today at Rapid7, that means integrating Surface Command — not as a dashboard or tool to manage, but as a behind-the-scenes capability that strengthens the service our customers rely on.

Extending the detection surface

Surface Command enhances the MDR experience by combining two critical perspectives:

  1. CAASM (Cyber Asset Attack Surface Management) consolidates insights from across internal tooling — vulnerability management platforms, EDR, identity systems, IT service management, firewalls, and more.
  2. EASM (External Attack Surface Management) complements this by continuously scanning for exposed infrastructure: domains, APIs, IPs, ports, and services.

Together, they offer a complete picture of what’s actually in your environment — and what’s at risk — without requiring additional effort from security teams. For the Rapid7 SOC, this means less risk for blind spots and faster, more confident investigations. For customers, it means fewer RFIs and greater trust in the response process.

Bridging the visibility gap

Many organizations today rely on spreadsheets and manual processes to keep track of their infrastructure — and the consequences are significant. Incomplete inventories, inconsistent classifications, and missed configuration details all contribute to increased risk and slower response.

Surface Command addresses this with three key strengths:

  • Complete inventory: Using API-based integrations with common security and IT operations tools, Surface Command automatically discovers and classifies a broad set of internal and internet-facing assets — from cloud environments to endpoint platforms, firewall configurations, and vulnerability management tools. This removes the guesswork and closes visibility gaps.
  • Continuous insight: Visibility isn’t a one-time event. Surface Command continuously monitors for new assets and changes to existing ones, ensuring the customer and the SOC always have a current picture of what exists and how it’s exposed.
  • Automated efficiency: By eliminating the need for manual tracking and inventory upkeep, Surface Command frees security teams to focus on higher-value priorities. One customer shared that this capability helped eliminate nearly 100 hours of manual asset tracking per month — time they redirected toward strategic initiatives.

These operational advantages translate directly into security value: better data, faster detection and investigation, and a more resilient managed defense.

Enabling a smarter MDR experience

Visibility is a means to an end. By enabling Surface Command, the MDR SOC has invaluable insight into every corner of your security environment, bringing efficiencies and deep insights to your managed security program:

  • Earlier awareness during onboarding: Our SOC gets a complete picture of the customer environment right away, which means we can begin protecting it more effectively from day one.
  • More context during incidents: When a detection triggers on a previously unknown asset, the SOC isn’t starting from zero. Surface Command provides the information needed to understand what a system is, who owns it, and how it’s configured.
  • Stronger foundation for threat hunting: For teams that want to lean into proactive defense, Surface Command gives the context needed to ask better questions — and find better answers.

It also supports compliance initiatives by clarifying what’s in scope and how it’s protected. For organizations pursuing NIST, CIS, or ISO alignment, that transparency can be a game changer.

Making Attack Surface Management more accessible than ever

Surface Command brings the power of Attack Surface Management — long seen as a capability reserved for mature, well-resourced security teams — directly into the hands of Rapid7 MDR customers. Our goal is to ensure that your internal security team and our SOC are given the most complete context possible from day one.

There are a number of ways Surface Command is available to MDR customers today. Contact your Rapid7 account team or click here to initiate a no commitment trial today.

(1) Enterprise Strategy Group

[$] Out of Pocket and into the wallabag

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

Mozilla has decided to throw in
the towel on Pocket, a social-bookmarking
service that it acquired in 2017. This has left many users scrambling
for a replacement for Pocket before its shutdown in July. One possible
option is wallabag, a
self-hostable, MIT-licensed project for saving web content for later
reading. It can import saved data from services like Pocket, share
content on the web, export to various formats, and more. Even better,
it puts users in control of their data long-term.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (.NET 8.0, .NET 9.0, firefox, ghostscript, gstreamer1-plugins-bad-free, libsoup3, mingw-freetype, perl, ruby, sqlite, thunderbird, unbound, valkey, and xz), Debian (chromium, firefox-esr, libavif, linux-6.1, modsecurity-apache, mydumper, systemd, and thunderbird), Fedora (coreutils, dnsdist, docker-buildx, maturin, mingw-python-flask, mingw-python-flit-core, ruff, rust-hashlink, rust-rusqlite, and thunderbird), Red Hat (pcs), SUSE (augeas, brltty, brotli, ca-certificates-mozilla, dnsdist, glibc, grub2, kernel, libsoup, libsoup2, libxml2, open-vm-tools, perl, postgresql13, postgresql15, postgresql16, postgresql17, python-cryptography, python-httpcore, python-h11, python311, runc, s390-tools, slurm, slurm_20_11, slurm_22_05, slurm_23_02, slurm_24_11, tomcat, and webkit2gtk3), and Ubuntu (linux-aws).

Сериалът не е турски

Post Syndicated from Емилия Милчева original https://www.toest.bg/serialut-ne-e-turski/

Не гледам турски сериали.

Сериалът не е турски

С тази фраза лидерът на ГЕРБ Бойко Борисов отказа да коментира случващото се в ДПС и преминаването на Джевдет Чакъров в лагера на ДПС – Ново начало и на главатаря му Делян Пеевски. 

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

Историята, в която Чакъров – подводачът на т.нар. автентично ДПС (Big Boss, разбира се, е Ахмед Доган), напуска партията си, е от българската драматична поредица „Смъртта на ДПС“. По БНТ Юджел Атилла определи действията на Чакъров като „последния пирон“ в ковчега. 

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

Но Доган посочи за лидер и феноменалния олигарх Делян Пеевски, който превзе ДПС, „изкупувайки“ партийния му елит чрез методите на тоягата и моркова. Чакъров напусна лагера на Доган, след като Софийският градски съд наложи запор върху фирми на сина му Сами Чакъров заради досъдебно производство, водено от Комисията за противодействие на корупцията и Софийската градска прокуратура. 

36-годишният Чакъров-младши е развил бизнес в различни сфери – хранителни стоки, консултантски и инвестиционни услуги до енергетика, но най-важният са соларните паркове и търговията с панели. Сред тях са „Белозем Солар Парк“, „Дупница Солар“ и „Верила Солар Парк 2“, обявен преди две години за най-големия и модерен в България, осигуряващ електроенергия за телекома Yettel. Инвестицията във „Верила“ е за около 200 млн. лв., с инсталирани мощности от 123 MW на над 1300 дка. Соларният парк на Чакъров ще получи и 41,2 млн. лв., тъй като е сред одобрените за еврофинансиране от Министерството на енергетиката 112 проекта за изграждане на съоръжения за съхранение на електроенергия.

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

От формацията определиха решението на Чакъров като „жалка персонална капитулация пред Пеевски“. Самият Пеевски каза, че Чакъров е напуснал „файтона на тези номади и всичко приключи“.

Какви ще са последиците?

Феникс от ДПС…

Нова партия ще се роди от ДПС, с ново име, без да повтаря стария модел, увери Юджел Атилла. Ако новата партия продължи да носи старите зависимости, задкулисие и икономическо обсебване, ще е просто ребрандирана фасада на същата политическа схема.

Но дали това ще е спасението за дълбоката криза на идентичността, в която е изпаднало ДПС – последната системна партия от Прехода, загинала пред очите ни. БСП се разпадаше бавно и постепенно поради неспособността да се превърне в модерна лява партия, а соцносталгиците и русофилите се разпръснаха по други политически атракциони. СДС агонизира по-кратко, но за сметка на това по-шумно заради очакванията за промяна, с които влезе в политиката. Вътрешни предателства, компромиси и злоупотреби с власт превърнаха „синьото лъвче“ в политически призрак, пришит към ГЕРБ. 

След 35 години история ДПС умира по различен начин, загубвайки най-важното – своя мит и своя разказ. Само за десетина месеца събитията, които се развиха, детронираха Ахмед Доган, който вече не е Сокола, а сянка на легендата. Безсмисленото нахлуване в обитаваната от него резиденция – т.нар. Боянски сараи, показа обезсилен политик, който трудно артикулира, далеч от някогашния ореол на стратег и балансьор, обграден от страх и почит. 

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

Realpolitik

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

Председателят на ДПС – Ново начало демаскира партията – обърна гръб на либералите от АЛДЕ и я придърпа към консерваторите евроскептици. Тази седмица евродепутати и депутати от ДПС – Ново начало с Пеевски участваха във форума за консервативни лидери и идеи CPAC Hungary 2025*. На откриването са били премиерите на Унгария, Словакия и Грузия – Виктор Орбан, Роберт Фицо, Иракли Кобаидзе, както и бившият министър-председател на Чехия Андрей Бабиш. Американският президент Доналд Тръмп благодарил на „дългогодишните си приятели“, които са били с него в най-трудните му моменти.

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

По bTV бившият лидер на младежкото ДПС Корман Исмаилов, един от напусналите партията през 2011 г., коментира, че „чакъровците“ отиват в „Ново начало“, защото има „нов разпределител на порциите“. Исмаилов предрече по-кратко лидерство на Пеевски, за разлика от „аналоговия Доган“.

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

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

В турските сериали поне хепиендът е гарантиран. Обаче сериалът не е турски.

Why Take9 Won’t Improve Cybersecurity

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/why-take9-wont-improve-cybersecurity.html

There’s a new cybersecurity awareness campaign: Take9. The idea is that people—you, me, everyone—should just pause for nine seconds and think more about the link they are planning to click on, the file they are planning to download, or whatever it is they are planning to share.

There’s a website—of course—and a video, well-produced and scary. But the campaign won’t do much to improve cybersecurity. The advice isn’t reasonable, it won’t make either individuals or nations appreciably safer, and it deflects blame from the real causes of our cyberspace insecurities.

First, the advice is not realistic. A nine-second pause is an eternity in something as routine as using your computer or phone. Try it; use a timer. Then think about how many links you click on and how many things you forward or reply to. Are we pausing for nine seconds after every text message? Every Slack ping? Does the clock reset if someone replies midpause? What about browsing—do we pause before clicking each link, or after every page loads? The logistics quickly become impossible. I doubt they tested the idea on actual users.

Second, it largely won’t help. The industry should know because we tried it a decade ago. “Stop. Think. Connect.” was an awareness campaign from 2016, by the Department of Homeland Security—this was before CISA—and the National Cybersecurity Alliance. The message was basically the same: Stop and think before doing anything online. It didn’t work then, either.

Take9’s website says, “Science says: In stressful situations, wait 10 seconds before responding.” The problem with that is that clicking on a link is not a stressful situation. It’s normal, one that happens hundreds of times a day. Maybe you can train a person to count to 10 before punching someone in a bar but not before opening an attachment.

And there is no basis in science for it. It’s a folk belief, all over the Internet but with no actual research behind it—like the five-second rule when you drop food on the floor. In emotionally charged contexts, most people are already overwhelmed, cognitively taxed, and not functioning in a space where rational interruption works as neatly as this advice suggests.

Pausing Adds Little

Pauses help us break habits. If we are clicking, sharing, linking, downloading, and connecting out of habit, a pause to break that habit works. But the problem here isn’t habit alone. The problem is that people aren’t able to differentiate between something legitimate and an attack.

The Take9 website says that nine seconds is “time enough to make a better decision,” but there’s no use telling people to stop and think if they don’t know what to think about after they’ve stopped. Pause for nine seconds and… do what? Take9 offers no guidance. It presumes people have the cognitive tools to understand the myriad potential attacks and figure out which one of the thousands of Internet actions they take is harmful. If people don’t have the right knowledge, pausing for longer—even a minute—will do nothing to add knowledge.

The three-part suspicion, cognition, and automaticity model (SCAM) is one way to think about this. The first is lack of knowledge—not knowing what’s risky and what isn’t. The second is habits: people doing what they always do. And third, using flawed mental shortcuts, like believing PDFs to be safer than Microsoft Word documents, or that mobile devices are safer than computers for opening suspicious emails.

These pathways don’t always occur in isolation; sometimes they happen together or sequentially. They can influence each other or cancel each other out. For example, a lack of knowledge can lead someone to rely on flawed mental shortcuts, while those same shortcuts can reinforce that lack of knowledge. That’s why meaningful behavioral change requires more than just a pause; it needs cognitive scaffolding and system designs that account for these dynamic interactions.

A successful awareness campaign would do more than tell people to pause. It would guide them through a two-step process. First trigger suspicion, motivating them to look more closely. Then, direct their attention by telling them what to look at and how to evaluate it. When both happen, the person is far more likely to make a better decision.

This means that pauses need to be context specific. Think about email readers that embed warnings like “EXTERNAL: This email is from an address outside your organization” or “You have not received an email from this person before.” Those are specifics, and useful. We could imagine an AI plug-in that warns: “This isn’t how Bruce normally writes.” But of course, there’s an arms race in play; the bad guys will use these systems to figure out how to bypass them.

This is all hard. The old cues aren’t there anymore. Current phishing attacks have evolved from those older Nigerian scams filled with grammar mistakes and typos. Text message, voice, or video scams are even harder to detect. There isn’t enough context in a text message for the system to flag. In voice or video, it’s much harder to trigger suspicion without disrupting the ongoing conversation. And all the false positives, when the system flags a legitimate conversation as a potential scam, work against people’s own intuition. People will just start ignoring their own suspicions, just as most people ignore all sorts of warnings that their computer puts in their way.

Even if we do this all well and correctly, we can’t make people immune to social engineering. Recently, both cyberspace activist Cory Doctorow and security researcher Troy Hunt—two people who you’d expect to be excellent scam detectors—got phished. In both cases, it was just the right message at just the right time.

It’s even worse if you’re a large organization. Security isn’t based on the average employee’s ability to detect a malicious email; it’s based on the worst person’s inability—the weakest link. Even if awareness raises the average, it won’t help enough.

Don’t Place Blame Where It Doesn’t Belong

Finally, all of this is bad public policy. The Take9 campaign tells people that they can stop cyberattacks by taking a pause and making a better decision. What’s not said, but certainly implied, is that if they don’t take that pause and don’t make those better decisions, then they’re to blame when the attack occurs.

That’s simply not true, and its blame-the-user message is one of the worst mistakes our industry makes. Stop trying to fix the user. It’s not the user’s fault if they click on a link and it infects their system. It’s not their fault if they plug in a strange USB drive or ignore a warning message that they can’t understand. It’s not even their fault if they get fooled by a look-alike bank website and lose their money. The problem is that we’ve designed these systems to be so insecure that regular, nontechnical people can’t use them with confidence. We’re using security awareness campaigns to cover up bad system design. Or, as security researcher Angela Sasse first said in 1999: “Users are not the enemy.”

We wouldn’t accept that in other parts of our lives. Imagine Take9 in other contexts. Food service: “Before sitting down at a restaurant, take nine seconds: Look in the kitchen, maybe check the temperature of the cooler, or if the cooks’ hands are clean.” Aviation: “Before boarding a plane, take nine seconds: Look at the engine and cockpit, glance at the plane’s maintenance log, ask the pilots if they feel rested.” This is obviously ridiculous advice. The average person doesn’t have the training or expertise to evaluate restaurant or aircraft safety—and we don’t expect them to. We have laws and regulations in place that allow people to eat at a restaurant or board a plane without worry.

But—we get it—the government isn’t going to step in and regulate the Internet. These insecure systems are what we have. Security awareness training, and the blame-the-user mentality that comes with it, are all we have. So if we want meaningful behavioral change, it needs a lot more than just a pause. It needs cognitive scaffolding and system designs that account for all the dynamic interactions that go into a decision to click, download, or share. And that takes real work—more work than just an ad campaign and a slick video.

This essay was written with Arun Vishwanath, and originally appeared in Dark Reading.

Трънливият път до успешната трансплантация на трахея

Post Syndicated from original https://www.toest.bg/trunliviyat-put-do-uspeshnata-transplantatsia-na-traheya/

Трънливият път до успешната трансплантация на трахея

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

Пътят на въздуха към белите дробове

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

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

Пречки пред успешната трансплантация на трахея

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

Трансплантация на биосинтетична трахея

Гръдният хирург д-р Паоло Макиарини, който някога е смятан за пионер в приложението на стволови клетки в медицината, е обвинен и осъден след смъртта на трима от пациентите му, месеци след проведената трансплантация на биосинтетична трахея. През 2023 г. Апелативният съд в Стокхолм осъжда Макиарини на 2 години и 6 месеца затвор.

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

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

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

Той е съавтор на три научни публикации, свързани с трансплантациите на биосинтетични трахеи. В една от статиите е описано състоянието на пациент в продължение на 12 месеца, но се оказва, че реално такива данни не са събирани, а самият Макиарини не е посещавал пациента след операцията. В друга научна статия се описва здравословното състояние на пациент, проследяван в продължение на 5 месеца, но отново впоследствие се доказва, че такива данни не са налични. И трите статии са изтеглени от медицинското научно списание The Lancet, съответно през 2016, 2019 и 2023 г.

Първата успешна трансплантация на трахея

През 2021 г. екип хирурзи от болница Mount Sinai в Ню Йорк осъществяват първата в света успешна трансплантация на трахея от трупен донор. Тази процедура с историческо значение е резултат от 30 години проучвания на кръвоснабдяването на трахеята. Операцията е с продължителност 18 часа, ръководи се от д-р Ерик Дженден и в нея участва екип от 50 специалисти. Протоколът за трансплантацията и реваскуларизацията е технически ясен и възпроизводим.

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

Поглед към бъдещето

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

Учените разглеждат и потенциалното приложение на частично децелуларизираните присадки на трахея в популации, където заболяванията на дихателната система са с по-висока честота. Децелуларизирането е ензимно или химично отстраняване на клетъчни компоненти от органа, за да се премахне имуногенният фактор и така да се намали рискът от отхвърляне. Усилията са насочени към изясняването на въпроса как предходни операции на дихателните пътища са засегнали стволовите клетки и регенерационните способности на тъканите. Например екипът на д-р Сюзън Рейнолдс от една от най-големите педиатрични болници в САЩ изследва стволовите клетки, които изграждат епитела на органите на дихателната система. Изследователите от Raynolds Lab установяват, че заболяванията на белите дробове водят до биологично остаряване на популацията от стволови клетки в дихателните пътища. Учените се надяват, че тази информация ще спомогне за подбора на пациенти, чието състояние ще се подобри значително след трансплантирането на частично децелуларизирана присадка на трахея.

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

ASRock Rack AMPONEMD12DNO for AmpereOne M Arm Servers Shown at Computex 2025

Post Syndicated from Cliff Robinson original https://www.servethehome.com/asrock-rack-amponemd12dno-for-ampereone-m-arm-servers-shown-at-computex-2025/

At Computex 2025, we saw the ASRock Rack AMPONEMD12DNO which is a 12-channel memory AmpereOne M Arm server platform

The post ASRock Rack AMPONEMD12DNO for AmpereOne M Arm Servers Shown at Computex 2025 appeared first on ServeTheHome.

Friday Squid Blogging: NGC 1068 Is the “Squid Galaxy”

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/friday-squid-blogging-ngc-1068-is-the-squid-galaxy.html

I hadn’t known that the NGC 1068 galaxy is nicknamed the “Squid Galaxy.” It is, and it’s spewing neutrinos without the usual accompanying gamma rays.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Amazon FSx for Lustre launches new storage class with the lowest-cost and only fully elastic Lustre file storage

Post Syndicated from Veliswa Boya original https://aws.amazon.com/blogs/aws/amazon-fsx-for-lustre-adds-new-storage-class-with-the-lowest-cost-and-only-fully-elastic-lustre-file-storage/

Seismic imaging is a geophysical technique used to create detailed pictures of the Earth’s subsurface structure. It works by generating seismic waves that travel into the ground, reflect off various rock layers and structures, and return to the surface where they’re detected by sensitive instruments known as geophones or hydrophones. The huge volumes of acquired data often reach petabytes for a single survey and this presents significant storage, processing, and management challenges for researchers and energy companies.

Customers who run these seismic imaging workloads or other high performance computing (HPC) workloads, such as weather forecasting, advanced driver-assistance system (ADAS) training, or genomics analysis, already store the huge volumes of data on either hard disk drive (HDD)-based or a combination of HDD and solid state drive (SSD) file storage on premises. However, as these on premises datasets and workloads scale, customers find it increasingly challenging and expensive due to the need to make upfront capital investments to keep up with performance needs of their workloads and avoid running out of storage capacity.

Today, we’re announcing the general availability of the Amazon FSx for Lustre Intelligent-Tiering, a new storage class that delivers virtually unlimited scalability, the only fully elastic Lustre file storage, and the lowest cost Lustre file storage in the cloud. With a starting price of less than $0.005 per GB-month, FSx for Lustre Intelligent-Tiering offers the lowest cost high-performance file storage in the cloud, reducing storage costs for infrequently accessed data by up to 96 percent compared to other managed Lustre options. Elasticity means you no longer need to provision storage capacity upfront because your file system will grow and shrink as you add or delete data, and you pay only for the amount of data you store.

FSx for Lustre Intelligent-Tiering automatically optimizes costs by tiering cold data to the applicable lower-cost storage tier based on access patterns and includes an optional SSD read cache to improve performance for your most latency sensitive workloads. Intelligent-Tiering delivers high performance whether you’re starting with gigabytes of experimental data or working with large petabyte-scale datasets for your most demanding artificial intelligence/machine learning (AI/ML) and HPC workloads. With the flexibility to adjust your file system’s performance independent of storage, Intelligent-Tiering delivers up to 34 percent better price performance than on premises HDD file systems. The Intelligent-Tiering storage class is optimized for HDD-based or mixed HDD/SSD workloads that have a combination of hot and cold data. You can migrate and run such workloads to FSx for Lustre Intelligent-Tiering without application changes, eliminating storage capacity planning and management, while paying only for the resources that you use.

Prior to this launch, customers used the FSx for Lustre SSD storage class to accelerate ML and HPC workloads that need all-SSD performance and consistent low-latency access to all data. However, many workloads have a combination of hot and cold data and they don’t need all-SSD storage for colder portions of the data. FSx for Lustre is increasingly used in AI/ML workloads to increase graphics processing unit (GPU) utilization, and now it’s even more cost optimized to be one of the options for these workloads.

FSx for Lustre Intelligent-Tiering
Your data moves between three storage tiers (Frequent Access, Infrequent Access, and Archive) with no effort on your part, so you get automatic cost savings with no upfront costs or commitments. The tiering works as follows:

Frequent Access – Data that has been accessed within the last 30 days is stored in this tier.

Infrequent Access – Data that hasn’t been accessed for 30 – 90 days is stored in this tier, at a 44 percent cost reduction from Frequent Access.

Archive – Data that hasn’t been accessed for 90 or more days is stored in this tier, at a 65 percent cost reduction compared to Infrequent Access.

Regardless of the storage tier, your data is stored across multiple AWS Availability Zones for redundancy and availability, compared to typical on-premises implementations, which are usually confined within a single physical location. Additionally, your data can be retrieved instantly in milliseconds.

Creating a file system
I can create a file system using the AWS Management Console, AWS Command Line Interface (AWS CLI), API, or AWS CloudFormation. On the console, I choose Create file system to get started.


I select Amazon FSx for Lustre and choose Next.


Now, it’s time to enter the rest of the information to create the file system. I enter a name (veliswa_fsxINT_1) for my file system, and for deployment and storage class, I select Persistent, Intelligent-Tiering. I choose the desired Throughput capacity and the Metadata IOPS. The SSD read cache will be automatically configured by FSx for Lustre based on the specified throughput capacity. I leave the rest as the default, choose Next, and review my choices to create my file system.

With Amazon FSx for Lustre Intelligent-Tiering, you have the flexibility to provision the necessary performance for your workloads without having to provision any underlying storage capacity upfront.


I wanted to know which values were editable after creation, so I paid closer attention before finalizing the creation of the file system. I noted that Throughput capacity, Metadata IOPS, Security groups, SSD read cache, and a few others were editable later. After I start running the ML jobs, it might be necessary to increase the throughput capacity based on the volumes of data I’ll be processing, so this information is important to me.

The file system is now available. Considering that I’ll be running HPC workloads, I anticipate that I’ll be processing high volumes of data later, so I’ll increase the throughput capacity to 24 GB/s. After all, I only pay for the resources I use.



The SSD read cache is scaled automatically as your performance needs increase. You can adjust the cache size any time independently in user-provisioned mode or disable the read cache if you don’t need low-latency access.


Good to know

  • FSx for Lustre Intelligent-Tiering is designed to deliver up to multiple terabytes per second of total throughput.
  • FSx for Lustre with Elastic Fabric Adapter (EFA)/GPU Direct Storage (GDS) support provides up to 12x (up to 1200 Gbps) higher per-client throughput compared to the previous FSx for Lustre systems.
  • It can deliver up to tens of millions of IOPS for writes and cached reads. Data in the SSD read cache has submillisecond time-to-first-byte latencies, and all other data has time-to-first-byte latencies in the range of tens of milliseconds.

Now available
Here are a couple of things to keep in mind:

FSx Intelligent-Tiering storage class is available in the new FSx for Lustre file systems in the US East (N. Virginia, Ohio), US West (N. California, Oregon), Canada (Central), Europe (Frankfurt, Ireland, London, Stockholm), and Asia Pacific (Hong Kong, Mumbai, Seoul, Singapore, Sydney, Tokyo) AWS Regions.

You pay for data and metadata you store on your file system (GB/months). When you write data or when you read data that is not in the SSD read cache, you pay per operation. You pay for the total throughput capacity (in MBps/month), metadata IOPS (IOPS/month), and SSD read cache size for data and metadata (GB/month) you provision on your file system. To learn more, visit the Amazon FSx for Lustre Pricing page. To learn more about Amazon FSx for Lustre including this feature, visit the Amazon FSx for Lustre page.

Give Amazon FSx for Lustre Intelligent-Tiering a try in the Amazon FSx console today and send feedback to AWS re:Post for Amazon FSx for Lustre or through your usual AWS Support contacts.

– Veliswa.

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

Enhance AI-assisted development with Amazon ECS, Amazon EKS and AWS Serverless MCP server

Post Syndicated from Elizabeth Fuentes original https://aws.amazon.com/blogs/aws/enhance-ai-assisted-development-with-amazon-ecs-amazon-eks-and-aws-serverless-mcp-server/

Today, we’re introducing specialized Model Context Protocol (MCP) servers for Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Serverless, now available in the AWS Labs GitHub repository. These open source solutions extend AI development assistants capabilities with real-time, contextual responses that go beyond their pre-trained knowledge. While Large Language Models (LLM) within AI assistants rely on public documentation, MCP servers deliver current context and service-specific guidance to help you prevent common deployment errors and provide more accurate service interactions.

You can use these open source solutions to develop applications faster, using up-to-date knowledge of Amazon Web Services (AWS) capabilities and configurations during the build and deployment process. Whether you’re writing code in your integrated development environment (IDE), or debugging production issues, these MCP servers support AI code assistants with deep understanding of Amazon ECS, Amazon EKS, and AWS Serverless capabilities, accelerating the journey from code to production. They work with popular AI-enabled IDEs, including Amazon Q Developer on the command line (CLI), to help you build and deploy applications using natural language commands.

  • The Amazon ECS MCP Server containerizes and deploys applications to Amazon ECS within minutes by configuring all relevant AWS resources, including load balancers, networking, auto-scaling, monitoring, Amazon ECS task definitions, and services. Using natural language instructions, you can manage cluster operations, implement auto-scaling strategies, and use real-time troubleshooting capabilities to identify and resolve deployment issues quickly.
  • For Kubernetes environments, the Amazon EKS MCP Server provides AI assistants with up-to-date, contextual information about your specific EKS environment. It offers access to the latest EKS features, knowledge base, and cluster state information. This gives AI code assistants more accurate, tailored guidance throughout the application lifecycle, from initial setup to production deployment.
  • The AWS Serverless MCP Server enhances the serverless development experience by providing AI coding assistants with comprehensive knowledge of serverless patterns, best practices, and AWS services. Using AWS Serverless Application Model Command Line Interface (AWS SAM CLI) integration, you can handle events and deploy infrastructure while implementing proven architectural patterns. This integration streamlines function lifecycles, service integrations, and operational requirements throughout your application development process. The server also provides contextual guidance for infrastructure as code decisions, AWS Lambda specific best practices, and event schemas for AWS Lambda event source mappings.

Let’s see it in action
If this is your first time using AWS MCP servers, visit the Installation and Setup guide in the AWS Labs GitHub repository to installation instructions. Once installed, add the following MCP server configuration to your local setup:

Install Amazon Q for command line and add the configuration to ~/.aws/amazonq/mcp.json. If you’re already an Amazon Q CLI user, add only the configuration.

{
  "mcpServers": {
    "awslabs.aws-serverless-mcp":  {
      "command": "uvx",
      "timeout": 60,
      "args": ["awslabs.aws_serverless_mcp_server@latest"],
    },
    "awslabs.ecs-mcp-server": {
      "disabled": false,
      "command": "uv",
      "timeout": 60,
      "args": ["awslabs.ecs-mcp-server@latest"],
    },
    "awslabs.eks-mcp-server": {
      "disabled": false,
      "timeout": 60,
      "command": "uv",
      "args": ["awslabs.eks-mcp-server@latest"],
    }
  }
}

For this demo I’m going to use the Amazon Q CLI to create an application that understands video using 02_using_converse_api.ipynb from Amazon Nova model cookbook repository as sample code. To do this, I send the following prompt:

I want to create a backend application that automatically extracts metadata and understands the content of images and videos uploaded to an S3 bucket and stores that information in a database. I'd like to use a serverless system for processing. Could you generate everything I need, including the code and commands or steps to set up the necessary infrastructure, for it to work from start to finish? - Use 02_using_converse_api.ipynb as example code for the image and video understanding.

Amazon Q CLI identifies the necessary tools, including the MCP serverawslabs.aws-serverless-mcp-server. Through a single interaction, the AWS Serverless MCP server determines all requirements and best practices for building a robust architecture.

I ask to Amazon Q CLI that build and test the application, but encountered an error. Amazon Q CLI quickly resolved the issue using available tools. I verified success by checking the record created in the Amazon DynamoDB table and testing the application with the dog2.jpeg file.

To enhance video processing capabilities, I decided to migrate my media analysis application to a containerized architecture. I used this prompt:

I'd like you to create a simple application like the media analysis one, but instead of being serverless, it should be containerized. Please help me build it in a new CDK stack.

Amazon Q Developer begins building the application. I took advantage of this time to grab a coffee. When I returned to my desk, coffee in hand, I was pleasantly surprised to find the application ready. To ensure everything was up to current standards, I simply asked:

please review the code and all app using the awslabsecs_mcp_server tools 

Amazon Q Developer CLI gives me a summary with all the improvements and a conclusion.

I ask it to make all the necessary changes, once ready I ask Amazon Q developer CLI to deploy it in my account, all using natural language.

After a few minutes, I review that I have a complete containerized application from the S3 bucket to all the necessary networking.

I ask Amazon Q developer CLI to test the app send it the-sea.mp4 video file and received a timed out error, so Amazon Q CLI decides to use the fetch_task_logs from awslabsecs_mcp_server tool to review the logs, identify the error and then fix it.

After a new deployment, I try it again, and the application successfully processed the video file

I can see the records in my Amazon DynamoDB table.

To test the Amazon EKS MCP server, I have code for a web app in the auction-website-main folder and I want to build a web robust app, for that I asked Amazon Q CLI to help me with this prompt:

Create a web application using the existing code in the auction-website-main folder. This application will grow, so I would like to create it in a new EKS cluster

Once the Docker file is created, Amazon Q CLI identifies generate_app_manifests from awslabseks_mcp_server as a reliable tool to create a Kubernetes manifests for the application.

Then create a new EKS cluster using the manage_eks_staks tool.

Once the app is ready, the Amazon Q CLI deploys it and gives me a summary of what it created.

I can see the cluster status in the console.

After a few minutes and resolving a couple of issues using the search_eks_troubleshoot_guide tool the application is ready to use.

Now I have a Kitties marketplace web app, deployed on Amazon EKS using only natural language commands through Amazon Q CLI.

Get started today
Visit the AWS Labs GitHub repository to start using these AWS MCP servers and enhance your AI-powered developmen there. The repository includes implementation guides, example configurations, and additional specialized servers to run AWS Lambda function, which transforms your existing AWS Lambda functions into AI-accessible tools without code modifications, and Amazon Bedrock Knowledge Bases Retrieval MCP server, which provides seamless access to your Amazon Bedrock knowledge bases. Other AWS specialized servers in the repository include documentation, example configurations, and implementation guides to begin building applications with greater speed and reliability.

To learn more about MCP Servers for AWS Serverless and Containers and how they can transform your AI-assisted application development, visit the Introducing AWS Serverless MCP Server: AI-powered development for modern applications, Automating AI-assisted container deployments with the Amazon ECS MCP Server, and Accelerating application development with the Amazon EKS MCP server deep-dive blogs.

— Eli

Introducing AWS Serverless MCP Server: AI-powered development for modern applications

Post Syndicated from Shridhar Pandey original https://aws.amazon.com/blogs/compute/introducing-aws-serverless-mcp-server-ai-powered-development-for-modern-applications/

Modern application development demands faster, more efficient ways to build and deploy software. Over the past decade, serverless computing has emerged as a transformative approach to software development, enabling developers to focus on building applications without having to manage the underlying infrastructure. As developers build their applications using AWS Serverless Compute, they seek guidance on selecting appropriate services, understanding best practices, and implementation patterns to make the most of this paradigm.

Today, AWS announces the open-source AWS Serverless Model Context Protocol (MCP) Server, a tool that combines the power of AI assistance with serverless expertise to enhance how developers build modern applications. The Serverless MCP Server provides contextual guidance specific to serverless development, helping developers make informed decisions about architecture, implementation, and deployment.

This post describes how the Serverless MCP Server works with AI coding assistants to streamline serverless development. Learn how to use this solution to accelerate your serverless development workflow and build robust, high-performing applications more efficiently.

Overview 

Serverless computing enables development teams to significantly reduce time-to-market while improving operational efficiency. Developers can focus on creating business value, while AWS services automatically handle scaling, availability, and infrastructure maintenance. AWS Lambda provides a seamless compute service where code runs in response to events, scaling instantly from a few requests per day to thousands per second. Through integration with over 200 AWS services, Lambda enables developers to build sophisticated applications using triggers from Amazon API Gateway, Amazon S3, Amazon DynamoDB, and many others. Whether you’re building data processing pipelines, real-time stream processing, or web applications, Lambda’s support for popular programming languages and development frameworks helps development teams leverage their existing skills while embracing the serverless paradigm.

MCP Server

MCP is an open protocol for AI agents to interact with external tools and data sources. It defines how AI assistants can discover, understand, and use various capabilities provided by external systems. This protocol allows AI models to extend their functionality beyond their own training data by accessing real-time information and executing specific tasks through standardized interfaces.

MCP servers implement this protocol by providing tools, resources, and contextual information that AI assistants can use via MCP clients. They serve as a knowledge bridge that gives AI assistants, such as Amazon Q Developer, Cline, and Cursor, the additional context needed to make informed decisions about cloud architecture and implementation. This is particularly valuable for serverless applications, where developers navigate multiple services, event patterns, and integration points to build scalable, performant applications.

AWS currently offers the AWS Lambda Tool MCP Server, which allows AI models to directly interact with existing Lambda functions as MCP tools without any code changes. This MCP server acts as a bridge between MCP clients and Lambda functions, allowing AI assistants to access and invoke Lambda functions.

Serverless MCP Server

The open-source AWS Serverless MCP launched today enhances the serverless development experience by providing AI coding assistants with comprehensive knowledge of serverless patterns, best practices, and AWS services. This MCP server acts as an intelligent companion, guiding developers through the entire application development lifecycle, from initial design to deployment, offering contextual assistance at each stage.

The new Serverless MCP server provides tools that cover many areas of serverless development. During the initial planning and setup phase, the MCP server helps developers initialize new projects using AWS Serverless Application Model (AWS SAM) templates, select appropriate Lambda runtimes, and set up project dependencies. This enables developers to quickly bootstrap new serverless applications with the right configuration and structure.

As development progresses, the MCP server assists with building and deploying serverless applications. It provides tools for local testing, building deployment artifacts, and managing deployments. For web applications, the MCP server offers specialized support for deploying backend, frontend, or full-stack applications, and setting up custom domains.

The MCP server also emphasizes operational excellence through comprehensive observability tools, helping developers to effectively monitor application performance and troubleshoot issues. Throughout the development process, the server provides contextual guidance for infrastructure as code (IaC) decisions, Lambda-specific best practices, and event schemas for Lambda event source mappings (ESMs).

Serverless MCP Server in action

To demonstrate the capabilities of the Serverless MCP Server, this example walks you through a scenario of creating, deploying, and troubleshooting a serverless application.

Prerequisites and installation

To get started, download the AWS Serverless MCP Server from GitHub or Python Package Index (PyPi) and follow the installation instructions. You can use this MCP server with any AI coding assistant of your choice, such as Q Developer, Cursor, Cline, etc. The walkthrough example in this post uses Cline.

Add the following code to your MCP client configuration. The Serverless MCP Server uses the default AWS profile by default. Specify a value in AWS_PROFILE if you want to use a different profile. Similarly, adjust the AWS Region and log level values as needed.

{
  "mcpServers": {
    "awslabs.aws-serverless-mcp": {
      "command": "uvx",
      "args": [
        "awslabs.aws_serverless_mcp_server@latest"
      ],
      "env": { 
        "AWS_PROFILE": "your-aws-profile",
        "AWS_REGION": "us-east-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

The Serverless MCP Server incorporates built-in guardrails to ensure secure and controlled development. By default, the MCP server operates in a read-only mode, allowing only non-mutating actions. This safety-first approach allows you to explore serverless capabilities and architectural patterns while preventing unintended changes to your applications or infrastructure. The server also restricts access to Amazon CloudWatch Logs by default, protecting sensitive operational data from exposure to AI assistants.

As your development needs evolve, you can selectively override these security defaults. The --allow-write flag enables mutating operations for tasks such as deployments and updates, while --allow-sensitive-data-access provides access to CloudWatch Logs for debugging and troubleshooting. Consider enabling these permissions only when necessary and in appropriate development contexts.

Creating and deploying a serverless application

Imagine that you want to build a to-do list web application. Start by prompting your AI assistant.

I want to build a new to-do list web application in a new workspace. I want to add, list, and delete to-dos. Would AWS Lambda be a good choice for this?

The agent uses the get_lambda_guidance_tool to receive tailored guidance based on the use case and the inferred event source, API Gateway in this case. Then, you want to better understand how to deploy the application to AWS.

I later want to deploy the application to AWS. Which Infrastructure as Code tool would be best for this?

There are several ways to deploy your functions to AWS such as AWS SAM or the AWS Cloud Development Kit (AWS CDK). The model opts to get more information before making a recommendation. It selects the get_iac_guidance_tool from the Serverless MCP Server.

The Serverless MCP Server can also assist you with interacting with the AWS Serverless Application Model Command Line Interface (AWS SAM CLI) as well as deploying application-based blueprints such as backend, frontend, or full-stack applications.

Before the deployment, test the function locally to verify that it works correctly.

I want to test my Lambda function locally before deploying it. Can you invoke the “TodoFunction” from my SAM project with a GET request?

Now that you are confident that the application works, you want to deploy the backend logic to AWS. So, you prompt the agent to deploy your app. It selects the deploy_webapp tool and provides the tool with arguments to deploy the app, including backend deploymentType. This tool uses the AWS Lambda Web Adapter framework, allowing you to easily deploy applications written in standard web frameworks like Express or Next.js, without any additional web adapters.

The agent can also check on the status of a deployment to make sure that it completes successfully.

Your application is now deployed to AWS and ready to serve traffic.

Troubleshooting the serverless application

The Serverless MCP Server also supports you in testing and troubleshooting your Lambda functions. It provides valuable context to AI assistants in identifying and remediating issues. For example, you can use your agent to check for any issues with your application.

Check the logs and metrics of the todo app for any issues

The model can analyze the logs and metrics and offer recommendations such as adjusting memory allocation.

The Serverless MCP Server tools provide the assistant with the additional context it needs to identify issues and generate recommendations.

In this example, the analysis and recommendations are:

Log Analysis

I’ve checked the logs for all three Lambda functions of your todo app, looking specifically for errors:

• ListTodosFunction: No errors detected
• AddTodoFunction: No errors detected
• DeleteTodoFunction: No errors detected

All functions are operating normally with successful executions and no error logs.

Performance Metrics

Lambda Function Performance
• Memory usage is reasonable at 100–106 MB out of 512 MB allocated (about 20% utilization)
• Fast execution durations for warm starts: 85–195 ms range
• No throttling or out-of-memory errors detected
• No function errors or exceptions in the logs

API Gateway Metrics
• Total Requests: 11 requests recorded
• Average Latency: 797 ms
• P95 Latency: 3364 ms (high)
• 4XX Errors: 0 (no client errors)
• 5XX Errors: 1 (one server error detected)

Issues Identified

The log analysis is clean with no errors, but the metrics reveal one potential issue:

  1. One 5XX Error in API Gateway: There was a single server-side error recorded in the API Gateway logs. Since there are no corresponding errors in the Lambda function logs, this might be related to:
    • A timeout (API Gateway taking too long to respond)
    • An integration issue between API Gateway and Lambda
    • A temporary network issue
  2. Relatively High P95 Latency: The 95th percentile latency of 3364 ms is quite high compared to the average. This suggests some outlier requests are taking significantly longer to complete.

Recommendations

  1. Monitor the 5XX error rate as it resurfaces.
  2. Consider implementing more detailed logging at the edge of the error path.
  3. Investigate the cause of the high P95 latency. Check for cold starts, payload size, or network latency as likely culprits.
  4. Consider enabling API Gateway and Lambda performance dashboards for more granular, historical latency and error metrics.
  5. Continue to monitor memory and duration metrics to ensure performance remains healthy as traffic increases.

Features supported by the Serverless MCP Server

The Serverless MCP Server provides several MCP tools, which can be classified into four categories.

  1. Serverless application lifecycle
    • sam_init_tool: Initializes a new AWS SAM project with the chosen runtime and dependencies.
    • sam_build_tool: Builds a serverless application using the AWS SAM CLI and prepares deployment artifacts.
    • sam_deploy_tool: Deploys a serverless application to AWS, managing artifact upload and stack creation.
    • sam_local_invoke_tool: Locally invokes a Lambda function for testing with custom events and environments.
  2. Web application deployment and management
    • deploy_webapp_tool: Deploys backend, frontend, or fullstack web applications to Lambda using the Lambda Web Adapter.
    • update_frontend_tool: Updates the frontend assets and optionally invalidates the Amazon CloudFront cache.
    • configure_domain_tool: Configures a custom domain, includes certificate and DNS setup.
  3. Observability
    • sam_logs_tool: Retrieves logs, and supports filtering and time range selection.
    • get_metrics_tool: Fetches specified metrics.
  4. Guidance, IaC templates, and deployment help
    • get_iac_guidance_tool: Provides guidance for selecting IaC tools.
    • get_lambda_guidance_tool: Offers advice on when to use Lambda for specific runtimes and use cases.
    • get_lambda_event_schemas_tool: Returns event schemas for Lambda integrations.
    • get_serverless_templates_tool: Supplies example AWS SAM templates for different serverless application types.
    • deployment_help_tool: Provides help and status information about deployments.
    • deploy_serverless_app_help_tool: Offers instructions for deploying serverless applications to Lambda.

Visit the Serverless MCP Server documentation for the full list of tools and resources.

Best practices and considerations

When building serverless applications with the AWS Serverless MCP Server, start by using its AI-assisted guidance for architectural decisions. Throughout development, use its guidance tools to make informed decisions about service selection, event patterns, and infrastructure design. Before deploying to AWS, use the Serverless MCP Server’s local testing capabilities to validate your application’s behavior. This approach helps ensure your application aligns with AWS best practices.

Robust monitoring and observability are critical to reliably operate your applications running in production. Use the Serverless MCP Server tools for deployment monitoring and setting up logging and metrics. This helps track application performance and quickly identify potential issues.

Conclusion

The open-source AWS Serverless MCP Server streamlines serverless application development by providing AI-assisted guidance throughout the development lifecycle. By combining AI assistance with serverless expertise, it enables developers to build and deploy applications more efficiently. The Serverless MCP Server’s toolset supports the complete development process, from initialization to observability, while helping developers implement AWS best practices.

As organizations continue to adopt serverless computing, tools that streamline development and accelerate delivery become increasingly valuable. AWS will continue to expand the collection of MCP servers for developers building serverless applications and refine existing tools based on customer feedback and emerging serverless development patterns.

To get started, visit the GitHub repository and explore the documentation. Share your experiences and suggestions through the GitHub repository to improve the MCP server’s capabilities and help shape the future of AI-assisted serverless development.

For more serverless learning resources, visit Serverless Land.

Modernizing applications with AWS AppSync Events

Post Syndicated from Ricardo Marques original https://aws.amazon.com/blogs/compute/modernizing-applications-with-aws-appsync-events/

In today’s fast-paced digital world, organizations are facing challenges for modernizing their applications. A common problem is the smooth shift from synchronous to asynchronous communication without substantial client or frontend alterations. When modernizing applications, it is often necessary to move from a synchronous communication model to an asynchronous one. However, this transition can be complex, especially when the client or frontend communicates synchronously. Adapting the current code for asynchronous communication demands significant time and resources.

AWS AppSync Events helps address this challenge by enabling you to build event-driven APIs that can bridge between synchronous and asynchronous communication models. With AppSync Events, you can modernize your backend architecture to leverage asynchronous patterns while maintaining compatibility with existing synchronous clients.

Overview

The solution comprises an API that converts client synchronous requests to asynchronous backend requests using AppSync Events.

For demonstrating the integration between the API and the backend, I’m simulating the backend processing using an asynchronous AWS Step Functions workflow. This workflow receives a Name and Surname event, waits 10 seconds, and posts a full-name event to the AppSync Event channel. To receive event notifications, the API subscribes to the AppSync channel. At the same time, the backend handles events asynchronously.

Figure 1: Representation of an API integrating a synchronous frontend with an asynchronous backend using AWS AppSync Events.

Figure 1: Representation of an API integrating a synchronous frontend with an asynchronous backend using AWS AppSync Events.

  1. The Amazon API Gateway makes a synchronous request to AWS Lambda and waits for the response.
  2. Lambda function starts the execution of the asynchronous workflow.
  3. After starting the workflow execution, Lambda connects to AppSync and creates a channel to receive asynchronous notifications (channels are ephemeral and unlimited. Here it creates one channel per request using the workflow execution ID).
  4. The workflow executes asynchronously, calling other workflows.
  5. Upon completion of the main workflow, it sends a POST request to the AppSync events API with the processing result. The POST is made to the channel that was created by the Lambda function using the workflow execution ID.
  6. AppSync receives the POST request and sends a notification to the subscriber, which in this case is the Lambda function. The entire process must be finished within the Lambda functions’s timeout limit you defined.
  7. Lambda sends the response to the API Gateway, which has been waiting for the synchronous response.

To better understand the Event API WebSocket Protocol used in this solution, refer to this AppSync documentation.

You can access the GitHub repo through this link: AppSync_Sync_Async_Integration.

The repository includes a comprehensive README file that walks you through the process of setting up and configuring the preceding solution.

Prerequisites

To follow this walkthrough, you need the following prerequisites:

With the full code, including API Gateway and Step Functions, on GitHub, this post only covers the core components: the AppSync Events API and the Lambda function.

Walkthrough

The following steps walk you through this solution.

Creating an AppSync event API with API Key Authorization

An AppSync Event API allows calls using API key, Amazon Cognito user pools, Lambda authorizer, OIDC, or AWS identity and Access Management (IAM). This solution uses API Key.

The infrastructure as code (IaC) has been created using Terraform. However, as of writing this post, there weren’t Terraform AppSync Event API resource available. Therefore, the AppSync Event API resources were made with AWS CloudFormation, which is imported and implemented by Terraform.

In the resource AWS:AppSync:Api, define the API name and Auth method:

Resources:
  #Creating the AppSync Events API
  EventAPI:
    Type: AWS::AppSync::Api
    Properties:
      Name: SyncAsyncAPI
      EventConfig:
        AuthProviders:
          - AuthType: API_KEY
        ConnectionAuthModes:
          - AuthType: API_KEY
        DefaultPublishAuthModes:
          - AuthType: API_KEY
        DefaultSubscribeAuthModes:
          - AuthType: API_KEY
#Creating the Events API Namespace
  DefaultNamespace:
    Type: AWS::AppSync::ChannelNamespace
    Properties:
      Name: AsyncEvents
      ApiId: !GetAtt EventAPI.ApiId
  
  #Creating the Events API APIKey
  EventAPIKey:
    Type: AWS::AppSync::ApiKey
    Properties:
      ApiId: !GetAtt EventAPI.ApiId
      Expires: 1748950672
      Description: 'API Key for Event API'

  #Creating the SecretsManager to store the APIKey
  SecretsManagerAPIKey:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: 'AppSyncEventAPIKEY'
      SecretString: !GetAtt EventAPIKey.ApiKey

To have the Host DNS, Realtime Endpoint, and Secret Manager created referenced by the Terraform template, output them:

Outputs:
  ApiARN:
    Description: 'The ARN ID'
    Value: !GetAtt EventAPI.ApiArn

  AppSyncHost:
    Description: 'The API Endpoint'
    Value: !GetAtt EventAPI.Dns.Http

  AppSyncRealTimeEndpoint:
    Description: 'The Real-time Endpoint'
    Value: !GetAtt EventAPI.Dns.Realtime

  SecretsManagerARN:
    Description: 'The ARN of the Secrets Manager entry'
    Value: !Ref SecretsManagerAPIKey

The key information needed from the AppSync Event API is:

  1. Host DNS: This DNS is used to send events to the API Channel through HTTP Post requests.
  2. Realtime endpoint: This endpoint is a WebSocket endpoint where the Lambda function connects to receive the events posted in the AppSync Channel.
  3. API Key: This key is used not only in the Post HTTP requests, but also to connect and subscribe to the AppSync channel.

Lambda Sync/Async API

In this solution, the Lambda function runs two tasks:

  1. Start an asynchronous workflow
  2. Subscribe to an event channel through WebSocket

To handle the WebSocket connection, use the websocket-client lib, which is a powerful Python lib developed for working with WebSockets.

Request isolation is maintained by using the same UUID for workflow name and AppSync channel name.

try:
        handler = WebSocketHandler()
        sfn_response = wf.start_workflow_async(event["body"])
        
        if sfn_response["status"] == "started":
            handler.execution_name = sfn_response["id"]
            handler.start_websocket_connection()
            
            return {
                'statusCode': 200,
                'body': json.dumps({ 
                        "id": handler.execution_name,
                        "nome completo": handler.final_name
                        })
            }
        else:
            raise ValueError("Workflow failed to start")

First, to initialize the WebSocket Connection, the subprotocols must be defined:

  • WEBSOCKET_PROTOCOL
  • Headers:
    • Host: The AppSync Host DNS (even with a WebSocket Connection, the HTTP Host must be sent)
    • x-api-key: The API key create fot the Event API.
    • Sec-Websocket-Protocol: WEBSOCKET_PROTOCOL
def start_websocket_connection(self) -> None:
        try: 
            """Initialize and start WebSocket connection."""
            header_str = self._create_connection_header()
            
            self.ws = websocket.WebSocketApp(
                os.environ["API_URL"],
                subprotocols=[WEBSOCKET_PROTOCOL, f'header-{header_str}'],
                on_open=self.on_open,
                on_message=self.on_message,
                on_error=self.on_error,
                on_close=self.on_close
)
            self.ws.run_forever()
        except Exception as e:
            return e
def _create_connection_header(self) -> str:
        """Create and encode connection header."""
        connection_header = {
            "host": os.environ["API_HOST"],
            "x-api-key": APIKEY,
            "Sec-WebSocket-Protocol": WEBSOCKET_PROTOCOL
        }
        return base64.b64encode(json.dumps(connection_header).encode()).decode()

Once the WebSocket connection is established, a first message with the type CONNECTION_INIT_TYPE must be sent.

To subscribe to the channel by which our function is notified when the Step Functions workflow finishes, send a second message with the type SUBSCRIBE_TYPE, an ID, the channel name and authorization.

For more information about types of message, read this AppSync documentation.

def on_open(self, ws: websocket.WebSocketApp) -> None:
        try:
            """Handle WebSocket connection opening and send initial messages."""
            logger.info("Connection opened")
            
            # Send connection initialization
            connection_init = {"type": CONNECTION_INIT_TYPE}
            ws.send(json.dumps(connection_init))

            # Send subscription
            subscription_msg = {
                "type": SUBSCRIBE_TYPE,
                "id": self.execution_name,
                "channel": f"{os.environ["APPSYNC_NAMESPACE"]}/{self.execution_name}",
                "authorization": {
                    "x-api-key": APIKEY,
                    "host": os.environ["API_HOST"]
                }
            }
            
            logger.info("Sending subscription")
            ws.send(json.dumps(subscription_msg))
        except Exception as e:
            self.on_error = e

After receiving the message confirming the subscription, wait for messages with the type data. Whenever a message with this type arrives, execute the logic to identify if the workflow was successfully executed, and then close the connection.

def on_message(self, ws: websocket.WebSocketApp, message: str) -> None:
        """Handle incoming WebSocket messages."""
        logger.info("Message received: %s", message)
        try:
            message_dict = json.loads(message)
            required_keys = ["id", "type", "event"]
            
            if all(key in message_dict for key in required_keys):
                event_json = json.loads(message_dict["event"])
                
                if (message_dict["id"] == self.execution_name and 
                    message_dict["type"] == "data"):
                    
                    self.final_name = event_json["nome_completo"]
                    logger.info("Message received: %s", self.final_name)
                    logger.info("Successfully received return message")
                    logger.info("Ending processing")
                    
                    self.message_queue = {
                        "status": SUCCESS_STATUS,
                        "executionID": message_dict["id"]
                    }
                    ws.close()
        except json.JSONDecodeError as e:
            logger.error("Failed to parse message: %s", str(e))
        except Exception as e:
            logger.error("Error processing message: %s", str(e))

Conclusion

In this post, you learned how to use event-driven architectures and the capabilities of AWS AppSync Events to integrate synchronous and asynchronous communication patterns in your applications. This allows you to modernize your systems without the need for extensive modifications to your existing frontend codebase. Explore the demonstrations and documentation provided in the GitHub repository to gain a deeper understanding of how AppSync Events can be applied to your specific use cases.

To learn more about serverless architectures and asynchronous invocation patterns, see Serverless Land.

The collective thoughts of the interwebz