AWS EC2 in 2026: Instance Families, Nitro, Savings Plans, and When to Use It

EC2 has been the core compute service at AWS since 2006 and in 2026 it still is. Containers, Lambda, and managed services have taken over a lot of workloads — and they should — but most serious AWS infrastructure runs on EC2 directly or underneath something that abstracts it away. ECS Fargate tasks run on EC2. RDS runs on EC2. EKS worker nodes are EC2 instances. Knowing EC2 well makes you better at working with all of it.

This post covers what has actually changed recently and what matters for production use today: the Nitro system, current instance families including Graviton4, the math on Savings Plans, and where EC2 is and isn’t the right tool.

The Nitro System

AWS finished migrating everything to the Nitro hypervisor a few years back, but the practical effects are still worth understanding if you haven’t thought about them.

Nitro is a custom hardware and software stack AWS built to replace the old Xen-based hypervisor. The key difference: Nitro offloads network and storage I/O to dedicated hardware rather than running it through the host CPU. On older Xen instances, VPC networking and EBS I/O consumed CPU cycles on the host. On Nitro instances, that work happens on a separate chip entirely.

In practice this means:

• Network throughput and latency are significantly better. An m7i.large gets up to 12.5 Gbps network bandwidth. Older m4.large instances were capped at around 1 Gbps.
• EBS I/O doesn’t compete with your application for CPU. On heavy database workloads this can be a meaningful difference.
• There’s a dedicated security chip that handles encryption and boot attestation.

If you’re still running m4, c4, or r4 instances, you’re on the old Xen-based stack. Migrating to current-generation Graviton or Intel instances will give you measurably better performance, often at lower cost. There’s no good reason to stay on M4 at this point.

All current-generation instances — anything C5, M5, R5 and newer, plus all Graviton instances — run on Nitro.

Instance Families in 2026

AWS has dozens of instance types, most of which you’ll never need. Here are the families that show up in actual production workloads:

The g suffix on a family name means it runs on Graviton (AWS’s ARM-based processor). m7g is the Graviton version of m7i. Same memory ratios, ARM architecture, lower price.

Graviton is worth serious consideration. Graviton3 (m7g, c7g, r7g) offers roughly 20-25% better price-performance than comparable x86 instances for most workloads. Graviton4 (r8g, c8g) launched in late 2024 and pushes that to around 30% better price-performance versus x86 equivalents.

If your application compiles for ARM64 — which covers the vast majority of Go, Java, Node.js, Python, and Ruby workloads — I’d default to Graviton unless something specific stops you. The two common blockers are x86-only dependencies (some commercial software, legacy binaries) and teams that haven’t tested on ARM64. Testing is a few hours of work and pays for itself fast.

On burstable instances: t4g and t3 instances earn CPU credits when idle and spend them when busy. They’re cheap and fine for dev environments, low-traffic sites, and jobs that burst briefly. Don’t run a production API server or database on them unless you’ve measured that the workload actually fits. Running out of CPU credits on a t3.micro running your production app at 2am is a bad time. If you’re not sure, use a fixed-performance instance.

On Trainium: trn1 instances use AWS’s Trainium chip, designed for ML training. For large-scale training jobs they’re often 30-40% cheaper than equivalent GPU instances. If your team is doing serious model training on AWS, it’s worth benchmarking against your current GPU instances. Inference is a different story — g6 or inf2 instances (Inferentia) are usually the right call there.

Pricing in 2026

An m7i.large (2 vCPU, 8 GB RAM) runs ~$0.096/hr on-demand in us-east-1.

On-Demand makes sense for variable or unpredictable workloads, short-lived resources, and anything you’re still sizing. Pay per second, no commitment. At $0.096/hr, running one m7i.large continuously for a year costs about $840. That’s a lot to pay for a server you could commit to.

Compute Savings Plans are the right model for production workloads you know will run long-term. You commit to a dollar-per-hour spend for 1 or 3 years. AWS applies the discount across any EC2 instance family and region. The flexibility is the point — you’re not locked to a specific instance type, so you can right-size, change families, or move regions and still get the discount.

Running the numbers on that same m7i.large:

• On-Demand: $0.096/hr × 8,760 hrs = $840/year
• 1-year Compute Savings Plan (no upfront): ~$0.063/hr = $552/year (34% savings)
• 3-year Compute Savings Plan (partial upfront): ~$0.044/hr = $385/year (54% savings)

For a production server you know will run for years, a 3-year plan at 54% off is real money. A team running 20 m7i.large instances on-demand versus 3-year Savings Plans is spending roughly $9,100/year extra.

Reserved Instances are still available and give slightly higher discounts than Savings Plans in some cases, but they lock you to a specific instance family, region, and sometimes OS. Standard RIs are hard to exit if you right-size or change direction. Convertible RIs can be exchanged but the process is clunky. For most teams, Compute Savings Plans are the better default. Reserved Instances make sense if you need the maximum possible discount and you’re confident in your instance type long-term.

Spot Instances give you access to unused EC2 capacity at up to 90% off. The catch is a 2-minute interruption notice when AWS needs the capacity back. Right workloads for Spot: batch processing, data pipelines, stateless worker pools, ML training jobs that checkpoint their progress. Wrong workloads: databases, anything stateful, any tier where an interruption causes user-facing downtime. Spot is particularly powerful combined with Auto Scaling Groups — more on that below.

Common Sizing Mistakes

A few patterns I see repeatedly on AWS bills:

Over-provisioning and never revisiting it. Teams launch with the safe choice — usually an instance that’s 2-3x what they need — and never look back. AWS Compute Optimizer analyzes CloudWatch metrics and tells you exactly which instances are overprovisioned. Run it. It’s free and the recommendations are usually right.

Buying Reserved Instances for specific types instead of Compute Savings Plans. If you buy a 3-year m6i.large Reserved Instance and then realize you should be on m7g.large (Graviton), you’re stuck or selling it on the marketplace at a loss. Savings Plans flex across the upgrade.

Running t2 instances. t2 is the old burstable family. It has worse burst credit mechanics, no EBS optimization by default, and worse network performance than t3 or t4g. There’s no reason to launch a new t2 instance. If you have old ones, migrate them.

Ignoring Graviton where it fits. I’ve seen teams spend 20-30% more on their compute bill simply because no one checked whether their application runs on ARM64. Check it. It usually does.

Security That Actually Matters

Everyone knows “restrict your security groups.” Here’s what teams actually miss in practice.

Enforce IMDSv2. The EC2 Instance Metadata Service (IMDS) lets your application retrieve its IAM credentials and other instance info. IMDSv1 is a simple HTTP request with no authentication — an SSRF vulnerability anywhere in your application can be exploited to steal the instance’s IAM credentials. IMDSv2 requires a session token obtained via PUT request, which SSRF attacks can’t easily forge.

Enforce IMDSv2 in Terraform:

metadata_options {
  http_endpoint               = "enabled"
  http_tokens                 = "required"  # IMDSv2 only
  http_put_response_hop_limit = 1
}

Set this on all new instances. For existing fleets, you can enforce it via AWS Config rules and then remediate.

Use EC2 Instance Connect or Session Manager instead of bastion hosts. A traditional bastion host is a dedicated EC2 instance you SSH through to reach internal instances. It needs to stay patched, has an SSH port open to the internet, and requires managing SSH key pairs. EC2 Instance Connect pushes a short-lived key to the instance for a single session — no persistent keys to rotate. AWS Systems Manager Session Manager gives you a shell over HTTPS with no SSH port open at all, full session logging to CloudWatch or S3, and access controlled by IAM. Neither requires a bastion host.

Use VPC endpoints for S3 and SSM. If your instances need to reach AWS APIs (S3, SSM Parameter Store, Secrets Manager) and you’re routing that traffic through a NAT gateway, you’re paying per-GB and sending it out over the internet. VPC Interface Endpoints keep that traffic on the AWS network, remove the internet exposure, and eliminate the NAT gateway cost for those API calls.

Auto Scaling in 2026

For any tier that handles variable traffic, Auto Scaling Groups with mixed instance types are the right default. The key config is MixedInstancesPolicy, which lets you specify a base of On-Demand instances plus a percentage of Spot, spread across multiple instance types to reduce interruption risk.

A typical setup:

• 20% of capacity as On-Demand (handles baseline, survives Spot interruptions)
• 80% Spot across 3-4 instance types (similar size, different families for capacity diversity)
• Target tracking scaling on CPU utilization or a custom CloudWatch metric
• Instance refresh for rolling updates — replace instances using the new launch template without downtime

The instance diversity matters for Spot stability. If you specify only m7i.large, you’ll get interrupted more often than if you also accept m6i.large, m7g.large, and m6a.large. They’re effectively interchangeable for most workloads.

For updates, instance refresh is the right tool. You update your launch template (new AMI, new user data, whatever changed), trigger a refresh with a minimum healthy percentage, and ASG replaces instances in batches. No downtime, no manual drain-and-terminate sequences.

When EC2 Is the Wrong Answer

To be honest about this:

Simple containerized web app — if it’s a stateless service running in a container, App Runner or ECS Fargate is probably the right move. You don’t manage the underlying instances, scaling is simpler, and you’re not paying for idle capacity.

Event-driven workloads — functions that run occasionally in response to events belong in Lambda. Paying for an EC2 instance to sit idle most of the day processing occasional jobs is waste.

Static sites and frontends — S3 plus CloudFront costs pennies per month and has zero servers to patch, update, or secure. If you’re running EC2 instances to serve a static site, stop.

Managed databases — RDS and Aurora handle backups, failover, patching, and replication. Running PostgreSQL or MySQL on EC2 gives you more control and potentially lower cost at very high scale, but you take on all the operational burden. Unless you have specific requirements that RDS can’t meet, use RDS.

EC2 is the right choice when you need fine-grained control over the runtime environment, you have workloads that don’t fit the managed service model (custom OS configs, specific hardware requirements, legacy software), or you’re running something that managed services don’t cover.

Where to Go From Here

If you’re managing EC2 at any scale:

1. Run AWS Compute Optimizer and act on the rightsizing recommendations.
2. Check your Graviton eligibility — if your workload supports ARM64, move it.
3. Convert your stable production workloads to Compute Savings Plans.
4. Enforce IMDSv2 across your fleet.
5. Replace bastion hosts with Session Manager.

The fundamentals of EC2 haven’t changed, but the defaults have shifted. Graviton is now the cost-performance leader for most workloads. Nitro is the baseline for anything you’d launch today. Savings Plans are cleaner than Reserved Instances for most teams. If your EC2 practices are from 2021, there’s probably real money and real security improvement sitting there.

Related posts:

• EC2 vs RDS vs Aurora — database hosting decisions
• AWS VPC design patterns 2026
• AWS FinOps and Well-Architected 2026
• GitLab CI deploy to AWS