Scaling data access with Amazon S3 Access Grants

To adhere to the principle of least privilege, users define granular access to their Amazon Simple Storage Service (Amazon S3) data based on applications, personas, groups or organization units (OUs). This practice helps customers to mitigate the risk of unauthorized access, limiting potential damage in case of a security breach as employees only have access to the resources essential for their tasks, preventing inadvertent data mishandling. Furthermore, customers want comprehensive auditability to track and analyze user activities with precision. This capability is essential for compliance with regulatory requirements and internal governance standards, enabling swift detection of any anomalous behavior or security incidents.

Amazon Web Services (AWS) recently announced a new feature, Amazon S3 Access Grants, that allows users to map identities in directories such as Microsoft Entra (previously known as Microsoft Azure AD) and Okta to datasets in Amazon S3. This helps users manage data permissions at scale by automatically granting the right Amazon S3 access to end-users based on their corporate identities. S3 Access Grants can also be used with AWS Identity and Access Management (IAM) as an easy and scalable way to complement existing resource-level controls in Amazon S3, such as S3 bucket policies. Additionally, S3 Access Grants log end-user identity, as well as the application used to access Amazon S3 data, in AWS CloudTrail. This helps provide a detailed audit history for all access to the data in your S3 buckets.

In this post, we provide an overview of S3 Access Grants and S3 Access Grants constructs, and we show an example of how to use S3 Access Grants based on an example access pattern. This includes how to use S3 Access Grants with IAM principals, and how to use it for users or groups from your corporate directory.

Achieving granular access at scale

Currently, users have various approaches to achieve granular access to data in Amazon S3, depending on the scale and complexity of the access patterns.

The method for achieving granular access to Amazon S3 data varies based on the scale and complexity of access patterns. For smaller datasets, users often use IAM permission policies and bucket policies, provided that they stay within the policy size limits. As the number of datasets and use cases grows, an alternative option is using Amazon S3 access points, offering more policy space by allowing thousands of access points per AWS Region per account. However, this approach needs additional logic to discover the right access point for the dataset, and is suitable for static access patterns. For complex and sophisticated evaluation of the data permissions, a third approach implements an “IAM Session Broker” pattern, where users handle the logic for access decisions and generate short-term IAM session credentials dynamically. Although this method supports scalability, it needs users to design and implement the access pattern logic themselves.

In all the preceding approaches, there is some management overhead in mapping Amazon S3 data access to users and groups, and auditing access. S3 Access Grants and IAM Identity Center’s new Trusted Identity Propagation remove this undifferentiated heavy-lifting of managing Amazon S3 granular access to users and groups from the users.

S3 Access Grants enables users to define simple permissions, such as read-only, write-only, or read-write access at a bucket, prefix, or object level. Then, users can assign IAM principals to S3 Access Grants, or they can use the integration with AWS IAM Identity Center to assign access to users and groups from their corporate directory. When using the IAM Identity Center integration, users can bring their corporate applications that authenticate users to a directory, and with a few lines of code to integrate with the IAM Identity Center API, they can enable those applications to access data on Amazon S3 on behalf of each authenticated user. In addition, with the IAM Identity Center integration, the user identity is logged with all access to Amazon S3 data, which enables the auditing of who accessed what.

Is S3 Access Grants appropriate for your use case?

Many permissions use cases in Amazon S3 can be implemented simply and effectively with IAM policies, both on IAM principals and S3 buckets. For smaller-scale use cases, we recommend that approach. S3 Access Grants simplify management of data permissions in S3 in situations such as the following:

• Large numbers of datasets in Amazon S3 and/or grantees that IAM or S3 bucket policy character limits become a concern.
• The permission scheme more naturally fits users/groups-to-datasets pattern, wherein it is more straightforward to assign grants directly to directory groups than to require users to assume intermediate IAM roles to gain access.
• More complex, many-to-many mappings of users to data, for example cases in which an individual user is a member of multiple groups and therefore needs access to a union of datasets in Amazon S3.

Before we dive deep into the workings of S3 Access Grants, let’s understand different constructs of S3 Access Grants.

Amazon S3 Access Grants – Concepts

