Cloudflare 1.1.1.1 Incident on July 14, 2025

Post Syndicated from Ash Pallarito original https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/

On 14 July 2025, Cloudflare’s 1.1.1.1 Resolver service became unavailable to the Internet starting at 21:52 UTC and ending at 22:54 UTC. The majority of 1.1.1.1 users globally were affected. For many users, not being able to resolve names using the 1.1.1.1 Resolver meant that basically all Internet services were unavailable. This outage can be observed on Cloudflare Radar.

The outage occurred because of a misconfiguration of legacy systems used to maintain the infrastructure that advertises Cloudflare’s IP addresses to the Internet.

This was a global outage. During the outage, Cloudflare’s 1.1.1.1 Resolver was unavailable worldwide.

We’re very sorry for this outage. The root cause was an internal configuration error and not the result of an attack or a BGP hijack. In this blog, we’re going to talk about what the failure was, why it occurred, and what we’re doing to make sure this doesn’t happen again.

Background

Cloudflare introduced the 1.1.1.1 public DNS Resolver service in 2018. Since the announcement, 1.1.1.1 has become one of the most popular DNS Resolver IP addresses and it is free for anyone to use.

Almost all of Cloudflare’s services are made available to the Internet using a routing method known as anycast, a well-known technique intended to allow traffic for popular services to be served in many different locations across the Internet, increasing capacity and performance. This is the best way to ensure we can globally manage our traffic, but also means that problems with the advertisement of this address space can result in a global outage.   

Cloudflare announces these anycast routes to the Internet in order for traffic to those addresses to be delivered to a Cloudflare data center, providing services from many different places. Most Cloudflare services are provided globally, like the 1.1.1.1 public DNS Resolver, but a subset of services are specifically constrained to particular regions. 

These services are part of our Data Localization Suite (DLS), which allows customers to configure Cloudflare in a variety of ways to meet their compliance needs across different countries and regions. One of the ways in which Cloudflare manages these different requirements is to make sure the right service’s IP addresses are Internet-reachable only where they need to be, so your traffic is handled correctly worldwide. A particular service has a matching “service topology” – that is, traffic for a service should be routed only to a particular set of locations.

On June 6, during a release to prepare a service topology for a future DLS service, a configuration error was introduced: the prefixes associated with the 1.1.1.1 Resolver service were inadvertently included alongside the prefixes that were intended for the new DLS service. This configuration error sat dormant in the production network as the new DLS service was not yet in use,  but it set the stage for the outage on July 14. Since there was no immediate change to the production network there was no end-user impact, and because there was no impact, no alerts were fired.

Incident Timeline

Time (UTC)

Event

2025-06-06 17:38

ISSUE INTRODUCED – NO IMPACT

A configuration change was made for a DLS service that was not yet in production. This configuration change accidentally included a reference to the 1.1.1.1 Resolver service and, by extension, the prefixes associated with the 1.1.1.1 Resolver service.

This change did not result in a change of network configuration, and so routing for the 1.1.1.1 Resolver was not affected.

Since there was no change in traffic, no alerts fired, but the misconfiguration lay dormant for a future release. 

2025-07-14 21:48

IMPACT START

A configuration change was made for the same DLS service. The change attached a test location to the non-production service; this location itself was not live, but the change triggered a refresh of network configuration globally.

Due to the earlier configuration error linking the 1.1.1.1 Resolver’s IP addresses to our non-production service, those 1.1.1.1 IPs were inadvertently included when we changed how the non-production service was set up.

The 1.1.1.1 Resolver prefixes started to be withdrawn from production Cloudflare data centers globally.

2025-07-14 21:52

DNS traffic to 1.1.1.1 Resolver service begins to drop globally

2025-07-14 21:54

Related, non-causal event: BGP origin hijack of 1.1.1.0/24 exposed by withdrawal of routes from Cloudflare. This was not a cause of the service failure, but an unrelated issue that was suddenly visible as that prefix was withdrawn by Cloudflare. 

2025-07-14 22:01

IMPACT DETECTED

Internal service health alerts begin to fire for the 1.1.1.1 Resolver

2025-07-14 22:01

INCIDENT DECLARED

2025-07-14 22:20

FIX DEPLOYED

Revert was initiated to restore the previous configuration. To accelerate full restoration of service, a manually triggered action is validated in testing locations before being executed.

2025-07-14 22:54

IMPACT ENDS

Resolver alerts cleared and DNS traffic on Resolver prefixes return to normal levels

2025-07-14 22:55

INCIDENT RESOLVED

Impact

Any traffic coming to Cloudflare via 1.1.1.1 Resolver services on these IPs was impacted. Traffic to each of these addresses were also impacted on the corresponding routes. 

1.1.1.0/24
1.0.0.0/24 
2606:4700:4700::/48
162.159.36.0/24
162.159.46.0/24
172.64.36.0/24
172.64.37.0/24
172.64.100.0/24
172.64.101.0/24
2606:4700:4700::/48
2606:54c1:13::/48
2a06:98c1:54::/48

When the impact started we observed an immediate and significant drop in queries over UDP, TCP and DNS over TLS (DoT). Most users have 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, or 2606:4700:4700::1001 configured as their DNS server. Below you can see the query rate for each of the individual protocols and how they were impacted during the incident:


It’s worth noting that DoH (DNS-over-HTTPS) traffic remained relatively stable as most DoH users use the domain cloudflare-dns.com, configured manually or through their browser, to access the public DNS resolver, rather than by IP address. DoH remained available and traffic was mostly unaffected as cloudflare-dns.com uses a different set of IP addresses. Some DNS traffic over UDP that also used different IP addresses remained mostly unaffected as well.

As the corresponding prefixes were withdrawn, no traffic sent to those addresses could reach Cloudflare. We can see this in the timeline for the BGP announcements for 1.1.1.0/24:


Pictured above is the timeline for BGP withdrawal and re-announcement of 1.1.1.0/24 globally

When looking at the query rate of the withdrawn IPs it can be observed that almost no traffic arrives during the impact window. When the initial fix was applied at 22:20 UTC, a large spike in traffic can be seen before it drops off again. This spike is due to clients retrying their queries. When we started announcing the withdrawn prefixes again, queries were able to reach Cloudflare once more. It took until 22:54 UTC before routing was restored in all locations and traffic returned to mostly normal levels.



Technical description of the error and how it happened

Failure of 1.1.1.1 Resolver Service

As described above, a configuration change on June 6 introduced an error in the service topology for a pre-production, DLS service. On July 14, a second change to that service was made: an offline data center location was added to the service topology for the pre-production DNS service in order to allow for some internal testing. This change triggered a refresh of the global configuration of the associated routes, and it was at this point that the impact from the earlier configuration error was felt. The service topology for the 1.1.1.1 Resolver’s prefixes was reduced from all locations down to a single, offline location. The effect was to trigger the global and immediate withdrawal of all 1.1.1.1 prefixes.

As routes to 1.1.1.1 were withdrawn, the 1.1.1.1 service itself became unavailable. Alerts fired and an incident was declared.

Technical Investigation and Analysis

The way that Cloudflare manages service topologies has been refined over time and currently consist of a combination of a legacy and a strategic system that are synced. Cloudflare’s IP ranges are currently bound and configured across these systems that  dictate where an IP range should be announced (in terms of datacenter location) on the edge network. The legacy approach of hard-coding explicit lists of data center locations and attaching them to particular prefixes has proved error-prone, since (for example) bringing a new data center online requires many different lists to be updated and synced consistently. This model also has a significant flaw in that updates to the configuration do not follow a progressive deployment methodology: Even though this release was peer-reviewed by multiple engineers, the change didn’t go through a series of canary deployments before reaching every Cloudflare data center. Our newer approach is to describe service topologies without needing to hard-code IP addresses, which better accommodate expansions to new locations and customer scenarios while also allowing for a staged deployment model, so changes can propagate slowly with health monitoring. During the migration between these approaches, we need to maintain both systems and synchronize data between them, which looks like this:


Initial alerts were triggered for the DNS Resolver at 22:01, indicating query, proxy, and data center failures. While investigating the alerts, we noted traffic toward the Resolver prefixes had drastically dropped and was no longer being received at our edge data centers. Internally, we use BGP to control route advertisements, and we found the Resolver routes from servers were completely missing.

Once our configuration error had been exposed and Cloudflare systems had withdrawn the routes from our routing table, all of the 1.1.1.1 routes should have disappeared entirely from the global Internet routing table. However, this isn’t what happened with the prefix 1.1.1.0/24. Instead, we got reports from Cloudflare Radar that Tata Communications India (AS4755) had started advertising 1.1.1.0/24: from the perspective of the routing system, this looked exactly like a prefix hijack. This was unexpected to see while we were troubleshooting the routing problem, but to be perfectly clear: this BGP hijack was not the cause of the outage. We are following up with Tata Communications.

Restoring the 1.1.1.1 Service

We reverted to the previous configuration at 22:20 UTC. Near instantly, we began readvertising the BGP prefixes which were previously withdrawn from the routers, including 1.1.1.0/24. This restored 1.1.1.1 traffic levels to roughly 77% of what they were prior to the incident. However, during the period since withdrawal, approximately 23% of the fleet of edge servers had been automatically reconfigured to remove required IP bindings as a result of the topology change. To add the configurations back, these servers needed to be reconfigured with our change management system which is not an instantaneous process by default for safety. 

The process by which the IP bindings can be restored normally takes some time, as the network in individual locations is designed to be updated over a course of multiple hours. We implement a progressive rollout, rather than on all nodes at once to ensure we don’t introduce additional impact. However, given the severity of the incident, we accelerated the rollout of the fix after verifying the changes in testing locations to restore service as quickly and safely as possible. Normal traffic levels were observed at 22:54 UTC.

Remediation and follow-up steps

We take incidents like this seriously, and we recognise the impact that this incident had. Though this specific issue has been resolved, we have identified several steps we can take to mitigate the risk of a similar problem occurring in the future. We are implementing the following plan as a result of this incident:

Staging Addressing Deployments: Legacy components do not leverage a gradual, staged deployment methodology. Cloudflare will deprecate these systems which enables modern progressive and health mediated deployment processes to provide earlier indication in a staged manner and rollback accordingly.

Deprecating Legacy Systems: We are currently in an intermediate state in which current and legacy components need to be updated concurrently, so we will be migrating addressing systems away from risky deployment methodologies like this one. We will accelerate our deprecation of the legacy systems in order to provide higher standards for documentation and test coverage.

Conclusion

Cloudflare’s 1.1.1.1 DNS Resolver service fell victim to an internal configuration error.

We are sorry for the disruption this incident caused for our customers. We are actively making these improvements to ensure improved stability moving forward and to prevent this problem from happening again.

Cloudflare recognized as a Visionary in 2025 Gartner® Magic Quadrant™ for SASE Platforms

