글로벌 서비스 - AWS장애 격리 경계
파티션별로 고유한 글로벌 서비스에지 네트워크의 글로벌 서비스글로벌 단일 지역 운영 기본 글로벌 엔드포인트를 사용하는 서비스글로벌 서비스 요약

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

글로벌 서비스

지역 및 영역 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 보여줍니다.

IAM단일 컨트롤 플레인과 지역화된 데이터 플레인이 있습니다.

다음은 파티션 서비스와 파티션 내 해당 컨트롤 플레인 위치입니다. aws

  • AWS IAM (us-east-1)

  • AWS Organizations (us-east-1)

  • AWS 계정 관리 () us-east-1

  • Route 53 애플리케이션 복구 컨트롤러 (ARCus-west-2) () - 이 서비스는 aws 파티션에만 있습니다.

  • AWS 네트워크 관리자 (us-west-2)

  • 루트 53 프라이빗 DNS (us-east-1)

이러한 서비스 컨트롤 플레인 중 가용성에 영향을 미치는 이벤트가 발생하는 경우 이러한 서비스에서 제공하는 CRUDL -type 작업을 사용하지 못할 수 있습니다. 따라서 복구 전략이 이러한 작업에 종속되어 있는 경우 컨트롤 플레인 또는 컨트롤 플레인을 호스팅하는 지역에 대한 가용성에 영향을 미치면 복구 성공 가능성이 낮아집니다. 부록 A - 부분 서비스 지침복구 중에 글로벌 서비스 컨트롤 플레인에 대한 종속성을 제거하기 위한 전략을 제공합니다.

권장 사항

복구 경로에서 파티션 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하세요. 파티셔널 서비스를 설계하는 방법에 부록 A - 부분 서비스 지침 대한 자세한 내용은 을 참조하십시오.

에지 네트워크의 글로벌 서비스

차세대 글로벌 AWS 서비스 세트는 aws 파티션에 컨트롤 플레인을 두고 글로벌 PoP (AWS 리전 PoS) 인프라에서 데이터 플레인을 호스팅합니다 (아마도 그럴 수도 있음). 호스팅된 데이터 플레인은 인터넷뿐만 아니라 모든 파티션의 리소스에서 액세스할 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 - 에지 네트워크 글로벌 서비스 지침 대한 자세한 내용은 을 참조하십시오.

글로벌 단일 지역 운영

최종 카테고리는 이전 카테고리처럼 전체 서비스가 아닌 글로벌 영향 범위를 갖는 서비스 내의 특정 컨트롤 플레인 운영으로 구성됩니다. 지정한 지역의 영역 및 지역 서비스와 상호 작용하는 동안 특정 작업에는 리소스가 위치한 곳과는 다른 단일 지역에 대한 근본적인 종속성이 있습니다. 이러한 서비스는 단일 지역에서만 제공되는 서비스와는 다릅니다. 해당 서비스 목록은 을 부록 C - 단일 지역 서비스 참조하십시오.

기본 글로벌 종속성에 영향을 미치는 오류가 발생하는 경우 종속 작업의 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 컨트롤 플레인에 의존하지 않는다는 점에 유의해야 합니다. ,, ip-10-0-10.ec2.internal ip-10-0-1-5.compute.us-west-2.compute.internali-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 호스팅됩니다. MRAP또한 컨트롤 플레인에는 콘텐츠를 제공하도록 구성된 각 지역의 AGA inus-west-2, Route 53 내부 및 ACM 각 리전에 대한 기본 종속성이 있습니다. us-east-1 MRAP 복구 경로나 자체 시스템의 데이터 플레인에 있는 MRAP 컨트롤 플레인의 가용성에 의존해서는 안 됩니다. 이는 에 있는 각 버킷의 액티브 또는 패시브 라우팅 상태를 지정하는 데 사용되는 MRAP페일오버 컨트롤과는 다릅니다. MRAP APIs이들은 5개로 AWS 리전 호스팅되며 서비스의 데이터 플레인을 사용하여 트래픽을 효과적으로 전환하는 데 사용할 수 있습니다.

    또한 Amazon S3 버킷 이름은 전 세계적으로 CreateBucket 고유하며 DeleteBucket APIsus-east-1, 호출이 버킷을 생성하려는 특정 지역으로 전달되더라도 aws 파티션에 대한 모든 API 호출은 이름의 고유성을 보장하기 위해 파티션에서 이를 기반으로 합니다. 마지막으로, 중요한 버킷 생성 워크플로가 있는 경우 버킷 이름의 특정 철자, 특히 식별 가능한 패턴을 따르는 버킷 이름의 사용 가능 여부에 의존해서는 안 됩니다.

    권장 사항

    복구 경로의 일부로 S3 버킷을 삭제 또는 새로 만들거나 S3 버킷 구성을 업데이트하는 데 의존하지 마십시오. 필요한 모든 S3 버킷을 필요한 구성으로 사전 프로비저닝하여 장애를 복구하기 위해 변경할 필요가 없도록 하십시오. 이 접근 방식은 MRAPs 에도 적용됩니다.

  • CloudFront

    Amazon API Gateway는 엣지에 최적화된 API 엔드포인트를 제공합니다. 이러한 엔드포인트 생성은 게이트웨이 엔드포인트 앞에 us-east-1 배포를 생성하는 CloudFront 컨트롤 플레인에 따라 달라집니다.

    권장 사항

    복구 경로의 일부로 엣지에 최적화된 API 게이트웨이 엔드포인트를 새로 생성하는 것에 의존하지 마십시오. 필요한 모든 게이트웨이 엔드포인트를 사전 프로비저닝하십시오. API

    이 섹션에서 설명하는 모든 종속성은 데이터 플레인 작업이 아니라 컨트롤 플레인 작업입니다. 워크로드가 정적으로 안정되도록 구성된 경우 이러한 종속성이 복구 경로에 영향을 주지 않아야 합니다. 정적 안정성을 구현하려면 추가 작업이나 서비스가 필요하다는 점을 염두에 두세요.

