Global routing across ACGR Regions

With Connect Customer Global Resiliency (ACGR), you can link instances across two AWS Regions to create a highly available contact center that meets regulatory requirements mandating redundancy across geographically distant locations, or business continuity requirements that demand the highest level of resiliency. Global routing extends this capability by allowing contacts that originate in one Region to be routed to agents signed in to the linked Region, so both Regions are active at all times. Because your full configuration and integrations are continuously exercised, you gain higher confidence that either Region is ready to handle the full workload whenever you need to shift traffic to one Region.

For information about setting up ACGR, see Set up Connect Customer Global Resiliency. For requirements and prerequisites, see Connect Customer Global Resiliency requirements.

How global routing works

Without global routing, each Connect Customer instance makes routing decisions independently. For example, contacts that originate in the us-east-1 instance can be routed only to agents signed into us-east-1. Global routing changes this behavior for linked ACGR instances. Instead, the routing service evaluates agents from both Regions simultaneously and directs each contact to the appropriate matching agent regardless of which ACGR instance the agent is signed in to.

Global routing works with your existing traffic distribution group configuration. You continue to use the UpdateTrafficDistribution API to control how telephony traffic and agents are distributed across Regions. For more information about traffic distribution groups, see Set up traffic distribution groups.

Key concepts

The following concepts apply when you use global routing:

Subdomain-based instance aliases

To use global routing, you must use the subdomain-based instance aliases, where the source and replica instances share the same alias name differentiated by a regional subdomain prefix. For example, if your primary instance is named example, your instances are addressed as follows:

If you are using a custom CCP built with Amazon Connect Streams, ensure that you update the connect.core.initCCP call to include both instance URLs (using the subdomain-based instance aliases):

connect.core.initCCP(containerDiv, {
  ccpUrl: "https://us-east-1.example.my.connect.aws/ccp-v2/",
  secondaryCCPUrl: "https://us-west-2.example.my.connect.aws/ccp-v2/",
  enableGlobalResiliency: true,
  loginUrl: "<URL for your SSO provider>",
  // Additional initCCP parameters
});

Agent experience with cross-region contacts

As before, agents continue to sign in via the global sign-in endpoint and are distributed across Regions based on their traffic distribution group configuration. The Agent Workspace has been updated to handle cross-region contacts. Global routing is also supported for custom Contact Control Panel (CCP) built with Amazon Connect Streams. When an agent receives a cross-region contact, the experience will be the same as when handling a same-region contact; the agent does not need to take any special action.

However, please note that certain resources such as Chat Quick Responses and Task Templates are not currently automatically replicated across ACGR instances (see What resources are mirrored in the replica instance). If you use these resources, please plan to replicate them yourself to provide a consistent agent experience across Regions.

You continue to use the UpdateTrafficDistribution API to shift agents across Regions. If an agent is handling a contact when their traffic distribution group configuration is updated, they can complete the contact prior to being switched to the alternate Region. The UpdateTrafficDistribution API only affects new incoming contacts. For example, if you update the traffic distribution group to direct 100% of agents and incoming calls to us-west-2, contacts that were already queued in us-east-1 will remain queued in us-east-1 until they are handled. With global routing enabled, any queued contacts remaining in us-east-1 can still be handled by agents in us-west-2, potentially improving business continuity in case all agents are shifted to the other Region. Alternately, you can temporarily disable and re-enable global routing via the UpdateCrossRegionRouting API.

Consolidated metrics and search

With global routing, supervisors and administrators see a consolidated view of contact and agent metrics across both Regions regardless of which Region they are signed in to. For example, if 8 agents are available for a queue, then real-time metrics and dashboards display a total count of 8 Agents Available, regardless of what Region the agents are signed into or what Region the supervisor is viewing the report from. This global view extends to historical metrics and the reporting APIs (GetMetricDataV2, GetCurrentUserData, GetCurrentMetricData).

Contact Search enables supervisors to find and view contacts handled across both paired instances in a single view, including agent details, analytics, call recording, and transcripts. Supervisors must sign in via the global sign-in endpoint to access consolidated contact search.

For more information, see Metrics, Reports and Search across ACGR Regions.

Event streams behavior

The following table summarizes where event streams are available when global routing is enabled.

Since AES and CTR remain regional, update your third-party integration pipelines to consume data from both Regions. While CES provides a consolidated view, we recommend building integration pipelines in both Regions for resiliency.

Temporarily disabling cross-region routing

Use the UpdateCrossRegionRouting API to temporarily disable or re-enable global routing. When global routing is disabled, contacts originating in one Region are no longer routed to agents in the other Region. Contacts that are currently connected to an agent in another Region will not be disconnected when the API is invoked; the agent can complete handling that contact, but will no longer be routed additional contacts from the other Region.

Additional considerations for custom integrations (StreamsJS, AWS SDK, Connect SDK for Agent Workspace)

While StreamsJS and Connect SDK for Agent Workspace have been updated to support cross-region routing, applications that invoke public APIs in the AWS SDK may need to be updated to fetch the contact's active Region and the agent's active Region, and direct API calls accordingly:

The following table outlines some common use cases for reference.

The contact's active Region and the agent's active Region can be identified in the following interfaces.

Supported features for cross-region routing

For a consistent agent experience across same-region and cross-region contacts, please ensure all relevant resources are replicated across both instances. For a list of which resources are currently mirrored automatically in Connect Customer Global Resiliency, see What resources are mirrored in the replica instance.

Connect Customer features that are currently supported for cross-region operation include the following.

Migrating to global routing

ACGR instances created before September 1, 2026 do not have access to global routing by default. To request access to this feature, contact your AWS account team. Once your instance is enabled for global routing, review the following steps:

If you are using a custom CCP built with Amazon Connect Streams, then you may want to maintain failover logic in your custom CCP during the migration by defining variables for both the previous replica domain and the new subdomain-based domain. Then, use conditional logic to fall back to the previous domain if the new domain is unreachable during the transition period.