Spot the difference: Schnelle Ressourcenübersicht

This content is more than 4 years old and the cloud moves fast so some information may be slightly out of date.

Lambda: Node 6.10 End of Lifetime - welche Funktionen sind betroffen?

Heute kam eine Abkündigung für die Unterstützung von node 6.10 per Mail von AWS.

“AWS Lambda: Node.js 6.10 will soon be EOL, please migrate your functions to a newer runtime version [AWS Account: 123456789012] "

Da stellt sich mir doch die Frage: “Was ist die effektivste Methode die Runtime von Lambda Ressourcen herauszufinden?”

Dazu will ich mal ein paar Methoden vorstellen. Es sind auch ein paar (noch) unbekannte dabei… Aber lest selbst

Der schnelle Weg: cli Ninja

Wer sich mit der aws CLI viel beschäftigt, kann gerade mit der Nutzung von “query” schnell Ergebnisse erzielen. Die Query wertet die JSON Antwort aus. Der lambda Service liefert ein Array von functions aus, welches alle Attribute enthält, unter anderem auch die Runtime.

Diese Auswertung müsste immer wieder ausgeführt werden, wenn eine Lambda Konfigurationsänderung durchgeführt wird.

aws lambda list-functions --query "Functions[?Runtime == 'nodejs6.10']"

Aber dazu benötigt man immer eine Workstation. Kann man das auch "workstationless” ausführen?

Ja, und zwar mit der neuen Funktion Config Query über die AWS Console.

Der neue Service: Config Advanced Query

In AWS Config werden die Konfigurationen von AWS Ressourcen geprüft und ausgewertet. Eine neue Funktion macht es möglich die gespeicherten Ressourcen in einer SQL Syntax abzufragen. Dabei fragt man nicht direkt die Ressourcenkonfiguration ab, wie es list-function macht, sondern die Konfigurationsdatenbank. Daher gibt es auch die Informationen wie configuration.lastModified.

Die Syntax für dieses Abfrage ist auch in den Beispielabfragen enthalten und sieht so aus:

SELECT
resourceId,
resourceType,
configuration.runtime,
configuration.lastModified,
configuration.description
WHERE
resourceType = 'AWS::Lambda::Function'
AND configuration.runtime = 'nodejs6.10'

Natürlich kann ich auch alle Funktionen suchen, die nicht einem bestimmten Wert entsprechen:

SELECT
*
WHERE
resourceType = 'AWS::Lambda::Function'
AND configuration.runtime != 'nodejs8.10'

In der Konsole findet man die Abfragen unter “AWS-Config, Ressourcen”

Console

Config führt regelmäßigem Compliance Check durch. Aber auch mit der query habe ich nur eine Momentaufnahme.

Will ich regelmäßig, bzw. immer, wenn eine Lambda Konfiguration geändert wurde, eine automatische Prüfung durchführen, so kann das auch mit “AWS Config” Rules erreicht werden.

Dazu wird eine Regel erstellt:

Regel

Für Lambda gibt es zwei vorkonfigurierte Regeln. Regeln können auch selber als Lambda Funktionen erstellt werden. Die richtige Regel heißt lambda-functions-setting-check:

preconfigured

Hier kann man nun bei “Rule parameters” unter runtime, z.B. den Wert “nodejs8.10” eintragen. Dann werden alle Lambda Konfigurationen, die nicht “nodejs8.10” als Runtime eingetragen haben als non-Compliant gemeldet.

Problematisch ist es hier, dass alle Lambda geprüft werden, auch z.B. die Funktionen die “Python” oder “go” als runtime haben. Bei mir sind dass dann 22 Lambdas, von denen die meisten aber in go geschrieben sind :) :

22 noncompliant resource(s)

Aber auch hierfür gibt es eine Lösung: Die Config Regeln können entweder auf Resource Typen (Wie “Lambda:Function”) oder Tags im Sope eingeschränkt werden. Will man nun nur alle Ressourcen prüfen, die man vorher z.B. mit dem Tag “Type: nodeLambda” getaggt hat, so schränkte man den Sope auf Tags ein:

AWS Config evaluates resources when the trigger occurs.

Dann prüft der Trigger für die Regel nicht den Ressourcentyp, sondern, ob diese Ressource gettagt ist.

In allen Lambda Funktionen, die node als Basis haben, trägt man diesen Tag ein:

Tagging Lambda functions with “nodeLambda” to filter AWS Config rules

Im Beispiel habe ich den Tag bei einer Funktion eingetragen und erhalte bei der Config-Regel-Prüfung auch nur noch eine non-compliant Resource:

1 noncompliant resource(s)

Fazit AWS Config ist ein sehr nützlicher Dienst, wenn es um Überprüfung von Compliance oder Sicherheitslücken in fast allen AWS Ressourcen geht. Die Abfragefunktion ist eine seht nützliche Ergänzung, die man sich genau anschauen sollte.

Photo by Mehrshad Rajabi on Unsplash

Similar Posts You Might Enjoy

How I spent a few hours using advanced technology to save $2

Opportunity cost is an important economic concept, but sometimes we need to ignore it to learn something. Join me in using a variety of services and tools to figure out what is using my KMS keys and if I can safely delete them. - by Maurice Borgmeier

Dissecting Serverless Stacks (IV)

Dissecting Serverless Stacks (IV) After we figured out how to implement a sls command line option to switch between the usual behaviour and a way to conditionally omit IAM in our deployments, we will get deeper into it and build a small hack on how we could hand over all artefacts of our project to somebody who does not even know SLS at all. - by Thomas Heinen

R can not be pushed in Production - deprecated!

Running Shiny on Fargate Some guys still thinking R cannot be used at scale or only in a limited way. I still do not understand the reason why people are like this. Since my last post about AWS Batch, which is a Docker-based service within AWS, which enables you to work with R, I spend a lot of time with Fargate, another Docker-based service on AWS. This time my boss wanted a BI app. - by Malte Walkowiak