Cloud Technology and Services
Compute, Containers, Serverless, and Scaling
CoreSelect virtual servers, managed application platforms, container orchestration, or serverless compute, then separate capacity scaling from traffic distribution.
Aligned to the current CLF-C02 exam guide, verified August 15, 2026.
Why this matters
Compute questions are designed around control, packaging, and operating responsibility. The service name follows from those requirements.
Must Know
- Amazon EC2 provides resizable virtual servers and guest operating-system control. Instance families emphasize needs such as general purpose, compute, memory, storage, or accelerated computing.
- AWS Lambda runs event-driven functions without the customer provisioning servers. AWS Fargate runs containers without the customer managing container hosts.
- Amazon ECS is AWS-native container orchestration. Amazon EKS provides managed Kubernetes control planes. Both can use EC2 or supported Fargate capacity.
- AWS Auto Scaling adds or removes capacity in response to demand or schedules. Elastic Load Balancing distributes incoming traffic across healthy targets.
- AWS Elastic Beanstalk simplifies deployment of supported applications while retaining visible underlying resources; Lightsail offers simplified bundles for straightforward workloads; AWS Batch schedules batch computing jobs.
Compare and Distinguish
- EC2 vs Lambda: EC2 provides server and OS control; Lambda runs functions without server management.
- Lambda vs Fargate: Lambda runs event-driven functions; Fargate supplies serverless compute for containers.
- ECS vs EKS: ECS uses AWS-native orchestration; EKS is for Kubernetes compatibility and tooling.
- Orchestrator vs compute: ECS and EKS organize containers; Fargate or EC2 supplies the capacity that runs them.
- Auto Scaling vs load balancing: Auto Scaling changes capacity; a load balancer spreads requests among healthy targets.
Scenario examples
- Scenario: Code must run whenever an object is uploaded, and no server administration is desired. Think: AWS Lambda.
- Scenario: A team has container images and wants to run them without managing worker nodes. Think: Use AWS Fargate with Amazon ECS or Amazon EKS.
- Scenario: A Kubernetes team wants a managed control plane. Think: Amazon EKS.
- Scenario: An EC2 web tier must add capacity during a traffic spike and distribute requests across healthy instances. Think: Auto Scaling plus Elastic Load Balancing.
Exam traps
- Serverless does not mean there are no servers; it means the customer does not provision and manage the underlying servers.
- Fargate is not a container registry or a separate orchestrator.
- A load balancer does not create new capacity, and Auto Scaling does not itself distribute each incoming request.
- An EC2 purchasing option changes price or capacity characteristics, not the fundamental purpose of EC2.
Key takeaways
- OS control: EC2. Event-driven function: Lambda. Container without host management: Fargate.
- AWS-native containers: ECS. Kubernetes: EKS.
- Capacity: Auto Scaling. Traffic distribution: Elastic Load Balancing.
How it works
- EC2 launches a chosen virtual-server configuration in a VPC and AZ.
- Lambda receives an event or request and runs configured function code; Fargate runs a defined container task or pod.
- An Auto Scaling group maintains capacity, and a load balancer routes traffic to registered healthy targets.
When to use it
- Use EC2 when virtual-server control or a specific OS environment matters.
- Use Lambda for event-driven functions and Fargate for containers without host management.
- Use ECS for AWS-native container orchestration or EKS when Kubernetes is required.
- Use Auto Scaling and Elastic Load Balancing together for elastic, distributed EC2 application tiers.
Security and governance implications
- Customers remain responsible for code, data, identity permissions, and application configuration across compute models.
- With EC2, the customer also manages the guest OS; managed and serverless services shift more infrastructure work to AWS.
Troubleshooting signals
- If traffic is not served despite enough capacity, examine target health and load distribution; if targets are overloaded, examine scaling capacity.
- When a container workload fails, distinguish orchestration, container configuration, and capacity needs rather than treating ECS, EKS, and Fargate as interchangeable.
More detail
- EC2 instance families let organizations align a virtual server with its dominant resource need without testing exact instance names at this level.
- ECS and EKS manage desired container workloads and placement. Fargate removes worker-host management but leaves application images, permissions, and configuration with the customer.
- Auto Scaling policies adjust desired capacity, while load balancer health checks help direct traffic away from unhealthy targets.
Ready for the quiz?
- Can you explain the different jobs of EKS and Fargate?
- Which compute option preserves guest operating-system control?
- Why might a variable web workload use both Auto Scaling and a load balancer?
- Which EC2 family emphasis fits a CPU-intensive workload?
Related objectives
- D3.3