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

The Amazon EC2 c-family latest generation policy flags compute-optimized EC2 instances running a previous c-family generation, such as c3 or c4, and recommends a current generation such as c5, c6i, or c7g. A c5.large costs about 19% less per month than a c3.large in US East (N. Virginia), with more memory and a newer processor. Apply this policy to any aws_instance or aws_launch_template whose instance_type uses a previous-generation c-family type.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon EC2 c-family instances are compute-optimized. Teams use them for batch processing, web and API servers, CI build runners, video encoding, and other CPU-bound workloads.

AWS classifies c1, c3, and c4 as previous-generation instance types. From c3 through c6i, each new c-family generation costs the same or less per hour than the one before it, on faster hardware.

A c3.large runs on an Intel Xeon E5-2680 v2 (Ivy Bridge) processor. A c5.large runs on an Intel Xeon Platinum processor with AVX-512 support, is EBS-optimized by default, and uses the AWS Nitro System with the Elastic Network Adapter (ENA).

The c5 family scales to 96 vCPUs and 192 GiB of memory on c5.24xlarge, with up to 25 Gbps of network bandwidth on the largest sizes.

Staying on c3 or c4 means paying more per hour for slower CPUs. This is a common source of wasted spend in long-lived AWS accounts, where the instance type was set years ago and never revisited.

Potential Savings

The Amazon EC2 c-family generation upgrade saves money because the current generation costs less per hour than the generation it replaces.

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 c3.large to c5.large saves about $14.60 per month, or roughly $175 per year. The same ratio holds across sizes, so a fleet of c3.2xlarge or c3.8xlarge instances saves proportionally more.

The c4 to c5 saving is about 15%. Moving to Graviton-based c7g saves about 31% against c3, but only for workloads that already run on Arm64.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon EC2 instance on a previous c-family generation, and the corrected configuration on c5.

Non-compliant configuration: EC2 instance on c3

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

This configuration pays about 19% more every hour for an older Ivy Bridge processor and less memory than a current-generation instance of the same size.

Compliant configuration: EC2 instance on c5

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

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

  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }

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

The only change is the instance_type value. The resource address stays the same, so Terraform updates the existing instance in place instead of creating a new one.

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

resource "aws_launch_template" "build_runners" {
  name_prefix   = "build-runners-"
  image_id      = var.ami_id
  instance_type = "c5.xlarge" # previously "c4.xlarge"
}

resource "aws_launch_template" "build_runners" {
  name_prefix   = "build-runners-"
  image_id      = var.ami_id
  instance_type = "c5.xlarge" # previously "c4.xlarge"
}

resource "aws_launch_template" "build_runners" {
  name_prefix   = "build-runners-"
  image_id      = var.ami_id
  instance_type = "c5.xlarge" # previously "c4.xlarge"
}

Step-by-Step Fix Instructions

1. Search Terraform code for instance_type values that start with c1., c3., or c4. in aws_instance and aws_launch_template resources.

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 supports the AWS Nitro System. c5 and later need ENA and NVMe drivers, which current Amazon Linux, Ubuntu, and Windows Server AMIs include.

4. For c3 instances, check whether the workload writes to the local instance store SSD. c5 and c6i have no instance store, so use c5d or c6id if the workload needs local disk.

5. Pick the target size by matching vCPU count. Consider c7g only if the workload and AMI run on Arm64.

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 previous-generation c-family types are flagged in pull requests before they merge.

Best Practices

• Pin approved instance types in shared Terraform modules with a validation block, so previous-generation c-family types fail at terraform plan.

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

• Review Reserved Instances and Savings Plans before migrating. A standard Reserved Instance for c4 does not cover c5 usage. Compute Savings Plans apply across instance families.

• Default Intel workloads to c6i, which matches c5 on price with a newer Ice Lake processor. c7i costs about 5% more per hour than c6i in US East.

• Use c7g only when the software stack and container images already support Arm64.

• This policy targets x86 upgrades within the c-family. Moving to Graviton is a separate decision with its own testing cost.

Tools and Scripts

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

The Amazon EC2 c-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 previous-generation c-family 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 c3.large costs before it merges, not on next month's AWS bill.

Infracost also scans connected repositories for previous-generation c-family 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 it to new resources only, so an unrelated PR does not force a risky instance change.

To find previous-generation c-family types in a Terraform codebase:

grep -rnE '"c[134]\.[0-9]*x?(large|medium)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"c[134]\.[0-9]*x?(large|medium)"' --include="*.tf" --include="*.tfvars"

grep -rnE '"c[134]\.[0-9]*x?(large|medium)"' --include="*.tf" --include="*.tfvars"

To list running EC2 instances on c1, c3, or c4 with the AWS CLI:

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

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

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

Illustrative example: an API tier. A platform team runs twelve c3.2xlarge instances behind a load balancer. Moving to c5.2xlarge cuts on-demand compute cost by about 19% and adds memory per node, after confirming the service does not rely on the c3 instance store.

Illustrative example: a CI build runner pool. A DevOps team runs build runners from a launch template set to c4.xlarge. Updating the launch template to c5.xlarge and rolling the Auto Scaling group through an instance refresh saves about 15% per hour on the same build jobs.

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

Considerations and Caveats

The Amazon EC2 c-family upgrade is low risk for most workloads, but old AMIs and instance store usage are where migrations go wrong.

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

• Instance store loss. c3 includes local SSD storage. c5 and c6i have none, and instance store data does not survive a stop.

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

• Reservations do not move automatically. Convertible Reserved Instances for c3 or c4 can be exchanged for c5. 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 compute-optimized generations 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.

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

• Amazon EC2 - consider using latest generation instances for t family instances: the burstable-instance version of the same upgrade, from t2 to t3.

• Amazon EC2 - consider using latest generation instances for i family instances: the storage-optimized version of this policy, where instance store changes matter even more.

• Amazon EC2 - Consider using a preferred instance type: a related Compute-group policy that restricts EC2 instance types to an approved list, which can exclude previous c-family generations by default.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon EC2 c-family latest generation policy is supported in Infracost and available in the free trial. Infracost flags previous-generation c-family instance types in Terraform 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 c-family latest generation policy. A finding can warn engineers or block the pull request, and the policy can apply to new resources only.

Does Infracost automatically fix violations?

No. Infracost reports each previous-generation Amazon EC2 c-family instance type in the pull request with the file and line to change. Choosing between c5, c5d, c6i, or c7g depends on instance store and CPU architecture needs, so the team makes that decision.

Is this policy cloud-agnostic?

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

Which Amazon EC2 c-family generation should replace c3 or c4?

For most x86 workloads, c5 or c6i is the direct replacement, at the same hourly rate in US East. Choose c5d or c6id when the workload needs local instance storage. Choose c7g when the Amazon EC2 workload already runs on Arm64.

Does upgrading an Amazon EC2 c-family instance cause downtime?

Yes, briefly. Changing the instance type on an Amazon EC2 instance requires a stop and start. Plan the change in a maintenance window, or roll it through an Auto Scaling group with an instance refresh.

How often should I review Amazon EC2 c-family instance generations?

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