What To Look For When Selecting An Instance Type

AWS

RDS and EC2 offer a variety of instance types. But many of them have a catch, which you should be aware of:

1. Many instances are classified as burstable. Avoid them ¹. If the instance type starts with T, like T2 or T3, it’s burstable.

2. RDS offers a tool called Performance Insights that tells you what’s slowing down your database. This is not compatible with t2 or t3 small or medium instances, so don’t use these four.

3. Don’t use Micro instances, since they’re excluded from the SLA.

4. Avoid using earlier generation instances. If you’re using them, check if a newer generation offers the same specifications for a lower price.

5. Use ARMs instance if possible for the best price-performance. The future is ARM: smartphones and iPads have used ARM since the beginning, and now laptops are switching. Servers are next. If you can’t use ARM, AMD is still cheaper than Intel.

6. Before you upgrade your instance, understand which aspect of performance is the bottleneck. If it’s CPU, upgrade to a compute-optimised instance, while keeping your memory the same, because that’s not a bottleneck. Similarly, if you’re bottlenecked for memory, increase your memory while keeping compute the same. Amazon offers instances with different ratios of memory to CPU: 2:1 (compute-optimised C6g), 4:1 (general-purpose), 8:1 (memory-optimised R6g) or 16:1 (memory-optimised X2gd). Pick the ratio that works for you ².

GCP

1. Don’t use N1 — it’s an older architecture.

2. Before using M2, consider that it doesn’t support on-demand pricing, locking you in.

3. Before using E2, consider that you may get an older architecture machine, or a newer one — there’s no commitment.

4. Before using M1, remember that it’s an older architecture, and see if another instance type gives you the memory you need.

1

1. Their performance suddenly drops when you exhaust the CPU credit balance.

2. Monitoring becomes harder: if you look at a graph showing a CPU utilisation of 10%, that means the CPU is not a bottleneck, right? Not if you’re entitled to only 10% baseline utilisation, in which case 10% means 100%. If you set an alert to fire if the CPU > 80%, it may not fire even when there’s a problem.

3. You can receive an unpredictable bill at the end of the month.

4. A non-burstable instance costs less for the same CPU utilisation.

2. You can alternatively optimise your software to use less CPU and more memory to match what the hardware offers, but that’s not a worthwhile endeavor when you can switch the hardware to match what your software wants.