Post Syndicated from Abe Carryl original https://blog.cloudflare.com/cloudflare-sase-gartner-magic-quadrant-2025/

We are thrilled to announce that Cloudflare has been named a Visionary in the 2025 Gartner® Magic Quadrant™ for Secure Access Service Edge (SASE) Platforms1 report. We view this evaluation as a significant recognition of our strategy to help connect and secure workspace security and coffee shop networking through our unique connectivity cloud approach. You can read more about our position in the report here.

Since launching Cloudflare One, our SASE platform, we have delivered hundreds of features and capabilities from our lightweight branch connector and intuitive native Data Loss Prevention (DLP) service to our new secure infrastructure access tools. By operating the world’s most powerful, programmable network we’ve built an incredible foundation to deliver a comprehensive SASE platform. 

Today, we operate the world’s most expansive SASE network in order to deliver connectivity and security close to where users and applications are, anywhere in the world. We’ve developed our services from the ground up to be fully integrated and run on every server across our network, delivering a unified experience to our customers. And we enable these services with a unified control plane, enabling end-to-end visibility and control anywhere in the world. Tens of thousands of customers trust Cloudflare with their network and security infrastructure.

We’re thrilled with our inclusion in this report and are even more excited that we’re only just getting started. Building on this foundation, we’re investing to move even faster to solve problems for our customers.

What is SASE?

SASE (pronounced “sassy”) is an architectural model that delivers network connectivity and security functions, and delivers them through a single cloud platform and/or centralized policy control.

Given the extent of what organizations need for networking and security, not all SASE capabilities may be available from a single vendor. For example, the security-as-a-service model is sometimes consumed as a part of Security Service Edge (SSE).

The evolution of this architecture, where a vendor delivers key functionality across networking and security service in a single offering, is SASE. What’s important to note, however, is that convergence can mean many, many different things. For example, some vendors started with SSE capabilities and are building out infrastructure to support it. Some vendors are using public cloud for their infrastructure. Some are aggressively pursuing M&A to acquire functionality. These decisions have led to many problematic questions such as: how many interfaces do organizations need to manage their network and security needs? Why is security enforcement sometimes in the cloud and sometimes at the branch edge?

We believe that the market deserves more than a buffet of features. Convergence should be greater than the sum of the parts. The infrastructure/control plane/data plane for networking services should not be an independent entity from the security services. We believe that we are delivering SASE capabilities in a fundamentally different manner than the majority of vendors in the market: by building out the platform first, and layering services upon it.

We also believe that our efforts to focus on the underlying network delivers better solutions for simplifying your infrastructure, establishing control, and maintaining visibility to support branch connectivity, hybrid work, Zero Trust, and secure cloud access.

What is required for SASE and how is Cloudflare different?

The Cloudflare Global network is one of the largest, most well-connected networks in the world, spanning more than 330 cities in over 125 countries. We are not a new vendor entering a new market, but rather one that has been delivering services upon a mature platform that’s been tested under the most extreme circumstances over the past 15+ years.

Our unified platform, Cloudflare’s connectivity cloud, is built upon a set of principles across our infrastructure, our control plane, and our data plane, that guides everything we do:

Infrastructure: The infrastructure that we build must be everywhere our customers do business. Users, applications, and data are everywhere, and therefore we build ahead of our customer’s needs to ensure that they can connect anything to anywhere, quickly and reliably.

Control Plane: To stay on top of operations, organizations want a single user interface for monitoring activity and enforcing policies, with changes pushed out globally in seconds. In addition, our customers want APIs to extend management into automation and infrastructure-as-code tools. We help organizations cut down on the tool sprawl, doing away with the drudgery and complexity that affects even the most basic administrative tasks with conventional tech stacks. And we restore observability across activity (again by virtue of facilitating any-to-any connectivity) to help with operations with troubleshooting, forensics, and insights across the application landscape.

Data Plane: The data plane is where services are delivered, and we constantly deliver innovations in how users connect, consistently enforce inspection and policy, and deliver traffic to the intended location securely. These services are composable, meaning that new functionality can be enabled from the Control Plane, without the headaches of network downtime normally associated with appliance insertion.

How customers benefit from Cloudflare’s design principles 

These principles are crucial for delivering a superior, end-to-end user experience. Your SASE environment is (or will be) processing packets from users across the globe. Latency damages the user experience, in ways that are similar to how a smoothly running engine becomes unreliable and inefficient as internal components become dirty. Our design principles establish the north star to ensure that everything we do and everything we build does not add grit to the engine. This is important because we are seeing a lot of confusion (and some obfuscation) about how to deliver performant SASE services.

To understand how our principles apply towards the delivery of SASE services:

Connecting users to a data center (last mile latency): With traditional on-prem networking, one of the major sources of latency is getting the traffic to the security stack. Both hub & spoke and VPN focus on taking traffic (from sometimes distant locations) to one of the organization’s security enforcement points such as a perimeter firewall. With SASE, the objective is to deliver the security closer to the user, using one of the SASE provider’s data centers. Cloudflare’s global coverage delivers service to within 50ms of 95% of the world’s population. This is something unique to Cloudflare, in that other vendors seldom discuss how much data center coverage is needed to deliver sufficient last mile performance, or sometimes use confusing metrics about the latency within their data centers (see next section) to infer what organizations might expect with end-to-end latency.

Delivering key networking and security services (processing latency): SASE data centers must deliver networking and security, but not all cloud data centers are designed the same. Some implementations in the market separate the SASE edge (the point of presence) from the actual compute (the data center itself). Some have disguised their single-pass processing with a series of daisy-chained proxies, which requires inefficiently decoding packets multiple times (From L3 to L7 and back to L3) to perform different security functions. As a result, there’s often a delta between the performance of a configuration that offers low latency and the configuration with the security features that customers want enabled. Cloudflare delivers full compute in every data center. There is no “next-hop” to compute; instead, there are fungible compute resources to ensure the fastest interface-to-interface possible with all the security features (including TLS decryption) enabled.

Connecting from the SASE to applications (Internet exchanges, private backbone, optimized routing and peering): Many vendors optimize their data centers to focus on egress to the Internet/cloud, typically by participating in Internet exchanges along with a handful of peering relationships. In other words, their networks were not designed for traffic between data centers, which is a suboptimal design for branch-to-branch or branch-to-data-center traffic.

Cloudflare’s network operates a private backbone for traffic destined to another Cloudflare data center, and we are one of the largest participants in Internet exchanges in the world for traffic destined to the Internet/cloud. We are connected to over 13,000 public and private networks, plus our open peering policy provides extensive access for networks of different sizes to participate as well. But user experience isn’t determinable solely by the number of interconnections. Not all Internet exchanges are the same, and in many cases there are variables that affect the quality and reliability of any given connection. That’s why Cloudflare further optimizes the connection to the user’s ultimate destination, whether destined to a public or private network, to make path selection more intelligent than simply counting hops over routing protocols.

How customers adopt Cloudflare One

We’ve discussed how we do what we do. Now let’s discuss the services we deliver. While customers have a number of different requirements that are specific to their organization, we do see centers of gravity that drive their use cases:

Network modernization initiatives: Enterprise networks are in ways more complicated than they need to be. To make the enterprise network suitable for today’s hybrid workspace, many organizations are looking for ways to converge the on-prem and remote user experience. The adoption of the coffee shop networking architecture is driving many projects towards single-vendor SASE. By using Cloudflare Access, users can access applications securely with identity and device-based contextual controls. Organizations use Magic WAN for network connectivity across branch offices, headquarters, regional campuses and the data center.

Security modernization initiatives: Security teams with concerns about enforcing more granular security controls to access critical resources are making efforts to adopt Zero Trust. These initiatives drive security-focused SASE use cases, which can both reduce the attack surface and centralize enforcement of adaptive access policies. Security teams need to both enable access to private applications while also securing access to the Internet. Use Cloudflare Access to implement Zero Trust Network Access, which accelerates the deployment of protections by layering granular, user-specific access controls on top of the existing network topology. Use Cloudflare Gateway to enforce content filtering policies to protect access to the Internet. Use Cloudflare Email Security to stop phishing attacks and disrupt the business email compromise attack lifecycle. 

Transformation initiatives: Most organizations have legacy investments in both networking and security infrastructure, and are embarking upon a transformation across their business to support their future needs. Organizations that are transforming need to tackle both networking and security modernization. Cloudflare One addresses comprehensive transformation by delivering networking services through Cloudflare Magic WAN, Cloudflare Access to implement ZTNA, Cloudflare Gateway to protect users from Internet threats, Cloudflare CASB to secure SaaS, and more.

Building beyond SASE

We’re building new capabilities that extend beyond the traditional definition of SASE, all while leveraging our core Cloudflare network foundation. This includes addressing a broader spectrum of security concerns that organizations face, such as phishing and DDoS attacks.

We are expanding our networking capabilities to help organizations simplify and automate multi-cloud connectivity. As the boundaries between public and private networking blur, particularly with the widespread adoption of AI across various applications, customers are looking for a single set of controls for all their applications. This requires market-leading Web Application and API Protection (WAAP) services that natively support both positive and negative security models as part of SASE.

Furthermore, we are rapidly deploying Graphics Processing Units (GPUs) in our data centers to power AI protections and support customer applications. As the only SASE platform that also serves as a leading Edge Distribution Platform with AI primitives, we are uniquely positioned to help customers to understand the latest AI capabilities and secure their users, networks, applications, and data with a security-first approach across the entire application lifecycle. We provide holistic support for the age of AI, and many leading Generative AI platforms rely on our network as critical infrastructure to operate. With their traffic and often code on our network, we enable the safeguard of customers’ AI usage.

We believe that these efforts will help the market evolve and address a broader range of customer concerns. We’re doing this incrementally, building integrated solutions on top of our foundation and accelerating our pace. We can’t wait to show you what we’ve got planned for the year ahead in SASE.

Are you interested in Cloudflare One? Contact us to learn more about how we can help.

***

1Gartner, Magic Quadrant for SASE Platforms, Analyst(s): Jonathan Forest, Neil MacDonald, Dale Koeppen, July 9, 2025

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

[$] Enforcement (or not) for module-specific exported symbols

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

Loadable kernel modules require access to kernel data structures and
functions to get their job done; the kernel provides this access by way of
exported symbols. Almost since this mechanism was created, there have been
debates over which symbols should be exported, and how. The 6.16 kernel
gained a new export mechanism that limits access to symbols to specific
kernel modules. That code is likely to change soon, but the addition
of an enforcement mechanism has since been backed out.

Security updates for Tuesday

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

Security updates have been issued by Debian (ffmpeg), Fedora (gnutls, linux-firmware, mingw-djvulibre, mingw-python-requests, and salt), Mageia (qtimageformats6), Oracle (gnome-remote-desktop, golang, kernel, libxml2, and perl-File-Find-Rule), SUSE (gstreamer-plugins-base, gstreamer-plugins-good, kernel, and protobuf), and Ubuntu (apport, glibc, gnutls28, and roundcube).

