Almost every developer who buys their first AWS server pays AWS more than they expected. Sometimes a lot more. The reason is that EC2 prices are not the bill — the bill is the EC2 instance plus its EBS volume plus its EIP if attached plus its data transfer plus its CloudWatch metrics plus any NAT Gateway it talks through. Each line item is reasonable in isolation; together they make AWS look two to four times more expensive than a same-shaped DigitalOcean droplet. The headline "$5 droplet vs. $4 t3.micro" comparison is misleading because the t3.micro doesn't include a public IP, doesn't include enough storage, and accrues bandwidth charges where DigitalOcean has a generous included allowance.
The honest reason to use EC2 is that you're already deeply on AWS. Your code needs IAM roles to talk to S3 or DynamoDB. You're behind an Application Load Balancer. You're using AWS-native managed databases. You have a CloudFormation or CDK or Terraform stack that already expects EC2. None of these are wrong — and in those contexts EC2 is excellent. For a single small project that doesn't need any of that, you'd be better served at DigitalOcean or Hetzner.
This tutorial walks the launch flow, points out the line items that pad the bill, and explains the AWS-specific concepts (AMI, security group, key pair, EBS) that make EC2 different from every other VPS in this guide. We won't sugar-coat the complexity; we'll just give you the path through it.
What you'll learn
- The AWS-specific vocabulary: AMI, instance type, security group, EBS, EIP
- Free tier vs. real billing — which gives you what for how long
- Launching a t3.micro the right way
- The bill components you'll actually pay
- When to skip EC2 entirely
Step 1: Decide if EC2 is the right answer
1
Three good reasons; otherwise pick elsewhere
You probably want EC2 if any of these are true:
- You need IAM roles on the instance to talk to other AWS services. Putting AWS keys in env vars is fine for development; for production, roles attached to the instance are the right pattern.
- You're already on AWS for other reasons — using S3 / RDS / SQS / etc. The data-transfer math gets better when the EC2 talks to AWS services in the same region.
- You need very specific compute (GPUs, ARM Graviton at scale, lots of memory, EBS-optimized I/O). AWS's instance type catalog has shapes the indie VPSs don't.
If none of these apply, DigitalOcean or Hetzner is cheaper, simpler, and faster to onboard.
Step 2: Learn the vocabulary
2
What each AWS term means
- AMI (Amazon Machine Image). The OS image. "Ubuntu 24.04 LTS" is an AMI; AWS publishes one per region. You can also make your own.
- Instance type. The VM shape —
t3.micro (1 vCPU / 1 GB, burstable), t3.small (1 vCPU / 2 GB), up through massive enterprise sizes. The t family is general-purpose burstable; m is balanced; c is compute-optimized; r is memory-optimized.
- Security group. A virtual firewall attached to the instance. You define allowed inbound/outbound rules. Default-deny inbound.
- Key pair. AWS-managed SSH key. You generate or upload one before launching; it's installed on the instance at boot.
- EBS volume. The persistent disk. Default is a small root volume; you can attach more. EBS bills per GB-month independently of the instance.
- EIP (Elastic IP). A static public IPv4 that survives instance stop/start. Free while attached to a running instance; billable when detached or unattached — this is the most common "I forgot about that" line item.
Step 3: Launch a t3.micro
3
From the EC2 console
In the AWS console, open EC2. Click Launch instances. Configure:
- Name: something memorable.
- AMI: "Ubuntu Server 24.04 LTS." Filter to Free Tier eligible if you want.
- Instance type:
t3.micro for general use, or t4g.micro for ARM (Graviton) — slightly cheaper, same shape.
- Key pair: create a new one or pick an existing. If creating, download the .pem file — you only get it once.
- Network settings: default VPC, "Allow SSH from anywhere" (or better, "Allow SSH from My IP"). For HTTP/HTTPS web servers, also allow ports 80/443.
- Configure storage: 8 GB is the default; bump to 20 GB if you'll need it. The first 30 GB is free under the AWS Free Tier for 12 months.
Click Launch instance. Wait a minute. The instance enters "running" state and gets a public IPv4.
The default public IPv4 changes on stop/start. If you stop the instance (not just reboot) and start it again, the IP changes. For anything pointed at by DNS, attach an Elastic IP — but only attach it while the instance is running, or you'll be billed for the unattached EIP.
Step 4: SSH in
4
Use the key pair you downloaded
# If you downloaded the .pem file, chmod it
chmod 600 ~/Downloads/my-key.pem
# Connect (default user for Ubuntu AMIs is 'ubuntu')
ssh -i ~/Downloads/my-key.pem ubuntu@<public-ip>
You're now on the instance as the ubuntu user, which has sudo. Different AMIs have different default users: ec2-user for Amazon Linux, admin for Debian, centos for older CentOS, etc.
Step 5: Hardening — mostly the same
5
Standard Ubuntu hygiene
sudo apt update && sudo apt upgrade -y
# Optional: create a non-default user (the 'ubuntu' user is fine for most projects)
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo rsync --archive --chown=deploy:deploy /home/ubuntu/.ssh /home/deploy
The firewall is already in place via the EC2 Security Group (network layer); ufw on top of that is belt-and-suspenders — useful but not strictly needed since the Security Group already blocks unwanted inbound. Most AWS-native users leave host-level firewall off and manage everything in Security Groups.
The full hardening checklist lives in its own tutorial. EC2's Security Group covers the network layer; the OS layer still needs the rest — SSH key-only + no root login, fail2ban, swap, log rotation, unattended security updates. Walk through
Prepare a fresh Linux server for production before pointing a domain at this box. Twenty minutes; pays back the first time it matters.
Step 6: The bill components
6
What you're actually paying for
A running t3.micro with default storage and a public IPv4 (while attached) costs, approximately:
- t3.micro compute: $0.0104/hour = ~$7.50/month.
- EBS root volume (8 GB gp3): ~$0.65/month.
- Public IPv4 (attached, since Feb 2024 AWS charges for these): $3.65/month.
- Data transfer out: first 100 GB/month free, then $0.09/GB. Hard to predict.
Total: roughly $12/month for the baseline. Free Tier covers most of this for the first 12 months of your AWS account; after that, you're paying real money for what would be $5–7 elsewhere.
Set up a billing alert. AWS Billing console → Budgets → Create a budget. Configure an email alert at $5, $10, $20 — whatever's high enough to be informative without spamming. The bill-surprise stories aren't malice; they're "I forgot I had two instances and a NAT gateway running."
Step 7: Point your domain
7
EIP or hostname; via Route 53 or any DNS
For a stable public IP, attach an Elastic IP. Then in your DNS provider, A record pointing at the EIP.
If you're using Route 53, you can use an Alias record at the apex pointing directly at an ALB or CloudFront — but for a single EC2, a normal A record at any DNS provider works fine.
Step 8: When to skip EC2
8
Three concrete cases
- You're learning Linux server administration. The cognitive overhead of AWS concepts (VPC, security group, IAM, ENI) gets in the way. DigitalOcean is friendlier; the Linux skills transfer.
- You want predictable monthly cost. EC2's bill has too many independent line items. DO and Hetzner are flat.
- You don't need any AWS-specific service. EC2 in isolation is overpriced for what it is. Use it because of the ecosystem, not despite it.
Terminating an instance doesn't delete its EBS volume by default on all AMIs (the behavior depends on a flag). If you terminate and your storage cost doesn't go away, check the Volumes page in the EC2 console — orphaned EBS volumes are a classic stealth cost.
What's next