AwsCustomResource: deploying S3 ReplicationConfiguration for existing bucket

[luukau]

ENV: Node 18 / AWS CDK 2.104.0

Based on the responses to #10348, I am using AwsCustomResource to configure S3 Replication on an existing source bucket. The source bucket was created using a different stack and has no knowledge of the target buckets that need to be replicated to, within same account but different region(s).

I use the following construct:

interface S3ReplicatorProps {
  replicatorAccountID: string;
  replicatorBucket: s3.IBucket;
  replicatorRoleArn: string;
  replicatorRules: object[];
}

export class S3Replicator extends Construct {
  constructor(
    scope: Construct,
    id: string,
    props: S3ReplicatorProps
  ) {
    super(scope, id);

    const onCreate: AwsSdkCall = {
      service: "S3",
      action: "putBucketReplication",
      parameters: {
        Bucket: props.replicatorBucket.bucketName,
        ReplicationConfiguration: {
          Role: props.replicatorRoleArn,
          Rules: props.replicatorRules
        },
        ExpectedBucketOwner: props.replicatorAccountID,
      },
      physicalResourceId: PhysicalResourceId.of(
        `s3replicator:${props.replicatorBucket.bucketName}`
      ),
    };

    const onUpdate = onCreate;

    const onDelete: AwsSdkCall = {
      service: "S3",
      action: "deleteBucketReplication",
      parameters: {
        Bucket: props.replicatorBucket.bucketName,
        ExpectedBucketOwner: props.replicatorAccountID,
      },
    };

    const customResource = new AwsCustomResource(
      this,
      "bucket-replicator",
      {
        policy: AwsCustomResourcePolicy.fromStatements([
          new iam.PolicyStatement({
            effect: iam.Effect.ALLOW,
            resources: [
              props.replicatorBucket.bucketArn, 
              props.replicatorBucket.bucketArn + "/*"
            ],
            actions: [
              "s3:PutReplicationConfiguration",
              "s3:Replicate*"
            ],
          }),
        ]),
        logRetention: RetentionDays.ONE_DAY,
        onCreate,
        onUpdate,
        onDelete,
      }
    );
  }
}

Which I employ like this:

new S3Replicator(this, "s3-replication", {
        replicatorAccountID: <account-ID>,
        replicatorBucket: sourceCodepipelineBucket,
        replicatorRoleArn: replicatorRole.roleArn,
        replicatorRules: replicationRules
      })

The CDK synth step works fine, however if I run a deploy I encounter the following error during:

replication-stack | 8/11 | 1:57:22 AM | CREATE_FAILED | Custom::AWS | s3-replication/bucket-replicator/Resource/Default (s3replicationbucketreplicator2AA4C9F1) Received response status [FAILED] from custom resource. Message returned: Access Denied (RequestId: )

Currently the source bucket has a fairly open permission policy in order to see if that makes any difference whilst deploying the stack with the above construct. I have also tried to 'loosen' the policy for the above AwsCustomResource, but both to no avail.

Additionally using the following replication rule

const replicationRules = [{
      ID: 'replicate-to-region-x',
      Destination: {
        Bucket: targetBucket.bucketArn,
        // Same account just different region
        Account: props.config.AWSAccountID,
        EncryptionConfiguration: {
          ReplicaKmsKeyID: s3EncryptionKeyArn,
        },
        AccessControlTranslation: {
          Owner: "Destination"
        },
      },
      Status: "Enabled",      
      SourceSelectionCriteria: {
        SseKmsEncryptedObjects: {
          Status: 'Enabled',
        },
      },
      DeleteMarkerReplication: {
        Status: "Enabled"
      },
      Filter: {
        Prefix: replicationObjectPrefix
      },
      Priority: 1
    }
]

I have been wrecking my brain over this. It must be something (obvious) I am overlooking ... any ideas?

[luukau]

Okay so I found a solution for my problem, just in case someone else is running into the same:

In Stack A, I create a property of type CfnBucket that can be consumed by another stack, like so.

export class StackA extends Stack {
  public readonly cfnSourceBucket: s3.CfnBucket;

  const sourceBucket = new s3.Bucket(
      this,
      ...
    );

   this.cfnSourceBucket = sourceBucket.node.defaultChild as s3.CfnBucket;
   ...
}

Stack B:

interface StackBProps extends cdk.StackProps {
  cfnSourceBucket: s3.CfnBucket;
  ...
}

export class StackB extends cdk.Stack {
  constructor(scope: Construct, id: string, props: StackBProps) {
    super(scope, id, props);
   
   ...
    props.cfnSourceBucket.replicationConfiguration = {
      role: replicatorRole.roleArn,
      rules: replicationRules
    }
    ...
  }
}

Which now allows me to use it this way when deploying Stack B:

...
      const deployStackB = new StackB(
        app,
        "stackB",
        {
          env: ....
          cfnSourceCodeBucket: securityStack.cfnSourceCodeBucket,
        }
      );
...

Maybe not the most elegant, but it works..... moving on ;)

[avirtual]

Been living the same hell, I'll give your solution a go and hopefully I can move on as well.

[avirtual]

It works if the source buckets were created with explicit bucketNames (not letting cloudformation generate a suffix), because the CF stack in the replication region won't be able to determine the names of the CfnBuckets otherwise. To solve this i had to do some fairly ugly workarounds.

1. Make cfnBuckets accessible in the original stack.
2. Create stack in the replication region (will create the destination buckets and an empty replication role). The buckets have to have explicit bucketNames, so no CF suffixes.
3. Create another stack in the source region that will add the required policies to the replication role, create the replication configuration and attach it to the original buckets (using the cfnBucket from the original stack)

The third stack was required because in my case the original stack is handling nearly 500 resources, so I can't really add more to it. If you don't have this issue you might get away with just two stacks, assuming you can modify/redeploy the original stack. If that is the case, you don't even need to 'export' cfnBuckets from the original stack, you just add a dependency to the new stack and then create the replication policies/configuration using whatever the new stack has created.