https://jumisa.iohttps://assets.zumisa.dev/wp-content/uploads/2024/02/S3Replication-high.mp4
Table of Contents
Why Use Replication across AWS S3 bucket?
Replication between S3 buckets enables automatic copying of the objects as they are written into the bucket. Replication helps us achieve the following:
Prerequisites For Replication
To Replicate objects across S3 buckets, the following are required:
Replication Types
Multiple types of replications can be used based on the business requirements.
The objects from one S3 bucket can be replicated into another S3 bucket in the same region within the same or different account.
The objects from one S3 bucket can be replicated into another S3 bucket in a different region within the same or a different account.
When there are two buckets A and B, the objects written in either bucket can be replicated into the other bucket.
All the replication methods mentioned above can replicate the objects instantly with or without any filters.
Batch replication is an on-demand job that can be used when only a particular set of objects can be replicated. For example, only the previously failed objects are to be replicated at a given time.
Setting Up Replication
Let us learn about S3 replication with an example of same-region replication within the same account.
Source Bucket





Destination Bucket
The destination bucket is also created with a similar configuration as the source bucket. Only the name differs. Now we have our source and destination buckets ready.

Replication Rule




,
]



In addition to the above configurations, there are a few more optional configurations that can be used to alter the properties of the replicated objects.
Replication Time Control replicates 99.99% of new objects within 15 minutes and includes replication metrics.
With Replication Metrics, you can monitor the total number and size of objects that are pending replication and the maximum replication time to the destination Region. You can also view and diagnose replication failures.
Delete Markers created by S3 delete operations will be replicated. Delete markers created by lifecycle rules are not replicated.
The Replica Modification Sync option is used to replicate metadata changes made to replicas from the destination bucket to the source bucket.
In our case, we are currently not using any of these options and leaving the default configuration untouched.

If there are any objects available in the S3 bucket before creating the replication rule, we can choose to run a one-time Batch Operations job from this replication configuration to replicate those objects to synchronize the source and destination buckets.

If we choose to replicate the existing objects, we will be redirected to the Create Batch Operations job widget.
The batch jobs can be configured to run automatically when it is created, or we can trigger it manually.
We can also generate a completion report and store it in a location to see if the replication works seamlessly or not. If the replication is failing this report will have a detailed log with which we can identify the error and fix it.
We can store this report in either of our existing buckets (source or destination) or a new bucket can be created to store the report. Since this job will be run only once just to verify the replication configuration, we need not create a separate bucket for the completion report. If the report is stored in the source bucket, then it will also be replicated to the destination bucket. To avoid this, we can choose the destination bucket as the path to store the completion report.
To add permissions for this job, we use the same IAM policy s3replicate_for_jumisa-source-bucket_c3e5eb. The JSON of the policy will be as follows:
,
]

The status of the Batch operation can be monitored as shown below.

Once the job is completed, we can see the objects from the source bucket replicated into the destination bucket.

Along with the replicated object, we can also see the completion report of the batch operation job in the destination bucket.
This report includes the manifest.json files and the actual report in a CSV file as shown below.

The manifest.json file contains the details of the job report such as the report format, report creation time, job status, bucket name, and path where the report file is stored in the bucket.
],
"ReportSchema": "Bucket, Key, VersionId, TaskStatus, ErrorCode, HTTPStatusCode, ResultMessage"

We have discussed here about how a replication between two S3 buckets in the same account and same region.
This is not the limit where the replication can be stopped.
There are a lot more types of replications possible as listed earlier in the article.
We highly appreciate your patience and time spent reading this article.
Stay tuned for more Content.
Happing reading !!! Let us learn together !!!