How to fix cpu_options.0.core_count conflicts with cpu_core_count in Terraform

TerraformBEGINNERMEDIUMUpdated Dec 30, 2025· 110 views

The Terraform AWS provider throws a conflicting configuration error when both the deprecated cpu_core_count argument and the newer cpu_options block are present in the same aws_instance resource. This conflict occurs because these are two incompatible ways of specifying the same CPU configuration, with cpu_core_count being deprecated in favor of cpu_options.

Quick fix

Fixes cpu_options.0.core_count conflicts with cpu_core_count

cpu_core_count       = 4
cpu_threads_per_core = 2
  1. Identify which method your configuration uses
  2. Remove the deprecated cpu_core_count and cpu_threads_per_core arguments
  3. Add the cpu_options block if you need CPU customization
  4. Verify your configuration syntax
terraform — error
cpu_core_count       = 4
cpu_threads_per_core = 2
cpu_options.0.core_count conflicts with cpu_core_count

What this error means

The Terraform AWS provider (v5.0.0+) deprecated the cpu_core_count and cpu_threads_per_core arguments in favor of the newer cpu_options block. When Terraform detects both the old and new syntax in the same resource configuration, it raises a validation error because the two approaches are mutually exclusive. You cannot use both simultaneously—you must choose one method for configuring EC2 CPU options.

Typical symptoms

  • Error message shows 'cpu_options.0.core_count: conflicts with cpu_core_count' during terraform plan
  • Error message shows 'cpu_options.0.threads_per_core: conflicts with cpu_threads_per_core'
  • Error appears when using terraform import with the -generate-config-out option to auto-generate code
  • Configuration worked in older AWS provider versions but fails after upgrading to v5.0.0 or later
  • Issue occurs when using Terraformer or other code generation tools that import AWS resources

Common causes

  1. Configuration uses both deprecated cpu_core_count/cpu_threads_per_core and the newer cpu_options block
  2. Generated configuration from terraform import or Terraformer tool includes both old and new syntax
  3. Manual migration from old syntax to new syntax left both methods in the same resource
  4. Provider version was upgraded to v5.0.0 or later without updating the configuration syntax
  5. Copy-pasting configuration from multiple sources combined deprecated and new arguments

How to fix "cpu_options.0.core_count conflicts with cpu_core_count"

1Identify which method your configuration uses

Open your Terraform configuration file (main.tf, variables.tf, etc.) and search for the aws_instance resource block. Look for lines containing either:

Old (deprecated) method:

hcl
cpu_core_count       = 4
cpu_threads_per_core = 2

New method:

hcl
cpu_options {
  core_count       = 4
  threads_per_core = 2
}

Note whether you have one, both, or neither of these.

2Remove the deprecated cpu_core_count and cpu_threads_per_core arguments

Delete the deprecated top-level arguments from your aws_instance resource. For example, change this:

hcl
resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "m5.large"
  cpu_core_count       = 4
  cpu_threads_per_core = 2
}

To this:

hcl
resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "m5.large"
}
3Add the cpu_options block if you need CPU customization

If you need to specify custom CPU options, use the newer cpu_options block instead:

hcl
resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "m5.large"

  cpu_options {
    core_count       = 4
    threads_per_core = 2
  }
}

The cpu_options block must include both core_count and threads_per_core if you use it. These values are set at instance launch time and cannot be changed afterward.

4Verify your configuration syntax

Check that your aws_instance resource no longer has any of these deprecated arguments:
- cpu_core_count
- cpu_threads_per_core

Run a syntax check:

bash
terraform validate

If the validate command succeeds without errors, your syntax is correct.

5Run terraform plan to verify the conflict is resolved

Execute a plan to confirm the error is gone:

bash
terraform plan

If the plan succeeds without the conflicting configuration error, the issue is resolved. Review the proposed changes to ensure they match your intentions before applying.

6Handle existing instances (if managing state)

If you're managing existing AWS infrastructure:

1. For new instances: The cpu_options block will be applied at creation time.

2. For existing instances: Terraform will not attempt to modify cpu_options after the instance is created (AWS does not support this). If you change cpu_options in your configuration, Terraform will require the instance to be destroyed and recreated.

To see what changes Terraform plans:

bash
terraform plan -out=tfplan
terraform show tfplan

Review carefully before applying if it shows a resource must be replaced.

Advanced notes

Immutable CPU Options: AWS does not allow you to change CPU options after an EC2 instance is launched. The core_count and threads_per_core values are set only at instance creation time. If you modify these values in your Terraform configuration, Terraform will be forced to destroy and recreate the instance.

Terraformer Migration: If you're using Terraformer to import AWS infrastructure, it may generate code with both old and new syntax. This is a known issue (GitHub #1712). The workaround is to manually remove the deprecated arguments after import.

Not all instance types support CPU customization: The cpu_options feature is only available on certain EC2 instance types. Attempting to use cpu_options with an instance type that doesn't support it will fail. Check the AWS documentation for your instance type before using cpu_options.

Threads per core values: The threads_per_core value can only be 1 (disables hyperthreading) or 2 (default, hyperthreading enabled). Other values are not valid.

AWS Provider v5.0.0 breaking change: This deprecation was introduced in AWS provider v5.0.0 as part of a major version upgrade. If you're still using provider v4.x, you can continue using the old syntax, but plan to migrate before upgrading to v6.0.0 when these arguments will be completely removed.

Frequently asked questions

What does "cpu_options.0.core_count conflicts with cpu_core_count" mean?
0+) deprecated the cpu_core_count and cpu_threads_per_core arguments in favor of the newer cpu_options block. When Terraform detects both the old and new syntax in the same resource configuration, it raises a validation error because the two approaches are mutually exclusive. You cannot use both simultaneously—you must choose one method for configuring EC2 CPU options.
How do I fix "cpu_options.0.core_count conflicts with cpu_core_count"?
The Terraform AWS provider throws a conflicting configuration error when both the deprecated cpu_core_count argument and the newer cpu_options block are present in the same aws_instance resource. This conflict occurs because these are two incompatible ways of specifying the same CPU configuration, with cpu_core_count being deprecated in favor of cpu_options.
What causes "cpu_options.0.core_count conflicts with cpu_core_count"?
Configuration uses both deprecated cpu_core_count/cpu_threads_per_core and the newer cpu_options block Generated configuration from terraform import or Terraformer tool includes both old and new syntax Manual migration from old syntax to new syntax left both methods in the same resource
Is the "cpu_options.0.core_count conflicts with cpu_core_count" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading