能否不使用Bucket Policy实现跨AWS账户复制S3 Bucket内容?
Absolutely! You don’t need bucket policies to copy objects between S3 buckets across AWS accounts—there are several reliable, IAM-focused approaches that let you do this without touching either bucket’s policy configuration. These methods are often more granular and secure than bucket policies since they tie permissions directly to specific IAM entities (users, roles, or EC2 instance profiles).
Method 1: Grant Cross-Account IAM Permissions Directly
This approach involves giving a single IAM entity (from either account) permissions to read from the source bucket and write to the target bucket, all via IAM policies (no bucket policies required).
Step-by-Step Breakdown:
- Source Account (Account A): Create or update an IAM user/role to allow reading from the source bucket:
- Attach this policy to your IAM entity:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::your-source-bucket", "arn:aws:s3:::your-source-bucket/*" ] } ] }
- Attach this policy to your IAM entity:
- Target Account (Account B): Update your IAM policy to explicitly allow the Account A IAM entity to write to the target bucket:
- Create a policy that references the ARN of the Account A entity, then attach it to an IAM role (or directly to a resource, but roles are cleaner):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::ACCOUNT-A-ID:user/your-source-user"}, "Action": ["s3:PutObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::your-target-bucket", "arn:aws:s3:::your-target-bucket/*" ] } ] }
- Create a policy that references the ARN of the Account A entity, then attach it to an IAM role (or directly to a resource, but roles are cleaner):
- Execute the Copy: Use the Account A entity's credentials to run the copy command. For example, with AWS CLI:
aws s3 sync s3://your-source-bucket s3://your-target-bucket
Method 2: Use Cross-Account IAM Roles
If you prefer not to expose long-term credentials for cross-account access, use AWS STS to assume a role in the target account. This uses temporary credentials, which is more secure.
Step-by-Step Breakdown:
- Target Account (Account B): Create an IAM role that trusts your source account's entity:
- Trust Policy: Allows the Account A entity to assume this role:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::ACCOUNT-A-ID:user/your-source-user"}, "Action": "sts:AssumeRole" } ] } - Permissions Policy: Grants the role write access to the target bucket:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:PutObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::your-target-bucket", "arn:aws:s3:::your-target-bucket/*" ] } ] }
- Trust Policy: Allows the Account A entity to assume this role:
- Source Account (Account A): Update your IAM entity's policy to allow assuming the Account B role:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::your-source-bucket", "arn:aws:s3:::your-source-bucket/*" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::ACCOUNT-B-ID:role/your-cross-account-write-role" } ] } - Execute the Copy:
- First, assume the target account role to get temporary credentials:
aws sts assume-role --role-arn arn:aws:iam::ACCOUNT-B-ID:role/your-cross-account-write-role --role-session-name s3-copy-session - Set the returned temporary credentials as environment variables, then run the sync:
export AWS_ACCESS_KEY_ID="TEMP_ACCESS_KEY" export AWS_SECRET_ACCESS_KEY="TEMP_SECRET_KEY" export AWS_SESSION_TOKEN="TEMP_SESSION_TOKEN" aws s3 sync s3://your-source-bucket s3://your-target-bucket
- First, assume the target account role to get temporary credentials:
Key Notes
- Encryption Considerations: If your source objects use SSE-KMS, you’ll need to add
kms:Decryptpermissions to your source account entity andkms:Encrypt(if using a different KMS key) to the target account role. - Granularity: Both methods let you restrict permissions to specific prefixes or object types, which is harder to do with bucket policies.
- No Bucket Policy Changes: Neither approach requires modifying the bucket policy on either source or target bucket—all permissions are managed in IAM.
内容的提问来源于stack exchange,提问作者Shi

