Understanding Instance Family Naming
EC2 instance type names encode a lot of information in a compact format, such as m6i.large or c7g.2xlarge: the letter prefix identifies the family (m for general purpose, c for compute-optimized, r for memory-optimized, t for burstable), the number after it is the generation, an optional suffix like g (Graviton/ARM), i (Intel), a (AMD), or n (network-optimized) describes the processor or capability, and the size after the dot scales vCPU and memory together in roughly consistent ratios. General purpose families balance compute, memory, and networking for typical web and application servers, compute-optimized families favor high vCPU-to-memory ratios for batch processing and video encoding, and memory-optimized families like the r-family or x-family favor large RAM for in-memory databases and caching layers.
Cricket analogy: The m-family, general purpose, is like an all-rounder such as Ben Stokes who can bat, bowl, and field competently, while the c-family, compute-optimized, is like a specialist strike bowler such as Jasprit Bumrah brought on specifically for pace and precision.
Right-Sizing and vCPU/Memory Trade-offs
Right-sizing means matching an instance's vCPU count, memory, and network bandwidth to actual measured workload demand rather than guessing, and AWS Compute Optimizer analyzes CloudWatch utilization metrics to recommend better-fitting instance types automatically. Burstable t-family instances (t3, t4g) use a CPU credit system: they run at a modest baseline performance and accumulate credits during idle periods, which they can spend to burst above baseline during traffic spikes, making them cost-effective for workloads with intermittent, spiky CPU demand like small web servers or dev environments — but a sustained high-CPU workload will exhaust credits and get throttled to baseline performance under the T3's default 'standard' credit mode.
Cricket analogy: CPU credits on a t3 instance are like Powerplay overs saved up during a slow middle innings, then spent explosively in the death overs — burn through them too fast without replenishing and you're stuck at a throttled, baseline scoring rate.
# Compare On-Demand hourly price for two instance types via Price List API (simplified via CLI helper)
aws pricing get-products \
--service-code AmazonEC2 \
--region us-east-1 \
--filters "Type=TERM_MATCH,Field=instanceType,Value=m6i.large" \
"Type=TERM_MATCH,Field=operatingSystem,Value=Linux" \
--max-results 1
# Request Spot instances with a max price cap and interruption handling
aws ec2 request-spot-instances \
--instance-count 4 \
--type "persistent" \
--launch-specification file://spot-spec.json \
--spot-price "0.05"On-Demand, Reserved, Savings Plans, and Spot Pricing
On-Demand pricing charges per second with no upfront commitment, ideal for unpredictable or short-lived workloads but the most expensive rate per hour. Reserved Instances and Compute Savings Plans require a 1- or 3-year commitment in exchange for discounts up to roughly 72% off On-Demand, with Savings Plans offering more flexibility since the commitment is a dollar-per-hour spend rather than a specific instance type or family, letting you shift workloads between families without losing the discount. Spot Instances let you bid for AWS's unused capacity at discounts up to 90%, but AWS can reclaim that capacity with a two-minute interruption notice, making Spot appropriate only for fault-tolerant, stateless, or checkpointable workloads such as batch rendering, CI/CD runners, or distributed data processing jobs that can resume from where they left off.
Cricket analogy: Spot Instances are like a franchise picking up a domestic player at a bargain price in the IPL auction knowing they might get recalled to the national team mid-tournament with short notice — great value, but availability isn't guaranteed.
Compute Savings Plans apply automatically to usage across instance families, sizes, OS, and regions (within the plan's scope), unlike Standard Reserved Instances which are tied to a specific instance family and region — making Savings Plans the more flexible discount mechanism for teams whose instance mix changes over time.
Choosing the Right Pricing Model for a Workload
A practical strategy blends models: use Reserved Instances or Savings Plans to cover the predictable baseline load you know will run 24/7, use On-Demand to cover short-term unplanned spikes above that baseline, and use Spot Instances for interruptible batch and parallelizable workloads where cost matters more than guaranteed completion time. Mixing models within a single Auto Scaling group is common — for example, running a guaranteed minimum fleet on Reserved capacity while an Auto Scaling group adds Spot Instances during traffic surges, cutting the marginal cost of scaling out dramatically compared to scaling purely On-Demand.
Cricket analogy: Blending pricing models is like a team fielding a core of contracted regulars for the full domestic season, Reserved capacity, while bringing in short-term net bowlers, Spot Instances, only during intense nets sessions before a big series.
Never run stateful, single-instance production databases on Spot Instances without a robust checkpoint or replication strategy — the two-minute interruption notice is too short to guarantee a clean shutdown, and repeated reclamation during high-demand periods can cause cascading availability problems.
- Instance type names encode family, generation, processor variant, and size, e.g. m6i.large or c7g.2xlarge.
- General purpose (m), compute-optimized (c), and memory-optimized (r/x) families balance vCPU-to-memory ratio differently.
- Burstable t-family instances use CPU credits: idle periods accrue credits that fund short bursts above baseline.
- On-Demand pricing offers full flexibility at the highest per-hour cost.
- Reserved Instances and Savings Plans trade a 1- or 3-year commitment for discounts up to ~72%, with Savings Plans being more flexible across instance families.
- Spot Instances offer up to 90% discounts on spare capacity but can be reclaimed with only a two-minute warning.
- Blending Reserved baseline capacity with On-Demand and Spot for surges is a common cost-optimization pattern in Auto Scaling groups.
Practice what you learned
1. In the instance type name c7g.2xlarge, what does the 'g' suffix indicate?
2. What happens to a T3 instance under sustained high CPU load once its CPU credit balance is exhausted?
3. Why are Compute Savings Plans generally considered more flexible than Standard Reserved Instances?
4. What is the key operational risk of running production workloads on Spot Instances?
Was this page helpful?
You May Also Like
EC2 Fundamentals
Learn what Amazon EC2 is, how virtual server instances work in the cloud, and how to launch, connect to, and manage them safely.
Auto Scaling Groups
Learn how EC2 Auto Scaling Groups automatically add and remove instances based on demand, using launch templates, scaling policies, and health checks.
Elastic Load Balancing
Learn how AWS Elastic Load Balancing distributes traffic across healthy targets, and the differences between Application, Network, and Gateway Load Balancers.