답변:
복제가있을 때의 단점은 아래 참고에서 비롯됩니다.
리전 별 엔드 포인트 대신에 예 : s3-eu-west-1.amazonaws.com).
복제를 사용하는 경우 일반적으로 AWS는 s3.amazonaws.com서버의 REST 요청을 대상 으로하여 별칭을 한 리전으로 라우팅 하고 리디렉션을 수행하도록합니다.
N.Virginia가 다운 될 때마다 마법이 작동을 멈추고 데이터에 액세스 할 수없고 특정 지역 엔드 포인트를 선택하도록 구성을 업데이트해야합니다.
문제는 DNS에서 발생하지 않으며 (버킷 자체에 대한 요청은 작동하지만) 버킷에 액세스하기 전에 S3 API 엔드 포인트에 연결하는 S3 클라이언트에서 발생합니다.이 경우 DNS 해상도가 해결 s3.amazonaws.com되었으며 이는 우리입니다. 동쪽 -1 끝점.
리전 별칭을 사용하면 AWS의 상태 확인 기능을 통해 리전별로로드 밸런싱이 쉬워집니다.
리전을 대상으로하는 DNS cname을 사용하여 신속하게 전환하는 경우, DNS TTL은 사용자의 책임이지만 클라이언트 ISP의 캐시 서버가 귀하의 가치를 존중한다는 보장은 없습니다 (클라이언트에서 발생할 수있는 많은 캐시 중 하나).
마지막으로, 스스로로드 밸런싱을 시도하면 AWS와 동일한 SPOF를 생성하여 유지 관리 부담이 추가 될 수 있습니다.
AWS가 노력하고 있지만 이것이 필자가 작성한 모든 정보입니다.
example-bucket버킷이 존재 하기 전에 example-bucket.s3.amazonaws.com이미 DNS에서 미국 동부를 가리 킵니다. 초기 버킷 생성 후 몇 분 내에 올바른 지역 엔드 포인트를 가리 키도록 영구적으로 변경됩니다. 여기서 경고는이 호스트 이름이 버킷 생성 직후에 잠시 후에 잘못 잘못 라우팅 될 수 있다는 것입니다.
s3.amazonaws.com버킷 생성 후 몇 분 내에 영역 의 버킷에 대한 DNS 항목 이 변경되며이 변경 사항은 us-east-1과 독립적으로 유지됩니다. 다른 리전에서 버킷을 생성하고 버킷 생성 your-bucket-name.s3.amazonaws.com전, 중 및 몇 분 후에 어떻게 해결되는지 확인하십시오. s3-1.amazonaws.com버킷 생성 후 Route 53 의 영역으로 정보가 푸시되어 us-east-1에 더 이상 의존하지 않고 존속됩니다.
많은 대기업들은이 기능을 사용하지 않아 잘못 될 것입니다. 추가 비용이 발생하며, 실제로 구현 된 경우에도 모든 종류의 실제 재해 복구 솔루션은 테스트되지 않았습니다.
비용 문제 이외의 영역 간 복제를 적극적으로 사용하는 회사는 개체 복제에 걸리는 대기 시간과 관련하여 유효한 우려를 제시 할 수 있습니다. S3는 복제 된 객체에 대해 쓰기 후 읽기 일관성을 허용하지 않지만 (단일 리전의 버킷에 대해서는) 허용합니다.
이 SE 질문 은 객체가 제대로 복제되지 않거나 복제하는 데 시간이 너무 오래 걸리는 문제를 제기합니다. 교차 리전 복제가 최종 일관성 모드에서 수행되는 경우 해결해야 할 사항이 많이 있습니다.