<p>Many big companies would be at fault for not using this feature. It does add additional cost, and historically any kind of <em>real</em> disaster recovery solution is untested even if implemented.</p>

<p>Other than the cost issue, companies who are actively using cross-region replication can offer a valid concern regarding the latency it takes for an object to replicate. S3 does not allow (as far as I know) read-after-write consistency on replicated objects, while it does allow it for a bucket in a single region.</p>

<p>This <a href="https://stackoverflow.com/questions/23786609/what-is-maximum-amazon-s3-replication-time-on-file-upload">SE question</a> raises a concern where objects are not being replicated properly, or take too long to replicate. Provided that cross-region replication is done in a mode of eventual consistency, there are a lot of concerns to address.</p>

CC BY-SA 3.0
2017-03-01T04:19:13.020Z
I would put further emphasis on the fact that S3 cross-region replication offers *eventual consistency* for some operations. That is *not* trivial to take into account. Depending on the application, it might be downright unacceptable. In any case, it is not fool-proof (can lead to bigger issues if someone assumes it's magic)
Alexandre
CC BY-SA 3.0
2017-03-01T04:11:49.233Z
2017-03-01T04:23:04.940Z
2017-05-23T12:39:34.013Z
Evgeny Zislis
<p>The drawback when there's replication come from the note below:</p>

<blockquote>
  <p>Amazon S3 routes any virtual hosted–style requests to the US East
  (N. Virginia) region by default if you use the US East (N. Virginia)
  endpoint (s3.amazonaws.com), instead of the region-specific endpoint
  (for example, s3-eu-west-1.amazonaws.com).</p>
</blockquote>

<p>When you use replication you usualy let AWS takes care of routing the alias to one region by targetting <code>s3.amazonaws.com</code> in your REST request from your servers and let the redirect do it's job.  </p>

<p>Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data and have to update your configuration to choose a specific region endpoint.</p>

<p>The problem does <em>not</em> come from the DNS (a request to the bucket itself will work) but from S3 clients, which will connect to the S3 API endpoint before accessing the bucket, in this case the dns resolution is done on <code>s3.amazonaws.com</code> and this is us-east-1 endpoint. </p>

<p>When you use regions alias, you loose the ease of load balancing over regions with the health check from AWS included.  </p>

<p>If you use DNS cname targeting the regions to switch quickly, you're responsible of your DNS TTL but nothing guarantee cache servers of client ISP will honor your value (one of many cache your client may encounter).  </p>

<p>And lastly, if you try to load balance yourself you'll probably create the same SPOF than AWS already have with the added burden of maintaining it.  </p>

<p>AWS is working on it but that's all the information I have at time of writing. </p>

CC BY-SA 3.0
2017-03-01T11:07:58.487Z
According to http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html it is possible to use 'bucketname.s3-eu-west-1.amazonaws.com' (substitute your favourite region) as a DNS alias. IFF that works, it can be a way to quickly switch (as quick as your pre-set TTL allows)
Michael Bravo
CC BY-SA 3.0
2017-03-01T12:31:37.253Z
@MichaelBravo extended the answer to address your concern :)
Tensibai
CC BY-SA 3.0
2017-03-02T12:21:10.067Z
*"Even if in theory you could use CNAME to region endpoints, the authoritative answer rely on the service in N.Virginia as far as I know and I've read about it"*  You're taking the quote about routing to the US East region by default out of context. Before the `example-bucket` bucket exists, `example-bucket.s3.amazonaws.com` already points to US East in DNS.  Within a few minutes of initial bucket creation, this permanently changes to point to the correct regional endpoint. The warning here is that this hostname may initially be briefly misrouted immediately after bucket creation -- not later.
Michael - sqlbot
CC BY-SA 3.0
2017-03-02T12:25:40.433Z
...so *"Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data in any region by the DNS alias method"* is therefore incorrect.  Buckets in other regions were not impacted by the us-east-1 outage, including those referenced using this style of hostname.
Michael - sqlbot
CC BY-SA 3.0
2017-03-02T12:29:07.630Z
No, you don't.  They change the DNS entry for your bucket in the `s3.amazonaws.com` zone within a few minutes of bucket creation, and this change persists independently of us-east-1.  Create a bucket in another region and watch how `your-bucket-name.s3.amazonaws.com` resolves before, during, and a few minutes after bucket creation.  The information is pushed to the `s3-1.amazonaws.com` zone in Route 53 after bucket creation and persists there, without further reliance on us-east-1.
Michael - sqlbot
CC BY-SA 3.0
2017-03-02T12:42:35.370Z
@Michael-sqlbot I see where the confusion comes from, indeed the quote may not be the better back up for the position. I'll try to find another one and edit.
Tensibai
CC BY-SA 3.0
2017-03-02T14:34:52.647Z
@Michael-sqlbot I've reworded the answer and cleaned up the comments. Indeed it was misleading focusing on the DNS part where it's the API endpoint the root cause.
Tensibai
CC BY-SA 3.0
2017-03-01T10:40:44.937Z
2017-03-02T14:33:10.920Z
2017-03-02T14:33:10.920Z
Tensibai
<p>Amazon S3 has an option of cross-region replication which should be pretty fault-tolerant against region/zone outages.</p>

<p>Does that mean those who are ranting about the outage did not make use of this aspect?</p>

