🦄 Making great presentations more accessible. This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Protect your data with AWS Backup: overview, use cases and what’s new (STG207)

In this video, Palak Desai and Bisman Sethi from AWS Backup present the service’s capabilities for protecting data across 20+ AWS resources. They announce 2025 launches including support for Amazon EKS, Redshift Serverless, and Aurora DSQL, plus enhancements like S3 backup tiering, direct copies to logically air-gapped vaults, and GuardDuty malware scanning integration. Chuck Uwanna from ExxonMobil shares their proactive resiliency strategy using immutable backups, automated orchestration, and isolated recovery environments to defend against ransomware. Rooshir Patel from JPMorgan Chase discusses their five-year journey implementing AWS Backup to meet strict regulatory requirements, emphasizing recoverability testing, cross-account/cross-region backups, and continuous compliance alignment with on-premises controls. The session highlights AWS Backup protecting 3.8 exabytes of data for over 1,500 customers.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction to AWS Backup: Protecting Growing Data at Scale

Hello everyone. Welcome to STG207. The session is Protect your data with AWS Backup: overview, use cases, and what’s new with AWS Backup. I’m Palak Desai. I lead product management for AWS Backup. Joining me is Bisman Sethi. She’s also a PM on the team. We also have our esteemed customers Chuck Uwanna from ExxonMobil Global Services Company. He’s going to talk about his journey with AWS Backup. And Rooshir Patel from JPMorgan Chase who’s also going to talk about their journey with AWS Backup. So let’s get started. We have an exciting agenda ahead of us.

From a viewpoint of what I’m going to cover today, we’re going to talk through why AWS Backup matters and why we should protect our data. We’re also going to discuss what is new with AWS Backup. We’ve had an exciting year in 2025 with many key launches, and we’re going to walk you through those launches. You’re going to hear from our customers how they are progressing with AWS Backup and what data protection means to them. We’ll round out with the customer journey from Exxon and JPMorgan Chase, our customers who are going to present their journey with us, and then we’ll conclude the session.

Just to call out, and I’ll post the slide at the end, there are many exciting sessions around what is new with AWS Backup, data protection, resiliency, and ransomware in general. I’ll flash the slide at the end, but please take a look and attend as many sessions as you can. All right, let’s get started. Now we all know that data is growing. Customers like yourself use data to run their businesses. We use data to better serve our customers. We use our data, for example, from the healthcare industries to go back in time and understand how our health is progressing. We use financial data to make decisions which better serve our customers. In general, customers like yourself are using data to drive their business, so data has value and data is growing.

As a result, we want to protect that data, and AWS Backup provides you with capabilities that allow you to protect that data. Quick facts: I want to thank all my customers. We have greater than 1,500 customers and growing. We refresh this stat every year at re:Invent and we are protecting 3.8 exabytes worth of data. So thank you so much for placing your trust in the service.

AWS Backup Capabilities: Centralized Data Protection Across 20+ Resources

From a what-we-do perspective, AWS Backup is the native solution for centralized data protection. We protect data sitting in the cloud across all of our AWS state for resources such as Amazon EBS and Amazon S3, and so on and so forth. We cover 20 plus resources that we protect. We’ve also extended into hybrid scenarios through our protection for VMware backups, so we can take a VMware server and back it up. We have that coverage from a viewpoint of data protection.

Double clicking in, what do we really do? We provide a fully managed service that centralizes and automates data protection via policies across 20 plus resources. As you can see, I’m not going to walk through the entire slide or each resource one by one, but you can see we have coverage across compute, block storage, object storage, file storage, databases, management, applications, and hybrid via AWS Backup support for VMware and SAP HANA. You see there is a new block that’s emerged this year on the slide which is containers. I’m very pleased to announce that we released our container support for AWS Backup support for Amazon ECS earlier this month at re:Invent and it’s well received by customers. It was a direct customer ask for AWS Backup and we have delivered on that promise and we’ll talk about all the launches in detail in later slides.

