AWS Academy Cloud Architecting

Module 14
Building Serverless Architectures and Microservices
Complete Study Summary — Pages 1 to 37

📷 [INSERT IMAGE: AWS Academy / AWS Logo Banner]

Version 3.0.2 | 200-ACACAD-30-EN-SG

Module Objectives
After completing this module you will be able to:
• Define serverless architectures and explain their benefits
• Identify the characteristics of microservices
• Architect a serverless solution using AWS Lambda
• Explain how containers are used in AWS
• Describe the types of workflows supported by AWS Step Functions
• Describe a common architecture for Amazon API Gateway
• Apply AWS Well-Architected Framework principles to serverless architectures

💡 As a cloud architect you must recognize when to choose serverless, apply event-driven
architectures, and know when to use workflow orchestrations to reduce manual intervention.
Section 1: Thinking Serverless
1.1 Traditional Three-Tier Web Application in a VPC
A classic web application deployed in a VPC uses a three-tier pattern:
Web Tier: A web domain points to an Application Load Balancer, which routes traffic to EC2
instances spread across two Availability Zones (AZs) inside an Auto Scaling group. This tier
handles the presentation layer in the browser.
Application Tier: Accessed through a second Application Load Balancer, this tier runs the
business logic on EC2 instances also deployed across two AZs in an Auto Scaling group. Both
the web and app tiers are customer-managed — security patches and updates are the
customer's responsibility.
Data Tier: Uses Amazon RDS in a Multi-AZ configuration — a primary database in one AZ with
synchronous replication to a secondary in the second AZ. RDS is AWS-managed (patching,
maintenance). When the primary fails, the secondary is promoted automatically.

📷 [INSERT IMAGE: Three-Tier Web App Architecture in a VPC — Web tier → App tier → Data tier
with ALBs and Auto Scaling]

The multi-tier pattern provides decoupled, independently scalable components. However, many
components such as message queues and authentication are undifferentiated — they look the
same for any application.

1.2 Benefits of AWS Serverless

AWS serverless eliminates the need to size, provision, or maintain servers. Starting in 2013,
AWS observed customers using EC2 for very short periods — this insight led to serverless,
where runtime is fully managed by AWS and pricing is based purely on usage.

📷 [INSERT IMAGE: AWS Serverless Benefits icons — No server management, Continuous

scaling, Pay-for-value, Built-in HA, Event-driven]

Benefit Description
No server management You never think about servers, OS patches, or capacity sizing. AWS
manages everything.
Pay-for-value Pay only for what you use. No payment for idle time. Granular billing
(e.g., milliseconds for Lambda).
Continuous scaling Services scale automatically based on demand. DynamoDB adjusts
read/write capacity; Lambda runs as many instances in parallel as
needed.
Built-in HA Serverless data stores replicate across 3 AZs. Compute runs in
isolated environments unaffected by other failures.
 Event-driven & Services publish, consume, and route events. Lambda integrates with
microservices SQS, Kinesis, DynamoDB Streams, and S3 natively.

1.3 AWS Serverless Services Overview

AWS has serverless options for every layer of the application stack:

📷 [INSERT IMAGE: AWS Serverless Services Grid — Compute / App Integration / Data Stores /
Web Hosting / Auth / CDN]

Category Service Purpose

Compute AWS Lambda / Lambda@Edge Event-driven code execution
without servers
Compute AWS Fargate Serverless containers with ECS
or EKS
Application Integration Amazon API Gateway Create, publish, and manage
REST and HTTP APIs
Application Integration AWS AppSync Deploy and manage GraphQL
APIs
Application Integration Amazon SNS Pub/sub messaging (app-to-app
and app-to-person)
Application Integration Amazon SQS Message queue to decouple
application components
Application Integration AWS Step Functions Workflow orchestration —
sequences AWS services
Application Integration Amazon EventBridge Event bus — routes events,
checks message schemas
Data Store Amazon S3 Object storage
Data Store Amazon EFS Managed NFS file system for
EC2, Lambda, and containers
Data Store Amazon DynamoDB Key-value & document DB —
single-digit ms response
Data Store Amazon Neptune Serverless Graph database, scales by
usage
Data Store Amazon Aurora Serverless Relational DB — scales based
on workload
Data Store Amazon Redshift Serverless Data warehouse — no cluster
management
Data Store Amazon OpenSearch Search and log analytics without
Serverless resource provisioning
 Web Hosting AWS Amplify Host and deploy static/dynamic
web apps
CDN Amazon CloudFront Global content delivery network
Authentication Amazon Cognito User authentication and JWT
issuance

1.4 Common Serverless Three-Tier Architecture Pattern

