El inconveniente cuando hay replicación proviene de la nota a continuación:
Amazon S3 enruta cualquier solicitud de estilo alojado virtual a la región Este de EE. UU. (N. Virginia) de forma predeterminada si usa el punto final Este de EE. UU. (N. Virginia) (s3.amazonaws.com), en lugar del punto final específico de la región (para ejemplo, s3-eu-west-1.amazonaws.com).
Cuando usa la replicación, generalmente deja que AWS se encargue de enrutar el alias a una región al enfocar s3.amazonaws.comsu solicitud REST desde sus servidores y dejar que la redirección haga su trabajo.
Cada vez que N.Virginia está inactivo, la magia deja de funcionar y no tienes suerte para acceder a tus datos y tienes que actualizar tu configuración para elegir un punto final de la región específica.
El problema no proviene del DNS (una solicitud al bucket en sí funcionará) sino de los clientes S3, que se conectarán al punto final de la API S3 antes de acceder al bucket, en este caso la resolución dns se realiza s3.amazonaws.comy esta es nuestra punto final este-1.
Cuando usa el alias de regiones, pierde la facilidad del equilibrio de carga en las regiones con el control de estado de AWS incluido.
Si usa DNS cname dirigido a las regiones para cambiar rápidamente, usted es responsable de su DNS TTL, pero nada garantiza que los servidores de caché del ISP del cliente respeten su valor (uno de los muchos caché que su cliente puede encontrar).
Y, por último, si intenta equilibrar la carga usted mismo, probablemente creará el mismo SPOF que AWS ya tiene con la carga adicional de mantenerlo.
AWS está trabajando en ello, pero esa es toda la información que tengo al momento de escribir.