Ядрената дилема на Иран: Към сделка или към нова война?

Post Syndicated from Искрен Иванов original https://www.toest.bg/yadrenata-dilema-na-iran-kum-sdelka-ili-kum-nova-voyna/

Ядрената дилема на Иран: Към сделка или към нова война?

Голяма част от анализите за региона на Близкия изток приемат за отправна точка на хипотезите си съществуващата дилема за сигурност между Държавата Израел и Ислямска република Иран заедно със съвременните тенденции във външната политика на САЩ. Въпреки предимствата си този подход крие един голям риск – ролята на Иран в региона далеч не се свежда до познатото ни уравнение в учебниците – когато една страна напада, другата се отбранява. Това е доста наивна представа за политическите реалности в Близкия изток, която не ни позволява правилно да оценим какви рискове крият иранските ядрени амбиции и защо ядрената програма на страната има глобални измерения. В този анализ ще се постараем да хвърлим светлина върху скритите аспекти на ядрената дилема на Иран и да отговорим на въпроса дали мечтаната ядрена сделка е постижима геополитическа реалност.

Стратегическата култура на Иран и ядрените ѝ амбиции

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

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

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

Това е силно идеологизирана презумпция, която не отговаря на историческата истина. От културно-историческа и политическа гледна точка Ислямска република Иран не може да се счита дори за правоприемник на шиитските империи от времето на Сефевидите по една основна причина: след Ислямската революция от 1979 г. шиитската традицията в страната се пречупва през визията на Рухола Хомейни – вилаят-е факих, която значително модифицира шиитската доктрина, отстоявана от иранските монархии в продължения на столетия. Хомейни „революционизира“ шиитската традиция, връчвайки политическата власт еднолично на духовенството – аятоласите, като отхвърля напълно принципа на секуларизма в политиката.

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

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

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

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

Възможните отговори са много, но най-прагматичният е един: той би бил много по-склонен да го използва, тъй като, за разлика от студения прагматизъм на Пхенян и Москва, политическата формула на властта в Техеран съдържа силен теократичен елемент, което я прави по-малко рационална и от Северна Корея, и от Русия. Да не говорим, че Иран няма да членува в нито един формат за ядрено сдържане, което ще го направи неуправляем дори за Русия.

Вторият е какво би се случило, ако иранските проксита в лицето на „Хизбула“ и на това, което е останало от „Хамас“, се сдобият с ядрен потенциал.

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

Кои са сдържащите сили пред Иран в Близкия изток?

На този етап се очертават няколко актьора, които ефективно биха могли да сдържат Техеран. Първият е Израел. Причината е новата отбранителна доктрина на страната, която беше модифицирана в месеците след атаките на „Хамас“ от 7 октомври 2023 г. В своя оригинален вариант израелската отбранителна доктрина „Дахия“ съдържа постановката, че Израел си запазва правото да действа диспропорционално, в случай че бъде нападнат, но с презумпцията, че приоритетно трябва да бъдат поразени властовите и ресурсните центрове на агресора. Тази доктрина доминираше в израелското стратегически мислене в годините след 11 септември 2001 г. и многократно беше критикувана от европейските правителства под предлог, че взема много цивилни жертви. 

Подобна логика обаче е погрешна, тъй като по обхват доктрината е избирателна (може да се приложи или не в зависимост от решението на командването), а ако Европа има НАТО, Израел е сам срещу много противници в Близкия изток. Ето защо през 2024 г. Военното командване на Израел реши да реформира доктрината си, включвайки в нея концепцията за pre-emptive strike (изпреварващ удар): правото на един държавен актьор да нанесе предварителен военен удар върху друг, ако са налице доказателства, че действията на отсрещната страна са заплаха за националната сигурност на нападащата, един вид, „нападам, за да не бъда нападнат“. Тук е мястото да кажем, че това понятие няма общо с друго понятие – preventive war (превантивна война), при което държавите прилагат сила само въз основа на предположения, а не на реални доказателства за неизбежно нападение. 

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

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

Както историята често си прави шеги, изборът за това се падна на президент, който дълго време обещаваше на американците, че ще се грижи преди всичко за Америка, а след това за нейните съюзници. Доналд Тръмп се озова в същата роля като Удроу Уилсън и Франклин Рузвелт, чиято съпротива срещу влизането на САЩ в двете световни войни в крайна сметка беше победена от нуждата някой да балансира разрушителните амбиции на агресорите. Вашингтон попадна в тази позиция за пореден път, тъй като обективният баланс на силите в системата на международните отношения го позиционира като единствения държавен актьор, който разполага с военностратегическите, икономическите и културните ресурси да реагира във всяка точка на света. В допълнение, лобито на изолационистите в американската външна политика е изключително малко и влиянието му върху Тръмп е по-скоро периферно. 

Намесата на САЩ в Близкия изток доказа и още нещо – че американският ядрен чадър над съюзниците функционира и че на Вашингтон може да се разчита, ако държавите изпълняват простото условие на бизнесмена Тръмп – да развиват отбранителните си способности солидарно със САЩ и да продължат да купуват американски оръжия.

Последната сдържаща сила пред Иран са останалите арабски държави, и по-точно Кралство Саудитска Арабия.

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

Република Турция, от друга страна, като част от НАТО и бидейки под американския ядрен чадър, си позволява лукса да флиртува с Иран. Това ѝ дава възможност да балансира между САЩ и Иран в позицията си и донякъде е мотив за Вашингтон да пуска покрай ушите си турските критики към Израел. Дали обаче Анкара ще продължи в същия дух при една повторна намеса на САЩ в Близкия изток или ако в близко бъдеще иранските шиитски проксита опитат терористичен атентат на турска територия – предстои да видим.

Какво ни чака оттук нататък?

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

Първият формат, в който може да се реализира политиката на Иран в региона, е конфронтационният.

Това е най-лошият възможен сценарий, тъй като при него дезинформацията, разпространявана от Техеран посредством „Хизбула“ и „Хамас“, ще продължава да се засилва, което ще доведе до липса на всякакъв диалог с Америка и съюзниците ѝ. Резултатите от такъв курс на събитията са ясни: нова война, в която Вашингтон ще се включи активно, за да защити Израел, а европейските държави вероятно ще участват избирателно. 

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

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

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

Ако Доналд Тръмп се съгласи с такова статукво в Близкия изток, за да си осигури подкрепата на консервативните републиканци изолационисти, той ще се върне към т.нар. политика на офшорно балансиране. САЩ ще продължат да снабдяват Израел с оръжия и ресурси, намесвайки се директно само ако иранските атаки застрашават пряко американските интереси. Ще станем свидетели на дирижирани битки и добре обмислени „сблъсъци“, което ще уеднакви политиката на Тръмп в региона с тази на Байдън. 

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

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

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

И накрая – нека си представим, че Иран просто спира с дезинформацията, без да води диалог, затваря се в себе си и не пречи на никого.

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

Днес обаче времената са други. Но да се върнем към розовия сценарий. Той е най-опасният, тъй като един ден Близкият изток ще се събуди на прага на втора Кубинска ракетна криза. В случай че това стане, Иран вече ще разполага с ракети, които могат да достигнат територията на европейските съюзници от НАТО, както и на Русия, Индия, Пакистан, Китай, а в дългосрочен план – и Източното крайбрежие на САЩ. Парадоксално е, че Америка осъзна тази реалност и без да е заплашена в краткосрочен план, се намеси, докато Европа, която е пряко застрашена, не го стори. 

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

Hyper-volumetric DDoS attacks skyrocket: Cloudflare’s 2025 Q2 DDoS threat report

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

Welcome to the 22nd edition of the Cloudflare DDoS Threat Report. Published quarterly, 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 second quarter of 2025. To view previous reports, visit www.ddosreport.com.

June was the busiest month for DDoS attacks in 2025 Q2, accounting for nearly 38% of all observed activity. One notable target was an independent Eastern European news outlet protected by Cloudflare, which reported being attacked following its coverage of a local Pride parade during LGBTQ Pride Month.

Key DDoS insights

  • DDoS attacks continue to break records. During 2025 Q2, Cloudflare automatically blocked the largest ever reported DDoS attacks, peaking at 7.3 terabits per second (Tbps) and 4.8 billion packets per second (Bpps).

  • Overall, in 2025 Q2, hyper-volumetric DDoS attacks skyrocketed. Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, an average of 71 per day. 

  • Although the overall number of DDoS attacks dropped compared to the previous quarter — which saw an unprecedented surge driven by a large-scale campaign targeting Cloudflare’s network and critical Internet infrastructure protected by Cloudflare — the number of attacks in 2025 Q2 were still 44% higher than in 2024 Q2. Critical infrastructure continues to face sustained pressure, with the Telecommunications, Service Providers, and Carriers sector jumping again to the top as the most targeted industry.

All the attacks in this report were automatically detected and blocked by our autonomous defenses.


To learn more about DDoS attacks and other types of cyber threats, refer to our Learning Center. Visit Cloudflare Radar to view an interactive version of this report where you can drill down further. Radar also offers a free API for those interested in investigating Internet trends. You can also learn more about the methodologies used in preparing these reports.

DDoS attacks in numbers

In 2025 Q2, Cloudflare mitigated 7.3 million DDoS attacks — down sharply from 20.5 million in Q1, when an 18-day campaign against Cloudflare’s own and other critical infrastructure protected by Cloudflare, drove 13.5 million of those attacks. 


DDoS attacks by quarter

We’ve just crossed halfway through 2025, and so far Cloudflare has already blocked 27.8 million DDoS attacks, equivalent to 130% of all the DDoS attacks we blocked in the full calendar year 2024.


DDoS attacks by year

Breaking it down further, Layer 3/Layer 4 (L3/4) DDoS attacks plunged 81% quarter-over-quarter to 3.2 million, while HTTP DDoS attacks rose 9% to 4.1 million. Year-over-year changes remain elevated. Overall attacks were 44% higher than 2024 Q2, with HTTP DDoS attacks seeing the largest increase of 129% YoY.


DDoS attacks by month

Hyper-volumetric DDoS attacks

In 2025 Q2, Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, averaging 71 hyper-volumetric attacks per day. Hyper-volumetric attacks include L3/4 DDoS attacks exceeding 1 Bpps or 1 Tbps, and HTTP DDoS attacks exceeding 1 million requests per second (Mrps).

The number of hyper-volumetric DDoS attacks exceeding 100 million packets per second (pps) surged by 592% compared to the previous quarter, and the number exceeding 1 billion pps and 1 terabits per second (Tbps) doubled compared to the previous quarter. The number of HTTP DDoS attacks exceeding 1 million rps (rps) remained the same at around 20 million in total, an average of almost 220,000 attacks every day.


