AWS S3 API Access to Other Users' Storage

Amazon Simple Storage Service (S3) is a highly scalable, durable, and secure object storage service provided by Amazon Web Services (AWS). In many real - world scenarios, you may need to access the S3 storage of other AWS users. This could be for data sharing, collaboration, or integration between different AWS accounts. The AWS S3 API provides a powerful way to achieve this. In this blog post, we will explore the core concepts, typical usage scenarios, common practices, and best practices related to accessing other users' S3 storage using the AWS S3 API.

Table of Contents#

  1. Core Concepts
  2. Typical Usage Scenarios
  3. Common Practices
  4. Best Practices
  5. Conclusion
  6. FAQ
  7. References

Article#

Core Concepts#

AWS S3 Buckets and Objects#

An S3 bucket is a container for objects. Objects are the files and their associated metadata that you store in S3. Each bucket has a unique name globally across all AWS accounts. When accessing another user's S3 storage, you are essentially interacting with their buckets and objects.

AWS IAM (Identity and Access Management)#

AWS IAM is used to manage access to AWS services and resources securely. To access another user's S3 storage, proper IAM permissions need to be set up. The owner of the S3 bucket (the resource owner) can grant permissions to other AWS accounts (the requester) using IAM policies. There are two main types of policies involved:

  • Bucket Policies: These are JSON - based access policies attached directly to the S3 bucket. They can be used to grant cross - account access. For example, the bucket owner can specify which AWS accounts are allowed to access the bucket and what actions they can perform.
  • IAM User or Role Policies: The requester can also have IAM policies attached to their users or roles that define the permissions to access the other user's bucket.

AWS STS (Security Token Service)#

AWS STS is used to request temporary, limited - privilege credentials. In some cases, instead of using long - term access keys, the requester can use STS to obtain temporary credentials to access the other user's S3 storage. This provides an extra layer of security as the credentials have a limited lifespan.

Typical Usage Scenarios#

Data Sharing between Departments#

In a large organization, different departments may have separate AWS accounts. For example, the marketing department may need to access data stored in an S3 bucket owned by the analytics department. By using the S3 API with proper permissions, the marketing department can access and analyze the data without having to transfer it to their own account.

Third - Party Data Integration#

A software company may need to access data stored in an S3 bucket owned by a third - party data provider. The data provider can grant the necessary permissions to the software company's AWS account, allowing the company to use the S3 API to retrieve and process the data for their application.

Disaster Recovery#

If a company has multiple AWS accounts for disaster recovery purposes, the secondary account may need to access the S3 buckets in the primary account. This ensures that in case of a disaster in the primary account, the secondary account can access the necessary data for recovery operations.

Common Practices#

Bucket Policy Configuration#

The bucket owner can create a bucket policy to grant cross - account access. Here is an example of a bucket policy that allows another AWS account to list the objects in a bucket:

{
    "Version": "2012 - 10 - 17",
    "Statement": [
        {
            "Sid": "CrossAccountListObjects",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::example - bucket"
        }
    ]
}

In this example, the account with the ID 123456789012 is allowed to list the objects in the example - bucket.

IAM Role Creation and Assume Role#

The requester can create an IAM role in their own account with the necessary permissions to access the other user's S3 bucket. The bucket owner can then configure their bucket policy to trust this role. The requester can use the AWS STS AssumeRole API to obtain temporary credentials for the role. Here is an example of using the AWS SDK for Python (Boto3) to assume a role:

import boto3
 
sts_client = boto3.client('sts')
 
assumed_role_object = sts_client.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/ExampleRole',
    RoleSessionName='ExampleSession'
)
 
credentials = assumed_role_object['Credentials']
 
s3_client = boto3.client(
    's3',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken']
)

Best Practices#

Least Privilege Principle#

Only grant the minimum permissions necessary for the requester to perform their tasks. For example, if the requester only needs to read objects from the bucket, do not grant write or delete permissions.

Regularly Review and Rotate Credentials#

If using long - term access keys, rotate them regularly. When using STS for temporary credentials, ensure that the token expiration time is set appropriately based on the usage requirements.

Enable S3 Bucket Logging and Monitoring#

Enable S3 bucket logging to track all access requests to the bucket. Use AWS CloudWatch to monitor the access patterns and detect any abnormal activities.

Conclusion#

Accessing other users' S3 storage using the AWS S3 API is a powerful feature that enables data sharing and collaboration across different AWS accounts. By understanding the core concepts such as S3 buckets, IAM, and STS, and following the typical usage scenarios, common practices, and best practices, software engineers can securely and effectively access the required data.

FAQ#

Q: Can I access another user's S3 bucket without their permission?#

A: No, you need proper permissions from the bucket owner. The bucket owner can grant permissions using bucket policies or by trusting IAM roles in your account.

Q: How long do STS temporary credentials last?#

A: The duration of STS temporary credentials can be configured. The minimum duration is 15 minutes, and the maximum is 12 hours.

Q: What if the bucket owner revokes the permissions while I have active STS credentials?#

A: Once the permissions are revoked, the STS credentials will no longer be able to access the bucket. The next time you try to access the bucket, you will receive an access denied error.

References#

2025-10