# DynamoDB 글로벌 테이블 준비 체크리스트
글로벌 테이블을 배포할 때 의사 결정 및 작업에 다음 체크리스트를 사용하세요.
+ 사용 사례가 MRSC 또는 MREC 일관성 모드 중 무엇에서 더 많은 이점을 얻을 수 있는지 확인합니다. 지연 시간이 길고 다른 장단점이 있더라도 강력한 일관성이 필요한가요?
+ 글로벌 테이블에 참여해야 하는 리전과 리전 수를 결정합니다. MRSC를 사용하려는 경우 세 번째 리전을 복제본 또는 감시자로 지정할지 결정합니다.
+ 애플리케이션의 쓰기 모드를 결정합니다. 이는 일관성 모드와 동일하지 않습니다. 자세한 내용은 [DynamoDB 글로벌 테이블을 사용한 쓰기 모드](bp-global-table-design.prescriptive-guidance.writemodes.md) 섹션을 참조하세요.
+ 쓰기 모드에 따라 [DynamoDB의 라우팅 전략](bp-global-table-design.prescriptive-guidance.request-routing.md) 전략을 계획합니다.
+ 일관성 모드, 쓰기 모드 및 라우팅 전략에 따라 [ 대피 프로세스 글로벌 테이블을 사용한 리전 대피 리전 대피란, 일반적으로 읽기 및 쓰기 활동 또는 읽기 활동과 같은 활동을 해당 리전 외부로 마이그레이션하는 프로세스입니다. 라이브 리전 대피라이브 리전 라이브 리전 대피 일상적인 비즈니스 활동의 일환(예: 해바라기 방식을 사용하는 경우 한 리전 모드에 쓰기), 현재 활성 리전을 변경하려는 비즈니스 결정, DynamoDB 외부의 소프트웨어 스택 장애에 대한 대응 또는 리전 내에서 일반적인 지연 시간보다 높은 지연 시간 등의 일반적인 문제가 발생하는 경우와 같이 여러 가지 이유로 라이브 리전을 대피하기로 결정할 수 있습니다. *임의의 리전에 쓰기* 모드에서는 라이브 리전 대피가 간단합니다. 라우팅 시스템을 통해 트래픽을 대체 리전으로 라우팅하고, 대피된 리전의 쓰기 작업을 평소처럼 복제할 수 있습니다. 한 리전에 쓰기 및 사용자 리전 모드에 쓰기는 일반적으로 MREC 테이블과 함께 사용됩니다. 따라서 새 활성 리전에서 쓰기 작업을 시작하기 전에 활성 리전에 대한 모든 쓰기 작업이 완전히 기록되고, 스트림 처리되며, 글로벌로 전파되었는지 확인하여 최신 버전의 데이터에서 향후 쓰기 작업이 처리되도록 해야 합니다. 리전 A는 활성이고 지역 B는 비활성이라고 가정해 보겠습니다(전체 테이블 또는 리전 A에 있는 항목의 경우). 대피를 수행하는 일반적인 메커니즘은 A에 대한 쓰기 작업을 일시 중지하고 이러한 작업이 B로 완전히 전파될 때까지 충분히 기다린 후 B를 활성으로 인식하도록 아키텍처 스택을 업데이트한 다음 B에 쓰기 작업을 재개하는 것입니다. 리전 A의 데이터가 리전 B에 완전히 복제되었음을 100% 확실하게 나타내는 지표는 없습니다. 리전 A가 정상인 경우 리전 A에 대한 쓰기 작업을 일시 중지하고 `ReplicationLatency` 지표의 최근 최대값의 10배를 기다리면 일반적으로 복제가 완료되었는지 확인하는 데 충분합니다. 리전 A가 비정상이고 다른 영역에서 지연 시간이 길어지면 대기 시간을 더 큰 배수로 설정할 수 있습니다. 오프라인 리전 대피오프라인 리전 오프라인 리전 대피 고려해야 할 특별한 경우가 있습니다. 리전 A가 예고 없이 완전히 오프라인 상태가 되면 어떻게 되나요? 이는 매우 드물지만 고려해야 하는 사안입니다.
오프라인 MRSC 테이블 대피
MRSC 테이블에서 이런 상황이 발생하면 특별한 조치는 필요하지 않습니다. MRSC 글로벌 테이블은 0의 목표 복구 시점(RPO)을 지원합니다. 오프라인 리전에서 MRSC 테이블에 대한 모든 성공적인 쓰기 작업은 다른 모든 리전 테이블에서 사용할 수 있으므로, 리전이 예고 없이 완전히 오프라인 상태가 되더라도 데이터에서 격차는 발생하지 않습니다. 비즈니스는 다른 리전에 있는 복제본을 계속 사용할 수 있습니다.
오프라인 MREC 테이블 대피
MREC 테이블에서 이와 같은 상황이 나타나는 경우에는 아직 전파되지 않은 리전 A의 모든 쓰기 작업은 보관되었다가 리전 A가 다시 온라인 상태가 된 후에 전파됩니다. 쓰기 작업은 손실되지 않지만 전파는 무기한 지연됩니다.
이 경우 어떻게 진행할지는 애플리케이션이 결정합니다. 비즈니스 연속성을 위해서는 새 기본 리전 B에 쓰기 작업을 계속해야 할 수도 있습니다. 하지만 리전 A로부터 항목에 대한 쓰기 작업 전파가 보류 중인 동안 리전 B의 해당 항목이 업데이트를 수신하는 경우, *최종 쓰기 우선* 모델에서는 전파가 억제됩니다. 리전 B에서의 모든 업데이트는 수신되는 쓰기 요청을 억제할 수 있습니다.
*임의의 리전에 쓰기* 모드에서는 리전 A의 항목이 결국 리전 B로 전파될 것으로 믿고 리전 A가 다시 온라인 상태가 될 때까지 항목이 누락될 가능성을 인식하면서 리전 B에서 읽기와 쓰기를 계속할 수 있습니다. 멱등성 쓰기 작업에서와 같이 가능하면 최근 쓰기 트래픽을 재생(예: 업스트림 이벤트 소스 사용)하여 누락될 수 있는 쓰기 작업의 공백을 메우고, 최종 쓰기 우선 충돌 해결이 수신 쓰기 작업의 최종 전파를 억제하도록 하는 방법을 고려해야 합니다.
그 밖의 쓰기 모드에서는 살짝 최신에서 뒤떨어진 데이터로 작업을 계속할 수 있는 정도를 고려해야 합니다. `ReplicationLatency`로 추적되는 짧은 기간 동안의 일부 쓰기 작업은 리전 A가 다시 온라인 상태가 될 때까지 누락됩니다. 비즈니스를 계속 진행할 수 있을까요? 진행 가능한 사용 사례도 있겠지만 추가 완화 메커니즘 없이는 가능하지 않을 수도 있습니다.
예를 들어 리전의 완전 중단 이후에도 중지 없이 사용 가능한 크레딧 잔액을 유지 관리해야 한다고 가정합니다. 잔액을 서로 다른 두 항목(리전 A가 홈 리전인 항목과 리전 B가 홈 리전인 항목)으로 나누고 각각 사용 가능한 잔액의 절반에서 시작할 수 있습니다. 이렇게 하면 *사용자 리전에 쓰기* 모드를 사용하는 것입니다. 각 리전에서 처리되는 트랜잭션 업데이트는 잔액의 로컬 사본에 기록됩니다. 리전 A가 완전히 오프라인 상태가 되더라도 리전 B에서 트랜잭션 처리를 계속 진행할 수 있으며, 쓰기 작업은 리전 B에 보관된 잔액 부분으로만 제한됩니다. 이렇게 잔액을 분할하면 잔액이 낮아지거나 크레딧을 재조정해야 할 때 복잡성이 발생하지만, 보류 중인 쓰기 작업에 불확실성이 있더라도 비즈니스를 안전하게 복구할 수 있는 한 가지 예가 됩니다.
또 다른 예로 웹 양식 데이터를 캡처하는 경우를 가정합니다. [OCC(낙관적 동시성 제어)](DynamoDBMapper.OptimisticLocking.md)를 사용하여 데이터 항목에 버전을 할당하고 최신 버전을 웹 양식에 숨겨진 필드로 포함할 수 있습니다. 제출할 때마다 데이터베이스에 있는 버전이 양식의 작성 기준 버전과 일치하는 경우에만 쓰기 작업이 성공합니다. 버전이 일치하지 않는 경우 데이터베이스에 있는 현재 버전을 기반으로 웹 양식을 새로 고치거나 신중하게 병합할 수 있고, 사용자는 다시 진행할 수 있습니다. OCC 모델은 일반적으로 다른 클라이언트가 데이터를 덮어쓰고 새 버전의 데이터를 생성하지 못하도록 보호하지만, 클라이언트가 이전 버전의 데이터를 발견할 수 있는 장애 조치 중에도 도움이 될 수 있습니다. 타임스탬프를 버전으로 사용하고 있다고 가정해 보겠습니다. 양식이 리전 A에서 12:00에 처음 빌드되었지만 장애 조치 이후 리전 B에 쓰려고 시도하다가 데이터베이스에 있는 최신 버전이 11:59임을 알게 되었다고 가정합니다. 이 시나리오에서 클라이언트는 12:00 버전이 리전 B로 전파될 때까지 기다린 다음 이 버전을 기반으로 쓰거나, 11:59를 기반으로 빌드하고 새 12:01 버전(쓰기 후에 리전 A가 복구된 후 수신 버전을 억제)을 생성할 수 있습니다.
마지막 세 번째 예에서는 한 금융 서비스 회사가 DynamoDB 데이터베이스에 고객 계정 및 금융 거래에 대한 데이터를 보관합니다. 이 회사는 리전 A가 완전히 중단될 경우 고객 계정과 관련된 모든 쓰기 활동을 리전 B에서 완전히 사용할 수 있도록 하거나 리전 A가 다시 온라인 상태가 될 때까지 부분적으로 알려진 고객 계정을 격리하고자 했습니다. 이 회사는 모든 업무를 일시 중지하는 대신 트랜잭션이 전파되지 않은 것으로 판단되는 극히 일부의 계정만 업무를 일시 중지하기로 결정했습니다. 이를 위해 리전 C라고 부르는 세 번째 리전을 사용했습니다. 리전 A에서 쓰기 작업을 처리하기 전에 보류 중인 작업(예: 계정의 새 트랜잭션 수)을 간략하게 요약하여 리전 C에 배치했습니다. 이 요약만으로도 리전 B가 해당 뷰가 최신 상태인지 판단하기에 충분했습니다. 이 조치로 인해 리전 C에서의 쓰기 시점부터 리전 A가 쓰기 작업을 수락하고 지역 B가 쓰기 작업을 수신할 때까지 계정이 사실상 잠겼습니다. 리전 C에 있는 데이터는 장애 조치 프로세스의 일부인 경우를 제외하고는 사용되지 않았습니다. 장애 조치 후 리전 B는 리전 C와 데이터를 교차 검증하여 최신 상태가 아닌 계정이 있는지 확인할 수 있었습니다. 이러한 계정은 리전 A 복구 시 부분 데이터를 리전 B로 전파할 때까지 격리된 것으로 표시됩니다. 리전 C가 실패하면 새 리전 D를 대신 사용할 수 있습니다. 데이터는 리전 C에 아주 잠깐 머물렀고, 몇 분 후에는 진행 중인 쓰기 작업에 대한 충분히 유용한 최신 기록이 리전 D에 있게 됩니다. 리전 B에 장애가 발생할 경우 리전 A는 리전 C와 협력하여 쓰기 요청을 계속 수락할 수 있었습니다. 이 회사는 지연 시간이 더 긴 쓰기(리전 C와 리전 A에 대한 쓰기)를 받아들일 용의가 있었고, 다행히도 계정 상태를 간략하게 요약할 수 있는 데이터 모델이 있었습니다. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title), [대피 프로세스](bp-global-table-design.prescriptive-guidance.evacuation.md)을 정의합니다.
+ 각 리전의 상태, 지연 시간, 오류에 대한 지표를 캡처합니다. DynamoDB 지표 목록은 AWS 블로그 게시물 [Monitoring Amazon DynamoDB for Operational Awareness](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)에 있는 관찰해야 할 지표 목록을 참조하세요. 또한 [합성 카나리아](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)(장애를 감지하도록 설계된 인위적 요청으로, 탄광에 있는 카나리아에서 유래)를 사용하고 고객 트래픽을 실시간으로 관찰해야 합니다. 모든 문제가 DynamoDB 지표에 나타나는 것은 아닙니다.
+ MREC를 사용하는 경우 `ReplicationLatency`에서 지속적인 증가에 대한 경보를 설정합니다. 증가는 글로벌 테이블의 쓰기 설정이 리전마다 다른 잘못된 구성을 나타낼 수 있습니다. 이는 복제된 요청 실패와 지연 시간 증가로 이어질 수 있습니다. 리전 중단이 있음을 나타낼 수도 있습니다. [좋은 예](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)는 최근 평균이 180,000밀리초를 초과할 경우 알림을 생성하는 것입니다. `ReplicationLatency`가 0으로 떨어지는 것을 관찰할 수도 있습니다. 이는 복제가 중단되었음을 나타냅니다.
+ 각 글로벌 테이블에 충분한 최대 읽기 및 쓰기 설정을 할당합니다.
+ 리전 대피 사유를 미리 식별합니다. 결정에 사람의 판단이 수반되는 경우 모든 고려 사항을 문서화합니다. 이 작업은 압박을 받지 않는 상태에서 사전에 신중하게 수행해야 합니다.
+ 리전 대피 시 취해야 하는 모든 조치를 위한 런북을 유지 관리합니다. 일반적으로 글로벌 테이블에 필요한 작업은 거의 없지만 나머지 스택을 이동하는 작업은 복잡할 수 있습니다.
**참고**
장애 조치 절차를 사용하는 경우 리전 장애 중에 일부 컨트롤 플레인 작업이 저하될 수 있으므로 데이터 플레인 작업에만 의존하고 컨트롤 플레인 작업에는 의존하지 않는 것이 모범 사례입니다.
자세한 내용은 AWS 블로그 게시물 [Build resilient applications with Amazon DynamoDB global tables: Part 4](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)를 참조하세요.
+ 리전 대피를 포함하여 런북의 모든 측면을 정기적으로 테스트합니다. 테스트되지 않은 런북은 신뢰할 수 없는 런북입니다.
+ [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)를 사용하여 전체 애플리케이션(글로벌 테이블 포함)의 복원력을 평가하는 방법을 고려합니다. Resilience Hub의 대시보드를 통해 전체 애플리케이션 포트폴리오 복원력 상태를 종합적으로 파악할 수 있습니다.
+ ARC 준비 상태 확인을 사용하여 애플리케이션의 현재 구성을 평가하고 모범 사례에서 벗어난 부분을 추적하는 것을 고려해 보세요.
+ Route 53 또는 Global Accelerator와 함께 사용할 상태 확인을 작성할 때 전체 데이터베이스 흐름을 포함하는 일련의 직접 호출을 수행합니다. DynamoDB 엔드포인트가 가동되었는지만 확인하도록 검사를 제한하면 AWS Identity and Access Management(IAM) 구성 오류, 코드 배포 문제, DynamoDB 외부 스택의 장애, 평균 읽기 또는 쓰기 지연 시간보다 높은 지연 시간 등과 같은 많은 장애 모드를 처리할 수 없습니다.
## 글로벌 테이블 배포에 대한 자주 묻는 질문(FAQ)
**글로벌 테이블의 요금은 어떻게 되나요?**
+ 기존 DynamoDB 테이블에 대한 쓰기 작업 요금은 쓰기 용량 단위(WCU, 프로비저닝된 테이블의 경우) 또는 쓰기 요청 단위(WRU, 온디맨드 테이블의 경우)를 기준으로 합니다. 5KB 항목을 쓰면 5단위의 요금이 부과됩니다. 글로벌 테이블에 대한 쓰기 요금은 프로비저닝된 테이블의 경우 복제된 쓰기 용량 단위(rWCU) 또는 온디맨드 테이블의 경우 복제된 쓰기 요청 단위로 책정됩니다. rWCU 및 rWRU 요금은 WCU 및 WRU와 같습니다.
+ rWCU 및 rWRU 요금은 항목을 직접 쓰거나 복제를 통해 쓰는 모든 리전에서 발생합니다. 리전 간 데이터 전송 요금이 적용됩니다.
+ 글로벌 보조 인덱스(GSI)에 대한 쓰기 작업은 로컬 쓰기 작업으로 간주되며, 일반 쓰기 단위를 사용합니다.
+ 현재 rWCU 또는 rWRU에 대해 예약 용량을 사용할 수 없습니다. GSI가 쓰기 단위를 소비하는 테이블의 경우 WCU에 대해 예약 용량을 구매하는 것이 여전히 유리할 수 있습니다.
+ 글로벌 테이블에 새 리전을 추가하면 DynamoDB는 새 리전을 자동으로 부트스트랩하고, 테이블 복원과 마찬가지로 테이블의 GB 크기를 기준으로 요금을 청구합니다. 리전 간 데이터 전송 요금도 적용됩니다.
**글로벌 테이블은 어떤 리전을 지원하나요?**
[글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)은 MREC 테이블에 대해 모든 AWS 리전을 지원하고 MRSC 테이블에 대해 다음 리전 세트를 지원합니다.
+ 미국 리전 세트: 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오리건)
+ EU 리전 세트: 유럽(아일랜드), 유럽(런던), 유럽(파리), 유럽(프랑크푸르트)
+ 아시아 태평양 리전 세트: 아시아 태평양(도쿄), 아시아 태평양(서울) 및 아시아 태평양(오사카).
**글로벌 테이블에서는 GSI를 어떻게 처리하나요?**
[글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)에서는 한 리전에서 생성한 GSI가 다른 참여 리전에도 자동으로 생성되고 자동으로 백필됩니다.
**글로벌 테이블의 복제를 중지하려면 어떻게 해야 하나요?**
+ 다른 테이블을 삭제하는 것과 같은 방식으로 복제본 테이블을 삭제할 수 있습니다. 글로벌 테이블을 삭제하면 해당 리전으로의 복제가 중지되고 해당 리전에 보관된 테이블 사본이 삭제됩니다. 하지만 테이블의 사본을 독립적 엔터티로 유지하는 동안에는 복제를 중지할 수 없으며 복제를 일시 중지할 수도 없습니다.
+ MRSC 테이블은 정확히 3개의 리전에 배포되어야 합니다. 복제본을 삭제하려면 MRSC 테이블이 로컬 테이블이 되도록 모든 복제본과 감시자를 삭제해야 합니다.
**DynamoDB Streams는 글로벌 테이블과 어떻게 상호 작용하나요?**
+ 각 글로벌 테이블은 시작 위치에 관계없이 모든 쓰기 작업을 기반으로 독립적인 스트림을 생성합니다. 이 DynamoDB 스트림을 한 리전 또는 모든 리전에서 독립적으로 사용하도록 선택할 수 있습니다. 로컬 쓰기 작업은 처리하되 복제된 쓰기 작업은 처리하지 않으려는 경우 쓰기 리전을 식별하는 고유한 리전 속성을 각 항목에 추가할 수 있습니다. 그런 다음 Lambda 이벤트 필터를 사용하여 로컬 리전에서의 쓰기 작업만을 위한 Lambda 함수를 호출할 수 있습니다. 이렇게 하면 삽입 및 업데이트 작업에 도움이 되지만 삭제 작업에는 도움이 되지 않습니다.
+ 다중 리전 최종 일관성(MREC 테이블)을 위해 구성된 글로벌 테이블은 복제본 테이블의 DynamoDB 스트림에서 변경 사항을 읽고 해당 변경 사항을 다른 모든 복제본 테이블에 적용하여 변경 사항을 복제합니다. 따라서 DynamoDB는 MREC 글로벌 테이블의 모든 복제본에서 기본적으로 활성화되며 해당 복제본에서 비활성화할 수 없습니다. MREC 복제 프로세스는 단기간에 여러 변경 사항을 복제된 단일 쓰기 작업으로 결합할 수 있습니다. 따라서 각 복제본의 스트림에는 약간 다른 레코드가 포함될 수 있습니다. MREC 복제본의 DynamoDB Streams 레코드는 항상 항목별로 정렬되지만, 항목 간 정렬은 복제본마다 다를 수 있습니다.
+ 다중 리전 강력한 일관성(MRSC 테이블)을 위해 구성된 글로벌 테이블은 복제에 DynamoDB Streams를 사용하지 않으므로 이 기능은 MRSC 복제본에서 기본적으로 활성화되지 않습니다. MRSC 복제본에서 DynamoDB Streams를 활성화할 수 있습니다. MREC 복제본의 DynamoDB Streams 레코드는 모든 복제본에서 동일하며 항상 항목별로 정렬되지만, 항목 간 정렬은 복제본 사이에서 다를 수 있습니다.
**글로벌 테이블은 트랜잭션을 어떻게 처리하나요?**
+ MRSC 테이블에서 트랜잭션 작업을 수행하면 오류가 발생합니다.
+ MREC 테이블에서 트랜잭션 작업은 쓰기 작업이 원래 이루어진 리전에서만 원자성, 일관성, 격리성 및 내구성(ACID) 보장을 제공합니다. 전역 테이블에서는 트랜잭션이 리전 간에 지원되지 않습니다. 예를 들어 미국 동부(오하이오) 및 미국 서부(오리건) 리전에 복제본이 있는 MREC 글로벌 테이블이 있고 미국 동부(오하이오)에서 `TransactWriteItems` 작업을 수행할 경우, 변경 내용이 복제될 때 미국 서부(오리건)에서 부분적으로 완료된 트랜잭션을 관찰할 수 있습니다. 변경 사항은 소스 리전에서 커밋된 이후에만 다른 리전에 복제됩니다.
**글로벌 테이블은 DynamoDB Accelerator 캐시(DAX)와 어떻게 상호 작용하나요?**
글로벌 테이블은 DynamoDB를 직접 업데이트하여 DAX를 우회하므로 DAX는 오래된 데이터를 보유하고 있다는 사실을 인식하지 못합니다. DAX 캐시는 캐시의 TTL이 만료되는 경우에만 새로 고쳐집니다.
**테이블의 태그가 전파되나요?**
아니요, 태그는 자동으로 전파되지 않습니다.
**테이블을 모든 리전에 백업해야 하나요 아니면 한 리전에만 백업해야 하나요?**
대답은 백업의 목적에 따라 달라집니다.
+ 데이터 내구성을 보장하려는 경우 DynamoDB는 이미 그러한 보호 장치를 제공합니다. 이 서비스는 내구성을 보장합니다.
+ 기록 레코드의 스냅샷을 보관하려는 경우(예: 규정 요구 사항 충족) 한 리전에 백업하는 것으로 충분합니다. AWS Backup를 사용하여 백업을 추가 리전에 복사할 수 있습니다.
+ 실수로 삭제되거나 수정된 데이터를 복구하려면 한 리전에서 [DynamoDB 시점 복구(PITR)](PointInTimeRecovery_Howitworks.md)를 사용하세요.
**을 사용하여 글로벌 테이블을 배포하려면 어떻게 해야 하나요?CloudFormation**
+ CloudFormation은 DynamoDB 테이블과 글로벌 테이블을 두 개의 개별 리소스인 `AWS::DynamoDB::Table`과 `AWS::DynamoDB::GlobalTable`로 나타냅니다. 한 가지 방법은 `GlobalTable` 구성을 사용하여 글로벌 테이블일 수 있는 모든 테이블을 생성하고, 처음에는 해당 테이블을 독립형 테이블로 유지하다가 나중에 필요에 따라 리전을 추가하는 것입니다.
+ CloudFormation에서 각 글로벌 테이블은 복제본 수에 관계없이 단일 리전에서 단일 스택에 의해 제어됩니다. 템플릿을 배포하면 CloudFormation은 단일 스택 작업의 일부로 모든 복제본을 생성하고 업데이트합니다. 동일한 [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 리소스를 여러 리전에 배포하면 안 됩니다. 이런 배포는 오류를 유발하며 지원되지 않습니다. 여러 리전에 애플리케이션 템플릿을 배포하는 경우 조건을 사용하여 단일 리전에서 `AWS::DynamoDB::GlobalTable` 리소스를 생성할 수 있습니다. 또는 `AWS::DynamoDB::GlobalTable` 리소스를 애플리케이션 스택과 별도의 스택에 정의하고 단일 리전에 배포되도록 선택할 수 있습니다.
+ 일반 테이블이 있고 이 테이블을 CloudFormation이 계속 관리하는 글로벌 테이블로 변환하려는 경우, 삭제 정책을 `Retain`으로 설정하고, 스택에서 테이블을 제거하고, 콘솔에서 테이블을 글로벌 테이블로 변환한 다음 글로벌 테이블을 스택에 새 리소스로 가져옵니다. 자세한 내용은 [AWS GitHub 리포지토리](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)를 참조하세요.
+ 교차 계정 복제는 현재 지원되지 않습니다.