获取使用 AWS CDK 创建的 dynamo 表的名称

Question

Using the example from here . I can create a table and lambda function that has access to the table. But I need to know the name of table to use table.put to add records.

Short term I am declaring the table name in the dynamo_table_props and then exporting it to the lambda as an environment variable. However, this is against the best practices to declare names.

I've tried to access the pattern properties , but cannot find the correct syntax.

What I have working is:

from aws_solutions_constructs.aws_iot_lambda_dynamodb import IotToLambdaToDynamoDB
from aws_cdk import (
    aws_iot as iot,
    aws_lambda as _lambda,
    Stack
)
from constructs import Construct

IotToLambdaToDynamoDB(self, 'test-iot-lambda-dynamodb-stack',
            lambda_function_props=_lambda.FunctionProps(
                code=_lambda.Code.from_asset('lambda'),
                runtime=_lambda.Runtime.PYTHON_3_9,
                handler='index.handler',
                environment={ 
                    'TABLE_NAME':'hard_coded_table_name'
                },
            ),
            iot_topic_rule_props=iot.CfnTopicRuleProps(
                topic_rule_payload=iot.CfnTopicRule.TopicRulePayloadProperty(
                    rule_disabled=False,
                    description="Processing of DTC messages from the AWS Connected Vehicle Solution.",
                    sql="SELECT * FROM 'connectedcar/dtc/#'",
                    actions=[]
                )
            ),
            dynamo_table_props=ddb.TableProps(
               partition_key={'name': 'id', 'type': ddb.AttributeType.STRING},
               table_name='hard_coded_table_name'))

 

Answer 1

Assigning a table name as a Lambdas environment variable is not against best practices.

"Environment variable lookups inside constructs and stacks are a common anti-pattern."

This is stating that the use of environment variables inside your CDK stack is an anti-pattern.

You can most definitely use a Lambdas Environment Variable to store your table name. Another approach is to use Parameter Store and obtain your values at runtime from your Lambda function.

Answer 2

I found the hint to the answer in this AWS Blog Post .

When you call the function for the construct you have to assign it to a variable, in this example I used iotToLambdaToDynamo . Then, the last line of the below code extracts the table name from the construct and injects it into the lambda as a environmental variable as per lynkfox answer.

from aws_solutions_constructs.aws_iot_lambda_dynamodb import 

IotToLambdaToDynamoDB
from aws_cdk import (
    aws_iot as iot,
    aws_lambda as _lambda,
    Stack
)
from constructs import Construct

iotToLambdaToDynamo = IotToLambdaToDynamoDB(self, 'test-iot-lambda-dynamodb-stack',
            lambda_function_props=_lambda.FunctionProps(
                code=_lambda.Code.from_asset('lambda'),
                runtime=_lambda.Runtime.PYTHON_3_9,
                handler='index.handler',
            ),
            iot_topic_rule_props=iot.CfnTopicRuleProps(
                topic_rule_payload=iot.CfnTopicRule.TopicRulePayloadProperty(
                    rule_disabled=False,
                    description="Processing of DTC messages from the AWS Connected Vehicle Solution.",
                    sql="SELECT * FROM 'connectedcar/dtc/#'",
                    actions=[]
                )
            ),

iotToLambdaToDynamo.lambda_function.add_environment("TABLE_NAME", iotToLambdaToDymamo.dynamo_table.table_name)

Answer 3

The best practices you reference to "not declare names" is regarding the aspect of CDK where you can use a 'name prop' as you did. This is only against best practices because it prevents your stack from being redeployable as a copy environment in the same account (and is difficult with some naming situations like s3, where the names must be globally unique)

usually, it's perfectly fine to get around this by using a variable+common name - ie table_name="${environment}-hard-coded-name" that you then either pass into the stack at deployment time (using a context flag or parameter store or the like to retrieve them when cdk synth runs)

Alternatively, if you dont care about human readable names, each Resource in cdk is a class object.

As per the documentation you can reference the table name with yourTable.tableName

Ive never used the IotToLambdaToDynamoDB construct before, but a quick look seems to indicate you can access the table and the lambda directly after instantiation.

which means you could do something like:

yourIot.function.addEnvironment("dynamoDbName", yourIot.Table.tableName)

(referencing function properties and iot pattern properties )