On top of basic data protection, we provide things along the lines of search and item level recovery, logically air gapping of your data for ransomware protection, restore testing, malware scanning, and auditing. So we have a slew of capabilities that we provide on top of the data that gets backed up. Some of the use cases that our customers use us for are on the slide. Of course it starts with backups, so we provide cloud native backups for 20 plus resources and growing. This year we have added support for Redshift Serverless. We have added support for Aurora DSQL, and we’ve added support for Amazon EKS. So we have expanded the number of resources that we back up data for. You can recover from the backups for use cases such as disaster recovery. Say you fat fingered and deleted a bunch of files, and if you want to recover, you can recover.

If a natural disaster like an earthquake occurs and you need to recover in a different region, you can restore from backups. Many of our customers operate in regulated industries, so they require reporting on their backup posture. We have capabilities built into our Backup Audit Manager to provide reports that you can share with regulators to demonstrate how you are backing up data, what you are backing up, where it is stored, whether it is encrypted, and what the retention period is. You can customize these reports based on your specific needs.

Our final key pillar is ransomware recovery. Many customers have asked us what we do when they face a ransomware attack. The critical question is how to recover applications from backed-up data to ensure successful recovery from a ransomware event. We have developed a range of capabilities in this space through our logically air-gapped vaults and extensions of that portfolio that we will cover in this session.

2025 Launch Highlights: New Resources and Enhanced Ransomware Protection

I am not going to walk through all the line items on the slide, as it is quite comprehensive. I will give you a few moments to review the slide. As you can see, in 2025 we have been very busy and launched many capabilities. We added support for new resources including Redshift, Aurora DSQL, and Amazon EKS. We have also strengthened support for existing resources by creating tiered storage at low cost for longer retention. For S3 backups, we have made enhancements to our RDS backups and will continue to progress on that front.

On the ransomware protection side, our notable launches, which Bisman will cover in detail, focus on enhancing capabilities for logically air-gapped vaults and adding malware scanning via GuardDuty. We will continue working on our platform to improve operations and resiliency. We will work through performance improvements so you will see backups becoming faster and more efficient throughout the year. We will also work on visibility and extend our platform to new regions as they become available.

Deep Dive into Key Features: Logically Air-Gapped Vaults and GuardDuty Integration

With this backdrop, I would like to invite Bisman Sethi, who works continuously with customers like yourselves, to walk through some of our key launches. Thanks Palak, and as Palak mentioned, we have been really busy this year. It is great to see all of the customer feedback we receive from you continuously, and being able to deliver on those requests is rewarding. I am going to deep dive into a few of our key launches and the enhanced capabilities we now offer. All of these are now generally available, and we will continue, as Palak mentioned, to keep enhancing these as we move forward.

One of our first key launches this year was enhancement for logically air-gapped vaults. Taking a step back, a logically air-gapped vault is a capability we launched last year for our ransomware protection pillar. A logically air-gapped vault is a vault that is air-gapped in nature and stored in an Amazon-owned account. Those vaults are locked by default with a compliance vault lock to ensure immutability. This year, to enhance ransomware protection, we added multi-party approval, which means you can create a secure trusted group of people that requires quorum, or three out of five users, to approve any sharing of that vault across organizations or when a restore is required during a ransomware event.

With this addition, we have added a critical layer of security to the logically air-gapped vault for enhanced ransomware protection. More importantly, this allows for faster recovery time objectives because it enables direct restore outside of your organization. In that same vein, we have continued to improve based on direct customer feedback requests. The first improvement is support for direct copies to a logically air-gapped vault. Previously, in order to store a backup in your logically air-gapped vault, you would need to create a copy in your production account and then copy that backup into a logically air-gapped vault. While we designed it that way to provide enhanced capabilities by keeping two copies of your backups, we received direct feedback from customers who had different use cases in mind for this feature.

What we now support is backing up your backup directly from your workload account to a logically air-gapped vault.

