#AWS #Note #Lambda

Notes_Lambda.md

• Serverless functions are event driven
• Drawbacks of serverless functions
  • debugging
  • less control on infra
• Serverless options
  • AWS Lambda
  • Azure Functions
  • Google Cloud Functions
  • iron.io
• Pricing depends on
  • No of request: each time it starts execution in response to an event
  • Duration: start of execution till it returns or terminates otherwise, rounded to nearest 100ms. Price depends on function memory (RAM) used.
• With serverless computing, you tell your serverless computing platform the maximum number of simultaneous function requests you want to run and the platform does the scaling for you
• You cannt access the infrastructure that AWS Lambda run on
• AWS Lambda stores code in Amazon S3 and encrypts it at rest. AWS Lambda performs additional integrity checks while your code is in use.
• Lambda function code must be written in a “stateless” style i.e. it should assume there is no affinity to the underlying compute infrastructure. Local file system access, child processes, and similar artifacts may not extend beyond the lifetime of the request, and any persistent state should be stored in Amazon S3, Amazon DynamoDB, or another Internet-available storage service.
• Lambda functions can include libraries, even native ones.
• Each Lambda function receives 500MB of non-persistent disk space in its own /tmp directory.
• Threads and processes can be used in Lambda functions. Resources allocated to the Lambda function, including memory, execution time, disk, and network use, must be shared among all the threads/processes it uses.
• Below restrictions apply to AWS Lambda function code
  • Inbound network connections are blocked by AWS Lambda
  • outbound connections only for TCP/IP and UDP/IP sockets
  • ptrace (debugging) system calls are blocked.
• Each AWS Lambda function runs in its own isolated environment, with its own resources and file system view. AWS Lambda uses the same techniques as Amazon EC2 to provide security and separation at the infrastructure and execution levels.
• Environment Variable
  • AWS Lambda support environment variables.You can easily create and modify environment variables from the AWS Lambda Console, CLI or SDKs.
  • For sensitive information, such as database passwords, we recommend you use client-side encryption using AWS Key Management Service and store the resulting values as ciphertext in your environment variable. You will need to include logic in your AWS Lambda function code to decrypt these values
  • Environment variables can be accessed from function code: System.getenv("NAME_OF_VARIABLE")
• Lambda layer: you can package any code (frameworks, SDKs, libraries, and more) as a Lambda Layer and manage and share them easily across multiple functions.
• AWS Lambda automatically monitors Lambda functions on your behalf, reporting real-time metrics through Amazon CloudWatch: duration, errors, throttle etc.
• Troubleshoot failures in an AWS Lambda function: integrates with Amazon CloudWatch logs, creating a log group for each Lambda function and providing basic application lifecycle event log entries, including logging the resources consumed for each use of that function. You can easily insert additional logging statements into your code.
• Scaling AWS Lambda function: You do not have to scale your Lambda functions, AWS Lambda scales them automatically on your behalf. Every time an event notification is received for your function, AWS Lambda quickly locates free capacity within its compute fleet and runs your code. Since your code is stateless, AWS Lambda can start as many copies of your function as needed without lengthy deployment and configuration delays. There are no fundamental limits to scaling a function. AWS Lambda will dynamically allocate capacity to match the rate of incoming events
• Resource Allocation for function: In the AWS Lambda resource model, you choose the amount of memory you want for your function, and are allocated proportional CPU power and other resources. For example, choosing 256MB of memory allocates approximately twice as much CPU power to your Lambda function as requesting 128MB of memory and half as much CPU power as choosing 512MB of memory. You can set your memory in 64MB increments from 128MB to 3GB.
• Pull event source: Kinesis, SQS, DynamoDB
• Events are passed to a Lambda function as an event input parameter. For event sources where events arrive in batches, such as Amazon SQS, Amazon Kinesis, and Amazon DynamoDB Streams, the event parameter may contain multiple events in a single call, based on the batch size you request
• Trigger a Lambda function on DynamoDB table updates by subscribing your Lambda function to the DynamoDB Stream associated with the table. You can associate a DynamoDB Stream with a Lambda function using the Amazon DynamoDB console, the AWS Lambda console or Lambda’s registerEventSource API.
• Kinesis and DynamoDB events: The Amazon Kinesis and DynamoDB Streams records sent to your AWS Lambda function are strictly serialized, per shard. This means that if you put two records in the same shard, Lambda guarantees that your Lambda function will be successfully invoked with the first record before it is invoked with the second record. If the invocation for one record times out, is throttled, or encounters any other error, Lambda will retry until it succeeds (or the record reaches its 24-hour expiration) before moving on to the next record. The ordering of records across different shards is not guaranteed, and processing of each shard happens in parallel.
• Respond to Amazon CloudWatch alarms: First, configure the alarm to send Amazon SNS notifications. Then from the AWS Lambda console, select a Lambda function and associate it with that Amazon SNS topic.
• Invoke an AWS Lambda function over HTTPS: invoke a Lambda function over HTTPS by defining a custom RESTful API using Amazon API Gateway. This gives you an endpoint for your function which can respond to REST calls like GET, PUT and POST
• Error handling:
  • For Amazon S3 bucket notifications and custom events, AWS Lambda will attempt execution of your function three times in the event of an error condition in your code or if you exceed a service or resource limit.
  • For ordered event sources that AWS Lambda polls on your behalf, such as Amazon DynamoDB Streams and Amazon Kinesis streams, Lambda will continue attempting execution in the event of a developer code error until the data expires. You can monitor progress through the Amazon Kinesis and Amazon DynamoDB consoles and through the Amazon CloudWatch metrics that AWS Lambda generates for your function. You can also set Amazon CloudWatch alarms based on error or execution throttling rates.
