Amazon EC2 – Consider Using Latest Generation t-Family Instances

The Amazon EC2 t-family latest generation policy flags burstable EC2 instances on the previous-generation t2 family and recommends t3, t3a, or Graviton-based t4g. A t3.medium costs about 10% less per hour than a t2.medium in US East (N. Virginia), with the same vCPU count and memory on a newer Intel Xeon processor and the AWS Nitro System. Apply this policy to any aws_instance or aws_launch_template whose instance_type starts with t2..

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon EC2 t-family instances are burstable. They run at a baseline CPU level and spend CPU credits to burst above it. This suits web servers, small APIs, build agents, and development environments.

The t2 family launched in 2014 on the Xen hypervisor. The t3 family runs on the AWS Nitro System with Intel Xeon Platinum 8000 series processors. It is EBS-optimized by default and supports up to 5 Gbps of network bandwidth.

A t3 instance costs less per hour than the t2 instance of the same size. Staying on t2 means paying more for older hardware.

This is a common source of wasted spend in long-lived AWS accounts. A t2.micro or t2.medium chosen years ago often sits in a shared module default that nobody has revisited.

Potential Savings

The Amazon EC2 t-family generation upgrade saves money because each current-generation option costs less per hour than t2 at the same 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 t2.medium to t3.medium saves about $3.50 per month, or roughly $42 per year. The per-instance number is small, which is exactly why t2 instances survive for years.

The same ratio holds across sizes. A fleet of 50 t2.medium instances moved to t3.medium saves about $175 per month, or $2,100 per year, from a one-line change per resource.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon EC2 instance on the previous t2 generation, and the corrected configuration on t3.

Non-compliant configuration: EC2 instance on t2

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t2.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

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

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t2.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

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

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t2.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

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

This configuration pays about 11% more every hour for an older processor and slower networking than a current-generation instance of the same size.

Compliant configuration: EC2 instance on t3

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

  credit_specification {
    cpu_credits = "standard"
  }

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

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

  credit_specification {
    cpu_credits = "standard"
  }

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

resource "aws_instance" "api" {
  ami                    = var.ami_id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.api.id]

  credit_specification {
    cpu_credits = "standard"
  }

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

The instance_type value is the change that fixes the policy violation. The resource name stays the same, so Terraform updates the existing instance instead of creating a new one.

The credit_specification block is optional. T3 instances launch in unlimited mode by default, while T2 instances launch in standard mode unless the account default was changed. Setting cpu_credits = "standard" keeps the t2 billing behavior, so sustained bursts are throttled instead of billed as surplus credits.

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

resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = var.ami_id
  instance_type = "t3.small" # previously "t2.small"

  credit_specification {
    cpu_credits = "standard"
  }
}

resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = var.ami_id
  instance_type = "t3.small" # previously "t2.small"

  credit_specification {
    cpu_credits = "standard"
  }
}

resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = var.ami_id
  instance_type = "t3.small" # previously "t2.small"

  credit_specification {
    cpu_credits = "standard"
  }
}

Step-by-Step Fix Instructions

1. Search Terraform code for instance_type values that start with t2. 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 the resource block.

3. Confirm the AMI supports the AWS Nitro System. t3 and later need ENA and NVMe drivers, which current Amazon Linux, Ubuntu, and Windows Server AMIs include.

4. Pick the target. Use t3 for a direct x86 replacement, t3a for lower cost on AMD, or t4g only if the workload and AMI run on Arm64.

5. Decide the credit mode. Add a credit_specification block with cpu_credits = "standard" if the workload previously relied on t2 throttling to cap cost.

6. Change the instance_type value and run terraform plan. Confirm the plan shows an in-place update to instance_type, not a resource replacement.

7. Apply during a maintenance window. Changing the instance type on an aws_instance stops and starts the instance.

8. Validate the workload, then add Infracost to CI/CD so new t2 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 t2 types fail at terraform plan.

• Migrate development and staging instances first. A stop and start can surface driver or boot issues on old AMIs.

• Watch CPU credit usage for the first few weeks after moving to t3 in unlimited mode. A workload that bursts constantly may cost more than expected.