For those additional use cases, it does provide an additional cost-saving measure, so you don’t need to keep two backup copies. The second feature is expanding support for CMK, or customer managed key support, for logically air-gapped vaults. By design, our default encryption for a logically air-gapped vault is an Amazon-owned key, and the thought process behind this is that in a ransomware event, if you lose access to your keys, you would still be able to restore your backups in the air-gapped vault.

However, we do understand that customers have different requirements, whether compliance requirements internally or externally. So with this feature, we do give you the option to encrypt your backups that are stored in a logically air-gapped vault with a customer managed key. Here is a typical reference architecture of how a customer may be implementing a logically air-gapped vault today. In the left corner, you’ll see a customer’s workload account where they are backing up their S3 buckets and EBS volumes into a standard AWS Backup vault. What you can then do is copy it into this logically air-gapped vault for that second layer of protection and immutability.

At the bottom, you’ll see what some customers do to manage access to their keys by having a separate key vault account where their CMKs are managed, and in this case, using their customer managed key to encrypt the backups in this logically air-gapped vault. Up top, you’ll see two additional accounts where the logically air-gapped vault has been shared for two separate purposes. The one at the top is a forensics account. This is where customers typically want to isolate their workloads to do forensics on their backups, such as restore testing.

Restore testing is another capability that we have where customers can actually restore their backups periodically and validate that their data is there as expected. In the backup world, your backups are only as good as their restores, so we do encourage this for those very critical workloads. At the bottom, you’ll also see the AWS recovery account, and this is what we mean in terms of a ransomware event or any event that you might have from a security perspective. A logically air-gapped vault does allow you to share that vault across organizations or accounts.

Here you’ll see we added the multi-party approval access. With that new multi-party approval feature, you can opt to have, say, three out of five people ensure that they have validated this sharing of the logically air-gapped vault so you can restore it into your clean environment. With that same thread of ransomware protection, we’ve also invested in an integration with Amazon GuardDuty for malware scanning of your backups. While our backups are stored in this immutable fashion, we also know that customers want to be able to ensure that their backups are clean and safe to restore, and that’s why we added support for Amazon GuardDuty.

Expanding Protection: S3 Backup Tiering and Amazon EKS Support

At launch, you can now scan your EC2, EBS, and S3 backups for malware, and you can do this in two ways. One is on a periodic basis, so as part of the backup plans and policies you set, you can now opt into scanning these backups, which means that you can have the scans of your backups as the backups are taken. Therefore, if any anomaly is detected, you’ll be notified immediately and you can proactively triage the issue. But what this also does is allow for secure restores.

We often hear that customers want to be able to restore to the last known good state of time. With the on-demand restore capability, before you do restore, you can restore it to a new set of principles in this case, and you can do an on-demand restore to double check and ensure that your backup is clean before you put it in that account. In addition to our ransomware capabilities, we’ve also added support and continued to improve our existing backup capabilities. So with this launch, S3 backup tiering provides a way for customers to find cost optimization for those long-term retention backups over 60 days.

How this now works is for your S3 backups, you can choose to tier down the objects in your backup to a lower cost storage tier if those backups and objects are retained for longer than 60 days. You can go in and configure when you would like those objects to be tiered down to based on your requirements and what makes sense from your cost savings perspective.

How this actually will work is after 60 or greater days, depending on the configuration you’ve put, you will be charged a one-time object transition fee which is meant to be quite nominal, and then those objects will take advantage of that lower cost storage tier. What makes this unique and is not a cold tier, if you will, is that this has no impact to restores or any performance. Therefore, we’re calling it a tiering option and it won’t operate as a cold storage that you may be familiar with either from AWS Backup or other usage.

Lastly, I want to highlight one of our other key launches that Palak mentioned was that we’ve added support for Amazon EKS. As we keep continuing to grow our Amazon footprint of what we support, I think this is a really interesting launch for two reasons. One, this is following the trends of how customers are now using EKS and how that’s transitioned since the birth of Kubernetes. Today we’ve seen that a lot of customers are now running stateful workloads on their containers versus stateless, which is what’s really driven the need for this protection.

