🦄 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 - Motability Operations' unified backup strategy: From fragmented to fortified
In this video, Sabith Venkitachalapathy from AWS Backup and Nick Rowe from Motability Operations discuss their journey implementing a unified immutable backup strategy. Motability Operations, serving 860,000+ customers including 100,000 EV drivers, needed ransomware-resilient recovery capabilities. They deployed AWS Backup across all environments using a 3-2-1-0 strategy with three pillars: immutability, isolation, and integrity. The solution features centralized backup vaults in compliance mode, CMK encryption strategy, IAM role separation, and Elastio integration for backup verification with 99.99% detection accuracy. The project progressed through design workshops, proof of concept, and agile deployment across multiple platform teams, achieving enhanced security posture and business continuity resilience.
; 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 Motability Operations and the Case for Immutable Backups
Hello everybody. Welcome to session STG 213, "Motability Operations' Unified Backup Strategy: From Fragmented to Fortified." My name is Sabith Venkitachalapathy. I'm a Senior Solutions Architect with the AWS Backup team. What gives me immense pleasure is that I'm joined by a customer champion who has championed AWS Backup in their organization. I'm very happy to welcome Nick Rowe, who is the Platform Manager at Motability Operations in the UK.
What we're going to cover today is the journey that Motability Operations went through. Nick will take us through what Motability Operations is, the technical drivers, and the challenges they faced. Then I'll rejoin Nick to discuss the journey and solution, where he'll walk us through the entire transformation approach and the milestones that Motability Operations achieved. Finally, we'll conclude and share some of the knowledge with you. With that, I'll welcome Nick to take us through this journey. Now to you, Nick. Thanks, Sabith. So who is Motability Operations?
Well, simply put, we provide all-inclusive leasing for cars, wheelchair accessible vehicles, scooters, and power chairs. We're keeping our customers on the move. The scale of our company is significant: we have over 860,000 customers, actually closer to 900,000 now. Importantly, because we're transitioning to green and electric vehicles, we have 100,000 EV drivers as well. We have excellent customer service satisfaction scores between 9.4 and 10, over 1,500 employees based in London, Bristol, and Edinburgh, and our vision is to deliver affordable, sustainable motability for disabled people now and into the future. We want to futureproof our scheme.
Some of our core values, which we really adhere to at Motability Operations, include finding solutions, listening, adapting, and solving problems together. We drive change and lead the way in motability innovation and sustainability. Most importantly for me, we care. We care about our customers and our employees, the people who work for us. This ethos runs throughout everything we do at Motability Operations.
So why immutable backups? There are many reasons for this. With ransomware and cyberattacks, immutable backups are locked and protected, unlike traditional backups that can be compromised. There's also compliance and audit readiness. Immutable storage meets regulatory compliance with guaranteed data retention and audit trails. There's data integrity and recoverability. Every backup is pristine. We know its cadence and what's in it, ensuring trusted system restoration. You don't go through the trouble of backing up everything only to find during recovery that it's corrupted. Most importantly, there's business continuity and resilience. It provides reliable, rapid recovery and meets our business continuity goals.
Some of the challenges and technical drivers that motivated us to embark on this at Motability Operations include needing a known good recovery state. We needed to know that if we were attacked, we had the ability to restore from a backup that we knew was clean and could have complete confidence in. There was also significant cross-platform complexity in AWS. We've been with AWS since 2018, and our state and footprint across platforms has grown considerably. We had many solutions using native AWS backup solutions across our entire estate. We also had detection and response capability gaps, which leads back to the same question of that known good state recovery. We needed forensics and scanning capabilities that give us the ability to know that we have a good backup. So we embarked on this project, which I've been working on for the last year with a team at Motability Operations.
We created some objectives. We had Moscow requirements for an immutable, ransomware-resilient recovery system. We went out to tender and approached multiple SaaS service providers.
We looked at many different products. In the end, we decided the best way forward was to go with AWS and work with them in delivering this solution.
So what are some of the key deliverables? We needed to deploy an immutable backup recovery system across all our AWS environments and complete handover to our operational team. We also needed updated recovery runbooks and importantly, testing as well. One of the major benefits is that it enhances our security posture and reduces our business impact from cyberattacks. It was truly a win-win for us.
Transformational Approach: Designing and Implementing a Ransomware-Resilient Recovery System
This was our transformational approach, which was structured in four stages. First, we designed a workshop where we got our architects together with AWS architects to work out how we would deploy this solution. Most importantly, before we started building and getting into the details, we conducted a proof of concept to ensure that what we were going to build was feasible and cost-effective, and that all the ideas aligned with our architectural principles. Then we defined which AWS services and technologies were in scope. You don't need to do everything. Some things you could argue that the technology within AWS is so good that you don't necessarily need to have immutable backups, but we had many different opinions in our company. In the end, we figured that immutable was the best choice. We've been deploying this project for the last year across multiple platform teams in an agile approach with different milestones.
I'd like to hand that back to Sabith now, and he can talk through how we partnered with AWS.
Now that you've heard the initial trigger for this project and how multiple operations started with this entire project, what we wanted to highlight is the fact that it was an entirely team effort. The team from AWS came together to work with the Motability Operations engineering team to not just define the scope of the project but to work with Motability Operations to conduct proper threat modeling to understand what Motability Operations wanted to achieve. Like most endeavors within AWS and with our customers, we started working backwards from the end state. That defined this entire exercise of what exactly is the way forward.
We started with the joint development of comprehensive protection requirements, which was a critical aspect of this entire project's success and laid the foundation for a long-term execution strategy. Once we defined the actual end state, it was much easier for us to work backwards from that end state. What worked well was defining the 3-2-1-0 strategy, an industry standard framework, and adapting it to Motability's requirements. We had the opportunity to work with multiple engineers, the AWS account teams, and the worldwide specialist organization from AWS. The 3-2-1-0 strategy is an industry-defined approach, but what we did as a combined team was adapt this strategy very specifically for Motability's requirements.
The focus of this entire project was immutability, isolation, integrity, and high availability, which we call the three defining pillars of a successful recovery strategy. This was not a one-off project or exercise. It was a continuous exercise wherein we monitored the success of the project, evaluated where we were continuously on the design and implementation, and adapted the course of action as required. The major highlight of this entire project was that it was completely tailored for Motability's requirements. It was about working backwards from what Motability wanted to achieve and how they would be able to get to the business outcomes they were pursuing.
With that, I would invite Nick back to take us through the solution and how they went through this.
We had an event-driven copy workflow using the EventBridge product to trigger a Lambda that successfully backed up replication with CloudWatch monitoring and retry logging. We also developed a CMK strategy, spending considerable time working out how it would function with key management across this project. We came up with a consistent CMK implementation across all platform intermediate vaults and manual management until automation deployment. Importantly, we also implemented IAM role separation with distinct roles defined for backup creation, management, and recovery, with no overlapping user assignments.
This solution was developed by someone more clever than me, so I won't go through the whole thing, but effectively, as you can see, we have a workload account that goes to a centralized backup. We also have a forensic account, and this is where Elastio comes in. This is where we know that we have a good recovery point, and an admin account as well, along with our recovery account.
These were the backup tools built for us. We had a centralized immutable backup vault, which is our tier two, and that separates the vault per platform, locked in compliance mode and separated by retention policies. Then we had an account-level backup at tier one with intermediate vaults encrypted with CMK 2, and there is one CMK 2 per platform. Some of our platforms are Motability-specific platform names: ADOS Native, Osmo, and NCW. Both tier one and the intermediate vaults are locked in governance mode.
We also had a backup workflow based on resource type with separate vaults per platform, again locked in compliance mode and separated by retention policies. Then we had an event-driven copy workflow with separate vaults per platform, locked in compliance mode and separated by retention policies. For our CMK strategy, we have separate vaults locked in compliance mode. You can see that compliance mode, retention policies, and your key and certificate management policy are crucial to this solution.
There are three pillars of ransomware recovery. First, immutability: backup data is stored in an air-gapped environment that cannot be accessed remotely. Second, isolation: the backup data cannot be changed, detected, or tampered with. Third, and crucially, integrity: backup data is verified, clean, uncompromised, and recoverable, and we use Elastio for this.
The Elastio platform covers several services including EC2, S3 buckets, AWS Backup, GuardDuty, and EFS. It detects hidden data compromise through a machine learning-driven engine that proactively scans backups for encryption and corruption, with a 99.99% detection accuracy. It ensures uncompromised recovery points, and there is no point doing this if what you are going to back up is being compromised, as it defeats the whole purpose. So we have confidence in that backup. It integrates seamlessly and has integrated seamlessly with our AWS accounts, and it has been very easy to implement.
Project Timeline, Outcomes, and Key Recommendations for Data Protection at Scale
In January 2025, we started our technical planning. Then in February, we moved to a centralized AWS backup account setup, and in March, we configured the forensic account and Elastio. Now we have been working through all our AWS accounts, and the first couple were challenging, but now it is like a sausage machine as we go through all of them. We have pen testing and auditing scheduled for November, which has been completed with a few findings, not many at all. We have low-level documentation and project closure, which was supposed to be December but is now pushed more to January and February, but we are getting there.
I will just send a few segments for the conclusions. Thank you, Nick. Hopefully that was a good learning experience that you can all be excited about. So what really matters, what are we concluding with this one? We had a very amazing partnership journey with multiple operations in ensuring they could implement their data protection strategies at scale using AWS Backup.
If you're in a similar state wanting to get through your journey of ensuring that you have a proper recovery resilience strategy in place, we would recommend that you get started with a proper vision. Defining what exactly the end state is represents the most critical aspect of this.
Then, as with most of the projects that we work on, we would like to work backwards from the vision that you have set up. That's where the AWS team comes in handy for you. We work closely with our customers in helping them define not just the explicit requirements, but also the implied requirements and ensuring we define the proper end state. Once you have that defined, it becomes much easier for you to work backwards from this and make high velocity two-way door decisions as much as possible so that you could always adapt and refine your journey in such a way that you would be able to achieve your end state in a more secure and cost effective way.
We would always recommend that customers utilize automation as much as possible. Some of the reference architectures that we mentioned here include blueprints available for implementing forensic accounts, recovery accounts, or even your central cyber vault accounts. All of those include your least privileged permissions that you can set up, including the defense in depth strategies that you can pursue. Obviously, as most of the customers embarking on a generative AI or an AI-driven strategy, there are more opportunities for you to utilize AI agents to automate most of the tasks as possible.
Some of the examples that most of our customers embark on is to use the Well-Architected Framework that is provided by AWS and to look at the AWS Backup implementation and then probably define where the alignment mismatches are and then adapt accordingly. We have also seen customers utilize AI agents at scale to automate some of the recovery aspects of it. With that said, we would definitely like to improve upon the experience that we have provided to you. If you have any feedback on the session and if you would like to reach out to us, there's always a feedback form that you can utilize as part of the re:Invent app, and we are available for offline conversations. Thank you very much.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)