Optional ReadonlyprefixS3 prefixes the sending role may replicate into, which also bound what it may list. Worth setting whenever the sending side writes under known prefixes, and especially when that side is not MDAA-managed: omitting it lets the external role write anywhere in the bucket and enumerate every key in it. Must cover the prefixes configured on the sending side or those objects fail to replicate.
Use cases: Confining incoming replicas to /data; Limiting what a non-MDAA sender can enumerate
AWS: Resource ARNs on the bucket policy replication grant
Validation: Optional; array of S3 prefixes
ReadonlysourceAWS account ID owning the sending bucket, checked at synth time against the account in sourceReplicationRoleArn so the two cannot silently disagree. Required, and deliberately redundant with the role ARN: stating the trusted account separately is what turns a mistyped ARN into a synth failure rather than a grant to an unintended account.
Use cases: Guarding against a mistyped replication role ARN
AWS: No emitted resource; synth-time validation only
Validation: Required; 12-digit AWS account ID; must match the account in sourceReplicationRoleArn
ReadonlysourceARN of the replication role used by the sending bucket. This role is owned by the sending account, so it is granted by ARN rather than through MDAA's access policies, which resolve role names to IDs in the deploying account only.
Use cases: Granting a partner account's replication role; Granting an MDAA source bucket's replication role
AWS: Principal on the bucket policy and KMS key policy grants
Validation: Required; IAM role ARN
Receiving-side replication settings, granting an externally-owned replication role the access it needs to write replicas into this bucket.
Use cases: Receiving replicas from a non-MDAA bucket; Completing the receiving end of an MDAA-to-MDAA pair
AWS: S3 bucket policy statements and a KMS key policy grant
Validation: sourceReplicationRoleArn and sourceAccount required