Adrian Cantrill’s SAA-C02 study course, 60 minutes: AWS Lambda part 3 and EventBridge
AWS Lambda – Part 3
The third part focused on a number of topics. The first topic was invoking Lambda functions.
There are three different methods for invoking Lambda functions: synchronous, asynchronous, and invocation using source mappings.
Synchronous:
– CLI/API invoke a lambda function, passing in data and waiting for a response
– Lambda function responds with data or fails
– Client communicates with APIGW which is proxied to Lambda function
– Lambda function responds or fails response back to client via APIGW
– Client sends a request, result (success or failure) returned during the request
– Errors or retries have to be handled within the client
Asynchronous:
– Typically used when AWS services invoke Lambda functions
– Client isn’t waiting for any kind of response; the even is generated and the client stops tracking
– If processing of the event fails, lambda will retry between 0 and 2 times (configurable). Lamba handles retry logic
– The function code needs to be idempotent: reprocessing a result should have the same result
– Lambda function needs to finish with some kind of desired state
– Events can be sent to a dead letter queue after repeated failed processing
– Lambda supports destinations (SQS, SNS, Lambda & EventBridge) where successful or failed events can be sent
– Different destinations can be configured based on successful processing or failures
Event source mapping:
– Typically used on streams or queues which don’t support event generation to invoke lambda (Kinesis, DynamoDB streams, SQS)
– Polls data and produces a source batch
– batches are broken up as required and sent into a Lambda function as event batches
– Lambda has a 15 minutes timeout; batch processing must complete within this time
– event source mappings read/poll from the stream or queue and deliver event batches to lambda; event batches are processed OK or FAIL as a batch
– There are no partially successful or failed batches; everything works or nothing works
– Permissions from the lambda execution role are used by the event source mapping to interact with the event source
– SQS Queues or SNS topics can be used for any discarded failed event batches
Lambda versions
– Lambda functions have versions
– A version is the code + the configuration of the lambda function
– it’s immutable – it never changes once published & has its own Amazong Resource Name
– $Latest points at the latest version
– Aliases (DEV, STAGE, PROD) point at a version – can be changed
Lambda startup times
– An execution context is the environment a lambda function runs in
– A cold start is a full creation and configuration including function code download
– with a warm start, the same execution context is reused. A new event is passed in but the execution context creation can be skipped
– Provisioned concurrency can be used. AWS will create and keep X contexts warm and ready to use improving start speeds
CloudWatchEvents and EventBridge
– If X happents, or at Y(times)… do Z
– EventBridge is CloudWatchEvents v2
– A default event Bus for the accoutn
– event bus: a stream of events which occur from any supported service inside that AWS account
– in CloudWatchEvents this is the only bus (implicit)
– EventBridge can be additional buses
– Rules match incoming events (or schedules)
EventBridge/CloudWatchEvents
– Default account event bus: a stream of events, which are generated by supported services within the AWS account
– EventBridge sits over the top of any event bridge it has exposure to
– Rules are linked to a specific event bus
– This event bus is the default event bus
– two types: event pattern rule, schedule (cron) rule
– events are JSON structures
CloudMastermind 