<p>Or is that cross-region replication is not completely fool-proof and would not have helped?</p>

CC BY-SA 3.0
2017-03-01T04:04:10.363Z
related: http://devops.stackexchange.com/questions/83/what-is-a-good-strategy-to-keep-my-site-online-when-s3-goes-offline
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T04:09:23.820Z
@Evgeny Thank you.  I was reading that same post, before asking this :)
Dawny33
<amazon-s3><high-availability>
Is cross-region replication 100% fool-proof for S3 region outages?
Dawny33
# Is cross-region replication 100% fool-proof for S3 region outages?

(Asked by: username_0 on 2017-03-01)

Amazon S3 has an option of cross-region replication which should be pretty fault-tolerant against region/zone outages.

Does that mean those who are ranting about the outage did not make use of this aspect?

Or is that cross-region replication is not completely fool-proof and would not have helped?

**Tags:** amazon-s3, high-availability

> **Comments:**
> **username_1**: related: http://devops.stackexchange.com/questions/83/what-is-a-good-strategy-to-keep-my-site-online-when-s3-goes-offline  
> **username_0**: @Evgeny Thank you.  I was reading that same post, before asking this :)  

---

## 2 answers

### Answer by username_3 on 2017-03-01. Score: 11 | Accepted answer

The drawback when there's replication come from the note below:

> Amazon S3 routes any virtual hosted–style requests to the US East
> (N. Virginia) region by default if you use the US East (N. Virginia)
> endpoint (s3.amazonaws.com), instead of the region-specific endpoint
> (for example, s3-eu-west-1.amazonaws.com).

When you use replication you usualy let AWS takes care of routing the alias to one region by targetting `s3.amazonaws.com` in your REST request from your servers and let the redirect do it's job.

Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data and have to update your configuration to choose a specific region endpoint.

The problem does *not* come from the DNS (a request to the bucket itself will work) but from S3 clients, which will connect to the S3 API endpoint before accessing the bucket, in this case the dns resolution is done on `s3.amazonaws.com` and this is us-east-1 endpoint.

When you use regions alias, you loose the ease of load balancing over regions with the health check from AWS included.

If you use DNS cname targeting the regions to switch quickly, you're responsible of your DNS TTL but nothing guarantee cache servers of client ISP will honor your value (one of many cache your client may encounter).

And lastly, if you try to load balance yourself you'll probably create the same SPOF than AWS already have with the added burden of maintaining it.

AWS is working on it but that's all the information I have at time of writing.

> **Comments:**
> **username_4**: According to http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html it is possible to use 'bucketname.s3-eu-west-1.amazonaws.com' (substitute your favourite region) as a DNS alias. IFF that works, it can be a way to quickly switch (as quick as your pre-set TTL allows)  
> **username_3**: @MichaelBravo extended the answer to address your concern :)  
> **username_5**: *"Even if in theory you could use CNAME to region endpoints, the authoritative answer rely on the service in N.Virginia as far as I know and I've read about it"*  You're taking the quote about routing to the US East region by default out of context. Before the `example-bucket` bucket exists, `example-bucket.s3.amazonaws.com` already points to US East in DNS.  Within a few minutes of initial bucket creation, this permanently changes to point to the correct regional endpoint. The warning here is that this hostname may initially be briefly misrouted immediately after bucket creation -- not later.  
> **username_5**: ...so *"Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data in any region by the DNS alias method"* is therefore incorrect.  Buckets in other regions were not impacted by the us-east-1 outage, including those referenced using this style of hostname.  
> **username_5**: No, you don't.  They change the DNS entry for your bucket in the `s3.amazonaws.com` zone within a few minutes of bucket creation, and this change persists independently of us-east-1.  Create a bucket in another region and watch how `your-bucket-name.s3.amazonaws.com` resolves before, during, and a few minutes after bucket creation.  The information is pushed to the `s3-1.amazonaws.com` zone in Route 53 after bucket creation and persists there, without further reliance on us-east-1.  
> **username_3**: @Michael-sqlbot I see where the confusion comes from, indeed the quote may not be the better back up for the position. I'll try to find another one and edit.  
> **username_3**: @Michael-sqlbot I've reworded the answer and cleaned up the comments. Indeed it was misleading focusing on the DNS part where it's the API endpoint the root cause.  

---

### Answer by username_1 on 2017-03-01. Score: 10

Many big companies would be at fault for not using this feature. It does add additional cost, and historically any kind of *real* disaster recovery solution is untested even if implemented.

Other than the cost issue, companies who are actively using cross-region replication can offer a valid concern regarding the latency it takes for an object to replicate. S3 does not allow (as far as I know) read-after-write consistency on replicated objects, while it does allow it for a bucket in a single region.

This [SE question](https://stackoverflow.com/questions/23786609/what-is-maximum-amazon-s3-replication-time-on-file-upload) raises a concern where objects are not being replicated properly, or take too long to replicate. Provided that cross-region replication is done in a mode of eventual consistency, there are a lot of concerns to address.

> **Comments:**
> **username_2**: I would put further emphasis on the fact that S3 cross-region replication offers *eventual consistency* for some operations. That is *not* trivial to take into account. Depending on the application, it might be downright unacceptable. In any case, it is not fool-proof (can lead to bigger issues if someone assumes it's magic)  

---

