Serverless and Microservices
Security considerations for serverless computing (Functions as a Service) and microservices architecture. Covers function security, API gateways, service mesh, service-to-service authentication, and distributed system challenges.
Understanding Serverless and Microservices
Serverless computing and microservices represent modern architectural approaches that change how applications are built and secured. Instead of monolithic applications, functionality is distributed across small, independent components.
Serverless (Functions as a Service): • Code runs in response to events • No server management • Provider handles infrastructure • Pay per execution
Microservices: • Application split into small services • Each service has single responsibility • Services communicate via APIs • Independent deployment and scaling
In 2020, a misconfigured AWS Lambda function at a major company exposed customer data because the function had overly permissive IAM permissions—illustrating why least privilege is critical even in serverless environments.
Both architectures introduce new security considerations around service communication, identity, and distributed systems.
Why This Matters for the Exam
Serverless and microservices are tested on SY0-701 as they're increasingly common architectures. Questions cover security implications, API security, and service-to-service communication.
Understanding these architectures helps with modern application security and cloud-native development. Traditional security approaches don't directly apply.
The exam tests awareness of unique security challenges and appropriate controls for these architectures.
Deep Dive
What Are the Security Risks of Serverless Computing?
Serverless Characteristics:
- •Functions execute on demand
- •Short-lived execution (seconds to minutes)
- •Provider manages underlying infrastructure
- •Event-driven (HTTP, queue, schedule triggers)
Security Considerations:
| Aspect | Security Implication |
|---|---|
| No server management | Less OS patching, but less control |
| Short execution | Difficult for persistent threats |
| Event triggers | Input validation critical |
| Third-party dependencies | Vulnerable libraries |
| Function permissions | Least privilege essential |
Serverless Risks:
- •Overprivileged function roles
- •Insecure function configurations
- •Vulnerable dependencies in packages
- •Event injection attacks
- •Sensitive data in environment variables
Function Security Best Practices:
# BAD - Overprivileged
Role: Admin access to all AWS services
# GOOD - Least privilege
Role: Read access to specific S3 bucket,
Write access to specific DynamoDB tableHow Do You Secure Microservices Communication?
Security Challenges:
| Challenge | Description |
|---|---|
| Service-to-service auth | How services trust each other |
| API security | Securing many endpoints |
| Data consistency | Distributed data management |
| Attack surface | Many services = many targets |
| Visibility | Monitoring distributed calls |
Service-to-Service Authentication Methods:
- •Mutual TLS (mTLS)
- •Service tokens (JWT)
- •Service mesh identity
- •API keys (less secure)
What Is an API Gateway and Why Is It Important?
API gateway is the central entry point for all API traffic.
API Gateway Security Functions:
| Function | Security Benefit |
|---|---|
| Authentication | Verify identity before reaching services |
| Authorization | Enforce access policies |
| Rate limiting | Prevent abuse and DDoS |
| Input validation | Block malformed requests |
| Logging | Centralized audit trail |
| SSL termination | Encrypt external traffic |
API Gateway Security Controls:
- •Centralized authentication/authorization
- •Request validation and sanitization
- •Throttling and rate limiting
- •TLS for all external communication
- •WAF integration for attack prevention
What Is a Service Mesh and How Does It Secure Microservices?
A service mesh is an infrastructure layer for service-to-service communication.
Service Mesh Components:
- •Sidecar proxies (handle all traffic)
- •Control plane (manages configuration)
- •Data plane (actual traffic flow)
Service Mesh Security Features:
- •Automatic mTLS between services
- •Service identity and authentication
- •Traffic encryption
- •Access policies
- •Observability and monitoring
Popular Service Meshes:
- •Istio
- •Linkerd
- •Consul Connect
- •AWS App Mesh
Service Mesh Benefits:
Without mesh: Each service implements own security
With mesh: Security handled by infrastructure
- mTLS automatic
- Identity automatic
- Policies centralizedWhat Is mTLS and Why Does It Matter?
Mutual TLS (mTLS):
- •Standard TLS: Only client verifies server
- •Mutual TLS: BOTH sides verify each other
mTLS in Microservices:
- •Every service has a certificate
- •Services authenticate before communicating
- •All traffic encrypted
- •Prevents service impersonation
Zero Trust for Microservices:
- •Never trust, always verify
- •Authenticate every service call
- •Encrypt all traffic
- •Least privilege access
- •Continuous verification
How CompTIA Tests This
Example Analysis
Scenario: A company's microservices application is breached. Attackers compromise one service and use its credentials to access other internal services, eventually reaching the database service and exfiltrating customer data.
Analysis - Microservices Security Failures:
What Happened:
- 1.Single service compromised (initial access)
- 2.Service had broad access to other services
- 3.No service-to-service authentication required
- 4.Lateral movement to database service
- 5.Data exfiltration
Security Failures:
| Failure | Impact |
|---|---|
| No service isolation | Compromise spread easily |
| No mTLS | Services trusted any request |
| Overprivileged access | Compromised service could reach DB |
| No segmentation | Flat network between services |
What Should Have Been Implemented:
Service Mesh / mTLS:
- •Each service has identity
- •Service-to-service encryption
- •Mutual authentication required
Least Privilege:
- •Service A can only talk to Service B
- •Explicit allow policies, default deny
API Gateway:
- •Centralized authentication
- •Rate limiting
- •Anomaly detection
Zero Trust Architecture:
- •No implicit trust between services
- •Every request authenticated
- •Continuous verification
Key insight: Microservices increase attack surface. Without proper service identity and access controls, compromising one service compromises all.
Key Terms
Common Mistakes
Exam Tips
Memory Trick
Think of microservices like a restaurant kitchen:
Without security controls: Every cook can walk into any station, grab any ingredient, and use any equipment. One bad actor, and they can contaminate everything.
With API Gateway: There's a single door into the kitchen with a host checking IDs and limiting how many orders come in (authentication + rate limiting).
With Service Mesh (mTLS): Every cook wears a name badge that other cooks verify before handing over ingredients. No badge, no ingredients.
Serverless is like hiring gig workers: You don't manage their cars or phones (infrastructure), but you're still responsible for what tasks you assign them (permissions) and what information you give them (data).
The "Lambda Rule": Just because you don't see the server doesn't mean you can give admin access. Serverless + overprivileged = breach waiting to happen.
Test Your Knowledge
Q1.A company uses AWS Lambda functions. What security control should be applied to limit what resources each function can access?
Q2.What infrastructure component provides automatic mutual TLS between microservices?
Q3.What is the PRIMARY security function of an API gateway in a microservices architecture?
Want more practice with instant AI feedback?
Continue Learning
Ready for the Exam?
See exactly where you stand on this concept and 182 others.
99% pass rate · Pass guarantee