Giving Different AWS Accounts Access to the Same S3 Data With Access Grants

Sharing S3 data across AWS accounts is common in organizations that separate workloads by team, environment, business unit, or customer.

The difficult part is usually not storing the data. The hard part is managing access without creating a large set of bucket policies, IAM roles, and cross-account permissions that become hard to maintain.

S3 Access Grants provides a way to introduce a more structured access layer between users or applications and S3 data. Instead of putting every access rule directly into a bucket policy, you can define which identities or groups should receive access to particular S3 locations.

This is useful when multiple AWS accounts need access to the same data, but the organization still wants centralized control over who can read or write what.

The Cross-Account S3 Access Problem

Imagine an organization with three AWS accounts:

Data Account
    |
    +-- S3 Bucket
        +-- finance/
        +-- analytics/
        +-- reports/

Application Account
    |
    +-- Data processing workloads

Analytics Account
    |
    +-- BI and reporting workloads

The S3 bucket lives in the Data Account, while applications that need the data run in other accounts.

A traditional approach might involve:

Bucket Policy
      |
      +-- Account A
      +-- Account B
      +-- Account C
      +-- Role X
      +-- Role Y
      +-- Role Z

As the number of teams and workloads increases, this becomes harder to maintain.

You also need to understand both sides of the permission model:

Identity-based permissions
        +
Resource-based bucket permissions
        =
Effective access

A configuration error on either side can prevent access or accidentally expose more data than intended.

What S3 Access Grants Changes

S3 Access Grants introduces a permission model that can map identities and groups to specific S3 data locations.

Instead of thinking only in terms of:

Who can access the bucket?

you can think in terms of:

Who can access this particular S3 location?

For example:

Finance Team
    |
    +-- s3://company-data/finance/

Analytics Team
    |
    +-- s3://company-data/analytics/

Reporting Application
    |
    +-- s3://company-data/reports/

This model becomes particularly useful when access needs to be managed at a more granular level than the bucket itself.

A Typical Cross-Account Architecture

A simplified architecture might look like this:

                 AWS Organization
                       |
          +------------+------------+
          |                         |
          v                         v
   Data Account              Application Account
          |                         |
          |                         |
      S3 Bucket                Workload
          ^                         |
          |                         |
          +------ Access Grants ---+

The data remains in the account that owns the S3 bucket.

The application runs in another account.

The access configuration determines which S3 locations that application can use.

This separation is useful because the team operating the application does not necessarily need ownership of the underlying data.

Start With the S3 Data Layout

Before configuring Access Grants, design the S3 data hierarchy.

For example:

s3://company-data/
    finance/
        invoices/
        payments/
    analytics/
        raw/
        processed/
    reports/
        daily/
        monthly/

Avoid putting unrelated data into the same logical location simply because it is convenient.

Access control becomes easier when the S3 prefix structure reflects actual ownership or access boundaries.

For example:

finance/
analytics/
reports/

provides clearer boundaries than a flat structure such as:

data/
file1.csv
file2.csv
file3.csv

The storage layout should support the authorization model.

Create the Access Grants Instance

S3 Access Grants uses an Access Grants instance associated with an AWS Region.

The exact console and API workflow can change as AWS evolves the service, so use the current AWS documentation when configuring the environment.

Conceptually, the configuration looks like:

Access Grants Instance
        |
        +-- Registered Location
        |
        +-- Access Grant
                |
                +-- Grantee
                |
                +-- S3 Location
                |
                +-- Permission

The important idea is that access is represented as a grant rather than being encoded entirely into a large bucket policy.

Register the S3 Location

The next step is to register the S3 location that Access Grants will manage.

For example:

s3://company-data/finance/

or:

s3://company-data/analytics/

This creates a clear relationship between the Access Grants configuration and the underlying S3 data.

You can think about it as:

Registered Location
        |
        +-- Bucket
        |
        +-- Prefix

The prefix is important because access can be scoped to a particular part of the bucket.

Define the Grantee

The grantee represents the identity that should receive access.

Depending on the architecture, this can be an IAM user, IAM role, or identity associated with a supported identity provider.

For cross-account applications, IAM roles are generally the more practical model.

For example:

Application Account
        |
        +-- AnalyticsAppRole

The role can then be associated with the required S3 data location.

This creates a useful separation:

Application Account
    |
    +-- Identity
            |
            v
      Access Grant
            |
            v
     S3 Data Location

Grant Only the Required Permission

Access should be limited to what the application actually needs.

For example, a reporting application might only need read access:

Permission:
    READ

A data processing workload may need:

Permission:
    READ
    WRITE

Avoid giving write access just because the application may need it later.

A useful permission model is:

This makes the access model easier to review.

Configure the Cross-Account IAM Role

The application account still needs an IAM role that the workload can assume.

For example:

Application Account
        |
        v
AnalyticsAppRole
        |
        v
Application

The role should be dedicated to the application rather than shared by unrelated workloads.