1

Generally, S3 permissions from other services are managed via a Bucket Policy for example: allowing Cloudtrail to send logs to S3.

However, for CRR (Cross-Region replication) or SRR (Same-Region replication), AWS thought of using Roles for S3 permissions - I was just thinking what could be the reason why they never went for putting Bucket Policies each on Source and Target buckets allowing the Principal as "Principal": {"Service": "s3.amazonaws.com"}

Could this be just a design preference from AWS or does it solve any other potential challenges?

Andrzej Sydor
  • 1,373
  • 4
  • 13
  • 28
  • 1
    One reason could be because its cleaner and easier this way. With bucket policies you would need to create two of them (one for source and one for dest). This is more work. Also you would clutter and obfuscate existing bucket policies. With role there is only 1 IAM entity to manage and create, and your bucket policies are clean or empty. By the way, for replication to different account, bucket policy is required on destination anyway. – Marcin Oct 05 '20 at 09:14
  • That explanation really helps !@Marcin – Abhishek Palakkal Kaliyath Oct 05 '20 at 09:15
  • Maybe there is a better, more technical explanation. Maybe someone can a concrete answer. – Marcin Oct 05 '20 at 09:19

0 Answers0