AWS Contact Center

How NatWest built multi-region resilience with Amazon Connect Customer

Introduction

For NatWest Group, one of the UK’s largest banks, delivering consistent customer experience consistently is both a business priority and a regulatory requirement. Maintaining uninterrupted service across customer experience operations is fundamental to the bank’s ability to meet its business continuity and disaster recovery obligations.

NatWest originally deployed its customer experience platform on Amazon Connect Customer in the AWS Europe (London) Region. Amazon Connect Customer’s single-Region architecture operates across at least three Availability Zones (AZ) in an active-active-active configuration, with each AZ backed by one or more data centers. This multi-AZ design delivers strong resilience and high availability for the vast majority of Amazon Connect Customer deployments. For customers who require the highest level of resiliency, including the ability to satisfy strict compliance requirements and geographic redundancy, Amazon Connect Customer offers Amazon Connect Customer Global Resiliency (ACGR). As a financial institution with strict compliance and resiliency needs, NatWest partnered with AWS to implement Amazon Connect Customer Global Resiliency (ACGR) — transforming their architecture into a fully active-active, multi-Region customer experience platform including the conversational AI experiences powered by Amazon Lex. This post shares their journey, the automation utilities they built, the challenges they overcame, and the lessons learned along the way.

“For NatWest, resilience is not optional—it’s fundamental to how we serve millions of customers every day. Moving to a multi-region contact center with Amazon Connect Customer Global Resiliency and Amazon Lex Global Resiliency was critical to ensuring uninterrupted service, even during regional failures. This transformation allows us to protect customer trust, scale with confidence, and meet the resilience standards expected of a leading financial institution.”

Business Context and Drivers

NatWest’s Amazon Connect Customer instance handles over 3 million monthly voice calls and supports critical banking functions. Customers use it to report fraud, block an affected card, access emergency funds, and resolve any time-sensitive requests. Additionally, the customer experience platform integrates with 26 different services, including workforce management which helps with agent scheduling to ensure human agents are available when needed, voice biometrics authentication to protect against fraud, and conversational AI which handles routine request through self-service. Given the mission-critical nature of these operations and the regulatory scrutiny surrounding financial services availability, maintaining service continuity across all scenarios is non-negotiable.

The key drivers for this initiative were:

  • Regulatory compliance: UK financial regulators require demonstrable Business Continuity and Disaster Recovery (BCDR) capabilities, including defined Recovery Time Objectives (RTOs)
  • Reduce dependency on single Region: With operations limited to single Region in London, an infrequent regional impairment would create challenges for an organization with strict regulatory requirements around service continuity.
  • Protecting customer trust: Customers expect uninterrupted access to banking services, especially during high-stress situations
  • Mission-critical operations: NatWest’s customer experience platform is the primary channel for sensitive banking interactions, where service continuity directly impacts customer outcomes.

Solution Architecture

NatWest extended their existing contact center in AWS Europe (London) Region by creating a fully synchronized replica in AWS Europe (Frankfurt) Region. Both Regions run simultaneously in an active-active configuration — meaning agents and customer calls can be handled from either Region at any time. If one Region becomes impaired, traffic continues flowing through the other with no perceptible impact to customers or agents. The architecture uses two core AWS capabilities:

Amazon Connect Customer Global Resiliency (ACGR)

ACGR enables organizations to create a replica Amazon Connect Customer instance in a second AWS Region. Key capabilities used by NatWest include:

  • Automated configuration replication — native near real-time bidirectional Amazon Connect Customer resource replication, critical for consistent experience across regions.
  • Traffic Distribution Groups (TDGs) — distributes phone number and agent traffic across ACGR instances based on configurable percentages.
  • Global agent sign-in — agents use a global sign in URL to authenticate across ACGR instances allowing them to easily move to an alternate Region.
  • Reserved Capacity in the replica – reserved capacity in the second AWS Region to move traffic without any constraints.

Amazon Connect Customer Global Resiliency also extends with Conversation AI resiliency by replicating Lex V2 bots across regions in near real-time, so that Interactive Voice Response (IVR) and self-service experiences remain consistent across the active-active deployment.

NWG-ACGR

Figure 1: NatWest multi-Region architecture using Amazon Connect Customer Global Resiliency across AWS Europe (London) and AWS Europe (Frankfurt) Regions, showing Traffic Distribution Groups routing calls and agents between both Regions.

Custom Automation Utilities

While ACGR natively handles configuration replication for Amazon Connect Customer and Amazon Lex respectively, NatWest recognized the need for operational tooling to manage Traffic Distribution Groups at scale. They developed six TDG management utilities and one Amazon Lex enablement utility, using native Amazon Connect Customer APIs to build custom automation capabilities, implementing all utilities as CI/CD pipeline stages across multiple environments (dev, test, preprod, and prod) to enable efficient Region switch.

Utility Purpose
Associate Agent to TDG Adds agents to a Traffic Distribution Group (TDG)
Associate Phone Number Links phone numbers to a TDG
Disassociate Agent from TDG Removes agents from a TDG
Update TDG Modifies traffic distribution percentages between London and Frankfurt
List TDG Displays all TDGs and their current traffic distribution
Amazon Lex Global Resiliency (ALGR) Bot Enablement Enables Amazon Lex Global Resiliency for Lex V2 bots across regions

Each utility accepts environment and instance parameters, enabling consistent operations across all deployment stages without manual configuration changes.

Implementation Journey

NatWest completed the implementation over 20 weeks, followed by a phased number porting period of three months.

Phase Weeks Key Activities
Phase 1: Planning & Discovery 1-4 weeks Operational Readiness requirement analysis, team formation, service quota review, AWS Well-Architected review
Phase 2: Development Setup 5-8 weeks Dev environment ACGR configuration, Single Sign-On validation, Terraform pipeline updates
Phase 3: Test & Pre-Production 9-16 weeks Non-replicated resource handling, TDG test scenarios, monitoring setup, staging validation
Phase 4: Production Deployment 17-20 weeks Service quota alignment, production ACGR enablement, phased traffic shifting
Phase 5: Number Porting Post-production Phased porting of telephony numbers to TDGs over three months

“Starting in non-production environments allowed us to surface integration issues early — particularly around non-replicated resources before they could impact our customers.”

“Amazon Connect Customer Global Resiliency gives us a strong foundation by automatically replicating core contact‑routing capabilities across regions, but the real success of our multi‑region strategy comes from understanding and embracing the shared responsibility model. For NatWest, that meant taking ownership of everything beyond the Amazon Connect Customer boundary. By clearly separating what AWS manages from what we manage, we were able to build a resilient, repeatable, and tightly controlled global architecture that meets our operational and regulatory expectations.”

Technical Challenges and How They Were Solved

Non-Replicated Resources

Amazon Connect Customer Global Resiliency (ACGR) operates in a shared responsibility model. AWS automatically replicates specific Amazon Connect Customer configuration resources necessary to route voice traffic across Regions, however, any resources that sit outside the Amazon Connect Customer resource boundary such as ooDB and AWS Lambda require customers to maintain an external replication pipeline.

For NatWest’s multi-Region deployment, this shared responsibility extended to a few key components:

Serverless Infrastructure: AWS Lambda functions required independent deployment to replica Regions using enhanced Terraform CI/CD pipelines to maintain consistent Infrastructure-as-Code (IaC) (IaC) deployments across environments.

Static Contents: Amazon S3 content, including audio prompts and static assets, was efficiently replicated across Regions using S3 cross-Region Replication, which automatically synchronizes objects between source and destination buckets.

Real-Time Streaming: Separate Amazon Kinesis Video Streams configurations were created in each Region to support integrations such as Nuance Gatekeeper voice biometrics, as these fall outside ACGR’s automated replication scope.

Language and Vocabulary Resources: Both Amazon Lex custom vocabularies and Amazon Connect Customer custom vocabularies required external replication pipelines to synchronize across Regions, as these resources extend beyond standard ACGR and ALGR replication coverage and require customer-managed orchestration.

Custom Contact Control Panel (CCP) Modifications

NatWest operates a customized CCP built using the Amazon Connect Customer Streams API. The team adapted their authentication logic to be Region-agnostic, ensuring agents could easily connect to the agent’s active Region.

Metrics and Monitoring

When NatWest deployed ACGR, Connect Customer did not provide a unified cross-Region metrics view natively. To address this gap, NatWest built custom Amazon CloudWatch dashboards and Amazon QuickSight reports to consolidate operational metrics across both Regions into a single operational view.

Today, ACGR offers native consolidated agent and contact metrics including consolidated Contact Search page for efficient contact center operations.

Security Considerations

Security is a shared responsibility between AWS and customers. NatWest applied the following security best practices throughout their ACGR implementation.

NatWest selected Frankfurt as the replica Region to maintain EU data residency compliance, which represents a key requirement for the organization’s regulatory obligations. NatWest encrypts all data in transit and at rest using AWS-managed keys, with customer-managed KMS keys applied in cases where policy requires additional control over encryption key management.

All automation utilities and Lambda functions operate under least-privilege IAM roles, scoped to the minimum permissions required for each operation. When configuring roles, refer to the IAM best practices guide to verify your implementation follows AWS security recommendations. The team validated identity provider configuration in non-production environments before production deployment to prevent authentication failures during traffic switch across Regions.

NatWest enabled AWS CloudTrail across both Regions to maintain a complete audit trail of configuration changes and any Region switch events, enabling NatWest to track all activities for compliance and troubleshooting purposes.

