기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS 서비스 유형
AWS 장애 격리 경계에 따라 영역, 지역, 글로벌 등 세 가지 범주의 서비스를 운영합니다. 이 섹션에서는 특정 서비스 유형의 장애가 실행 중인 워크로드에 어떤 영향을 미치는지 확인할 수 있도록 이러한 다양한 유형의 서비스가 어떻게 설계되었는지 자세히 설명합니다. AWS또한 탄력적인 방식으로 이러한 서비스를 사용하도록 워크로드를 설계하는 방법에 대한 높은 수준의 지침을 제공합니다. 글로벌 서비스의 경우, 이 문서는 서비스의 컨트롤 플레인 장애로 인한 워크로드 영향을 방지하는 데 도움이 [부록 B - 에지 네트워크 글로벌 서비스 지침](appendix-b---edge-network-global-service-guidance.md) 되는 규범적 지침도 제공합니다. 이를 통해 단일 장애 지점으로 인한 영향을 최소화하면서 글로벌 AWS 서비스에 대한 의존도를 안전하게 유지할 수 있습니다. [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md)
**Topics**
+ [영역별 서비스](zonal-services.md)
+ [지역 서비스](regional-services.md)
+ [글로벌 서비스](global-services.md)
# 영역별 서비스
[https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) AWS 을 통해 Amazon EC2 EBS 및 Amazon과 같은 영역 서비스를 제공할 수 있습니다. 영역 서비스는 리소스를 배포할 가용 영역을 지정할 수 있는 기능을 제공하는 서비스입니다. 이러한 서비스는 지역 내 각 가용 영역에서 독립적으로 작동하며, 더 중요한 것은 각 가용 영역에서도 독립적으로 장애가 발생한다는 것입니다. 즉, 한 가용 영역에 있는 서비스의 구성 요소는 다른 가용 영역의 구성 요소에 종속되지 않습니다. 영역 서비스에는 **영역** 데이터 플레인이 있기 때문에 이렇게 할 수 있습니다. 와 같은 일부 경우에는 인스턴스 시작과 EC2 같이 영역별로 정렬된 작업을 위한 영역 컨트롤 플레인도 서비스에 포함됩니다. EC2 AWS 또한 이러한 서비스의 경우 서비스와 쉽게 상호 작용할 수 있도록 지역 컨트롤 플레인 엔드포인트를 제공합니다. 또한 지역 제어 플레인은 지역 범위 기능을 제공할 뿐만 아니라 영역 제어 플레인 상단의 집계 및 라우팅 계층 역할도 합니다. 이는 다음 그림에 나와 있습니다.
![\[이 이미지는 영역별로 분리된 컨트롤 플레인과 데이터 플레인이 있는 영역 서비스를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png)
가용 영역을 통해 고객은 단일 데이터 센터에서보다 가용성이 높고 내결함성이 뛰어나며 확장 가능한 프로덕션 워크로드를 운영할 수 있습니다. 워크로드가 여러 가용 영역을 사용하는 경우 단일 가용 영역의 물리적 인프라에 영향을 미치는 문제로부터 고객을 더 잘 격리하고 보호할 수 있습니다. 이를 통해 고객은 가용 영역 전반에 걸쳐 중복되는 서비스를 구축할 수 있으며, 올바르게 설계되면 한 가용 영역에 장애가 발생하더라도 운영 상태를 유지할 수 있습니다. 고객은 이를 활용하여 가용성이 높고 복원력이 뛰어난 AZI 워크로드를 만들 수 있습니다. 아키텍처에 AZI 구현하면 한 가용 영역의 리소스가 다른 가용 영역의 리소스와의 상호 작용을 최소화하거나 제거하므로 격리된 가용 영역 장애로부터 빠르게 복구할 수 있습니다. 이를 통해 가용 영역 간 종속성을 제거하여 가용 영역 대피를 단순화할 수 있습니다. 가용 영역 제거 메커니즘 생성에 대한 자세한 내용은 [고급 다중 AZ 복원 패턴을](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) 참조하십시오. 또한 가용 영역을 한 번에 단일 가용 영역에만 배포하거나 해당 가용 영역의 변경이 잘못된 경우 서비스에서 가용 영역을 제거하는 등 자체 서비스에 AWS 사용되는 것과 동일한 모범 사례를 따라 가용 영역을 더욱 활용할 수 있습니다.
[정적 안정성은](static-stability.md) 다중 가용 영역 아키텍처에서도 중요한 개념입니다. 다중 가용 영역 아키텍처에서 대비해야 하는 장애 모드 중 하나는 가용 영역의 손실이며, 이로 인해 가용 영역의 가치가 손실될 수 있습니다. 가용 영역 손실을 처리할 수 있을 만큼 충분한 용량을 미리 프로비저닝하지 않은 경우 현재 부하로 인해 남은 용량이 과다하게 될 수 있습니다. 또한 손실된 용량을 대체하려면 사용하는 영역 서비스의 컨트롤 플레인에 의존해야 하는데, 이는 정적으로 안정적인 설계보다 안정성이 떨어질 수 있습니다. 이 경우 충분한 추가 용량을 사전 프로비저닝하면 동적으로 변경할 필요 없이 정상 운영을 계속할 수 있으므로 가용 영역과 같은 장애 도메인이 손실되어도 정적으로 안정적으로 대처할 수 있습니다.
여러 가용 영역에 배포된 Auto Scaling EC2 인스턴스 그룹을 사용하여 워크로드의 필요에 따라 동적으로 규모를 확장 및 축소할 수 있습니다. Auto Scaling은 몇 분에서 수십 분에 걸쳐 점진적으로 사용량이 변경되는 경우에 적합합니다. 하지만 새 EC2 인스턴스를 시작하는 데는 시간이 걸립니다. 특히 인스턴스에 부트스트래핑 (예: 에이전트, 애플리케이션 바이너리 또는 구성 파일 설치) 이 필요한 경우에는 더욱 그렇습니다. 이 기간 동안에는 현재 부하로 인해 남은 용량이 과다해질 수 있습니다. 또한 Auto Scaling을 통한 새 인스턴스 배포는 EC2 컨트롤 플레인에 의존합니다. 이는 단점이 있습니다. 단일 가용 영역이 손실되어도 정적으로 안정적으로 작동하려면 Auto Scaling을 사용하여 새 EC2 인스턴스를 프로비저닝하는 대신 손상된 가용 영역에서 이동된 부하를 처리할 수 있을 만큼 충분한 인스턴스를 다른 가용 영역에 미리 프로비저닝해야 합니다. 하지만 추가 용량을 사전 프로비저닝하면 추가 비용이 발생할 수 있습니다.
예를 들어 정상 운영 중에 워크로드에 3개의 가용 영역에서 고객 트래픽을 처리하기 위해 6개의 인스턴스가 필요하다고 가정해 보겠습니다. 단일 가용 영역 장애에 대해 정적 안정성을 유지하려면 각 가용 영역에 총 9개의 인스턴스를 배포해야 합니다. 가용 영역 상당의 인스턴스 중 하나에 장애가 발생하더라도 여전히 6개 남았기 때문에 장애 발생 시 새 인스턴스를 프로비저닝하고 구성할 필요 없이 고객 트래픽을 계속 제공할 수 있습니다. 이 경우 50% 의 추가 인스턴스를 실행하기 때문에 EC2 용량의 정적 안정성을 확보하려면 추가 비용이 듭니다. 리소스를 사전 프로비저닝할 수 있는 모든 서비스 (예: S3 버킷 또는 사용자 사전 프로비저닝) 에 추가 비용이 발생하는 것은 아닙니다. 원하는 워크로드 복구 시간을 초과할 위험과 정적 안정성 구현의 절충점을 비교해야 합니다.
AWS Local Zones 및 Outposts는 일부 AWS 서비스의 데이터 플레인을 최종 사용자에게 더 가깝게 제공합니다. 이러한 서비스의 컨트롤 플레인은 상위 지역에 있습니다. Local Zone 또는 Outposts 인스턴스는 로컬 영역 또는 Outposts 서브넷을 생성한 가용 EC2 영역과 같은 영역 서비스에 EBS 대한 컨트롤 플레인 종속성을 갖게 됩니다. 또한 Elastic Load Balancing (ELB), 보안 그룹, 아마존 엘라스틱 쿠버네티스 서비스 (Amazon) 에서 관리하는 쿠버네티스 컨트롤 플레인 EKS (사용하는 경우) 과 같은 리전 [서비스에](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) 대한 리전 컨트롤 플레인에도 종속됩니다. EKS Outposts와 관련된 추가 정보는 [설명서와 [지원 및](https://aws.amazon.com/outposts/rack/faqs/) 유지](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) 관리를 참조하십시오. FAQ Local Zones 또는 Outposts를 사용할 때 정적 안정성을 구현하면 상위 지역에 대한 네트워크 연결 중단이나 컨트롤 플레인 장애에 대한 복원력을 개선할 수 있습니다.
# 지역 서비스
지역 서비스는 여러 가용 영역을 기반으로 AWS 구축된 서비스이므로 고객이 영역 서비스를 최대한 활용하는 방법을 고민하지 않아도 됩니다. 여러 가용 영역에 배포된 서비스를 논리적으로 그룹화하여 고객에게 단일 지역 엔드포인트를 제공합니다. 아마존 SQS 및 [아마존 DynamoDB는](https://aws.amazon.com/dynamodb/) 지역 서비스의 예입니다. 이들은 가용 영역의 독립성과 중복성을 사용하여 가용성 및 내구성 위험 범주로 인프라 장애를 최소화합니다. 예를 들어 Amazon S3는 요청과 데이터를 여러 가용 영역에 분산하고 가용 영역 장애로부터 자동으로 복구하도록 설계되었습니다. 하지만 서비스의 리전 엔드포인트와만 상호 작용합니다.
AWS 대부분의 고객은 영역 서비스를 사용하는 지역 서비스 또는 다중 AZ 아키텍처를 사용하여 단일 지역에서 복원력 목표를 달성할 수 있다고 생각합니다. 그러나 일부 워크로드에는 추가 중복성이 필요할 수 있으며, 이를 분리하여 HA 또는 비즈니스 연속성을 위한 다중 지역 AWS 리전 아키텍처를 만들 수 있습니다. 물리적/논리적 분리를 통해 둘 사이의 상호 AWS 리전 관련된 장애를 방지할 수 있습니다. 즉, EC2 고객으로서 가용 영역 전체에 배포하여 가용 영역 격리의 이점을 누릴 수 있는 경우와 마찬가지로 여러 지역에 배포하면 지역 서비스에서도 동일한 이점을 얻을 수 있습니다. 이를 위해서는 애플리케이션에 다중 지역 아키텍처를 구현해야 하며, 이를 통해 지역 서비스의 장애에 대한 복원력을 확보할 수 있습니다.
그러나 다중 지역 아키텍처의 이점을 달성하는 것은 어려울 수 있습니다. 응용 프로그램 수준에서 어떤 것도 취소하지 않으면서 지역적 격리를 활용하려면 세심한 작업이 필요합니다. 예를 들어, 지역 간에 애플리케이션을 페일오버하는 경우 각 지역의 애플리케이션 스택을 엄격하게 구분하고, 모든 애플리케이션 종속성을 파악하고, 애플리케이션의 모든 부분을 함께 페일오버해야 합니다. 애플리케이션 간 종속성이 많은 복잡한 마이크로서비스 기반 아키텍처로 이를 달성하려면 많은 엔지니어링 및 비즈니스 팀 간의 계획과 조정이 필요합니다. 개별 워크로드가 자체적으로 페일오버 결정을 내리도록 허용하면 조정이 덜 복잡해지지만 단일 지역 내에서와 비교하여 지역 간에 발생하는 지연 시간의 현저한 차이로 인해 모달 동작이 발생합니다.
AWS 은 현재 지역 간 동기식 복제 기능을 제공하지 않습니다. 지역 간에 비동기적으로 복제된 데이터스토어 (에서 제공 AWS) 를 사용하는 경우 지역 간에 애플리케이션을 페일오버하면 데이터 손실이나 불일치가 발생할 수 있습니다. 발생할 수 있는 불일치를 줄이려면 신뢰할 수 있고 워크로드 포트폴리오의 여러 데이터 저장소에서 운영해야 하는 신뢰할 수 있는 데이터 조정 프로세스가 필요합니다. 그렇지 않으면 데이터 손실을 감수할 수 있어야 합니다. 마지막으로, 페일오버를 연습하여 필요할 때 제대로 작동하는지 확인해야 합니다. 페일오버를 실행하기 위해 애플리케이션을 지역 간에 정기적으로 교체하려면 상당한 시간과 리소스가 투자됩니다. 여러 지역에서 동시에 실행되는 애플리케이션을 지원하기 위해 여러 지역에서 동기식으로 복제된 데이터스토어를 사용하기로 결정한 경우, 100마일 또는 1000마일에 걸친 이러한 데이터베이스의 성능 특성 및 지연 시간은 단일 지역에서 운영되는 데이터베이스와는 매우 다릅니다. 이를 위해서는 이 동작을 고려하여 처음부터 애플리케이션 스택을 계획해야 합니다. 또한 두 지역의 가용성이 크게 종속되어 워크로드의 복원력이 저하될 수 있습니다.
# 글로벌 서비스
지역 및 영역 AWS 서비스 외에도 컨트롤 플레인과 데이터 플레인이 각 지역에 독립적으로 존재하지 않는 소수의 AWS 서비스가 있습니다. *리소스가 지역별로 한정되지 않기 때문에 일반적으로 글로벌 리소스라고 합니다.* 글로벌 AWS 서비스는 여전히 정적 안정성을 확보하기 위해 컨트롤 플레인과 데이터 플레인을 분리하는 기존의 AWS 설계 패턴을 따릅니다. 대부분의 글로벌 서비스가 크게 다른 점은 컨트롤 플레인이 *한* AWS 리전곳에서 호스팅되는 반면 데이터 플레인은 전 세계에 분산되어 있다는 점입니다. 세 가지 유형의 글로벌 서비스가 있으며, 선택한 구성에 따라 글로벌처럼 보일 수 있는 서비스 집합도 있습니다.
다음 섹션에서는 각 글로벌 서비스 유형과 해당 제어 플레인과 데이터 플레인이 분리되는 방식을 설명합니다. 이 정보를 사용하면 글로벌 서비스 컨트롤 플레인에 의존하지 않고도 신뢰할 수 있는 고가용성 (HA) 및 재해 복구 (DR) 메커니즘을 구축하는 방법을 안내할 수 있습니다. 이 접근 방식은 글로벌 서비스 컨트롤 플레인이 호스팅되는 지역과 다른 지역에서 운영하는 경우에도 아키텍처의 단일 장애 지점을 제거하고 지역 간 잠재적 영향을 방지하는 데 도움이 됩니다. 또한 글로벌 서비스 컨트롤 플레인에 의존하지 않는 페일오버 메커니즘을 안전하게 구현하는 데도 도움이 됩니다.
## 파티션별로 고유한 글로벌 서비스
*일부 글로벌 AWS 서비스는 각 파티션에 존재합니다 (이 백서에서는 파티션 서비스라고 함).* 파티셔널 서비스는 컨트롤 플레인을 하나로 제공합니다. AWS 리전 AWS Network Manager와 같은 일부 파티션 서비스는 컨트롤 플레인 전용이며 다른 서비스의 데이터 플레인을 오케스트레이션합니다. 예를 들어 다른 파티셔널 서비스에는 파티션의 모든 영역에 격리되어 분산되는 자체 데이터 플레인이 있습니다. IAM AWS 리전 파티션 서비스에 장애가 발생해도 다른 파티션에는 영향을 주지 않습니다. `aws`파티션에서 IAM 서비스의 컨트롤 플레인은 `us-east-1` 지역에 있으며 파티션의 각 리전에는 분리된 데이터 플레인이 있습니다. 또한 파티셔널 서비스는 및 `aws-cn` 파티션에 독립적인 컨트롤 플레인과 데이터 플레인을 `aws-us-gov` 갖추고 있습니다. 컨트롤 플레인과 데이터 플레인의 분리는 다음 다이어그램에 나와 있습니다. IAM
![\[이 이미지는 단일 컨트롤 플레인과 지역화된 데이터 플레인이 있음을 IAM 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png)
다음은 파티션 서비스와 파티션 내 해당 컨트롤 플레인 위치입니다. `aws`
+ AWS IAM (`us-east-1`)
+ AWS Organizations (`us-east-1`)
+ AWS 계정 관리 () `us-east-1`
+ Route 53 애플리케이션 복구 컨트롤러 (ARC`us-west-2`) () - 이 서비스는 `aws` 파티션에만 있습니다.
+ AWS 네트워크 관리자 (`us-west-2`)
+ 루트 53 프라이빗 DNS (`us-east-1`)
이러한 서비스 컨트롤 플레인 중 가용성에 영향을 미치는 이벤트가 발생하는 경우 이러한 서비스에서 제공하는 CRUDL -type 작업을 사용하지 못할 수 있습니다. 따라서 복구 전략이 이러한 작업에 종속되어 있는 경우 컨트롤 플레인 또는 컨트롤 플레인을 호스팅하는 지역에 대한 가용성에 영향을 미치면 복구 성공 가능성이 낮아집니다. [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md)복구 중에 글로벌 서비스 컨트롤 플레인에 대한 종속성을 제거하기 위한 전략을 제공합니다.
****권장 사항****
복구 경로에서 파티션 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하세요. 파티셔널 서비스를 설계하는 방법에 [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md) 대한 자세한 내용은 을 참조하십시오.
## 에지 네트워크의 글로벌 서비스
차세대 글로벌 AWS 서비스 세트는 `aws` 파티션에 컨트롤 플레인을 두고 글로벌 PoP ([AWS 리전 PoS](points-of-presence.md)) 인프라에서 데이터 플레인을 호스팅합니다 (아마도 그럴 수도 있음). 호스팅된 데이터 플레인은 인터넷뿐만 아니라 모든 파티션의 리소스에서 액세스할 PoPs 수 있습니다. 예를 들어 Route 53은 리전에서 컨트롤 플레인을 운영하지만 데이터 플레인은 PoPs 리전 세계 수백 개 `us-east-1` 지역과 각 지역 AWS 리전 (지역 DNS 내 Route 53 퍼블릭 및 프라이빗 지원) 에 분산되어 있습니다. Route 53 상태 확인도 데이터 플레인의 일부이며 `aws` 파티션에 AWS 리전 있는 8개부터 수행됩니다. 클라이언트는 AWS 가상 사설 클라우드 (VPC) 와 같은 GovCloud 다른 파티션을 포함하여 인터넷상의 어느 곳에서나 Route 53 퍼블릭 호스팅 영역을 DNS 사용하여 문제를 해결할 수 있습니다. 다음은 글로벌 에지 네트워크 서비스와 `aws` 파티션 내 해당 컨트롤 플레인 위치입니다.
+ Route 53 퍼블릭 DNS (`us-east-1`)
+ 아마존 CloudFront (`us-east-1`)
+ AWS WAF 클래식 포 CloudFront (`us-east-1`)
+ AWS WAF 용 CloudFront (`us-east-1`)
+ Amazon 인증서 관리자 (ACM) 용 CloudFront (`us-east-1`)
+ AWS글로벌 액셀러레이터 (AGA) (`us-west-2`)
+ AWS Shield Advanced (`us-east-1`)
EC2인스턴스 또는 엘라스틱 IP 주소에 대한 AGA 상태 확인을 사용하는 경우 Route 53 상태 확인을 사용합니다. AGA상태 확인의 생성 또는 업데이트는 Route 53 컨트롤 플레인에 따라 달라집니다`us-east-1`. AGA상태 점검 실행에는 Route 53 상태 점검 데이터 플레인이 사용됩니다.
이러한 서비스의 컨트롤 플레인을 호스팅하는 지역에 영향을 미치는 장애 또는 컨트롤 플레인 자체에 영향을 미치는 장애가 발생하는 경우 이러한 서비스에서 제공하는 CRUDL -type 작업을 사용하지 못할 수 있습니다. 복구 전략에서 이러한 작업에 의존했다면 이러한 서비스의 데이터 플레인에만 의존하는 경우보다 해당 전략의 성공 가능성이 낮을 수 있습니다.
****권장 사항****
복구 경로에서 에지 네트워크 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하십시오. 에지 네트워크에서 글로벌 서비스를 설계하는 방법에 [부록 B - 에지 네트워크 글로벌 서비스 지침](appendix-b---edge-network-global-service-guidance.md) 대한 자세한 내용은 을 참조하십시오.
## 글로벌 단일 지역 운영
최종 카테고리는 이전 카테고리처럼 전체 서비스가 아닌 글로벌 영향 범위를 갖는 서비스 내의 특정 컨트롤 플레인 운영으로 구성됩니다. 지정한 지역의 영역 및 지역 서비스와 상호 작용하는 동안 특정 작업에는 리소스가 위치한 곳과는 다른 단일 지역에 대한 근본적인 종속성이 있습니다. 이러한 서비스는 단일 지역에서만 제공되는 서비스와는 다릅니다. 해당 서비스 목록은 을 [부록 C - 단일 지역 서비스](appendix-c---single-region-services.md) 참조하십시오.
기본 글로벌 종속성에 영향을 미치는 오류가 발생하는 경우 종속 작업의 CRUDL -type 작업을 사용하지 못할 수 있습니다. 복구 전략에서 이러한 작업에 종속된 경우 이러한 서비스의 데이터 영역에만 의존하는 경우보다 해당 전략의 성공 가능성이 낮을 수 있습니다. 복구 전략을 위해 이러한 작업에 종속되지 않도록 해야 합니다.
다음은 글로벌 범위를 가진 다른 서비스가 의존할 수 있는 서비스 목록입니다.
+ **Route 53**
일부 AWS 서비스는 리소스별 DNS 이름을 제공하는 리소스를 생성합니다. 예를 들어 Elastic Load Balancer (ELB) 를 프로비저닝하면 서비스가 Route 53에서 에 대한 공개 DNS 기록과 상태 확인을 생성합니다. ELB 이는 Route 53 컨트롤 플레인에 의존합니다. `us-east-1` 사용하는 다른 서비스도 컨트롤 플레인 워크플로의 일부로 Route 53 레코드를 프로비저닝하거나ELB, 공개 Route 53 DNS 레코드를 생성하거나, Route 53 상태 확인을 생성해야 할 수 있습니다. 예를 들어, 아마존 API 게이트웨이 REST API 리소스, 아마존 관계형 데이터베이스 서비스 (Amazon) 데이터베이스 또는 RDS OpenSearch 아마존 서비스 도메인을 프로비저닝하면 모두 Route 53에 레코드가 DNS 생성됩니다. 다음은 Route 53 컨트롤 플레인을 사용하여 DNS 레코드, 호스팅 영역을 생성, 업데이트 또는 삭제하거나 Route 53 상태 확인을 생성하는 `us-east-1` 데 컨트롤 플레인이 의존하는 서비스 목록입니다. 이 목록은 완전한 것이 아니며, 리소스를 생성, 업데이트 또는 삭제하기 위한 컨트롤 플레인 작업이 Route 53 컨트롤 플레인에 따라 달라지는 가장 일반적으로 사용되는 서비스 중 일부를 강조하기 위한 것입니다.
+ 아마존 API 게이트웨이 REST 및 HTTP APIs
+ 아마존 RDS 인스턴스
+ 아마존 Aurora 데이터베이스
+ 아마존 ELB 로드 밸런서
+ AWS PrivateLink VPC엔드포인트
+ AWS Lambda URLs
+ 아마존 ElastiCache
+ 아마존 OpenSearch 서비스
+ 아마존 CloudFront
+ Amazon MemoryDB
+ Amazon Neptune
+ 아마존 다이나모DB 액셀러레이터 () DAX
+ AGA
+ DNS기반 서비스 검색 (Route 53을 관리하는 AWS Cloud Map API 데 사용ECS) 을 지원하는 Amazon Elastic 컨테이너 서비스 (AmazonDNS)
+ Amazon EKS 쿠버네티스 컨트롤 플레인
[EC2인스턴스 호스트 이름에 대한 VPC DNS 서비스는 각각 독립적으로 AWS 리전 존재하며 Route 53](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) 컨트롤 플레인에 의존하지 않는다는 점에 유의해야 합니다. ,, `ip-10-0-10.ec2.internal` `ip-10-0-1-5.compute.us-west-2.compute.internal``i-0123456789abcdef.ec2.internal`, 등과 같이 VPC DNS 서비스의 EC2 인스턴스에 대해 AWS 생성되는 레코드는 Route 53 컨트롤 플레인을 사용하지 않습니다. `i-0123456789abcdef.us-west-2.compute.internal` `us-east-1`
****권장 사항****
복구 경로에서 Route 53 리소스 레코드, 호스팅 영역 또는 상태 확인의 생성, 업데이트 또는 삭제가 필요한 리소스의 생성, 업데이트 또는 삭제에만 의존하지 마십시오. 예를 들어 복구 경로에서 Route 53 컨트롤 플레인에 대한 종속성을 방지하기 위해 이러한 리소스를 사전 프로비저닝하십시오. ELBs
+ **Amazon S3**
다음 Amazon S3 컨트롤 플레인 작업은 기본적으로 `us-east-1` `aws` 파티션에 종속되어 있습니다. Amazon S3 또는 기타 서비스에 영향을 미치는 장애로 인해 다른 지역에서 이러한 컨트롤 플레인 작업이 손상될 수 있습니다. `us-east-1`
```
PutBucketCors
DeleteBucketCors
PutAccelerateConfiguration
PutBucketRequestPayment
PutBucketObjectLockConfiguration
PutBucketTagging
DeleteBucketTagging
PutBucketReplication
DeleteBucketReplication
PutBucketEncryption
DeleteBucketEncryption
PutBucketLifecycle
DeleteBucketLifecycle
PutBucketNotification
PutBucketLogging
DeleteBucketLogging
PutBucketVersioning
PutBucketPolicy
DeleteBucketPolicy
PutBucketOwnershipControls
DeleteBucketOwnershipControls
PutBucketAcl
PutBucketPublicAccessBlock
DeleteBucketPublicAccessBlock
```
Amazon S3 다중 지역 액세스 포인트 (MRAP) 의 컨트롤 플레인은 해당 지역을 직접 MRAPs 대상으로 생성, 업데이트 또는 삭제를 요청하는 [요청에서만 `us-west-2` 호스팅됩니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html). MRAP또한 컨트롤 플레인에는 콘텐츠를 제공하도록 구성된 각 지역의 AGA in`us-west-2`, Route 53 내부 및 ACM 각 리전에 대한 기본 종속성이 있습니다. `us-east-1` MRAP 복구 경로나 자체 시스템의 데이터 플레인에 있는 MRAP 컨트롤 플레인의 가용성에 의존해서는 안 됩니다. 이는 에 있는 각 버킷의 액티브 또는 패시브 라우팅 상태를 지정하는 데 사용되는 [MRAP페일오버 컨트롤과는](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html) 다릅니다. MRAP APIs이들은 [5개로 AWS 리전](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration) 호스팅되며 서비스의 데이터 플레인을 사용하여 트래픽을 효과적으로 전환하는 데 사용할 수 있습니다.
또한 Amazon S3 [버킷 이름은 전 세계적으로 `CreateBucket` 고유하며](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) `DeleteBucket` APIs`us-east-1`, 호출이 버킷을 생성하려는 특정 지역으로 전달되더라도 `aws` 파티션에 대한 모든 API 호출은 이름의 고유성을 보장하기 위해 파티션에서 이를 기반으로 합니다. 마지막으로, 중요한 버킷 생성 워크플로가 있는 경우 버킷 이름의 특정 철자, 특히 식별 가능한 패턴을 따르는 버킷 이름의 사용 가능 여부에 의존해서는 안 됩니다.
****권장 사항****
복구 경로의 일부로 S3 버킷을 삭제 또는 새로 만들거나 S3 버킷 구성을 업데이트하는 데 의존하지 마십시오. 필요한 모든 S3 버킷을 필요한 구성으로 사전 프로비저닝하여 장애를 복구하기 위해 변경할 필요가 없도록 하십시오. 이 접근 방식은 MRAPs 에도 적용됩니다.
+ **CloudFront**
Amazon API Gateway는 [엣지에 최적화된 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized) 엔드포인트를 제공합니다. 이러한 엔드포인트 생성은 게이트웨이 엔드포인트 앞에 `us-east-1` 배포를 생성하는 CloudFront 컨트롤 플레인에 따라 달라집니다.
****권장 사항****
복구 경로의 일부로 엣지에 최적화된 API 게이트웨이 엔드포인트를 새로 생성하는 것에 의존하지 마십시오. 필요한 모든 게이트웨이 엔드포인트를 사전 프로비저닝하십시오. API
이 섹션에서 설명하는 모든 종속성은 데이터 플레인 작업이 아니라 컨트롤 플레인 작업입니다. 워크로드가 정적으로 안정되도록 구성된 경우 이러한 종속성이 복구 경로에 영향을 주지 않아야 합니다. 정적 안정성을 구현하려면 추가 작업이나 서비스가 필요하다는 점을 염두에 두세요.
## 기본 글로벌 엔드포인트를 사용하는 서비스
일부 경우에는 AWS 서비스가 AWS 보안 토큰 서비스 ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)) 와 같은 기본 글로벌 엔드포인트를 제공합니다. 다른 서비스는 이 기본 글로벌 엔드포인트를 기본 구성으로 사용할 수 있습니다. 즉, 사용 중인 지역 서비스가 단일 AWS 리전지역에 대한 글로벌 종속성을 가질 수 있습니다. 다음 세부 정보는 기본 글로벌 엔드포인트에서 의도하지 않은 종속성을 제거하여 지역적 방식으로 서비스를 사용하는 데 도움이 되는 방법을 설명합니다.
**AWS STS:** STS 는 IAM 사용자 또는 인증한 사용자 (페더레이션 사용자) 를 위해 권한이 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스입니다. STS AWS 소프트웨어 개발 키트 (SDK) 및 명령줄 인터페이스 () 에서의 사용 기본값은 입니다. CLI `us-east-1` 이 STS 서비스는 지역별 엔드포인트도 제공합니다. 이러한 엔드포인트는 기본적으로 활성화되며, 지역에서도 기본적으로 활성화됩니다. [AWS STS지역화된](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) 엔드포인트를 SDK 구성하거나 CLI 다음 지침에 따라 언제든지 이러한 이점을 활용할 수 있습니다. 또한 SigV4A를 사용하려면 지역 엔드포인트에서 요청한 [임시 자격 증명이 필요합니다](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions). STS 이 작업에는 글로벌 STS 엔드포인트를 사용할 수 없습니다.
****권장 사항****
지역 STS 엔드포인트를 사용하도록 SDK 및 CLI 구성을 업데이트하십시오.
**보안 어설션 마크업 언어 (SAML) 로그인:** SAML 서비스는 어디에나 존재합니다. AWS 리전이 서비스를 사용하려면 적절한 지역 SAML 엔드포인트 (예: [https://us-west-2.signin.aws.amazon.com/saml](https://us-west-2.signin.aws.amazon.com/saml)) 를 선택하십시오. 지역 엔드포인트를 사용하려면 신뢰 정책 및 ID 공급자 (IdP) 의 구성을 업데이트해야 합니다. 자세한 내용은 [AWS SAML설명서를 참조하십시오](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html).
호스팅되는 IdP를 사용하는 경우 장애 이벤트 중에 IdP가 영향을 받을 위험이 있습니다. AWS AWS 이로 인해 IdP 구성을 업데이트할 수 없거나 완전히 페더레이션하지 못할 수 있습니다. IdP가 손상되거나 사용할 수 없는 경우에 대비하여 “브레이크글라스” 사용자를 사전 프로비저닝해야 합니다. 정적으로 안정적인 방식으로 Break-Glass 사용자를 생성하는 방법에 [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md) 대한 자세한 내용은 를 참조하십시오.
****권장 사항****
여러 지역의 로그인을 IAM 허용하도록 역할 신뢰 정책을 업데이트하세요. SAML 장애가 발생한 경우 선호 엔드포인트가 손상된 경우 다른 지역 SAML 엔드포인트를 사용하도록 IdP 구성을 업데이트하십시오. IdP가 손상되었거나 사용할 수 없는 경우에 대비하여 브레이크-글래스 사용자를 생성하세요.
**AWS IAMIdentity Center:** Identity Center는 고객 및 클라우드 애플리케이션에 대한 Single Sign-On 액세스를 중앙에서 쉽게 관리할 수 있는 클라우드 기반 서비스입니다. AWS 계정 Identity Center는 선택한 단일 지역에 배포해야 합니다. 하지만 서비스의 기본 동작은 에서 호스팅되는 글로벌 SAML 엔드포인트 ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)) 를 사용하는 `us-east-1` 것입니다. Identity Center를 다른 AWS 리전곳에 배포한 경우 Identity Center [배포와 동일한 지역 콘솔 엔드포인트를 대상으로 하도록 모든 권한 세트의 릴레이 상태를](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) URL 업데이트해야 합니다. [예를 들어 Identity Center를 에 `us-west-2` 배포한 경우 https://us-west-2.console.aws.amazon.com 을 사용하도록 권한 집합의 릴레이 상태를 업데이트해야 합니다.](https://us-west-2.console.aws.amazon.com) 이렇게 하면 Identity Center 배포에 대한 `us-east-1` 종속성이 모두 제거됩니다.
또한 IAM Identity Center는 단일 지역에만 배포할 수 있으므로 배포에 장애가 발생할 경우를 대비하여 “브레이크글라스” 사용자를 미리 프로비전해야 합니다. 정적으로 안정적인 방식으로 Break-Glass 사용자를 생성하는 방법에 [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md) 대한 자세한 내용은 를 참조하십시오.
****권장 사항****
서비스가 배포된 지역과 일치하도록 IAM Identity Center에서 권한 URL 집합의 릴레이 상태를 설정하십시오. IAMIdentity Center 배포를 사용할 수 없는 경우를 대비하여 유용한 사용자를 생성하십시오.
**Amazon S3 스토리지 렌즈:** 스토리지 렌즈는 라는 기본 대시보드를 제공합니다 default-account-dashboard. 대시보드 구성 및 관련 지표는 에 저장됩니다`us-east-1`. 대시보드 구성 및 지표 데이터의 [홈 지역을 지정하여 다른 지역에](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region) 추가 대시보드를 생성할 수 있습니다.
****권장 사항****
의 서비스에 영향을 미치는 장애 발생 중에 기본 S3 Storage Lens 대시보드의 데이터가 필요한 경우 대체 홈 지역에 `us-east-1` 추가 대시보드를 생성하십시오. 추가 지역에서 생성한 다른 사용자 지정 대시보드를 복제할 수도 있습니다.
## 글로벌 서비스 요약
글로벌 서비스를 위한 데이터 플레인은 지역 AWS 서비스와 유사한 격리 및 독립 원칙을 적용합니다. 한 지역의 데이터 플레인에 영향을 미치는 장애가 다른 AWS 리전지역의 IAM 데이터 플레인 작동에는 영향을 미치지 않습니다. IAM 마찬가지로 PoP에서 Route 53의 데이터 플레인에 영향을 미치는 장애는 나머지 Route 53 데이터 플레인의 작동에는 영향을 미치지 않습니다. PoPs 따라서 컨트롤 플레인이 운영되는 지역 또는 컨트롤 플레인 자체에 영향을 미치는 서비스 가용성 이벤트를 고려해야 합니다. 각 글로벌 서비스에는 컨트롤 플레인이 하나뿐이므로 해당 컨트롤 플레인에 영향을 미치는 장애가 발생할 경우 CRUDL -type 작업 (서비스를 직접 사용하는 대신 서비스를 설정하거나 구성하는 데 일반적으로 사용되는 구성 작업) 에 지역 간 영향을 미칠 수 있습니다.
글로벌 서비스를 탄력적으로 사용하도록 워크로드를 설계하는 가장 효과적인 방법은 정적 안정성을 사용하는 것입니다. 장애 시나리오에서는 영향을 완화하거나 다른 위치로의 장애 조치를 취하기 위해 컨트롤 플레인을 사용하여 변경할 필요가 없도록 워크로드를 설계하십시오. 컨트롤 플레인 종속성을 제거하고 단일 장애 지점을 제거하기 위해 이러한 유형의 글로벌 서비스를 활용하는 방법에 대한 규범적 지침은 및 을 참조하십시오. [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md) [부록 B - 에지 네트워크 글로벌 서비스 지침](appendix-b---edge-network-global-service-guidance.md) 복구를 위해 컨트롤 플레인 작업의 데이터가 필요한 경우 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) Parameter Store (SSMParameter Store) 파라미터, DynamoDB 테이블 또는 S3 버킷과 같은 데이터 플레인을 통해 액세스할 수 있는 데이터 스토어에 이 데이터를 캐시하십시오. 중복성을 위해 해당 데이터를 추가 지역에 저장하도록 선택할 수도 있습니다. 예를 들어, Route 53 애플리케이션 복구 컨트롤러 (ARC) 의 [모범 사례에](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html) 따라 5개의 지역 클러스터 엔드포인트를 하드코딩하거나 북마크해야 합니다. 장애 이벤트 중에는 매우 안정적인 데이터 플레인 클러스터에서 호스팅되지 않는 Route 53 ARC API 작업을 비롯한 일부 API 작업에 액세스하지 못할 수 있습니다. `DescribeCluster`API작업을 사용하여 Route 53 ARC 클러스터의 엔드포인트를 나열할 수 있습니다.
다음은 글로벌 서비스의 컨트롤 플레인에 대한 종속성을 유발하는 가장 일반적인 구성 오류 또는 안티 패턴 중 일부를 요약한 것입니다.
+ Route 53 레코드를 변경하여 A 레코드 값을 업데이트하거나 가중치가 적용된 레코드 세트의 가중치를 변경하여 장애 조치를 수행합니다.
+ 장애 조치 중에 IAM 역할 및 정책을 포함한 IAM 리소스 생성 또는 업데이트. 이는 일반적으로 의도적인 것은 아니지만 테스트되지 않은 장애 조치 계획의 결과일 수 있습니다.
+ 장애 발생 시 운영자가 운영 환경에 액세스할 수 있도록 IAM Identity Center를 활용합니다.
+ IAMIdentity Center를 다른 지역에 배포한 `us-east-1` 경우 기본 ID 센터 구성을 사용하여 콘솔을 활용하십시오.
+ AGA트래픽 다이얼 가중치를 변경하여 지역별 장애 조치를 수동으로 수행합니다.
+ 손상된 오리진에서 장애가 발생되지 않도록 CloudFront 배포의 오리진 구성을 업데이트합니다.
+ Route 53에서의 DNS 레코드 생성에 따라 장애 발생 시 ELBs 및 RDS 인스턴스와 같은 재해 복구 (DR) 리소스를 프로비저닝합니다.
다음은 이전의 일반적인 안티패턴을 방지하는 데 도움이 되는 탄력적인 방식으로 글로벌 서비스를 사용하기 위해 이 섹션에 제공된 권장 사항을 요약한 것입니다.
****권장 사항 요약****
복구 경로에서 파티션 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하세요. 파티셔널 서비스를 설계하는 방법에 [부록 A - 부분 서비스 지침](appendix-a---partitional-service-guidance.md) 대한 자세한 내용은 을 참조하십시오.
복구 경로에서 에지 네트워크 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하십시오. 에지 네트워크에서 글로벌 서비스를 설계하는 방법에 [부록 B - 에지 네트워크 글로벌 서비스 지침](appendix-b---edge-network-global-service-guidance.md) 대한 자세한 내용은 을 참조하십시오.
복구 경로에서 Route 53 리소스 레코드, 호스팅 영역 또는 상태 확인의 생성, 업데이트 또는 삭제가 필요한 리소스의 생성, 업데이트 또는 삭제에만 의존하지 마십시오. 예를 들어 복구 경로에서 Route 53 컨트롤 플레인에 대한 종속성을 방지하기 위해 이러한 리소스를 사전 프로비저닝하십시오. ELBs
복구 경로의 일부로 S3 버킷을 삭제 또는 새로 만들거나 S3 버킷 구성을 업데이트하는 데 의존하지 마십시오. 필요한 모든 S3 버킷을 필요한 구성으로 사전 프로비저닝하여 장애를 복구하기 위해 변경할 필요가 없도록 하십시오. 이 접근 방식은 MRAPs 에도 적용됩니다.
복구 경로의 일부로 엣지에 최적화된 API 게이트웨이 엔드포인트를 새로 만드는 것에 의존하지 마십시오. 필요한 모든 게이트웨이 엔드포인트를 사전 프로비저닝하십시오. API
지역 STS 엔드포인트를 사용하도록 SDK 및 CLI 구성을 업데이트하십시오.
여러 지역의 SAML 로그인을 허용하도록 IAM 역할 신뢰 정책을 업데이트하세요. 장애가 발생한 경우 선호 엔드포인트가 손상된 경우 다른 지역 SAML 엔드포인트를 사용하도록 IdP 구성을 업데이트하십시오. IdP가 손상되었거나 사용할 수 없는 경우를 대비하여 브레이크글래스 사용자를 생성하세요.
서비스가 배포된 지역과 일치하도록 IAM Identity Center에서 권한 URL 집합의 릴레이 상태를 설정하십시오. Identity Center 배포를 사용할 수 없는 경우를 대비하여 유용한 사용자를 생성하십시오.
에서 서비스에 영향을 미치는 장애 발생 중에 기본 S3 Storage Lens 대시보드의 데이터가 필요한 경우 대체 `us-east-1` 홈 지역에 추가 대시보드를 생성하십시오. 추가 지역에서 생성한 다른 사용자 지정 대시보드를 복제할 수도 있습니다.