Hyper-volumetric DDoS attacks in 2025 Q2

Threat actors

When asked who was behind the DDoS attacks they experienced in 2025 Q2, the majority (71%) of respondents said they didn’t know who attacked them. Of the remaining 29% of respondents that claimed to have identified the threat actor, 63% pointed to competitors, a pattern especially common in the Gaming, Gambling and Crypto industries. Another 21% attributed the attack to state-level or state-sponsored actors, while 5% each said they’d inadvertently attacked themselves (self-DDoS), were targeted by extortionists, or suffered an assault from disgruntled customers/users.


Top threat actors reported in 2025 Q2

Ransom DDoS attacks

The percentage of attacked Cloudflare customers that reported being targeted by a Ransom DDoS attack or that were threatened increased by 68% compared to the previous quarter, and by 6% compared to the same quarter in 2024. 


Ransom DDoS attacks by quarter 2025 Q2

Diving deeper, Ransom DDoS attacks soared in June 2025. Around a third of respondents reported being threatened or subjected to Ransom DDoS attacks.


Ransom DDoS attacks by month 2025 Q2

Top attacked locations

The ranking of the top 10 most attacked locations in 2025 Q2 shifted significantly. China climbed two spots to reclaim first place, Brazil jumped four spots to second place, Germany slipped two spaces to third place, India edged up one to fourth, and South Korea rose four to fifth. Turkey fell four places to sixth, Hong Kong dropped three to seventh, and Vietnam vaulted an astonishing fifteen spots into eighth. Meanwhile, Russia rocketed forty places to ninth, and Azerbaijan surged thirty-one to round out the top ten.


The locations most targeted by DDoS attacks for 2025 Q2

It’s important to note that these attacked locations are determined by the billing country of the Cloudflare customer whose services were targeted — not that those nations themselves are under attack. In other words, a high rank simply means more of our registered customers in that billing jurisdiction were targeted by DDoS traffic, rather than implying direct geopolitical targeting.

Top attacked industries

The ranking of the top 10 most attacked industries in 2025 Q2 also saw notable movement. Telecommunications, Service Providers and Carriers climbed one spot to claim first place, while the Internet sector jumped two spots to second place. Information Technology & Services held its placement as third most attacked, and Gaming rose one spot to fourth place. Gambling & Casinos slipped four spots to fifth place, and the Banking & Financial Services industry remained in sixth place. Retail inched up one spot to seventh place, and Agriculture made a dramatic 38-place leap into eighth. Computer Software climbed two spots to ninth place, and Government hopped two places to round out the top ten most attacked industries.


The top attacked industries of DDoS attacks for 2025 Q2

Top sources of DDoS attacks

The ranking of the top 10 largest sources of DDoS attacks in 2025 Q2 also saw several shifts compared to the previous quarter. Indonesia climbed one spot to claim the first place, Singapore jumped two places to second place, Hong Kong dropped two places to third, Argentina slipped one space as fourth and Ukraine held on as the fifth-largest source of DDoS attacks. Russia surged six spots as the sixth-largest source, followed by Ecuador who jumped seven places. Vietnam inched up one place as the eighth-largest source. The Netherlands moved up four places as the ninth-largest source, and Thailand fell three places as the tenth-largest source of DDoS attacks.


The top sources of DDoS attacks for 2025 Q2

It’s important to note that these “source” rankings reflect where botnet nodes, proxy or VPN endpoints reside — not the actual location of threat actors. For L3/4 DDoS attacks, where IP spoofing is rampant, we geolocate each packet to the Cloudflare data center that first ingested and blocked it, drawing on our presence in over 330 cities for truly granular accuracy.

Top source networks of DDoS attacks

An ASN (Autonomous System Number) is a unique identifier assigned to a network or group of IP networks that operate under a single routing policy on the Internet. It’s used to exchange routing information between systems using protocols like BGP (Border Gateway Protocol).

For the first time in about a year, the German-based Hetzner (AS24940) network dropped from the first place as the largest source of HTTP DDoS attack to the third place. In its place, Austrian-based Drei (AS200373) jumped 6 places as the number one largest source of HTTP DDoS attacks. The US-based DigitalOcean (AS14061) hopped one spot to the second place.


The top 10 ASN sources of HTTP DDoS attacks

As can be seen in the chart above, 8 out of 10 ASNs listed offer virtual machines (VMs), hosting, or cloud services which indicate the common use of VM-based botnets. These botnets are estimated to be 5,000x stronger than IoT-based botnets. Only Drei (AS200373) and ChinaNet Backbone (AS4134) are primarily ISPs or telecom carriers without significant public VM/cloud offerings.


IoT-based botnets versus VM-based botnets

To help hosting providers, cloud computing providers and any Internet service providers identify and take down the abusive accounts that launch these attacks, we leverage Cloudflare’s unique vantage point to provide a free DDoS Botnet Threat Feed for Service Providers. Over 600 organizations worldwide have already signed up for this feed, and we’ve already seen great collaboration across the community to take down botnet nodes. This is possible thanks to the threat feed which provides these service providers a list of offending IP addresses from within their ASN that we see launching HTTP DDoS attacks. It’s completely free and all it takes is opening a free Cloudflare account, authenticating the ASN via PeeringDB, and then fetching the threat intelligence via API.

With a simple API call, service providers can get a list of offending IPs from within their network. An example response is provided below.

{
  "result": [
    {
      "cidr": "127.0.0.1/32",
      "date": "2024-05-05T00:00:00Z",
      "offense_count": 10000
    },
    // ... other entries ...
  ],
  "success": true,
  "errors": [],
  "messages": []
}

Example response from the free ISP DDoS Botnet Threat Feed API

Attack vectors

Defending against DDoS Botnets

In Q2 2025, the majority (71%) of HTTP DDoS attacks were launched by known botnets. Rapid detection and blocking of these attacks was possible as a result of operating a massive network and seeing many different types of attacks and botnets. By leveraging real-time threat intelligence, our systems are able to incriminate DDoS botnets very fast, contributing to a more effective mitigation. Even if a DDoS botnet has been incriminated while targeting only one website or IP address, our entire network and customer base is immediately protected against it. This real-time threat intelligence system adapts with botnets as they morph and change nodes.


The top HTTP DDoS attack vectors for 2025 Q2

L3/4 attack vectors

In Q2 2025, DNS flood attacks were the top L3/4 attack vector accounting for almost a third of all L3/4 DDoS attacks. SYN floods was the second most common attack vector, dipping from 31% in Q1 to 27% in Q2. 

In third place, UDP floods also grew meaningfully, rising from 9% in Q1 to 13% in Q2. RST floods, another form of TCP-based DDoS attacks, accounting for 5% of all L3/4 attacks, was the fourth most common vector. Rounding out the top five, SSDP floods edged into fifth place at 3% despite a decline from 4.3% last quarter, but enough to push the previously prevalent Mirai attacks (which fell from 18% in Q1 to just 2% in Q2) out of the top five altogether.


The top L3/4 DDoS attack vectors for 2025 Q2

Breakdown of the top 3 L3/4 DDoS attack vectors

Below are details about the top 3 most common L3/4 DDoS attacks. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare’s customers are protected against these attacks.

DNS Flood Attack

  • Type: Flood

  • How it works: A DNS flood aims to overwhelm a DNS server with a high volume of DNS queries—either valid, random, or malformed—to exhaust CPU, memory, or bandwidth. Unlike amplification attacks, this is a direct flood aimed at degrading performance or causing outages, often over UDP port 53, but sometimes over TCP as well (especially for DNS-over-TCP or DNSSEC-enabled zones).

  • How to defend against the attack: Use Cloudflare DNS as primary or secondary, Cloudflare DNS Firewall and/or Cloudflare Magic Transit to absorb and mitigate query floods before they reach your origin. Cloudflare’s global network handles tens of millions of DNS queries per second with built-in DDoS filtering and query caching, blocking malformed or excessive traffic while answering legitimate requests.

  • How to avoid unintended impact: Avoid blocking all DNS traffic or disabling UDP port 53, which would break normal resolution. Rely on Cloudflare’s DNS-specific protection such as the Advanced DNS Protection system, and deploy DNSSEC-aware protection to handle TCP-based query floods safely.

SYN Flood Attack

  • Type: Flood

  • How it works: In a SYN flood, threat actors  send a large volume of TCP SYN packets—often with spoofed IP addresses—to initiate connections that are never completed. This leaves the target system with half-open connections, consuming memory and connection tracking resources, potentially exhausting server limits and preventing real clients from connecting.

  • How to defend against the attack: Use Cloudflare Magic Transit to intercept and mitigate TCP SYN floods at the edge. Cloudflare leverages SYN cookies, connection tracking, and behavioral analysis to distinguish real clients from spoofed or malicious sources, ensuring legitimate TCP connections are completed successfully. Using Cloudflare’s CDN/WAF services or Cloudflare Spectrum which are both reverse-proxy services for HTTP or TCP, respectively. Using a reverse-proxy basically eliminates the possible impact of TCP-based DDoS attacks.

  • How to avoid unintended impact: Blocking all SYN traffic or applying aggressive timeouts can block real users. Instead, rely on Cloudflare’s Advanced TCP protection system, which uses SYN rate shaping, anomaly detection, and spoofed-packet filtering to mitigate attacks without affecting genuine client connections.

UDP DDoS attack

  • Type: Flood

  • How it works: A high volume of UDP packets is sent to random or specific ports on the target IP address(es). It may attempt to saturate the Internet link or overwhelm its in-line appliances with more packets than it can handle in order to create disruption or an outage.

  • How to defend against the attack: Deploy cloud-based volumetric DDoS protection that can fingerprint attack traffic in real-time such as Cloudflare Magic Transit or Cloudflare Spectrum, apply smart rate-limiting on UDP traffic, and drop unwanted UDP traffic altogether with the Magic Firewall.

  • How to avoid unintended impact: Aggressive filtering may disrupt legitimate UDP services such as VoIP, video conferencing, or online games. Apply thresholds carefully.

Emerging threats

Among emerging L3/4 DDoS threats in 2025 Q2, Teeworlds flood saw the biggest spike. These attacks jumped 385% QoQ, followed by the RIPv1 flood, which surged 296%. RDP floods climbed by 173%, and Demon Bot floods increased by 149%. Even the venerable VxWorks flood made a comeback, rising 71% quarter-over-quarter. These dramatic upticks highlight threat actors’ ongoing experimentation with lesser-known and legacy protocols to evade standard defenses.


The top emerging threats for 2025 Q2

Breakdown of the top emerging threats

Below are details about the emerging threats for 2025 Q2, mostly recycling of very old attack vectors. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare’s customers are protected against these attacks.

