Skip to content
Last updated: July 2026
Current State of Ransomware
Attackers have worked out that the fastest way to force a payment is to take away the victim’s ability to recover. So they now go after the backups first.
- 89% of ransomware victims had their backup repositories targeted, and 34% of those backups were modified or deleted (Veeam, 2025). When the backups fall with everything else, there’s no clean copy to restore from.
- 48% of breaches now involve ransomware, up from 44% a year earlier, and vulnerability exploitation drives about 31% of incidents, up from 20% (Verizon 2026 DBIR).
- Defenders are pushing back. 69% of victims didn’t pay a ransom, up from 64% the year before, and the median payment fell from around $150K to under $140K (Verizon 2026 DBIR).
That last shift only holds if you can actually recover. Refusing to pay is a real option when you’re sitting on clean, immutable backups the attacker can’t reach or delete. Immutability takes that option off the table for them.
This is part of a series of articles about immutable backups.
The Tendency to Downplay Ransomware
Although organizations are forced to disclose data breaches, ransomware attacks are, more often than not, downplayed and they don’t give enough information to warrant a proper response from the users affected.
For example, the Minneapolis school district had a tragic data breach that shut down schools for an entire week and exposed more than 189,000 files with secure, personal information. The school district officially called it an ‘encryption event’ and didn’t provide safety protocol in a timely manner.
The company Rackspace had an attack that caused significant outages and disruptions for its Hosted Exchange services. This affected 27 of their customers who couldn’t access their email during the so-called ‘security incident’. Rackspace ended up giving up altogether and had to rebuild their email servers.
Even CodeSpaces, who did everything “right”, went out of business after 24 hours. Why? It simply took too long to recover their data. The fact is that 43% of organizations that lose their data for 30 days end up losing their entire business. And that’s because…
The Biggest Cost Isn’t the Ransom
The cost per hour of downtime to your critical applications is rarely lower than 6 figures. The loss of data is one thing, but the cost to your business of not operating is huge. And in the end, damage to a company’s reputation as a secure business partner will cost them in the long run with the ever-real threat of being shut down entirely.
Even more alarming the healthcare industry, which has been increasingly attacked with ransomware, reported that a rise in cyberattacks leads to increased mortality rates. That’s a high price to pay.
Should You Pay the Blackmailer?
Once you pay the bad actor, what’s to prevent them from coming back? Blackmailers don’t return data and usually never intended to return it. Paying the ransom is no guarantee of anything.
The only guarantee of returning your data is to have a reliable backup and recovery solution in place (more on that in a bit).
Why Is Ransomware so Prevalent?
Besides the draw of easy money, the anonymity of cryptocurrency, and the lack of strong controls with an increasingly remote workforce, another big reason we’re seeing a spike in ransomware is due to something called “Ransomware as a Service” or RaaS.
RaaS is a simple business model that anyone can signup for. It exists on the dark web, Twitter profiles, and many more easy-to-access channels. The malicious actor simply chooses what kind of attack they want and the preferred paid channels. Then the RaaS operator provides the malicious code intended to introduce and attack the organization’s system. No programming skills required! The RaaS market has gotten so competitive that there are different RaaS models competing with each other for business, running marketing campaigns, distributing white papers and drumming up business on Twitter.
How does ransomware work?
- The initial infection can come from many different avenues, primarily phishing emails.
- The execution then triggers and possibly multiplies throughout the corporation’s network and environment.
- Encryption locks data and it suddenly becomes inaccessible.
- Bad actors then send or show a demand combined with a time limit to force a knee jerk decision.
- Payment, when it’s given, is mainly through cryptocurrency so it’s sure to be untraceable. If you’re very lucky, you’ll get an encryption key. But, typically, that data is never seen again.
The Castle Analogy: defending against ransomware
The castle analogy is a convenient visual in order to understand that any single element does not provide a complete security solution against ransomware.
Email filtering, web blocking, software updates, employee training, anti-malware and anti phishing software are all recommended uses for certain levels of defense against invaders. These would be your moats, ramparts, ditches, embrasures, and other external defenses.
But how do you make your castle truly impenetrable? How do you secure the castle entrance? That’s where your backups come in. Your last line of defense, the only guaranteed method to get your data back is having a usable backup that you can easily recover. An effective backup and disaster recovery solution means that you are protected and able to recover your functions when all else fails.
Immutable Backups
Immutable storage keeps a backup in a write-once, read-many state so it can’t be altered or deleted until its retention period ends.
For the full breakdown of how immutability works, its pros and cons, and how to pick a provider, see our pillar guide on immutable backups.
Here we’ll stay on the AWS-specific setup.
How exactly does immutability help us?
All kinds of things can go wrong within your cloud environment. Immutability can protect us against: accidental deletion of a resource, bugs, and previously mentioned malicious attacks. Immutability also captures that ‘golden copy’ of data and satisfies the increasing number of regulatory requirements that companies are mandated to comply with (healthcare and financial companies are particularly affected by this).
Related content: read our guide to Azure immutable backups
Fortify your cloud across every critical dimension.
- Efficiency + Optimization
- Security + Control
- Orchestration + Visibility
Immutability using Amazon S3 Object Lock
Overview of Amazon S3 Object Lock
Amazon S3 is object storage used by millions of customers, and storing backups in S3 is one of the most common uses. S3 Object Lock puts those backup objects in a write-once state, both to meet compliance rules like FINRA, CFTC, and SEC, and to keep a copy safe from ransomware.
Object Lock has two modes, and the difference matters most when the attacker already has admin rights.
- Governance mode. Ordinary accounts can’t change or delete a locked object, but a user holding the
s3:BypassGovernanceRetentionpermission can. It stops mistakes and everyday accounts. A privileged attacker can still get around it. - Compliance mode. No one can delete the object or shorten its retention until the period ends, including the AWS account root user. This is the setting that holds when ransomware has taken over an admin account.
You can also apply a legal hold, which locks an object with no expiry until someone with the right permission removes it.
Enabling Amazon S3 Object Lock
Object Lock needs S3 Versioning turned on. You can enable it on a new bucket or an existing one (AWS used to allow it only at bucket creation, and now supports turning it on for existing buckets too). Set a retention period per object or as a bucket-level default, and S3 stamps a “retain until” date in the object’s metadata at write time, so the object can’t be deleted before that date. Retention can be extended, never shortened.
N2W backs up your AWS workloads to Object-Locked storage as often as every 60 seconds, and recovers near-instantly through its Object Lock integration.
Related content: using N2W Object Lock integration.
One limit worth naming: Object Lock protects the objects, not the account. An attacker who controls your account still can’t delete the locked backups, but they can run up storage costs or cause trouble elsewhere. That’s why the next two pieces, the snapshot vault and cross-account isolation, matter.
Be sure to read through our step-by-step on how to set up your Amazon S3 buckets with Object Lock.
Immutability using Amazon EBS Snapshot Lock
A snapshot is a fixed point-in-time copy, so it can’t be altered once it’s taken. What used to remain was the risk of deletion. Amazon closed that with EBS Snapshot Lock: you lock a snapshot in governance or compliance mode for a set duration, and it can’t be deleted, by accident or on purpose, until the lock expires. It works like S3 Object Lock. In governance mode a privileged user can override; in compliance mode no one can, including the account root user.
So an EBS snapshot can now be immutable the same way an S3 object is. N2W drives this through the native AWS APIs, so its EBS immutability uses EBS Snapshot Lock directly. Same idea across S3, Wasabi, and Azure Blob: N2W calls each platform’s own lock for true immutability.
Related content: read our guide to immutable snapshots
Combine native locks with isolation for air-gapped immutability
Locks and isolation solve different halves of the problem, so the strongest setup uses both. Lock the copies at the storage layer: S3 Object Lock for S3 objects, EBS Snapshot Lock for snapshots. Then keep those copies in a separate account, region, or cloud. A locked copy in the same account still sits one blast radius from the attacker. Put the locked copy in:
- A separate AWS account your production credentials can’t administer, so a compromise of production never reaches the backups.
- A second Region, so a Region-wide outage or a targeted attack on one Region still leaves a clean copy somewhere else.
N2W automates all of it: scheduled backups copied cross-account, cross-Region, or cross-cloud into storage you own, and locked immutable so they can’t be deleted before their retention ends. It runs through native AWS and Azure APIs, so there’s no extra agent or outside dependency in the path, and your data never leaves your accounts.
For the full walkthrough on isolating backups this way, see our guide on air-gapped backups.
Where immutability meets compliance
Regulations like HIPAA, SOX, and GDPR expect retention controls and protection against tampering. Immutable backups support those controls directly, and AWS and Azure provide the HIPAA-eligible storage that immutability runs on.
N2W runs inside your own AWS account and never holds your data, so it supports the immutability and retention controls these regimes expect without becoming a custodian of that data itself. Whether a specific deployment meets a given standard depends on how you configure retention, access, and the rest of your environment.
Bonus anti-ransomware capabilities with N2W
Looking for more ransomware backup strategies? N2W has even more security capabilities built-in so you can rest assured you’re maximizing your ransomware protection.
- N2W can restore itself. What if N2W itself fails? Since it’s deployed as an AMI through the AWS marketplace along with the metadata, N2W can restore itself using snapshots.
- N2W can restore network data. Having the ability to bring back network configurations in addition to resources is extremely important. Restoring your VPC settings, subnet settings, and VPN connections along with your resources is critical in making them available and usable.
- Backups continue running. Even if the N2W agent is disabled, backups are fully restorable.
- Backups are always restorable. N2W backups can be restored even without N2W (using the EC2 console). There’s absolutely no lock-in and this is particularly convenient for those companies that keep backups for 7+ years because there’s no need to worry about restores in the far-off future. (As backup and restore experts, it is extremely important to us that our customer’s security needs come before any forced product commitment.)
- Indestructible backups. You are fully in control of your backups. They aren’t kept on any Windows/Linux machine or network share. There’s no way to improve on snapshots, so backup data never leaves that cloud native format. An attacker therefore is unable to destroy them.
Bonus read: find out why not all immutability is created equal
