EC2 virtual servers, Lambda serverless functions, Auto Scaling, and containers (ECS/Fargate) are the four main ways to run code on AWS. This page covers when to use each and how to operate them.

Why Compute Services Matter

Every application needs somewhere to run. In traditional IT, that means buying servers, racking them in a data center, and managing hardware failures. AWS compute services let you skip all of that and get straight to running your code.

This guide covers two main approaches:

• EC2 (Elastic Compute Cloud): Virtual servers you control completely, like renting computers in the cloud
• Lambda: Serverless functions where you just upload code and AWS handles everything else

Which should you choose? Start with EC2 if you need full control, have long-running processes, or are migrating existing applications. Choose Lambda for event-driven workloads, APIs, or when you want zero server management.

AWS Crash Course: From Zero to Cloud in 30 Minutes

If you’re completely new to AWS, this crash course will get you up and running quickly. We’ll build something real while learning the essentials.

What You’ll Build

In the next 30 minutes, you’ll deploy a simple web application that demonstrates core AWS concepts. By the end, you’ll have:

• A virtual server running in the cloud (EC2)
• A globally accessible website (S3 + CloudFront)
• A managed database (RDS)
• Monitoring and alerts (CloudWatch)
• All connected securely

Prerequisites

• An AWS account (sign up at aws.amazon.com - credit card required but we’ll stay in free tier)
• Basic command line knowledge
• A web browser
• 30 minutes of focused time

Step 1: Secure Your Account (5 minutes)

Never skip this step. AWS gives you powerful tools that can cost money if misused.

1. Enable MFA on Root Account

   AWS Console → Your Account → Security Credentials → MFA
   

   Use Google Authenticator or similar. This prevents unauthorized access even if your password leaks.

2. Create Your First IAM User

   IAM → Users → Add User
   Username: your-name-admin
   Access: AWS Management Console access
   Permissions: AdministratorAccess (for learning only!)
   

3. Set Up Billing Alerts

   Billing → Billing Preferences → Receive Billing Alerts
   CloudWatch → Alarms → Create Alarm
   Metric: EstimatedCharges
   Threshold: $5
   

Common Pitfall: Using root account for daily work. This is like using admin/sudo for everything - dangerous and unnecessary.

Step 2: Launch Your First Server (10 minutes)

Let’s create a virtual server (EC2 instance) - your computer in the cloud.

1. Navigate to EC2

   Services → EC2 → Launch Instance
   

2. Configure Your Instance
   • Name: MyFirstServer
   • OS: Amazon Linux 2023 (free tier eligible)
   • Instance Type: t2.micro (1 CPU, 1GB RAM - free tier)
   • Key Pair: Create new → Download .pem file (guard this carefully!)
   • Network: Allow SSH (22) and HTTP (80)
3. Connect to Your Server

   # Mac/Linux
   chmod 400 your-key.pem
   ssh -i your-key.pem ec2-user@your-instance-ip
   
   # Windows (use PuTTY or WSL)
   

4. Install a Web Server

   sudo yum update -y
   sudo yum install httpd -y
   sudo systemctl start httpd
   sudo systemctl enable httpd
   echo "<h1>Hello from AWS!</h1>" | sudo tee /var/www/html/index.html
   

Visit your instance’s public IP in a browser - you have a website!

What Just Happened?

• You rented a computer in AWS’s data center
• You connected to it over the internet
• You installed software just like on any Linux machine
• Your website is now globally accessible

Common Pitfalls:

• Forgetting to allow HTTP in security group (your firewall rules)
• Losing your key pair (no key = no access)
• Leaving instances running (they cost money outside free tier hours)

Step 3: Create Scalable Storage (5 minutes)

EC2 storage disappears when instances terminate. Let’s use S3 for permanent storage.

1. Create an S3 Bucket

   S3 → Create Bucket
   Name: my-first-bucket-[random-numbers]
   Region: Same as your EC2
   Block all public access: OFF (for learning only!)
   

2. Upload a File Create a simple HTML file locally:

   <!DOCTYPE html>
   <html>
   <head><title>My S3 Site</title></head>
   <body>
     <h1>This website runs from S3!</h1>
     <p>No servers needed.</p>
   </body>
   </html>
   

   Upload via console → Make public

3. Enable Static Website Hosting

   Bucket → Properties → Static website hosting → Enable
   Index document: index.html
   

