This chapter covers microservices architecture on AWS—a core concept for the CLF-C02 exam under Domain 1: Cloud Concepts (Objective 1.2). Understanding microservices is critical because AWS itself is built on microservices, and many exam scenarios test your ability to distinguish between monolithic and microservices approaches. This objective carries approximately 8-10% of the exam weight. By the end of this chapter, you'll grasp what microservices are, how AWS services like Amazon ECS, EKS, Lambda, API Gateway, and Step Functions enable them, and—most importantly—how to answer exam questions that ask you to identify the benefits, trade-offs, and appropriate use cases for microservices on AWS.
Jump to a section
Imagine a restaurant kitchen that serves hundreds of meals each night. In a traditional 'monolithic' kitchen, one giant team prepares every dish from appetizers to desserts in a single, crowded workspace. If the dessert station breaks, the entire kitchen slows down—even salads and steaks suffer. Now imagine a modern kitchen divided into specialized stations: one for grilling, one for salads, one for desserts, and one for drinks. Each station operates independently with its own ingredients, tools, and chef. The grill station doesn't need to know how desserts are made; it only communicates via a ticket system (an API) when an order needs a steak. If the dessert station catches fire, the other stations keep working—customers still get their salads and steaks. The dessert station can be fixed or replaced without shutting down the whole kitchen. This is microservices: each service (station) runs its own process, communicates via lightweight protocols (the tickets), can be deployed independently, and is owned by a small team. AWS services like Amazon ECS, EKS, and Lambda are the kitchen managers that orchestrate these stations, scaling them up or down based on demand. The key mechanism: each microservice has its own database (like each station has its own fridge), so if one fails, it doesn't corrupt the others. This isolation is what makes microservices resilient and scalable.
What Are Microservices and What Problem Do They Solve?
Microservices is an architectural style where a single application is composed of many loosely coupled, independently deployable services. Each service is self-contained, owns its own data, and communicates with others via well-defined APIs (typically HTTP/REST or messaging). This contrasts with the monolithic architecture, where all functionality is packaged into a single deployable unit.
The problem microservices solve: In a monolith, as the application grows, it becomes difficult to maintain, scale, and deploy. A small change requires rebuilding and deploying the entire application. Scaling means scaling everything, even parts that don't need it. A bug in one module can crash the whole system. Microservices address these issues by breaking the application into smaller, manageable pieces. Each service can be developed, deployed, and scaled independently. Teams can work on different services simultaneously, using different technologies if needed. This aligns with DevOps practices and enables continuous delivery.
How Microservices Work on AWS
On AWS, microservices are typically deployed using containers or serverless functions. Containers (via Amazon ECS or Amazon EKS) package the service code and dependencies into a portable image. Serverless functions (AWS Lambda) run code in response to events without provisioning servers.
Communication between services: Services communicate through APIs (often using Amazon API Gateway as a front door) or through asynchronous messaging with Amazon SQS (queues) or Amazon SNS (pub/sub). For example, an order service might send a message to a queue, and a fulfillment service picks it up. This decoupling ensures that if one service is slow, the other is not blocked.
Service discovery: Services need to find each other. AWS Cloud Map or service meshes like AWS App Mesh provide service discovery and traffic routing.
Data management: Each microservice has its own database (polyglot persistence). For example, a user service might use Amazon DynamoDB (NoSQL), while a reporting service uses Amazon RDS (SQL). This prevents tight coupling at the data layer.
Key AWS Services for Microservices
Amazon ECS (Elastic Container Service): A fully managed container orchestration service. You define tasks (your microservices) and ECS places them on EC2 instances or Fargate (serverless compute). ECS integrates with AWS services like ALB for load balancing and CloudWatch for logging.
Amazon EKS (Elastic Kubernetes Service): Managed Kubernetes. If you need portability across clouds or on-premises, EKS gives you standard Kubernetes APIs. It's more complex than ECS but offers more flexibility.
AWS Lambda: For event-driven microservices. Each Lambda function is a microservice. You pay per invocation and duration. Lambda is ideal for short-lived, stateless tasks.
Amazon API Gateway: Creates RESTful or WebSocket APIs that front your microservices. It handles authentication, throttling, caching, and request transformation.
AWS Step Functions: Coordinates multiple microservices into a workflow. It's a state machine that can handle retries, error handling, and parallel execution.
Amazon SQS and SNS: Decouple microservices. SQS for message queues, SNS for pub/sub notifications.
AWS App Mesh: Service mesh that provides observability, traffic control, and security for microservices.
Tiers, Configurations, and Pricing Models
Compute options: - EC2 (under ECS): You manage the underlying EC2 instances. You pay for EC2 instances (per second) plus ECS no additional cost. - Fargate (launch type for ECS/EKS): Serverless compute for containers. You pay for vCPU and memory resources allocated per task, per second. No need to manage servers. - Lambda: Pay per request and duration. Free tier: 1 million requests and 400,000 GB-seconds per month.
Orchestration: - ECS: No additional cost beyond compute. - EKS: $0.10 per hour per cluster (plus compute and other resources).
API Gateway: - REST API: Pay per API call (starting at $3.50 per million) plus data transfer. - HTTP API: Cheaper, simpler, for HTTP-only APIs. - WebSocket API: Pay per message and connection duration.
Messaging: - SQS: Standard queue: $0.40 per million requests. FIFO: $0.50 per million requests. - SNS: $0.50 per million publishes, plus $0.06 per 100,000 notification deliveries.
Comparison to On-Premises or Competing Approaches
On-premises microservices require managing physical servers, container orchestration (like Kubernetes), networking, storage, and monitoring. You must provision for peak capacity, leading to low utilization. AWS abstracts this: you get elastic scaling, pay-as-you-go, and managed services. Compared to a monolith, microservices introduce complexity: network latency, distributed tracing, eventual consistency, and the need for DevOps automation. AWS services like X-Ray (tracing), CloudWatch (monitoring), and CodeDeploy (deployment) help manage this complexity.
When to Use Microservices vs Alternatives
Use microservices when: - The application is large and complex with multiple domains. - Different parts have different scaling requirements (e.g., a search service that spikes vs. a user profile service that is steady). - You need to deploy frequently and independently. - Teams are organized around business capabilities (e.g., a team for payments, another for inventory).
Avoid microservices when: - The application is simple (e.g., a blog or a CRUD app). A monolith is simpler and faster to develop. - The team is small and lacks DevOps expertise. - You cannot tolerate network latency between services. - Strong transactional consistency across services is required (distributed transactions are hard).
Alternatives: - Monolithic: Single deployment unit. Easier to develop and test initially. - Service-oriented architecture (SOA): Similar but heavier, often using enterprise service buses. Microservices are a finer-grained evolution. - Serverless monolith: A single Lambda function that does everything—not recommended for large apps.
AWS Best Practices for Microservices
Design for failure: Use retries, circuit breakers, and dead-letter queues.
Stateless services: Store session state in external stores like ElastiCache or DynamoDB.
Use CI/CD: Automate builds, tests, and deployments with AWS CodePipeline and CodeBuild.
Implement observability: Use CloudWatch Logs, metrics, and X-Ray for tracing.
Secure with IAM: Each service should have least-privilege permissions.
Use infrastructure as code: AWS CloudFormation or CDK to provision resources.
Exam Note
CLF-C02 focuses on the *concepts* of microservices: benefits (scalability, agility, fault isolation), trade-offs (complexity, network overhead), and how AWS services support them. You won't be asked to deploy microservices, but you must recognize scenarios where microservices are appropriate and identify which AWS services enable them. Common exam questions ask: "Which AWS service can be used to decouple microservices?" (Answer: SQS or SNS) or "What is a benefit of microservices over a monolith?" (Answer: independent deployability).
Design the Microservice Boundaries
Identify business capabilities (e.g., user management, product catalog, order processing). Each becomes a separate microservice. Define clear API contracts (REST or GraphQL). For example, an e-commerce app might have services: UserService, ProductService, OrderService, PaymentService. Each service owns its data—UserService uses DynamoDB, ProductService uses RDS. Define how services communicate: synchronous (HTTP via API Gateway) or asynchronous (SQS/SNS). This step determines the level of coupling. On the exam, expect questions that test your understanding of service boundaries: a service should not share a database with another service.
Set Up the Container or Serverless Environment
For containerized microservices, create an Amazon ECS cluster (or EKS cluster). Define task definitions with Docker images stored in Amazon ECR. For serverless, create Lambda functions using the AWS console or CLI. Example: To create an ECS cluster using the AWS CLI: `aws ecs create-cluster --cluster-name my-microservices-cluster`. For Lambda: `aws lambda create-function --function-name ProductService --runtime python3.9 --role arn:aws:iam::123456789012:role/lambda-role --handler index.handler --zip-file fileb://function.zip`. Behind the scenes, AWS provisions the control plane and schedules tasks. Default limits: 500 ECS clusters per region, 1000 tasks per service (can be increased).
Create API Gateway as the Front Door
Create an API Gateway REST or HTTP API that routes requests to appropriate microservices. Define resources and methods (e.g., GET /products integrates with ProductService). Configure request validation, throttling (default 10,000 requests per second per API), and authentication (e.g., Cognito or IAM). API Gateway can transform requests/responses using mapping templates. Behind the scenes, API Gateway manages the API lifecycle, caching (TTL default 300 seconds), and can generate SDKs. On the exam, know that API Gateway is used to create a unified API for multiple microservices.
Implement Service Communication and Decoupling
For synchronous calls, use API Gateway or Application Load Balancer (ALB) with target groups pointing to ECS services or Lambda. For asynchronous decoupling, create an SQS queue for each service that needs to receive messages. For example, OrderService publishes an order-created message to SQS; InventoryService polls the queue. Use SNS for fan-out: OrderService publishes to an SNS topic, and multiple subscribers (e.g., EmailService, AnalyticsService) receive the notification. Set up dead-letter queues for failed messages. This step is crucial for exam questions about decoupling: SQS and SNS are the primary services.
Deploy and Scale Microservices Independently
Use AWS CodePipeline and CodeDeploy to automate deployments. For ECS, use blue/green deployments with CodeDeploy. For Lambda, use versions and aliases. Configure auto scaling: ECS services can use target tracking scaling policies based on CPU/memory (default cooldown 300 seconds). Lambda scales automatically per invocation but has a concurrency limit (default 1000 per region). Use Application Auto Scaling for ECS. Behind the scenes, AWS monitors metrics and adjusts capacity. On the exam, know that microservices can be scaled independently—a key advantage over monoliths.
Scenario 1: E-commerce Platform A large online retailer migrated from a monolithic Java application to microservices on AWS. They broke the monolith into 30+ services: Product Catalog, Shopping Cart, Order Management, Payment, Shipping, Recommendations, and User Profiles. Each service runs in its own ECS Fargate task. The Product Catalog service uses DynamoDB for fast reads; the Order Management service uses RDS PostgreSQL for transactional integrity. API Gateway exposes a unified API to the mobile app and website. SQS decouples Order Management from Shipping: when an order is placed, a message goes to a queue; the Shipping service picks it up and processes it asynchronously. This allows the checkout flow to be fast even if Shipping is slow. Cost: They saved 40% compared to running the monolith on oversized EC2 instances because they can scale each service independently. Misconfiguration: Initially, they set no throttling on API Gateway, and a flash sale caused a spike that overwhelmed the Payment service, leading to failed transactions. They added throttling and a circuit breaker pattern using AWS App Mesh.
Scenario 2: Media Streaming Backend A video streaming startup uses microservices to handle video upload, transcoding, metadata management, and user subscriptions. Upload service uses Lambda and S3 presigned URLs. Transcoding service uses AWS Elemental MediaConvert triggered by S3 events. Metadata service uses DynamoDB. User subscription service uses API Gateway + Lambda + Cognito. Step Functions coordinates the upload-to-publish workflow: upload, transcode, update metadata, notify user via SNS. This decoupled architecture allowed them to scale transcoding independently during peak upload times. Cost: They use Lambda for infrequent tasks (user subscriptions) and Fargate for steady-state transcoding. Misunderstanding: They initially tried to use a single Lambda function for the entire workflow, which hit the 15-minute timeout limit. They refactored into Step Functions with smaller Lambda functions.
Scenario 3: Financial Services Compliance A bank built a microservices platform for trade processing. Each service (trade capture, risk calculation, reporting, settlement) runs in its own VPC with strict security groups. They use AWS PrivateLink to connect services across accounts. Each service has its own database (Aurora for trade capture, DynamoDB for reporting). They use SQS FIFO queues to ensure exactly-once processing for trade messages. AWS KMS encrypts data at rest. They use AWS Config to enforce compliance rules. Misconfiguration: They initially shared a database between services, leading to schema changes breaking other services. They refactored to separate databases. Cost: Higher due to multiple databases and VPC endpoints, but necessary for compliance.
What CLF-C02 Tests on Objective 1.2 (Microservices) The exam tests your understanding of the *conceptual* differences between monolithic and microservices architectures, the benefits and trade-offs, and which AWS services enable microservices. You will not be asked to write code or configure services. Expect questions that present a scenario and ask: "Which architecture would be most appropriate?" or "Which AWS service can be used to decouple components?"
Common Wrong Answers and Why Candidates Choose Them 1. Choosing Amazon EC2 as the primary service for microservices. Candidates see EC2 as a general compute service and assume it's the best fit. However, for microservices, managed container services (ECS, EKS) or serverless (Lambda) are more appropriate because they handle orchestration, scaling, and deployment. EC2 requires manual management, which contradicts the agility goal of microservices. 2. Selecting Amazon RDS as a shared database for all microservices. In a monolith, a single database is common. But microservices should each have their own database to avoid tight coupling. The exam tests this: if a scenario describes services sharing a database, it's likely a monolith, not microservices. 3. Thinking that microservices always use synchronous communication. Many candidates assume APIs are always synchronous. However, microservices often use asynchronous messaging (SQS, SNS) to improve resilience. The exam may ask how to decouple services—answer is SQS or SNS, not direct API calls. 4. Confusing API Gateway with Elastic Load Balancer. Both route traffic, but API Gateway is specifically for APIs (REST, WebSocket) and can handle authentication, throttling, and transformation. ALB is for HTTP/HTTPS load balancing to targets. For microservices frontend, API Gateway is the typical choice.
Specific Service Names and Terms on the Exam - Amazon ECS, Amazon EKS, AWS Fargate, AWS Lambda - Amazon API Gateway - Amazon SQS, Amazon SNS - AWS Step Functions - AWS App Mesh - Amazon DynamoDB (per-service database) - Monolithic vs. microservices - Loose coupling, independent deployment, fault isolation
Tricky Distinctions - ECS vs. EKS: Both orchestrate containers. ECS is simpler, AWS-native. EKS is Kubernetes-standard, more portable. The exam may ask which is AWS's native container orchestration (ECS). - SQS vs. SNS: SQS is for point-to-point queuing; SNS is for pub/sub. Both decouple, but SNS pushes to multiple subscribers. - Lambda vs. Fargate: Lambda is for short, event-driven functions (max 15 min). Fargate runs containers for longer durations. Choose Lambda for simple, stateless tasks; Fargate for complex or long-running services.
Decision Rule for Multiple-Choice Questions If a question asks about decoupling, look for SQS or SNS. If it asks about independent scaling, look for microservices. If it asks about a unified API for multiple services, look for API Gateway. If it asks about coordinating a workflow across services, look for Step Functions. Eliminate options that suggest a single database or a monolith when the scenario emphasizes agility and independent deployment.
Microservices are loosely coupled, independently deployable services that each own their own data.
AWS services that enable microservices include Amazon ECS, EKS, Lambda, API Gateway, SQS, SNS, and Step Functions.
Key benefits: independent scaling, fault isolation, faster deployments, and team autonomy.
Key trade-offs: increased complexity, network latency, and need for distributed tracing and DevOps automation.
On the CLF-C02 exam, recognize scenarios where microservices are appropriate (large, complex apps) vs monoliths (simple apps).
Decoupling is achieved using SQS (queues) or SNS (pub/sub), not direct HTTP calls.
Each microservice should have its own database; sharing a database is a sign of a monolith.
API Gateway provides a unified API frontend for multiple microservices.
These come up on the exam all the time. Here's how to tell them apart.
Monolithic Architecture
Single codebase and deployment unit
Scaling requires scaling the entire application
Tight coupling; a bug in one module can crash the whole app
Simpler development and testing initially
Shared database across all components
Microservices Architecture
Multiple independent services, each with its own codebase
Each service can be scaled independently based on demand
Fault isolation; failure in one service does not affect others
More complex due to network communication and distributed data
Each service owns its own database (polyglot persistence)
Mistake
Microservices always use containers.
Correct
Microservices can also be implemented using serverless functions (AWS Lambda) or even EC2 instances. Containers are common but not mandatory. The defining characteristic is independent deployability and ownership of data, not the packaging technology.
Mistake
Microservices require Kubernetes.
Correct
AWS offers Amazon ECS as a simpler, fully managed alternative to Kubernetes. Many production microservices run on ECS with Fargate. Kubernetes (EKS) is an option but adds complexity. The exam does not require Kubernetes knowledge.
Mistake
Each microservice must have its own public IP and be directly accessible.
Correct
Microservices are typically internal and communicate through private networks (VPC). API Gateway or a load balancer provides the public endpoint. Direct exposure increases attack surface and is not a best practice.
Mistake
Microservices eliminate the need for a database.
Correct
Each microservice often has its own database, but databases are still needed. The difference is that each service owns its data store, leading to polyglot persistence (using different database types for different needs).
Mistake
Microservices are always faster than monoliths.
Correct
Microservices add network latency between services. For simple applications, a monolith can be faster. The benefit of microservices is in scalability, maintainability, and team autonomy, not raw performance.
In a monolithic architecture, all components are packaged into a single deployable unit, often sharing a single database. Scaling requires scaling the entire application. Microservices break the application into multiple independent services, each with its own database and deployable separately. On AWS, a monolith might run on a single EC2 instance or Elastic Beanstalk, while microservices use ECS, EKS, or Lambda. The exam tests this distinction: a scenario with independent scaling and fault isolation points to microservices.
Amazon SQS (Simple Queue Service) and Amazon SNS (Simple Notification Service) are the primary services for decoupling microservices. SQS provides a message queue for point-to-point communication, allowing services to process messages asynchronously. SNS provides a pub/sub model where multiple subscribers receive notifications. Both prevent services from being tightly coupled. On the exam, if a question asks how to decouple services, choose SQS or SNS, not direct API calls.
No. Microservices can be implemented using AWS Lambda (serverless functions) or even EC2 instances. Containers (via ECS or EKS) are a popular choice because they package dependencies, but Lambda is simpler for event-driven, stateless services. The exam does not require you to choose a specific technology; it focuses on the architectural concept.
Amazon API Gateway acts as a single entry point for client applications to access multiple microservices. It handles request routing, authentication, throttling, caching, and response transformation. This allows microservices to be internal and not directly exposed. On the exam, API Gateway is the correct answer when a scenario describes a unified API for a microservices-based application.
No, best practice is that each microservice owns its own database. Sharing a database creates tight coupling, schema change conflicts, and scaling bottlenecks. This is a key exam point: if a scenario describes services sharing a database, it is likely a monolith, not microservices. Each microservice should use its own database (e.g., DynamoDB for one, RDS for another).
AWS Step Functions coordinates multiple microservices into a workflow. It defines a state machine that can invoke Lambda functions, run ECS tasks, or make API calls in sequence or parallel. It handles retries, error handling, and waits. For example, an order processing workflow might call payment, inventory, and shipping services. On the exam, Step Functions is the answer when a scenario requires orchestrating a multi-step process across services.
Each microservice can be scaled independently based on its own demand. For ECS services, you can use target tracking scaling policies based on CPU or memory. For Lambda, scaling is automatic but subject to concurrency limits (default 1000 per region). For API Gateway, you can enable throttling and caching. This independent scaling is a major advantage over monoliths, where the entire application must scale together.
You've just covered Microservices on AWS — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?