Pritam Chakraborty

Certified Solutions Architect Associate Exam

Preparation Note

MODULE 13
Serverless
 Serverless

1
▪ In the Serverless don’t need to Manage Servers Just Deploy Codes
▪ Initially when AWS Pioneered Serverless it was Mostly Function as a Service (FAAS)
▪ Now Serverless is Anything that we Provision & Don't Have to think about the Server
Capacity or Manage them
▪ We don't even see the servers
▪ AWS Manages Them for us

Serverless in AWS –
▪ Lambda
▪ API Gateway
▪ S3
▪ DynamoDB
▪ Cognito
▪ SNS, SQS
▪ Step Functions
▪ Fargate …

AWS Lambda
Difference between EC2 & Lambda –
1. AWS EC2
▪ Virtual Servers on cloud
▪ Limited by RAM & CPU***
▪ Mostly Used for Continuously Running***
▪ Scaling Means Adding More Instances / Removing
2. AWS LAMBDA
▪ Virtual Functions ~ No Servers to Manage
▪ Short Executions, Limited Run Time (15 Min)***
▪ Run on Demand***
▪ Automated Scaling

Pritam
 2
Figure 1 : EC2 Server

Figure 2 : Lambda Function

Lambda Benefits –
▪ Easy Pricing
o Pay Per Request & Compute Time
o Free Tier 1 Million Request & 400,000 GBs of Compute Time***
▪ Integrated will all AWS services
▪ Supports many Programming Languages
o Python, Java, NodeJS, C#, Ruby etc.
▪ Supports Containers (specialized containers)
▪ Easy Monitoring
▪ Easy to get more Resources Per Functions (up to 10GB of ram)
▪ Increasing RAM also Improves CPU & Network Performance

Pritam
Lambda Thumbnail Creation –

3
Figure 3 : Lambda Thumbnail Creation

Serverless Cron Job –

Figure 4 : Serverless Cron Job

Lambda Limits (Per region) –

1. Execution
o Memory Allocations 128MB - 10GB
o Maximum Execution Time 900 Seconds (15 Minute)***
o Environment Variables Max 4KB
o Large files can be temporarily stored at /tmp directory: 512mb to 10gb
o Concurrency executions: 1000 (can be increased on request)
2. Deployment
o Max Functions Size Uncompressed Code + Dependency = 250MB***
o Max Functions Size Compressed = 50 MB***
o Can use /tmp dir. to Load Large Files at startup

Lambda SnapStart –
▪ Improves Lambda Functions Performance by 10X for No Cost for JAVA 11/+***
▪ When Enabled Functions is Invoked From Pre Init Stage

Pritam
 4
Figure 5 : Lambda SnapStart

Lambda@Edge & CloudFront Functions

▪ CloudFront Supports 2 Type of Functions
1. Lambda@Edge
2. CloudFront Functions

Use Case –
▪ We can Run Serverless Functions at CloudFront Level to Customize CDN Content
▪ Website Security & Privacy
▪ A/B testing and SEO
▪ User Authentication & Authorizations
▪ User tracking & real time image transformation
▪ Bot Mitigation

CloudFront Functions
▪ High Performance High Scale & only for the Viewer Request & Response***
▪ Light Weight Functions Written in JavaScript***
▪ For high scale latency sensitive CDN Customizations***
▪ Sub-millisecond startup times, Millions of Requests
▪ Used to Change only Viewer Request & Viewer Response***
▪ Native feature of CloudFront, manage code entirely within CloudFront

Pritam
 5
Figure 6 : CloudFront Function

Use Cases of CloudFront Functions –

1. Request Authentication & Authorizations***
a. Create & Validate User Generated Tokens
2. URL Rewrites or Redirects
3. Header Manipulation***
4. Transform req. Attributes to create an optimal cache key

Lambda@Edge Functions
▪ Lambda functions
▪ Written in NodeJS or Python***
▪ Used to Change***
o Viewer Request
o Viewer Response
o Origin Request
o Origin Response
▪ Support Thousands of Requests***
▪ Network Access, Filesystem Access, Access to Request Body (unlike CloudFront
functions)***
▪ Expensive than CloudFront Functions

Pritam
 6
Figure 7 : Lambda@ Edge Functions

Use Cases of Lambda@Edge Functions –

▪ Longer Execution Time***
▪ Adjustable CPU & Memory
▪ Network Access***
▪ Filesystem Access***

Networking of Lambda
▪ By Default Lambda is Launched Outside of our VPC
▪ That’s why Lambda Launched in AWS owned VPC

Figure 8 : Default Deployment of Lambda

▪ Thus it can not access Our Own VPC Internal Resources

Pritam
 ▪ To solve this, Deploy Lambda in Same/Own VPC

7
Figure 9 : Deploy Lambda in Same VPC

Lambda with RDS Proxy –

▪ If Lambda Functions Directly Connect with RDS Database there will be Too Many
Open Connections Under High Load
▪ It will ultimately Lead to Time Out & RDS Performance Issues
▪ RDS Proxy -
o Improves Scalability by Pooling & sharing DB Connections
o Preserves Connections
o Improves Security by Enforcing IAM Authentication
▪ Lambda must be Deployed in Same VPC to be able to Connect with the RDS Proxy***

Figure 10 : Lambda Proxy

Pritam
Invoking Lambda from RDS & Aurora –

8
▪ Invoke Lambda Functions from within the DB Instance
▪ Allows us to Process Data Events from the DB Instance***
▪ Supported for RDS for PostgreSQL & Aurora MySQL***
▪ Must Allow the Inbound Traffic to your Lambda Function from the DB Instance
▪ DB Must Have Required Permissions to Invoke Lambda Functions

Figure 11 : Invoking Lambda from RDS & Aurora

RDS Event Notification –

▪ Only Get the Notification for DB Instances***
▪ Not Data Transactions***
▪ Near Real Time Events (up to 5 minutes)

DynamoDB
▪ Fully Managed, Highly Available with Replication Across Multiple AZ
▪ NoSQL DB & Scales to Massive Workloads
▪ Millions of Request per Seconds, Trillions of Row, 100s of TB Of Storage
▪ Fast and consistent in performance (single digit millisecond)
▪ Integrated with IAM for Security & Authorization
▪ Low Cost and Auto Scaling Capabilities***
▪ No maintenance or patching window, always available
▪ Standard and Infrequent access table class

Pritam
 ▪ DynamoDB is Made of Tables***

9
▪ Each Table Has a Primary Key(must be decided at creation time)
▪ Each table can have Infinite Number of Items=Rows
▪ Each Item has Attributes=Columns (can be added over time, can be null)
▪ Max size of an item is 400KB
▪ Data Types supported are
o String, Number, Binary, Boolean, Null, List, Map, String set, Number set, Binary set
▪ In DynamoDB you can Rapidly Evolve Schemas

DynamoDB - Read/Write Capacity modes –

Control how you Manage your Table's Capacity (read/write throughput)
1. Provisioned Mode (default)
o You Specify the Number of Reads/Writes Per Second
o You need to Plan Capacity Beforehand***
o Pay for Provisioned Read Capacity Units (RCU) & Write Capacity Units
(WCU)
o Possibility to Add Auto-Scaling Mode for RCU & WCU
2. On-Demand Mode
o Read/Writes Automatically Scale Up/Down With your Workloads
o No Capacity Planning Needed
o Pay for What You Use, More Expensive ($$$)
o Great for Unpredictable Workloads, Steep Sudden Spikes***

DynamoDB Accelerator (DAX) –

▪ Fully Managed, Highly Available, Seamless in Memory Cache for DynamoDB
▪ Caches Data In Front Of DynamoDB***
▪ Microsecond latency
▪ Does Not require application logic modification (compatible with existing dynamodb api’s)
▪ 5 Minutes TTL for Cache(Default)***
▪ AWS Suggest to Have DAX than Elasticache for DynamoDB Caching***
▪ AWS Suggest to Use DAX for Individual Object Cache, Query & Scan Cache***
▪ AWS Suggest to Use Elasticache to Cache Aggregation Results(Large Datasets)***

Pritam
 10
Figure 12 : DAX ~ DynamoDB Accelerator

DynamoDB - Stream Processing –

▪ Ordered Stream of Item Level Modifications (Create/Update/Delete) in a table
▪ Use case
o React to Changes in Real-Time
o Real time usage analytics
o Implement Cross Region Replication***
o Invoke Lambda on Table Data Changes***
1. DynamoDB Streams –
o 24 Hour Data Retention
o Limited Number of Consumers
o We Can Process Using Lambda Triggers
o If we want to access by kinesis client library, use kinesis adapter

Figure 13 : DynamoDB Streams

Pritam
 2. Kinesis Data Streams –

11
o 1 Year Retention
o High Number of Consumers
o Process using lambda, kinesis data analytics, kinesis data firehose, AWS glue etc.

DynamoDB Global Tables –

o Global Table is Replicated Across Regions
o Make DynamoDB Table Accessible with Low Latency in Multiple Regions
o Every Replica in Global Table will Have Active-Active Replication***
o Must Enable DynamoDB Streams to Use Global Table***

Figure 14 : DynamoDB Global Tables

DynamoDB Time To Live (TTL) -

▪ Automatically Delete Table Items After an Expiry Time Stamp
▪ Use cases : Reduced Stored Data, Web Session Handling

DynamoDB Backups –
1. Continuous backups using point-in-time recovery (PITR)
▪ Optionally Enabled for the Last 35 Days
▪ Point-In-Time Recovery to Any Time within the Backup Window
▪ The Recovery Process Creates a New Table***
2. On-demand backups
▪ Full Backups for Long-Term Retention, until explicitly deleted
▪ Doesn't affect performance or latency

Pritam
 ▪ Can be Configured & Managed in AWS Backup (enables cross-region copy)

12
▪ The Recovery Process Creates a New Table

DynamoDB - Integration with S3 –

1. Export to S3 (must enable PITR)
▪ Works for any Point Of Time in the Last 35 Days Doesn't Affect the Read Capacity
of your Table
▪ Perform Data Analysis on Top of DynamoDB
▪ ETL on Top of S3 data before importing back into DynamoDB
▪ Export in DynamoDB JSON or ION format***
2. Import from S3
▪ Import CSV, DynamoDB JSON or ION format
▪ Doesn't Consume Any Write Capacity***
▪ Creates a New Table
▪ Import Errors are Logged in CloudWatch Logs

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 & Authorization)
▪ Create API keys, handle request throttling
▪ Swagger / Open API import to quickly define APIs
▪ Transform and validate requests and responses
▪ Cache API responses

Example Workflow –
1. A User Sends a Request (GET user details) to the API Gateway
2. API Gateway Processes the Request, Validates it & Routes it to the Backend Service
(a Lambda function)

Pritam
 3. The Backend Service Processes the Request & Sends a Response Back to the API

13
Gateway.
4. API Gateway Returns the Response to the User

API Gateway Endpoint Types –

1. Private
o Can Only be Accessed Within the VPC Using an Interface VPC Endpoint (ENI)

Figure 15 : Private API Gateway Endpoint

2. Regional
o For Client Within One Region
o Could Manually Combine with CloudFront(more control over the caching
strategies and the distribution)

Figure 16 : Regional API Gateway Endpoint

Pritam
 3. Edge Optimized (default)

14
o For Global Clients
o Requests are Routed via CloudFront Edge Locations
o API gateway still Lives in One Region

Figure 17 : Edge Optimized API Gateway Endpoint

API Gateway Security –

▪ User Authentication through
1. IAM Roles (useful for internal applications)

Figure 18 : API Authentication ~ IAM Roles

2. Cognito (for external users)

Figure 19 : API Authentication ~ Cognito

Pritam
 3. Custom Authorizers (your own logic)

15
Figure 20 : API Authentication ~ Custom Authorizers

AWS Step Functions –

▪ Build Serverless Visual Workflow to Orchestrate your Lambda Functions
▪ Features : Sequence, Parallel, Conditions, Timeouts, Error Handling, …
▪ Can integrate with EC2, ECS, On-Premises Servers, API Gateway, SQS Queues etc…
▪ Possibility of Implementing Human Approval Feature
▪ Use cases: order fulfillment, data processing, web applications, any workflow

Cognito
▪ Give Users an Identity to Interact with our Web or Mobile Application
1. Cognito User Pools :
o Sign In Functionality for App Users
o Integrate with API Gateway & Application Load Balancer***
2. Cognito Identity Pools (Federated Identity) :
o Provide AWS Credentials to Users so They Can Access AWS Resources
Directly***
o Integrate with Cognito User Pools as an Identity Provider***

***When to use Cognito Over IAM : Question Contains "Hundreds of Users", "Mobile
Users", "Authenticate with SAML", “The Users Sit Outside of AWS”***

Figure 21 : Cognito

Pritam
Cognito User Pools –

16
▪ Create a Serverless Database of User for your Web & Mobile Apps
▪ Simple Login: Username (Or Email) / Password Combination
▪ Password Reset
▪ Email & Phone Number Verification
▪ Multi-Factor Authentication (MFA)
▪ Federated Identities: Users from LinkedIn, Google***

Figure 22 : Cognito User Pools

▪ Cognito User Pools Integrates with API Gateway & Application Load Balancer***

Figure 23 : Cognito User Pool

Pritam
Cognito Identity Pools (Federated Identities) –

17
▪ Get Identities for "Users" so they Obtain Temporary AWS Credentials***
▪ Users Source can be Cognito User Pools, 3rd Party Logins, etc......
▪ Users can then access AWS Services Directly or through API Gateway
▪ The IAM Policies Applied to the Credentials are Defined in Cognito
▪ They can be customized based on the user_id for fine grained control
▪ Default IAM Roles For Authenticated and Guest Users
▪ ***We can get Row Level Security in DynamoDB using Identity Pools***

Figure 24 : Cognito Identity Pools

Pritam