feat(efs): replicating file systems

[badmintoncryer]

Issue # (if applicable)

Closes #21455.

Reason for this change

EFS supports replicating file systems but AWS CDK cannot configure it.

Description of changes

Add replicationConfiguration to FileSystemProps

declare const vpc: ec2.Vpc;
declare const kmsKey: kms.Key;

// auto generate a replication destination file system
new efs.FileSystem(this, 'ReplicationSourceFileSystem1', {
  vpc,
  replicationConfiguration: {
    kmsKey, // optional
    region: 'us-east-1', // optional
    availabilityZone: 'us-east-1a', // optional, Specifing the AZ means creating a One Zone file system as the replication destination
  }
});

// specify the replication destination file system
const destinationFileSystem = new efs.FileSystem(this, 'DestinationFileSystem', {
  vpc,
  // set as the read-only file system for use as a replication destination
  replicationOverwriteProtection: efs.ReplicationOverwriteProtection.DISABLED,
});

new efs.FileSystem(this, 'ReplicationSourceFileSystem2', {
  vpc,
  replicationConfiguration: {
    destinationFileSystem,
    // cannot configure other properties when destinationFileSystem is specified
  }
});

Description of how you validated changes

I have added both unit and integ tests.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[lpizzinidev]

Thanks 👍 I left some initial comments for some refactoring.
Please let me know if you have suggestions for further improvements.

[lpizzinidev]

Why aren't we allowing multiple destinations? (CFN declaration)

[badmintoncryer]

CloudFormation supports an array of destinations, but the maximum number of elements is restricted to 1. Therefore, I did not implement support for multiple destinations.

Should I add support for it to accommodate future expansion?

[lpizzinidev]

Tricky question.
I guess we can keep it like this for now and deprecate it in the future in favor of an array of configurations if necessary.

[badmintoncryer]

I've updated to receive replicationConfiguration as array.

[badmintoncryer]

I apologize for misunderstanding your opinion.. Which implementation will you adopt?

[TheRealAmazonKendra]

So what I would do here is actually make this an enum like class to future proof us against if/when the service team does allow for multiple regions. My suggestion would be to make ReplicationConfiguration a class with static functions like the Schedule class. For now, we'll only have one function that takes in one replicationConfiguration, but in the future we can add more functions for multiple.

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[badmintoncryer]

@gracelu0 I've updated my implementation and have a question. Could you please confirm it again?

[TheRealAmazonKendra]

Well shit. I have a bunch of review comments in pending. They're from a hot minute ago so some may be outdated.

[TheRealAmazonKendra]

If the availability zone is only a valid field if the region is provided, these two should fields should be a single object.

[TheRealAmazonKendra]

Further down I'm also seeing a lot of checking for whether certain properties are compatible with one another. This tells me that the contract here is too loose. I get that you are working from a construct that uses a lot of optional props when they really shouldn't be but I'd like further changes to not follow that pattern.

Can we structure this in a way that enforces the dependent props in the contract and disallows the combinations you're checking for below?

[TheRealAmazonKendra]

So what I would do here is actually make this an enum like class to future proof us against if/when the service team does allow for multiple regions. My suggestion would be to make ReplicationConfiguration a class with static functions like the Schedule class. For now, we'll only have one function that takes in one replicationConfiguration, but in the future we can add more functions for multiple.

[gracelu0]

Final tiny docstring comments and then I'm good to approve :)

[gracelu0]

Suggested change

	*
	* @default - create a new file system for the replication

[badmintoncryer]

@gracelu0
I believe the @ default description is essential because the destinationFileSystem is optional. Removing this description could cause the CI to fail.

What do you think?

[gracelu0]

Ohh right, thanks for pointing that out! perhaps “None” or “No destinationFileSystem set” instead then?

[badmintoncryer]

Thanks! I've updated it.

[gracelu0]

LGTM, thank you for contributing!

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: ecfd8c0
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).