Run applications on premises and access Amazon S3 objects from AWS Outposts

Today we are excited to announce support for direct local access to S3 on Outposts buckets. You can now run applications in an on-premises network and access objects from S3 on Outposts buckets running on your AWS Outposts.

Common use cases for S3 on Outposts involve localized data ingest, processing, and data residency. For example, a workload may entail ingesting data generated locally as input to pre-processing workflows, ML inference, or other analytics workloads hosted on the Outpost. Customers also look to S3 on Outposts for local hosting of datasets for latency sensitive applications or in bandwidth constrained environments.

Previously, S3 on Outposts customers used S3 Access Points and virtual private cloud (VPC) only endpoints to interact with their S3 on Outposts buckets. While this design addresses a wide range of local data processing and data residency use-cases, many of our customers asked for more ways to interact with their S3 on Outposts data. For example, in local processing workflows, customers are running parts of their workloads in on-premises servers that require S3 on Outposts buckets to be accessible outside the Outposts VPC.

Now, using customer owned IP (CoIP) addresses and the Outposts Local Gateway (LGW) you have a natively supported way to provide external local clients access to S3 on Outposts buckets. S3 on Outposts has supported private mode endpoints and S3 Access Points for providing access to data hosted in S3 on Outposts. Now, CoIP mode endpoints compliment standard VPC-only endpoints and let you address an expanded set of local data processing use cases using S3 on Outposts.

In this blog post, I take a deeper look at how this new access mode works and how to get started using CoIP mode access points.

S3 on Outposts CoIP Access Points

Getting started with S3 on Outposts requires an active Outpost configured with one of the available S3 on Outposts storage capacity tiers.

Similar to the architecture of VPC-only access, CoIP enabled access also uses S3 on Outposts endpoints. These endpoints represent four or more cross-account elastic network interfaces attached to service managed EC2 instances in a single subnet of a VPC extended to your Outpost. S3 on Outposts endpoints are named resources with Amazon Resource Names (ARNs) and can be associated with one or more VPC-specific access points. Endpoints must be configured with a security group enabling the required network access permissions. Data access is then enabled by associating an S3 on Outposts bucket with an S3 Access Point configured with a policy appropriate for the required access pattern.

With CoIP access mode, these endpoints are configured with addresses from the CoIP pool instead of private VPC addresses. As in standard VPC-only mode, data access is enabled after both an endpoint security group and an access point configured with an appropriate policy are associated with an S3 on Outposts bucket.

These two high-level diagrams highlight the differences between the two access modes:

Figure 1. S3 on Outposts Private Mode

Figure 2. S3 on Outposts COIP Mode

Here are a few points to consider prior to configuring CoIP mode access points:

• Endpoints are VPC-specific and only one type can exist per VPC (either private or CoIP).
• For CoIP access mode, the S3 on Outposts endpoint must be deployed in a VPC that is associated with the Outposts LGW route table.
• The VPC subnet hosting the endpoint must have a routing table entry allowing routing to on-premises endpoints through the Outposts LGW.
• At least four addresses must be available in the CoIP pool.
• One or more access points must be deployed in the same VPC as the endpoint.
• An endpoint can be replaced, but not modified following creation.
• Although CoIP endpoints are accessible from within the VPC, private mode endpoints are designed for internal VPC traffic.
• Review the S3 on Outposts restrictions and limitations for additional detail.

Environment overview

Now let’s look at the configuration workflow. Here’s the representative architecture I am building with S3 on Outposts CoIP access mode enabled.

Configuration

I opted to use Terraform, a popular infrastructure as code software tool developed by Hashicorp to provision the prerequisite resources needed for the CoIP enabled S3 on Outposts environment. In case you are new to Terraform, Hashicorp hosts a plethora of getting started tutorials. Also, we have several helpful references as well on the AWS Partner blog.

Here’s a breakdown of the resources I will provision with Terraform. Data sources were used extensively throughout to define all required input variables.

1. VPC with a single private Outposts subnet.
2. Association between newly created VPC and the Outposts Local Gateway routing table.
3. Routing table entry for Outposts private subnet, Default route to LGW for on-premises workloads.
4. Security Group for S3 Endpoint: HTTPS access from within newly created VPC, and from on premises address range.

VPC and Subnets

#Deploying VPC that will contain all resources
resource "aws_vpc" "s3blog-op-vpc" {
    cidr_block              = "10.115.0.0/16"
    enable_dns_support      = "true" 
    enable_dns_hostnames    = "true"
    enable_classiclink      = "false"
    instance_tenancy        = "default"}

#Deploying subnet resource to Outposts in "s3blog-op-vpc" VPC
resource "aws_subnet" "s3blog-op-subnet" {
    vpc_id                          = aws_vpc.s3blog-op-vpc.id
    cidr_block                      = "10.115.10.0/24"
    map_public_ip_on_launch         = "false"
    availability_zone               = data.aws_outposts_outpost.s3blog-op.availability_zone
    outpost_arn                     = data.aws_outposts_outpost.s3blog-op.arn}