Your website now runs without any servers! Access via the S3 website endpoint.

Why This Matters: S3 is virtually unlimited storage that’s always available. It’s perfect for images, videos, backups, and static websites.

Step 4: Add a Database (5 minutes)

Most applications need to store data. Let’s add a managed database.

1. Create an RDS Instance

   RDS → Create Database
   Engine: MySQL
   Template: Free tier
   DB Instance: db.t3.micro
   Username: admin
   Password: [choose-strong-password]
   

2. Configure Access
   • Same VPC as your EC2
   • Security group: Allow MySQL port (3306) from your EC2 security group
3. Connect from EC2

   # On Amazon Linux 2023, use dnf and the mariadb105 client package:
   sudo dnf install mariadb105 -y
   mysql -h your-rds-endpoint -u admin -p
   

What’s Happening: AWS manages backups, updates, and availability. You just use the database.

Step 5: Monitor Everything (5 minutes)

You can’t improve what you don’t measure. CloudWatch monitors everything.

1. View EC2 Metrics

   EC2 → Your Instance → Monitoring Tab
   

   See CPU, network, disk usage

2. Create an Alarm

   CloudWatch → Alarms → Create Alarm
   Select Metric: EC2 → Per-Instance Metrics
   CPU Utilization > 80% for 5 minutes
   Send notification to your email
   

3. View Logs Install CloudWatch agent on EC2:

   sudo yum install amazon-cloudwatch-agent -y
   

Real Impact: You’ll know about problems before your users do.

Your First Cloud Architecture

Congratulations! You’ve built a real cloud architecture:

flowchart TB
    Internet([Internet]) --> EC2["EC2<br/>Web Server"]
    EC2 --> RDS[("RDS<br/>Database")]
    S3["S3<br/>Static Assets"] --> CF["CloudFront<br/>CDN"]
    CF --> Internet
    CW["CloudWatch"] -. "monitors" .-> EC2
    CW -. "monitors" .-> RDS

Next Steps After the Crash Course

1. Clean Up (Important!):
   • Terminate EC2 instance
   • Delete RDS instance
   • Empty and delete S3 bucket
   • This prevents charges
2. What to Learn Next:
   • IAM Roles: Give EC2 permission to access S3 without keys
   • Auto Scaling: Automatically add/remove servers based on load
   • Load Balancers: Distribute traffic across multiple servers
   • VPC: Create private networks for security
3. Practice Projects:
   • Deploy a WordPress blog (EC2 + RDS)
   • Create a serverless API (Lambda + API Gateway)
   • Build a data pipeline (S3 + Lambda + DynamoDB)

Common Beginner Mistakes to Avoid

1. The “It Works on My Machine” Trap
   • Always test in an AWS environment
   • Local and cloud environments differ
2. The “Infinite Scale” Misconception
   • Everything has limits (even in cloud)
   • Plan for growth, but start small
3. The “Set and Forget” Danger
   • Cloud resources need maintenance
   • Automate everything possible
4. The “All Public” Security Hole
   • Start with least privilege
   • Only expose what’s necessary
5. The “Bill Shock” Surprise
   • Set up billing alerts immediately
   • Understand pricing before using services
   • Use AWS Cost Explorer weekly

This crash course gives you hands-on experience with core AWS services. You’ve deployed real infrastructure and learned by doing. The rest of this guide builds on these foundations with deeper knowledge and advanced patterns.

Core Concepts to Master First

Before diving into specific services, let’s understand the fundamental concepts that make cloud computing powerful:

The Cloud Mental Model

Traditional IT requires you to predict capacity, buy hardware, and maintain everything yourself. Cloud computing flips this model - you provision resources on-demand, scale instantly, and let AWS handle the infrastructure complexity.

Regions and Availability Zones

AWS operates in multiple geographic regions worldwide. Each region contains multiple Availability Zones (AZs) - essentially separate data centers with independent power, cooling, and networking. This geographic distribution is your foundation for building resilient applications that can survive failures.

The Pay-as-You-Go Model

Unlike traditional IT where you pay upfront for capacity you might not use, AWS charges based on actual consumption. Launch 100 servers for an hour? You pay for 100 server-hours. This model enables experimentation and scaling without massive capital investment.

Security as a Shared Responsibility

