CLD120 Module 13 — Building Microservices and Serverless Architectures

Module Objective

Design a microservices or serverless architecture using AWS Lambda, Amazon API Gateway, and container orchestration services.

Modules 3–8All layers✓ built

Module 9Elasticity & HA✓ done

Module 10Automation✓ done

Module 11Caching✓ done

Module 12Decoupling✓ done

Module 13Serverlessyou are here

Module 14Disaster recovery

Builds on Modules 4 and 12: microservices and serverless designs apply decoupling (Module 12) to the compute layer (Module 4). Also draws on Cloud Foundations Modules 6 and 9, and Amazon Cognito from Module 8.

Monolithic vs. Microservices Revisited

Monolith

One café application tier
ordering + inventory + notifications

Deployed and scaled as a single unit

→

Microservices

Ordering

Inventory

Notifications

Each owned, deployed, and scaled independently

Microservices aren’t free. They trade deployment simplicity for independent scaling and fault isolation — a deliberate choice with real operational costs, not an automatic improvement.

AWS Lambda in Depth

Each function has one narrow job, triggered by an event.

Trigger Source	Example Use in the Café Architecture
Amazon API Gateway	Handles an HTTP request from the ordering app
Amazon SQS	Processes a queued order from the Module 12 decoupled design
Amazon S3 event	Automatically resizes an uploaded product image

Lambda fits naturally with decoupling. Functions are short-lived and stateless, so they pair well with the queue- and event-based patterns from Module 12 — a message or event triggers exactly the function that handles it.

Amazon API Gateway

Ordering app
HTTP requests

→

API Gateway
routing · authorization · throttling

→

POST /orders → Lambda
GET /menu → Lambda

API Gateway Feature	What It Provides
Request routing	Maps each incoming HTTP request to the correct backend Lambda function
Authorization	Integrates with IAM or Amazon Cognito (Module 8) to control who can call an API
Throttling	Protects backend services from request spikes

API Gateway + Lambda is a common serverless pair — one of the most frequently referenced serverless patterns on the SAA-C03 exam.

Container Orchestration Revisited

Amazon ECS, Amazon EKS, and AWS Fargate suit microservices that need more control over runtime and dependencies than Lambda allows — without managing EC2 instances directly.

AWS Lambda

Short-lived, event-driven tasks
no runtime to manage

ECS / EKS with Fargate

Longer-running processes, or specific runtime dependencies
more control, still no servers to manage

Lambda vs. containers is about fit, not superiority. Neither is inherently “more serverless” or better architected.

Serverless Application Patterns

Users

→

API Gateway
front door

→

Lambda
business logic

→

DynamoDB
low-latency data

Lambda ↔ SQS · SNS · EventBridge ↔ Lambda
asynchronous communication between services (Module 12)

A reusable design: this combination underlies many production serverless applications on AWS — recognize it as a pattern rather than reasoning through each service from scratch.

Key Terms

Microservice: An independently deployable service with one narrow responsibility within a larger application
Amazon API Gateway: A managed service handling routing, authorization, and throttling for APIs, often in front of Lambda
Serverless microservices pattern: API Gateway, Lambda, and DynamoDB, connected through SQS, SNS, or EventBridge
Event-driven trigger: A source — API call, queue message, or S3 event — that invokes a Lambda function

Review Questions

What operational cost does splitting a monolith into microservices introduce, even as it improves independent scalability?
What are three different event sources that can trigger an AWS Lambda function?
What role does Amazon API Gateway typically play in front of a set of Lambda functions?
When might a container-based microservice on ECS or EKS be a better fit than a Lambda function?