• You can invoke a Lambda function using a custom event through AWS Lambda’s Invoke API. Only the function’s owner or another AWS account that the owner has granted permission can invoke the function
• Use AWS Step Functions to coordinate a series of AWS Lambda functions in a specific order. You can invoke multiple Lambda functions sequentially, passing the output of one to the other, and/or in parallel, and Step Functions will maintain state during executions for you.
• AWS Lambda function customize its behavior to the device and app making the request. It automatically gain insight into the device and application that made the call through the ‘context’ object. Context object is passes as a parameter in handleRequest method.
• Lambda provides the Amazon Linux build of openjdk 1.8.
• When you update a Lambda function, there will be a brief window of time, typically less than a minute, when requests could be served by either the old or the new version of your function.
• AWS Lambda is designed to run many instances of your functions in parallel. However, AWS Lambda has a default safety throttle for number of concurrent executions per account per region (visit here for info on default safety throttle limits). Max concurrent execustions can be controlled at individual fuction level
• On exceeding the throttle limit on concurrent executions, AWS Lambda functions being invoked synchronously will return a throttling error (429 error code). Lambda functions being invoked asynchronously can absorb reasonable bursts of traffic for approximately 15-30 minutes, after which incoming events will be rejected as throttled. In case the Lambda function is being invoked in response to Amazon S3 events, events rejected by AWS Lambda may be retained and retried by S3 for 24 hours. Events from Amazon Kinesis streams and Amazon DynamoDB streams are retried until the Lambda function succeeds or the data expires. Amazon Kinesis and Amazon DynamoDB Streams retain data for 24 hours.
• You can configure an Amazon SQS queue or an Amazon SNS topic as your dead letter queue for a Lambda function
• Error Handling: On failure, Lambda functions being invoked synchronously will respond with an exception. Lambda functions being invoked asynchronously are retried at least 3 times. Events from Amazon Kinesis streams and Amazon DynamoDB streams are retried until the Lambda function succeeds or the data expires. Kinesis and DynamoDB Streams retain data for a minimum of 24 hours.
• Lambda functions are region specific. In the console Region has to be selecte before creating function
• Lambda functions provide access only to a single VPC. If multiple subnets are specified, they must all be in the same VPC. You can connect to other VPCs by peering your VPCs.
• Lambda functions configured to access resources in a particular VPC will not have access to the internet as a default configuration. If you need access to external endpoints, you will need to create a NAT in your VPC to forward this traffic and configure your security group to allow this outbound traffic.
• Collection of serverless applications published by developers, companies, and partners in the AWS community available with the AWS Serverless Application Repository
• You can automate your serverless application’s release process using AWS CodePipeline and AWS CodeDeploy. CodePipeline is a continuous delivery service that enables you to model, visualize and automate the steps required to release your serverless application. CodeDeploy provides a deployment automation engine for your Lambda-based applications.
• AWS Step Functions can be used to coordinate a series of AWS Lambda functions in a specific order. You can invoke multiple Lambda functions sequentially, passing the output of one to the other, and/or in parallel, and Step Functions will maintain state during executions for you.
• AWS Serverless Application Model(SAM) is open sourced under Apache 2.0
• Lambda@Edge
  • Allows you to run code across AWS locations globally without provisioning or managing servers, responding to end users at the lowest network latency. You just upload your Node.js code to AWS Lambda and configure your function to be triggered in response to Amazon CloudFront requests (i.e., when a viewer request lands, when a request is forwarded to or received back from the origin, and right before responding back to the end user)
  • To use Lambda@Edge, you just upload your code to AWS Lambda and associate a function version to be triggered in response to Amazon CloudFront requests.
  • Difference between Lambda and Lambda@Edge: API Gateway and Lambda are regional services. Using Lambda@Edge and Amazon CloudFront allows you to execute logic across multiple AWS locations based on where your end viewers are located. Invocation Type of event sources
• S3: Asynch, retried 2 times
• Cognito: Synch
• Poll-based event sources that are stream-based like Kinesis, DynamoDB: AWS Lambda polls and invokes functions synchronously. Retried till data expires
• Poll-based event sources that are not stream-based like SQS: AWS Lambda polls and invokes functions synchronously.Retries till message expires, available once visiblity timout is over
• SNS: