Resilient systems keep businesses running, which is especially important in heavily regulated industries such as financial services, healthcare, and transportation. A frozen trading system, a hospital losing patient records mid shift, or disrupted flight data all carry real consequences for the people relying on them. Customers in these industries are regularly audited and must demonstrate that their architecture can withstand disruption. AWS supports these companies with three resilience services: Fault Injection Service, which stress tests systems to see if they break, Application Recovery Controller, which gets things running again after they do, and Resilience Hub, meant to tie the customer journey together.
All three services launched in rapid succession in 2021, and I took on design leadership in 2025, when two designers from the services joined my org. In the first four years, the three services scaled to meet growing customer needs, but grew increasingly complex and disjointed along the way. A key factor: the services were split across two different leadership teams. We conducted research and customer journey mapping that revealed customers were struggling to onboard, go deep within any single service, and connect the three services together to complete their workflows.
With the UX team leading the design, we launched the Next Generation Resilience Hub in May 2026, bringing system architecture, topology maps, and AI powered assessment, remediation, and dependency discovery into one service. Prescriptive Testing was added in August 2026, making it far simpler for customers to get started running resilience tests and to grow their practice from there.
Customers choose to move to the next generation experience or continue with the original Resilience Hub, so the new unified service could roll out without disrupting anyone already relying on the old workflow.
Our research showed customers struggled to understand their system, working from a series of disconnected tables instead of seeing it end to end. We redesigned that into a full topology map customers can explore, and check against their own mental model of their architecture.
AI groups a customer's resources into service functions, the logical pieces of their application, like frontend delivery or payment processing. Customers can edit those groupings to make sure they reflect their service accurately.
AI evaluates a customer's architecture against AWS Well-Architected best practices and surfaces specific failure modes, ranked by severity. Customers review and act on each one instead of guessing where their system is exposed.
Fault Injection Service, Application Recovery Controller, and Resilience Hub shipped independently, though they served one customer job: understand a system, test it, and fix what breaks. Resilience Hub covered understanding a system's architecture, assessing it, and setting policy, but there was no clean bridge from there into testing. Fault Injection Service was nominally merged into the Hub, but not in a way that worked well, and recovery, through Application Recovery Controller, stood apart from both. Every extra hand off meant lost context, a real risk for a regulated customer preparing for an audit, or a system where downtime carries real consequences, like financial services, healthcare, or airlines.
Customers navigated large scale architecture through a series of tables and connected resource screens, leaving them to derive the full system mapping in their head instead of seeing it end to end. The original Resilience Hub could only reason about resources a customer explicitly imported, so anything undeclared was invisible, and nothing checked whether that declared picture still matched what was actually running. That gap, between what customers thought they had told the system and what was really deployed, is where resilience problems hide.
Fault Injection Service required customers to build a template, then run an experiment by selecting targets from the application structure they had already defined in Resilience Hub, an overwhelming set of steps for anyone who had not tested before. Resilience Hub separately required setting up metrics and deciding whether they were meeting a goal. The tie between the two services was murky, and Fault Injection Service had effectively been shoehorned into Resilience Hub, creating further confusion about how they related.
Many of our largest customers already relied on the existing services as a critical part of their daily workflow, and whatever we built next had to leave that workflow intact. Strategically, that meant designing a new unified service that worked alongside the old ones during the transition.
Large organizations had many teams contributing to the overall system. Separate teams often owned individual services, and the combination of those services created an entire user journey. As a result, it was difficult to keep up with all the changes happening at the individual team level, at scale, which created risk exposure.
Findings roll up across all of a customer's systems and services into a single queue, so a team can triage by severity and category instead of checking each service on its own.
Each finding explains why it matters, in the context of a customer's own architecture, and comes with AI-generated recommendations for mitigating it, watching for it, and testing against it.
Customers can see and edit the assumptions driving each assessment, agent inferred or their own, so the AI grounds its findings in how the system actually behaves instead of guessing. They can also add service design files, giving the AI additional context to work from.
Design presented an overall vision to build Resilience Hub into a single service that guides customers from start to finish. We moved system definition away from grouping resources by technical dependency and toward System and Service: a System reflects a customer's actual user journey, and each Service is a piece of that journey that could break on its own. We aligned the site's structure to match the customer journey phases we uncovered in research.
We replaced the manual testing workflow, building a CloudFormation template, deploying a Fault Injection Service experiment by hand, and reading CloudWatch to judge the result, with pre built test templates the product builds, targets against a customer's already discovered resources, runs, and scores automatically.
I pushed for this, drawing on research across several of the services under my purview that pointed to the same theme: customers needed a way to visually navigate their system. The design lead and I carried forward learnings from an earlier resource map we had shipped for the Load Balancing service, which had measurably reduced support tickets for a top customer issue. Resilience Hub's topology map builds on that same approach, generated automatically from a customer's actual resources rather than assembled by hand across tables and screens. Customers can see how their services connect and check that picture against their own mental model in one view.
We built a multi agent system that analyzes a customer's current topology, evaluates it against their policies, supplied business context files, and AWS Well-Architected best practices to generate findings and recommendations. Customers can feed back into the system by updating the assumptions it made, so it regenerates findings tailored to their specific needs and concerns.
We incorporated a method to constantly watch for changes in customer architecture and surface those changes to customers. These dependencies were automatically included in tests, reducing the risk of missing a new service or change in services. Customers can mark them as soft or hard dependencies, which factor into the AI powered analysis.
Regulated industry customers, including in financial services, transportation, government, and healthcare, started adopting the Next Generation Resilience Hub within the first two months of launch.
Based on what we learned about how customers approach resilience, we molded Resilience Hub into something built for their real journey: understanding a system's architecture, assessing it for risk, and testing it under real conditions. Testing has always meant running against real conditions, but now we have eliminated most of the choices and setup steps that used to stand between deciding to test and getting a result. Customers pick a test and run it, custom fit to their own architecture, instead of assembling an action, a target, and an experiment one at a time. All three phases now live in one connected product, and the simplified path to testing is a key part of what is accelerating adoption.
Dependency discovery has helped customers identify risks they did not know existed. In one public example, a DoiT engineer used the Next Generation Resilience Hub to run a failure mode assessment against a production system his team already considered well architected. It surfaced an undocumented dependency on a third party payment provider that two years of manual reviews had missed. He was able to fix it and prevent future issues.
Read the engineer's full account: The new AWS Resilience Hub found a failure mode missed for two years.