AWS Serverless

Serverless in AWS

AWS Lambda (not PHP)
- increasing RAM also improve CPU & network
- Lambda Container Image
  - the container image must implement the Lambda Runtime API
  - ECS / Fargate is preferred for running arbitrary OCI images
- Pricing
  - pay per call
    - $0.2 per 1 million requests
  - pay per duration (in increment of 1ms)
- Lambda Limits - per Region
  - Execution
    - Memory allocation: 128 MB – 10GB (1 MB increments)
    - Maximum execution time: 900 seconds (15 minutes)
    - Environment variables (4 KB)
    - Disk capacity in the “function container” (in /tmp): 512 MB to 10GB
    - Concurrency executions: 1000 (can be increased)
  - Deployment
    - Lambda function deployment size (compressed .zip) 50MB
    - Size of uncompressed deployment (code + dependencies) 250MB
    - Can use the /tmp directory to load other files at startup
    - Size of environment variables: 4KB
- SnapStart
  - improves performance up to 10x at no extra cost for java 11 and above
- Edge Function
  - CloudFront Functions (JS)
    - high-scale, latency-sensitive CDN customizations
    - millions of requests/second
    - used to change viewer requests and responses
    - use cases
      - cache key normalization
      - header manipulation
      - url rewrites or redirects
      - request authentication & authorization
  - Lambda@Edge (NodeJS, Python) ($$$)
    - scales to 1000s of requests/second
    - used to change CloudFront requests and responses
    - longer execution time
    - adjustable CPU or memory
Dynamo DB
Cognito
API Gateway
S3
SNS & SQS
Kinesis Data Firehose
Aurora Serverless
Step Functions
Fargate

Lambda

by default, lambda function is launched outside your own VPC (in an AWS-owned VPC)
lambda in VPC
- must define the VPC ID, subnets, security groups
- Lambda will create an ENI in your subnets
with RDS Proxy
- lambda function must be deployed inside your VPC, because RDS proxy is never publicly accessible
Invoking Lambda from RDS & Aurora
- allows to process data events from within a database
- supports RDS for Postgres and Aurora MySQL
- must allow outbound traffic to Lambda function
- DB instance must have the required permissions to invoke Lambda

DynamoDB

Fully managed, highly available with replication across multiple AZ
NoSQL database - not a relational database - with transaction support
Scales to massive workloads, distributed database
Millions of requests per seconds, trillions of row, 100s of TB of storage
Fast and consistent in performance (single-digit millisecond)
Integrated with IAM for security, authorization and administration
Low cost and auto-scaling capabilities
No maintenance or patching, always available
Standard & Infrequent Access (IA) Table Class
can rapidly evolve schemas
read/write capacity modes
- provisioned mode (default)
  - pay for provisioned RCU/WCU
  - possibility to add auto-scaling mode
- on-demand mode (more expensive)
  - pay for what you use
DynamoDB Accelerator (DAX)
- in-memory cache
- microseconds latency for cached data
- default 5 minutes TTL
Stream processing
- ordered stream of item-level modifications (create/update/delete) in a table
- 24 hours retention
- limited of consumers
- use cases
  - react to changes in real-time
  - real-time usage analytics
  - insert into derivative tables
  - implement cross-region replication
  - invoke Lambda on changes to your DynamoDB table
Global Tables
- low latency in multiple-regions
- two-way (active-active) replication
- applications can READ and WRITE to the table in any region
- must enable dynamoDB Streams as a pre-requisite
inherited TTL feature
- automatically delete items after an expiry timestamp
backups for DR
- continuous backups using point-in-time recovery
  - optionally enabled for the last 35 days
  - the recovery process creates a new table
- on-demand backups
  - full backups for long-term retention, until explicitly deleted
  - doesn’t affect performance or latency
  - can be configured and managed in AWS Backup (enable cross-region copy)
  - the recovery process creates a new table
integration with [[aws-s3|S3]]
- export to S3 (must enable PITR)
- import from s3

Tables

each table has a primary key (must be configured at creation time)
each table can have an infinite number of items (rows)
each item has attributes (can be added over-time, can be null)
maximum size of an item is 400KB
data types
- scalar types - string, number, binary, boolean, null
- document types - list, map
- set types - string set, number set, binary set
update schema at need

1
2
3
4


--- primary key --- attributes ---
-- partition key -- sort key -- ...
-- user_id -- game_id -- score -- result --
-- kjahsdk -- 1234 -- 92 -- win

API Gateway

AWS Lambda + API Gateway: No infrastructure to manage
Support for the WebSocket Protocol
Handle API versioning (v1, v2…)
Handle different environments (dev, test, prod…)
Handle security (Authentication and Authorization)
Create API keys, handle request throttling
Swagger / Open API import to quickly define APIs
Transform and validate requests and responses
Generate SDK and API specifications
Cache API responses
high level integration
- lLambda function
- HTTP
- AWS Service
endpoint types
- edge-optimized (default) - for global clients
  - requests are routed through the CloudFront edge locations
  - the API gateway still lives in only one region
- regional
- private
  - can only be accessible from your VPC using an interface VPC endpoint
  - use a resource policy to define access
security
- user authentication through
  - IAM Roles - internal applications
  - Cognito - external users
  - Custom Authorizer
- custom domain name HTTPS
  - security through integration with ACM
  - if using edge-optimized endpoint, then the certificate must be in us-east-1
  - if using regional endpoint, the certificate must be in the API gateway region
  - must setup CNAME or A-alias record in Route53

Step Functions

Serverless + Lambda

build serverless visual workflow to orchestrate your lambda functions
features - sequence, parallel, conditions, timeouts, error handling
integration - EC2, ECS, on-premises servers, API Gateway, SQS, etc…

Amazon Cognito

give users an identity to interact with our web or mobile application
Cognito user pools
- integrate with API gateway & ALB
- user features
  - create a serverless database of user for your web & mobile apps
  - password reset
  - MFA
  - federated identities: FB, GOOGLE, SAML
Cognito identity pools (federated identity)
- Get identities for “users” so they obtain temporary AWS credentials
- users source can be CUP, 3^rd party logins, etc…
- users can then access AWS services directly or through API Gateway
- Default IAM roles for authenticated and guest users
Cognito vs IAM - hundreds of users, mobile users, authenticate with SAML