A widely used serverless architecture for web apps combines:
• Amazon CloudFront — distributes the static front-end from an Amazon S3 bucket to the
browser
• Amazon Cognito — handles user authentication and issues a JWT (JSON Web Token)
• Amazon API Gateway — receives API requests and validates the JWT with Cognito
• AWS Lambda — runs the business logic once the token is validated
• Amazon DynamoDB — stores and retrieves application data

📷 [INSERT IMAGE: Serverless 3-Tier Architecture: CloudFront → S3 (front-end) | Cognito → API

Gateway → Lambda → DynamoDB]

💡 Key takeaways: Serverless = no server management + pay-for-value + continuous scaling + built-

in fault tolerance. Serverless is ideal for event-driven and microservice architectures.
Section 2: Architecting Serverless Microservices
2.1 What Is a Microservice?
A microservices architecture structures an application as a collection of independent, loosely
coupled services. Each service runs as an independent process, communicates through
lightweight APIs, and can be updated, deployed, and scaled independently.

📷 [INSERT IMAGE: Microservice Characteristics Diagram — Autonomous (left) vs Specialized

(right)]

Autonomous Specialized
Can be developed and deployed without affecting Performs a single business function solving a
other microservices specific problem
Scales independently Owned by a small team that chooses its own tools
Does not share code with other microservices Is stateless — enables fast instantiation and
scaling
Communicates only through well-defined APIs Has its own data store (supports ACID
transactions)

2.2 Monolith vs. Microservices — Practical Example

Consider a forum application with three processes: Users, Topics, and Messages.
Monolithic approach: All three processes are tightly coupled and run as a single service. Any
spike in one process forces the entire system to scale. A single failure can crash the whole app.
Adding features becomes more complex as the code base grows.
Microservices approach: Each process is an independent component. User Service, Topic
Service, and Message Service each run independently. They communicate via lightweight APIs
and can be scaled, deployed, and updated individually.

📷 [INSERT IMAGE: Monolith vs Microservices diagram — Users/Topics/Messages as single block

vs three separate service boxes]

2.3 Benefits of Microservices

📷 [INSERT IMAGE: Benefits of microservices icons — Agility, Reusability, Scaling, Freedom,

Resilience, Deployment]
 Benefit Explanation
Team agility Small, independent teams own their services and work quickly without
coordination overhead.
Reusable code Services can be reused as building blocks for new features — no need
to write from scratch.
Flexible scaling Each microservice scales independently to match the demand of the
feature it supports.
Technological freedom Teams choose the best runtime, language, and tool for their specific
problem.
Resilience Total service failure degrades functionality gracefully rather than
crashing the entire application.
Simplified deployment CI/CD pipelines make it easy to test, deploy, and roll back individual
services.

2.4 Microservice Serverless Patterns on AWS

📷 [INSERT IMAGE: Microservice Patterns diagram — RESTful APIs | Containers | Streaming —
each with Serverless data store]

RESTful APIs: REST (stateless communication) is a natural fit for Lambda, which is stateless
by design. Use Amazon API Gateway + AWS Lambda for a fully serverless REST microservice.
Lambda has a maximum duration of 15 minutes per invocation.
Containers: If a microservice requires more than 15 minutes to complete, use containers (AWS
Fargate) behind an Application Load Balancer with API Gateway. If serverless is not required,
Amazon ECS or Amazon EKS can replace Fargate.
Streaming: Microservices can be invoked by streaming services. AWS Lambda integrates
natively with Amazon Kinesis and scales alongside it.

2.5 Microservices in a Three-Tier Serverless Architecture

Microservices operate in the app and data tiers of the three-tier pattern — not as a standalone
full architecture. The combination of API Gateway (API layer) + Lambda (compute) +
DynamoDB (data store) is the canonical serverless microservice pattern.
📷 [INSERT IMAGE: Three-tier serverless architecture highlighting the App and Data tiers where
microservices operate]
💡 Microservices are not a replacement for the full three-tier architecture — they are the inner
workings of its app and data tiers.

💡 Key takeaways: Microservices are autonomous + specialized. Benefits include agility, reusability,
flexible scaling, technological freedom, resilience, and simplified deployment.
Section 3: Building Serverless Architectures with
AWS Lambda
3.1 Server vs. Serverless — Operational Task Comparison
The main advantage of serverless is radical reduction in operational overhead. When using
Lambda you only need to: build and deploy your app, and monitor and maintain it in production.

Operational Task Server in a VPC Serverless (Lambda)

Configure an instance ✅ Yes (your responsibility) ❌ No (AWS manages)
Update operating system (OS) ✅ Yes ❌ No
Install application platform ✅ Yes ❌ No
Build and deploy applications ✅ Yes ✅ Yes
Configure auto scaling & load ✅ Yes ❌ No
balancing
Continuously secure & monitor ✅ Yes ❌ No
instances
Monitor and maintain ✅ Yes ✅ Yes
applications