So when we say an EKS backup, we are saying that we will back up your EKS cluster state, so the Kubernetes objects, deployments, and all the resources that are running on your cluster in addition to the persistent storage that is attached to your cluster. At launch we’ve added support for Amazon EBS, Amazon S3, and Amazon EFS that’s attached to your cluster, and as a backup we will take a backup of all of these components and create a composite recovery point which will then allow you to restore either just the storage or the full cluster.

To make sure that you do have that continual immutability for EKS, there’s no agents required to actually enable this, so you can now add a tag to your clusters or assign these to your existing backup plans and then back them alongside your additional resources. With that, I’m glad that we were able to showcase what AWS Backup is and some of our bigger launches, but who better to hear how AWS Backup is benefiting them than some of our customers. So I’d like to invite Chuck on stage to talk about how AWS Backup is being deployed at ExxonMobil and a lot of their learnings.

ExxonMobil’s Proactive Resiliency: Building Cyber Recovery Capabilities in AWS

Thank you. Ransomware attacks are the deadliest threats that our digital assets face anywhere—on cloud, on premises, even at our homes. Nothing is immune from ransomware attacks. But that’s why we’re here. That’s why we’re all gathered here today to explore strategies, tools, and techniques that we can use to not only secure our digital assets from ransomware attacks, but how we can recover those assets if an attack does indeed happen.

And that’s important. The conversation we’re about to have today is critical because in recent years ransomware attacks have disrupted global enterprises. They have brought operations to a halt, corrupting data and resulting in huge cost overruns in recovery and reputational damage. Hospitals and healthcare systems are not immune from ransomware attacks. Some of them have had to turn away patients because their systems were locked and their data was corrupted.

When Colonial Pipeline was hit by a ransomware attack, it wasn’t just a cybersecurity issue. It was a disruptor for fuel supply across the eastern United States. It triggered investigations and cost millions of dollars in recovery. JBS Foods paid 11 million dollars to regain control of its systems and data.

These are not isolated events. These are business continuity failures with wide-ranging national impact. Many experts believe that ransomware attacks are a matter of when, not if. They are almost inevitable. We cannot foretell the future, and we do not invest in crystal balls. What we at ExxonMobil have invested in is what I call proactive resiliency. It is an insurance policy that we take out so that if an attack does indeed infect our systems, we can recover in a rapid, secure, and safe manner. We are investing in strategic cyber recovery capabilities—not just backups, but secure, orchestrated, on-demand, isolated environments that enable us to restore critical workloads in the event of an attack.

My name is Chuck Uwanna. I am Principal Application Architect for Strategy and Modernization at ExxonMobil. I have also led a cross-functional team of experts to build out what I have described as proactive resiliency. We did that in AWS, and today I am going to tell you why we did it, how we did it, and share some key takeaways. When we set out on this project to reimagine our cybersecurity capabilities in AWS, our mission was clear. It was to enable secure performance and on-demand recovery of critical workloads in the event of an attack, and we wanted to do this for our global footprint, for all of our resources wherever they are located.

We started with a set of core principles—about three of them. The first one is immutability. We wanted our backups to be tamper-proof. We wanted every time a backup is taken to not be overwritten. The second one was orchestration. Recovery must be automated and repeatable. We do not want a lot of manual intervention because when our systems are attacked, we want to be able to recover in a rapid fashion. Last but not least is isolation, and isolation is key. It is crucial because we want to ensure that recovery happens in a clean and secure environment. The last thing anybody wants is to suffer another ransomware attack while recovering from an attack.

Why did we choose AWS? There are a few reasons behind that. We did have previously robust cyber recovery capabilities on premises. But as we all know, it is hard to scale on-premises hardware. It is difficult to do that, and it is also expensive. It takes an army of IT professionals like me to go in and perform a recovery exercise successfully. That is one set of reasons. The other reason is that over the past few years, our company has been migrating mission-critical business applications to AWS. These are applications that have large data requirements, so we are moving our on-premises data center to AWS. Because of these factors, it made logical sense and strategic sense for us to co-locate our cyber recovery capabilities adjacent to our production systems.

