aws_dynamodb: allow point_in_time_recovery to be IResolvable

Describe the feature

The point_in_time_recovery field passed to the aws_dynamodb.Table constructor should also permit an IResolvable to be passed.

The underlying CfnTable resource already allows an IResolvable for point_in_time_recovery_enabled. https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_dynamodb/CfnTable.html#aws_cdk.aws_dynamodb.CfnTable.PointInTimeRecoverySpecificationProperty

Use Case

We want to use an Aspect to check that developers either enable point-in-time recovery for our production account, or explicitly disable it for all accounts. Currently, this is not feasible for two reasons:

1. We cannot distinguish explicit disable from implicit disable.
2. We cannot just hard-code True because it is contingent upon the account.

Instead, we want to make two implementations of IResolvable. Then the Aspect can simply check that point_in_time_recovery_enabled is set to an instance of once of these two classes.

Proposed Solution

Fix the Table constructor to allow for IResolvable for point_in_time_recovery. If provided, it will generate the corresponding PointInTimeRecoverySpecificationProperty instance.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

1.140.0

Environment details (OS name and version, etc.)

Alpine 3.15

[skinny85]

You can invoke cdk deploy TestStack1 TestStack2, you can invoke just cdk deploy TestStack1 if TestStack1 depends on TestStack2 (very common), you can invoke cdk deploy TestStack* (the command accepts wildcards), you can invoke ckd deploy MyStage/* if you’re using the Stage class, etc.

This is a giant maintenance headache. Every time a developer adds a new stack, they must also add it to the list of parameters to cdk deploy. If they don’t, it will “mysteriously” not deploy.

No. I literally gave 3 different ways that do not involve any changes when adding a new Stack.

And all of that business aside, defining all the stacks for all accounts like that is very inflexible. To deploy to a new account, I now have to make yet another copy of every stack in cdk.py.

Again, no. See the Stage class example. You can also write a loop. There are a million ways to remove this duplication.

Can you show the code of your Aspect, and how are developers using it in their one Stack instance?

The checker Aspect is applied to the whole App, not individual Stacks (directly). This is done so there is no chance a developer forgets to add it to their Stack.

The visit method says if the node is of type aws_dynamodb.Table, then look at node.node.default_child.point_in_time_recovery_specification and verify that it matches one of our two approved strategies (either “always disable” or “enable in prod”). The code for this is still in progress, so I can’t post it here.

OK. I think we’ve exhausted the discussion here. I really tried, but I can’t help more without seeing the code.

You obviously have some very strong opinions on how you want to structure your CDK code. I wish you luck, and I hope you manage to satisfy your requirements.

[skinny85]

I’ve thought about it some more, and I think the answer is a custom Construct that wraps the CDK L2 Table construct.

This way, you can deal with setting pointInTimeRecovery to whatever you want by getting the CfnTable underlying the Table (using the Node.defaultChild helper) - you probably want to use an Fn::If CloudFormation function, and possibly a Mapping too. This way, your developers will never have to know the details, and everything will happen automatically for them.

Your Aspect can then validate that all DynamoDB Tables used in the App were created using your library, and not the Table class directly (here you can check for the presence your magical IResolvable subclass, that your custom Construct will use).