06. Serverless

AWS Lambda

  • Synchronous Invocations
    • Results is returned right away
    • Client need to handle Errors with actions(debug, retries, exponential backoff, etc)
    • Users Invoked
      • Elastic Load Balancing (Application Load Balancer)
      • Amazon API Gateway
      • Amazon CloudFront (Lambda@Edge)
      • Amazon S3 Batch
    • Service Invoked
      • Amazon Cognito
      • AWS Step Functions
    • Others
      • Amazon Lex
      • Amazon Alexa
      • Amazon Kinesis Data Firehose
  • Asynchronous Invocations
    • S3, SNS, CloudWatch Events (ie EventBridge)
    • Put the invocations into Events Queue
    • Retry on errors for 3 times, init Run – 1min wait – 1st retry – 2 mins wait – 2nd retry – 2mins wait – final retry; duplicate logs entries in CloudWatch Logs as retried
    • the processing is idempotent
    • Can define a DLQ (dead-letter queue) – SNS or SQS – for failed processing (need correct IAM permissions)
    • Invoked by
      • Amazon Simple Storage Service (S3), with S3 Events Notifications
      • Amazon Simple Notification Service (SNS)
      • Amazon CloudWatch Events / EventBridge
      • AWS CodeCommit (CodeCommit Trigger : new branch, new tag, new push)
      • AWS CodePipeline (invoke a Lambda function during the pipeline, Lambda must callback)
      • Amazon CloudWatch Logs (log processing)
      • Amazon Simple Email Service
      • AWS CloudFormation
      • AWS Config
      • AWS IoT
      • AWS IoT Events
  • To expose Lambda as an HTTP(S) endpoint
    • ALB, registered Lambda in a target group; also QueryParameters and Headers needed to be Key/Value paired
      • support multi-value headers, auto-convert multiple values with same key into arrays to Lambda
    • API Gateway
  • Event Source Mapping (synchronous invoked)
    • Streams
      • Kinesis Data Streams or DynamoDB Streams
      • One Lambda invocation per stream shard
      • Processed items aren’t removed from the stream
      • process multiple batches in parallel (up to 10 batches per shard)
      • By default, if your function returns an error, the entire batch is reprocessed until the function succeeds, or the items in the batch expire
    • Queue
      • SQS & SQS FIFO queue
      • Long Polling with batch size (1-10 messages)
      • the DLQ have to set on SQS, not on Lambda
      • items would be deleted from queue once successfully processed by Lambda
      • For SQS (standard) queue Lambda adds 60 more instances per minute to scale up, up to 1000 batches
      • For SQS FIFO queue Lambda scales to the number of active message groups (defined in GroupID), and messages under same GroupID would be processed in order
  • Event Object – original sources prepared for application codes
    • JSON, contains information from the invoking service (e.g., EventBridge, custom, …)
    • Lambda runtime converts the event to an object (e.g., dict type in Python)
    • Example: input arguments, invoking service arguments, …
  • Context Object – details about the Lambda resources described
    • Provides methods and properties that provide information about the invocation, function, and runtime environment
    • Passed to your function by Lambda at runtime
    • Example: aws_request_id, function_name, memory_limit_in_mb, …
  • Destinations
    • Asynchronous invocations – can define destinations for successful and failed event to
      • Amazon SQS
      • Amazon SNS
      • AWS Lambda
      • Amazon EventBridge bus
    • Event Source mapping – only for discarded event batches, send to
      • Amazon SQS
      • Amazon SNS
  • Lambda Execution Role (IAM Role), to grant the Lambda function permissions to AWS services/resources
    • AWSLambdaBasicExecutionRole – Upload logs to CloudWatch
    • AWSLambdaKinesisExecutionRole – Read from Kinesis
    • AWSLambdaDynamoDBExecutionRole – Read from DynamoDB Streams
    • AWSLambdaSQSQueueExecutionRole – Read from SQS
    • AWSLambdaVPCAccessExecutionRole – Deploy Lambda function in VPC
    • AWSXRayDaemonWriteAccess – Upload trace data to X-Ray
  • Lambda Resources Based Policy, to allow resources to call Lambda functions
  • Lambda Event Variables, as key / value pair in β€œString” form
  • Can embrace X-Ray for tracing, by enabling “Active Tracing” in configuration, with IAM Execution Role (AWSXRayDaemonWriteAccess)
    • _X_AMZN_TRACE_ID: contains the tracing header
    • AWS_XRAY_CONTEXT_MISSING: by default, LOG_ERROR
    • AWS_XRAY_DAEMON_ADDRESS: the X-Ray Daemon IP_ADDRESS:PORT
  • Edge functions attached on CloudFront with
    • CloudFront Functions, as lightweight functions written in JavaScript, can be millions requests per second
      • change viewer requests (after CloudFront received) and viewer responses (before forwarding to clients)
      • managed in CloudFront
    • Lambda@Edge
      • Lambda functions written in NodeJS or Python, only support up to 1K request per second
      • change CloudFront requests and responses:
        • Viewer Request – after CloudFront receives a request from a viewer
        • Origin Request – before CloudFront forwards the request to the origin
        • Origin Response – after CloudFront receives the response from the origin
        • Viewer Response – before CloudFront forwards the response to the viewer
      • Author in one AWS Region (us-east-1)
  • asd
  • asd

Step Functions

  • Workflow in JSON
  • Start with SDK, API Gateway call, or Event Bridge
  • Task: Invoke 1 AWS service or Run 1 Activity
  • States: Choice, Fail-or-Succeed, Pass, Wait, Map, Parallel
  • Error Handling should be in Step Functions, not in Task; using Retry and Catch, running from top to bottom but not sequentially (“OR”)
  • Wait for Task token: append .waitForTaskToken in Resource, pause the running until receiving a SendTaskSuccess or SendTaskFailure API call. (PUSH mechanism)
  • Activity Task: Activity Worker on EC2/Lambda/.., using GetTaskActivity API call for poll, sending response with SendTaskSuccess or SendTaskFailure API call (PULL mechanism), with SendTaskHeartBeat + HeartBeatSeconds
  • Standard vs Express (asynchronous and synchronous)

AWS Serverless Application Modal (SAM)

  • configure via JSON/YAML, complied to CloudFormation stack
  • use CodeDeploy for Lambda function
    • Traffic Shifting
    • Pre- and Pro- for testing on traffic shifting
    • rollback by AWS CloudWatch Alarm
  • run Lambda, API Gateway, DynamoDB locally
    • Lambda start/invoke
    • API Gateway
    • AWS Events (sample payloads for event resources)
  • SAM Recipe
    • Transform Header – template
    • Write Code
    • Package and Deploy – into S3 Bucket
  • SAM Accelerate (sam sync) – reduce latency
    • update existing SAM template
    • using “–code” option, without updating infrastructure (service APIs and bypass CloudFormation)
  • SAM Policy Templates
    • apply permissions to Lambda Functions
  • SAM Multiple Environments, using “samconfig.toml”


DynamoDB

AWS API Gateway

Amazon S3

AWS SNS & SQS

AWS Kinesis Data Firehose

Aurora Serverless