# Data protection in Amazon S3 In addition to the resilience offered by the AWS global infrastructure, Amazon S3 offers a number of features to help protect your data against accidental deletions or Regional failures. **S3 Replication** You can use live replication to enable automatic, asynchronous copying of objects across Amazon S3 buckets. Buckets that are configured for object replication can be owned by the same AWS account or by different accounts. You can replicate objects to a single destination bucket or to multiple destination buckets. The destination buckets can be in different AWS Regions or within the same Region as the source bucket. To enable failover controls, you can configure replication to be two-way (bidirectional) so that your source and destination buckets can be kept in sync during a Regional failure. For more information, see [Replicating objects within and across Regions](replication.md). **Multi-Region Access Points and failover controls** Amazon S3 Multi-Region Access Points provide a global endpoint that applications can use to fulfill requests from S3 buckets that are located in multiple AWS Regions. You can use Multi-Region Access Points to build multi-Region applications with the same architecture that's used in a single Region, and then run those applications anywhere in the world. Instead of sending requests over the congested public internet, Multi-Region Access Points provide built-in network resilience with acceleration of internet-based requests to Amazon S3. Application requests made to a Multi-Region Access Point global endpoint use [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/) to automatically route over the AWS global network to the closest-proximity S3 bucket with an active routing status. For more information about Multi-Region Access Points, see [Managing multi-Region traffic with Multi-Region Access Points](MultiRegionAccessPoints.md). With Amazon S3 Multi-Region Access Point failover controls, you can maintain business continuity during Regional traffic disruptions, while also giving your applications a multi-Region architecture to fulfill compliance and redundancy needs. If your Regional traffic gets disrupted, you can use Multi-Region Access Point failover controls to select which AWS Regions behind an Amazon S3 Multi-Region Access Point will process data-access and storage requests. To support failover, you can set up your Multi-Region Access Point in an active-passive configuration, with traffic flowing to the active Region during normal conditions, and a passive Region on standby for failover. If you have S3 Cross-Region Replication (CRR) enabled with two-way replication rules, you can keep your buckets synchronized during a failover. For more information about failover controls, see [Amazon S3 Multi-Region Access Points failover controls](MrapFailover.md). **S3 Versioning** Versioning is a means of keeping multiple variants of an object in the same bucket. You can use versioning to preserve, retrieve, and restore every version of every object stored in your Amazon S3 bucket. With versioning, you can easily recover from both unintended user actions and application failures. For more information, see [Retaining multiple versions of objects with S3 Versioning](Versioning.md). **S3 Object Lock** You can use S3 Object Lock to store objects using a *write once, read many* (WORM) model. Using S3 Object Lock, you can prevent an object from being deleted or overwritten for a fixed amount of time or indefinitely. S3 Object Lock enables you to meet regulatory requirements that require WORM storage or simply to add an additional layer of protection against object changes and deletion. For more information, see [Locking objects with Object Lock](object-lock.md). **AWS Backup** Amazon S3 is natively integrated with AWS Backup, a fully managed, policy-based service that you can use to centrally define backup policies to protect your data in Amazon S3. After you define your backup policies and assign Amazon S3 resources to the policies, AWS Backup automates the creation of Amazon S3 backups and securely stores the backups in an encrypted backup vault that you designate in your backup plan. For more information, see [Backing up your Amazon S3 data](backup-for-s3.md). For a tutorial on using some of these features together to protect your data, see [Tutorial: Protecting data on Amazon S3 against accidental deletion or application bugs using S3 Versioning, S3 Object Lock, and S3 Replication](https://aws.amazon.com/getting-started/hands-on/protect-data-on-amazon-s3/?ref=docs_gateway/amazons3/DataDurability.html). **Important** In addition to using the preceding features to protect your data, we recommend reviewing the recommendations in [Security best practices for Amazon S3](security-best-practices.md). **Topics** + [Replicating objects within and across Regions](replication.md) + [Managing multi-Region traffic with Multi-Region Access Points](MultiRegionAccessPoints.md) + [Retaining multiple versions of objects with S3 Versioning](Versioning.md) + [Locking objects with Object Lock](object-lock.md) + [Backing up your Amazon S3 data](backup-for-s3.md) # Replicating objects within and across Regions You can use replication to enable automatic, asynchronous copying of objects across Amazon S3 buckets. Buckets that are configured for object replication can be owned by the same AWS account or by different accounts. You can replicate objects to a single destination bucket or to multiple destination buckets. The destination buckets can be in different AWS Regions or within the same Region as the source bucket. There are two types of replication: *live replication* and *on-demand replication*. + **Live replication** – **To automatically replicate new and updated objects** as they are written to the source bucket, use live replication. Live replication doesn't replicate any objects that existed in the bucket before you set up replication. To replicate objects that existed before you set up replication, use on-demand replication. + **On-demand replication** – **To replicate existing objects** from the source bucket to one or more destination buckets on demand, use S3 Batch Replication. For more information about replicating existing objects, see [When to use S3 Batch Replication](#batch-replication-scenario). There are two forms of live replication: *Cross-Region Replication (CRR)* and *Same-Region Replication (SRR)*. + **Cross-Region Replication (CRR)** – You can use CRR to replicate objects across Amazon S3 buckets in different AWS Regions. For more information about CRR, see [When to use Cross-Region Replication](#crr-scenario). + **Same-Region Replication (SRR)** – You can use SRR to copy objects across Amazon S3 buckets in the same AWS Region. For more information about SRR, see [When to use Same-Region Replication](#srr-scenario). **Topics** + [Why use replication?](#replication-scenario) + [When to use Cross-Region Replication](#crr-scenario) + [When to use Same-Region Replication](#srr-scenario) + [When to use two-way replication (bi-directional replication)](#two-way-replication-scenario) + [When to use S3 Batch Replication](#batch-replication-scenario) + [Workload requirements and live replication](#replication-workload-requirements) + [What does Amazon S3 replicate?](replication-what-is-isnot-replicated.md) + [Requirements and considerations for replication](replication-requirements.md) + [Setting up live replication overview](replication-how-setup.md) + [Managing or pausing live replication](disable-replication.md) + [Replicating existing objects with Batch Replication](s3-batch-replication-batch.md) + [Troubleshooting replication](replication-troubleshoot.md) + [Monitoring replication with metrics, event notifications, and statuses](replication-metrics.md) ## Why use replication? Replication can help you do the following: + **Replicate objects while retaining metadata** – You can use replication to make copies of your objects that retain all metadata, such as the original object creation times and version IDs. This capability is important if you must ensure that your replica is identical to the source object. + **Replicate objects into different storage classes** – You can use replication to directly put objects into S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, or another storage class in the destination buckets. You can also replicate your data to the same storage class and use lifecycle configurations on the destination buckets to move your objects to a colder storage class as they age. + **Maintain object copies under different ownership** – Regardless of who owns the source object, you can tell Amazon S3 to change replica ownership to the AWS account that owns the destination bucket. This is referred to as the *owner override* option. You can use this option to restrict access to object replicas. + **Keep objects stored over multiple AWS Regions** – To ensure geographic differences in where your data is kept, you can set multiple destination buckets across different AWS Regions. This feature might help you meet certain compliance requirements. + **Replicate objects within 15 minutes** – To replicate your data in the same AWS Region or across different Regions within a predictable time frame, you can use S3 Replication Time Control (S3 RTC). S3 RTC replicates 99.99 percent of new objects stored in Amazon S3 within 15 minutes (backed by a service-level agreement). For more information, see [Meeting compliance requirements with S3 Replication Time Control](replication-time-control.md). **Note** S3 RTC does not apply to Batch Replication. Batch Replication is an on-demand replication job, and can be tracked with S3 Batch Operations. For more information, see [Tracking job status and completion reports](batch-ops-job-status.md). + **Sync buckets, replicate existing objects, and replicate previously failed or replicated objects** – To sync buckets and replicate existing objects, use Batch Replication as an on-demand replication action. For more information about when to use Batch Replication, see [When to use S3 Batch Replication](#batch-replication-scenario). + **Replicate objects and fail over to a bucket in another AWS Region** – To keep all metadata and objects in sync across buckets during data replication, use two-way replication (also known as bi-directional replication) rules before configuring Amazon S3 Multi-Region Access Point failover controls. Two-way replication rules help ensure that when data is written to the S3 bucket that traffic fails over to, that data is then replicated back to the source bucket. ## When to use Cross-Region Replication S3 Cross-Region Replication (CRR) is used to copy objects across Amazon S3 buckets in different AWS Regions. CRR can help you do the following: + **Meet compliance requirements** – Although Amazon S3 stores your data across multiple geographically distant Availability Zones by default, compliance requirements might dictate that you store data at even greater distances. To satisfy these requirements, use Cross-Region Replication to replicate data between distant AWS Regions. + **Minimize latency** – If your customers are in two geographic locations, you can minimize latency in accessing objects by maintaining object copies in AWS Regions that are geographically closer to your users. + **Increase operational efficiency** – If you have compute clusters in two different AWS Regions that analyze the same set of objects, you might choose to maintain object copies in those Regions. ## When to use Same-Region Replication Same-Region Replication (SRR) is used to copy objects across Amazon S3 buckets in the same AWS Region. SRR can help you do the following: + **Aggregate logs into a single bucket** – If you store logs in multiple buckets or across multiple accounts, you can easily replicate logs into a single, in-Region bucket. Doing so allows for simpler processing of logs in a single location. + **Configure live replication between production and test accounts** – If you or your customers have production and test accounts that use the same data, you can replicate objects between those multiple accounts, while maintaining object metadata. + **Abide by data sovereignty laws** – You might be required to store multiple copies of your data in separate AWS accounts within a certain Region. Same-Region Replication can help you automatically replicate critical data when compliance regulations don't allow the data to leave your country. ## When to use two-way replication (bi-directional replication) + **Build shared datasets across multiple AWS Regions** – With replica modification sync, you can easily replicate metadata changes, such as object access control lists (ACLs), object tags, or object locks, on replication objects. This two-way replication is important if you want to keep all objects and object metadata changes in sync. You can [enable replica modification sync](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-for-metadata-changes.html#enabling-replication-for-metadata-changes) on a new or existing replication rule when performing two-way replication between two or more buckets in the same or different AWS Regions. + **Keep data synchronized across Regions during failover** – You can synchronize data in buckets between AWS Regions by configuring two-way replication rules with S3 Cross-Region Replication (CRR) directly from a Multi-Region Access Point. To make an informed decision on when to initiate failover, you can also enable S3 replication metrics so that you can monitor the replication in Amazon CloudWatch, in S3 Replication Time Control (S3 RTC), or from the Multi-Region Access Point. + **Make your application highly available** – Even in the event of a Regional traffic disruption, you can use two-way replication rules to keep all metadata and objects in sync across buckets during data replication. ## When to use S3 Batch Replication Batch Replication replicates existing objects to different buckets as an on-demand option. Unlike live replication, these jobs can be run as needed. Batch Replication can help you do the following: + **Replicate existing objects** – You can use Batch Replication to replicate objects that were added to the bucket before Same-Region Replication or Cross-Region Replication were configured. + **Replicate objects that previously failed to replicate** – You can filter a Batch Replication job to attempt to replicate objects with a replication status of **FAILED**. + **Replicate objects that were already replicated** – You might be required to store multiple copies of your data in separate AWS accounts or AWS Regions. Batch Replication can replicate existing objects to newly added destinations. + **Replicate replicas of objects that were created from a replication rule** – Replication configurations create replicas of objects in destination buckets. Replicas of objects can be replicated only with Batch Replication. ## Workload requirements and live replication Depending on your workload requirements, some types of live replication will be better suited to your use case than others. Use the following table to determine which type of replication to use for your situation, and whether to use S3 Replication Time Control (S3 RTC) for your workload. S3 RTC replicates 99.99 percent of new objects stored in Amazon S3 within 15 minutes (backed by a service-level agreement, or SLA). For more information, see [Meeting compliance requirements with S3 Replication Time Control](replication-time-control.md). | Workload requirement | S3 RTC (15-minute SLA) | Cross-Region Replication (CRR) | Same-Region Replication (SRR) | | --- | --- | --- | --- | | Replicate objects between different AWS accounts | Yes | Yes | Yes | | Replicate objects within the same AWS Region within 24-48 hours (not SLA backed) | No | No | Yes | | Replicate objects between different AWS Regions within 24-48 hours (not SLA backed) | No | Yes | No | | Predictable replication time: Backed by SLA to replicate 99.9 percent of objects within 15 minutes | Yes | No | No | # What does Amazon S3 replicate? Amazon S3 replicates only specific items in buckets that are configured for replication. **Topics** + [What is replicated with replication configurations?](#replication-what-is-replicated) + [What isn't replicated with replication configurations?](#replication-what-is-not-replicated) ## What is replicated with replication configurations? By default, Amazon S3 replicates the following: + Objects created after you add a replication configuration. + Unencrypted objects. + Objects encrypted using customer provided keys (SSE-C), objects encrypted at rest under an Amazon S3 managed key (SSE-S3) or a KMS key stored in AWS Key Management Service (SSE-KMS). For more information, see [Replicating encrypted objects (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C)](replication-config-for-kms-objects.md). + Object metadata from the source objects to the replicas. For information about replicating metadata from the replicas to the source objects, see [Replicating metadata changes with replica modification sync](replication-for-metadata-changes.md). + Only objects in the source bucket for which the bucket owner has permissions to read objects and access control lists (ACLs). For more information about resource ownership, see [Amazon S3 bucket and object ownership](access-policy-language-overview.md#about-resource-owner). + Object ACL updates, unless you direct Amazon S3 to change the replica ownership when source and destination buckets aren't owned by the same accounts. For more information, see [Changing the replica owner](replication-change-owner.md). It can take a while until Amazon S3 can bring the two ACLs in sync. This change in ownership applies only to objects created after you add a replication configuration to the bucket. + Object tags, if there are any. + S3 Object Lock retention information, if there is any. When Amazon S3 replicates objects that have retention information applied, it applies those same retention controls to your replicas, overriding the default retention period configured on your destination buckets. If you don't have retention controls applied to the objects in your source bucket, and you replicate into destination buckets that have a default retention period set, the destination bucket's default retention period is applied to your object replicas. For more information, see [Locking objects with Object Lock](object-lock.md). ### How delete operations affect replication If you delete an object from the source bucket, the following actions occur by default: + If you make a DELETE request without specifying an object version ID, Amazon S3 adds a delete marker. Amazon S3 deals with the delete marker as follows: + If you are using the latest version of the replication configuration (that is, you specify the `Filter` element in a replication configuration rule), Amazon S3 does not replicate the delete marker by default. However, you can add *delete marker replication* to non-tag-based rules. For more information, see [Replicating delete markers between buckets](delete-marker-replication.md). + If you don't specify the `Filter` element, Amazon S3 assumes that the replication configuration is version V1, and it replicates delete markers that resulted from user actions. However, if Amazon S3 deletes an object due to a lifecycle action, the delete marker is not replicated to the destination buckets. + If you specify an object version ID to delete in a `DELETE` request, Amazon S3 deletes that object version in the source bucket. But it doesn't replicate the deletion in the destination buckets. In other words, it doesn't delete the same object version from the destination buckets. This protects data from malicious deletions. ## What isn't replicated with replication configurations? By default, Amazon S3 doesn't replicate the following: + Objects in the source bucket that are replicas that were created by another replication rule. For example, suppose you configure replication where bucket A is the source and bucket B is the destination. Now suppose that you add another replication configuration where bucket B is the source and bucket C is the destination. In this case, objects in bucket B that are replicas of objects in bucket A are not replicated to bucket C. To replicate objects that are replicas, use Batch Replication. Learn more about configuring Batch Replication at [Replicating existing objects](s3-batch-replication-batch.md). + Objects in the source bucket that have already been replicated to a different destination. For example, if you change the destination bucket in an existing replication configuration, Amazon S3 won't replicate the objects again. To replicate previously replicated objects, use Batch Replication. Learn more about configuring Batch Replication at [Replicating existing objects](s3-batch-replication-batch.md). + Batch Replication does not support re-replicating objects that were deleted with the version ID of the object from the destination bucket. To re-replicate these objects, you can copy the source objects in place with a Batch Copy job. Copying those objects in place creates new versions of the objects in the source bucket and initiates replication automatically to the destination. For more information about how to use Batch Copy, see, [Examples that use Batch Operations to copy objects](batch-ops-examples-copy.md). + By default, when replicating from a different AWS account, delete markers added to the source bucket are not replicated. For information about how to replicate delete markers, see [Replicating delete markers between buckets](delete-marker-replication.md). + Objects that are stored in the S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, S3 Intelligent-Tiering Archive Access, or S3 Intelligent-Tiering Deep Archive Access storage classes or tiers. You cannot replicate these objects until you restore them and copy them to a different storage class. To learn more about S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive, see [Storage classes for rarely accessed objects](storage-class-intro.md#sc-glacier). To learn more about the S3 Intelligent-Tiering, see [Managing storage costs with Amazon S3 Intelligent-Tiering](intelligent-tiering.md). + Objects in the source bucket that the bucket owner doesn't have sufficient permissions to replicate. For information about how an object owner can grant permissions to a bucket owner, see [Grant cross-account permissions to upload objects while ensuring that the bucket owner has full control](example-bucket-policies.md#example-bucket-policies-acl-2). + Updates to bucket-level subresources. For example, if you change the lifecycle configuration or add a notification configuration to your source bucket, these changes are not applied to the destination bucket. This feature makes it possible to have different configurations on source and destination buckets. + Actions performed by lifecycle configuration. For example, if lifecycle configuration is enabled only on your source bucket, Amazon S3 creates delete markers for expired objects but doesn't replicate those markers. If you want the same lifecycle configuration applied to both the source and destination buckets, enable the same lifecycle configuration on both. For more information about lifecycle configuration, see [Managing the lifecycle of objects](object-lifecycle-mgmt.md). + When you're using tag-based replication rules with live replication, new objects must be tagged with the matching replication rule tag in the `PutObject` operation. Otherwise, the objects won't be replicated. If objects are tagged after the `PutObject` operation, those objects also won't be replicated. To replicate objects that have been tagged after the `PutObject` operation, you must use S3 Batch Replication. For more information about Batch Replication, see [Replicating existing objects](s3-batch-replication-batch.md). # Requirements and considerations for replication Amazon S3 replication requires the following: + The source bucket owner must have the source and destination AWS Regions enabled for their account. The destination bucket owner must have the destination Region enabled for their account. For more information about enabling or disabling an AWS Region, see [Specify which AWS Regions your account can use](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) in the *AWS Account Management Reference Guide*. + Both source and destination buckets must have versioning enabled. For more information about versioning, see [Retaining multiple versions of objects with S3 Versioning](Versioning.md). + Amazon S3 must have permissions to replicate objects from the source bucket to the destination bucket or buckets on your behalf. For more information about these permissions, see [Setting up permissions for live replication](setting-repl-config-perm-overview.md). + If the owner of the source bucket doesn't own the object in the bucket, the object owner must grant the bucket owner `READ` and `READ_ACP` permissions with the object access control list (ACL). For more information, see [Access control list (ACL) overview](acl-overview.md). + If the source bucket has S3 Object Lock enabled, the destination buckets must also have S3 Object Lock enabled. To enable replication on a bucket that has Object Lock enabled, you must use the AWS Command Line Interface, REST API, or AWS SDKs. For more general information, see [Locking objects with Object Lock](object-lock.md). **Note** You must grant two new permissions on the source S3 bucket in the AWS Identity and Access Management (IAM) role that you use to set up replication. The two new permissions are `s3:GetObjectRetention` and `s3:GetObjectLegalHold`. If the role has an `s3:Get*` permission, it satisfies the requirement. For more information, see [Setting up permissions for live replication](setting-repl-config-perm-overview.md). For more information, see [Setting up live replication overview](replication-how-setup.md). If you are setting the replication configuration in a *cross-account scenario*, where the source and destination buckets are owned by different AWS accounts, the following additional requirement applies: + The owner of the destination buckets must grant the owner of the source bucket permissions to replicate objects with a bucket policy. For more information, see [(Optional) Step 3: Granting permissions when the source and destination buckets are owned by different AWS accounts](setting-repl-config-perm-overview.md#setting-repl-config-crossacct). + The destination buckets cannot be configured as Requester Pays buckets. For more information, see [Using Requester Pays general purpose buckets for storage transfers and usage](RequesterPaysBuckets.md). ## Considerations for replication Before you create a replication configuration, be aware of the following considerations. **Topics** + [Lifecycle configuration and object replicas](#replica-and-lifecycle) + [Versioning configuration and replication configuration](#replication-and-versioning) + [Using S3 Replication with S3 Intelligent-Tiering](#replication-and-intelligent-tiering) + [Logging configuration and replication configuration](#replication-and-logging) + [CRR and the destination Region](#replication-and-dest-region) + [S3 Batch Replication](#considerations-batch-replication) + [S3 Replication Time Control](#considerations-RTC) ### Lifecycle configuration and object replicas The time it takes for Amazon S3 to replicate an object depends on the size of the object. For large objects, it can take several hours. Although it might take a while before a replica is available in the destination, it takes the same amount of time to create the replica as it took to create the corresponding object in the source bucket. If a lifecycle configuration is enabled on a destination bucket, the lifecycle rules honor the original creation time of the object, not when the replica became available in the destination bucket. Replication configuration requires the bucket to be versioning-enabled. When you enable versioning on a bucket, keep the following in mind: + If you have an object Expiration lifecycle configuration, after you enable versioning, add a `NonCurrentVersionExpiration` policy to maintain the same permanent delete behavior as before you enabled versioning. + If you have a Transition lifecycle configuration, after you enable versioning, consider adding a `NonCurrentVersionTransition` policy. ### Versioning configuration and replication configuration Both the source and destination buckets must be versioning-enabled when you configure replication on a bucket. After you enable versioning on both the source and destination buckets and configure replication on the source bucket, you will encounter the following issues: + If you attempt to disable versioning on the source bucket, Amazon S3 returns an error. You must remove the replication configuration before you can disable versioning on the source bucket. + If you disable versioning on the destination bucket, replication fails. The source object has the replication status `FAILED`. ### Using S3 Replication with S3 Intelligent-Tiering S3 Intelligent-Tiering is a storage class that is designed to optimize storage costs by automatically moving data to the most cost-effective access tier. For a small monthly object monitoring and automation charge, S3 Intelligent-Tiering monitors access patterns and automatically moves objects that have not been accessed to lower-cost access tiers. Replicating objects stored in S3 Intelligent-Tiering with S3 Batch Replication or invoking [https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html) or [https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPartCopy.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPartCopy.html) constitutes access. In these cases, the source objects of the copy or replication operations are tiered up. For more information about S3 Intelligent-Tiering see, [Managing storage costs with Amazon S3 Intelligent-Tiering](intelligent-tiering.md). ### Logging configuration and replication configuration If Amazon S3 delivers logs to a bucket that has replication enabled, it replicates the log objects. If [server access logs](ServerLogs.md) or [AWS CloudTrail logs](cloudtrail-logging.md) are enabled on your source or destination bucket, Amazon S3 includes replication-related requests in the logs. For example, Amazon S3 logs each object that it replicates. ### CRR and the destination Region Amazon S3 Cross-Region Replication (CRR) is used to copy objects across S3 buckets in different AWS Regions. You might choose the Region for your destination bucket based on either your business needs or cost considerations. For example, inter-Region data transfer charges vary depending on the Regions that you choose. Suppose that you chose US East (N. Virginia) (`us-east-1`) as the Region for your source bucket. If you choose US West (Oregon) (`us-west-2`) as the Region for your destination buckets, you pay more than if you choose the US East (Ohio) (`us-east-2`) Region. For pricing information, see "Data Transfer Pricing" in [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). There are no data transfer charges associated with Same-Region Replication (SRR). ### S3 Batch Replication For information about considerations for Batch Replication, see [S3 Batch Replication considerations](s3-batch-replication-batch.md#batch-replication-considerations). ### S3 Replication Time Control For information about best practices and considerations for S3 Replication Time Control (S3 RTC), see [Best practices and guidelines for S3 RTC](replication-time-control.md#rtc-best-practices). # Setting up live replication overview **Note** Objects that existed before you set up replication aren't replicated automatically. In other words, Amazon S3 doesn't replicate objects retroactively. To replicate objects that were created before your replication configuration, use S3 Batch Replication. For more information about configuring Batch Replication, see [Replicating existing objects](s3-batch-replication-batch.md). To enable live replication—Same-Region Replication (SRR) or Cross-Region Replication (CRR)—add a replication configuration to your source bucket. This configuration tells Amazon S3 to replicate objects as specified. In the replication configuration, you must provide the following: + **The destination buckets** – The bucket or buckets where you want Amazon S3 to replicate the objects. + **The objects that you want to replicate** – You can replicate all objects in the source bucket or a subset of objects. You identify a subset by providing a [key name prefix](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#keyprefix), one or more object tags, or both in the configuration. For example, if you configure a replication rule to replicate only objects with the key name prefix `Tax/`, Amazon S3 replicates objects with keys such as `Tax/doc1` or `Tax/doc2`. But it doesn't replicate objects with the key `Legal/doc3`. If you specify both a prefix and one or more tags, Amazon S3 replicates only objects that have the specific key prefix and tags. + **An AWS Identity and Access Management (IAM) role** – Amazon S3 assumes this IAM role to replicate objects on your behalf. For more information about creating this IAM role and managing permissions, see [Setting up permissions for live replication](setting-repl-config-perm-overview.md). In addition to these minimum requirements, you can choose the following options: + **Replica storage class** – By default, Amazon S3 stores object replicas using the same storage class as the source object. You can specify a different storage class for the replicas. + **Replica ownership** – Amazon S3 assumes that an object replica continues to be owned by the owner of the source object. So when it replicates objects, it also replicates the corresponding object access control list (ACL) or S3 Object Ownership setting. If the source and destination buckets are owned by different AWS accounts, you can configure replication to change the owner of a replica to the AWS account that owns the destination bucket. For more information, see [Changing the replica owner](replication-change-owner.md). You can configure replication by using the Amazon S3 console, AWS Command Line Interface (AWS CLI), AWS SDKs, or the Amazon S3 REST API. For detailed walkthroughs of how to set up replication, see [Examples for configuring live replication](replication-example-walkthroughs.md). Amazon S3 provides REST API operations to support setting up replication rules. For more information, see the following topics in the *Amazon Simple Storage Service API Reference*: + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketReplication.html) + [https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html) **Topics** + [Replication configuration file elements](replication-add-config.md) + [Setting up permissions for live replication](setting-repl-config-perm-overview.md) + [Examples for configuring live replication](replication-example-walkthroughs.md) # Replication configuration file elements Amazon S3 stores a replication configuration as XML. If you're configuring replication programmatically through the Amazon S3 REST API, you specify the various elements of your replication configuration in this XML file. If you're configuring replication through the AWS Command Line Interface (AWS CLI), you specify your replication configuration using JSON format. For JSON examples, see the walkthroughs in [Examples for configuring live replication](replication-example-walkthroughs.md). **Note** The latest version of the replication configuration XML format is V2. XML V2 replication configurations are those that contain the `` element for rules, and rules that specify S3 Replication Time Control (S3 RTC). To see your replication configuration version, you can use the `GetBucketReplication` API operation. For more information, see [https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketReplication.html) in the *Amazon Simple Storage Service API Reference*. For backward compatibility, Amazon S3 continues to support the XML V1 replication configuration format. If you've used the XML V1 replication configuration format, see [Backward compatibility considerations](#replication-backward-compat-considerations) for backward compatibility considerations. In the replication configuration XML file, you must specify an AWS Identity and Access Management (IAM) role and one or more rules, as shown in the following example: ``` IAM-role-ARN ... ... ... ``` Amazon S3 can't replicate objects without your permission. You grant permissions to Amazon S3 with the IAM role that you specify in the replication configuration. Amazon S3 assumes this IAM role to replicate objects on your behalf. You must grant the required permissions to the IAM role first. For more information about managing permissions, see [Setting up permissions for live replication](setting-repl-config-perm-overview.md). You add only one rule in a replication configuration in the following scenarios: + You want to replicate all objects. + You want to replicate only one subset of objects. You identify the object subset by adding a filter in the rule. In the filter, you specify an object key prefix, tags, or a combination of both to identify the subset of objects that the rule applies to. The filters target objects that match the exact values that you specify. If you want to replicate different subsets of objects, you add multiple rules in a replication configuration. In each rule, you specify a filter that selects a different subset. For example, you might choose to replicate objects that have either `tax/` or `document/` key prefixes. To do this, you add two rules, one that specifies the `tax/` key prefix filter and another that specifies the `document/` key prefix. For more information about object key prefixes, see [Organizing objects using prefixes](using-prefixes.md). The following sections provide additional information. **Topics** + [Basic rule configuration](#replication-config-min-rule-config) + [Optional: Specifying a filter](#replication-config-optional-filter) + [Additional destination configurations](#replication-config-optional-dest-config) + [Example replication configurations](#replication-config-example-configs) + [Backward compatibility considerations](#replication-backward-compat-considerations) ## Basic rule configuration Each rule must include the rule's status and priority. The rule must also indicate whether to replicate delete markers. + The `` element indicates whether the rule is enabled or disabled by using the values `Enabled` or `Disabled`. If a rule is disabled, Amazon S3 doesn't perform the actions specified in the rule. + The `` element indicates which rule has precedence whenever two or more replication rules conflict. Amazon S3 attempts to replicate objects according to all replication rules. However, if there are two or more rules with the same destination bucket, then objects are replicated according to the rule with the highest priority. The higher the number, the higher the priority. + The `` element indicates whether to replicate delete markers by using the values `Enabled` or `Disabled`. In the `` element configuration, you must provide the name of the destination bucket or buckets where you want Amazon S3 to replicate objects. The following example shows the minimum requirements for a V2 rule. For backward compatibility, Amazon S3 continues to support the XML V1 format. For more information, see [Backward compatibility considerations](#replication-backward-compat-considerations). ``` ... Rule-1 Enabled-or-Disabled integer Enabled-or-Disabled       arn:aws:s3:::amzn-s3-demo-destination-bucket ... ... ... ``` You can also specify other configuration options. For example, you might choose to use a storage class for object replicas that differs from the class for the source object. ## Optional: Specifying a filter To choose a subset of objects that the rule applies to, add an optional filter. You can filter by object key prefix, object tags, or a combination of both. If you filter on both a key prefix and object tags, Amazon S3 combines the filters by using a logical `AND` operator. In other words, the rule applies to a subset of objects with both a specific key prefix and specific tags. **Filter based on object key prefix** To specify a rule with a filter based on an object key prefix, use the following XML. You can specify only one prefix per rule. ``` ... key-prefix ... ... ``` **Filter based on object tags** To specify a rule with a filter based on object tags, use the following XML. You can specify one or more object tags. ``` ... key1 value1 key2 value2 ... ... ... ``` **Filter with a key prefix and object tags** To specify a rule filter with a combination of a key prefix and object tags, use the following XML. You wrap these filters in an `` parent element. Amazon S3 performs a logical `AND` operation to combine these filters. In other words, the rule applies to a subset of objects with both a specific key prefix and specific tags. ``` ... key-prefix key1 value1 key2 value2 ... ... ... ``` **Note** If you specify a rule with an empty `` element, your rule applies to all objects in your bucket. When you're using tag-based replication rules with live replication, new objects must be tagged with the matching replication rule tag in the `PutObject` operation. Otherwise, the objects won't be replicated. If objects are tagged after the `PutObject` operation, those objects also won't be replicated. To replicate objects that have been tagged after the `PutObject` operation, you must use S3 Batch Replication. For more information about Batch Replication, see [Replicating existing objects](s3-batch-replication-batch.md). ## Additional destination configurations In the destination configuration, you specify the bucket or buckets where you want Amazon S3 to replicate objects. You can set configurations to replicate objects from one source bucket to one or more destination buckets. ``` ... arn:aws:s3:::amzn-s3-demo-destination-bucket ... ``` You can add the following options in the `` element. **Topics** + [Specify storage class](#storage-class-configuration) + [Add multiple destination buckets](#multiple-destination-buckets-configuration) + [Specify different parameters for each replication rule with multiple destination buckets](#replication-rule-configuration) + [Change replica ownership](#replica-ownership-configuration) + [Enable S3 Replication Time Control](#rtc-configuration) + [Replicate objects created with server-side encryption by using AWS KMS](#sse-kms-configuration) ### Specify storage class You can specify the storage class for the object replicas. By default, Amazon S3 uses the storage class of the source object to create object replicas, as in the following example. ``` ... arn:aws:s3:::amzn-s3-demo-destination-bucket storage-class ... ``` ### Add multiple destination buckets You can add multiple destination buckets in a single replication configuration, as follows. ``` ... Rule-1 Enabled-or-Disabled integer Enabled-or-Disabled arn:aws:s3:::amzn-s3-demo-destination-bucket1 Rule-2 Enabled-or-Disabled integer Enabled-or-Disabled arn:aws:s3:::amzn-s3-demo-destination-bucket2 ... ``` ### Specify different parameters for each replication rule with multiple destination buckets When adding multiple destination buckets in a single replication configuration, you can specify different parameters for each replication rule, as follows. ``` ... Rule-1 Enabled-or-Disabled integer Disabled Enabled 15 arn:aws:s3:::amzn-s3-demo-destination-bucket1 Rule-2 Enabled-or-Disabled integer Enabled Enabled 15 Enabled arn:aws:s3:::amzn-s3-demo-destination-bucket2 ... ``` ### Change replica ownership When the source and destination buckets aren't owned by the same accounts, you can change the ownership of the replica to the AWS account that owns the destination bucket. To do so, add the `` element. This element takes the value `Destination`. ``` ... arn:aws:s3:::amzn-s3-demo-destination-bucket destination-bucket-owner-account-id Destination ... ``` If you don't add the `` element to the replication configuration, the replicas are owned by the same AWS account that owns the source object. For more information, see [Changing the replica owner](replication-change-owner.md). ### Enable S3 Replication Time Control You can enable S3 Replication Time Control (S3 RTC) in your replication configuration. S3 RTC replicates most objects in seconds and 99.99 percent of objects within 15 minutes (backed by a service-level agreement). **Note** Only a value of `15` is accepted for the `` and `