기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 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>
+ **운영 오버헤드 감소** - 단일 시스템을 관리/유지 관리하고 설정/구성 중복을 줄입니다.
+ **중앙 집중식 관리** - 통합 지표, 보고, 대기열, 라우팅 프로필, 사용자 등
+ **일관된 고객 경험** - 팀 전체의 공통 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)가 필요할 수 있습니다.
+ **일관되지 않은 사용자 경험** - 엄격하게 관리되지 않는 한 각 인스턴스는 흐름 설계, 고객 경험, 고객 보안 모델 등이 드리프트될 수 있습니다.

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

단일 인스턴스 아키텍처와 다중 인스턴스 아키텍처의 결정은 미묘하며 고객 요구 사항의 특성에 따라 크게 달라집니다. Amazon Connect의 확장성, 사용자 지정성, 프로그래밍 가능성 및 보안을 고려할 때 일반적으로 여러 리전이 필요한 강력한 요구 사항이 없는 단일 인스턴스 Amazon Connect 아키텍처(단일 Amazon Connect Global Resiliency 페어 포함)를 권장합니다.