Lambda vs ECS Fargate vs EC2

Concepts Covered

• Lambda functions
• ECS services
• Fargate launch type
• EC2 instances
• Event-driven compute
• Containerized workloads
• Long-running services
• Runtime control
• Scaling model
• SAA-C03 compute traps

1. Plain-English Mental Model

Lambda, ECS Fargate, and EC2 are all compute options, but they give you different shapes of ownership.

Lambda = run code in response to events
ECS Fargate = run containers without managing EC2 hosts
EC2 = run virtual servers with full instance control

The question is not "which one is newest?" The question is "what shape does this workload naturally have?"

A short image-resize handler after an S3 upload feels like Lambda. A long-running containerized web API feels like ECS Fargate. A custom appliance, legacy daemon, or workload needing OS-level control may feel like EC2.

2. Why This Service Exists

AWS offers multiple compute models because applications do not all behave the same way.

Some workloads are brief and event-driven. They wake up, process one event or batch, and finish. Lambda removes the need to keep servers waiting.

Some workloads are packaged as containers and run as services or workers. ECS gives orchestration, and Fargate removes host management.

Some workloads need full server control: custom agents, kernel modules, specialized networking, GPUs, unusual licensing, local daemons, or deep OS tuning. EC2 gives that control.

For SAA-C03, compute questions often hinge on phrases such as "no server management", "containerized application", "long-running", "event-driven", "custom AMI", "full control", "short task", "batch worker", or "timeout".

3. The Naive Approach And Where It Breaks

The naive approach is to choose Lambda for anything called serverless.

That breaks when the workload runs longer than Lambda limits, needs a continuously listening process, needs stable container behavior, or opens many database connections.

Another naive approach is to choose EC2 because it can run anything. That is true, but it adds patching, AMIs, scaling groups, instance recovery, host security, and operational ownership.

Another mistake is thinking Fargate means "no architecture." Fargate removes EC2 host management, but the service still needs task definitions, IAM roles, networking, security groups, load balancers, logs, scaling, and deployment controls.

4. Core Primitives

Lambda primitives are functions, event sources, execution roles, memory, timeout, concurrency, event source mappings, and destinations or DLQs.

ECS Fargate primitives are clusters, task definitions, tasks, services, capacity providers, task roles, task execution roles, security groups, subnets, logs, and load balancer target groups.

EC2 primitives are instances, AMIs, instance types, EBS volumes, security groups, key pairs, user data, launch templates, Auto Scaling groups, and lifecycle management.

Each primitive reveals the operating model. Lambda owns the server layer. Fargate owns the container host layer. EC2 makes the instance your responsibility.

5. Architecture Use Cases

Use Lambda for API handlers, S3 object processing, DynamoDB Streams, SQS queue consumers, scheduled cleanup, lightweight automation, and event glue.

Use ECS Fargate for containerized web apps, APIs, workers, scheduled tasks, background services, and applications that need a container process rather than a function invocation.

Use EC2 for lift-and-shift applications, custom software stacks, specialized networking, GPU or hardware-specific workloads, self-managed clusters, legacy agents, and workloads where OS control matters.

The common serverless API shape is:

API Gateway -> Lambda -> DynamoDB

The common container API shape is:

ALB -> ECS service on Fargate -> RDS

The common EC2 shape is:

ALB -> Auto Scaling group of EC2 instances -> managed or self-managed backend

7. Security Model

Lambda security centers on execution roles, resource-based invocation permissions, environment configuration, secrets access, and VPC placement when private resources are needed.

ECS Fargate security centers on task roles, task execution roles, image security, network placement, security groups, secrets injection, and container isolation.

EC2 security centers on IAM instance profiles, OS patching, SSH or Systems Manager access, AMI hygiene, security groups, EBS encryption, and host-level hardening.

Operational control creates security responsibility. EC2 gives the most control and the most patching responsibility. Lambda gives the least host control and the least host-management burden.

8. Reliability And Resilience

Lambda scales automatically, but function errors, retries, duplicate events, throttles, cold starts, and downstream overload still need design.

ECS services maintain desired task count. Spread tasks across Availability Zones and use load balancer health checks, deployment settings, and graceful shutdown.

EC2 reliability usually depends on Auto Scaling groups, health checks, launch templates, multi-AZ subnets, load balancers, patching, and instance replacement.

For all three, the managed compute layer does not fix bad downstream dependencies. Databases, queues, caches, secrets, and networks still need resilience.

9. Performance And Scaling

Lambda scales by concurrent invocations and event source configuration. It is excellent for spiky event-driven work, but cold starts and concurrency limits can matter.

ECS Fargate scales by launching tasks. It fits services where each task can handle ongoing requests or work. Scaling is not instant in the same way as starting more Lambda execution environments.

EC2 scales through instance fleets. It can be highly optimized for performance, but scaling and capacity planning are your responsibility.

If the workload is latency-sensitive and always hot, containers or EC2 may be more predictable. If the workload is intermittent, Lambda may be simpler and cheaper.

10. Cost Model

Lambda charges by requests and execution duration. It shines when work is intermittent or spiky.

Fargate charges by task CPU, memory, and runtime. It shines when you want container operations without paying the EC2 management tax in human time.

EC2 charges by instance capacity. It can be cheaper for steady, highly utilized workloads, especially with Savings Plans, Reserved Instances, Spot, and careful bin packing.

The cheapest compute on paper is not always cheapest operationally. Include patching, deployment complexity, scaling, observability, and failure response.

12. SAA-C03 Exam Signals

"Run code without provisioning servers" points to Lambda.

"Short event-driven task" points to Lambda.

"Containerized application with low operational overhead" points to ECS Fargate.

"Long-running container service" points to ECS service, often on Fargate.

"Full control over OS, AMI, or host configuration" points to EC2.

"Need GPU or specialized instance choice" often points to EC2 or ECS on EC2 depending on wording.

"Work exceeds Lambda timeout" points away from Lambda.

13. Common Exam Traps

Do not choose Lambda for every low-ops workload if the process is long-running.

Do not choose EC2 when the requirement explicitly minimizes server management and containers fit.

Do not assume Fargate replaces ECS. ECS is the orchestrator; Fargate is a compute option.

Do not ignore downstream capacity when Lambda scales quickly.

Do not forget that EC2 requires patching and instance lifecycle operations.

Do not force a monolith into Lambda functions just because serverless sounds modern.

15. Related Topics

Review AWS Lambda, Amazon ECS And AWS Fargate, Amazon EC2, and Amazon Elastic Container Registry.

Official AWS references:

• AWS Lambda event source mappings
• Amazon ECS launch types and capacity providers
• Amazon EC2 instances