We have air-gapped isolation. In addition to the scalability and native security that we get from the AWS platform, we have the benefit of leveraging immutable, air-gapped, isolated systems. We can also use automated ephemeral system environments that we can spin up on demand. We can do this when we’re testing, and we can do it in recovery from an actual attack. The reason ephemeral environments are important for us is that they save us costs. We don’t have to pay for stateful environments for recovery when they are not in use. But they also reduce our attack surface because a malicious actor is not going to be able to attack something that doesn’t exist.

Now, how did we do this? How did we square the circle of our requirements, those core principles that I mentioned earlier—immutability, orchestration, and isolation? How do we resolve those principles with AWS solutions? This is how we did it. At least this is fifty percent of how we did it. I have broken up the backup and recovery aspects of our solution, our proactive resiliency solution, into two parts just so it’s easy for us to review. This is not too dissimilar from the reference architecture that was shared earlier.

We leverage AWS Backup. AWS Backup provides the policies that we use to make sure that we write once and read many. We enforce those policies. We secure our backups immutably in lag vaults, and that provides us with the isolation and immutability that we need. Now I want to take a moment to step through the diagram that you’re looking at. You see the white box that is the workload organization. It could be anything at your enterprise—a production organization, for instance. And then we have three kinds of accounts denoted by the pink boxes that you see inside of that rectangle.

The backup delegation account, the smallest box, is the orchestrator of this whole thing. It is the brains behind the whole operation. AWS Backup leverages policies to orchestrate backups within what we call the cyber application account, and that’s the medium-sized box that you see towards the top of the rectangle. Within the cyber application account, by the way, there could be between one to many cyber application accounts depending upon your use case. At our enterprise, we went through an effort to identify, based on certain criteria, what applications we term cyber applications, and then we leverage a tagging mechanism to let AWS Backup know to back up the resources within the cyber application accounts and store them in a backup vault.

I want to put a pin on this because it was shared earlier that there are new features that AWS has rolled out in the past couple of weeks: the direct to lag vault feature. That is a real efficiency opportunity for our enterprise because previously we would stage backups in the backup vault. It was required, but it wasn’t doing anything for us. The direct to lag vault feature removes the requirement to store backups in the backup vault. Not only does this make for efficiency, but it also reduces our costs. I did the math for our workloads, and it saves us about seven percent. That’s seven percent in total cost avoidance by just eliminating that staging step. So that’s kudos to the AWS team for rolling out the direct to lag vault feature.

Within the Cyber App Account, you can back up applications directly into the larger clear air gap vault, and I want to touch on that because that’s the larger box that you see at the bottom of the rectangle. The logically air-gapped vault is the central repository for our immutable backups. That’s where we store them, and because of one policy, they’re not going to be overridden. We’re still leveraging AWS KMS keys, the AWS managed keys, but thankfully the customer managed keys are now available for us to use in the Cyber Recovery Backup Account where the logically air-gapped vault is located.

One more thing that I want to mention in this diagram is that we are doing all of this work and thought process went in because we want to make sure that our golden goose—see the little thing with the halo—the backups are inviolate, untouched, not tampered with. That’s the key here for a successful recovery: a clean backup that hasn’t been tampered with. For ease of readability, I have brought in the previous box showing the Cyber Recovery Backup Account just so we can see how we recover and restore resources from the logically air-gapped vault into a new Cyber Account that we just created.

I mentioned a while ago that ephemerality is a big thing for us. We don’t want to pay for stateful environments, and it also reduces our attack surface. So leveraging the AWS Resource Access Manager Share, or RAM Share, we can share, not copy, but we can share the logically air-gapped vault into a new Cyber Application Account that we’re trying to recover into. Once it’s in there, we can find a recovery point that our cybersecurity team has previously analyzed and told us is no good. The restoration process for this is fully automated. Within a couple of minutes, we have our EC2 instances that were backed up in the previous flow, our S3 buckets, our EBS volumes—they’re all available again, all of that in an automated fashion.

