Aws-cdk: How to skip DynamoDB Table creation if already exists

[rampatina]

:question: General Issue

The Question

How can we skip if the Dynamo Table creation if already existing in the stack, otherwise always create a new table.
or Is there any way to catch the error and proceed with the next steps? (Similar to Try/Catch)

Environment

• CDK CLI Version: 1.27.0
• Module Version: 1.20.0
• OS: Macintosh
• Language: TypeScript

Other information

[RomainMuller]

We have a SingletonFunction construct that does something similar for lambda Functions. You can find the source of it at @aws-cdk/aws-lambda/lib/singleton-lambda.ts.

Conceptually, it creates the resource in the root Stack (instead of in some construct's scope). A UUID is assigned to reduce the risk of collisions with a legitimate construct scoped to the Stack as well... Then we use tryFindChild to tell if the singleton already exists, creating it otherwise.

You should be able to easily implement the same pattern for a DynamoDB Table.

[rampatina]

Thanks for the reply. Do we have any way to check the existence of the DynamoDB table in an AWS environment through CDK?

[Douglas-Scott]

I believe this is possible with a CustomResource.

https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-cloudformation.CustomResource.html

[mattiLeBlanc]

@Douglas-Scott Sorry, but that documentation page is far from helpful.
Is there any example available how to check if the table does exist? We use RemovalPolicy.RETAIN on the DB so when we remove our stack but not our DB, it would be nice if it could skip DB creation and just continue.

[mattiLeBlanc]

I create on solution which you might find hacky, but it works fine in our CDK stack deploy script:

import * as Dynamodb from 'aws-sdk/clients/dynamodb';
import { SharedIniFileCredentials } from 'aws-sdk';
   ...

  async checkIfDynamoDbExists(name: string ) {
    const credentials = new SharedIniFileCredentials({profile: this.user});
    const dynamodb = new Dynamodb({
      region: this.config.region,
      credentials: this.user ? credentials : undefined
    });
    const tables = await dynamodb.listTables().promise();
    return tables!.TableNames!.indexOf(name) > 0;
  }

It will return me a true or false, and based on that I either create a table or get it:

 const tableExists = await this.resourceService.checkIfDynamoDbExists(applicationName);
    let dynamoDBTable: Table;
    if (!tableExists) {
      dynamoDBTable = new DynamoDbConstruct(this, `${id}-dynamoDb`, {
        applicationName
      }).table;
    } else {
      dynamoDBTable = Table.fromTableName(this, 'Table', applicationName) as Table;
    }

[malpaso]

Why is this issue closed? Seems like a pretty big missing piece for IaC. How is a CDK stack that creates an API, crud Lambdas and a DynamoDB supposed to re-deploy?

[mickog]

I agree this is crazy that this issue is closed.

[mattiLeBlanc]

So a downside of that workaround I proposed is that if you recreate your stack, and the table needs to be assimilated, it will not be part of the stack by just using the fromTableName solution.
You actually have to import the CFN resource of your table back into your new stack using an import in the CF dashboard.

If you your stack has created the table in the first place, it will not throw an error on redeploy. It knows that the table exists. Only if you have recreated your stack, the table would be an orphan. And you have to bring it into your family.

[mickog]

I've created another issue here https://github.com/aws/aws-cdk/issues/11208 raised it as a bug cause it sounds like it is to me but looks like the stance on it is that when a stack is pulled down it only retains resources to prevent data loss and is not meant to be used again. I thought it was common enough to pull down stacks though from time to time for a fresh deployment it can be great to fix something when having problems trouble shooting an issue. The old turn it off and back on trick