Amazon EC2 – Consider Using Latest Generation Instances for i-Family Instances

The Amazon EC2 i-family latest generation policy flags storage-optimized EC2 instances still running the previous-generation i2 family and recommends moving them to i3 or newer. An i3.xlarge costs about 63% less per month than an i2.xlarge in US East (N. Virginia), with the same vCPUs and memory, more local SSD, and NVMe-based storage. Apply this policy to any aws_instance whose instance_type starts with i2..

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon EC2 i-family instances are storage-optimized. Teams run them for NoSQL databases such as Cassandra and MongoDB, search clusters, data warehousing, and other workloads that need fast local SSD.

AWS lists i2 as a previous-generation instance family. An i2 instance runs on an Intel Xeon E5-2670 v2 (Ivy Bridge) processor and uses SATA-based instance store SSDs.

An i3 instance runs on an Intel Xeon E5-2686 v4 (Broadwell) processor and attaches its instance store as NVMe SSD. According to AWS, i3 delivers over 4x higher I/O performance, over 2x higher disk throughput, and 18% more SSD per vCPU than i2.

AWS also states that i3 offers the lowest price per read IOPS of all EC2 instances. Staying on i2 means paying close to three times the hourly rate for slower storage.

This is one of the largest per-instance savings among the Amazon EC2 generation upgrade policies. It applies only where the workload can tolerate rebuilding its local SSD data during the move.

Potential Savings

The Amazon EC2 i-family generation upgrade saves money because i3 costs far less per hour than the i2 instance it replaces, at the same vCPU and memory size.

Monthly figures assume 730 hours at US East (N. Virginia) on-demand Linux rates. Prices vary by region, operating system, and purchase option.

Moving one i2.xlarge to i3.xlarge saves about $395 per month, or roughly $4,700 per year. The i-family is priced linearly by size, so larger i2 instances save proportionally more.

The i4i.xlarge costs about 10% more per hour than i3.xlarge. It still costs about 60% less than i2.xlarge, and it adds memory and a newer Ice Lake processor on the AWS Nitro System.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon EC2 instance on the previous-generation i2 family, and the corrected configuration on i3.

Non-compliant configuration: EC2 instance on i2

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i2.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i2.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i2.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

This configuration pays about $623 per month for an Ivy Bridge processor and SATA-based local SSD. This is a common source of wasted spend in AWS accounts where storage-heavy clusters were sized years ago and never revisited.

Compliant configuration: EC2 instance on i3

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i3.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i3.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

resource "aws_instance" "cassandra" {
  ami                    = var.ami_id
  instance_type          = "i3.xlarge"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.cassandra.id]

  root_block_device {
    volume_type = "gp3"
    volume_size = 50
  }

  tags = {
    Name = "cassandra-01"
  }
}

The only Terraform change is the instance_type value. The operational change is larger: the local SSD on the new instance starts empty, so the workload must be able to rebuild or restore its data.

The same instance_type fix applies to launch templates used by Auto Scaling groups:

resource "aws_launch_template" "search_nodes" {
  name_prefix   = "search-nodes-"
  image_id      = var.ami_id
  instance_type = "i3.2xlarge" # previously "i2.2xlarge"
}

resource "aws_launch_template" "search_nodes" {
  name_prefix   = "search-nodes-"
  image_id      = var.ami_id
  instance_type = "i3.2xlarge" # previously "i2.2xlarge"
}

resource "aws_launch_template" "search_nodes" {
  name_prefix   = "search-nodes-"
  image_id      = var.ami_id
  instance_type = "i3.2xlarge" # previously "i2.2xlarge"
}

Step-by-Step Fix Instructions

1. Search Terraform code for instance_type values that start with i2. in aws_instance and aws_launch_templateresources.

2. Check shared modules, .tfvars files, and variable defaults. Older instance types often sit in a variable "instance_type" default rather than in the resource block.

3. Confirm the AMI includes ENA and NVMe drivers. Current Amazon Linux, Ubuntu, and Windows Server AMIs include both.

4. Update disk mount configuration. i3 instance store volumes appear as NVMe devices such as /dev/nvme0n1, not as the /dev/xvdb style names used on i2.

5. Plan how the workload repopulates its local SSD. For replicated databases such as Cassandra, replace one node at a time and let the cluster stream data back.

6. Change the instance_type value and run terraform plan. Confirm the plan shows an in-place update to instance_type on aws_instance, which AWS applies by stopping and starting the instance.

7. Apply during a maintenance window, then validate disk mounts, replication health, and application performance.

8. Add Infracost to CI/CD so new i2 instance types are flagged in pull requests before they merge.

Best Practices

• Pin approved instance types in shared Terraform modules with a validation block, so i2 types fail at terraform plan.

• Migrate one node of a replicated cluster first. A single node shows whether drivers, mounts, and data streaming behave as expected.

• Treat instance store data as disposable. Back up or replicate anything that must survive an instance type change.

• Default to i3 for the largest saving per instance. Choose i4i when the workload benefits from the newer Ice Lake processor and extra memory, at about 10% more per hour.

• Review Reserved Instances and Savings Plans before migrating. A Standard Reserved Instance for i2 does not cover i3 usage.

• This policy targets the move away from i2. Choosing between i3, i3en, and i4i is a separate sizing decision based on storage density and I/O needs.

Tools and Scripts

How does Infracost detect previous-generation Amazon EC2 i-family instances automatically?

