
Serverless Architectures with AWS Lambda: Overview and Best Practices [pdf] - yarapavan
https://d1.awsstatic.com/whitepapers/serverless-architectures-with-aws-lambda.pdf
======
yarapavan
Related document - Serverless Applications Lens from AWS Well-Architected
Framework - at [https://d1.awsstatic.com/whitepapers/architecture/AWS-
Server...](https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-
Applications-Lens.pdf)

Todd Hoff's notes from the paper:

Serverless: applications are ones that don't require you to provision or
manage any servers. Lambda: a high-scale, provision-free serverless compute
offering based on functions. At its core, you use Lambda to execute code.
Central tenant: your code cannot make assumptions about state. Events: you can
associate your Lambda function with event sources occurring within AWS
services that will invoke your function as needed. You don’t have to write,
scale, or maintain any of the software that integrates the event source with
your Lambda function. Security best practices: One IAM Role per Function; You
should not have any long-lived AWS credentials included within your Lambda
function code or configuration; Secrets should always only exist in memory and
never be logged or written to disk; API Gateway can perform much of the heavy
lifting by providing things like native AWS SigV4 authentication,47 generated
client SDKs,48 and custom authorizers; inside a VPC, you should apply network
security best practices through use of least privilege security groups, Lambda
function-specific subnets, network ACLs, and route tables that allow traffic
coming only from your Lambda functions to reach intended destinations.
Reliability Best Practices: The availability posture of your Lambda function
depends on the number of Availability Zones it can be executed in; What can be
complex, like most multi-region application designs, is coordinating a
failover decision across all tiers of your application stack; take advantage
of dead letter queues and implement how to process events placed on that queue
after recovery occurs. Performance Best Practices: By analyzing the Max Memory
Used: field, you can determine if your function needs more memory or if you
over-provisioned your function's memory size; choose the language you’re
already most comfortable with; Always use the default network environment
unless connectivity to a resource within a VPC via private IP is required;
Choose an interpreted language over a compiled language; Trim your function
code package to only its runtime necessities; After initial execution, store
and reference any externalized configuration or dependencies that your code
retrieves locally; Limit the reinitialization of variables/objects on every
invocation; Keep alive and reuse connections; use AWS X-Ray.54 X-Ray lets you
trace the full lifecycle of an application request. Operation Best Practices:
log; Create a custom metric and integrate directly with the API required from
your Lambda function as it’s executing.

