回答:
複製がある場合の欠点は、以下の注意にあります。
リージョン固有のエンドポイント（for例：s3-eu-west-1.amazonaws.com）。
レプリケーションを使用する場合、AWSは通常s3.amazonaws.com、サーバーからのRESTリクエストでターゲットを設定することでエイリアスを1つのリージョンにルーティングし、リダイレクトに任せるようにします。
N.Virginiaがダウンすると、マジックが機能しなくなり、データにアクセスできず、設定を更新して特定のリージョンエンドポイントを選択する必要があります。
問題はDNSからではなく（バケットへのリクエスト自体が機能します）、S3クライアントから発生します。S3クライアントはバケットにアクセスする前にS3 APIエンドポイントに接続します。この場合、dns解決が行われs3.amazonaws.com、これはus- east-1エンドポイント。
リージョンエイリアスを使用すると、AWSからのヘルスチェックが含まれているため、リージョン間の負荷分散の容易さが失われます。
リージョンをターゲットにしたDNS cnameを使用してすばやく切り替える場合、DNS TTLの責任がありますが、クライアントISPのキャッシュサーバーが値を保証する保証はありません（クライアントが遭遇する可能性のある多くのキャッシュの1つ）。
そして最後に、自分で負荷分散を行おうとすると、おそらく、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の質問は、オブジェクトが適切にレプリケートされていない、またはレプリケートに時間がかかりすぎるという懸念を生じさせます。リージョン間レプリケーションが結果整合性のモードで実行される場合、対処すべき多くの懸念事項があります。