• Review Reserved Instances and Savings Plans before migrating. A standard Reserved Instance for t2 does not cover t3 usage; Compute Savings Plans apply across families.

• Treat t4g as a separate decision. Moving to Graviton saves the most, but it requires Arm64 builds of every binary and container image.

• This policy is aimed at burstable workloads. If an Amazon EC2 t3 instance runs near 100% CPU most of the day, a fixed-performance family such as m-family is usually the better fit.

Tools and Scripts

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

The Amazon EC2 t-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. It flags t2 instance types in the PR comment, with the file and line to change.

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

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

Teams can set the policy to warn engineers or block pull requests. Teams can also limit the policy to new resources only, so an unrelated PR does not force an instance restart.

To find t2 instance types in a Terraform codebase:

grep -rnE '"t2\.(nano|micro|small|medium|large|xlarge|2xlarge)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"t2\.(nano|micro|small|medium|large|xlarge|2xlarge)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"t2\.(nano|micro|small|medium|large|xlarge|2xlarge)"' --include="*.tf" --include="*.tfvars"

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

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

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

aws ec2 describe-instances \
  --filters "Name=instance-type,Values=t2.*" \
  --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 t-family generation upgrade scale with fleet count, because the code change per resource is one attribute.

Illustrative example: a fleet of development environments. A platform team runs 60 t2.medium instances as per-engineer development boxes. Moving the shared module default to t3.medium cuts on-demand compute cost by about 10%, and the change ships in a single pull request.

Illustrative example: an Auto Scaling web tier. A team runs web servers from a launch template set to t2.large. Updating the launch template to t3.large and rolling the group through an instance refresh saves about 10% per hour. It also raises network bandwidth for the same traffic.

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

Considerations and Caveats

The Amazon EC2 t-family upgrade is low risk for most workloads, but credit mode and old AMIs are where migrations go wrong.

• Unlimited mode by default. T3, T3a, and T4g launch in unlimited mode. Sustained bursting above baseline is billed as surplus CPU credits, which can erase the hourly saving.

• Nitro driver support. t3 and later require ENA and NVMe drivers. Very old custom AMIs may not boot until these drivers are installed.

• vCPU count on small sizes. t3.nano, t3.micro, and t3.small have 2 vCPUs, while the t2 equivalents have 1. Check any software licensed per vCPU.

• Restart required. Changing instance_type stops and starts the instance. Without an Elastic IP, the public IPv4 address changes.

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

Related Policies and Concepts

• Amazon EC2 - consider using latest generation instances for m family instances: the same generation upgrade for general-purpose EC2 instances, and the usual home for t-family workloads that stop bursting.

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

• Amazon EC2 - consider using latest generation instances for r family instances: the memory-optimized equivalent of this t-family policy.

• AWS EC2 - consider using Graviton instances: a related Compute-group policy for moving x86 instances, including t3, to Arm-based Graviton types such as t4g.

• Amazon EC2 - Consider using a preferred instance type: a broader policy that limits EC2 instance types to an approved list that can exclude t2.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon EC2 t-family latest generation policy is supported in Infracost and available in the free trial. Infracost flags EC2 resources using t2 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 t-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?

No. Infracost reports each t2 instance type in the pull request with the file and line to change. Choosing between t3, t3a, or t4g depends on architecture and credit mode, so the team makes that decision.

Is this policy cloud-agnostic?

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

Which Amazon EC2 instance type should replace t2?

For most x86 workloads, t3 is the direct replacement for t2 at the same size and about 10% lower cost. Choose t3a for a larger saving on AMD processors. Choose t4g when the Amazon EC2 workload already runs on Arm64.

Can moving from t2 to t3 increase my Amazon EC2 bill?

Yes, in one case. Amazon EC2 t3 instances launch in unlimited mode, so a workload that bursts above baseline for long periods pays for surplus CPU credits. Setting cpu_credits to standard in the credit_specification block avoids that charge.

How often should I review Amazon EC2 instance generations?

Teams running Infracost in CI/CD get an Amazon EC2 t-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.