Task Statement 2.1: Design scalable and loosely coupled architectures.
📘AWS Certified Solutions Architect – (SAA-C03)
1. What is Serverless?
Serverless is a cloud computing model where:
- You do not manage servers
- AWS automatically handles:
- Infrastructure
- Scaling
- Availability
- Patching
You only focus on writing and running code.
Key AWS Serverless Services
- AWS Lambda → Run code without servers
- Amazon API Gateway → Create and manage APIs
- Amazon DynamoDB → Serverless database
- Amazon S3 → Storage with event triggers
- Amazon EventBridge → Event-driven integration
- AWS Step Functions → Orchestrate workflows
- Amazon SNS → Notifications
- Amazon SQS → Decoupling via queues
2. Key Characteristics of Serverless
Understanding these helps you decide when to use it:
2.1 No Server Management
- No EC2 instances
- No OS-level management
2.2 Automatic Scaling
- Scales up and down automatically
- Handles sudden traffic spikes without manual intervention
2.3 Pay-per-Use Pricing
- You pay only:
- When code runs (Lambda)
- Per request or execution time
- No cost when idle
2.4 Event-Driven Execution
- Functions run only when triggered
- Common triggers:
- API calls
- File uploads
- Database changes
- Queue messages
3. When to Use Serverless (Exam-Critical)
3.1 Event-Driven Architectures
Use serverless when your system reacts to events.
Example (IT context):
- File uploaded to Amazon S3
- Automatically triggers AWS Lambda
- Processes file and stores result in Amazon DynamoDB
Why serverless?
- No need for continuous running servers
- Efficient and cost-effective
3.2 Variable or Unpredictable Workloads
Use serverless when:
- Traffic is spiky
- Requests are inconsistent
Why?
- Lambda scales automatically
- No over-provisioning or under-provisioning
3.3 Microservices Architectures
Serverless fits well with small, independent services.
Pattern:
- Each microservice = one or more Lambda functions
- API exposed via Amazon API Gateway
Benefits:
- Loose coupling
- Independent deployment
- Fine-grained scaling
3.4 Short-Lived Tasks (Stateless Processing)
Use serverless for:
- Tasks that run for a short duration
- No need to maintain session state
Examples:
- Data transformation
- Log processing
- API request handling
3.5 Backend for APIs (Serverless APIs)
Use serverless to build APIs:
Architecture:
- Client → API Gateway → Lambda → Database
Benefits:
- No backend server management
- Scales automatically
- Cost-efficient for low/medium traffic
3.6 Real-Time File Processing
Use when:
- Files are uploaded frequently
- Processing must start immediately
Flow:
- Upload → Amazon S3
- Event → AWS Lambda
- Output stored or forwarded
3.7 Decoupled Architectures
Serverless works well with messaging services:
- Amazon SQS → buffering
- Amazon SNS → fan-out
- Amazon EventBridge → event routing
Why?
- Improves fault tolerance
- Services communicate asynchronously
3.8 Workflow Orchestration
Use serverless for multi-step processes:
- Use AWS Step Functions
- Coordinate multiple Lambda functions
Benefits:
- Error handling
- Retry logic
- State management
3.9 Rapid Development and Prototyping
Serverless is ideal when:
- You need to build quickly
- No infrastructure setup is desired
4. Serverless Architectural Patterns (Exam Focus)
4.1 Event-Driven Pattern
- Events trigger Lambda
- Common services:
- S3
- EventBridge
- DynamoDB Streams
4.2 API-Driven Pattern
- API Gateway → Lambda → Database
4.3 Stream Processing Pattern
- Data streams processed in real time
- Services:
- Amazon Kinesis
- Lambda consumers
4.4 Queue-Based Pattern
- Producers send messages to SQS
- Lambda processes messages
4.5 Fan-Out Pattern
- SNS distributes messages to multiple subscribers
- Each triggers separate Lambda functions
4.6 Orchestration Pattern
- Step Functions control flow across services
5. When NOT to Use Serverless (Very Important for Exam)
5.1 Long-Running Processes
- Lambda has execution limits (max ~15 minutes)
Use alternatives:
- EC2
- Containers (ECS/EKS)
5.2 Stateful Applications
- Serverless is stateless by design
- Not suitable for:
- In-memory sessions
- persistent connections
5.3 High, Constant Workloads
- If workload is steady:
- EC2 or containers may be cheaper
5.4 Low-Latency Requirements (Cold Starts)
- Lambda may introduce cold start delay
Not ideal for:
- Ultra-low latency systems
5.5 Complex Compute or Custom OS Requirements
- If you need:
- GPU
- Custom OS configs
→ Use EC2 or containers
6. Advantages of Serverless
- No infrastructure management
- Automatic scaling
- Built-in high availability
- Pay-per-use pricing
- Faster development
7. Limitations of Serverless
- Execution time limits
- Cold starts
- Debugging complexity
- Vendor lock-in
- Limited control over environment
8. Exam Tips (Highly Important)
You should choose serverless when:
- Event-driven system is required
- Workload is unpredictable
- Need automatic scaling
- Want minimal operational overhead
- Building microservices or APIs
Avoid serverless when:
- Long-running tasks
- Constant heavy workloads
- Need full OS control
- Require persistent state
9. Quick Decision Guide
| Requirement | Use Serverless? |
|---|---|
| Event-based processing | ✅ Yes |
| Spiky traffic | ✅ Yes |
| Stateless APIs | ✅ Yes |
| Real-time file processing | ✅ Yes |
| Long-running jobs | ❌ No |
| Stateful systems | ❌ No |
| Constant workload | ❌ Usually No |
Final Summary
Serverless is best when you need:
- Automatic scaling
- Event-driven execution
- Low operational effort
- Cost efficiency for variable workloads
It is a core concept in SAA-C03, especially in:
- Event-driven design
- Microservices
- Loose coupling