The Amazon EC2 i-family latest generation policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks EC2 resources in each pull request and flags i2 instance types in the PR comment, with the exact file and line to change.

The same Infracost pull request comment shows the estimated monthly cost of the change. Reviewers see what an i2.xlarge costs before it merges, not on next month's AWS bill.

Infracost also scans connected repositories for i2 instance types already in code. FinOps and platform teams can burn down that backlog over time and measure progress, tracking issues prevented in pull requests separately from existing issues fixed.

Teams can set the policy to warn engineers or block pull requests, and can limit it to new resources only so an unrelated pull request does not force a data migration.

To find i2 instance types in a Terraform codebase:

grep -rnE '"i2\.[0-9]*x?large"' --include="*.tf" --include="*.tfvars"

grep -rnE '"i2\.[0-9]*x?large"' --include="*.tf" --include="*.tfvars"

grep -rnE '"i2\.[0-9]*x?large"' --include="*.tf" --include="*.tfvars"

To list running EC2 instances on i2 with the AWS CLI:

aws ec2 describe-instances \
  --filters "Name=instance-type,Values=i2.*" \
  --query "Reservations[].Instances[].{id:InstanceId,type:InstanceType,state:State.Name}" \
  --output

aws ec2 describe-instances \
  --filters "Name=instance-type,Values=i2.*" \
  --query "Reservations[].Instances[].{id:InstanceId,type:InstanceType,state:State.Name}" \
  --output

aws ec2 describe-instances \
  --filters "Name=instance-type,Values=i2.*" \
  --query "Reservations[].Instances[].{id:InstanceId,type:InstanceType,state:State.Name}" \
  --output

If an instance is managed by Terraform, change instance_type in code rather than in the console. Otherwise the next terraform apply sets the old type again.

Examples of Impact

Savings from the Amazon EC2 i-family generation upgrade are large per instance, because i3 costs roughly a third of the i2 hourly rate.

Illustrative example: a Cassandra cluster. A platform team runs six i2.xlarge nodes for a Cassandra ring. Replacing them one at a time with i3.xlarge cuts on-demand compute cost by about 63%, roughly $2,370 per month across the cluster, while moving data onto faster NVMe storage.

Illustrative example: a search tier in an Auto Scaling group. A team runs search nodes from a launch template set to i2.2xlarge. Updating the launch template to i3.2xlarge and rolling the group through an instance refresh cuts the on-demand hourly rate by about 63% for every node the group launches from then on.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Amazon EC2 i-family upgrade is high reward, but the local SSD is where migrations go wrong.

• Instance store data is lost. Changing the instance type stops the instance, and data on i2 instance store volumes does not survive a stop.

• Device names change. i3 exposes instance store as NVMe devices, so /etc/fstab entries and mount scripts written for i2 need updating.

• Driver support. i3 and newer types need ENA and NVMe drivers. Very old custom AMIs may need updating before the move.

• Reservations do not move automatically. Convertible Reserved Instances for i2 can be exchanged. Standard Reserved Instances must run out or be sold on the Reserved Instance Marketplace.

• Provider-specific. This policy targets Amazon EC2 through the aws Terraform provider. Azure and Google Cloud have their own storage-optimized VM families with different names.

Related Policies and Concepts

• Amazon EC2 - consider using latest generation instances for r family instances: the same generation upgrade for memory-optimized EC2 instances.

• Amazon EC2 - consider using latest generation instances for m family instances: the same generation upgrade for general-purpose EC2 instances.

• Amazon EC2 - consider using latest generation instances for c family instances: the compute-optimized equivalent of this i-family policy.

• Amazon OpenSearch - consider using latest generation instances for i family instances: the managed search version of this policy, moving i2 search nodes to i3.

• Amazon EBS - consider upgrading gp2 volumes to gp3: a related policy for the EBS volumes that sit alongside instance store on storage-heavy EC2 workloads.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon EC2 i-family latest generation policy is supported in Infracost and available in the free trial. Infracost flags EC2 resources using i2 instance types in pull requests, so the team can change the instance type before merge.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Amazon EC2 i-family latest generation policy. For example, a finding can warn engineers or block the pull request, and can apply to new resources only.

Does Infracost automatically fix violations?

Not without review. Infracost reports each i2 instance type in the pull request with the file and line to change. For existing issues, Infracost AutoFix can open a pull request with a suggested change, which an engineer reviews, tests, and merges. Moving an Amazon EC2 i-family instance also requires a plan for its local SSD data.

Is this policy cloud-agnostic?

No. The Amazon EC2 i-family latest generation policy targets Amazon EC2 through the aws Terraform provider. Azure and Google Cloud have their own storage-optimized VM families, with different resource and attribute names.

Which Amazon EC2 i-family generation should replace i2?

For the largest saving, i3 is the direct replacement for i2, with the same vCPUs and memory at about 63% lower cost in US East. Choose i4i when the Amazon EC2 workload benefits from a newer processor and extra memory, at about 10% more per hour than i3.

Does upgrading an Amazon EC2 i-family instance cause data loss?

It can. Changing the instance type on an Amazon EC2 i2 instance stops it, and data on instance store volumes does not survive a stop. Replicate or back up local SSD data first, and replace nodes one at a time in clustered workloads.

How often should I review Amazon EC2 instance generations?

Teams running Infracost in CI/CD get an Amazon EC2 i-family check on every pull request that touches an EC2 resource. For existing instances, a quarterly review of instance generations is a reasonable cadence for most teams.