#Associating "s3blog-op-vpc" VPC with the Outposts local gateway
resource "aws_ec2_local_gateway_route_table_vpc_association" "s3blog-op-subnet-lgwrta" {
    vpc_id                          = aws_vpc.s3blog-op-vpc.id
    local_gateway_route_table_id    = data.aws_ec2_local_gateway_route_table.s3blog-op-lgwrt.id

Routing Table entries and associations

#Routing table for Outposts subnet in Outposts VPC
resource "aws_route_table" "s3blog-op-subnet-rt" {
    vpc_id = aws_vpc.s3blog-op-vpc.id}

#Route for private subnet to on-premise
resource "aws_route" "s3blog-op-onprem" {
    route_table_id  = aws_route_table.s3blog-op-subnet-rt.id
    destination_cidr_block  = "0.0.0.0/0"
    gateway_id = data.aws_ec2_local_gateway.s3blog-op-lgw.id}

#Associating route table to Outposts subnet
resource "aws_route_table_association" "s3blog-op-subnet-rta" {
    route_table_id = aws_route_table.s3blog-op-subnet-rt.id
    subnet_id = aws_subnet.s3blog-op-subnet.id}

Security Group

#HTTPS from VPC and on-premise access to S3 Endpoint
resource "aws_security_group" "s3blog-sg-ep" {
    name        = "s3blog-sg-ep"
    description = "Security group for S3 blog endpoint"
    vpc_id      = aws_vpc.s3blog-op-vpc.id

    ingress {
        description = "Https from within VPC"
        from_port   = 443
        to_port     = 443
        protocol    = "tcp"
        cidr_blocks = [aws_vpc.s3blog-op-vpc.cidr_block]}

    ingress {
        description = "Https from on-prem"
        from_port   = 443
        to_port     = 443
        protocol    = "tcp"
        cidr_blocks = [var.On-premCIDR]}

With these infrastructure building blocks provisioned and online, I am ready to work through the S3 on Outposts configuration.

I start by using Terraform to create a bucket on the Outpost:

#Creating an S3 bucket on the Outpost
resource "aws_s3control_bucket" "s3blog-bucket" {
    bucket = "s3blog-bucket"
    outpost_id = data.aws_outposts_outpost.s3blog-op.id
}

Next, I transition to the AWS Management Console and walk through the updated configuration experience for CoIP mode access points.

Start by entering a name for the access point, for this demo I’ve chosen “s3blog-ap.” Selecting an Outpost will provide an option to associate the access point with a bucket (if any have been provisioned to the Outpost). Here I’ve selected the “s3blog-bucket” created earlier via Terraform.

Next, select the VPC in which the access point will be provisioned. I’ve selected the VPC provisioned earlier via Terraform. This enables endpoint configuration options if no endpoint exists within the selected VPC. You must specify the destination subnet and security group. Again I’ve selected both the subnet and security group created earlier via Terraform. Additionally, you must choose the endpoint access type, and for CoIP mode, provide the appropriate CoIP pool in which the endpoint will be provisioned.

Lastly, although the access point can be created without specifying an access point policy, access will not be enabled until a policy is attached. The wizard shows the ARN of the to-be created access point. This can be used in the resource section of a policy statement. Here I’ve attached a sample policy that allows users with a specific assumed role named “S3-Outposts-User” access to the access point.

Once submitted, an endpoint can take up to 5 minutes to be created. Once all configurations are complete, I can begin interacting with objects stored in S3 on Outposts buckets. Keep in mind the Amazon S3 console doesn’t support using access points to access objects in your Outposts bucket. You will use the AWS CLI, AWS SDK, or Amazon S3 REST API to access S3 on Outposts bucket resources. Learn more.

Additional detail on how to work with objects using S3 on Outposts can be found in the S3 user guide. The same CLI syntax is used to interact with objects stored in S3 on Outposts for both private and CoIP mode access points.

Here’s an example of a put-object request originating from local clients using the newly created CoIP enabled access point.

aws s3api put-object --bucket arn:aws:s3-outposts:us-east-1:1234567890:outpost/op-1234567890/accesspoint/s3blog-ap --key testkey --body sample-object.xml

That’s it! I am now able to store and retrieve objects locally using CoIP enabled access points.

Conclusion

Together, S3 endpoints and access points can easily be extended to support a range of local data access patterns. In this example workflow, I created a local S3 on Outposts bucket that can only be accessed by a subset of local users with a specific assumed role. This is enabled in part by network access controls defined in the endpoint attached security group and the IAM policy attached to the S3 Access Point. More detail on the security controls available with Outposts can be found in this Architecting for Data Residency on AWS Outposts tech talk.

Lastly, here are a few additional resources to continue learning with Outposts.

• AWS Outposts
• Amazon S3 on Outposts
• User Guide: Using Amazon S3 on Outposts