That’s precisely how we are enabling proactive resiliency measures in AWS. Now I want to talk about some takeaways. If you take nothing away from this presentation today, I’d like for you to remember that the best time to plan for an attack is before it happens. Resiliency should always trump reaction. Always. That’s what we’ve done here by deploying proactive resiliency measures to emerge stronger from a ransomware attack.

We used immutable backups stored in air-gapped vaults to make sure that our data is not corrupted. We used ephemeral recovery environments that are isolated from corruption because we don’t want to be infected again while recovering from an attack. But there’s a key piece that I haven’t talked about until now: recovery automated recovery tests. You need to test your backups for recovery as frequently as possible. When the world has ended, anything that can go wrong will go wrong. So you increase confidence in your backup and recovery processes if you can frequently test recovery in ephemeral environments.

I opened the presentation by talking about ransomware as a matter of when, not if—the inevitability of ransomware attacks. That’s why at ExxonMobil, we don’t rely on crystal balls. We rely on proactive resiliency measures, and I’ve shown you exactly what that looks like.

Resiliency measures are an insurance policy. When an attack does happen, we’re not going to be sitting ducks. We’re going to have our ducks in a row for a rapid, secure, and safe recovery. Thank you for your time. I hope you enjoy the rest of re:Invent.

JPMorgan Chase’s Journey: Meeting Regulatory Requirements with AWS Backup

Thank you, Chuck. So it’s a great customer journey that Chuck just outlined. We have yet another great customer journey and outcome with JPMorgan Chase. I would like to invite Rooshir Patel on the stage.

Hey Rooshir, great to have you here again. We have been working together for the past five years. Tell us what is data protection from JPMorgan Chase’s standpoint and what does your team do?

We essentially back up and, more importantly, recover the data for the firm. From our standpoint, we have a bunch of slides here that you can read through offline, but we thought we’d make this a bit more interactive. We ensure that we enable the business to recover their data. We ensure that resiliency and availability are there. We make sure that the solutions we have are flexible and that they’re scalable.

But at the end of the day, as you said earlier on stage, no one really cares about backups. It’s more about recoverability, and that’s what we’ve worked a lot with your team and yourself over the last few years on. The last thing you really want is to have backups with data that you can’t recover. You want to be able to make sure that when there is a need—say a disaster, fat fingering, ransomware, whatever it may be—you’re able to bring your applications back online based on the data that you’ve backed up. That’s the insurance policy that backups give you.

Yes, backups are very important, but restorability is the key as well. You have really helped us shape the service. Tell us how AWS Backup has evolved to meet your needs. How have your needs evolved and how has the service evolved?

Five years ago, our conversation was about data durability. It really wasn’t about the number of copies for us. We’re highly regulated, and we want to ensure that we have logically segmented and air-gapped copies of data both on-premises and off-premises. The solutions we’ve built over the last ten years on-premises are built to meet regulatory requirements for the strictest regulators. Think of Singapore MAS and HKMA in Hong Kong.

A lot of what we had to do with you and your team was to ensure that the same type of governance and the same type of structure and infrastructure-related capabilities that we built out, you could abstract and build natively in AWS. That’s been our journey of how do we get to good so that we have the same parallel features and functionalities on-premises and off-premises, especially as we’ve been working over the last year and a half on hybrid workloads.

Perfect. So as Rooshir mentioned, there are lots of regulations and lots of visibility requirements and compliance requirements that banks like JPMorgan Chase have to deal with, and many customers that we serve. Some of our requirements around isolation and reporting have really come up from direct customer feedback from customers like ExxonMobil and JPMorgan Chase. Tell us more about some of your key controls and things that AWS Backup has done over the course of the last year that you can now influence within your protection strategy.

