Hi CDK Fans

Im vorherigen Teil I habe ich das DynamoDB Stream to Lambda Solution Construct in mein Alfresco Provisioner CDK Deployment eingebaut und den Gewinn dadurch diskutiert. Diese Woche habe ich weitere CDK Solutions Constructs integriert. CDK Solutions Constructs sind CDK Constructs welche oft genutzte Cloudformation Pattern kapseln. Näheres darüber kannst du in Teil I lesen.

Cloudfront S3

Zu finden in GitHub ist das das Cloudfront S3 Solution Construct. Es implementiert ein Cloudfront vorangestellt einem S3 Bucket. Dadurch können Dateien performanter verteilt werden, da sie mittels eines Content Delivery Networks gecachet und on the Edge verteilt werden. Mit dem Cloudfront S3 Solution Pattern kommen einige tolle well-architected Aspekte wie z.B. HTTP Security Headers und buckets für CDN und S3 Access Logs.

const { CloudFrontToS3 } = require('@aws-solutions-constructs/aws-cloudfront-s3');

new CloudFrontToS3(stack, 'test-cloudfront-s3', {
    deployBucket: true
});

Ich wollte dieses Pattern verwenden um die S3 Static Webside zu erweitern, da diese bereits ein Cloudfront besitzt. Allerdings unterstützt das Cloudfront S3 Solution Construct keine Static Websides. Deshalb kann ich es leider nicht für meinen Stack benutzen. Egal was zählt ist, dass ich viel über dieses Solution Construct gelernt habe und nun weiß wofür ich es nicht verwenden kann, was ja auch nützlich ist!

SQS Lambda

Das SQS Lambda Solution Construct ist ein spannendes Pattern welches eine Queue vom Simple Queue Service (kurz: SQS), mit einem Lambda verbindet und so die Queue Messages an das Lambda zur Weiterverarbeitung leitet. Die Queue und das Lambda bekommen dabei ausschließlich benötigten Permissions. Zusätzlich deployed das SQS Lambda Solution Construct noch eine Dead Letter Queue die zum Speichern und Weiterverarbeiten von fehlgeschlagenden Messages dient.

const { SqsToLambda } = require('@aws-solutions-constructs/aws-sqs-lambda');

new SqsToLambda(stack, 'SqsToLambdaPattern', {
    deployLambda: true,
    lambdaFunctionProps: {
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'index.handler',
        code: lambda.Code.asset(`${__dirname}/lambda`)
    }
});

Ich benötigte dieses Solution Construct da das im Teil I erwähnte DynamoDB Stream to Lambda Solution Construct ein komisches Verhalten aufgewiesen hat indem es anscheinend Event Messages manchmal dupliziert. Mit dem SQS Lambda Solution Construct konnte ich eine FIFO SQS erstellen welche nun zusätzlich die im vorherigen Absatz erwähnten Vorteile besitzt.

Lambda DynamoDB

Ein simples aber dennoch tolles Solution Construct ist das Lambda DynamoDB. Es standardisiert die Verbindung eines Lambdas zu einer DynamoDB perfekt. Bedarfsweise kann eine existierende DynamoDB Tabelle übergeben oder eine neue erstellt werden:

const { LambdaToDynamoDB } = require('@aws-solutions-constructs/aws-lambda-dynamodb');

new LambdaToDynamoDB(stack, 'test-lambda-dynamodb-stack', {
    deployLambda: true,
    lambdaFunctionProps: {
        code: lambda.Code.asset(`${__dirname}/lambda`),
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'index.handler'
    },
    //optional existierende Tabelle übergeben
    existingTableObj: ddbTable
});

Als Teil des Solution Constructs werden die DynamoDB Zugriffsprivilegien and das Lambda erteilt. Ebenfalls wird nach der Erstellung oder Weiterleitung der Tabelle eine Environment Variable dem Lambda übergeben, welches den Namen der Tabelle enthält. Somit kann dann ohne jeglichen größeren Aufwand auf die Tabelle innerhalb des Lambdas zugegriffen werden:

// Kopiert vom Solution Construct Repo
this.lambdaFunction.addEnvironment('DDB_TABLE_NAME', this.dynamoTable.tableName);

// Verwendung innerhalb des Lambdas
const DDB_TABLE_NAME = process.env.DDB_TABLE_NAME || ''

Zusammenfassung

Somit konnten die nächsten CDK Solution Construct erfolgreich integriert werden. Bei dem Arbeiten mit den CDK Solution Constructs stellt sich bei mir die Frage, ob es nicht auch Sinn mache eigene Solutions Constructs zu bauen. Das hätte den Vorteil der Abstraktion der Infrastruktur. Allerdings sind die Nachteile, dass eventuell nicht viel Rücksicht auf das well-architected Framework genommen wird.

Ein weiterer Nachteil wäre, dass die selbsterstellten Solution Constructs natürlich maintained und weiter entwickelt werden sollte und das einen zusätzlichen Aufwand darstellt. Ich denke es ist so wie es oft sein sollte, der Use Case wird über die Sinnhaftigkeit der Kreierung von Solution Constructs entscheiden. Bis dahin kann und sollte man ruhig die existieren AWS CDK Solution Constructs verwenden, denn diese sind Open Source auf Git und die starke AWS Community maintained und entwickelt diese kräftig weiter. Ich konnte sogar auch schon zurück kontributieren um einen Bug zu fixen. Lasst mich wissen wie eure Erfahrungen mit den CDK Solution Constructs sind!

An die tollen Leser dieses Artikels sei gesagt, dass Feedback jeglicher Art gerne gesehen ist. In Zukunft werde ich versuchen hier eine Diskussionsfunktion einzubauen. Bis dahin sendet mir doch bitte direkten Feedback über meine Sozial Media accounts wie Twitter oder FaceBook. Vielen Dank :).

Ich liebe es an Content Management Open Source Projekte zu arbeiten. Vieles kannst du bereits frei nutzen auf www.github.com/mmuller88 . Wenn du meine dortige Arbeit sowie meine Blog Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen und ein Patreon zu werden:

Werde ein Patreon!

Share