Teeworlds DDoS Attack

  • Type: Flood

  • How it works: Teeworlds is a fast-paced, open-source 2D multiplayer shooter game that uses a custom UDP-based protocol for real-time gameplay. Threat actors flood the target’s game server with spoofed or excessive UDP packets that mimic in-game actions or connection attempts. This can overwhelm server resources and cause lag or outages.

  • How to defend against the attack: Use Cloudflare Spectrum or Cloudflare Magic Transit to protect the servers. Cloudflare automatically detects and mitigates these types of attacks using real-time fingerprinting, blocking attack traffic while allowing real players through. Magic Transit also provides a packet-level firewall capability, the Magic Firewall which can be used to craft custom protection.

  • How to avoid unintended impact: When crafting custom rules, avoid blocking or aggressively rate-limiting UDP port 8303 directly as it can disrupt overall gameplay. Instead, rely on intelligent detection and mitigation services to avoid affecting legitimate users.


Teeworlds Screenshot Jungle. Source: Wikipedia

RIPv1 DDoS attack

  • Type: Reflection + (Low) Amplification

  • How it works: Exploits the Routing Information protocol version 1 (RIPv1), an old unauthenticated distance-vector routing protocol that uses UDP/520. Threat actors send spoofed routing updates to flood or confuse networks.

  • How to prevent becoming a reflection / amplification element: Disable RIPv1 on routers. Use RIPv2 with authentication where routing is needed.

  • How to defend against the attack: Block inbound UDP/520 from untrusted networks. Monitor for unexpected routing updates.

  • How to avoid unintended impact: RIPv1 is mostly obsolete; disabling it is generally safe. If legacy systems rely on it, validate routing behavior before changes.

RDP DDoS Attack

  • Type: Reflection + Amplification

  • How it works: The Remote Desktop Protocol (RDP) is used for remote access to Windows systems and typically runs over TCP port 3389. In some misconfigured or legacy setups, RDP can respond to unauthenticated connection attempts, making it possible to abuse for reflection or amplification. Threat actors send spoofed RDP initiation packets to exposed servers, causing them to reply to a victim, generating high volumes of unwanted traffic.

  • How to defend against the attack: Use Cloudflare Magic Transit to protect your network infrastructure. Magic Transit provides L3/L4 DDoS protection, filtering out spoofed or malformed RDP traffic before it reaches your origin. For targeted application-layer abuse, Cloudflare Gateway or Zero Trust Network Access (ZTNA) can help secure remote desktop access behind authenticated tunnels.

  • How to avoid unintended impact: Do not block TCP/3389 globally if RDP is actively used. Instead, restrict RDP access to known IPs or internal networks, or use Cloudflare Tunnel with Zero Trust Network Access (ZTNA) to remove public exposure altogether while maintaining secure access for legitimate users.

DemonBot DDoS Attack

  • Type: Botnet-based Flood

  • How it works: DemonBot is a malware strain that infects Linux-based systems—particularly unsecured IoT devices—via open ports or weak credentials. Once infected, devices become part of a botnet that can launch high-volume UDP, TCP, and application-layer floods. Attacks are typically command-and-control (C2) driven and can generate significant volumetric traffic, often targeting gaming, hosting, or enterprise services. To avoid infection, leverage antivirus software and domain filtering. 

  • How to defend against the attack: Use Cloudflare Magic Transit to absorb and filter large-scale network-layer floods before they reach your infrastructure. Cloudflare’s real-time traffic analysis and signature-based detection neutralize traffic originating from DemonBot-infected devices. For application-layer services, Cloudflare DDoS protection and WAF can mitigate targeted HTTP floods and connection abuse.

  • How to avoid unintended impact: Instead of broadly blocking traffic types or ports, rely on Cloudflare’s adaptive mitigation to distinguish between legitimate users and botnet traffic. Combine with IP reputation filtering, geo-blocking, and rate limiting to reduce false positives and maintain service availability.


VxWorks Flood DDoS Attack

  • Type: Flood (IoT-based)

  • How it works: VxWorks is a real-time operating system (RTOS) used in millions of embedded and IoT devices (e.g., routers, industrial controllers). Devices running outdated or misconfigured versions of VxWorks can be compromised and used to launch DDoS attacks. Once infected—often via public exploits or weak credentials—they send high volumes of UDP, TCP, or ICMP traffic to overwhelm targets, similar to traditional IoT botnets.

  • How to defend against the attack: Deploy Cloudflare Magic Transit to block volumetric traffic at the network edge. Cloudflare uses real-time fingerprinting and  proprietary heuristics to identify traffic from compromised VxWorks devices and mitigate it in real-time. For application services, Cloudflare’s DDoS mitigation and Gateway services provide additional protection against protocol-level abuse.

  • How to avoid unintended impact: Avoid over-blocking UDP or ICMP traffic, as it may disrupt legitimate diagnostics or real-time services. Instead, use Cloudflare’s intelligent filtering, rate limiting, and geo/IP reputation tools to safely mitigate attacks while avoiding impact to legitimate traffic.


Cloudflare’s real-time fingerprint generation flow

Attack size & duration

Most DDoS attacks are small and short. In 2025 Q2, 94% of L3/4 DDoS attacks didn’t exceed 500 Mbps. Similarly, around 85% of L3/4 DDoS attacks didn’t exceed 50,000 pps. The majority of HTTP DDoS attacks are also small, 65% stay below 50K rps. “Small”, though, is a relative term.

An average modern server typically refers to a general-purpose physical or virtual machine with around 4–8 CPU cores (e.g. Intel Xeon Silver), 16–64 GB RAM, and a 1 Gbps NIC, running a Linux OS like Ubuntu or CentOS with NGINX or similar software. This setup can handle ~100,000–500,000 pps, up to ~940 Mbps throughput, and around 10,000–100,000 rps for static content or 500–1,000 rps for database-backed dynamic applications, depending on tuning and workload.

Assuming the server is unprotected by a cloud DDoS protection service, if it’s targeted by “small” DDoS attacks during peak time traffic rates, it is very likely that the server won’t be able to handle it. Even “small” DDoS attacks can cause significant impact to unprotected servers.


DDoS attacks size and duration in 2025 Q2

While the majority of DDoS attacks are small, hyper-volumetric DDoS attacks are increasing in size and frequency. 6 out of every 100 HTTP DDoS attacks exceed 1M rps, and 5 out of every 10,000 L3/4 DDoS attacks exceed 1 Tbps — a 1,150% QoQ increase.


The largest attack in the world: 7.3 Tbps

Most DDoS attacks are short in duration, even the largest and most intense ones. Threat actors often rely on brief bursts of concentrated traffic—sometimes lasting as little as 45 seconds as seen with the monumental 7.3 Tbps DDoS attack — in an attempt to avoid detection, overwhelm targets and cause maximum disruption before defenses can fully activate. This tactic of short, high-intensity bursts makes detection and mitigation more challenging and underscores the need for always-on, real-time protection. Thankfully, Cloudflare’s autonomous DDoS defenses kick in immediately.

Helping build a better Internet

At Cloudflare, we’re committed to helping build a better Internet. A part of that mission is offering free, unmetered DDoS protection regardless of size, duration and quantity. We don’t just defend against DDoS attacks. The best defense is a good offense, and using our free ISP Botnet Threat Feed, we contribute to botnet takedowns. 

While many still adopt protection reactively or rely on outdated solutions, our data shows proactive, always-on security is far more effective. Powered by a global network with 388 Tbps capacity across 330+ cities, we provide automated, in-line, battle-proven defense against all types of DDoS attacks.

Revenue NSW modernises analytics with AWS, enabling unified and scalable data management, processing, and access

Post Syndicated from Saeed Barghi original https://aws.amazon.com/blogs/big-data/revenue-nsw-modernises-analytics-with-aws-enabling-unified-and-scalable-data-management-processing-and-access/

Revenue NSW, in Australia, is New South Wales (NSW) state’s principal revenue management agency and aspires to be the world’s most innovative and customer-centric revenue agency. Revenue NSW exists to administer grants, resolve fines, and collect revenue to fund essential state services for the over 8 million people of NSW in a fair, efficient, and timely manner.

Analytics at Revenue NSW plays a key role in enabling the organization’s goals and purpose by delivering reliable, secure, and authoritative insights. These insights are key to:

  • Understanding customer attributes to enable empathetic and informed actions
  • Supporting policy development
  • Assisting in the sequencing of millions of decisions
  • Maintaining compliance and education
  • Fostering transparency by providing open data and insights directly to the public

The challenge

Revenue NSW Analytics consumes data from a multitude of operational databases and real-time interfaces and through internally generated reports and files received from external data partners such as other government departments and agencies. The varying technologies, formats, and complexities of these data sources created friction and inefficiencies in data transformation, consolidation, and analysis in an environment that is often time-critical. In addition, these analytics systems were previously hosted on dedicated hardware on-premises that was nearing end-of-life and wasn’t easy to scale efficiently. To address these challenges, Revenue NSW Analytics used their partnership with AWS to build a strategic, unified, scalable, frictionless and modern data environment to help them standardize data transformation and consolidation pipelines from the hundreds of data sources. Additionally, the modern data environment must provide a single source of truth and enable secure and seamless access to the data through a unified SQL interface regardless of the data’s original format or technology.

After understanding other offerings, Revenue NSW Analytics decided on a proof of concept (PoC) using Amazon Web Services (AWS) cloud-based services, including Amazon Redshift. The key goals of the PoC were to assess the completeness of the solution, its performance, and the potential change in total cost of ownership compared to their on-premises setup.

Amazon Redshift, with its integration options, columnar storage, and massively parallel processing (MPP) architecture, offered the desired end-state solution. Tests demonstrated a typical speed increase between 5- and 50-fold in query execution, with many results 100 times faster than the existing on-premises solution. Amazon Redshift also performed significantly better compared with other cloud-based solutions, offering up to 6 times better performance. The success of the initial PoC led Revenue NSW Analytics to further collaborate with AWS, working towards developing a prototype that incorporated Amazon Redshift alongside various data ingestion patterns.

The solution

To simplify data ingestion from the operational databases—which run on different database engines including Oracle, PostgreSQL, and Microsoft SQL—Revenue NSW Analytics used AWS Database Migration Service (AWS DMS) to perform a bulk initial load, followed by capturing ongoing changes from these databases into Amazon Redshift in near real time.

For data from Salesforce’s real-time API, Revenue NSW Analytics used Amazon AppFlow to automate the continuous pulling and ingesting of data into Amazon Redshift.

The hundreds of structured and semi-structured data files were handled using AWS Glue. These files are regularly uploaded to Amazon Simple Storage Service (Amazon S3), triggering the relevant AWS Glue extract, transform, and load (ETL) jobs in an event-based architecture to transfer the data into Amazon Redshift.

To facilitate repeatability and enable iteration, Revenue NSW Analytics used infrastructure-as-code (IaC) and continuous integration and delivery (CI/CD) pipelines to deploy the different components of the solution.

The following is a high-level architecture demonstrating how these different components and services fit together.