기본 글로벌 엔드포인트를 사용하는 서비스

일부 경우에는 AWS 서비스가 AWS 보안 토큰 서비스 (AWS STS) 와 같은 기본 글로벌 엔드포인트를 제공합니다. 다른 서비스는 이 기본 글로벌 엔드포인트를 기본 구성으로 사용할 수 있습니다. 즉, 사용 중인 지역 서비스가 단일 AWS 리전지역에 대한 글로벌 종속성을 가질 수 있습니다. 다음 세부 정보는 기본 글로벌 엔드포인트에서 의도하지 않은 종속성을 제거하여 지역적 방식으로 서비스를 사용하는 데 도움이 되는 방법을 설명합니다.

AWS STS: STS 는 IAM 사용자 또는 인증한 사용자 (페더레이션 사용자) 를 위해 권한이 제한된 임시 자격 증명을 요청할 수 있는 웹 서비스입니다. STS AWS 소프트웨어 개발 키트 (SDK) 및 명령줄 인터페이스 () 에서의 사용 기본값은 입니다. CLI us-east-1 이 STS 서비스는 지역별 엔드포인트도 제공합니다. 이러한 엔드포인트는 기본적으로 활성화되며, 지역에서도 기본적으로 활성화됩니다. AWS STS지역화된 엔드포인트를 SDK 구성하거나 CLI 다음 지침에 따라 언제든지 이러한 이점을 활용할 수 있습니다. 또한 SigV4A를 사용하려면 지역 엔드포인트에서 요청한 임시 자격 증명이 필요합니다. STS 이 작업에는 글로벌 STS 엔드포인트를 사용할 수 없습니다.

권장 사항

지역 STS 엔드포인트를 사용하도록 SDK 및 CLI 구성을 업데이트하십시오.

