Sharing AWS Outposts in a multi account AWS environment: Part 2
This post is written by Karl Schween, Principal Solutions Architect at AWS.
This post is part two of two part series ‘Sharing AWS Outposts in a multi account AWS environment’ providing you guidance and considerations for sharing AWS Outposts and Amazon S3 on Outposts in a multiple AWS Account environment.
AWS Outposts is a fully managed service that extends AWS infrastructure, services, and tools to virtually any data center, co-location space, or on-premises facility for a truly consistent hybrid experience. With AWS Outposts, you can run some AWS services locally and connect to a broad range of services available in the local AWS Region. Amazon S3 on Outposts delivers object storage to your on-premises AWS Outposts environment to meet local data processing and data residency needs. Using the S3 APIs and features, S3 on Outposts makes it easy to store, secure, tag, retrieve, report on, and control access to the data on your Outpost. Outposts supports workloads and devices requiring low latency access to on-premises systems, local data processing, data residency, and application migration with local system interdependencies.
In this post, you will learn different models for sharing Amazon S3 on Outposts with your workload account to align with your operating model. You will learn how to create an AWS RAM resource share for ‘S3 on Outposts’ applying shared S3 on Outposts resource for your workload.
In part one, ‘Sharing AWS Outposts in a multi account AWS environment: Part 1’, you learnt the benefits of using multiple accounts for Outposts, where to place Outposts inside your AWS Organizations organization and approaches to share Outpost resources across your AWS accounts. You learnt different models for sharing Outpost resources with your workload account to align with your operating model.
This post uses AWS Command Line Interface (CLI) examples. To utilize these, you must first install and configure the AWS CLI. For more information, see Installing the AWS CLI.
Amazon S3 on Outposts
With Amazon S3 on Outposts, you can create S3 buckets on your AWS Outposts and store and retrieve objects on premises for applications that require local data access, local data processing, and data residency. When sharing Amazon S3 on Outposts, your resource management can be streamlined to help reduce operational overhead, provide consistency for sharing resources, and provide visibility into shared accounts usage. By using AWS RAM, you share the ‘S3 on Outposts’ resource to let your builders create, manage, and access Amazon S3 on Outposts buckets and objects from their workload account.
When sharing, consider the S3 on Outposts specifications, including that the S3 on Outposts bucket owner account is always the owner of all of the objects in the bucket, and only the S3 on Outposts bucket owner account can perform operations on the bucket. S3 on Outposts requires an Outpost subnet. You can use an Outpost subnet shared with your consumer account or create the Outpost subnet in an Amazon VPC in your consumer account.
S3 on Outposts access points are named network endpoints that are attached to buckets that you can use to perform Amazon S3 object operations. When you create an access point for an S3 on Outposts bucket, you create the access point in the same account where you created the S3 on Outposts bucket. You can’t use an access point created in a different account to the one where you created the bucket.
S3 on Outposts endpoints route requests to an S3 on Outposts access point. You can create one Outpost endpoint per Amazon VPC, and this endpoint can be assigned to only one Outpost subnet. Endpoints for the same Outpost can be created only from Amazon VPCs that have non-overlapping CIDR blocks. To allow Amazon S3 API actions to S3 on Outposts buckets and objects, you must configure ingress rules on port 443/tcp in the security group assigned to the endpoint.
If you receive the response ‘The Outposts endpoint couldn’t be created’ when creating an endpoint using the AWS CLI s3outposts create-endpoint command, then check for existing Outposts endpoints across all of the accounts that the Outpost is shared with for overlapping VPC CIDR blocks. If you receive the response ’Endpoint with this VPC id already exists’, then check for existing endpoints for the VPC using the AWS CLI s3outposts list-endpoints command.
After you create an S3 on Outpost bucket in your consumer account using a shared Outpost subnet, you will use the endpoint already created for the Amazon VPC owned by the account sharing the Outpost subnet. When creating the bucket using the shared Outpost subnet with the Amazon S3 console, you can expect to see the message ‘Outposts endpoint unknown for shared resource
<your-vpc-id>’. Viewing the bucket in the console, you will notice the Outpost access point associated Outpost endpoint is listed as ‘Endpoint unknown’. This is expected, as the Outpost endpoint is in the account that owns the shared Outpost Subnet.
Using Amazon CloudWatch Amazon S3 on Outposts CloudWatch metrics, you can monitor S3 on Outposts in the owner account. To list the available metrics, you can use the AWS CLI list-metrics command specifying the namespace “AWS/S3Outposts”. From the owner account, you can view the metric AccountUsedBytes to determine the total size of all of the objects for a specified consumer account. From the consumer account, you can view the metric BucketUsedBytes to determine the total size of all of the objects for the given bucket. Furthermore, you can view the metric OutpostFreeBytes to determine the count of free bytes of S3 on Outposts capacity.
To create an AWS RAM resource share for ‘S3 on Outposts’
The following AWS CLI example creates a resource share named MyS3onOutpostsShare. Replace
<your-region>, <outpost-owner-account-id>, <outpost-id>, <outpost-consumer-account-id>, <your-tag-key>, and <your-tag-value> with your own information.