diff --git a/website/source/docs/faq.html.md b/website/source/docs/faq.html.md
index 1a4fc69b6..5411f098f 100644
--- a/website/source/docs/faq.html.md
+++ b/website/source/docs/faq.html.md
@@ -115,3 +115,14 @@ HTTP 413 status will be returned to any client that attempts to store more
than that limit in a value. It should be noted that the Consul key/value store
is not designed to be used as a general purpose database. See
[Server Performance](/docs/guides/performance.html) for more details.
+
+## Q: What data is replicated between Consul datacenters?
+
+In general, data is not replicated between different Consul datacenters. When a
+request is made for a resource in another datacenter, the local Consul servers forward
+an RPC request to the remote Consul servers for that resource and return the results.
+If the remote datacenter is not available, then those resources will also not be
+available, but that won't otherwise affect the local datacenter. There are some special
+situations where a limited subset of data can be replicated, such as with Consul's built-in
+[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or
+external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate).
diff --git a/website/source/docs/guides/areas.html.markdown.erb b/website/source/docs/guides/areas.html.markdown.erb
index a10574495..7a30b3737 100644
--- a/website/source/docs/guides/areas.html.markdown.erb
+++ b/website/source/docs/guides/areas.html.markdown.erb
@@ -21,6 +21,15 @@ failure of any datacenter does not impact the availability of Consul in other
datacenters. This means each datacenter runs independently, each having a dedicated
group of servers and a private LAN [gossip pool](/docs/internals/gossip.html).
+In general, data is not replicated between different Consul datacenters. When a
+request is made for a resource in another datacenter, the local Consul servers forward
+an RPC request to the remote Consul servers for that resource and return the results.
+If the remote datacenter is not available, then those resources will also not be
+available, but that won't otherwise affect the local datacenter. There are some special
+situations where a limited subset of data can be replicated, such as with Consul's built-in
+[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or
+external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate).
+
This guide covers the advanced form of federating Consul clusters using the new
network areas capability added in [Consul Enterprise](https://www.hashicorp.com/products/consul/)
version 0.8.0. For the basic form of federation available in the open source version
diff --git a/website/source/docs/guides/datacenters.html.md b/website/source/docs/guides/datacenters.html.md
index daf442e3e..66aaf0e7a 100644
--- a/website/source/docs/guides/datacenters.html.md
+++ b/website/source/docs/guides/datacenters.html.md
@@ -16,6 +16,15 @@ failure of any datacenter does not impact the availability of Consul in other
datacenters. This means each datacenter runs independently, each having a dedicated
group of servers and a private LAN [gossip pool](/docs/internals/gossip.html).
+In general, data is not replicated between different Consul datacenters. When a
+request is made for a resource in another datacenter, the local Consul servers forward
+an RPC request to the remote Consul servers for that resource and return the results.
+If the remote datacenter is not available, then those resources will also not be
+available, but that won't otherwise affect the local datacenter. There are some special
+situations where a limited subset of data can be replicated, such as with Consul's built-in
+[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or
+external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate).
+
This guide covers the basic form of federating Consul clusters using a single
WAN gossip pool, interconnecting all Consul servers.
[Consul Enterprise](https://www.hashicorp.com/products/consul/) version 0.8.0 added support
diff --git a/website/source/docs/internals/architecture.html.md b/website/source/docs/internals/architecture.html.md
index 35240872e..21fcbfbc2 100644
--- a/website/source/docs/internals/architecture.html.md
+++ b/website/source/docs/internals/architecture.html.md
@@ -114,6 +114,15 @@ server in the correct datacenter. That server may then forward to the local lead
This results in a very low coupling between datacenters, but because of failure detection,
connection caching and multiplexing, cross-datacenter requests are relatively fast and reliable.
+In general, data is not replicated between different Consul datacenters. When a
+request is made for a resource in another datacenter, the local Consul servers forward
+an RPC request to the remote Consul servers for that resource and return the results.
+If the remote datacenter is not available, then those resources will also not be
+available, but that won't otherwise affect the local datacenter. There are some special
+situations where a limited subset of data can be replicated, such as with Consul's built-in
+[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or
+external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate).
+
## Getting in depth
At this point we've covered the high level architecture of Consul, but there are many