本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Connect：单实例还是多个实例？
<a name="single-instance-multiple-instances"></a>

## Amazon Connect 的单个实例（包括单个 ACGR 对）
<a name="single-instance-connect"></a>

### 适用场景
<a name="single-instance-best-for"></a>

通过共享基础设施和统一的客户体验实现集中式联络中心运营。

### 优点
<a name="single-instance-pros"></a>
+ **降低操作开销** — Manage/maintain 单一系统，减少设置/配置的重复。
+ **集中管理** — 统一的指标、报告、队列、路由配置文件、用户等。
+ **一致的客户体验** — 跨团队通用 IVR、流程和设置。

### 缺点
<a name="single-instance-cons"></a>
+ **数据/租户隔离设计** — 必须设计跨业务部门、品牌或地区的数据隔离。
+ **单一地理位置**-在远离实例的区域，延迟可能很高。
+ **服务配额管理** — 由于难以预测多个业务部门的使用量和增长，因此服务配额管理可能更具挑战性。

## 多个 Amazon Connect 实例
<a name="multiple-instances-connect"></a>

### 适用场景
<a name="multiple-instances-best-for"></a>

具有地理、监管或安全要求无法在单一区域实施的企业（电话、数据隔离、物理距离导致的延迟等）。

### 优点
<a name="multiple-instances-pros"></a>
+ **高度隔离** — 每个 BU 或区域可以有自己的代理、路由、报告。在印度、韩国和南非，需要对特工进行隔离。
+ **量身定制的配置** — 可以按实例自定义流程、提示和集成。
+ **更简单的数据驻留**-对于跨国组织的合规性可能很有用。
+ **缩小爆炸半径** — 一个实例中的问题不会影响其他问题。
+ **地理位置**-可以选择区域以保持本地电话流量本地化。

### 缺点
<a name="multiple-instances-cons"></a>
+ **更高的管理开销**-需要维护和更新多个环境。
+ **分散的报告**-目前需要建立多区域报告。
+ **成本增加** — 每个实例可能需要重复的资源（Lambda、Amazon Lex、API）。
+ **用户体验不一致** — 除非严格管理，否则每个实例都可能在流程设计、客户体验、客户安全模型等方面有所不同。

## Summary
<a name="single-multiple-instances-summary"></a>

单实例架构还是多实例架构的决定是细致入微的，并且高度取决于客户需求的性质。考虑到 Amazon Connect 的可扩展性、可定制性、可编程性和安全性，在没有需要多个区域的迫切要求的情况下，我们通常建议使用单实例 Amazon Connect 架构（包括单个 Amazon Connect 全球弹性对）。