AWS secures the infrastructure (the “security of the cloud”), while you secure your data and applications (“security in the cloud”). Understanding this division helps you build secure systems from day one.

Identity and Access Management (IAM)

Before creating any resources, understand IAM - it’s the foundation of AWS security. IAM controls who can do what in your AWS account. Start with these principles:

• Never use your root account for daily work
• Create individual users with specific permissions
• Use roles for applications, not hardcoded credentials
• Enable MFA (Multi-Factor Authentication) everywhere

Your First Steps with AWS

Now that you understand the core concepts, let’s get practical. AWS can feel overwhelming with its 200+ services, but you don’t need to learn them all at once. Here’s a progressive path from beginner to advanced cloud architect.

Getting Your Hands Dirty

Start with the AWS Free Tier - it gives you 12 months of free access to core services with generous limits. This is your playground for learning without worrying about costs.

1. Create an AWS Account: Set up billing alerts immediately (even on free tier)
2. Secure Your Account: Enable MFA on your root account and create an IAM user for daily work
3. Launch Your First EC2 Instance: Think of it as renting a computer in the cloud
4. Store Files in S3: Upload some files and understand object storage
5. Set Up a Simple Website: Combine EC2 and S3 to host a basic web application

Each step builds on the previous one, gradually introducing you to how AWS services work together.

Essential Services for Every Developer

Let’s explore the services you’ll use most often, understanding not just what they do, but why they matter for real applications.

Compute Services: Your Application’s Brain

Amazon EC2 - Virtual Servers

EC2 (Elastic Compute Cloud) is like renting computers in the cloud. You choose the operating system, processing power, memory, and storage. Need a small server for testing? Launch a t2.micro. Building a data processing pipeline? Spin up a compute-optimized instance.

Real-world example: A startup begins with one EC2 instance running their web application. As traffic grows, they add more instances behind a load balancer. During Black Friday, they scale to 50 instances, then scale back down afterward.

Choosing the Right Instance Type

Consider the following when selecting an instance type: What is your workload’s primary bottleneck? CPU, memory, storage, or network?

*Prices are approximate for US East, on-demand. Actual prices vary by region and change over time.

EC2 Pricing Models

You can significantly reduce costs by choosing the right pricing model:

Practical EC2 Patterns

1. Right-Sizing Instances

Check your CPU utilization with CloudWatch. If CPU stays below 20% consistently, you are likely overpaying:

# Check CPU utilization for the past day
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistics Average --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z --period 3600

When to downsize: t3.micro to t3.nano saves 50%. m5.large to t3.medium saves 60% for variable workloads.

2. Spot Instances for Batch Processing

Spot instances offer up to 90% savings for interruptible workloads. The key is designing for interruption:

# Request a Spot instance with a max price
aws ec2 request-spot-instances --spot-price "0.10" \
  --instance-count 1 --type "one-time" \
  --launch-specification file://spot-spec.json

When to use Spot: Batch processing, CI/CD builds, data analysis, any job that can checkpoint and resume.

3. Auto-Recovery for Critical Instances

Configure CloudWatch alarms to automatically recover instances that fail system status checks:

# Set up auto-recovery alarm
aws cloudwatch put-metric-alarm --alarm-name ec2-auto-recovery \
  --metric-name StatusCheckFailed_System --namespace AWS/EC2 \
  --statistic Maximum --period 60 --evaluation-periods 2 \
  --threshold 0 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:automate:region:ec2:recover

Common EC2 Pitfalls and Solutions

Quick fix for lost SSH access: Use AWS Systems Manager to connect without keys:

aws ssm start-session --target i-1234567890abcdef0

Quick fix for static IPs: Allocate an Elastic IP to prevent IP changes:

aws ec2 allocate-address --domain vpc
aws ec2 associate-address --instance-id i-1234567890abcdef0 --allocation-id eipalloc-xxx

AWS Lambda - Serverless Computing

Lambda represents a paradigm shift. Instead of managing servers, you upload your code and AWS runs it in response to events. You pay only for the milliseconds your code executes.

Real-world example: An e-commerce site uses Lambda to resize product images. When a seller uploads a photo, Lambda automatically creates multiple sizes for different devices. No servers to manage, automatic scaling, and you only pay when images are processed.

EC2 vs Lambda: When to Use Each

