S3 file replication might not be the solution to all of your troubles

S3 file replication is a really good function in theory. First, it enables versioning (which is a requirement for file replication to work). Second, the replication copies any metadata and ACLs (Access Control Lists) associated with the object.

There are a few shortcomings that might make you want to avoid this approach of replicating objects in your buckets. One of the major shortcomings is probably that the replication only works cross-region. This is not a problem if you want to create a geo-redundant stack, but if you only want a backup then replicating cross a region might not be what you really want (for cost and latency reasons). Replication also only works with new or changed objects. You can of course go through your whole bucket and touch every object to create a new version, but that might not be desirable.

But the most major draw-back of S3 bucket replication might just be one of its features: that the replication process also copies any metadata and ACLs. Because what happens if your source accound gets deleted? The target account doesn’t have ownership of the objects and thus, even if you have the whole of your infrastructure as code, you cannot restore your business (as easily as you might have thought it would have been).

For now I suggest using AWS lambda for S3 bucket replication. It is much more flexible (replicate to a bucket in your own region etc) and you can with some work solve the problems with the ownership of the objects - give write access via the ACL to another user who read the object, delete it and overwrite it.

Back to Home