S3 Access Grants introduces a few concepts for its simplified access scheme. We start by defining them.

S3 Access Grants instance: An S3 Access Grants instance is a logical grouping of individual grants that defines who has what level of access to what Amazon S3 data. There is one instance per AWS Region in a single AWS account. This account-and regional-level instance of S3 Access Grants can control access to all buckets in the same account and AWS Region. If you intend to use S3 Access Grants to grant access to external directory users and groups, then you must associate your S3 Access Grants instance with your IAM Identity Center instance. If you intend to grant access to IAM principals in other AWS accounts, you will use a resource-based policy on the S3 Access Grants instance to allow those cross-account API calls.

Locations: S3 Access Grants works by vending IAM credentials with access scoped to a particular Amazon S3 prefix. An S3 Access Grants location is associated with an IAM role from which these temporary sessions are created. The most common configuration is a single location at s3:// for all S3 Access Grants, which can cover access to all S3 buckets in the AWS Region and account; S3 Access Grants calls this a “default” location. Customers with more advanced use cases that call for the use of multiple different IAM roles can create multiple S3 Access Grants locations to do that.

Grant: An individual grant in S3 Access Grants allows a specific entity – an IAM principal, a directory user, or a directory group – access to an S3 bucket, prefix, or object. For example, you might have a grant allowing a particular directory group, 01234567-89ab-cdef-0123-456789abcdef READ access to s3://DOC-EXAMPLE-BUCKET/projects/foo/*, which would grant users in that group read access to everything under projects/foo/ in that bucket.

S3 Access Grants temporary credentials: An application requests just-in-time access credentials by calling a new Amazon S3 API, GetDataAccess, requesting permissions to a single object, prefix, or bucket, and a permission level of READ, WRITE, or READWRITE. The S3 Access Grants feature evaluates the request against the configured grants. If there is a matching grant, then it assumes the IAM role associated with the location of the matching grant, which scopes the permissions to the permissions of the IAM session precisely to the Amazon S3 prefix of the grant. The expiration time of the access credentials defaults to one hour, but it can be set to any value from 15 minutes to 36 hours.

Let’s try to understand these constructs with an example. In the first section, we explain the scenario and follow it with an implementation of S3 Access Grants for the scenario.

Amazon S3 Access Grants – Set-up

To understand how S3 Access Grants map to the example we are illustrating, we call the IAM roles developerRole and analystRole. Importantly, roles are not really people — these are roles that people or services could assume. Later, we show you how to use IAM Identity Center so that the access is truly based on users and groups.

Access pattern scenario

In the following diagram, a default Amazon S3 location with scope for s3:// is defined with the s3ag-location-role IAM role. This IAM role has permissions to perform Amazon S3 actions within the account. S3 Access Grants uses this IAM role to create temporary credentials upon request for access.

Now, we want to define the following access. An IAM role, developerRole, should have both READ and WRITE access on developer/ prefix. Another IAM role, analystRole, should be allowed only READ access on analysis/ prefix. An S3 Access Grant, on the left (colored in blue), is defined for developerRole to access the prefix developer/ under DOC-BUCKET-EXAMPLE bucket. An S3 Access Grant, on the right (colored in green), is defined for analystRole to access the prefix analysis/ under DOC-BUCKET-EXAMPLE bucket, as shown in Figure 1.

Figure 1: Overview of S3 Access Grants

As show in Figure 1, when it’s time for Bob to read data, they use their developerRole IAM role to call the S3 Access Grants GetDataAccess API. If they request the READ permission to any Amazon S3 prefix or object that starts with s3://DOC-BUCKET-EXAMPLE/developer/, then GetDataAccess returns a set of temporary IAM session credentials with permission to s3://DOC-BUCKET-EXAMPLE/developer/*. Similarly, they can ask for WRITE access, because the grant also allows that.

Similarly, Alice can use the analystRole IAM role to call GetDataAccess to request READ access to anything in Amazon S3 that starts with s3://DOC-BUCKET-EXAMPLE/analysis/, and S3 Access Grants returns the appropriately-scoped IAM session credentials. However, if they request WRITE permission, they get an Access Denied error, since there is no grant giving them write access to the data. Furthermore, if Alice requests any level of access to data under s3://DOC-BUCKET-EXAMPLE/developer/ or Bob requests any level of access to data under s3://DOC-BUCKET-EXAMPLE/analysis/, then that too gets an Access Denied.

