AWS t3.micro vs t3.small: Price, Performance & When to Upgrade

Specs at a Glance

The single biggest difference: t3.small has 2× the RAM and 2× the CPU burst capacity. Everything else is identical.

Pricing Comparison

Both instances are available On-Demand and as Spot. Here's the full cost breakdown at us-east-1 rates:

Pricing varies significantly by region. In eu-north-1 (Stockholm), both instances are slightly cheaper than us-east-1. Use the t3.micro page and t3.small page on CloudBench to see live per-region pricing.

CPU Burst Behavior: The Critical Difference

Both t3.micro and t3.small are burstable instances — they earn CPU credits when idle and spend them when under load. But the credit economy is very different between the two.

In practice: a t3.micro starts running into credit exhaustion under sustained CPU load above 10%. A t3.small handles sustained loads up to 20% without touching its credit balance.

Benchmark Scores

Since both instances use the same underlying Intel Xeon processor and vCPU configuration, single-core Sysbench scores are essentially identical. The multi-core score is also the same (2 vCPUs on both).

Raw CPU performance is identical. The t3.micro wins on price-to-performance ratio — but only if you never hit the memory ceiling or credit limit.

See real benchmark data: t3.micro benchmarks | t3.small benchmarks

Use Cases

t3.micro is the right call for:

• Low-traffic websites and APIs — WordPress sites, static-backed APIs, or small admin panels with <50 concurrent users
• Development and staging environments — Perfect for personal dev servers, staging instances, or CI runners that sit idle most of the time
• Microservices and sidecars — Individual services in a larger architecture that handle a narrow, low-load function
• Cron jobs and schedulers — Burst when running, idle the rest of the time — exactly what t3.micro excels at
• Database replicas (read-only, low query volume) — MySQL or PostgreSQL read replicas on light traffic

t3.small is the right call for:

• Node.js or JVM applications — The JVM alone eats 300–500 MB at startup. With 1 GiB total on t3.micro, you're left with almost nothing for your actual app
• Small databases (primary instances) — MySQL, PostgreSQL, or Redis primaries need headroom for OS, connections, and buffer pools
• Docker hosts — Each container has overhead. One container can fit on t3.micro; two or more almost always need t3.small
• Applications with sustained 10–20% CPU baseline — If your app consistently uses 10–15% CPU, t3.micro burns credits constantly. t3.small handles it without touching the credit balance
• Production workloads where memory OOM = downtime — Don't risk it for $7.49/month

When to Upgrade: The Decision Checklist

Regional Pricing: Where to Run Each

AWS pricing varies by region. The cheapest regions for t3 instances are generally us-east-1 (N. Virginia) and eu-north-1 (Stockholm). eu-north-1 in particular often has the lowest Spot prices due to lower demand.

Spot prices are approximate and fluctuate. Check CloudBench for live rates.

Verdict

Start with t3.micro. It's the right default for anything non-critical. At $7.49/month, the cost of being wrong is low. Monitor your CloudWatch metrics — specifically MemoryUtilization and CPUCreditBalance — for 1–2 weeks. If either shows sustained pressure, upgrade to t3.small.

Don't run JVM apps on t3.micro. The memory math doesn't work. Start with t3.small for any Java, Kotlin, or Scala service.

For cost-sensitive workloads where interruptions are acceptable, Spot pricing on t3.micro (~$0.0031/hr) is hard to beat — roughly $2.23/month for a complete dev environment. See our Spot vs On-Demand guide for when that makes sense.