3.2 AWS Lambda — Core Concepts

📷 [INSERT IMAGE: AWS Lambda service icon and key properties card]

Property Value / Detail

What it is Event-driven compute service — runs code without provisioning or
managing servers
Memory range 128 MB minimum — 10,240 MB maximum (determines vCPU and
network bandwidth)
Max duration 15 minutes (hard AWS limit — cannot be changed)
Deployment packages .zip file archives OR container images
Pricing model Pay only for compute time consumed — no charge when code is not
running
Concurrency Lambda runs multiple instances in parallel governed by concurrency
and scaling limits
Infrastructure AWS handles server maintenance, OS updates, capacity provisioning,
auto scaling, and logging
3.3 Lambda Function Location Options
📷 [INSERT IMAGE: Lambda location diagram — Option A: Lambda Service VPC (standard region
deploy) | Option B: CloudFront regional edge cache (Lambda@Edge)]

Option A — Standard Lambda in an AWS Region

When a Lambda function is invoked, the Lambda service instantiates an isolated Firecracker
microVM on an EC2 instance inside the Lambda service VPC. Firecracker (developed by AWS)
starts a microVM in under one second. After the function runs, the VM is kept warm for the next
request. Lambda manages all network access, security rules, and VPC monitoring
automatically.

Option B — Lambda@Edge (CloudFront regional edge cache)

Lambda@Edge lets you author [Link] or Python functions in US East (N. Virginia) and deploy
them globally at CloudFront edge locations. Processing requests closer to viewers reduces
latency significantly.
Example: A retail website uses cookies to record a customer's jacket color preference.
Lambda@Edge intercepts the CloudFront request and modifies it so CloudFront returns the
jacket image in the selected color — without ever hitting the origin server.
💡 CloudFront Functions (different from Lambda@Edge) have no network access and are subject to
much smaller time and package size limits.

3.4 Connecting Lambda to Your VPC

📷 [INSERT IMAGE: Lambda VPC connection diagram — Lambda VPC → ENI (Hyperplane) →
Customer VPC → RDS Proxy + EC2 App Instance]

By default, Lambda functions run in the Lambda service VPC and cannot access resources in
your own VPCs. To connect Lambda to your VPC:
• Lambda creates Hyperplane Elastic Network Interfaces (ENIs) in your VPC when the
function is configured for VPC access.
• The Lambda VPC connects to your account VPC using VPC-to-VPC NAT (V2N) — uni-
directional (Lambda → your VPC only).
• To give Lambda internet access from inside your VPC, route outbound traffic through a
NAT Gateway in a public subnet.

Scaling bottleneck — RDS connections: Lambda functions can scale very rapidly and
saturate the connection pool of an Amazon RDS database. Solution: Use Amazon RDS Proxy,
which manages a connection pool and presents a single endpoint to Lambda. Lambda functions
connect to RDS Proxy, which has an open connection to the database ready to be used.
Supported with MySQL and Aurora.
Scaling bottleneck — EC2 app instances: Deploy the EC2 instance behind an Application
Load Balancer in an EC2 Auto Scaling group so it scales with Lambda's demand.
3.5 Lambda Invocation Types
📷 [INSERT IMAGE: Lambda invocation types diagram — Synchronous | Asynchronous | Event
Source Mappings (queues & streams)]

Synchronous Processing
The requestor makes a request and waits for a response. Lambda runs the function and returns
the result (or error) directly. Common patterns:
• Web and mobile app microservices (via Amazon API Gateway)
• Lambda function URLs — dedicated HTTPS endpoints. The URL never changes after
creation.
• Machine learning inferences
💡 Function URLs use resource-based policies for security and support CORS configuration. If the
Lambda function changes behind API Gateway, no client-side changes are needed.

📷 [INSERT IMAGE: Synchronous invocation diagram — Browser → API Gateway → Lambda |

Browser → Function URL → Lambda]

Asynchronous Processing
The requestor fires a request without waiting for a response. Lambda queues the event and
processes it separately. Use cases:
• Scheduled events (daily reports, recurring processes) — triggered by Amazon
EventBridge
• Queued messages from Amazon SQS or Amazon SNS
• Image or video transformation triggered by S3 object events
• AWS service triggers (S3, SNS invoke Lambda asynchronously)
If an AWS service lacks a direct Lambda integration, Amazon EventBridge acts as the event
bus to route the request. Errors and invocation records can be forwarded to SQS or Amazon
EventBridge for chaining.
📷 [INSERT IMAGE: Asynchronous invocation diagram — AWS service trigger or scheduled event
→ Lambda queue → Lambda function]

Event Source Mappings — Queues and Streams