You can have up to one hundred thousand grants and one thousand locations per S3 Access Grants instance. Rather than editing long and complex S3 bucket policies each time an individual user-prefix access relationship is added or removed, you can instead add and remove discrete grants for each such relationship.

Setup of the access pattern scenario

Now that you understand the basic concepts of S3 Access Grants, let’s walk through how to create the grants we showed in the previous section. For this example, we will assume that the IAM roles developerRole and analystRole, as well as the S3 bucket DOC-EXAMPLE-BUCKET, already exist.

1. Creating an S3 Access Grants instance: To create the S3 Access Grants instance, run the following command.

aws s3control create-access-grants-instance --account-id 123456789012

2. Creating an S3 Access Grants location: The next step is to create the S3 Access Grants location. To do that, you need an IAM role to assign to the location that has a trust to the S3 Access Grants service and allows access to the Amazon S3 resource. Call this IAM role s3ag-location-role.

i. S3 Access Grants IAM role:
To allow S3 Access Grants to generate credentials, you must create an IAM role and associate it with the location. The IAM role trust policy must allow the service principal access-grants.s3.amazonaws.com to execute the following actions:
– sts:AssumeRole – To generate IAM credentials with the requester identity
– sts:SetSourceIdentity – Needed when using grants with IAM roles grantees
– sts:SetContext – Needed when using grants with DIRECTORY_USER/DIRECTORY_GROUP grantees

Create a file called trust-policy.json, and copy and paste the below content in the file:
//trust-policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "access-grants.s3.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:SetContext"
            ]
        }
    ]
}

Run the following command after that:

aws iam create-role --role-name s3ag-location-role \
        --assume-role-policy-document file://trust-policy.json

ii. Create an IAM policy to attach Amazon S3 permissions to the IAM role.

Create a file called iam-policy.json
//iam-policy.json

{
   "Version":"2012-10-17",
   "Statement": [
       {
         "Sid": "ObjectLevelReadPermissions",
         "Effect":"Allow",
         "Action":[
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:GetObjectAcl",
            "s3:GetObjectVersionAcl",
            "s3:ListMultipartUploadParts"
         ],
         "Resource":[ 
            "arn:aws:s3:::*"  
         ],
         "Condition":{
            "StringEquals": { "aws:ResourceAccount": "{{accountId}}" },
            "ArnEquals": {
                "s3:AccessGrantsInstanceArn": ["arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"]
            }
        } 
      },
      {
         "Sid": "ObjectLevelWritePermissions",
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:PutObjectAcl",
            "s3:PutObjectVersionAcl",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion",
            "s3:AbortMultipartUpload"
         ],
         "Resource":[
            "arn:aws:s3:::*"  
         ],
         "Condition":{
            "StringEquals": { "aws:ResourceAccount": "{{accountId}}" },
            "ArnEquals": {
                "s3:AccessGrantsInstanceArn": ["arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"]
            }
         } 
      },
      {
         "Sid": "BucketLevelReadPermissions",
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket"
         ],
         "Resource":[
            "arn:aws:s3:::*"
         ],
         "Condition":{
            "StringEquals": { "aws:ResourceAccount": "{{accountId}}" },
            "ArnEquals": {
                "s3:AccessGrantsInstanceArn": ["arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"]
            }
         }     
      },
      {
         "Sid": "KMSPermissions",
         "Effect":"Allow",
         "Action":[
            "kms:Decrypt",
            "kms:GenerateDataKey"
         ],
         "Resource":[
            "*"
         ]
      }
   ]
}

NOTE: You need to change this IAM policy to replace the placeholders {{accountId}}, {{region}}, and {{instanceId}} with the information from your account, AWS Region, and access grants instance ID respectively. The above policy is for the default location. If you are creating a non-default location, update the location list in the resource element of the policy.

Run the following command after that:

aws iam put-role-policy --role-name s3ag-location-role --policy-name s3ag-location-role --policy-document file://iam-policy.json

iii. Create an S3 Access Grants location

Now that you have created an IAM role, you can create the default S3 Access Grants location for your account and associate it with that IAM role.

aws s3control create-access-grants-location \
--account-id 123456789012 \
--location-scope s3:// \
--iam-role-arn arn:aws:iam::123456789012:role/s3ag-location-role

Setting the location-scope to s3:// is the recommended option when creating the Access Grants location. By doing so, you are telling S3 Access Grants to use the s3ag-location-role to vend credentials for all GetDataAccess requests.

Accessing Amazon S3 data using S3 Access Grants (same account scenario)

1. Creating access grants:

Now you can create the grants that give the IAM roles developerRole and analystRole access to developer/ and analysis/ prefixes respectively. At this point you can create two grants. One to give the developerRole read-write access to s3://DOC-EXAMPLE-BUCKET/developer/* and another one to give the analystRole read-only access to s3://DOC-EXAMPLE-BUCKET/analysis/*.

Creating a READWRITE S3 Access Grants for developerRole on developer/ prefix.

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/developer/*" \
--permission READWRITE \
--grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/developerRole

Creating a READ S3 Access Grants for analystRole on analysis/ prefix.

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/analysis/*" \
--permission READ \
--grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/analystRole

Because you are giving developerRole and analystRole IAM roles access to Amazon S3 prefixes through S3 Access Grants, you do not need to give them direct permissions such as s3:GetObject actions to the data. Instead, the only permission that each needs is s3:GetDataAccess, i.e., the ability to request access to the data from S3 Access Grants. In other words, S3 Access Grants evaluates which of these IAM roles has access to which sets of data.

Here is an example IAM policy needed for the IAM roles developerRole and analystRole:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetDataAccess"
            ],
            "Resource": [
                "arn:aws:s3:us-east-2:123456789012:access-grants/default"
            ]
        }
    ]
}

The grants for the developer and analyst IAM roles are now in place. Next, we’re going to show you how Bob, using the developerRole, can make use of that grant to read data in Amazon S3.

2. Requesting temporary credentials:

Using the developerRole, Bob will make an API request to S3 Access Grants GetDataAccess API.

aws s3control get-data-access \
--account-id 123456789012 \
--target s3://DOC-EXAMPLE-BUCKET/bob/developer/* \
--permission READ

S3 Access Grants evaluates the request based on the principal who made the request, the target and the permission requested. As long as the target requested matches any grant that starts with this bucket and prefix, S3 Access Grants will return a success response. This success response does not return data from S3; rather, it returns a set of IAM credentials for a session that has access to that data. For the preceding request, the GetDataAccess API will succeed because the caller, developerRole, has a grant to the target s3://DOC-EXAMPLE-BUCKET/developer/*, which matches the request (s3://DOC-EXAMPLE-BUCKET/developer/).

The response will be similar to this:

{
    "Credentials": {
        "AccessKeyId": "ASIACKCEVSQ6C2EXAMPLE",
        "SecretAccessKey": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
        "SessionToken": "<SessionTokenString...>",
        "Expiration": "2023-11-07T17:34:37+00:00"
    },
    "MatchedGrantTarget": "s3://DOC-EXAMPLE-BUCKET/developer/*"
}

The preceding success response contains temporary IAM session credentials. Using those credentials, the application can make Amazon S3 requests, for example Amazon S3’s GetObject API, to access any object(s) under s3://DOC-EXAMPLE-BUCKET/developer/ until those credentials expire. In other words, an S3 Access Grants application generally should not be requesting access to each object individually. Instead, it should reuse the credentials for all access under the matched grant until the credentials expire.

Any request to GetDataAccess that matches this grant will result in the same MatchedGrantTarget in a success response. For example, if Bob requests READ access to s3://DOC-EXAMPLE-BUCKET/developer/reports/file.txt, that also matches the grant, so S3 Access Grants succeed. By default, that success response includes temporary IAM session credentials to access everything under the matched grant, which is s3://DOC-EXAMPLE-BUCKET/developer/. For most S3 Access Grants use cases, in which the application is likely to make many subsequent requests to more objects under the same prefix, this is the desired behavior. However, in the less common case that the application wants a narrower scope of access, the optional “privilege” parameter can be set to the value “minimal.” In that case, S3 Access Grants return temporary IAM session credentials that only have access to the specifically requested object.

Here are some examples of GetDataAccess requests and responses for developerRole. For this example, assume that there are two grants for developerRole:

• A READ grant to s3://DOC-EXAMPLE-BUCKET/developer/*
• A READ grant to s3://DOC-EXAMPLE-BUCKET/developer/reports/*

Let’s see how privilege works for the grant to developerRole.

In the preceding example, we illustrated the working of S3 Access Grants by providing role-based access on two prefixes in Amazon S3. With just two IAM roles and two datasets in S3, this pattern is easy enough to implement using direct IAM permission techniques, and you would not need S3 Access Grants for it. However, as IAM roles, prefixes in Amazon S3, and access mappings increase in number and complexity, S3 Access Grants starts to have a manageability advantage. It allows you to manage these individual permissions one-by-one, rather than with in-place edits to monolithic IAM policy documents that can get complex to edit at scale. In particular, if some of these IAM roles are in different AWS accounts from the bucket, the limit on the S3 bucket policy size is a factor in how many different access patterns can be supported.

The next section describes how to set up S3 Access Grants for access across AWS accounts.

Accessing Amazon S3 data using S3 Access Grants (cross-account scenario)

The S3 Access Grants instance supports resource-based policies. Therefore, with the right resource-based policies in place, S3 Access Grants can also be used to grant access to IAM principals in other AWS accounts.

In this example, we intend to support grants to AWS account 111111111111. Because we are expecting IAM principals in AWS account 111111111111 to make requests to s3:GetDataAccess as they access data in S3, we are authorizing this action to be taken cross-account. The permissions shown here for s3:ListAccessGrants and s3:ListAccessGrantsLocations will be needed, if you expect this account to list S3 Access Grants, and use them to access data.

//s3ag-policy.json

{
 "Version": "2012-10-17",
 "Statement": [{
  "Effect": "Allow",
          "Principal": {
             "AWS": "111111111111"
          },
  "Action": [
        "s3:ListAccessGrants",
        "s3:ListAccessGrantsLocations",
        "s3:GetDataAccess"
        ],
   "Resource": "arn:aws:s3:us-east-2:123456789012:access-grants/default"
    }
  ]
}

To assign this policy document to your S3 Access Grants instance, you can run the following command:

aws s3control put-access-grants-instance-resource-policy \
--account-id 123456789012 \
--policy file://s3ag-policy.json \
--region us-east-2

This policy on the S3 Access Grants instance is a normal resource-based policy, and it supports everything that the IAM policy language supports. Although you could have granted access to specific IAM principals in account 111111111111, for example using the aws:PrincipalArn condition, generally you would not need to do that here. Instead, within the S3 Access Grants instance, you would write granular grants for individual IAM principals from that account. These are easier to manage individually in S3 Access Grants than doing so in a resource-based policy.

Below is a diagram with a cross-account grant permission to the testingRole, from account 1111111111.

Figure 2: Access Grants with cross-account access

So far, we have talked about using S3 Access Grants to grant access to IAM principals, both in the same and different AWS accounts. An especially powerful feature comes by way of S3 Access Grants’ integration with IAM Identity Center: the ability to make grants directly to directory users and groups. You might make these grants, for example, if you have corporate applications through which your organization’s users access data. By granting access directly to users and groups, these applications no longer need to map users to IAM roles as they might have had to do before. In the next section, we will show you how to use S3 Access Grants with directory users and groups.

Accessing S3 data using S3 Access Grants for directory users

If you use S3 Access Grants with AWS IAM Identity Center, you can give users access to locations based on the user or their group membership in your corporate directory. IAM Identity Center gives you a single place in the AWS cloud where you can bring in the users you have and make them available for assignments to AWS managed applications and AWS accounts. When you connect S3 Access Grants to IAM Identity Center, your users can access Amazon S3 data through applications that use S3 Access Grants to offer a single sign-on experience. These users do not need to understand or use IAM roles directly. Another benefit of this is that the users’ identity is logged in each AWS CloudTrail data event for S3, simplifying the audit task of determining who (which user) accessed data.

Before you can use S3 Access Grants this way, you must first set up AWS IAM Identity Center. For more information, see Manage workforce identities. The key things to know are:

1. You can connect a supported identity provider to IAM Identity Center and use your existing users and groups, or create users and groups in IAM Identity Center.
2. You must provision the users and groups who will use S3 Access Grants, into IAM Identity Center. If you use an external identity provider, this is best accomplished using the System for Cross-domain Identity Management (SCIM) protocol.
3. Your users will need to access the data by way of an AWS service or application that is also integrated with IAM Identity Center. Refer to this blog post to learn how to build an application that gives its users a single sign-on experience to access data sets through S3 Access Grants.

Please visit Enabling AWS IAM Identity Center for more information on setting up IAM Identity Center.

Here, we will show you how to create the grants in S3 Access Grants for corporate users and groups.

Once you have enabled IAM Identity Center, configured your identity source, and provisioned users, you will be ready to grant access directly to users and groups. The steps for that are as follows:

1. Associate S3 Access Grants with IAM Identity Center

This step enables you to refer to IAM Identity Center users and groups in the access grants. This can also be done with one click in the S3 Access Grants console.

aws s3control associate-access-grants-identity-center \
--account-id 123456789012 \
--identity-center-arn arn:aws:sso:::instance/ssoins-1234567890abcdef

2. Create grants for users and groups from IAM Identity Center
To create an S3 Access Grant to a specific user or group from Identity Center, you must find the GUID in IAM Identity Center. Below, we are showing you where to find this value in the IAM Identity Center console. In our example, the user “Rafael” has the GUID 83d43802-00b1-7054-db02-f1d683aacba5 in IAM Identity Center.

Figure 3: Identity Center user information with User ID

Another way to find the GUID of an IAM Identity Center user is via API requests to the Identity Store API, through either the AWS CLI, or programmatically using the AWS SDK. Here is the documentation for the identity store APIs.

For example, this command will list the users in IAM Identity Center with their names and identifiers.

aws identitystore list-users --identity-store-id d-1a2b3c4d1234

This command returns GUID for the user.

aws identitystore get-user-id --region us-east-2 --cli-input-json '{ 
"IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { 
"AttributePath": "UserName", "AttributeValue": "rafael" } } }'

This command will list the groups in IAM Identity Center.

aws identitystore list-groups --identity-store-id d-1a2b3c4d1234

And this command returns the GUID for the group named “TeamA”.

aws identitystore get-group-id --region us-east-2 --cli-input-json '{ 
"IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { 
"AttributePath": "DisplayName", "AttributeValue": "TeamA" } } }'

Granting S3 Access Grants permission to directory users and groups from IAM Identity Center is similar to granting access to IAM principals. The grantee type will be DIRECTORY_USER or DIRECTORY_GROUP, and the grantee identifier will be the GUID that IAM Identity Center users to identify the user or group.

For example, we used get-user-id to get the GUID for Rafael, and the command below will give access to his user id 83d43802-00b1-7054-db02-f1d683aacba5 with the scope DOC-EXAMPLE-BUCKET/rafael/*.

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/rafael/*" \
--permission READWRITE \
--grantee GranteeType=DIRECTORY_USER,GranteeIdentifier=83d43802-00b1-7054-db02-f1d683aacba5 \

Conclusion

In this post, you learned how S3 Access Grants can help you scale your data access to Amazon S3 through grants. These grants not only support IAM principals but also allow direct granting of access to users and groups from a corporate directory that is synchronized with IAM Identity Center.

S3 Access Grants provides a more flexible and scalable mechanism to define access patterns at scale than IAM-based techniques. With its integration with IAM Identity Center Trusted Identity Propagation, you can now develop data applications that authenticate users and access data in Amazon S3 on behalf of each individual authenticated user. It also simplifies audit, as the end-user’s identity appears in the AWS CloudTrail data events for Amazon S3.

To learn more about S3 Access Grants, visit the documentation.