“Security and regulatory compliance were foundational to our Cross-Region implementation on AWS. By selecting Frankfurt to meet EU data residency requirements, enforcing encryption for data in transit and at rest, and applying least-privilege IAM with comprehensive CloudTrail auditing, we were able to meet stringent regulatory expectations without compromising resilience or agility. Rigorous pre-production validation ensured smooth regional traffic switching while maintaining the highest security standards.”

As part of setting up dependent services configuration in the second AWS Region, NatWest periodically performed traffic switches to the alternate Region to ensure the configuration is accurate and the business operates consistently in the second Region. This was critical to verify that configurations are always in sync and helped build confidence that in the event of a Region switch, the business can provide a consistent agent and caller experience. NatWest carries out this failover testing quarterly to ensure their runbooks remain up-to-date and they maintain confidence for a successful Region switch.

Results

The implementation delivered measurable improvements across resilience, compliance, and operations.

  • Near-instantaneous RTO — Reduced Recovery Time Objective from over 30 minutes to near instantaneous through Traffic Distribution Groups, which automatically reroute calls without manual intervention.
  • Full capacity under stress — Maintained full call capacity of 3,500+ calls during simulated regional outage testing.
  • Regulatory compliance — Successfully met BCDR requirements by implementing a documented, tested multi-Region architecture that satisfies compliance obligations.
  • Simplified agent experience — Single global sign-in URL provides a smooth experience for over 3,500 agents to move across Regions or ACGR instances as needed.
  • Reduced operational overhead — Automated configuration synchronization replaced manual multi-Region deployments, freeing the engineering team from repetitive administrative tasks.
  • End-to-end service continuity — Maintained continuity across 26 integrated services in both Regions, ensuring dependent applications remained functional during Region switches.

Lessons Learned

Based on NatWest’s experience, the following recommendations will help teams planning a similar implementation:

1. Start in non-production — Surface integration issues with non-replicated resources before they reach production

2. Validate SAML/SSO early — Identity provider configuration must be completed and tested before initiating ACGR replica creation along with global sign-in

3. Audit all integrations — Document every service integrated with Amazon Connect Customer and classify each as replicated or non-replicated before beginning

4. Build monitoring before go-live — Cross-Region operational dashboards should be in place before production traffic is shifted

5. Implement regular fault injection testing — Schedule periodic failover drills to validate that traffic rerouting, agent sign-in, and all 26 integrated services function correctly during simulated regional impairments. NatWest runs quarterly fault injection exercises to validate RTO targets under realistic conditions.

6. Use phased traffic shifting — Gradually increase Frankfurt traffic percentages rather than a hard cutover, using TDG update utilities to control the rollout

7. Apply AWS Well-Architected reviews at each phase gate to validate architecture decisions against the Reliability Pillar along with the Resiliency lens.

Conclusion

NatWest’s implementation of Amazon Connect Customer Global Resiliency and Amazon Lex Global Resiliency demonstrates how large financial institutions can achieve contact center resilience that meets financial regulatory standards without sacrificing operational simplicity. By combining AWS-native replication capabilities with purpose-built automation utilities and a disciplined phased approach, NatWest transformed a single-Region architecture into a fully resilient, multi-Region contact center — meeting regulatory requirements and protecting customer experience simultaneously.

The journey required 20 weeks of focused engineering effort, but the result is an architecture that sustains a complete regional outage with no perceptible customer impact and no manual intervention.

Next Steps

Ready to build multi-Region resilience into your Amazon Connect Customer contact center? Start by reviewing the Amazon Connect Customer Global Resiliency documentation and the Amazon Lex Global Resiliency guide. You can also explore the AWS Well-Architected Reliability Pillar to assess your current architecture and identify resilience gaps before beginning your implementation.

Authors bio

Prateek Guleria is a DevOps Lead at Natwest. Entrusted with performing automations, overseeing the development and implementation of CI/CD pipelines, and maintaining cloud infrastructure on AWS platform.
Abilashkumar P C is a Sr. Specialist Solutions Architect for Applied AI at Amazon Web Services, based in London. He works with customers to design and build resilient, AI-powered solutions across contact centers powered by serverless technologies.
Prabhakar Rajasekar is an Applied AI Solution Architect at Amazon Web Services for WWSO in Aachen, Germany. Besides helping customers in their digital transformation, you will see him spending time with his kids in the garden or in the woods.
Srinath Chandrasekharan is a Release Train Manager at NatWest, serving as the strategic orchestrator of program execution, ensuring all technology deliverables are precisely planned, synchronised, and executed in direct alignment with Business and Technology OKRs.
Baraa Elkosh is a Senior Technical Account Manager at AWS based in London, UK. He partners with enterprise customers to accelerate their cloud adoption, specializing in Contact Center modernization and AI integration, while ensuring operational stability at scale.
Manoj Srinivas is a Product Manager at Amazon Web Services based in Seattle, WA. He drives development of Amazon Connect Global Resiliency, the capability that lets enterprises run Amazon Connect seamlessly across AWS Regions for business continuity and compliance. Outside of work, he loves to travel and play soccer.