보안 어설션 마크업 언어 (SAML) 로그인: SAML 서비스는 어디에나 존재합니다. AWS 리전이 서비스를 사용하려면 적절한 지역 SAML 엔드포인트 (예: https://us-west-2.signin.aws.amazon.com/saml) 를 선택하십시오. 지역 엔드포인트를 사용하려면 신뢰 정책 및 ID 공급자 (IdP) 의 구성을 업데이트해야 합니다. 자세한 내용은 AWS SAML설명서를 참조하십시오.

호스팅되는 IdP를 사용하는 경우 장애 이벤트 중에 IdP가 영향을 받을 위험이 있습니다. AWS AWS 이로 인해 IdP 구성을 업데이트할 수 없거나 완전히 페더레이션하지 못할 수 있습니다. IdP가 손상되거나 사용할 수 없는 경우에 대비하여 “브레이크글라스” 사용자를 사전 프로비저닝해야 합니다. 정적으로 안정적인 방식으로 Break-Glass 사용자를 생성하는 방법에 부록 A - 부분 서비스 지침 대한 자세한 내용은 를 참조하십시오.

권장 사항

여러 지역의 로그인을 IAM 허용하도록 역할 신뢰 정책을 업데이트하세요. SAML 장애가 발생한 경우 선호 엔드포인트가 손상된 경우 다른 지역 SAML 엔드포인트를 사용하도록 IdP 구성을 업데이트하십시오. IdP가 손상되었거나 사용할 수 없는 경우에 대비하여 브레이크-글래스 사용자를 생성하세요.

AWS IAMIdentity Center: Identity Center는 고객 및 클라우드 애플리케이션에 대한 Single Sign-On 액세스를 중앙에서 쉽게 관리할 수 있는 클라우드 기반 서비스입니다. AWS 계정 Identity Center는 선택한 단일 지역에 배포해야 합니다. 하지만 서비스의 기본 동작은 에서 호스팅되는 글로벌 SAML 엔드포인트 (https://signin.aws.amazon.com/saml) 를 사용하는 us-east-1 것입니다. Identity Center를 다른 AWS 리전곳에 배포한 경우 Identity Center 배포와 동일한 지역 콘솔 엔드포인트를 대상으로 하도록 모든 권한 세트의 릴레이 상태를 URL 업데이트해야 합니다. 예를 들어 Identity Center를 에 us-west-2 배포한 경우 https://us-west-2.console.aws.amazon.com 을 사용하도록 권한 집합의 릴레이 상태를 업데이트해야 합니다. 이렇게 하면 Identity Center 배포에 대한 us-east-1 종속성이 모두 제거됩니다.

또한 IAM Identity Center는 단일 지역에만 배포할 수 있으므로 배포에 장애가 발생할 경우를 대비하여 “브레이크글라스” 사용자를 미리 프로비전해야 합니다. 정적으로 안정적인 방식으로 Break-Glass 사용자를 생성하는 방법에 부록 A - 부분 서비스 지침 대한 자세한 내용은 를 참조하십시오.

권장 사항

서비스가 배포된 지역과 일치하도록 IAM Identity Center에서 권한 URL 집합의 릴레이 상태를 설정하십시오. IAMIdentity Center 배포를 사용할 수 없는 경우를 대비하여 유용한 사용자를 생성하십시오.

Amazon S3 스토리지 렌즈: 스토리지 렌즈는 라는 기본 대시보드를 제공합니다 default-account-dashboard. 대시보드 구성 및 관련 지표는 에 저장됩니다us-east-1. 대시보드 구성 및 지표 데이터의 홈 지역을 지정하여 다른 지역에 추가 대시보드를 생성할 수 있습니다.

권장 사항

의 서비스에 영향을 미치는 장애 발생 중에 기본 S3 Storage Lens 대시보드의 데이터가 필요한 경우 대체 홈 지역에 us-east-1 추가 대시보드를 생성하십시오. 추가 지역에서 생성한 다른 사용자 지정 대시보드를 복제할 수도 있습니다.

글로벌 서비스 요약

글로벌 서비스를 위한 데이터 플레인은 지역 AWS 서비스와 유사한 격리 및 독립 원칙을 적용합니다. 한 지역의 데이터 플레인에 영향을 미치는 장애가 다른 AWS 리전지역의 IAM 데이터 플레인 작동에는 영향을 미치지 않습니다. IAM 마찬가지로 PoP에서 Route 53의 데이터 플레인에 영향을 미치는 장애는 나머지 Route 53 데이터 플레인의 작동에는 영향을 미치지 않습니다. PoPs 따라서 컨트롤 플레인이 운영되는 지역 또는 컨트롤 플레인 자체에 영향을 미치는 서비스 가용성 이벤트를 고려해야 합니다. 각 글로벌 서비스에는 컨트롤 플레인이 하나뿐이므로 해당 컨트롤 플레인에 영향을 미치는 장애가 발생할 경우 CRUDL -type 작업 (서비스를 직접 사용하는 대신 서비스를 설정하거나 구성하는 데 일반적으로 사용되는 구성 작업) 에 지역 간 영향을 미칠 수 있습니다.

글로벌 서비스를 탄력적으로 사용하도록 워크로드를 설계하는 가장 효과적인 방법은 정적 안정성을 사용하는 것입니다. 장애 시나리오에서는 영향을 완화하거나 다른 위치로의 장애 조치를 취하기 위해 컨트롤 플레인을 사용하여 변경할 필요가 없도록 워크로드를 설계하십시오. 컨트롤 플레인 종속성을 제거하고 단일 장애 지점을 제거하기 위해 이러한 유형의 글로벌 서비스를 활용하는 방법에 대한 규범적 지침은 및 을 참조하십시오. 부록 A - 부분 서비스 지침 부록 B - 에지 네트워크 글로벌 서비스 지침 복구를 위해 컨트롤 플레인 작업의 데이터가 필요한 경우 AWS Systems Manager Parameter Store (SSMParameter Store) 파라미터, DynamoDB 테이블 또는 S3 버킷과 같은 데이터 플레인을 통해 액세스할 수 있는 데이터 스토어에 이 데이터를 캐시하십시오. 중복성을 위해 해당 데이터를 추가 지역에 저장하도록 선택할 수도 있습니다. 예를 들어, Route 53 애플리케이션 복구 컨트롤러 (ARC) 의 모범 사례에 따라 5개의 지역 클러스터 엔드포인트를 하드코딩하거나 북마크해야 합니다. 장애 이벤트 중에는 매우 안정적인 데이터 플레인 클러스터에서 호스팅되지 않는 Route 53 ARC API 작업을 비롯한 일부 API 작업에 액세스하지 못할 수 있습니다. DescribeClusterAPI작업을 사용하여 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 - 부분 서비스 지침 대한 자세한 내용은 을 참조하십시오.

복구 경로에서 에지 네트워크 서비스의 컨트롤 플레인에 의존하지 마십시오. 대신 이러한 서비스의 데이터 플레인 운영에 의존하십시오. 에지 네트워크에서 글로벌 서비스를 설계하는 방법에 부록 B - 에지 네트워크 글로벌 서비스 지침 대한 자세한 내용은 을 참조하십시오.

복구 경로에서 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 홈 지역에 추가 대시보드를 생성하십시오. 추가 지역에서 생성한 다른 사용자 지정 대시보드를 복제할 수도 있습니다.