Along with standardization and unified access, the success criteria of the new data environment included the ease of transition, consolidation of processes to the new standardised pipelines, scalability, language uniformity, and availability. The combination of supporting standard SQL, AWS DMS, and Amazon AppFlow low-code capabilities, and supporting Python in AWS Glue, a popular programming language, played a crucial role in facilitating the successful transition and adoption of the cloud-based data environment.

Other success factors of this environment include the ability to work within current budgets, and the extendibility and modularity of the solution. As shown in the preceding high-level architecture, the solution runs on multiple building blocks that are decoupled, modular, and either serverless—like AWS Glue—or managed services that support seamless scalable configurations that don’t require rebuilds. This allowed Revenue NSW Analytics to start small with each use case, expand and grow as required, and pay only for what they need.

Moreover, with the new cloud-based data environment, Revenue NSW Analytics can access to up-to-date data in near real time, which is essential to fulfilling critical use cases such as information requests and assisting with compliance case identification. The automated data ingestion pipelines removed much of the boilerplate and heavy lifting, allowing Revenue NSW teams to work more efficiently and focus on the differentiators of their business, and in some cases, shorten workflow times from months to weeks or days.

Another significant factor contributing to the project’s success is the people at the heart of Revenue NSW Analytics. The teams allocated to own and deliver this platform are cross-functional, with adjoining responsibilities and skills, and were prepared through multiple in-person and online training sessions. The teams were empowered to trial individual services to deliver new use cases and iterate on the solution to learn from successes and innovate progressively. This approach, together with support Revenue NSW received from AWS specialist solution architects, helped to minimize the risk of knowledge gaps that often arise when separate teams are responsible for building and operating a system.

The hard work of the Analytics team, the investment of Revenue NSW Analytics leadership in its people, and the continuous support from AWS can truly be seen throughout the delivery of the data environment, resulting in the achievement of the intended outcomes.

Conclusion and call to action

Since going live with their cloud-based data environment on AWS, Revenue NSW has onboarded dozens of analysts who can get more done in less time. This is a result of establishing a single source of truth from different data sources in Amazon Redshift, so that analysts and data consumers don’t need to shop around to find the data that they need to complete their tasks. This new data environment also provides Revenue NSW with the ability to create improved conditions for:

  • Increasing agility by exposing reusable, trusted data services for people and AI
  • Empowering operational systems with services best provided by analytical approaches
  • Decommissioning heritage, costly infrastructure and data practices.

Successful delivery of the cloud-based data environment on AWS has led to further collaboration between AWS and Revenue NSW. This includes exploring the adoption of AI and machine learning (AI/ML) and generative AI to further improve the delivery of services for the people of NSW.

To learn more about customer success stories like this or how to get started with building a data environment on AWS, contact your AWS account team. You can read about similar customers by browsing Customer Success Stories on our website.


About the authors

Saeed BarghiSaeed Barghi is a Sr. Specialist Solutions Architect at Amazon Web Services (AWS) specializing in architecting enterprise data platforms and AI solutions. Based in Melbourne, Australia, Saeed works with public sector customers in Australia and New Zealand and helps his customers build fit-for-purpose and future-proof data platforms and AI solutions.

Miroslaw (Mick) Mioduszewski is the Director of Analytics at Revenue NSW Department of Customer service in NSW. He held multiple C-level roles in private and public companies as well as government, e.g. COO and CIO, as well as serving as company director. Mick holds computer science and business degrees, is a fellow of the Australian Institute of Company Directors and an industry fellow at the University of technology, Sydney.

Moha Alsouli is a Public Sector Solutions Architect at Amazon Web Services (AWS) in Sydney. He is dedicated to supporting state and local government customers deliver citizen services, through solution design, reviews, optimisation, and architecture guidance. Moha is also specialising in generative artificial intelligence (AI) on AWS.

Любомир Попйорданов – за волята и волния човешки дух

Post Syndicated from Ина Иванова original https://www.toest.bg/lyubomir-popyordanov-za-volyata-i-volniya-choveshki-duh/

Любомир Попйорданов – за волята и волния човешки дух

Когато се спомене името Любомир Попйорданов, всички, които го познават, обикновено възкликват: „Любо!“ По светналите им очи се вижда колко откровен, активен и търсещ човек е.

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

Роден е в България, но детството му преминава основно в Тунис, където баща му д-р Йордан Попйорданов работи като лекар. Впоследствие завършва Френската гимназия в София и право в Софийския университет.

Баща е на две пораснали дъщери, художнички, и син – студент по архитектура. Страстен планинар. Основател е на агенциите за приключенски туризъм „Одисея-ин“ и „Зиг-Заг Холидейз“, основател и дългогодишен председател на Управителния съвет на Българската асоциация за алтернативен туризъм (БААТ) – организация, която е ангажирана с опазването и устойчивото използване на българското природно, културно и историческо наследство. Именно БААТ въведе в законодателството правната рамка на къщите за гости. Любомир Попйорданов създава първия публичен фестивал за зелен туризъм – „Зелени дни“ – и намира време да основе „Стената“ (магазини, предлагащи специализирана екипировка за туризъм, къмпинг и катерене), да издава книги и да публикува собствена. Вече близо две десетилетия организира Фестивала за приключенско кино и екстремни спортове „Дни на предизвикателствата“. Носител е на награди за отговорен туризъм и корпоративно дарителство. Зад гърба си има залесителни кампании в Пирин и Витоша (конкретно – Софийското Светогорие и Сеславския манастир). Това са част от каузите, на които е посветен, но зад наименованията им стои мрежа от сърцати хора, с които е по човешки свързан.

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

Всуе или с променлив успех, но Любомир Попйорданов не спира да опитва. Колективните каузи и механизмите на гражданското общество изискват не просто ентусиазъм, а и умението да не се отказваш.

Любомир Попйорданов винаги остро се е противопоставял на опитите туристическият сектор да бъде използван за оправдание на лобистки инвестиционни интереси. Той е активен участник в борбата за защита на националните и природните паркове и срещу опитите за застрояване им – бори се с еднаква страст за морето и за планините на България.


Няма как да не започнем от високото, от планината. Без какво не може в нея? 

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

Изборът е, който ни определя като хора. 

Какво Ви е нужно, за да се усетите цялостен?

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

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

Чистото преживяване в планината с хора, които са ни важни, или с приятели по свръзка; или приключение с лодка в горещите южни ширини; самотно или споделено навлизане в джунглата на Амазонка; или срещата и вечерта, прекарана в някоя откъсната от света родопска махала – ето това е откъсване от консуматорството. 

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

Любомир Попйорданов – за волята и волния човешки дух
Любомир Попйорданов © личен архив

Има ли потенциал алтернативният туризъм да развива дребно предприемачество в изоставените от държавата региони?

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

Все пак именно в този период (до 2012–2015 г.) се родиха най-добрите примери за устойчив и отговорен туризъм. След това термините бяха употребени, така както и идеите за възобновяеми енергийни източници и Зелената сделка. Политическият елит, който управлява държавата ни, с няколко малки изключения, от 2001 г. насам не работи за обществения интерес. 

По образование сте юрист. По призвание – пишете и рисувате. А по характер?

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

Какво Ви тревожи напоследък?

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

Любомир Попйорданов – за волята и волния човешки дух
Автопортрет на Любомир Попйорданов

Какъв искахте да станете, когато бяхте дете?

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

Човек не става нещо, той е. 

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

Какво научихте за себе си от рисуването? В тишина ли предпочитате да създавате платната си?

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

Бавно живеене или живот на скорост?

Въпросът е стар колкото света. Festina lente („Бързай бавно“, лат. – б.р.). Зад историята на сградите, които бележат епохи, както и при литературните произведения и голямото кино винаги има натрупвания, които в един момент достигат до взрив, задават нова посока в естетическите търсения и внушения, забързват обществените отношения и нашия личен живот. 

Да бързаме бавно. Да внасяме смисъл в скоростта.


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

Transforming IT Infrastructure Visibility at Doğan Trend Automotive

Post Syndicated from Michael Kammer original https://blog.zabbix.com/transforming-it-infrastructure-visibility-at-dogan-trend-automotive/30715/

Established in 2020 to consolidate Doğan Group’s automotive and mobility companies and brands under a single entity, Doğan Trend Automotive is a prominent player in their industry. Representing a diverse portfolio ranging from automobiles, motorcycles, and marine engines to electric commercial vehicles, Doğan Trend also delivers innovative solutions to customers through its e-commerce platforms, such as suvmarket.com and vespastoreturkey.com.

The challenge

Doğan Trend’s IT ecosystem spans data centers, remote locations, and multiple units, necessitating seamless operations as well as an efficient monitoring and alert system. The existing infrastructure posed challenges in monitoring, making it difficult to detect potential issues in a timely manner, thus increasing operational risks.

The solution

To address Doğan Trend’s needs, our associates at ASNSKY implemented a Zabbix-based monitoring system. Key highlights of the project included:

  • Centralized dashboards: Custom dashboards were designed for data centers and remote locations, enabling the unified monitoring of IT locations and components from a single interface.
  • A dynamic alert system: Alerts prioritized based on predefined conditions allowed for the swift and effective resolution of critical issues.
  • Seamless operations: Early detection of potential issues prevented operational disruptions and ensured continuity.

Throughout the integration process, ASNSKY’s team collaborated closely with Doğan Trend’s IT department, addressing the specific requirements of different units and providing training for effective system use.

The results

Implementing the new monitoring system rapidly delivered the following results:

  • Enhanced visibility: Real-time monitoring of all IT locations and components made potential issues easy to spot.
  • Proactive issue management: Early detection of critical issues reduced operational downtime.
  • Increased efficiency: The centralized monitoring system drastically improved the responsiveness and effectiveness of Doğan Trend’s IT team.

“This project with the ASNSKY team made our IT infrastructure more transparent and manageable. With Zabbix’s flexible and effective monitoring capabilities, we gained active control over our critical operations. We thank the ASNSKY team for this successful collaboration.” – Burak Altunalan, IT System Management Specialist at Doğan Trend Automotive

In conclusion

Doğan Trend plans to further take advantage of Zabbix’s flexibility to strengthen their resilience and operational efficiency. Their association with ASNSKY marks a significant step toward achieving these objectives.

To learn more about what Zabbix can do for retail customers in every sector, get in touch with us. 

About ASNSKY

ASNSKY enhances its customers’ competitiveness by integrating the power of enterprise-grade open-source-solutions in security and infrastructure with a professional service approach and high quality standards.

Backed by deep industry expertise and a team of seasoned professionals, ASNSKY stands as a trusted partner in your digital transformation journey.

The post Transforming IT Infrastructure Visibility at Doğan Trend Automotive appeared first on Zabbix Blog.

Равенството като инвестиция. Разговор с проф. Лий Баджет

