Sharing AWS Outposts in a multi account AWS environment: Part 1

This post is written by Karl Schween, Principal Solutions Architect at AWS.

This post is part one 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 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 will learn different models for sharing Outpost resources with your workload account to align with your operating model. This post aligns your AWS Outposts deployment to a recommended multi-account AWS environment as defined by the Organizing Your AWS Environment Using Multiple Accounts AWS Whitepaper.

In part two, ‘Sharing AWS Outposts in a multi account AWS environment: Part 2’, you will learn different models for sharing Amazon S3 on Outposts 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.

Benefits of using multiple AWS accounts and AWS Outposts

Using multiple accounts plays an important role in how you meet your business, governance, security, and operational requirements for AWS Outposts. You can group workloads based on business purpose and ownership by sharing Outpost resources to distinct accounts using AWS Resource Access Manager (AWS RAM). Sharing your Outpost helps you align the ownership and decision-making with individual accounts, as well as avoid dependencies and conflicts with how Outpost-hosted workloads are secured and managed. You achieve AWS resource independence and isolation by using distinct accounts to provide security and access boundaries for an Outpost. This isolation boundary provides you with a way to limit the scope of impact from adverse events, including the misconfiguration of an Outpost impacting workload resources. By sharing Outpost resources with other accounts, you inherit the isolation properties of these accounts, letting you apply distinct security controls by environment or profile to the workload and constrain access to sensitive data.

When you’re building a workload targeted for deployment on Outposts, in the early stages of a workload’s lifecycle you can continue to provide builders with separate accounts in support of experimentation, development, and early testing within the AWS Region. Using an AWS Region for these early stages helps to minimize the consumption of Outpost resources targeted or deployed for production. You can make decisions for sharing Outpost capacity to support any stages of the workload lifecycle that require low-latency access to on-premises systems, local data processing, or data residency. Outpost sharing helps support multiple IT operating models, using multiple accounts to apply distinct governance and operational controls relevant to the operating model for data residency and latency sensitive workloads.

Billing and metering for AWS Outposts is linked to the owner account, where the Outpost was created. When you share Outpost resources with a distinct account that represents the billing boundary for a workload, you can manage costs using cost allocation tags applied to workload resources to identify Outpost usage. Maintain consistent tags for Outpost consumer accounts using AWS Organizations tag policies.

AWS Outposts with AWS Organizations

Deploying your Outpost into a multi-account environment managed by AWS Organizations helps you centrally govern your environment as you grow and scale your workloads on AWS Outposts. This post content refers to the Basic organization with infrastructure services pattern from the Organizing Your AWS Environment Using Multiple Accounts AWS Whitepaper as the starting point for an Outpost deployment inside of the Organization.

As an AWS Outposts customer, you can create and manage Outpost resources centrally, as well as share the resources across one or more AWS accounts within your organization. Create or move an account for this purpose under the Infrastructure OU in your organization with the name shared-infra-outposts. The account where you create your Outpost is defined as the Outpost owner account. It is where you will assign responsibility for your Outpost.

View Amazon CloudWatch metrics for AWS Outposts in the owner account. From the owner account, you can also view metrics related to Outpost capacity usage for individual accounts by using the ‘Account’ metric dimension to filter metrics. AWS services launched on an Outpost generate Amazon CloudWatch metrics in the consumer AWS account where the related Outposts resource is shared. For more visibility into the consumer or owner account Amazon CloudWatch metrics, add cross-account functionality to your CloudWatch console. This functionality provides cross-account visibility to your dashboards, alarms, metrics, and automatic dashboards without having to log in and out of different accounts.

Share Outpost resources with AWS accounts under the organization Workloads OU. Accounts under the Workloads OU are intended to house most of your business-specific workloads, including both production and non-production environments. You launch supported AWS services on an Outpost in an Outpost consumer account to create a business-specific workload that requires, low latency access to on-premises systems, local data processing, or data residency. Later in this post, I share to individual account principals inside of the organization for granular control of which workload account can launch AWS services on the shared Outpost. As an Outpost owner, you can also share with an Organizational Unit or an entire organization in AWS Organizations.

For data residency use-cases, you may consider applying Service Control Policies (SCPs) to restrict the usage of the AWS Region. This lets workload resources only be launched on the Outpost. We recommend you apply security guardrails to OUs rather than accounts and apply SCPs to a nested OU that you create under the Workloads OU. Consider each AWS service deployed on the Outpost and associated service data that may reside in the AWS Region. The Outpost parent AWS Region may be in a different country from where the Outpost is deployed. You can check an Outpost’s installation address by viewing the Site ID in the Outposts console.