An event source mapping is a Lambda resource that polls an event source (queue or stream)
and invokes Lambda with batched records. Lambda can poll:
• Amazon DynamoDB Streams
• Amazon Kinesis
• Amazon SQS
• Amazon DocumentDB
Lambda batches records together into a single payload and invokes the function. The payload
cannot exceed 6 MB. You configure the maximum batch window and payload size.
Example: When a customer order changes status to 'delivery in progress' in a DynamoDB table,
the DynamoDB stream triggers Lambda, which sends a notification to the customer and
performs financial processing.
📷 [INSERT IMAGE: Event source mapping diagram — DynamoDB Stream → Lambda service polls
→ batches records → invokes Lambda function]

3.6 Python Lambda Function Handler

The Lambda function handler is the entry point that processes events. Lambda passes two
arguments to the handler:
• event — a JSON document containing input data and invoking service data
• context — object providing methods and properties about the invocation, function, and
runtime environment

import json def lambda_handler(event, context): length = event['length']

width = event['width'] area = calculate_area(length, width) data =
{'area': area} return [Link](data) def calculate_area(length, width):
return length * width

Best practice: Keep the handler function small. Place all business logic in separate methods.
This reduces handler load times.
💡 Use Amazon Q Developer in the AWS Management Console or as an IDE plugin for on-demand
code recommendations.

3.7 Lambda Layers

📷 [INSERT IMAGE: Lambda Layers diagram — Without layers: two functions each with full
dependencies | With layers: functions share Layer 1 (custom runtime) and Layer 2
(dependencies)]

A Lambda layer is a .zip file archive containing supplementary code or data (libraries, custom
runtimes, configuration files). Benefits of using layers:
• Reduce deployment package size — dependencies go into the layer, not the function
package
• Separate function logic from dependencies — update either one independently
• Share dependencies across multiple functions — one layer, many functions
• Unlock the Lambda console code editor — only available when the deployment package
is small enough

💡 Key takeaways for Lambda: runs code without server management; can run in the Lambda VPC or
Lambda@Edge; can connect to your VPC via Hyperplane ENIs; supports synchronous,
asynchronous, and event source mapping invocations; use layers to share code dependencies.
Key Concepts Summary (Pages 1–37)

Concept Key Points

Serverless definition No server management; pay-for-value; auto-
scales; built-in fault tolerance across 3 AZs
Traditional 3-tier vs serverless EC2 tiers require OS patching, scaling config, and
monitoring by the customer; serverless eliminates
all of that
AWS serverless services Compute: Lambda, Fargate | Integration: API
Gateway, SNS, SQS, Step Functions,
EventBridge | Data: DynamoDB, S3, EFS, Aurora
Serverless
Microservice: Autonomous Independent deployment, independent scaling, no
shared code, API-only communication
Microservice: Specialized Single business function, small team, stateless,
owns its own data store
Monolith vs Microservices Monolith = tightly coupled, scales as a unit, one
failure can crash all | Microservices =
independent, resilient, individually scalable
Microservice benefits Agility, reusability, flexible scaling, tech freedom,
resilience, simplified deployment
Serverless microservice patterns RESTful APIs (API Gateway + Lambda),
Containers (Fargate), Streaming (Lambda +
Kinesis)
Lambda memory 128 MB min — 10,240 MB max; memory = vCPU
+ network bandwidth
Lambda timeout Max 15 minutes (hard limit)
Lambda@Edge Run [Link] or Python functions at CloudFront
edge locations; authored in us-east-1
Lambda VPC connection Hyperplane ENIs + V2N NAT; use RDS Proxy to
prevent connection saturation
Synchronous invocation API Gateway or function URL; waits for response;
used for web apps, APIs, ML inferences
Asynchronous invocation No wait for response; used for S3 events, SNS,
scheduled EventBridge tasks
Event source mapping Lambda polls DynamoDB Streams, Kinesis, SQS,
DocumentDB; batches records; max 6 MB
payload
Lambda function handler Entry point; receives event (JSON) + context
objects; keep handler small, business logic in
 separate methods
Lambda layers .zip with libraries/runtimes/config; shared across
functions; reduce package size; enable console
code editor
Exam Completion Record
Fill in this section once you complete the Module 14 knowledge check in AWS Academy. Paste
a screenshot of your result in the image area below.

🏆 EXAM COMPLETION RECORD 🏆

AWS Academy Cloud Architecting — Module 14: Building Serverless Architectures and
Microservices

Student Name:

Date Completed:

Score / Result:

📷 [INSERT IMAGE: Screenshot of passed exam / Knowledge Check result from AWS
Academy]

✅ I have completed and passed the Module 14 Knowledge Check!

Notes / Reflection:

AWS Academy Cloud Architecting — Module 14 Study Guide | © 2024 Amazon Web Services, Inc.