AWS EC2 vs Lambda vs S3: A Beginner's Guide to Core Services

If AWS has 240+ services, three of them stand out as the foundational trio every beginner needs to understand: EC2 (virtual machines), Lambda (serverless functions), and S3 (object storage). They are the oldest, the most-used, and the building blocks underneath almost every higher-level AWS service. Get clear on what each one does, when to pick one over the others, and you will be able to design a real cloud app with confidence.

This guide compares all three in plain language, walks through realistic use cases, and shows you how they often work together in the same architecture. By the end you will have a sharp mental model for "where does my code run?" and "where does my data live?" on AWS.

The 30-Second Mental Model

Three sentences:

1. EC2 is a Linux (or Windows) server you rent by the second — full operating system, full control, you manage everything.
2. Lambda is a function that runs in response to an event — no server to manage, pay only for execution time.
3. S3 is a place to put files — virtually unlimited, durable, and the cheapest reliable storage in the cloud.

EC2 and Lambda are both "compute" (places code runs). S3 is "storage" (a place data lives). In real apps, they almost always show up together: a Lambda function that reads a file from S3, or an EC2 web server that serves uploaded images stored on S3.

EC2: A Virtual Machine in the Cloud

EC2 (Elastic Compute Cloud) gives you a virtual server in an AWS data centre that you can SSH into, install anything on, and run for as long as you want. You pick the size (CPU, RAM, network), the operating system (Ubuntu, Amazon Linux, Windows Server), and pay by the second. When you are done, you stop or terminate it.

Use EC2 when:

• You need a long-running server (web app, game server, custom database).
• You need full OS control (custom kernel modules, GPUs, specialised libraries).
• You are migrating an existing on-premises app that expects a real server.
• You want predictable per-second pricing for steady-state workloads.

Avoid EC2 when:

• Your workload is bursty or event-driven (use Lambda).
• You just want to run containers (use ECS Fargate or App Runner).
• You can use a managed service (RDS for databases, ElastiCache for Redis).

A typical "Hello, EC2": launch a t4g.small (ARM, ~$15/month always-on, free for 12 months under the free tier), SSH in, install Nginx, point a Route 53 domain at its public IP. That is real production infrastructure with full root access.

Lambda: Code Without Servers

Lambda lets you upload a function in Node.js, Python, Go, Rust, Java, .NET (and a few others), and AWS runs it in response to events — an HTTP request via API Gateway or Function URLs, an upload to S3, a message on SQS, a scheduled cron, anything. You pay per millisecond of execution and per million requests. There is no server to patch or scale; AWS handles all of that.

Use Lambda when:

• Workloads are event-driven (file uploaded → resize image, message queued → send email).
• Traffic is spiky or unpredictable (Lambda scales from 0 to thousands of concurrent executions automatically).
• You want zero ops for a small API or backend job.
• Cost matters and you do not want to pay for idle servers.

Avoid Lambda when:

• A function needs to run for more than 15 minutes (the hard limit).
• You need very low cold-start latency for every single request (use provisioned concurrency or a long-running EC2/container).
• The workload is heavy and constant — at very high volume, Lambda gets more expensive than equivalent EC2.
• You need persistent local state.

In 2026 the modern way to deploy Lambdas is with AWS SAM, the Serverless Framework, or SST — not by uploading zip files in the console.

S3: Object Storage You Can Trust Forever

S3 (Simple Storage Service) was AWS's very first service, launched in 2006, and it is the foundation of half the internet. You create a bucket, upload objects (files of any size up to 5 TB), and S3 stores them with eleven 9s of durability (99.999999999%) at extremely low cost. There is no concept of folders — keys can include slashes that look like folders, but it is all flat object storage.

Use S3 for:

• Static website hosting (HTML, CSS, JS, images).
• User-uploaded media (avatars, video, file attachments).
• Data lake storage (logs, parquet files, analytics inputs).
• Backups, archives, and disaster recovery.
• Hosting downloadable artefacts (installers, releases).

S3 has multiple storage classes that trade access speed for cost: Standard (default, milliseconds), Standard-IA (Infrequent Access), Glacier Instant (cheap, still fast), and Glacier Deep Archive (~$1/TB/month, hours to retrieve). Lifecycle rules can automatically move old objects between classes.

Pair with CloudFront (AWS's CDN) for global static delivery and you have one of the fastest, cheapest, most reliable static hosting setups in the world.

How They Work Together: A Real App

A small image-sharing app on AWS uses all three:

1. The user uploads an image directly to S3 (browser → presigned URL → S3, no server in the middle).
2. The S3 upload event triggers a Lambda function that resizes the image into thumbnails and stores them back in S3.
3. The web app — running as an EC2 instance behind an Application Load Balancer (or as a containerised service on ECS Fargate) — serves the HTML and reads thumbnail URLs from a database.
4. CloudFront sits in front of S3 to deliver images globally with low latency.

EC2 handles the long-running web server. Lambda handles the bursty image-processing workload. S3 holds all the durable data. Each service is doing the job it is best at — and you are paying for what you use, not for what you provision.

Decision Matrix

Common Mistakes Beginners Make

• Running a database on EC2. Use RDS or Aurora — managed backups, patching, and replication for the same price.
• Leaving an EC2 instance running and forgetting it. A medium instance is ~$60/month. Stop or terminate when done.
• Making S3 buckets public by accident. S3 Block Public Access is on by default in 2026 — keep it that way and use CloudFront + Origin Access Identity for serving.
• Using Lambda for very long jobs. 15-minute hard limit. For longer jobs, use AWS Batch, ECS, or Step Functions.
• Hardcoding AWS credentials. EC2 instance roles and Lambda execution roles give your code temporary credentials automatically. Never commit AKIA... keys.

Quick Reference

• EC2 launch (CLI): aws ec2 run-instances --image-id ami-... --instance-type t4g.small --key-name mykey.
• EC2 list: aws ec2 describe-instances --output table.
• Lambda invoke: aws lambda invoke --function-name myfn --payload '{}' out.json.
• Lambda logs: aws logs tail /aws/lambda/myfn --follow.
• S3 upload: aws s3 cp file.txt s3://mybucket/. Sync: aws s3 sync ./build s3://mybucket/.
• S3 presigned URL: aws s3 presign s3://mybucket/key --expires-in 600.
• Cold start mitigation: Lambda provisioned concurrency, or use SnapStart (Java).
• Free tier (always): 750 EC2 hours/month for 12 months, 1M Lambda requests/month forever, 5 GB S3 for 12 months.