The Security OU Log Archive Account is recommended as the consolidation point for log data that is gathered from both Outpost owner and consumer accounts, including AWS CloudTrail Logs. When viewing these access logs, you must consider the account ID of the event. When launching an AWS service on a shared Outpost, the account ID from which the launching API call is issued is the Outpost consumer account. Consider the nature of the log data collected for an AWS service launched on the Outpost. You may need to filter operational log data in the context of the Outpost use-case.

The following diagram shows AWS Organizations with AWS Outposts owner and consumer account locations inside of the organization.

Sharable AWS Outposts resources

To launch supported AWS services on an Outpost from your distinct workload account, share your Outpost across your organization using AWS Resource Access Manager (AWS RAM). Working with shared AWS Outposts resources, you share from the owner account to one or more consumer accounts. We recommend creating a separate AWS RAM resource share for each shareable Outpost resource to maintain a boundary of responsibility to discrete AWS account principals in your Organization. We also recommend labeling your resource shares using tag key-value pairs to help you identify the owner and context.

Before sharing an Outpost resource with a consumer account, identify the account or workload owners and establish an operating model for the shared Outpost. Shared Outpost resource permissions include permissions for both owners and consumers, which you align with your operating model. Sharing an Outpost resource grants the specified consumer account principal the AWS RAM default managed permission for the resource type that was shared. View permission details, including the JSON policy text, using the AWS CLI get-permission command.

When removing a consumer account from an AWS RAM resource share, request that the workload owners remove any AWS services launched on the Outpost. AWS services already launched on the Outpost persist even when the account no longer has access to the shared resource. This includes the ability to restart and stop Amazon Elastic Compute Cloud (EC2) instances, as well as increase the capacity of attached EBS volumes. When using Amazon Simple Storage Service (S3) on Outposts, request that owners remove any buckets or objects, as these persist after the consumer account is removed from an Amazon S3 on Outposts resource share. An Amazon S3 on Outposts consumer can continue to use an existing bucket, where they can add and manage objects subject to Amazon S3 permissions. If a consumer account leaves the Organization, then the consumer account ID principal is removed from the owner account resource share automatically.

The “Outposts” resource

When sharing an Outpost with member accounts in your organization, we recommend sharing the Outpost resource ‘Outposts’. Sharing the ‘Outposts’ resource lets you list the supported Amazon EC2 instance types and brings Outpost context to the AWS management console for the supported AWS services that you launch. The ‘Outposts’ resource is required for selected AWS services to use an Outpost. This includes creating Outpost subnets or deploying an Application Load Balancer on Outposts.

To create an Outpost resource share

The following AWS CLI example creates a resource share named MyOutpostShare. Replace <your-region>, <outpost-owner-account-id>, <outpost-id>, <outpost-consumer-account-id>, <your-tag-key>, and <your-tag-value> with your own information.

PROMPT> aws ram create-resource-share \
--name MyOutpostShare \
--permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionOutpostsOutpost \
--resource-arns arn:aws:outposts:<your-region>:<outpost-owner-account-id>:outpost/<outpost-id> \
--no-allow-external-principals \
--principals <outpost-consumer-account-id> \
--tags key=<your-tag-key>,value=<your-tag-value>

PROMPT> aws ram create-resource-share \
--name MySubnetShare \
--permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionSubnet \
--resource-arns arn:aws:ec2:<your-region>:<outpost-subnet-owner-account-id>:subnet/<subnet-id> \
--no-allow-external-principals \
--principals <outpost-consumer-account-id> \
--tags key=<your-tag-key>,value=<your-tag-value>

PROMPT> aws ram create-resource-share \
--name MyLocalgatewayroutetableShare \
--permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionLocalGateway \
--resource-arns arn:aws:ec2:<your-region>:<outpost-owner-account-id>:local-gateway-route-table/<local-gateway-route-table-id>\
--no-allow-external-principals \
--principals <outpost-consumer-account-id> \
--tags key=<your-tag-key>,value=<your-tag-value>

PROMPT> aws ram create-resource-share \
--name MyCapacityReservationShare \
--permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionCapacityReservation \
--resource-arns arn:aws:ec2:<your-region>:<outpost-owner-account-id>:capacity-reservation/<capacity-reservation-id> \
--no-allow-external-principals \
--principals <workload-account-id> \
--tags key=<your-tag-key>,value=<your-tag-value>