Post Syndicated from original https://www.toest.bg/ravenstvoto-kato-investitsiya-razgovor-s-prof-lee-badgett/

Равенството като инвестиция. Разговор с проф. Лий Баджет

Проф. Мери Вирджиния Лий Баджет (известна като проф. Лий Баджет) е главна икономистка в Koppa LGBTI+ Economic Power Lab и водеща изследователка в областта на равенството за ЛГБТИ+ хора. Преподавала е икономика в Масачузетския университет в Амхърст и е била съдиректорка на Центъра за равенство в заетостта. Тя е старша изследователка в Института „Уилямс“ към Калифорнийския университет в Лос Анджелис (UCLA). Авторка е на книгата „Икономическите аргументи за ЛГБТИ+ равенство. Защо справедливото и равно третиране е от полза за всички нас“, в която анализира икономическите загуби, произтичащи от хомофобията и трансфобията. Проф. Баджет е консултирала Световната банка, Програмата за развитие на ООН и други международни организации по теми, свързани с политиките в областта на ЛГБТИ+ равенството.

Докладът на Института за пазарна икономика (ИПИ) „Икономическата цена на хомофобията в България“, изготвен по поръчка на Фондация GLAS, използва методологията на проф. Баджет и екипа ѝ. Един от изводите на експертите от ИПИ е, че в резултат от дискриминацията на ЛГБТИ+ хората към 2022 г. България е загубила между 2,5 и 4,3 млрд. евро само от чуждестранни инвестиции. 


Проф. Баджет, в книгата си описвате как дискриминацията срещу ЛГБТИ+ хората води до значителни икономически загуби. За какъв вид загуби става дума?

Съществуват различни оценки в зависимост от държавата и използваната методология, но всички показват, че икономическите загуби могат да бъдат сериозни – до 1% от брутния вътрешен продукт (БВП) на една страна. Това е огромна сума. Правила съм такива изследвания за Индия и няколко държави в Югоизточна Азия. Подобни оценки са направени от институции като Световната банка за други страни. Организацията за икономическо сътрудничество и развитие (ОИСР) също публикува основен доклад със заглавие „Икономическите аргументи за по-голямо равенство на ЛГБТИ+ в САЩ“, според който намаляването на ефектите от дискриминацията и стигмата би увеличило БВП на САЩ с 2,6%. Друг добър източник е платформата Open For Business, която анализира как приобщаващата среда подпомага привличането на инвестиции и таланти. В крайна сметка, когато ЛГБТИ+ хората са изключени, техните умения и продуктивност остават неизползвани и това намалява цялостната ефективност на икономиката.

Ако загубите са толкова големи, защо виждаме толкова много анти-ЛГБТИ+ реторика и политики, които набират сила в някои страни със средни и ниски доходи – а дори и в части от ЕС и Съединените щати?

За съжаление, тази реакция често е резултат от дълбоко вкоренена хомофобия и трансфобия. Тези нагласи са ирационални от гледна точка на икономиката, която е насочена към това какво могат да допринесат хората. Уви, хомофобията и трансфобията могат да бъдат политически ефективни. Понякога политици експлоатират тези нагласи, за да привлекат подкрепа от определени групи. Има случаи, в които това се прави и за отвличане на вниманието – например от лошото управление или икономическите неуспехи. От гледна точка на икономистите такава дискриминация просто е неефективна. Ако някой не бъде нает или повишен заради своята сексуална ориентация или джендърна идентичност, а не въз основа на таланта и продуктивността си, икономиката губи. Това е неправилно разпределение на човешкия капитал. Същото важи и за отношението на работното място – ако ЛГБТИ+ служителите са тормозени или се чувстват несигурни сред колегите си, те не могат да дадат най-доброто от себе си, а това е загуба за всички.

Равенството като инвестиция. Разговор с проф. Лий Баджет
С Фил Криън, съучредител на Koppa LGBTI+ Economic Power Lab. Снимка: личен архив

Може ли да споделите примери или данни, които показват как включването на ЛГБТИ+ хора в икономиката носи ползи за обществото като цяло?

Да, включването носи ползи за всички. Когато ЛГБТИ+ хората имат равен достъп до образование и заетост, те по-лесно развиват своите умения, идеи и креативност и допринасят повече. Това увеличава производителността и иновациите. Премахването на дискриминацията и подобряването на достъпа до възможности води до положителни резултати във всички сектори. Бихме могли да видим и по-ниски разходи за здравеопазване, когато дискриминацията намалява, тъй като стигмата, тормозът и страхът са също така основни фактори за психични и физически здравословни проблеми сред ЛГБТИ+ общностите. Икономиките просперират, когато всички хора могат да участват равноправно, без страх.

Кои са основните предизвикателства при събирането на данни за икономическите ефекти от дискриминацията срещу ЛГБТИ+ хора?

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

Но това започва да се променя. В Европейския съюз, Австралия, Нова Зеландия и САЩ се провеждат анкети, които помагат за създаването на политики. Страни като Мексико, Бразилия, Колумбия и Еквадор започнаха да включват въпроси за сексуалната ориентация и джендърната идентичност в националните си проучвания. В Южна Азия някои страни признават „трети пол“ в преброяванията. Правителствата могат да събират такива данни безопасно и етично – така, както правят с друга чувствителна информация. Разполагаме и с дигитални методи, които по-добре защитават поверителността на данните на ЛГБТИ+ хората и позволяват на статистическите агенции да събират тези данни по-ефективно. Когато имаме повече и по-добри данни, това ни помагат да създаваме приобщаващи политики и да проследяваме напредъка.

Какво послание бихте искали да отправите към българските читатели?

Колкото повече научаваме за ЛГБТИ+ хората, толкова по-ясно виждаме колко много допринасят те за нашето общество и икономика. Моето послание към българските читатели е: срещнете се с ЛГБТИ+ хора. Опознайте ги, опознайте ЛГБТИ+ общностите и предизвикателствата, с които се сблъскват – изслушайте ги, чуйте ги, научете се от тях, – и ги подкрепяйте.


Мнението на автора, изразено в този текст, е лично и не отразява позициите на ООН или на нейните държави членки.

Gigabyte G893-ZX1-AAX2 AMD Instinct MI325X Server Review

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/gigabyte-g893-zx1-aax2-amd-instinct-mi325x-server-review/

In our Gigabyte G893-ZX1-AAX2 review, we see how this 8x GPU AMD Instinct MI325X system (2TB of HBM3E!) with dual AMD EPYC CPUs works

The post Gigabyte G893-ZX1-AAX2 AMD Instinct MI325X Server Review appeared first on ServeTheHome.

Announcing the end of support for Node.js 18.x in AWS CDK

Post Syndicated from Charles Meruwoma original https://aws.amazon.com/blogs/devops/announcing-the-end-of-support-for-node-js-18-x-in-aws-cdk/

On November 30th, 2025, the AWS Cloud Development Kit (CDK) will no longer support Node.js 18.x, which reached end of life on April 30, 2025. This change applies to all AWS CDK components that depend on Node.js, including the AWS CDK CLI, the Construct Library, and broader CDK ecosystem projects such as JSII, Projen, and CDK8s.

We encourage you to upgrade to a Node.js Active Long Term Support (LTS) version, which is Node.js 22.x as of July 6, 2025. Given that Node.js 18.x is past end of life, we recommend migrating your CDK projects to newer Node.js LTS versions as soon as possible.

Why are we doing this?

Node.js 18.x reached its End of Life support on April 30, 2025, per the Node.js Release Schedule. This means the Node.js community no longer provides bug fixes or security updates for this version. By dropping support for end-of-life versions, we ensure that AWS CDK users benefit from the latest security patches, performance improvements, and modern Node.js capabilities. This approach aligns with AWS’s commitment to security best practices and our standard policy of supporting only actively maintained runtime versions.

What’s changing?

Starting December 1, 2025, AWS CDK will officially end support for Node.js 18.x. While your existing CDK deployments may continue to function, we will no longer address issues, provide bug fixes, or offer technical support for problems that occur specifically with Node.js 18.x. Any support cases or bug reports related to Node.js 18.x will require reproduction on a supported Node.js version (20.x or 22.x as of June 2025) before we can assist.

Key points

Moving forward, projects that remain on Node.js 18.x will gradually lose access to new AWS CDK capabilities as we develop features using modern Node.js APIs that are not available in older versions. This creates a growing compatibility gap that will make it increasingly challenging to leverage CDK innovations and improvements. The security implications are equally concerning, as any vulnerabilities discovered in the unsupported Node.js 18.x runtime will not receive patches or workarounds from our development team, potentially exposing your infrastructure to known security risks.

The challenges extend throughout the development lifecycle. Without regular compatibility testing against Node.js 18.x, we cannot ensure reliable CDK behavior, and you may encounter unexpected issues in production environments. When problems do arise, our support team will need to reproduce any reported issues on supported Node.js versions before providing assistance, which could delay resolution during critical incidents. Additionally, the broader CDK ecosystem, including third-party libraries and tools your projects depend on, will likely follow similar deprecation schedules, creating compounding compatibility challenges that become more difficult to resolve over time.

Timeline

We’re announcing this change in July 2025, to provide you with a five-month transition period before support officially ends on November 30th, 2025. During this transition window, our team will continue to address issues that arise with Node.js 18.x, giving you time to plan, test, and execute your upgrade strategy without immediate pressure. This period is designed to help you thoroughly validate your CDK projects against newer Node.js versions and ensure smooth deployments in your production environment.

Beginning December 1st, 2025, AWS CDK will officially discontinue support for Node.js 18.x across all components and ecosystem projects. From this point forward, all bug fixes, security patches, and new feature development will target only supported Node.js versions, currently 20.x and 22.x as of June 2025. We strongly recommend using this transition period to migrate to Node.js 22.x, the current Active Long Term Support version, which will provide the longest runway for future compatibility as the Node.js release cycle continues.

Version validation and update steps

Begin your migration by checking which Node.js version you’re currently running across all environments where you deploy CDK projects. Run `node -v` in your local development environment, CI/CD pipelines, and any automated deployment systems to get a complete picture of your current setup.

Once you’ve identified all instances of Node.js 18.x, update your runtime to a supported version using either a version manager like nvm or by downloading the official installer from nodejs.org. We recommend upgrading directly to Node.js 22.x since it’s the current Active Long Term Support version and will provide the longest compatibility runway. After updating your runtime, thoroughly test your CDK projects in non-production environments to ensure your deployment scripts and third-party dependencies work correctly with the new version. Pay particular attention to any custom constructs or complex deployment workflows that may be sensitive to changes in Node.js versions.

Finally, establish a process for staying current with future Node.js releases by bookmarking the AWS CDK Node.js Version Support Timeline, which provides up-to-date information on runtime compatibility and upcoming deprecations. This proactive approach will help you anticipate future changes and plan your upgrade strategies well in advance, avoiding the pressure of last-minute migrations when support windows close.

