# Managing S3 on Outposts storage
With Amazon S3 on Outposts, you can create S3 buckets on your AWS Outposts and easily store and retrieve objects on premises for applications that require local data access, local data processing, and data residency. S3 on Outposts provides a new storage class, S3 Outposts (`OUTPOSTS`), which uses the Amazon S3 APIs, and is designed to store data durably and redundantly across multiple devices and servers on your AWS Outposts. You communicate with your Outpost bucket by using an access point and endpoint connection over a virtual private cloud (VPC). You can use the same APIs and features on Outpost buckets as you do on Amazon S3 buckets, including access policies, encryption, and tagging. You can use S3 on Outposts through the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDKs, or REST API. For more information, see [What is Amazon S3 on Outposts?](S3onOutposts.md)
For more information about managing and sharing your Amazon S3 on Outposts storage capacity, see the following topics.
**Topics**
+ [Managing S3 Versioning for your S3 on Outposts bucket](S3OutpostsManagingVersioning.md)
+ [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](S3OutpostsLifecycleManaging.md)
+ [Replicating objects for S3 on Outposts](S3OutpostsReplication.md)
+ [Sharing S3 on Outposts by using AWS RAM](outposts-sharing-with-ram.md)
+ [Other AWS services that use S3 on Outposts](S3OutpostsOtherServices.md)
# Managing S3 Versioning for your S3 on Outposts bucket
When enabled, S3 Versioning saves multiple distinct copies of an object in the same bucket. You can use S3 Versioning to preserve, retrieve, and restore every version of every object stored in your Outposts buckets. S3 Versioning helps you recover from unintended user actions and application failures.
Amazon S3 on Outposts buckets have three versioning states:
+ **Unversioned** – If you’ve never enabled or suspended S3 Versioning on your bucket, it is unversioned and returns no S3 Versioning status. For more information about S3 Versioning, see [Managing S3 Versioning for your S3 on Outposts bucket](#S3OutpostsManagingVersioning).
+ **Enabled** – Enables S3 Versioning for the objects in the bucket. All objects added to the bucket receive a unique version ID. Objects that already existed in the bucket at the time that you enable versioning have a version ID of `null`. If you modify these (or any other) objects with other operations, such as [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html), the new objects get a unique version ID.
+ **Suspended** – Suspends S3 Versioning for the objects in the bucket. All objects added to the bucket after versioning is suspended receive the version ID `null`. For more information, see [Adding objects to versioning-suspended buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AddingObjectstoVersionSuspendedBuckets.html) in the *Amazon S3 User Guide*.
After you enable S3 Versioning for an S3 on Outposts bucket, it can never return to an unversioned state. However, you can suspend versioning. For more information about S3 Versioning, see [Managing S3 Versioning for your S3 on Outposts bucket](#S3OutpostsManagingVersioning).
For each object in your bucket, you have a current version and zero or more noncurrent versions. To reduce storage costs, you can configure your bucket S3 Lifecycle rules to expire noncurrent versions after a specified time period. For more information, see [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](S3OutpostsLifecycleManaging.md).
The following examples show you how to enable or suspend versioning for an existing S3 on Outposts bucket by using the AWS Management Console and the AWS Command Line Interface (AWS CLI). To create a bucket with S3 Versioning enabled, see [Creating an S3 on Outposts bucket](S3OutpostsCreateBucket.md).
**Note**
The AWS account that creates the bucket owns it and is the only one that can commit actions to it. Buckets have configuration properties, such as Outpost, tag, default encryption, and access point settings. The access point settings include the virtual private cloud (VPC), the access point policy for accessing the objects in the bucket, and other metadata. For more information, see [S3 on Outposts specifications](S3OnOutpostsRestrictionsLimitations.md#S3OnOutpostsSpecifications).
## Using the S3 console
**To edit the S3 Versioning settings for your bucket**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. Choose the Outposts bucket that you want to enable S3 Versioning for.
1. Choose the **Properties** tab.
1. Under **Bucket Versioning**, choose **Edit**.
1. Edit the S3 Versioning settings for the bucket by choosing one of the following options:
+ To suspend S3 Versioning and stop the creation of new object versions, choose **Suspend**.
+ To enable S3 Versioning and save multiple distinct copies of each object, choose **Enable**.
1. Choose **Save changes**.
## Using the AWS CLI
To enable or suspend S3 Versioning for your bucket by using the AWS CLI, use the `put-bucket-versioning` command, as shown in the following examples. To use these examples, replace each `user input placeholder` with your own information.
For more information, see [put-bucket-versioning](https://docs.aws.amazon.com/cli/latest/reference/s3control/put-bucket-versioning.html) in the *AWS CLI Reference*.
**Example : To enable S3 Versioning**
```
aws s3control put-bucket-versioning --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/op-01ac5d28a6a232904/bucket/example-outposts-bucket --versioning-configuration Status=Enabled
```
**Example : To suspend S3 Versioning**
```
aws s3control put-bucket-versioning --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/op-01ac5d28a6a232904/bucket/example-outposts-bucket --versioning-configuration Status=Suspended
```
# Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket
You can use S3 Lifecycle to optimize storage capacity for Amazon S3 on Outposts. You can create lifecycle rules to expire objects as they age or are replaced by newer versions. You can create, enable, disable, or delete a lifecycle rule.
For more information about S3 Lifecycle, see [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](#S3OutpostsLifecycleManaging).
**Note**
The AWS account that creates the bucket owns it and is the only one that can create, enable, disable, or delete a lifecycle rule.
To create and manage the lifecycle configuration for your S3 on Outposts bucket, see the following topics.
**Topics**
+ [Creating and managing a lifecycle rule by using the AWS Management Console](S3OutpostsLifecycleConsole.md)
+ [Creating and managing a lifecycle configuration by using the AWS CLI and SDK for Java](S3OutpostsLifecycleCLIJava.md)
# Creating and managing a lifecycle rule by using the AWS Management Console
You can use S3 Lifecycle to optimize storage capacity for Amazon S3 on Outposts. You can create lifecycle rules to expire objects as they age or are replaced by newer versions. You can create, enable, disable, or delete a lifecycle rule.
For more information about S3 Lifecycle, see [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](S3OutpostsLifecycleManaging.md).
**Note**
The AWS account that creates the bucket owns it and is the only one that can create, enable, disable, or delete a lifecycle rule.
To create and manage a lifecycle rule for an S3 on Outposts by using the AWS Management Console, see the following topics.
**Topics**
+ [Creating a lifecycle rule](#s3-outposts-bucket-create-lifecycle)
+ [Enabling a lifecycle rule](#s3-outposts-bucket-enable-lifecycle)
+ [Editing a lifecycle rule](#s3-outposts-bucket-edit-lifecycle)
+ [Deleting a lifecycle rule](#s3-outposts-bucket-delete-lifecycle)
## Creating a lifecycle rule
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. Choose the Outposts bucket that you want to create a lifecycle rule for.
1. Choose the **Management** tab, and then choose **Create Lifecycle rule**.
1. Enter a value for **Lifecycle rule name**.
1. Under **Rule scope**, choose one of the following options:
+ To limit the scope to specific filters, choose **Limit the scope of this rule using one or more filters**. Then, add a prefix filter, tags, or object size.
+ To apply the rule to all objects in the bucket, choose **Apply to all objects in the bucket**.
1. Under **Lifecycle rule actions**, choose one of the following options:
+ **Expire current versions of objects** – For versioning-enabled buckets, S3 on Outposts adds a delete marker and retains the objects as noncurrent versions. For buckets that don't use S3 Versioning, S3 on Outposts permanently deletes the objects.
+ **Permanently delete noncurrent versions of objects ** – S3 on Outposts permanently deletes noncurrent versions of objects.
+ **Delete expired object delete markers or incomplete multipart uploads** – S3 on Outposts permanently deletes expired object delete markers or incomplete multipart uploads.
If you limit the scope of your Lifecycle rule by using object tags, you can't choose **Delete expired object delete markers**. You also can't choose **Delete expired object delete markers** if you choose **Expire current object versions**.
**Note**
Size-based filters can't be used with delete markers and incomplete multipart uploads.
1. If you chose **Expire current versions of objects** or **Permanently delete noncurrent versions of objects**, configure the rule trigger based on a specific date or the object's age.
1. If you chose **Delete expired object delete markers**, to confirm that you want to delete expired object delete markers, select **Delete expired object delete markers**.
1. Under **Timeline Summary**, review your Lifecycle rule, and choose **Create rule**.
## Enabling a lifecycle rule
**To enable or disable a bucket lifecycle rule**
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. Choose the Outposts bucket that you want to enable or disable a lifecycle rule for.
1. Choose the **Management** tab, and then under **Lifecycle rule**, choose the rule that you want to enable or disable.
1. For **Action**, choose **Enable or disable rule**.
## Editing a lifecycle rule
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. Choose the Outposts bucket that you want to edit a lifecycle rule for.
1. Choose the **Management** tab, and then choose the **Lifecycle rule** that you want to edit.
1. (Optional) Update the value for **Lifecycle rule name**.
1. Under **Rule scope**, edit the scope as needed:
+ To limit the scope to specific filters, choose **Limit the scope of this rule using one or more filters**. Then, add a prefix filter, tags, or object size.
+ To apply the rule to all objects in the bucket, choose **Apply to all objects in the bucket**.
1. Under **Lifecycle rule actions**, choose one of the following options:
+ **Expire current versions of objects** – For versioning-enabled buckets, S3 on Outposts adds a delete marker and retains the objects as noncurrent versions. For buckets that don't use S3 Versioning, S3 on Outposts permanently deletes the objects.
+ **Permanently delete noncurrent versions of objects ** – S3 on Outposts permanently deletes noncurrent versions of objects.
+ **Delete expired object delete markers or incomplete multipart uploads** – S3 on Outposts permanently deletes expired object delete markers or incomplete multipart uploads.
If you limit the scope of your Lifecycle rule by using object tags, you can't choose **Delete expired object delete markers**. You also can't choose **Delete expired object delete markers** if you choose **Expire current object versions**.
**Note**
Size-based filters can't be used with delete markers and incomplete multipart uploads.
1. If you chose **Expire current versions of objects** or **Permanently delete noncurrent versions of objects**, configure the rule trigger based on a specific date or the object age.
1. If you chose **Delete expired object delete markers**, to confirm that you want to delete expired object delete markers, select **Delete expired object delete markers**.
1. Choose **Save**.
## Deleting a lifecycle rule
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. Choose the Outposts bucket that you want to delete a lifecycle rule for.
1. Choose the **Management** tab, and then under **Lifecycle rule**, choose the rule that you want to delete.
1. Choose **Delete**.
# Creating and managing a lifecycle configuration by using the AWS CLI and SDK for Java
You can use S3 Lifecycle to optimize storage capacity for Amazon S3 on Outposts. You can create lifecycle rules to expire objects as they age or are replaced by newer versions. You can create, enable, disable, or delete a lifecycle rule.
For more information about S3 Lifecycle, see [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](S3OutpostsLifecycleManaging.md).
**Note**
The AWS account that creates the bucket owns it and is the only one that can create, enable, disable, or delete a lifecycle rule.
To create and manage a lifecycle configuration for an S3 on Outposts bucket by using the AWS Command Line Interface (AWS CLI) and the AWS SDK for Java, see the following examples.
**Topics**
+ [PUT a lifecycle configuration](#S3OutpostsPutBucketLifecycleConfiguration)
+ [GET the lifecycle configuration on an S3 on Outposts bucket](#S3OutpostsGetBucketLifecycleConfiguration)
## PUT a lifecycle configuration
------
#### [ AWS CLI ]
The following AWS CLI example puts a lifecycle configuration policy on an Outposts bucket. This policy specifies that all objects that have the flagged prefix (`myprefix`) and tags expire after 10 days. To use this example, replace each `user input placeholder` with your own information.
1. Save the lifecycle configuration policy to a JSON file. In this example, the file is named `lifecycle1.json`.
```
{
"Rules": [
{
"ID": "id-1",
"Filter": {
"And": {
"Prefix": "myprefix",
"Tags": [
{
"Value": "mytagvalue1",
"Key": "mytagkey1"
},
{
"Value": "mytagvalue2",
"Key": "mytagkey2"
}
],
"ObjectSizeGreaterThan": 1000,
"ObjectSizeLessThan": 5000
}
},
"Status": "Enabled",
"Expiration": {
"Days": 10
}
}
]
}
```
1. Submit the JSON file as part of the `put-bucket-lifecycle-configuration` CLI command. To use this command, replace each `user input placeholder` with your own information. For more information about this command, see [put-bucket-lifecycle-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/put-bucket-lifecycle-configuration.html) in the *AWS CLI Reference*.
```
aws s3control put-bucket-lifecycle-configuration --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/op-01ac5d28a6a232904/bucket/example-outposts-bucket --lifecycle-configuration file://lifecycle1.json
```
------
#### [ SDK for Java ]
The following SDK for Java example puts a lifecycle configuration on an Outposts bucket. This lifecycle configuration specifies that all objects that have the flagged prefix (`myprefix`) and tags expire after 10 days. To use this example, replace each `user input placeholder` with your own information. For more information, see [PutBucketLifecycleConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketLifecycleConfiguration.html) in the *Amazon Simple Storage Service API Reference*.
```
import com.amazonaws.services.s3control.model.*;
public void putBucketLifecycleConfiguration(String bucketArn) {
S3Tag tag1 = new S3Tag().withKey("mytagkey1").withValue("mytagkey1");
S3Tag tag2 = new S3Tag().withKey("mytagkey2").withValue("mytagkey2");
LifecycleRuleFilter lifecycleRuleFilter = new LifecycleRuleFilter()
.withAnd(new LifecycleRuleAndOperator()
.withPrefix("myprefix")
.withTags(tag1, tag2))
.withObjectSizeGreaterThan(1000)
.withObjectSizeLessThan(5000);
LifecycleExpiration lifecycleExpiration = new LifecycleExpiration()
.withExpiredObjectDeleteMarker(false)
.withDays(10);
LifecycleRule lifecycleRule = new LifecycleRule()
.withStatus("Enabled")
.withFilter(lifecycleRuleFilter)
.withExpiration(lifecycleExpiration)
.withID("id-1");
LifecycleConfiguration lifecycleConfiguration = new LifecycleConfiguration()
.withRules(lifecycleRule);
PutBucketLifecycleConfigurationRequest reqPutBucketLifecycle = new PutBucketLifecycleConfigurationRequest()
.withAccountId(AccountId)
.withBucket(bucketArn)
.withLifecycleConfiguration(lifecycleConfiguration);
PutBucketLifecycleConfigurationResult respPutBucketLifecycle = s3ControlClient.putBucketLifecycleConfiguration(reqPutBucketLifecycle);
System.out.printf("PutBucketLifecycleConfiguration Response: %s%n", respPutBucketLifecycle.toString());
}
```
------
## GET the lifecycle configuration on an S3 on Outposts bucket
------
#### [ AWS CLI ]
The following AWS CLI example gets a lifecycle configuration on an Outposts bucket. To use this command, replace each `user input placeholder` with your own information. For more information about this command, see [get-bucket-lifecycle-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/get-bucket-lifecycle-configuration.html) in the *AWS CLI Reference*.
```
aws s3control get-bucket-lifecycle-configuration --account-id 123456789012 --bucket arn:aws:s3-outposts::123456789012:outpost/op-01ac5d28a6a232904/bucket/example-outposts-bucket
```
------
#### [ SDK for Java ]
The following SDK for Java example gets a lifecycle configuration for an Outposts bucket. For more information, see [GetBucketLifecycleConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketLifecycleConfiguration.html) in the *Amazon Simple Storage Service API Reference*.
```
import com.amazonaws.services.s3control.model.*;
public void getBucketLifecycleConfiguration(String bucketArn) {
GetBucketLifecycleConfigurationRequest reqGetBucketLifecycle = new GetBucketLifecycleConfigurationRequest()
.withAccountId(AccountId)
.withBucket(bucketArn);
GetBucketLifecycleConfigurationResult respGetBucketLifecycle = s3ControlClient.getBucketLifecycleConfiguration(reqGetBucketLifecycle);
System.out.printf("GetBucketLifecycleConfiguration Response: %s%n", respGetBucketLifecycle.toString());
}
```
------
# Replicating objects for S3 on Outposts
With S3 Replication on AWS Outposts, you can configure Amazon S3 on Outposts to automatically replicate S3 objects across different Outposts, or between buckets on the same Outpost. You can use S3 Replication on Outposts to maintain multiple replicas of your data in the same or different Outposts, or across different accounts, to help meet data-residency needs. S3 Replication on Outposts helps power your compliant storage needs and data sharing across accounts. If you need to ensure that your replicas are identical to the source data, you can use S3 Replication on Outposts to make replicas of your objects that retain all metadata, such as the original object creation time, tags, and version IDs.
S3 Replication on Outposts also provides detailed metrics and notifications to monitor the status of object replication between buckets. You can use Amazon CloudWatch to monitor replication progress by tracking bytes pending replication, operations pending replication, and replication latency between your source and destination buckets. To quickly diagnose and correct configuration issues, you can also set up Amazon EventBridge to receive notifications about replication object failures. To learn more, see [Managing your replication](manage-outposts-replication.md).
**Topics**
+ [Replication configuration](#outposts-replication-add-config)
+ [Requirements for S3 Replication on Outposts](#outposts-replication-requirements)
+ [What is replicated?](#outposts-replication-what-is-replicated)
+ [What isn't replicated?](#outposts-replication-what-is-not-replicated)
+ [What isn't supported by S3 Replication on Outposts?](#outposts-replication-what-is-not-supported)
+ [Setting up replication](outposts-replication-how-setup.md)
+ [Managing your replication](manage-outposts-replication.md)
## Replication configuration
S3 on Outposts stores a replication configuration as XML. In the replication configuration XML file, you specify an AWS Identity and Access Management (IAM) role and one or more rules.
```
IAM-role-ARN
...
...
...
```
S3 on Outposts can't replicate objects without your permission. You grant S3 on Outposts permissions with the IAM role that you specify in the replication configuration. S3 on Outposts assumes that IAM role to replicate objects on your behalf. You must grant the required permissions to the IAM role before starting replication. For more information about these permissions for S3 on Outposts, see [Creating an IAM role](outposts-replication-prerequisites-config.md#outposts-rep-pretwo).
You add one rule in a replication configuration in the following scenarios:
+ You want to replicate all objects.
+ You want to replicate 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.
You add multiple rules in a replication configuration if you want to replicate different subsets of objects. In each rule, you specify a filter that selects a different subset of objects. 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 S3 on Outposts replication configuration and replication rules, see [ ReplicationConfiguration ](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ReplicationConfiguration.html) in the *Amazon Simple Storage Service API Reference*.
## Requirements for S3 Replication on Outposts
Replication requires the following:
+ The destination Outpost CIDR range must be associated in your source Outpost subnet table. For more information, see [Prerequisites for creating replication rules](outposts-replication-prerequisites-config.md).
+ Both the source and destination buckets must have S3 Versioning enabled. For more information about versioning, see [Managing S3 Versioning for your S3 on Outposts bucket](S3OutpostsManagingVersioning.md).
+ Amazon S3 on Outposts must have permission to replicate objects from the source bucket to the destination bucket on your behalf. That means you must create a service role to delegate `GET` and `PUT` permissions to S3 on Outposts.
1. Before creating the service role, you must have `GET` permission on the source bucket and `PUT` permission on the destination bucket.
1. To create the service role to delegate permissions to S3 on Outposts, you must first configure permissions to allow an IAM entity (a user or role) to perform the `iam:CreateRole` and `iam:PassRole` actions. Then, you allow the IAM entity to create a service role. To make S3 on Outposts assume the service role on your behalf and delegate `GET` and `PUT` permissions to S3 on Outposts, you must assign the necessary trust and permissions policies to the role. For more information about these permissions for S3 on Outposts, see [Creating an IAM role](outposts-replication-prerequisites-config.md#outposts-rep-pretwo). For more information about creating a service role, see [Creating a service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html).
## What is replicated?
By default, S3 on Outposts replicates the following:
+ Objects created after you add a replication configuration.
+ Object metadata from the source objects to the replicas. For information about how to replicate metadata from the replicas to the source objects, see [Replication status if Amazon S3 replica modification sync on Outposts is enabled](manage-outposts-replication.md#outposts-replication-status-sync).
+ Object tags, if there are any.
### 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, S3 on Outposts adds a delete marker. S3 on Outposts deals with the delete marker as follows:
+ S3 on Outposts does not replicate the delete marker by default.
+ However, you can add *delete marker replication* to non-tag-based rules. For more information about how to enable delete marker replication in your replication configuration, see [Using the S3 console](replication-between-outposts.md#outposts-enable-replication).
+ If you specify an object version ID to delete in a `DELETE` request, S3 on Outposts permanently deletes that object version in the source bucket. However, 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 behavior protects data from malicious deletions.
## What isn't replicated?
By default, S3 on Outposts 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.
+ 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, S3 on Outposts won't replicate the objects again.
+ Objects that are created with server-side encryption with customer-provided encryption keys (SSE-C).
+ 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 the source and destination buckets.
+ Actions performed by lifecycle configuration.
For example, if you enable a lifecycle configuration only on your source bucket and configure expiration actions, S3 on Outposts creates delete markers for expired objects in the source bucket but doesn't replicate those markers to the destination buckets. 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 [Creating and managing a lifecycle configuration for your Amazon S3 on Outposts bucket](S3OutpostsLifecycleManaging.md).
## What isn't supported by S3 Replication on Outposts?
The following S3 Replication features are currently not supported by S3 on Outposts:
+ S3 Replication Time Control (S3 RTC). S3 RTC is not supported because the object traffic in S3 Replication on Outposts travels over your on-premises network (the local gateway). For more information about local gateways, see [ Working with the local gateway](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#working-with-lgw) in the *AWS Outposts User Guide*.
+ S3 Replication for Batch Operations.
# Setting up replication
**Note**
Objects that existed in your bucket before you set up a replication rule aren't replicated automatically. In other words, Amazon S3 on Outposts doesn't replicate objects retroactively. To replicate objects that were created before your replication configuration, you can use the `CopyObject` API operation to copy them to the same bucket. After the objects are copied, they appear as "new" objects in the bucket and the replication configuration will apply to them. For more information about copying an object, see [Copying an object in an Amazon S3 on Outposts bucket using the AWS SDK for Java](S3OutpostsCopyObject.md) and [https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html) in the *Amazon Simple Storage Service API Reference*.
To enable S3 Replication on Outposts, add a replication rule to your source Outposts bucket. The replication rule tells S3 on Outposts to replicate objects as specified. In the replication rule, you must provide the following:
+ **The source Outposts bucket access point** – The access point Amazon Resource Name (ARN) or access point alias of the bucket from which you want S3 on Outposts to replicate the objects. For more information about using access point aliases, see [Using a bucket-style alias for your S3 on Outposts bucket access point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-outposts-access-points-alias.html).
+ **The objects that you want to replicate** – You can replicate all of the objects in the source Outposts bucket or a subset. You identify a subset by providing a [key name prefix](https://docs.aws.amazon.com/general/latest/gr/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/`, S3 on Outposts 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, S3 on Outposts replicates only objects that have the specific key prefix and tags.
+ **The destination Outposts bucket** – The ARN or access point alias of the bucket to which you want S3 on Outposts to replicate the objects.
You can configure the replication rule by using the REST API, AWS SDKs, AWS Command Line Interface (AWS CLI), or Amazon S3 console.
S3 on Outposts also provides 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_control_PutBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutBucketReplication.html)
+ [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_GetBucketReplication.html)
+ [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_DeleteBucketReplication.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_DeleteBucketReplication.html)
**Topics**
+ [Prerequisites for creating replication rules](outposts-replication-prerequisites-config.md)
+ [Creating replication rules on Outposts](replication-between-outposts.md)
# Prerequisites for creating replication rules
**Topics**
+ [Connecting your source and destination Outpost subnets](#outposts-rep-preone)
+ [Creating an IAM role](#outposts-rep-pretwo)
## Connecting your source and destination Outpost subnets
To have your replication traffic go from your source Outpost to your destination Outpost over your local gateway, you must add a new route to set up networking. You must connect the Classless Inter-Domain Routing (CIDR) networking ranges of your access points together. For each pair of access points, you need to set up this connection only once.
Some steps to set up the connection are different, depending on the access type of your Outposts endpoints that are associated with your access points. The access type for endpoints is either **Private** (direct virtual private cloud [VPC] routing for AWS Outposts) or **Customer owned IP** (a customer-owned IP address pool [CoIP pool] within your on-premises network).
### Step 1: Find the CIDR range of your source Outposts endpoint
**To find the CIDR range of your source endpoint that's associated with your source access point**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the left navigation pane, choose **Outposts buckets**.
1. In the **Outposts buckets** list, choose the source bucket that you want for replication.
1. Choose the **Outposts access points** tab, and choose the Outposts access point for the source bucket for your replication rule.
1. Choose the Outposts endpoint.
1. Copy the subnet ID for use in [Step 5](#outposts-pre-step5).
1. The method that you use to find the CIDR range of the source Outposts endpoint depends on the access type of your endpoint.
In the **Outposts endpoint overview** section, see the **Access Type**.
+ If the access type is **Private**, copy the **Classless inter-domain routing (CIDR)** value to use in [Step 6](#outposts-pre-step6).
+ If the access type is **Customer Owned IP**, do the following:
1. Copy the **Customer owned IPv4 pool** value to use as the ID of the address pool later on.
1. Open the AWS Outposts console at [https://console.aws.amazon.com/outposts/](https://console.aws.amazon.com/outposts/home).
1. In the navigation pane, choose **Local gateway route tables**.
1. Choose the **Local gateway route table ID** value of your source Outpost.
1. In the details pane, choose the **CoIP pools** tab. Paste the value of your CoIP pool ID that you copied previously in the search box.
1. For the matched CoIP pool, copy the corresponding **CIDRs** value of your source Outposts endpoint for use in [Step 6](#outposts-pre-step6).
### Step 2: Find the subnet ID and the CIDR range of your destination Outposts endpoint
To find the subnet ID and the CIDR range of your destination endpoint that's associated with your destination access point, follow the same substeps in [Step 1](#outposts-pre-step1) and change your source Outposts endpoint to your destination Outposts endpoint when you apply those substeps. Copy the subnet ID value of your destination Outposts endpoint for use in [Step 6](#outposts-pre-step6). Copy the CIDR value of your destination Outposts endpoint for use in [Step 5](#outposts-pre-step5).
### Step 3: Find the local gateway ID of your source Outpost
**To find the local gateway ID of your source Outpost**
1. Open the AWS Outposts console at [https://console.aws.amazon.com/outposts/](https://console.aws.amazon.com/outposts/home).
1. In the left navigation pane, choose **Local gateways**.
1. On the **Local gateways** page, find the Outpost ID of your source Outpost that you want to use for replication.
1. Copy the local gateway ID value of your source Outpost for use in [Step 5](#outposts-pre-step5).
For more information about local gateway, see [Local gateway](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) in the *AWS Outposts User Guide*.
### Step 4: Find the local gateway ID of your destination Outpost
To find the local gateway ID of your destination Outpost, follow the same substeps in [Step 3](#outposts-pre-step3), except look for the Outpost ID for your destination Outpost. Copy the local gateway ID value of your destination Outpost for use in [Step 6](#outposts-pre-step6).
### Step 5: Set up the connection from your source Outpost subnet to your destination Outpost subnet
**To connect from your source Outpost subnet to your destination Outpost subnet**
1. Sign in to the AWS Management Console and open the VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the left navigation pane, choose **Subnets**.
1. In the search box, enter the subnet ID for your source Outposts endpoint that you found in [Step 1](#outposts-pre-step1). Choose the subnet with the matched subnet ID.
1. For the matched subnet item, choose the **Route table** value of this subnet.
1. On the page with a selected route table, choose **Actions**, and then choose **Edit routes**.
1. On the **Edit routes** page, choose **Add route**.
1. Under **Destination**, enter the CIDR range of your destination Outposts endpoint that you found in [Step 2](#outposts-pre-step2).
1. Under **Target**, choose **Outpost Local Gateway**, and enter the local gateway ID of your source Outpost that you found in [Step 3](#outposts-pre-step3).
1. Choose **Save changes**.
1. Make sure the **Status** for the route is **Active**.
### Step 6: Set up the connection from your destination Outpost subnet to your source Outpost subnet
1. Sign in to the AWS Management Console and open the VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the left navigation pane, choose **Subnets**.
1. In the search box, enter the subnet ID for your destination Outposts endpoint that you found in [Step 2](#outposts-pre-step2). Choose the subnet with the matched subnet ID.
1. For the matched subnet item, choose the **Route table** value of this subnet.
1. On the page with a selected route table, choose **Actions**, and then choose **Edit routes**.
1. On the **Edit routes** page, choose **Add route**.
1. Under **Destination**, enter the CIDR range of your source Outposts endpoint that you found in [Step 1](#outposts-pre-step1).
1. Under **Target**, choose **Outpost Local Gateway**, and enter the local gateway ID of your destination Outpost that you found in [Step 4](#outposts-pre-step4).
1. Choose **Save changes**.
1. Make sure the **Status** for the route is **Active**.
After you connect the CIDR networking ranges of your source and destination access points, you must create an AWS Identity and Access Management (IAM) role.
## Creating an IAM role
By default, all S3 on Outposts resources—buckets, objects, and related subresources—are private, and only the resource owner can access the resource. S3 on Outposts needs permissions to read and replicate objects from the source Outposts bucket. You grant these permissions by creating an IAM *service role* and specifying that role in your replication configuration.
This section explains the trust policy and minimum required permissions policy. The example walkthroughs provide step-by-step instructions to create an IAM role. For more information, see [Creating replication rules on Outposts](replication-between-outposts.md). For more information about IAM roles, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*.
+ The following example shows a *trust policy*, where you identify S3 on Outposts as the service principal that can assume the role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"s3-outposts.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
+ The following example shows an *access policy*, where you grant the role permissions to perform replication tasks on your behalf. When S3 on Outposts assumes the role, it has the permissions that you specify in this policy. To use this policy, replace the `user input placeholders` with your own information. Make sure to replace them with the Outpost IDs of your source and destination Outposts and the bucket names and access point names of your source and destination Outposts buckets.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3-outposts:GetObjectVersionForReplication",
"s3-outposts:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/SOURCE-OUTPOST-ID/bucket/SOURCE-OUTPOSTS-BUCKET/object/*",
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/SOURCE-OUTPOST-ID/accesspoint/SOURCE-OUTPOSTS-BUCKET-ACCESS-POINT/object/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3-outposts:ReplicateObject",
"s3-outposts:ReplicateDelete"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/DESTINATION-OUTPOST-ID/bucket/DESTINATION-OUTPOSTS-BUCKET/object/*",
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/DESTINATION-OUTPOST-ID/accesspoint/DESTINATION-OUTPOSTS-BUCKET-ACCESS-POINT/object/*"
]
}
]
}
```
------
The access policy grants permissions for the following actions:
+ `s3-outposts:GetObjectVersionForReplication` – Permission for this action is granted on all objects to allow S3 on Outposts to get a specific object version that's associated with each object.
+ `s3-outposts:GetObjectVersionTagging` – Permission for this action on objects in the *`SOURCE-OUTPOSTS-BUCKET`* bucket (the source bucket) allows S3 on Outposts to read object tags for replication. For more information, see [Adding tags for S3 on Outposts buckets](S3OutpostsBucketTags.md). If S3 on Outposts doesn't have this permission, it replicates the objects, but not the object tags.
+ `s3-outposts:ReplicateObject` and `s3-outposts:ReplicateDelete` – Permissions for these actions on all objects in the *`DESTINATION-OUTPOSTS-BUCKET`* bucket (the destination bucket) allow S3 on Outposts to replicate objects or delete markers to the destination Outposts bucket. For information about delete markers, see [How delete operations affect replication](S3OutpostsReplication.md#outposts-replication-delete-op).
**Note**
Permission for the `s3-outposts:ReplicateObject` action on the *`DESTINATION-OUTPOSTS-BUCKET`* bucket (the destination bucket) also allows replication of object tags. Therefore, you don't need to explicitly grant permission for the `s3-outposts:ReplicateTags` action.
For cross-account replication, the owner of the destination Outposts bucket must update its bucket policy to grant permission for the `s3-outposts:ReplicateObject` action on the*`DESTINATION-OUTPOSTS-BUCKET`*. The `s3-outposts:ReplicateObject` action allows S3 on Outposts to replicate objects and object tags to the destination Outposts bucket.
For a list of S3 on Outposts actions, see [Actions defined by S3 on Outposts](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3onoutposts.html#amazons3onoutposts-actions-as-permissions).
**Important**
The AWS account that owns the IAM role must have permissions for the actions that it grants to the IAM role.
For example, suppose that the source Outposts bucket contains objects owned by another AWS account. The owner of the objects must explicitly grant the AWS account that owns the IAM role the required permissions through the bucket policy and the access point policy. Otherwise, S3 on Outposts can't access the objects, and replication of the objects fails.
The permissions described here are related to the minimum replication configuration. If you choose to add optional replication configurations, you must grant additional permissions to S3 on Outposts.
### Granting permissions when the source and destination Outposts buckets are owned by different AWS accounts
When the source and destination Outposts buckets aren't owned by the same accounts, the owner of the destination Outposts bucket must update the bucket and access point policies for the destination bucket. These policies must grant the owner of the source Outposts bucket and the IAM service role permissions to perform replication actions, as shown in the following policy examples, or replication will fail. In these policy examples, *`DESTINATION-OUTPOSTS-BUCKET`* is the destination bucket. To use these policy examples, replace the `user input placeholders` with your own information.
If you're creating the IAM service role manually, set the role path as `role/service-role/`, as shown in the following policy examples. For more information, see [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) in the *IAM User Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PolicyForDestinationBucket",
"Statement": [
{
"Sid": "Permissions on objects",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/service-role/source-account-IAM-role"
},
"Action": [
"s3-outposts:ReplicateDelete",
"s3-outposts:ReplicateObject"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:444455556666:outpost/DESTINATION-OUTPOST-ID/bucket/DESTINATION-OUTPOSTS-BUCKET/object/*"
]
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PolicyForDestinationAccessPoint",
"Statement": [
{
"Sid": "Permissions on objects",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/service-role/source-account-IAM-role"
},
"Action": [
"s3-outposts:ReplicateDelete",
"s3-outposts:ReplicateObject"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:111122223333:outpost/DESTINATION-OUTPOST-ID/accesspoint/DESTINATION-OUTPOSTS-BUCKET-ACCESS-POINT/object/*"
]
}
]
}
```
------
**Note**
If objects in the source Outposts bucket are tagged, note the following:
If the source Outposts bucket owner grants S3 on Outposts permission for the `s3-outposts:GetObjectVersionTagging` and `s3-outposts:ReplicateTags` actions to replicate object tags (through the IAM role), Amazon S3 replicates the tags along with the objects. For information about the IAM role, see [Creating an IAM role](#outposts-rep-pretwo).
# Creating replication rules on Outposts
S3 Replication on Outposts is the automatic, asynchronous replication of objects across buckets in the same or different AWS Outposts. Replication copies newly created objects and object updates from a source Outposts bucket to a destination Outposts bucket or buckets. For more information, see [Replicating objects for S3 on Outposts](S3OutpostsReplication.md).
**Note**
Objects that existed in the source Outposts bucket before you set up replication rules aren't replicated. In other words, S3 on Outposts doesn't replicate objects retroactively. To replicate objects that were created before your replication configuration, you can use the `CopyObject` API operation to copy them to the same bucket. After the objects are copied, they appear as "new" objects in the bucket and the replication configuration will apply to them. For more information about copying an object, see [Copying an object in an Amazon S3 on Outposts bucket using the AWS SDK for Java](S3OutpostsCopyObject.md) and [https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html) in the *Amazon Simple Storage Service API Reference*.
When you configure replication, you add replication rules to the source Outposts bucket. Replication rules define which source Outposts bucket objects to replicate and the destination Outposts bucket or buckets where the replicated objects will be stored. You can create a rule to replicate all the objects in a bucket or a subset of objects with a specific key name prefix, one or more object tags, or both. A destination Outposts bucket can be in the same Outpost as the source Outposts bucket, or it can be in a different Outpost.
For S3 on Outposts replication rules, you must provide both the source Outposts bucket's access point Amazon Resource Name (ARN) and the destination Outposts bucket's access point ARN instead of the source and destination Outposts bucket names.
If you specify an object version ID to delete, S3 on Outposts deletes that object version in the source Outposts bucket. But it doesn't replicate the deletion to the destination Outposts bucket. In other words, it doesn't delete the same object version from the destination Outposts bucket. This behavior protects data from malicious deletions.
When you add a replication rule to an Outposts bucket, the rule is enabled by default, so the rule starts working as soon as you save it.
In this example, you set up replication for source and destination Outposts buckets that are on different Outposts and are owned by the same AWS account. Examples are provided for using the Amazon S3 console, the AWS Command Line Interface (AWS CLI), and the AWS SDK for Java and AWS SDK for .NET. For information about cross-account S3 Replication on Outposts permissions, see [Granting permissions when the source and destination Outposts buckets are owned by different AWS accounts](outposts-replication-prerequisites-config.md#outposts-rep-prethree).
For prerequisites to set up S3 on Outposts replication rules, see [Prerequisites for creating replication rules](outposts-replication-prerequisites-config.md).
## Using the S3 console
Follow these steps to configure a replication rule when the destination Amazon S3 on Outposts bucket is in a different Outpost from the source Outposts bucket.
If the destination Outposts bucket is in a different account from the source Outposts bucket, you must add a bucket policy to the destination Outposts bucket to grant the owner of the source Outposts bucket account permission to replicate objects in the destination Outposts bucket.
**To create a replication rule**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the **Outposts Buckets** list, choose the name of the bucket that you want to use as the source bucket.
1. Choose the **Management** tab, scroll down to the **Replication rules** section, and then choose **Create replication rule**.
1. For **Replication rule name**, enter a name for your rule to help identify the rule later. The name is required and must be unique within the bucket.
1. Under **Status**, **Enabled** is chosen by default. An enabled rule starts to work as soon as you save it. If you want to enable the rule later, choose **Disabled**.
1. Under **Priority**, the rule's priority value determines which rule to apply if there are overlapping rules. When objects are included in the scope of more than one replication rule, S3 on Outposts uses these priority values to avoid conflicts. By default, new rules are added to the replication configuration at the highest priority. The higher the number, the higher the priority.
To change the priority for the rule, after you save the rule, choose the rule name from the replication rule list, choose **Actions**, and then choose **Edit priority**.
1. Under **Source bucket**, you have the following options for setting the replication source:
+ To replicate the whole bucket, choose **Apply to *all *objects in the bucket**.
+ To apply prefix or tag filtering to the replication source, choose **Limit the scope of this rule by using one or more filters**. You can combine a prefix and tags.
+ To replicate all objects that have the same prefix, under **Prefix**, enter a prefix in the box. Using the **Prefix** filter limits replication to all objects that have names that begin with the same string (for example, `pictures`).
If you enter a prefix that is the name of a folder, you must use a **/** (forward slash) as the last character (for example, `pictures/`).
+ To replicate all objects that have one or more of the same object tags, choose **Add tag**, and then enter the key-value pair in the boxes. To add another tag, repeat the procedure. For more information about object tags, see [Adding tags for S3 on Outposts buckets](S3OutpostsBucketTags.md).
1. To access your S3 on Outposts source bucket for replication, under **Source access point name**, choose an access point that is attached to the source bucket.
1. Under **Destination**, choose the access point ARN of the destination Outposts bucket where you want S3 on Outposts to replicate objects. The destination Outposts bucket can be in the same or a different AWS account as the source Outposts bucket.
If the destination bucket is in a different account from the source Outposts bucket, you must add a bucket policy to the destination Outposts bucket to grant the owner of the source Outposts bucket account permission to replicate objects to the destination Outposts bucket. For more information, see [Granting permissions when the source and destination Outposts buckets are owned by different AWS accounts](outposts-replication-prerequisites-config.md#outposts-rep-prethree).
**Note**
If versioning is not enabled on the destination Outposts bucket, you get a warning that contains an **Enable versioning** button. Choose this button to enable versioning on the bucket.
1. Set up an AWS Identity and Access Management (IAM) service role that S3 on Outposts can assume to replicate objects on your behalf.
To set up an IAM role, under **IAM role**, do one of the following:
+ To have S3 on Outposts create a new IAM role for your replication configuration, choose **Choose from existing IAM roles**, and then choose **Create new role**. When you save the rule, a new policy is generated for the IAM role that matches the source and destination Outposts buckets that you choose. We recommend that you choose **Create new role**.
+ You can also choose to use an existing IAM role. If you do, you must choose a role that grants S3 on Outposts the necessary permissions for replication. If this role doesn't grant S3 on Outposts sufficient permissions to follow your replication rule, replication fails.
To choose an existing role, choose **Choose from existing IAM roles**, and then choose the role from the dropdown menu. You can also choose **Enter an IAM role ARN** and then enter the IAM role's Amazon Resource Name (ARN).
**Important**
When you add a replication rule to an S3 on Outposts bucket, you must have the `iam:CreateRole` and `iam:PassRole` permissions to be able to create and pass the IAM role that grants S3 on Outposts replication permissions. For more information, see [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*.
1. All objects in Outposts buckets are encrypted by default. For more information about S3 on Outposts encryption, see [Data encryption in S3 on Outposts](s3-outposts-data-encryption.md). Only objects that are encrypted by using server-side encryption with Amazon S3 managed keys (SSE-S3) can be replicated. The replication of objects that are encrypted by using server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS) or server-side encryption with customer-provided encryption keys (SSE-C) is not supported.
1. As needed, enable the following additional options while setting the replication rule configuration:
+ If you want to enable S3 on Outposts replication metrics in your replication configuration, select **Replication metrics**. For more information, see [Monitoring progress with replication metrics](manage-outposts-replication.md#outposts-enabling-replication-metrics).
+ If you want to enable delete marker replication in your replication configuration, select **Delete marker replication**. For more information, see [How delete operations affect replication](S3OutpostsReplication.md#outposts-replication-delete-op).
+ If you want to replicate metadata changes made to the replicas back to the source objects, select **Replica modification sync**. For more information, see [Replication status if Amazon S3 replica modification sync on Outposts is enabled](manage-outposts-replication.md#outposts-replication-status-sync).
1. To finish, choose **Create rule**.
After you save your rule, you can edit, enable, disable, or delete your rule. To do so, go to the **Management** tab for the source Outposts bucket, scroll down to the **Replication rules** section, choose your rule, and then choose **Edit rule**.
## Using the AWS CLI
To use the AWS CLI to set up replication when the source and destination Outposts buckets are owned by the same AWS account, you do the following:
+ Create source and destination Outposts buckets.
+ Enable versioning on both of the buckets.
+ Create an IAM role that gives S3 on Outposts permission to replicate objects.
+ Add the replication configuration to the source Outposts bucket.
To verify your setup, you test it.
**To set up replication when the source and destination Outposts buckets are owned by the same AWS account**
1. Set a credentials profile for the AWS CLI. In this example, we use the profile name `acctA`. For information about setting credential profiles, see [Named profiles](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) in the *AWS Command Line Interface User Guide*.
**Important**
The profile that you use for this exercise must have the necessary permissions. For example, in the replication configuration, you specify the IAM service role that S3 on Outposts can assume. You can do this only if the profile that you use has the `iam:CreateRole` and `iam:PassRole` permissions. For more information, see [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*. If you use administrator credentials to create a named profile, the named profile will have the necessary permission to perform all the tasks.
1. Create a source bucket and enable versioning on it. The following `create-bucket` command creates a `SOURCE-OUTPOSTS-BUCKET` bucket in the US East (N. Virginia) (`us-east-1`) Region. To use this command, replace the `user input placeholders` with your own information.
```
aws s3control create-bucket --bucket SOURCE-OUTPOSTS-BUCKET --outpost-id SOURCE-OUTPOST-ID --profile acctA --region us-east-1
```
The following `put-bucket-versioning` command enables versioning on the `SOURCE-OUTPOSTS-BUCKET` bucket. To use this command, replace the `user input placeholders` with your own information.
```
aws s3control put-bucket-versioning --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/SOURCE-OUTPOST-ID/bucket/SOURCE-OUTPOSTS-BUCKET --versioning-configuration Status=Enabled --profile acctA
```
1. Create a destination bucket and enable versioning on it. The following `create-bucket` command creates a `DESTINATION-OUTPOSTS-BUCKET` bucket in the US West (Oregon) (`us-west-2`) Region. To use this command, replace the `user input placeholders` with your own information.
**Note**
To set up a replication configuration when both the source and destination Outposts buckets are in the same AWS account, you use the same named profile. This example uses `acctA`. To test the replication configuration when the buckets are owned by different AWS accounts, you specify different profiles for each bucket.
```
aws s3control create-bucket --bucket DESTINATION-OUTPOSTS-BUCKET --create-bucket-configuration LocationConstraint=us-west-2 --outpost-id DESTINATION-OUTPOST-ID --profile acctA --region us-west-2
```
The following `put-bucket-versioning` command enables versioning on the `DESTINATION-OUTPOSTS-BUCKET` bucket. To use this command, replace the `user input placeholders` with your own information.
```
aws s3control put-bucket-versioning --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/DESTINATION-OUTPOST-ID/bucket/DESTINATION-OUTPOSTS-BUCKET --versioning-configuration Status=Enabled --profile acctA
```
1. Create an IAM service role. Later in the replication configuration, you add this service role to the `SOURCE-OUTPOSTS-BUCKET` bucket. S3 on Outposts assumes this role to replicate objects on your behalf. You create an IAM role in two steps:
1. Create an IAM role.
1. Copy the following trust policy and save it to a file named `s3-on-outposts-role-trust-policy.json` in the current directory on your local computer. This policy grants S3 on Outposts service principal permissions to assume the service role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"s3-outposts.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. Run the following command to create the role. Replace the `user input placeholders` with your own information.
```
aws iam create-role --role-name replicationRole --assume-role-policy-document file://s3-on-outposts-role-trust-policy.json --profile acctA
```
1. Attach a permissions policy to the service role.
1. Copy the following permissions policy and save it to a file named `s3-on-outposts-role-permissions-policy.json` in the current directory on your local computer. This policy grants permissions for various S3 on Outposts bucket and object actions. To use this policy, replace the `user input placeholders` with your own information.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3-outposts:GetObjectVersionForReplication",
"s3-outposts:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/SOURCE-OUTPOST-ID/bucket/SOURCE-OUTPOSTS-BUCKET/object/*",
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/SOURCE-OUTPOST-ID/accesspoint/SOURCE-OUTPOSTS-BUCKET-ACCESS-POINT/object/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3-outposts:ReplicateObject",
"s3-outposts:ReplicateDelete"
],
"Resource": [
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/DESTINATION-OUTPOST-ID/bucket/DESTINATION-OUTPOSTS-BUCKET/object/*",
"arn:aws:s3-outposts:us-east-1:123456789012:outpost/DESTINATION-OUTPOST-ID/accesspoint/DESTINATION-OUTPOSTS-BUCKET-ACCESS-POINT/object/*"
]
}
]
}
```
------
1. Run the following command to create a policy and attach it to the role. Replace the `user input placeholders` with your own information.
```
aws iam put-role-policy --role-name replicationRole --policy-document file://s3-on-outposts-role-permissions-policy.json --policy-name replicationRolePolicy --profile acctA
```
1. Add a replication configuration to the `SOURCE-OUTPOSTS-BUCKET` bucket.
1. Although the S3 on Outposts API requires a replication configuration in XML format, the AWS CLI requires that you specify the replication configuration in JSON format. Save the following JSON in a file called `replication.json` to the local directory on your computer. To use this configuration, replace the `user input placeholders` with your own information.
```
{
"Role": "IAM-role-ARN",
"Rules": [
{
"Status": "Enabled",
"Priority": 1,
"DeleteMarkerReplication": { "Status": "Disabled" },
"Filter" : { "Prefix": "Tax"},
"Destination": {
"Bucket":
"arn:aws:s3-outposts:region:123456789012:outpost/DESTINATION-OUTPOST-ID/accesspoint/DESTINATION-OUTPOSTS-BUCKET-ACCESS-POINT"
}
}
]
}
```
1. Run the following `put-bucket-replication` command to add the replication configuration to your source Outposts bucket. To use this command, replace the `user input placeholders` with your own information.
```
aws s3control put-bucket-replication --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/SOURCE-OUTPOST-ID/bucket/SOURCE-OUTPOSTS-BUCKET --replication-configuration file://replication.json --profile acctA
```
1. To retrieve the replication configuration, use the `get-bucket-replication` command. To use this command, replace the `user input placeholders` with your own information.
```
aws s3control get-bucket-replication --account-id 123456789012 --bucket arn:aws:s3-outposts:region:123456789012:outpost/SOURCE-OUTPOST-ID/bucket/SOURCE-OUTPOSTS-BUCKET --profile acctA
```
1. Test the setup in the Amazon S3 console:
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the `SOURCE-OUTPOSTS-BUCKET` bucket, create a folder named `Tax`.
1. Add sample objects to the `Tax` folder in the `SOURCE-OUTPOSTS-BUCKET` bucket.
1. In the `DESTINATION-OUTPOSTS-BUCKET` bucket, verify the following:
+ S3 on Outposts replicated the objects.
**Note**
The amount of time that it takes for S3 on Outposts to replicate an object depends on the size of the object. For information about how to see the status of replication, see [Getting replication status information](manage-outposts-replication.md#outposts-replication-status).
+ On the object's **Properties** tab, the **Replication status** is set to **Replica** (identifying this as a replica object).
# Managing your replication
This section describes additional replication configuration options that are available in S3 on Outposts, how to determine the replication status, and how to troubleshot replication. For information about core replication configuration, see [Setting up replication](outposts-replication-how-setup.md).
**Topics**
+ [Monitoring progress with replication metrics](#outposts-enabling-replication-metrics)
+ [Getting replication status information](#outposts-replication-status)
+ [Troubleshooting replication](#outposts-replication-troubleshoot)
+ [Using EventBridge for S3 Replication on Outposts](outposts-replication-eventbridge.md)
## Monitoring progress with replication metrics
S3 Replication on Outposts provides detailed metrics for the replication rules in your replication configuration. With replication metrics, you can monitor in 5-minute intervals the progress of replication by tracking bytes pending replication, replication latency replication, and operations pending. To assist in troubleshooting any configuration issues, you can also set up Amazon EventBridge to receive notifications about replication failures.
When replication metrics are enabled, S3 Replication on Outposts publishes the following metrics to Amazon CloudWatch:
+ **Bytes Pending Replication** – The total number of bytes of objects that are pending replication for a given replication rule.
+ **Replication Latency** – The maximum number of seconds by which the replication destination bucket is behind the source bucket for a given replication rule.
+ **Operations Pending Replication** – The number of operations that are pending replication for a given replication rule. Operations include objects, delete markers, and tags.
**Note**
S3 Replication on Outposts metrics are billed at the same rate as CloudWatch custom metrics. For more information, see [CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/).
## Getting replication status information
The replication status can help you determine the current state of an object that's being replicated by Amazon S3 on Outposts. The replication status of a source object will return either `PENDING`, `COMPLETED`, or `FAILED`. The replication status of a replica will return `REPLICA`.
### Replication status overview
In a replication scenario, you have a source bucket on which you configure replication and a destination bucket to which S3 on Outposts replicates objects. When you request an object (using `GetObject`) or object metadata (using `HeadObject`) from these buckets, S3 on Outposts returns the `x-amz-replication-status` header in the response as follows:
+ When you request an object from the source bucket, S3 on Outposts returns the `x-amz-replication-status` header if the object in your request is eligible for replication.
For example, suppose that you specify the object prefix `TaxDocs` in your replication configuration to tell S3 on Outposts to replicate only objects with the key name prefix `TaxDocs`. Any objects that you upload that have this key name prefix—for example, `TaxDocs/document1.pdf`—will be replicated. For object requests with this key name prefix, S3 on Outposts returns the `x-amz-replication-status` header with one of the following values for the object's replication status: `PENDING`, `COMPLETED`, or `FAILED`.
**Note**
If object replication fails after you upload an object, you can't retry replication. You must upload the object again. Objects transition to a `FAILED` state for issues such as missing replication role permissions or missing bucket permissions. For temporary failures, such as if a bucket or your Outpost is unavailable, the replication status doesn't transition to `FAILED`, but remains `PENDING`. After the resource is back online, S3 on Outposts resumes replicating those objects.
+ When you request an object from a destination bucket, if the object in your request is a replica that S3 on Outposts created, S3 on Outposts returns the `x-amz-replication-status` header with the value `REPLICA`.
**Note**
Before deleting an object from a source bucket that has replication enabled, check the object's replication status to ensure that the object has been replicated.
### Replication status if Amazon S3 replica modification sync on Outposts is enabled
When your replication rules enable S3 on Outposts replica modification sync, replicas can report statuses other than `REPLICA`. If metadata changes are in the process of replicating, the `x-amz-replication-status` header for the replica returns `PENDING`. If replica modification sync fails to replicate metadata, the header for the replica returns `FAILED`. If metadata is replicated correctly, the header for the replica returns the value `REPLICA`.
## Troubleshooting replication
If object replicas don't appear in the destination Amazon S3 on Outposts bucket after you configure replication, use these troubleshooting tips to identify and fix issues.
+ The time it takes S3 on Outposts to replicate an object depends on several factors, including the distance between the source and destination Outposts, and the size of the object.
You can check the source object's replication status. If the object's replication status is `PENDING`, S3 on Outposts hasn't completed the replication. If the object's replication status is `FAILED`, check the replication configuration that you set on the source bucket.
+ In the replication configuration on the source bucket, verify the following:
+ The access point Amazon Resource Name (ARN) of the destination bucket is correct.
+ The key name prefix is correct. For example, if you set the configuration to replicate objects with the prefix `Tax`, then only objects with key names such as `Tax/document1` or `Tax/document2` are replicated. An object with the key name `document3` is not replicated.
+ The status is `Enabled`.
+ Verify that versioning hasn't been suspended on either bucket. Both the source and destination buckets must have versioning enabled.
+ If the destination bucket is owned by another AWS account, verify that the bucket owner has a bucket policy on the destination bucket that allows the source bucket owner to replicate objects. For an example, see [Granting permissions when the source and destination Outposts buckets are owned by different AWS accounts](outposts-replication-prerequisites-config.md#outposts-rep-prethree).
+ If an object replica doesn't appear in the destination bucket, the following issues might prevent replication:
+ S3 on Outposts doesn't replicate an object in a source bucket that is a replica created by another replication configuration. For example, if you set a replication configuration from bucket A to bucket B to bucket C, S3 on Outposts doesn't replicate object replicas in bucket B to bucket C.
If you want to replicate objects in bucket A to bucket B and bucket C, set multiple bucket destinations in different replication rules for your source bucket replication configuration. For example, create two replication rules on source bucket A, with one rule to replicate to destination bucket B and the other rule to replicate to destination bucket C.
+ A source bucket owner can grant other AWS accounts permission to upload objects. By default, the source bucket owner doesn't have permissions for the objects created by other accounts. The replication configuration replicates only the objects for which the source bucket owner has access permissions. To avoid replication issues, the source bucket owner can grant other AWS accounts permissions to create objects conditionally, requiring explicit access permissions on those objects.
+ Suppose that in the replication configuration, you add a rule to replicate a subset of objects that have a specific tag. In this case, you must assign the specific tag key and value at the time that the object is created in order for S3 on Outposts to replicate the object. If you first create an object and then add the tag to that existing object, S3 on Outposts doesn't replicate the object.
+ Replication fails if the bucket policy denies access to the replication role for any of the following actions:
Source bucket:
```
1. "s3-outposts:GetObjectVersionForReplication",
2. "s3-outposts:GetObjectVersionTagging"
```
Destination buckets:
```
1. "s3-outposts:ReplicateObject",
2. "s3-outposts:ReplicateDelete",
3. "s3-outposts:ReplicateTags"
```
+ Amazon EventBridge can notify you when objects don't replicate to their destination Outposts. For more information, see [Using EventBridge for S3 Replication on Outposts](outposts-replication-eventbridge.md).
# Using EventBridge for S3 Replication on Outposts
Amazon S3 on Outposts is integrated with Amazon EventBridge and uses the `s3-outposts` namespace. EventBridge is a serverless event bus service that you can use to connect your applications with data from a variety of sources. For more information, see [What is Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) in the *Amazon EventBridge User Guide*.
To assist in troubleshooting any replication configuration issues, you can set up Amazon EventBridge to receive notifications about replication failure events. EventBridge can notify you in instances when objects don't replicate to their destination Outposts. For more information about the current state of an object that's being replicated, see [Replication status overview](manage-outposts-replication.md#outposts-replication-status-overview).
Whenever certain events happen in your Outposts bucket, S3 on Outposts can send events to EventBridge. Unlike other destinations, you don't need to select which event types that you want to deliver. You can also use EventBridge rules to route events to additional targets. After EventBridge is enabled, S3 on Outposts sends all of the following events to EventBridge.
| Event type | Description | Namespace |
| --- | --- | --- |
| `OperationFailedReplication` | The replication of an object within a replication rule failed. For more information about S3 Replication on Outposts failure reasons, see [Using EventBridge to view S3 Replication on Outposts failure reasons](#outposts-replication-failure-codes). | `s3-outposts` |
## Using EventBridge to view S3 Replication on Outposts failure reasons
The following table lists S3 Replication on Outposts failure reasons. You can configure an EventBridge rule to publish and view the failure reason through Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS), AWS Lambda, or Amazon CloudWatch Logs. For more information about the permissions that are required to use these resources for EventBridge, see [Using resource-based policies for EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html).
| Replication failure reason | Description |
| --- | --- |
| AssumeRoleNotPermitted | S3 on Outposts can't assume the AWS Identity and Access Management (IAM) role that's specified in the replication configuration. |
| DstBucketNotFound | S3 on Outposts can't find the destination bucket that's specified in the replication configuration. |
| DstBucketUnversioned | Versioning isn't enabled on the Outposts destination bucket. To replicate objects with S3 Replication on Outposts, you must enable versioning on the destination bucket. |
| DstDelObjNotPermitted | S3 on Outposts can't replicate deletes to the destination bucket. The s3-outposts:ReplicateDelete permission might be missing for the destination bucket. |
| DstMultipartCompleteNotPermitted | S3 on Outposts can't complete a multipart upload of objects in the destination bucket. The s3-outposts:ReplicateObject permission might be missing for the destination bucket. |
| DstMultipartInitNotPermitted | S3 on Outposts can't initiate a multipart upload of objects to the destination bucket. The s3-outposts:ReplicateObject permission might be missing for the destination bucket. |
| DstMultipartPartUploadNotPermitted | S3 on Outposts can't upload multipart upload objects in the destination bucket. The s3-outposts:ReplicateObject permission might be missing for the destination bucket. |
| DstOutOfCapacity | S3 on Outposts can't replicate to the destination Outpost because the Outpost is out of S3 storage capacity. |
| DstPutObjNotPermitted | S3 on Outposts can't replicate objects to the destination bucket. The s3-outposts:ReplicateObject permission might be missing for the destination bucket. |
| DstPutTaggingNotPermitted | S3 on Outposts can't replicate object tags to the destination bucket. The s3-outposts:ReplicateObject permission might be missing for the destination bucket. |
| DstVersionNotFound | S3 on Outposts can't find the required object version in the destination bucket in order to replicate that object version's metadata. |
| SrcBucketReplicationConfigMissing | S3 on Outposts can't find a replication configuration for the access point that's associated with the source Outposts bucket. |
| SrcGetObjNotPermitted | S3 on Outposts can't access the object in the source bucket for replication. The s3-outposts:GetObjectVersionForReplication permission might be missing for the source bucket. |
| SrcGetTaggingNotPermitted | S3 on Outposts can't access the object tag information from the source bucket. The s3-outposts:GetObjectVersionTagging permission might be missing for the source bucket. |
| SrcHeadObjectNotPermitted | S3 on Outposts can't retrieve object metadata from the source bucket. The s3-outposts:GetObjectVersionForReplication permission might be missing for the source bucket. |
| SrcObjectNotEligible | The object isn't eligible for replication. The object or its object tags don't match the replication configuration. |
For more information about troubleshooting replication, see the following topics:
+ [Creating an IAM role](outposts-replication-prerequisites-config.md#outposts-rep-pretwo)
+ [Troubleshooting replication](manage-outposts-replication.md#outposts-replication-troubleshoot)
## Monitoring EventBridge with CloudWatch
For monitoring, Amazon EventBridge integrates with Amazon CloudWatch. EventBridge automatically sends metrics to CloudWatch every minute. These metrics include the number of [events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) that have been matched by a [rule](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) and the number of times a [target](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) is invoked by a rule. When a rule runs in EventBridge, all of the targets associated with the rule are invoked. You can monitor your EventBridge behavior through CloudWatch in the following ways.
+ You can monitor the available [EventBridge metrics](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html#eb-metrics) for your EventBridge rules from the CloudWatch dashboard. Then, you can use CloudWatch features, such as CloudWatch alarms, to set alarms on certain metrics. If those metrics reach the custom threshold values that you've specified in the alarms, you receive notifications and can take action accordingly.
+ You can set Amazon CloudWatch Logs as a target of your EventBridge rule. Then, EventBridge creates log streams and CloudWatch Logs stores the text from the events as log entries. For more information, see [EventBridge and CloudWatch Logs](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html#eb-cloudwatchlogs-permissions).
For more information about debugging EventBridge event delivery and archiving events, see the following topics:
+ [Event retry policy and using dead-letter queues](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html)
+ [Archiving EventBridge events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-archive-event.html)
# Sharing S3 on Outposts by using AWS RAM
Amazon S3 on Outposts supports sharing S3 capacity across multiple accounts within an organization by using AWS Resource Access Manager ([AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)). With S3 on Outposts sharing, you can allow others to create and manage buckets, endpoints, and access points on your Outpost.
This topic demonstrates how to use AWS RAM to share S3 on Outposts and related resources with another AWS account in your AWS organization.
## Prerequisites
+ The Outpost owner account has an organization configured in AWS Organizations. For more information, see [ Creating an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_create.html) in the *AWS Organizations User Guide*.
+ The organization includes the AWS account that you want to share your S3 on Outposts capacity with. For more information, see [ Sending invitations to AWS accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_invite-account) in the *AWS Organizations User Guide*.
+ Select one of the following options that you want to share. The second resource (either **Subnets** or **Outposts**) must be selected so that endpoints are also accessible. Endpoints are a networking requirement in order to access data stored in S3 on Outposts.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonS3/latest/s3-outposts/outposts-sharing-with-ram.html)
## Procedure
1. Sign in to the AWS Management Console by using the AWS account that owns the Outpost, and then open the AWS RAM console at [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home).
1. Make sure that you have enabled sharing with AWS Organizations in AWS RAM. For information, see [ Enable resource sharing within AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*.
1. Use either Option 1 or Option 2 in the [prerequisites](#outposts-ram-prereqs) to create a resource share. If you have multiple S3 on Outposts resources, select the Amazon Resource Names (ARNs) of the resources that you want to share. To enable endpoints, share either your subnet or Outpost.
For more information about how to create a resource share, see [ Create a resource share](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create) in the *AWS RAM User Guide*.
1. The AWS account that you shared your resources with should now be able to use S3 on Outposts. Depending on the option that you selected in the [prerequisites](#outposts-ram-prereqs), provide the following information to the account user:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonS3/latest/s3-outposts/outposts-sharing-with-ram.html)
**Note**
The user can confirm that the resources have been shared with them by using the AWS RAM console, the AWS Command Line Interface (AWS CLI), AWS SDKs, or REST API. The user can view their existing resource shares by using the [get-resource-shares](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-shares.html) CLI command.
## Usage examples
After you have shared your S3 on Outposts resources with another account, that account can manage buckets and objects on your Outpost. If you shared the **Subnets** resource, then that account can use the endpoint that you created. The following examples demonstrate how a user can use the AWS CLI to interact with your Outpost after you share these resources.
**Example : Create a bucket**
The following example creates a bucket named *amzn-s3-demo-bucket1* on the Outpost `op-01ac5d28a6a232904`. Before using this command, replace each `user input placeholder` with the appropriate values for your use case.
```
aws s3control create-bucket --bucket amzn-s3-demo-bucket1 --outpost-id op-01ac5d28a6a232904
```
For more information about this command, see [create-bucket](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/create-bucket.html) in the *AWS CLI Reference*.
**Example : Create an access point**
The following example creates an access point on an Outpost by using the example parameters in the following table. Before using this command, replace these `user input placeholder` values and the AWS Region code with the appropriate values for your use case.
| **Parameter** | **Value** |
| --- | --- |
| Account ID | 111122223333 |
| Access point name | example-outpost-access-point |
| Outpost ID | op-01ac5d28a6a232904 |
| Outpost bucket name | amzn-s3-demo-bucket1 |
| VPC ID | vpc-1a2b3c4d5e6f7g8h9 |
The Account ID parameter must be the AWS account ID of the bucket owner, which is the shared user.
```
aws s3control create-access-point --account-id 111122223333 --name example-outpost-access-point \
--bucket arn:aws:s3-outposts:us-east-1:111122223333:outpost/op-01ac5d28a6a232904/bucket/amzn-s3-demo-bucket1 \
--vpc-configuration VpcId=vpc-1a2b3c4d5e6f7g8h9
```
For more information about this command, see [create-access-point](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/create-access-point.html) in the *AWS CLI Reference*.
**Example : Upload an object**
The following example uploads the file *`my_image.jpg`* from the user's local file system to an object named *`images/my_image.jpg`* through the access point *`example-outpost-access-point`* on the Outpost *`op-01ac5d28a6a232904`*, owned by the AWS account *`111122223333`*. Before using this command, replace these `user input placeholder` values and the AWS Region code with the appropriate values for your use case.
```
aws s3api put-object --bucket arn:aws:s3-outposts:us-east-1:111122223333:outpost/op-01ac5d28a6a232904/accesspoint/example-outpost-access-point \
--body my_image.jpg --key images/my_image.jpg
```
For more information about this command, see [put-object](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-object.html) in the *AWS CLI Reference*.
If this operation results in a Resource not found error or is unresponsive, your VPC might not have a shared endpoint.
To check whether there is a shared endpoint, use the [list-shared-endpoints](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3outposts/list-shared-endpoints.html) AWS CLI command. If there is no shared endpoint, work with the Outpost owner to create one. For more information, see [ListSharedEndpoints](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3outposts_ListSharedEndpoints.html) in the *Amazon Simple Storage Service API Reference*.
**Example : Create an endpoint**
The following example creates an endpoint on a shared Outpost. Before using this command, replace the `user input placeholder` values for the Outpost ID, subnet ID, and security group ID with the appropriate values for your use case.
The user can perform this operation only if the resource share includes the **Outposts** resource.
```
aws s3outposts create-endpoint --outposts-id op-01ac5d28a6a232904 --subnet-id XXXXXX --security-group-id XXXXXXX
```
For more information about this command, see [create-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3outposts/create-endpoint.html) in the *AWS CLI Reference*.
# Other AWS services that use S3 on Outposts
Other AWS services that run local to your AWS Outposts can also use your Amazon S3 on Outposts capacity. In Amazon CloudWatch the `S3Outposts` namespace shows detailed metrics for buckets within S3 on Outposts, but these metrics don't include usage for other AWS services. To manage your S3 on Outposts capacity that is consumed by other AWS services, see the information in the following table.
| AWS service | Description | Learn more |
| --- | --- | --- |
| Amazon S3 | All direct S3 on Outposts usage has a matching account and bucket CloudWatch metric. | [See metrics](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3OutpostsCapacity.html#S3OutpostsCloudWatchMetrics) |
| Amazon Elastic Block Store (Amazon EBS) | For Amazon EBS on Outposts, you can choose an AWS Outpost as your snapshot destination and store locally in your S3 on Outpost. | [Learn more](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshots-outposts.html) |
| Amazon Relational Database Service (Amazon RDS) | You can use Amazon RDS local backups to store your RDS backups locally on your Outpost. | [Learn more](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.html) |