EC2 is a virtual server, but AWS provides many higher-level compute services. Choose based on how much infrastructure you want to manage.
Lambda
Lambda is serverless function compute. You upload function code and run it in response to events.
AWS manages:
- Server provisioning
- Scaling
- Runtime environment
- Availability
- Millisecond billing
Typical triggers:
- API Gateway
- S3 events
- SQS
- EventBridge
The main limitation is a maximum execution time of 15 minutes.
Containers and Orchestration
Containers package applications with dependencies, runtime, and configuration so they run consistently.
Orchestration manages container lifecycle: start, stop, scale, recovery, and rolling updates.
ECS
ECS is AWS's native container orchestration service.
ECS on EC2: you manage the underlying EC2 instances and get more control.
ECS on Fargate: no server management; focus on container tasks.
EKS
EKS is managed Kubernetes.
EKS on EC2: for teams needing Kubernetes plus infrastructure control.
EKS on Fargate: for teams wanting Kubernetes without managing nodes.
ECR
ECR is a container image registry for storing, managing, and pulling images.
Fargate
Fargate is a serverless compute engine for containers. It is not an orchestrator; it is the managed compute layer used with ECS or EKS.
Other Compute Services
Elastic Beanstalk: upload code and let AWS handle deployment, scaling, load balancing, and health checks.
AWS Batch: run batch workloads, such as scientific computing, transcoding, or massively parallel processing.
Lightsail: lightweight VPS with predictable pricing for small sites, blogs, learning, and test environments.
Outposts: extends AWS infrastructure to on-premises locations for low latency, data residency, or compliance.
Selection guide:
- Event-driven functions: Lambda
- Containers without servers: ECS/EKS + Fargate
- Kubernetes ecosystem: EKS
- Simple web app deployment: Elastic Beanstalk
- Batch jobs: AWS Batch
- Small VPS: Lightsail
- Hybrid local AWS: Outposts
Deeper Notes
When reviewing this topic, do not memorize names only. Focus on Lambda, containers, ECS, EKS, ECR, Fargate, and operational boundaries of compute models. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.
- AWS review should connect services into architecture: entry point, compute, networking, storage, permissions, monitoring, and cost.
- For each service, ask what problem it solves, who operates it, and what the blast radius is when it fails.
- Both exams and real projects care about boundaries: Region vs AZ, managed vs self-managed, stateful vs stateless resources.
In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.
Practical Checklist
- Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
- Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
- Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
- Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
- End with one sentence about tradeoff: what it gives up and what it buys.
Self-Check Questions
- What core problem does this topic solve?
- What alternatives exist, and what are their costs?
- Where are the most likely edge cases?
- How would code, tests, or monitoring prove that it is reliable?
Applied Scenario
A practical way to study this topic is to place it inside a small SaaS deployment: users enter through a domain, CloudFront or a load balancer receives traffic, the app runs on EC2, ECS, or Lambda, databases and caches live in private subnets, logs go to CloudWatch, permissions are controlled by IAM, and static assets are stored in S3. For every AWS service, ask where it sits in this chain: entry, compute, network, storage, security, monitoring, or cost control.
Common Pitfalls:
- Memorizing service names without being able to draw the request path.
- Ignoring network boundaries and exposing databases publicly.
- Not estimating cost or failure blast radius.