Conclusion

This deprecation is part of our ongoing commitment to provide a secure, high-quality experience for AWS CDK users. By migrating to a Node.js Active Long Term Support (LTS) version, you will benefit from enhanced performance, ongoing security updates, and continued AWS CDK advancements. If you have any questions or concerns about this deprecation, please reach out and open an issue in our GitHub repo.

Modernizing SOAP applications using Amazon API Gateway and AWS Lambda

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/compute/modernizing-soap-applications-using-amazon-api-gateway-and-aws-lambda/

This post demonstrates how you can modernize legacy SOAP applications using Amazon API Gateway and AWS Lambda to create bidirectional proxy architectures that enable integration between SOAP and REST systems without disrupting existing business operations.

Many organizations today face the challenge of maintaining critical business systems that were built decades ago. These legacy applications power essential business operations despite relying on outdated technologies and integration patterns. Although complete system replacement would be ideal, practical constraints such as budget limitations, resource availability, technical complexity, and missing documentation often make modernization efforts challenging.

This post first shows proxy architecture patterns to expose a legacy SOAP server over a REST API. It then shows how to integrate a legacy SOAP client with applications using a REST API.

While SOAP and REST APIs share HTTP as their foundation, SOAP has some limitations compared to REST, like limited HTTP methods (GET/POST only) and mandatory XML formatting. REST is more flexible with multiple HTTP methods and diverse payload formats (plain text, binary, HTML, JSON, XML).

Using API Gateway and Lambda to proxy SOAP service

Consider a legacy solution that only supports SOAP. The following diagram shows the architecture for a SOAP proxy server using API Gateway and Lambda.

Figure 1: SOAP Server Proxy for modernized architecture

Figure 1: SOAP Server Proxy for modernized architecture

The proxy exposes the APIs hosted on the SOAP Server (on the right side of the image) over a REST interface. A SOAP service expects the HTTP Content-Type header set to text/xml, and a XML format payload that follows the WSDL specification defined by the server.

In the proposed architecture, the Lambda function is the core transformation engine, handling the bidirectional conversion between JSON and XML formats. Lambda functions can be developed in multiple programming languages such as Python, Node.js, Java, C#, Go, Ruby, and PowerShell, allowing you to use your existing development expertise. The serverless nature of Lambda provides automatic scaling to handle traffic spikes without needing infrastructure management or capacity planning.

API Gateway acts as the intelligent front door, managing all incoming requests and routing them appropriately. It provides enterprise-grade features such as request throttling to protect backend systems from overload, comprehensive authentication and authorization mechanisms, API key management for partner access control, request and response validation, caching capabilities for improved performance, and detailed monitoring and logging. These built-in features remove the need for custom middleware development and provide immediate operational benefits. API Gateway can receive multiple payload format such as XML, JSON, binary data, and plain text. This makes it suitable for diverse integration scenarios.

Using API Gateway and Lambda to support legacy SOAP clients

The previous section focused on exposing SOAP services over REST APIs. Organizations also face the reverse challenge where legacy SOAP client applications must access REST services. The architecture for supporting legacy SOAP clients follows a similar pattern but with reversed data flow. In this case, the legacy SOAP client sends XML-formatted requests to what it believes is a SOAP server. However, behind the scenes API Gateway and Lambda work together to translate these requests into REST API calls.

Figure 2: Legacy SOAP client modernization architecture

Figure 2: Legacy SOAP client modernization architecture

The legacy SOAP client application sends XML SOAP messages to API Gateway. The Lambda function receives these SOAP requests, extracts the relevant data from the XML envelope, and transforms it into JSON format for the modern REST service.

The Lambda function wraps the JSON response from the REST services into the SOAP XML format that the legacy client expects. It recreates the appropriate XML structure, SOAP headers, and ensures that the response conforms to the WSDL specification that the client application was designed to consume.

Example scenario

Let’s suppose our legacy client application needs to send a SOAP request to convert an integer number to its word form. The SOAP envelop to convert the number 1519 to its long form “one thousand, five hundred and nine” looks like this:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body> \
        <ConvertNumberToWordsSoapIn>
            <NumberToWordsRequest>1519</NumberToWordsRequest>
        </ConvertNumberToWordsSoapIn>
    </soap:Body>
</soap:Envelope>

The REST conversion service expects a JSON payload the as follownig:

jsonObject = {
	"data" : 1519
}

The following code block shows a sample Lambda function implementation for this. This function converts the SOAP XML envelop to JSON, changes the http header to application/json, and converts response from REST service to SOAP format.

var parseString = require('xml2js').parseString;
const axios = require('axios');

exports.handler = async (event, context) => {
    var valueNumber;
    
    try {
        console.log("Parsing XML string");

        // Parsing the XML to obtain data needed for conversion (number to words)
        parseString(event.body, function (err, result) {
            if (!err) {
                valueNumber = result['soap:Envelope']['soap:Body'][0]
                              ['ConvertNumberToWordsSoapIn'][0]
                              ['NumberToWordsRequest'][0];
            } else { 
                console.log (err);
                throw (err);
            }
        });
        console.log("Creating JSON for calling the service");
        // Creating JSON to call service
        var jsonObject = {
            "data" : valueNumber
        }
        
        console.log("Calling Microservice (NumberToWords)");
        const headers = { 
            'Content-Type': 'Application/json'
        };
        
        console.log ("Parameter for NumberToWords URL:" + 
                    JSON.stringify(process.env.NumberToWordMicroservice));

        // Calling numberToWords REST Server
        var resultNumberToWords = await 
            axios.post(process.env.NumberToWordMicroservice, jsonObject, { headers });
        
        // Creating the response
        console.log("Creating response XML");

        var resp =  create_response (JSON.stringify(resultNumberToWords.data.message));
        console.log("Response in XML: "+ resp);
        
        // Returning the value in XML using text/xml content type
        let response = {'statusCode': 200, headers: {"content-type": "text/xml"}, 
                        'body': JSON.stringify(resp)}
        return response;
        
    } catch (err) {
        console.log ("Error: " + err);
        let response = {'statusCode': 500, 
                        headers: {"content-type": "text/xml"}, 'body': err}
        return response;
    }
};

// Function to create a SOAP XML envelope with the result value
function create_response(numberInWords) {
  return '<?xml version="1.0" encoding="utf-8"?> \
            <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">\
            <soap:Body>\
              <m:ConvertNumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/"> \
                  <m:ConvertNumberToWordsResponseResult>' + numberInWords + '</m:ConvertNumberToWordsResponseResult> \
              </m:ConvertNumberToWordsResponse> \
            </soap:Body>\
            </soap:Envelope>';
}

With this approach, you can maintain your existing SOAP client applications without modification, allowing them to consume modern REST services. You can preserve investments in legacy client applications while gradually modernizing the overall system. This architecture is particularly valuable in scenarios where multiple legacy SOAP clients need to access the same modern REST services. This is because a single proxy can serve multiple client applications simultaneously. The serverless nature of the architecture makes sure that it scales automatically based on the number of client requests, providing cost-effective operation regardless of usage patterns.

Alternative approach using API Gateway transformation capabilities

The Lambda-based approach provides maximum flexibility and control. API Gateway also offers built-in transformation capabilities that can handle certain SOAP modernization scenarios without the need for compute resources.

The native API Gateway transformation uses Apache Velocity Template Language mapping templates. It converts the payload directly at the gateway, offering a streamlined solution for specific modernization scenarios.

The VTL approach works by defining mapping templates that handle the conversion process between different payload formats. When modernizing SOAP services, these templates can intercept REST requests with JSON payloads, restructure the data into XML format compatible with your legacy SOAP endpoints, and reverse the process for responses returning to the client.

Figure 3: API Gateway with velocity template language transformation

Figure 3: API Gateway with velocity template language transformation

This gateway-native transformation strategy offers several operational advantages. You benefit from streamlined architecture because the transformation logic resides entirely within the API Gateway service. There are no other infrastructure components to manage or monitor, and the solution avoids the complexity of coordinating between multiple AWS services. Cost efficiency is another key benefit, as there are no compute charges beyond the standard API Gateway pricing.

Consider the previous example of converting a number to its word format. The VTL transformation in API Gateway will look like this:

## Parse the SOAP envelope and extract the number value
#set(\$xmlDoc = \$input.path('\$'))
#set(\$numberToWords = \$xmlDoc.Envelope.Body.ConvertNumberToWordsSoapIn.NumberToWordsRequest)

## Convert to integer if it's a string
#if(\$numberToWords.toString().matches("^\d+\$"))
  #set(\$dataValue = \$numberToWords.toInteger())
#else
  #set(\$dataValue = \$numberToWords)
#end

{
  "data": \$dataValue
}

You should consider VTL transformations when your SOAP services have predictable, stable schemas with relatively direct XML structures. This approach works particularly well for legacy systems that rarely undergo changes and have clear request-response patterns. For more dynamic environments or complex transformation requirements, the Lambda-based solution provides superior flexibility and maintainability.

Security considerations

An important consideration when working with legacy SOAP services is understanding their authentication mechanisms. SOAP protocols often implement authentication through security standards, where authentication credentials and security tokens are embedded directly within the SOAP envelope headers. This includes username tokens, digital signatures, and encryption elements that are part of the XML structure.

When SOAP envelopes contain unencrypted authentication information in the headers, the proxy architecture typically functions without more modifications. This is because the Lambda function can pass through these authentication elements transparently to the backend SOAP service. However, due to the nature of SOAP authentication being tightly integrated with the XML envelope structure, certain scenarios may need custom handling within the Lambda function.

For example, if the SOAP service uses timestamp-based authentication tokens, session management, or needs specific security header modifications, the Lambda function may need customization to properly handle, validate, or refresh these authentication elements during the JSON-to-XML transformation process. Organizations should carefully analyze their SOAP service authentication requirements to determine if more Lambda logic is needed to maintain security compliance.

Moreover, make sure that any SOAP authentication credentials processed by the Lambda function are handled securely and never logged in plain text.

Conclusion

In this post, you learned how cloud-native services can bridge the gap between legacy systems and modern application architectures, allowing you to use your existing investments while adopting contemporary development practices and technologies.

Amazon API Gateway and AWS Lambda enable organizations to create REST services that proxy legacy SOAP servers, allowing modern applications to consume legacy services through JSON payloads while preserving existing SOAP infrastructure. This serverless solution provides cost-effectiveness, automatic scaling, and reduced operational overhead while facilitating company modernization through scalable APIs without abandoning legacy software investments.

This modernization strategy allows you to gradually transition from legacy SOAP services to modern REST APIs without disrupting existing business operations. As your modernization journey progresses, you can extend this pattern to support more SOAP services or implement more sophisticated transformation logic based on your specific business requirements.

For more serverless learning resources, visit Serverless Land.

The collective thoughts of the interwebz