For us, we have to be able to show that it’s a backup, that we actually have a backup, and that we tested it. We created backup plans and restore plans with you all. We test most of our critical applications and recoverability at a set frequency. You all allow us to do that in a pretty seamless way and in a scheduled way as well. We take that and we evidence it. We evidence not only the backup but the recoverability. We provide telemetry on the backup, so the ability to make sure that the backup was successful. We show that if you have a backup, you certify that at a set frequency. If you don’t have a backup, you certify that you don’t need a backup. On top of that, we look at recoverability—the ability to wipe a host and rebuild it from scratch, the ability to recover from an immutable backup, and the ability to do an SRDR event.

All those things we’ve worked with you and your team on to ensure that what we do on-premises translates to what we do off-premises. The same controls that apply for us on-premises are the exact same controls that we’re using off-premises as well. Whatever we do on-premises to match those controls and evidence them, we work with you to ensure that we can do the same. That’s also spanned across new workloads as we light up new workloads with you all.

We make sure that we can back up and recover those natively through AWS. We also ensure that we have features that are lit up per region, which has been a concentrated effort for us as we’ve gone live with new regions. Over the years, we’ve also looked at cross-account backups, cross-region backups, and Backup Vault, along with all the telemetry monitoring that we’ve enhanced to ensure that we can provide the same level of telemetry on-premises and off-premises.

We’ve also looked at encryption at rest, encryption in flight, role-based access, and access management in general. We’ve examined the lifecycle of backups, looking at minimum retention and maximum retention as we segment what is operational recovery with a set time for those backups versus archive, which has a completely different system. We’ve worked with you on these four different types of retentions and also on the ability to ensure that through Terraform, tagging was there. Tagging took us quite a while to get right, but it allows us for the observability and telemetry.

Most recently, we’ve looked at the alerting and monitoring that you have in place. If you look at vendors like CoECD, Commvault, Veritas, and NetBackup, it’s very granular. NetBackup had 2,000 error codes, whereas you don’t have that yet. You have the minimum things like long-running backups or backup failures, but we’re building out that granularity to match what we have on-premises.

As Rooshir mentioned, we are enhancing our roadmap to meet the requirements of customers like himself and you all, with fine-grain encryption and access management. These are key to your backup posture. You want to make sure that the access to that backup is restricted. You want to make sure that you have the right monitoring tools in place and the right backup lifecycles. Tagging is very crucial because as soon as you tag your backups, they get picked up by the policy, and that’s the beauty of AWS Backup. You just tag your resources the right way and they get picked up by AWS Backup, so you can now instill backup management at scale, which is what’s been done within the bank.

Continuous Compliance and Session Wrap-Up

We talked about compliance and governance as well. When you look at immutability, we talk about the same thing that we have on-premises and off-premises. It’s the ability to have segregated credential backups and to have backups in distinct locations. We have cross-account, cross-region with you, and we have Backup Vault, but all of that is viewed by the regulators as the same. They don’t care if you have it on-premises or off-premises. We have to show continuous compliance that what we’re doing in principle is the same with you as we do on-premises. That continuously gets audited, and regulators have RFIs that come through on an annual basis.

If we look at the overall alignment, I think five years ago you guys were asked why. I think now you guys ask less about the why and more about how can we get this done and what’s the key driver. Service has certainly evolved. We are addressing more and more use cases and more and more requirements as can be seen in the 2025 launch this year. We have come up with so many new launches, and this has been directly influenced by customers. Customers are the ones who have told us what we need to do and when we need to do it.

With this, I’ll round up our session. I would love to say thank you to all of you for being here today and spending the time with us. There is a small survey, so please let us know how we did and what you would like to hear. There are more sessions on AWS Backup related capabilities. We’re talking about ransomware recovery, cost optimization, and resiliency in general. There are tons of sessions, chalk talks, and whiteboards. Please feel free to attend them, give us feedback, and let us know what you would like to hear next year.

Thank you so much. Have a good day.

---

; This article is entirely auto-generated using Amazon Bedrock.