Practical Lambda Patterns

1. Event-Driven Processing (triggered by S3 uploads, database changes, etc.)

def lambda_handler(event, context):
    # Get the uploaded file info from S3 trigger
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Process the file (resize image, parse CSV, etc.)
    # ...
    return {'statusCode': 200, 'body': 'Processed successfully'}

2. API Backend (with API Gateway)

def lambda_handler(event, context):
    if event['httpMethod'] == 'GET':
        return {'statusCode': 200, 'body': json.dumps({'message': 'Hello'})}
    elif event['httpMethod'] == 'POST':
        data = json.loads(event['body'])
        # Process data...
        return {'statusCode': 201, 'body': json.dumps({'created': True})}

3. Scheduled Tasks (with CloudWatch Events/EventBridge)

def lambda_handler(event, context):
    # Runs on schedule (e.g., daily cleanup, reports)
    # Delete old files, send notifications, generate reports
    return {'statusCode': 200, 'body': 'Task completed'}

Common Lambda Pitfalls and Solutions

Reducing cold starts: Keep deployment packages small. Avoid large libraries like pandas (40MB) when simpler alternatives work.

Handling long processes: Use AWS Step Functions to orchestrate multiple Lambda functions:

{
  "StartAt": "ProcessChunk",
  "States": {
    "ProcessChunk": {
      "Type": "Map",
      "ItemsPath": "$.chunks",
      "MaxConcurrency": 10,
      "Iterator": { "StartAt": "DoWork", "States": {...} }
    }
  }
}

Handling large files: Stream instead of loading everything into memory:

# Stream large files line by line
for line in s3_object['Body'].iter_lines():
    process_line(line)  # Process one line at a time

Auto Scaling: Capacity That Tracks Demand

A single EC2 instance forces an uncomfortable choice: size it for peak traffic and waste money during quiet hours, or size it for average load and fall over during spikes. EC2 Auto Scaling removes the choice by adding and removing instances automatically based on demand.

The mechanism has three parts working together:

The most robust everyday choice is a target tracking policy: you name a metric and a target value, and AWS adds or removes capacity to hold it there.

# Maintain 2-10 instances, scaling to keep average CPU around 50%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 50.0
  }'

Scaling policy types at a glance:

Containers on AWS: ECS and Fargate

Many teams package applications as containers (see Docker) rather than managing whole servers. AWS offers two main ways to run them.

Amazon ECS (Elastic Container Service) is AWS’s native container orchestrator. You define a task definition (which container images to run, with how much CPU and memory), and ECS schedules those tasks onto compute capacity.

That capacity comes in two launch types:

Fargate is serverless compute for containers: you specify CPU and memory per task and AWS runs it without any EC2 instances for you to patch or scale. It is to containers what Lambda is to functions — zero host management, pay only for what runs.

// A minimal Fargate task definition (excerpt)
{
  "family": "web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "web",
    "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/web-app:latest",
    "portMappings": [{ "containerPort": 80 }]
  }]
}

Choosing Among the Compute Options

By now you have four ways to run code on AWS. This table ties them together:

Key Takeaways

• EC2 for control, Lambda for scale-to-zero. Choose EC2 when you need a long-running server you fully control; choose Lambda for event-driven, bursty work that should cost nothing when idle.
• Auto Scaling plus load balancing. Pair an Auto Scaling group with a load balancer so capacity tracks demand and unhealthy instances are replaced automatically.
• Spot instances cut cost. Use Spot for fault-tolerant, interruptible workloads to save up to 90%; keep baseline capacity on On-Demand or Reserved.
• Mind Lambda’s limits. Watch cold starts, the 15-minute timeout, and package size. Reach for Step Functions to orchestrate long or multi-stage work.
• Fargate for containers without servers. Run containers on ECS (or EKS) with Fargate to skip host patching and scaling entirely — choose the EC2 launch type only when you need control over the underlying instances.

See Also

• AWS Hub - Overview of all AWS documentation
• Storage Services - S3 and EBS for your data
• Database Services - RDS and DynamoDB
• Networking & Content Delivery - VPC, load balancers, and CloudFront
• Security - IAM and security best practices
• Infrastructure as Code - CloudFormation, monitoring, and cost optimization
• Kubernetes on AWS - Container orchestration with EKS
• Docker - Containerization fundamentals